• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04M
管理番号 1286095
審判番号 不服2013-15075  
総通号数 173 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-05-30 
種別 拒絶査定不服の審決 
審判請求日 2013-08-05 
確定日 2014-04-08 
事件の表示 特願2010-544402「発話名の発音の音声版を提供するシステムおよび方法」拒絶査定不服審判事件〔平成21年 7月30日国際公開、WO2009/094415、平成23年 4月 7日国内公表、特表2011-511537、請求項の数(10)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 1.手続の経緯と本願発明
本願は、2009年 1月22日(パリ条約による優先権主張外国庁受理2008年 1月24日、(US)米国)を国際出願日とする出願であって、平成25年 4月 3日付けで拒絶査定がなされ、これに対し、平成25年 8月 5日付けで審判請求がなされたものである。
本願の特許請求の範囲の請求項1?10に係る発明は、平成24年10月16日付け手続補正書の特許請求の範囲の請求項1?10に記載された以下のとおりのものと認める。

「 【請求項1】
録音型発話名の発音の音声版を提供する方法であって、
アプリケーション・サーバが、ハイパーテキスト転送プロトコル(hｔｔｐ)インターフェースを介して、人物の発話名の発音を要求するユーザ要求を受信するステップと、
前記アプリケーション・サーバが、外部ボイスメール・システムに、前記外部ボイスメール・システムに保存された録音型発話名(RSN_(VM))音声ファイルを要求するRSN_(VM)要求クエリを送信するステップとを含み、前記RSN_(VM)音声ファイルは前記人物が当人の名前を発話した録音型音声コンテンツを含み、さらに、
前記アプリケーション・サーバが、前記外部ボイスメール・システムから、前記RSN_(VM)音声ファイルを収納したRSN_(VM)応答を受信するステップと、
前記アプリケーション・サーバが、ハイパーテキスト転送プロトコル(hｔｔｐ)インターフェースを介して、ネットワーク・アクセス端末の前記ユーザに、前記ネットワーク・アクセス端末による再生用に前記人物の発話名の発音の音声版を提供する前記RSN_(VM)音声ファイルを送信するステップとを含む方法。

【請求項2】
前記人物が名簿サービスのメンバであり、前記アプリケーション・サーバが、前記ユーザに前記メンバに関する名簿情報を提供する名簿サービス・アプリケーション・サーバである、請求項1に記載の方法。

【請求項3】
前記アプリケーション・サーバが、名簿メンバ・プロファイル・データベースに、前記名簿メンバにRSN_(VM)が利用可能であるかを判定するためにhｔｔｐクエリを送信するステップと、
前記アプリケーション・サーバが、前記名簿メンバ・プロファイル・データベースから、前記名簿メンバに関連付けられたRSN_(VM)識別子(RSN_(VM)ID)を受信するステップとをさらに含む、請求項2に記載の方法。

【請求項4】
前記アプリケーション・サーバが、前記ボイスメール・システムに前記RSN_(VM)要求クエリを送信するために前記ボイスメール・システムを位置付けるためのRSN_(VM)IDを使用するステップをさらに含み、前記ボイスメール・システムがボイスメール・プロセッサを含み、前記RSN_(VM)IDが、前記ボイスメール・プロセッサのIPアドレスまたはドメイン名を含む位置情報を含む、請求項3に記載の方法。

【請求項5】
前記アプリケーション・サーバが、1人または複数のユーザから複数の異なる人物の発話名の発音に対する複数のユーザ要求を受信するステップと、
前記アプリケーション・サーバが、複数の異なる外部ボイスメール・システムに、前記外部ボイスメール・システムに保存された録音型発話名(RSN_(VM))音声ファイルを要求するRSN_(VM)要求クエリを送信するステップとを含み、前記RSN_(VM)音声ファイルの各々が前記複数の異なる人物の異なる1人に対応し、さらに、
前記アプリケーション・サーバが、前記外部ボイスメール・システムから前記RSN_(VM)音声ファイルを受信するステップと、
前記アプリケーション・サーバが、1つまたは複数のネットワーク・アクセス端末の前記1人または複数のユーザに前記人物の発話名の発音の音声版を提供する前記RSN_(VM)音声ファイルを送信するステップとをさらに含む、請求項4に記載の方法。

【請求項6】
ユーザに人物の録音型発話名の発音の音声版を提供するシステムであって、
人物の発話名の発音を求めたユーザ要求を受信するためにハイパーテキスト転送プロトコル(hｔｔｐ)インターフェースを介してユーザ操作のネットワーク・アクセス端末に接続されたアプリケーション・サーバを含み、外部ボイスメール・システムに保存された、人物が当人の名前を発話した録音型発話名(RSN_(VM))音声ファイルを要求するRSN_(VM)要求hｔｔｐクエリを送信するため、そして、非通話環境で、前記RSN_(VM)音声ファイルを、前記ユーザに前記人物の録音型発話名の発音の音声版を提供すべく再生用に前記ユーザ操作のネットワーク・アクセス端末に送信するために、前記アプリケーション・サーバがhｔｔｐインターフェースを介して前記外部ボイスメール・システムに接続される、システム。

【請求項7】
前記人物が名簿サービスのメンバであり、前記アプリケーション・サーバが、前記ユーザに前記メンバに関する名簿情報を提供する名簿サービス・アプリケーション・サーバである、請求項6に記載のシステム。

【請求項8】
前記名簿メンバに関連付けられたRSN_(VM)識別子(RSN_(VM)ID)を名簿メンバ・プロファイル・データベースから前記アプリケーション・サーバに送信するために前記アプリケーション・サーバに接続された名簿メンバ・プロファイル・データベースをさらに含む、請求項7に記載のシステム。

【請求項9】
前記ボイスメール・システムがボイスメール・プロセッサを含み、前記RSN_(VM)IDが、前記ボイスメール・プロセッサのIPアドレスまたはドメイン名を含む位置情報を含む、請求項8に記載のシステム。

【請求項10】
前記アプリケーション・サーバが、ボイスメール・システムに保存された録音型発話名(RSN_(VM))音声ファイルを要求するRSN_(VM)要求hｔｔｐクエリを送信するために、hｔｔｐインターフェースを介して前記複数の異なる外部ボイスメール・システムに接続され、前記RSN_(VM)音声ファイルの各々が、複数の異なる人物の異なる1人に対応してユーザにユーザに発話名の発音を提供し、前記ボイスメール・システムがボイスメール・プロセッサを含み、前記名簿メンバ・プロファイル・データベースが、複数の異なる人物のそれぞれ異なる前記1人ごとに関連付けられたRSN_(VM)IDを含み、前記RSN_(VM)IDが前記ボイスメール・プロセッサの前記IPアドレスまたは前記ドメイン名を有する、請求項9に記載のシステム。」

2.引用例
(2-1)
これに対して、原査定の拒絶理由に引用された米国特許第6,810,113号明細書(以下、「引用例1」という。)には、「METHODS AND SYSTEMS TO MAKE SPOKEN NAME DATA AVAILABLE」(発話名データを利用可能にするための方法及びシステム)(( )は当審仮訳。以下も同様。)として、図面とともに以下の事項が記載されている。

イ.「The present inventions relate to messaging systems, and particularly, relate to embodiments that present a sender of message with an announcement of a name or other information related to the recipient.」(1欄14?17行)
(この発明は、メッセージングシステムに関連し、特に、メッセージの送信者に、受信者に関連する名前又は他の情報についての告知を提供する態様に関連する。)

ロ.「FIG. 1 is a block diagram of an exemplary system 10 wherein exemplary embodiments of the present inventions may be implemented or operated. The system 10 includes a variety of interconnected network elements. A group of such elements includes the plurality of end offices, which are indicated as service switching points (SSPs or switches) 12a, 12b, 12c. An SSP typically includes switch functionality, but also includes other functionality so as to communicate with other network elements, and in particular, with Advanced Intelligent Network (AIN) elements. SSP 12a and SSP 12c are each coupled to a subscriber line, which also may be referred to as a line or calling line. Each SSP 12a, 12b, 12 c serves a designated group of lines, and thus, the SSP that serves a particular line may be referred to as its serving switch. The line is typically connected to a piece of terminating equipment including a telephone 14. Although a telephone 14 is illustrated as the terminating equipment, such terminating equipment may include other telecommunication devices including facsimile machines, computers, modems, etc. End offices may further be coupled through a tandem office (not illustrated), which may be used to connect and switch circuits between and among end offices.
Each active line in an AIN is assigned a ten digit (NPA-NXX-XX XX) line number regardless of whether seven or ten digits are dialed to reach the subscriber. A line number is commonly referred to as a number, telephone number, destination number, or a directory number.
SSP 12b is connected by trunks (Signaling System 7 (SS7)) to a voice mail system (VMS1) 15. (These trunks use SS7 signals for call set-up and other actions and are referred to as SS7 trunks.) SSP 12c is connected by SS7 trunks to a voice mail system (VMS2) 17. A voice mail system (VMS) also may be referred to as a messaging platform (MP).
SSPs 12a, 12b, 12c are interconnected by a plurality of trunk circuits 18. These are the voice path trunks that interconnect the SSPs to connect communications. Each of the SSPs may be connected to another type of AIN element referred to as a local signal transfer point (STP) 20 via respective data links. Currently, these data links employ a signaling protocol referred to as Signaling System 7 (SS7). Much of the intelligence of the AIN resides in yet another type of element referred to as a service control point (SCP) 22 that is connected to STP 20 over an SS7 data link. Among the functions performed by the SCP 22 is the maintenance of network databases and subscriber databases as represented collectively by databases 24.」(6欄21?66行)
(図1は、この発明が実装され、動作される典型的なシステム10のブロック線図である。システム10は、様々な相互に接続されるネットワーク要素を含む。このような要素の1つのグループは、複数の終端局を含み、それらは、サービススイッチングポイント(SSPｓ又はスイッチ)12a、12b、12cとして表される。SSPは、典型的にスイッチ機能を含むが、また、他のネットワーク要素、特に、アドバンスドインテリジェントネットワーク(AIN)と通信するように、他の機能も含む。SSP12aとSSP12cは、各々、加入者線に結合され、それらは、また、ライン又は発呼ラインということができる。各SSP12a、12b、12cは、指定されたグループのラインを提供し、ここで、特定のラインを提供するSSPは、その提供するスイッチということができる。ラインは、典型的に、電話機14を含む1つの終端装置に接続される。電話機14が、終端装置として図示されているが、このような終端装置は、ファクシミリ装置、コンピュータ、モデム等を含む他の通信装置を含むことができる。終端局は、さらに、終端局間の回線を接続及びスイッチするために使用することができるタンデム局(図示せず)を介して結合される。
AINの各現用ラインは、加入者に到達するために7又は10デジットがダイヤルされるのかに係わらず、10デジット(NPA-NXX-XX XX)のライン番号が割り当てられる。ライン番号は、一般に、番号、電話番号、宛先番号、又は、見出し番号ということができる。
SSP12bはトランク(シグナリングシステム7(SS7))によって、ボイスメールシステム(VMS1)15に接続される(これらのトランクは、呼のセットアップ及び他のアクションのためにSS7信号を使用し、SS7トランクという。SSP12cはSS7トランクによって、ボイスメールシステム(VMS2)17に接続される。ボイスメールシステムは、また、メッセージングプラットフォーム(MP)ということができる。
SSP12a、12b、12cは、複数のトランク回線によって、相互に接続される。これらは、通信を接続するためにSSPを相互に接続する音声パストランクである。SSPの各々は、それぞれのデータリンクを経由して、ローカルな信号転送ポイント(STP)20というもう一つのタイプのAIN要素に接続することができる。現在、これらのデータリンクは、シグナリングシステム7(SS7)というシグナリングプロトコルを採用する。AINの能力の多くは、SS7データリンクを介してSTP20に接続されるサービスコントロールポイント(SCP)というもう一つのタイプの要素にも存在している。SCP22によって実行される機能の中に、データベース24によって集合的に表されるようなネットワークデータベース及び加入者データベースの維持がある。)

ハ.「The SCP 22 is coupled to or includes one or more databases 24 and a Region-Wide Messaging Directory (RMD) 24a. The RMD provides high-speed directory lookup for messaging subscribers. Generally, an RMD stores information referred to as profile data so as to determine which messaging platform of the system serves which subscriber. ・・・(中略)・・・
The RMD includes an interface for the Light-Weight Directory Access Protocol (LDAP). The RMD may act as both a client and a server with respect to LDAP. Particularly, the RMD acts as an LDAP server in responses to queries for subscriber profile data (also referred to as profile data) from clients. The queries typically are LDAP v.2 formatted queries. In addition, the RMD acts as an LDAP client when the RMD retrieves the spoken name data from a messaging platform. The spoken name data also may be referred to herein as spoken name verification. The RMD stores the subscriber profile data which may include subscriber, service, and other messaging data. LDAP clients may retrieve the profile data relating to a particular subscriber or number from the RMD. In addition, the RMD supports the LDAP attributes field for LDAP clients to choose the fields that they desire to retrieve from the server. As noted, the RMD also acts as an LDAP client to retrieve spoken name data from the VMSs. Each VMS has a unique domain name associated with it. The RMD stores the domain name of the subscriber's VMS in the service data of the subscriber's profile data.」(8欄32?67行)
(SCP22は、1又はそれ以上のデータベース24及びリージョンワイドメッセージングディレクトリ(RMD)に結合されるか、又は、含む。RMDは、メッセージングを行う加入者に対し、高速なディレクトリ調査を提供する。一般に、RMDは、システムのいずれのメッセージングプラットフォームがいずれの加入者に提供するかを決定するために、プロファイルデータという情報を蓄積している。・・・(中略)・・・
RMDは、ライトウエイトディレクトリアクセスプロトコル(LDAP)に対するインターフェースを含む。RMDは、LDAPに関して、クライアントとサーバーの両方で動作することができる。特に、RMDは、クライアントからの加入者プロファイルデータ(プロファイルデータともいう)に対するクエリへの応答において、LDAPサーバーとして動作する。クエリは、典型的に、LDAPV.2のフォーマットのクエリである。さらに、RMDが、メッセージングプラットフォームから発話名データを検索するとき、RMDは、LDAPクライアントとして動作する。発話名データは、また、ここでは、発話名の照合ということができる。RMDは、加入者、サービス及び他のメッセージングデータを含むことができる加入者プロファイルデータを蓄積する。LDAPクライアントは、RMDから、特定の加入者又は番号に関連するプロファイルデータを検索することができる。さらに、RMDは、LDAPクライアントがサーバーから検索することを望む領域を選択するためにLDAPの属性領域をサポートする。記述したように、RMDは、また、VMSから発話名データを検索するようにLDAPクライアントとして動作する。各VMSは、それに関連する唯一のドメイン名を有する。RMDは、加入者のプロファイルデータのサービスデータに、加入者のVMSのドメイン名を蓄積する。

ニ.「When a sender sends a message, replies to a message, or forwards a message to a recipient, the sender 14 typically contacts or is in contact with his or her messaging platform (VMS1) 15. When the sender indicates a desire to send, reply, or forward a message, the VMS1 obtains the number for the destination of the message from the sender. The VMS1 may already have the number if the sender is replying to a message. In response, the VMS1 takes action to obtain the spoken name data associated with the number. FIGS.2A and 2B provide examples of how the VMS1 may go about retrieving the spoken name data to announce or present to the sender.」(9欄36?47行)
(送信者がメッセージを送る、メッセージに返答する、又は、受信者にメッセージを転送するとき、送信者14は、典型的に、彼又は彼女のメッセージングプラットフォーム(VMS1)15に接続又は連絡をする。送信者が、メッセージを送る、返答する、又は、転送する希望を示すとき、送信者からメッセージの宛先に関する番号を取得する。送信者がメッセージへ返答をする場合には、VMS1は、すでに、番号を有することができる。応答として、VMS1は、番号に関連した発話名データを取得するための動作をする。図2A及び2Bは、VMS1が、送信者に告知又は提示するための発話名データを検索することに関して、どのように動作することができるかの例を提供する。)

ホ.「An alternative exemplary embodiment of the present inventions differs from the example of FIGS.2A-2B in that in these examples the directory obtains the spoken name data for the VMS1. FIG.3A is a flow diagram illustrating this alternative exemplary method. After start 300, per block 302, VMS1 15 uses a query to ask the RMD 24a for the subscriber profile data associated with the requested mailbox or number. The query from VMS1 to the RMD 24a may be referred to herein as a primary or initial query. The query may make use of a standardized protocol such as an LDAP query. The LDAP query includes the common name (CN), which is the number or mailbox number (plus the number of a submailbox, if applicable) of the recipient of the message. ・・・(中略)・・・
Per block 304, a determination is made as to whether the RMD 24a has the spoken name data (and/or other information). The RMD 24a uses the number or mailbox number to check whether the RMD 24a includes the spoken name data (and/or other information). As explained above, the RMD 24a sends an error message to VMS1 15 if the calling line number sent in VMS1's query is not for a valid subscriber.
If the RMD 24a does not have the spoken name data (and/or other information), then the RMD 24a takes action to obtain the spoken name data (and/or other information). Preferably, the RMD 24a includes profile data for subscribers in the messaging system. The profile data at least keeps track of which messaging platform in the messaging system serves which subscribers. The RMD 24a uses the number or the mailbox number received in the query from the VMS1 to obtain an indication as to the location of the spoken name data (and/or other information) relating to the recipient of the message. Once the RMD 24a has obtained this indication (preferably from the profile data), the RMD 24a then sends a query to the appropriate messaging platform serving the number or mailbox number. The query may make use of a standardized protocol such as an LDAP query. The LDAP query from the RMD 24a to the other messaging platform may be referred to herein as a secondary or follow-up query. This query may include an encoding attribute, and other information as appropriate, and requests the spoken name data (and/or other information) as shown in block 306.
Then in block 308, in response to the query from the RMD 24a, the VMS2 17 uses the number or mailbox number to obtain the spoken name data (and/or other information) related to the recipient of the message. The VMS2 17 sends the spoken name data and the appropriate value in the voice encoding attribute (and/or other information or attributes) to RMD 24a via a response. The response may make use of a standardized protocol such as an LDAP response. The VMS2 17 may convert the spoken name data (and/or other information) into the format used by the VMS1 15. The response from the VMS2 to the RMD may be referred to as a secondary or follow-up response. The response may make use of a standardized protocol such as an LDAP response.
As shown in block 310, if the RMD 24a has the spoken name data (and/or other information), or once the RMD 24a receives the spoken name data (and/or other information) from VMS2 17, the RMD 24a sends the spoken name data (and/or other information) to VMS1 15. In some cases, this may mean that the RMD 24a sends its profile data related to the recipient including the spoken name data (and/or other information) retrieved from the VMS2 17. The RMD 24a sends the spoken name data (and/or other information) to the VMS1 in a response to the VMS1's query. This response from the RMS 24a may be referred to as a primary or initial response. The response may make use of a standardized protocol such as an LDAP response.
The VMS1 15 receives the response from the RMS 24a. Then, as per block 312, VMS1 presents or otherwise makes an announcement of the spoken name (and/or other information) to the sender. The exemplary method then ends in block 314.」(12欄4?13欄18行)
(この発明の代替となる典型的な態様は、これらの例において、ディレクトリが、VMS1 15に対し、発話名データを取得することにおいて、図2A-2Bの例と相違する。図3は、この代替となる典型的な方法を記述した流れ線図である。開始300の後、ブロック302により、VMS1 15は、要求されたメールボックス又は番号に関連した加入者プロファイルデータをRMD24aに問い合わせるクエリを使用する。VSM1からRMD24aへのクエリは、ここでは、第1又は最初のクエリということができる。クエリは、LDAPクエリのような標準化されたプロトコルを利用することができる。LDAPクエリは、メッセージの受信者の番号又はメールボックス(可能なら、加えて、サブメールボックス)番号である、コモンネーム(CN)を含む。・・・(中略)・・・
ブロック304により、RMD24aが発話名データ(及び/又は、他の情報)を有するか否かについて決定が為される。RMD24aは、RMD24が発話名データ(及び/又は、他の情報)を含むか否かをチェックするために、番号又はメールボックス番号を利用する。上記で説明したように、VSM1のクエリで送られた発呼ライン番号が有効な加入者のものでない場合は、RMD24aは、VMS1にエラーメッセージを送る。
RMD24aが発話名データ(及び/又は、他の情報)を有していない場合は、RMD24aは、発話名データ(及び/又は、他の情報)を取得するための動作をする。好ましくは、RMD24aメッセージングシステムの加入者に対するプロファイルデータを含む。プロファイルデータは、少なくとも、メッセージングシステムのいずれのメッセージングプラットフォームがいずれの加入者に提供するのかを捕捉している。RMD24aは、メッセージの受信者に関連する発話名データ(及び/又は、他の情報)の場所についての指示を取得するために、VSM1からのクエリで受信した番号又はメールボックス番号を使用する。一度、RMD24aは、この指示を取得(好ましくは、プロファイルデータから)すると、RMD24aは、番号又はメールボックス番号を提供している適切なメッセージングプラットフォームにクエリを送信する。クエリは、LDAPクエリのような標準化されたプロトコルを利用することができる。RMD24aから他のメッセージングプラットフォームへのLDAPクエリは、ここでは、第2又はフォローアップクエリということができる。このクエリは、符号化属性、及び、適切な他の情報を含むことができ、ブロック306に表されるように、発話名データ(及び/又は、他の情報)を要求する。
そして、ブロック308において、RMD24aからのクエリへの応答として、VMS2 17は、メッセージの受信者に関連する発話名データ(及び/又は、他の情報又は属性)を取得するために、番号又はメールボックス番号を使用する。VMS2 17は、応答として、RMD24aに、発話名データ及び音声の符号化属性の適切な値(及び/又は、他の情報)を送信する。応答は、LDAP応答のような標準化されたプロトコルを利用することができる。VMS2 17は、発話名データ(及び/又は、他の情報)をVMS1 15が使用するフォーマットに変換することができる。VMS2からRDMへの応答は、第2又はフォローアップ応答ということができる。応答は、LDAP応答のような標準化されたプロトコルを使用することができる。
ブロック310に表されるように、RMD24aが発話名データ(及び/又は、他の情報)を有している、又は、一度、RMD24aが発話名データ(及び/又は、他の情報)をVMS2 17から受信する場合は、RMD24aは、発話名データ(及び/又は、他の情報)をVMS1 15に送信する。いくつかの場合、これは、RMD24aが、VMS2 17から検索された発話名データ(及び/又は、他の情報)を含む受信者に関連したそのプロファイルデータを送信することを意味することができる。RMD24aは、VMS1のクエリへの応答として、VMS1に発話名データ(及び/又は、他の情報)送信する。RMS24aからのこの応答は、第1又は最初の応答ということができる。応答は、LDAP応答のような標準化されたプロトコルを利用することができる。
VMS1 15は、RMS24aからの応答を受信する。そして、ブロック312により、VMS1は、送信者に発話名(及び/又は、他の情報)を提示、又は、さもなくば、告示する。典型的な方法は、ブロック314で終了する。)

ヘ.「FIG.3B illustrates the actions of the exemplary method of FIG.3A, but in block diagram form using arrows to illustrate the actions among the elements of the system 10. FIG.3B presents the relevant elements of the system 10 in simplified format for ease of explanation. In particular, this block diagram illustrates an exemplary method for VMS1 15 to interact with an intelligent network element (INE) such as an SCP in a messaging system and an other messaging platform in a messaging system to allow for the exchange of spoken name data relating to mailboxes among messaging platforms of the messaging system 10.
Pursuant to FIG.3B, in response to a sender indicating a desire to send a message, the VMS1 15 has obtained or has retained a number or mailbox number for the recipient of the message. The VMS1 transmits a query to an INE such as SCP 22 for profile data relating to the recipient of the message. The VMS1 may be referred to as a requesting messaging platform because it is requesting information. The query may be an LDAP query. See arrow 1 in FIG.3B. The INE includes a directory 24a that has profile data for keeping track of which messaging platform serves which mailbox of the mailboxes in the messaging system.
The directory 24a also includes a controller (not illustrated) with a functional connection through the SCP (or otherwise) to the VMS1 and to other messaging platforms such as VMS2 17. The controller responds to the query from the VMS1 15 by causing use of the profile data in a query/response exchange over a connection to VMS2 17 to obtain the particular spoken name data from the other messaging platform. See arrow 2.
The VMS2 17 uses the information provided in the query, specifically the number (CN) or mailbox number, to obtain the spoken name data related to the identity associated with the number of the recipient. The VMS 2 then provides the particular spoken name data in a response to the query from the directory 24a. See arrow 3 .
In response to receipt of the particular spoken name data from the VMS2 17, the controller of the directory 24a causes the particular spoken name data to be transmitted in a response to the requesting platform. See arrow 4. Upon receiving the response with the spoken name data from the VMS2, the VMS1 then makes an announcement or otherwise provides the spoken name data to the sender. Advantageously, the sender is provided with confirmation that the number the sender dialed is associated with a person or other entity who is to be the recipient of the message from the sender.」(13欄19?65行)
(図3Bは、システム10の要素間の動作を記述するために矢印を使用したブロック線図の形式ではあるが、図3Aの典型的な方法の動作を記述する。図3Bは、説明を容易にするために簡単な形式で、システム10の関連する要素を提示する。特に、このブロック線図は、VMS1が、メッセージングシステム10のメッセージングプラットフォーム間でメールボックスに関連する発話名データの交換を可能にするメッセージングシステムのSCPのようなインテリジェントネットワーク要素(INE)、及び、メッセージングシステムの他のメッセージングプラットフォームと相互に動作するための典型廷な方法を記述している。
図3Bに従って、メッセージを送信する希望を示している送信者への応答として、VMS1 15は、メッセージの受信者の番号又はメールボックス番号を取得又は保持している。VMS1は、メッセージの受信者に関連するプロファイルデータのために、SCP22のようなINEにクエリを転送する。VMS1は、情報を要求しているので、メッセージングを要求するプラットフォームということができる。クエリは、LDAPクエリとすることができる。図3Bの矢印1を参照して下さい。INEは、いずれのメッセージングプラットフォームが、メッセージングシステムのメールボックスのいずれのメールボックスに提供するのかを捕捉するためのプロファイルデータを有するディレクトリ24aを含む。ディレクトリ24aは、また、SCPを介して(又は、別な方法で)、VMS1及びVMS2 17のような他のメッセージングプラットフォームへ機能的に接続するコントローラ(図示せず)を含む。コントローラは、他のメッセージングプラットフォームから特定の発話名データを取得するため、VMS2 17への接続を介したクエリ/応答の交換によるプロファイルデータを利用することにより、VMS1 15からのクエリに応答する。矢印2参照。
VMS2 17は、受信者の番号に関連する識別子と関連した発話名データを取得するために、クエリで提供される情報、特に、番号(CN)又はメールボックス番号を使用する。VMS2は、そして、ディレクトリ24aからのクエリに応答し、特定の発話名データを提供する。矢印3参照。
VMS2 17からの特定の発話名データの受信に応答して、ディレクトリ24aのコントローラは、要求するプラットフォームへの応答として、特定の発話名データを転送させる。矢印4参照。VMS2から発話名データを伴う応答を受信すると、VMS1は、送信者に、告知をするか、さもなくば、発話名データを提供する。効果として、送信者は、送信者がダイヤルした番号が送信者からのメッセージの受信者となるべき人又は他のエンティティと関連するしていることの確認が提供される。)

上記引用例1の記載及び図面並びにこの分野の技術常識を考慮すると、
A.上記イ.ホ.及びヘ.の記載から、引用例1には、メッセージの「送信者」に、「メッセージの受信者」の「発話名データ」を提供する方法及びシステムが記載されていると認められる。
そして、同ホ.の「Then, as per block 312, VMS1 ・・・otherwise makes an announcement of the spoken name (and/or other information) to the sender.」(そして、ブロック312により、VMS1は、送信者に発話名(及び/又は、他の情報)を・・・さもなくば、告知する。)及び同ヘ.の「Upon receiving the response with the spoken name data from the VMS2, the VMS1 then makes an announcement ・・・ to the sender.」(VMS2から発話名データを伴う応答を受信すると、VMS1は、送信者に、告知をするか・・・。)という記載から、引用例1の方法及びシステムでは、「発話名データ」を音声として提供するものといえる。
B.上記ニ.の記載から、引用例1の方法及びシステムでは、ボイスメールシステム1(「VMS1」)が「送信者」から「メッセージ」の送信等の要求を受信し、さらに、上記ハ.ホ.及びヘ.の記載から、「VMS1」が、「リージョンワイドメッセージングディレクトリ(RMD)」に「メッセージの受信者」の「プロファイルデータ」を「問い合わせる」「第1のクエリ」を送信し、該「RMD」が、ボイスメールシステム2(「VMS2」)に保存された「発話名データ」を取得するための「第2のクエリ」を「VMS2」に送信することが明らかである。
そして、引用例1の方法及びシステムでは、同ホ.及びヘ.の記載から、「RMD」は、「VMS2」から「発話名データ」を含む「第2の応答」を受信し、さらに、「VMS1」は、該「RMD」から、該「発話名データ」を「第1の応答」として受信し、該「VMS1」は、「送信者」に該「発話名データ」を音声として提供することが明らかである。
また、引用例1の方法において、「VMS1」、「RMD」、「VMS2」が、要求や「クエリ」及び「応答」を受信/送信することは、受信/送信するステップといえることは自明である。
C.上記ロ.の記載及び図1、3Bから、引用例1に記載された「送信者」が、ネットワークに接続された端末のユーザとなることは明らかであり、該「端末」により、「発話名データ」が音声として提供されることは自明である。
D.上記ハ.ホ.及びヘ.の記載から、引用例1に記載された「VMS1」、「RMD」、「VMS2」の間の通信は、LDAPプロトコルを使用することが明らかである。
したがって、上記引用例1には、以下の発明(以下、「引用発明」という。)が記載されていると認められる。

「発話名データを音声として提供する方法であって、
VMS1が、送信者からのメッセージの送信等のための要求を受信するステップと、
前記VMS1が、RMDに、プロファイルデータを問い合わせる第1のクエリを送信し、前記RMDが、VMS2に、前記VMS2に保存された発話名データを取得するための第2のクエリを送信するステップとを含み、
前記RMDが、前記VMS2から、前記発話名データを含む第2の応答を受信し、前記VMS1は、前記RMDから、前記発話名データを含む第1の応答を受信するステップと、
前記VMS1が、ネットワークに接続された端末の送信者に、前記ネットワークに接続された端末により音声として提供する前記発話名データを送信するステップとを含む方法。」

(2-2)
同じく、原査定の拒絶理由に引用された米国特許第6,901,431号明細書(以下、「引用例2」という。)には、「APPLICATION SERVER PROVIDING PERSONALIZED VOICE ENABLED WEB APPLICATION SERVICES USING EXTENSIBLE MARKUP LANGUAGE DOCUMENTS」(拡張可能なマーク付け言語の文書を使用する個人向け音声を使用可能なWEBアプリケーションサービスを提供するアプリケーションサーバ)として、図面とともに以下の事項が記載されている。

イ.「The application server, upon receiving a voice application operation request from a browser serving a user, determines whether a personalized, user specific XML document exists for the user and for the corresponding voice application operation. If the application server determines the presence of the personalized XML document for a user-specific execution of the corresponding voice application operation, the application server dynamically generates a personalized HTML page having media content and control tags for personalized execution of the voice application operation; however if the application server determines an absence of the personalized XML document for the user-specific execution of the corresponding voice application operation, the application server dynamically generates a generic HTML page, based on a generic XML page, for generic execution of the voice application operation. Hence, a user can personalize any number of voice application operations, enabling a web-based voice application to be completely customized or merely partially customized.」(4欄9?28行)
(アプリケーションサーバは、ユーザにサービスを提供するブラウザーから音声アプリケーション操作の要求を受信すると、ユーザ及び対応する音声アプリケーション操作に対する個人向けの、ユーザに特化したXML文書が存在するか否か決定する。アプリケーションサーバが、対応する音声アプリケーション操作をユーザに特化して実行するための個人向けXML文書の存在を決定する場合、アプリケーションサーバは、動的に、メディアコンテンツと音声アプリケーション操作を個人向けに実行するための制御タグをを有する個人向けHTMLページを生成する。しかしながら、アプリケーションサーバが、対応する音声アプリケーション操作をユーザに特化して実行するための個人向けXML文書の不在を決定する場合、アプリケーションサーバは、動的に、音声アプリケーション操作の一般的に実行するために、一般的なXMLページに基づいて、一般的なXMLページを生成する。そして、ユーザは、如何なる数の音声アプリケーション操作も個人向けにすることができ、ウエッブベースの音声アプリケーションを完全にカスタマイズ又は単に部分的にカスタマイズすることができる。)

ロ.「One aspect of the present invention provides a method in an application server for executing a voice application. The method includes receiving an HTTP request requesting a prescribed voice application operation from a user. The method also includes selectively executing one of a generic XML document that specifies the prescribed voice application operation and a user-specific XML document that specifies the prescribed voice application operation personalized for the identified user, based on a determined presence of the user-specific XML document, for generation of an HTML page having media content corresponding to the prescribed voice application operation. The selected execution of either a generic XML document or a user-specific XML document enables a user to personalized his or her voice application, as desired. Hence, a user can personalize selected XML pages in order to provide a personalized interface, as well as personalized voice application logic and voice application functions such as procedure calls to external databases. Hence, a user can create a voice home page to greet callers with customized options, and/or a customized interface for accessing and retrieval of messages from the user's mailbox.」(4欄29?50行)
(この発明の1つの面は、アプリケーションサーバにおける音声アプリケーションを実行するための方法を提供することである。方法は、ユーザからの所定の音声アプリケーション操作を要求するHTTP要求を受信することを含む。方法は、また、所定の音声アプリケーション操作を特定する一般的なXML文書、及び、所定の音声アプリケーション操作に対応するメディアコンテンツを有するHTMLページを生成するため、ユーザに特化されたXML文書の決定された存在に基づいて、識別されたユーザに対し個人向けの所定の音声アプリケーション操作を特定するユーザに特化されたXML文書の1つを選択的に実行することを含む。一般的なXML文書、又は、ユーザに特化されたXML文書のいずれかの選択された実行は、希望されるように、ユーザに彼又は彼女の音声アプリケーションを個人向けとさせることができる。そして、ユーザは、手順が外部のデータベースへ電話するような個人向け音声アプリケーションロジック及び音声アプリケーション機能と同様に、個人向けインターフェースを提供するために、選択されたXMLページを個人向けとすることができる。そして、ユーザは、カスタマイズされたオプション、及び/又は、ユーザのメールボックスからメッセージへのアクセス及び検索のためのカスタマイズされたインターフェースで発呼者を迎えるための音声ホームページを作成することができる。)

ハ.「Another aspect of the present invention provides a system configured for configured for executing a voice application. The application server includes a hypertext transport protocol (HTTP) interface for receiving an HTTP request specifying execution of a prescribed voice application operation for an identified user. The application runtime environment is configured for dynamically generating, in response to the HTTP request, a first hypertext markup language (HTML) document having media content for execution of the voice application operation for the identified user based on execution of a selected XML document, the application runtime environment selecting one of a generic XML document that specifies the prescribed voice application operation and a user-specific XML document that specifies the prescribed voice application operation personalized for the identified user, based on a determined presence of the user-specific XML document. Hence, the application server generates an HTML page for execution of the voice application operation by a browser, based on the determined presence of a user-specific XML document, enabling a user to personalize their application interface and/or voice application functions.」(4欄51?5欄5行)
(この発明のもう1つの面は、音声アプリケーションを実行するために構成されたシステムを提供することである。アプリケーションサーバは、識別されたユーザのための所定の音声アプリケーション操作の実行を特定するHTTP要求を受信するためのハイパーテキストトランスポートプロトコル(HTTP)インターフェースを含む。アプリケーションの実行時の環境は、HTTP要求への応答として、選択されたXML文書の実行に基づいて、識別されたユーザのための音声アプリケーション操作の実行のためのメディアコンテンツを有する最初のハイパーテキストマークアップ言語(HTML)文書を動的に生成するために構成され、所定の音声アプリケーションを操作を特定する一般的なXML文書、及び、ユーザに特化したXML文書の決定された存在に基づいて、識別されたユーザのために個人向けの所定の音声アプリケーション操作を特定するユーザに特化したXML文書の1つを選択するアプリケーションの実行時の環境である。そして、アプリケーションサーバは、ユーザに特化したXML文書の決定された存在に基づいて、ブラウザーによる音声アプリケーション操作の実行のためのHTMLページを生成し、ユーザが、それらのアプリケーションインターフェース、及び/又は、音声アプリケーション機能を個人向けにすることができる。)

上記引用例2の記載及び図面並びにこの分野の技術常識を考慮すると、上記引用例2には、以下の事項(以下、「技術事項」という。)が記載されていると認められる。

「アプリケーションサーバが、ハイパーテキスト転送プロトコル(HTTP)インターフェースを介して、ユーザ要求を受信すること。」

3.対比
本願の請求項1に係る発明(以下、「本願発明」という。)と引用発明を比較すると、
イ.引用発明の「発話名データを音声として提供する」ことと、本願発明の「録音型発話名の発音の音声版を提供する」こととは、「録音型」という点を除いて、いずれも「発話名の発音の音声版を提供する」という点で一致する。
ロ.引用発明の「送信者からメッセージの送信等のための要求を受信する」と本願発明の「ハイパーテキスト転送プロトコル(hｔｔｐ)インターフェースを介して、人物の発話名の発音を要求するユーザ要求を受信する」とは、いずれも「ユーザ要求を受信する」という点で一致する。
ハ.引用発明の「VMS2」は、本願発明の「外部ボイスメール・システム」に相当し、また、引用発明の「発話名データ」と本願発明の「録音型発話名(RSN_(VM))音声ファイル」とは、いずれも「発話名音声ファイル」という点で一致する。
すると、引用発明の「VMS2に、VMS2に保存された発話名データを取得するための第2のクエリを送信する」と本願発明の「外部ボイスメール・システムに、前記外部ボイスメール・システムに保存された録音型発話名(RSN_(VM))音声ファイルを要求するRSN_(VM)要求クエリを送信する」とは、いずれも「外部ボイスメール・システムに、前記外部ボイスメール・システムに保存された発話名音声ファイルを要求する要求クエリを送信する」という点で一致する。
ニ.引用発明の「VMS1」と本願発明の「アプリケーション・サーバ」は、いずれもユーザからの要求を受信し、そして、ユーザへ「発話名音声ファイル」を送信するものであるから、「要求の受信とデータの送信をする手段」という点で一致する。
ホ.引用発明の「発話名データを含む第2の応答」と本願発明の「RSN_(VM)音声ファイルを収納したRSN_(VM)応答」とは、いずれも「音声ファイルを収納した応答」という点で一致するので、引用発明の「発話名データを含む第1の応答を受信する」と本願発明の「RSN_(VM)音声ファイルを収納したRSN_(VM)応答を受信する」とは、いずれも「音声ファイルを収納した応答を受信する」という点で一致する。
ヘ.引用発明の「ネットワークに接続された端末」、「送信者」は、本願発明の「ネットワーク・アクセス端末」、「ユーザ」にそれぞれ相当し、引用発明の「ネットワークに接続された端末により音声として提供する前記発話名データ」と本願発明の「ネットワーク・アクセス端末による再生用に前記人物の発話名の発音の音声版を提供する前記RSN_(VM)音声ファイル」とは、いずれも「ネットワーク・アクセス端末による再生用に前記人物の発話名の発音の音声版を提供する前記音声ファイル」という点で差異はない。
よって、引用発明の「ネットワークに接続された端末の送信者に、前記ネットワークに接続された端末により音声として提供する前記発話名データを送信する」と本願発明の「ハイパーテキスト転送プロトコル(hｔｔｐ)インターフェースを介して、ネットワーク・アクセス端末の前記ユーザに、前記ネットワーク・アクセス端末による再生用に前記人物の発話名の発音の音声版を提供する前記RSN_(VM)音声ファイルを送信する」とは、いずれも「ネットワーク・アクセス端末の前記ユーザに、前記ネットワーク・アクセス端末による再生用に前記人物の発話名の発音の音声版を提供する前記音声ファイルを送信する」という点で一致する。
したがって、本願発明と引用発明は、以下の点で一致ないし相違する。

＜一致点＞
「発話名の発音の音声版を提供する方法であって、
要求の受信とデータの送信をする手段が、ユーザ要求を受信するステップと、
外部ボイスメール・システムに、前記外部ボイスメール・システムに保存された発話名音声ファイルを要求する要求クエリを送信するステップとを含み、さらに、
前記外部ボイスメール・システムから、前記音声ファイルを収納した応答を受信するステップと、
前記要求の受信とデータの送信をする手段が、ネットワーク・アクセス端末の前記ユーザに、前記ネットワーク・アクセス端末による再生用に前記人物の発話名の発音の音声版を提供する前記音声ファイルを送信するステップとを含む方法。」

＜相違点＞
A.上記「発話名」に関して、本願発明は、「録音型発話名」であるのに対し、引用発明は、当該「録音型」か否か不明である点。
B.上記「要求の受信とデータの送信をする手段」に関し、本願発明は、「アプリケーション・サーバ」であるのに対し、引用発明は、「VMS(ボイスメールシステム)1」である点。
C.上記「ユーザ要求」に関し、本願発明は、「人物の発話名の音声を要求するユーザ要求」であるのに対し、引用発明は、「送信者からのメッセージの送信等のための要求」である点。
D.上記「発話名音声ファイル」及び「要求クエリ」に関し、本願発明は、「録音型発話名(RSN_(VM))音声ファイル」及び「RSN_(VM)要求クエリ」であり、該「録音型発話名(RSN_(VM))音声ファイル」が、「人物が当人の名前を発話した録音型音声コンテンツを含」むのに対し、引用発明は、当該構成を明示していない点。
E.上記「要求クエリを送信するステップ」に関し、本願発明では、「アプリケーション・サーバ」が「要求クエリを送信する」のに対し、引用発明では、「VMS1」がRMDに第1のクエリを送信し、その後、RMDが「第2のクエリ(要求クエリ)を送信する」点。
F.上記「音声ファイルを収納した応答」に関し、本願発明は、「RSN_(VM)音声ファイルを収納したRSN_(VM)応答」であるのに対し、引用発明は、当該構成を明示していない点。
G.上記「外部ボイスメール・システムから」、「応答を受信するステップ」に関し、本願発明では、「アプリケーション・サーバ」が「応答を受信する」のに対し、引用発明では、RMDが、「VMS2(外部ボイスメール・システム)」から、発話名データを含む第2の応答を受信し、その後、「VMS1」が、RMDから、「第1の応答(応答)を受信する」点。
H.上記「要求の受信とデータの送信をする手段」が、「ユーザ要求を受信」又は「音声ファイルを送信」することに関し、本願発明では、「ハイパーテキスト転送プロトコル(hｔｔｐ)インターフェースを介して」、受信又は送信するのに対し、引用発明では、当該構成を明示していない点。
I.上記「音声ファイルを送信する」に関して、本願発明は、「RSN_(VM)音声ファイルを送信する」のに対し、引用発明は、当該構成を明示していない点。

4.検討
上記相違点B.E.及びG.について検討する。
本願発明の「アプリケーション・サーバ」は、本願明細書【0013】?【0016】及び図1を参酌すると、ボイスメールシステムとは別のサーバとして設けられていることが明らかであるから、引用発明の「VMS1」とは異なる構成である。
そして、本願発明では、該「アプリケーション・サーバ」を有することにより、電話をかける、またはボイスメール・メッセージを残す、または残そうとするなど、通話を伴う従来の方法でボイスメール・システムに関わることなく、人物の名前の発音を1つまたは複数のボイスメールシステムから得られる(本願明細書【0013】)という効果を奏するものである。
よって、上記相違点B.E.及びG.に係る本願発明の構成は、上記引用発明及び技術事項とは異なるものであって、また、同引用発明及び技術事項から当業者が容易になし得たものということもできない。
したがって、他の相違点について検討するまでもなく、本願発明は、上記引用例1に記載された発明及び同引用例2に記載された技術事項に基づいて、当業者が容易に発明することができたものとすることはできない。

そして、本願の請求項1に係る発明と同様の発明特定事項を有する同請求項6に係る発明、及び、同請求項1を引用し、さらに限定を付加する請求項2?5に係る発明、並びに、同請求項6を引用し、さらに限定を付加する請求項7?10に係る発明についても、上記と同様の理由により、上記引用例1に記載された発明及び同引用例2に記載された技術事項に基づいて、当業者が容易に発明することができたものとすることはできない。

5.むすび
以上のとおり、本願の請求項1?10に係る発明は、上記引用例1に記載された発明及び同引用例2に記載された技術事項に基づいて、当業者が容易に発明をすることができたものとすることはできないから、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2014-03-26 
出願番号 特願2010-544402(P2010-544402)
審決分類 P 1 8・ 121- WY (H04M)
最終処分 成立  
前審関与審査官 吉村 伊佐雄  
特許庁審判長 田中 庸介
特許庁審判官 山本 章裕
矢島 伸一
発明の名称 発話名の発音の音声版を提供するシステムおよび方法  
代理人 岡部 讓  
代理人 吉澤 弘司  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ