JP5059004B2 - 電話呼をｓｉｐ等のコンピュータ・プロトコルに基づくダイアログと関連付ける方法およびコンピュータ可読記録媒体 - Google Patents

Description

本発明は、電話呼をコンピュータ・プロトコルに基づくダイアログと関連付ける方法およびシステムに関する。

公衆交換電話網（ＰＳＴＮ：Public Switched Telephone Network）では、シグナリング（signaling）を頻繁に使用して、回線やセッション等を設定したり終了したりする場合もある。例えば、ＰＳＴＮ用の１つのシグナリング・プロトコルは共通線信号方式７（common channel Signaling System 7、ＳＳ７）と呼ばれる。ＰＳＴＮでは、現存のシグナリング・プロトコルは、基本的な呼設定や呼終了、課金、無線サービスおよびローミング、ローカル番号ポータビリティ、無料電話サービス、発呼者ＩＤ、３者電話、呼転送高度機能、等をサポートすることができる。しかしながら、これら現存のシグナリング・プロトコルは限られたサポートしか提供できない。例えば、発呼者ＩＤについては、発呼者ＩＤ情報が端から端まで行き着くかは保証の限りではない。電話呼が構内交換機（ＰＢＸ：Private Branch Exchange）の内線等から発呼された場合、発呼者ＩＤがユーザについて一意でないという別の問題もある。例えば、アクメ社の従業員が電話をかけた場合、識別できるのはその従業員ではなく「アクメ」である。

ＰＳＴＮのシグナリング・プロトコルとは異なり、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）は決められたシグナリング・フェーズ中の通信に限定されない。ＳＩＰは、コンピュータシステムが相互に発見し合い、マルチメディアセッションを確立し、変更し、終了するためのアプリケーション層の制御プロトコルである。例えば、ＳＩＰは、ＶｏＩＰ（Voice Over Internet Protocol）技術の実現に使用される主要なプロトコルの１つである。ＶｏＩＰ技術の実現は、通常、ＰＳＴＮの従来型回線向きプロトコルではなく、音声情報のデジタル形式への変換とそれの離散的パケットでの送信を含む。ＳＩＰはまた、インスタントメッセージ伝達やその他の「リアルタイム」通信技術などの機能の実現に使用される。例えば、インスタントメッセージ伝達サービスは、会話において、参加者がメッセージを送信すると、１、２秒の内に他の参加者がそれを受信できるようにする。受信した参加者はそこで相手の参加者に同じ様にして回答メッセージを送信できる。

ＳＩＰはインターネット向けに提案された標準規格である。その仕様「ＲＦＣ３２６１」は＜http://www.ietf.org/rfc/rfc3261.txt＞で入手可能である（非特許文献１参照）。イベント通知に関するＳＩＰ拡張版の仕様「ＲＦＣ３２６５」は＜http://www.ietf.org/rfc/rfc3265.txt＞で入手可能である（非特許文献２参照）。ＳＩＰネットワークは、クライアント、サーバ、またはその両方としてダイアログに参加可能なエンティティを含む。ＳＩＰは４つのタイプのエンティティ、すなわち、ユーザエージェント、プロキシサーバ、リダイレクトサーバ、およびレジストラ（registrar）を備える。ユーザエージェントは他のＳＩＰエンティティとメッセージを交換することによりセッションを開始したり終了したりする。ユーザエージェントは、ＳＩＰリクエストを開始する装置であるユーザエージェントクライアント（「ＵＡＣ」、User Agent Client）、またはＳＩＰリクエストを受信してそのようなリクエストに応える装置であるユーザエージェントサーバ（「ＵＡＳ」、User Agent Server）であってよい。一例として、「ＩＰ電話」、携帯情報端末（ＰＤＡ）、およびその他任意のタイプのコンピュータ装置がユーザエージェントであってよい。装置は、あるダイアログではＵＡＣであり、別のダイアログではＵＡＳであることができ、ダイアログ中に役割を変更してもよい。プロキシサーバは、クライアントに対してはサーバ、サーバに対してはクライアントとして動作するエンティティである。そうすることにより、プロキシサーバはＵＡＣとＵＡＳとの間のメッセージを傍受、通訳、または転送する。リダイレクトサーバはＳＩＰリクエストを受け付け、リクエストを送信したＵＡＣへのレスポンス（response）を生成して、別のネットワークリソースに連絡するよう命令する。レジストラは、登録情報をユーザエージェントから受け付け、受信した登録情報をロケーション・サービスに知らせるサーバである。

ＳＩＰは２つのメッセージ・タイプをサポートする。すなわち、ＵＡＣからＵＡＳへ送信されるリクエスト（request）と、リクエストに応える際にＵＡＳからＵＡＣに送信されるレスポンス（response）である。ＳＩＰメッセージは３つの部分で構成される。ＳＩＰメッセージの第１の部分は、「リクエスト行」であり、これは、メッセージのメソッド（例えば、ＩＮＶＩＴＥ）と要求対象であるユーザまたはサービスを特定するＲｅｑｕｅｓｔ ＵＲＩを示すフィールドを含む。ＳＩＰメッセージの第２の部分は、名前−値の対としてその値が表現されるヘッダで構成される。ＳＩＰメッセージの第３の部分はメッセージ本体であり、これは開始するセッションの記述またはセッションに関するデータの収容に使用される。メッセージ本体はリクエストまたはレスポンスに出現してもよい。

IETF RFC3261 SIP: Session Initiation Protocol（規格）<http://www.ietf.org/rfc/rfc3261.txt> IETF RFC3265 Session Initiation Protocol （SIP）-Specific Event Notification（規格） <http://www.ietf.org/rfc/rfc3265.txt> ECMA-269, Services for Computer Supported Telecommunication Applications （CSTA） Phase III（規格）

電話呼をセッション開始プロトコル（ＳＩＰ）等のコンピュータ・ダイアログと関連付ける方法およびシステムが提供される。

ダイアログが、電話呼に関する情報をコンピュータ装置に備えることを可能にする場合もある。パーティＡがパーティＢに電話をかけたいとする。パーティＡとパーティＢの両方ともコンピュータ装置と電話機を持っている。彼らのコンピュータ装置間のメッセージ伝達を使用して、パーティＡはパーティＢとの電話を始めるリクエストを送信する。このリクエストがパーティＢのコンピュータ装置に受け入れられると、コンピュータ・ダイアログ（例えば、ＳＩＰの招待（invite）トラザクションのダイアログ）のシグナリング・フェーズが確立され、公衆交換電話網（ＰＳＴＮ）を介して電話を開始する試みがなされる。電話呼が成功裡に確立された旨の確認を受信すると、構成が適切であるとして、パーティＡのコンピュータ装置とパーティＢのコンピュータ装置は通話フェーズのコンピュータ・ダイアログ（例えば、ＳＩＰダイアログ）を始める。（シグナリング・フェーズと通話フェーズの両方の）コンピュータ・ダイアログは、パーティＡとパーティＢの識別、電話呼の状態、電話呼に関連する装置の状態、等に関するメッセージの送信に使用されてもよい。

幾つかのシステム・コンポーネントがダイアログの設定を可能にする場合もあり、これらは、パーティＡとパーティＢのコンピュータ装置で実行される通信アプリケーション、パーティＡとパーティＢのコンピュータ装置間のメッセージの授受を支援するライブ（live）通信サーバ、公衆交換電話網とコンピュータ装置間のインタフェース、公衆交換電話網のコンポーネント（ＰＢＸを含む場合もある）、等を含む場合もあり、含まない場合もある。

以上の「課題を解決するための手段」における説明は、以下の詳細な説明でさらに述べられる概念から選択して、簡明な形で紹介するべく供されたものである。以上の「課題を解決するための手段」における説明は、特許請求の主題事項の主要な特徴または本質的な特徴を特定することを意図するものではなく、また特許請求の主題事項の範囲を決定する際の補助として使用されることを意図するものでもない。

電話呼をコンピュータベースのダイアログと関連付ける設備（例えば、ソフトウェア設備および関連システム）が提供される。ある実施形態では、エンドツーエンドのＳＩＰダイアログは、公衆交換電話網（ＰＳＴＮ）等の「旧来型電話網」上で行われる電話呼と関連付けられて確立される。その設備はＰＳＴＮ呼の状態をＳＩＰダイアログの状態に同期させる。例えば、発呼側パーティが、ＳＩＰダイアログを使用して着呼側パーティに特定される場合もある。これは、電話呼が発呼者ＩＤ情報を含まない場合であっても、着呼側パーティが発呼側パーティを特定可能にする。加えて、ＳＩＰは、１つ以上のフィールドを使用して拡張され、ＰＳＴＮ状態のＳＩＰ状態との同期をサポートする。そのような拡張の例は、１つ以上の呼情報フィールド（例えば、ＳＩＰ ＩＮＶＩＴＥを介して送られる）、１つ以上の呼情報レスポンス・フィールド（例えば、ＳＩＰ ２００ ＯＫを介して送られる）および１つ以上の呼情報マッチ・フィールド（例えば、ＳＩＰ ＡＣＫを介して送られる）を含む。

ある実施形態では、ユーザ（発呼側）が、彼または彼女のコンピュータのコンタクト（連絡先）リスト中の誰か（着呼側パーティ）に電話をかけたいとき、彼または彼女はそのコンタクトを選択し、そのコンタクトへ電話をかけるよう指示する。その時、発呼側コンピュータ装置上のアプリケーションは、着呼側パーティのコンピュータ装置へリクエスト（例えば、ＳＩＰ ＩＮＶＩＴＥ）を送信し、シグナリング・フェーズのダイアログを開始する。そのリクエストは、電話機情報はコンタクトを使用してダイアログを確立する態様である旨の表示を含んでもよい。着呼側パーティはその時点で発呼側からの電話を期待できることを知る。着呼側パーティのコンピュータ装置が受け入れる旨を応え、またその電話機情報をサポートする旨を知らせると、発呼側コンピュータ装置は電話システムを通して電話をかけ、そして着呼側パーティの電話機で呼び出しを開始した旨を知らせる配達メッセージの取得を待つ。着呼側パーティが電話機の呼び出しを聞くと、着呼側パーティはその電話がその発呼側からであると予期できるが、ＳＩＰメッセージを送信した発呼側の呼が着呼する直前に別の発呼者から呼が着呼しない限り、実際にそうであろう。発呼側コンピュータ装置が、呼が応答され、またコンピュータによる交換が行われた旨の知らせを受信すると、発呼側コンピュータ装置はＰＳＴＮ電話呼が成功したことを知り、成功を知らせるコンピュータ・メッセージを送信する。着呼側パーティはその時点でその電話が予期どおりの発呼側からであることを知る。

呼が確認の受信を応答された後、通話フェーズのコンピュータ・ダイアログが確立される。その結果、発呼側コンピュータ装置と着呼側パーティのコンピュータ装置との間で情報の遣り取りが可能になる。この情報は、呼が保留された、逸れた、転送された、等の表示を含んでもよい。

図１は、ある実施形態における、設備のコンポーネントを示すブロック図である。設備が、１つ以上のクライアント１５０およびクライアント１７５にインターネット１３５を介して接続されるライブ通信サーバ１００を備える実施形態もある。ライブ通信サーバ１００はプレゼンス（presence）サーバ１０５を備えるが、これは、インスタントメッセージ伝達サービスの各ユーザに関する状態情報を保持するＳＩＰレジストラであってもよい。プレゼンスサーバ１０５は、サブスクリプション（subscription）コンポーネント１１５およびプレゼンス文書蓄積装置１２０を含んでもよい。サブスクリプション・コンポーネント１１５は、各ユーザについて、そのユーザのプレゼンス情報の通知を申し込んだユーザの最新リストを保持する。各ユーザの状態情報は、プレゼンス文書と呼ばれる文書形式で表現されてもよい。プレゼンス文書蓄積装置１２０は、ライブ通信サーバ１００上で、各ユーザについてユーザの最新状態を表示するプレゼンス文書を収容する。

ユーザ・データ・サーバ１１０は、各ユーザについての持続的データを保持し、コンタクトリスト蓄積装置１２５を備える。コンタクトリスト蓄積装置１２５は、各ユーザのコンタクトリストを収容する。ライブ通信サーバ１００が、ユーザが登録されたエンドポイントにそのユーザのコンタクトリストを提供する実施形態もある。そのようなエンドポイントの例には、クライアントＡ１５０およびクライアントＢ１７５が含まれ、それは両方とも人間のユーザに対応していてよい。クライアント１５０およびクライアント１７５が通信アプリケーション１５５を備える実施形態もある。通信アプリケーション１５５は、サブスクライブ（subscribe）コンポーネント１６０、登録（registration）コンポーネント１６５、およびユーザ・インタフェース・コンポーネント１７０を収容してもよい。サブスクライブ・コンポーネント１６０は、ユーザのコンタクトのプレゼンス情報の通知を申し込む。登録コンポーネント１６５は、ユーザのエンドポイントをライブ通信サーバ１００に登録し、ユーザのプレゼンス情報への更新について公表する。ユーザ・インタフェース・コンポーネント１７０は、ウインドウ、ビュー、および通信アプリケーション１５５との相互作用時にユーザに表示されるその他のグラフィック要素を提供する。

設備は、各クライアントに対応する電話機（１８０および１９０）の通信を通すＰＳＴＮ網１３０に対応してもよい。電話機１８０および電話機１９０はまた、各々、旧来型のＰＢＸ１８５およびＰＢＸ１９５に繋がっていてもよい。必要な場合、遠隔呼制御（Remote Call Control、ＲＣＣ）サーバ１９６がＰＢＸ（またはその他のＰＳＴＮコンポーネント）とクライアントのコンピュータ装置との間のインタフェースを提供してもよい。このようにして、クライアントのコンピュータ装置は、電話をされたＰＢＸで起こる活動を知らされる。例えば、遠隔呼制御サーバは、通信アプリケーションが使用する標準的なプロトコルをＰＢＸがサポートする特有のコンピュータ テレフォニー インテグレーション（ＣＴＩ：Computer Telephony Integration）用プロトコルへ変換するゲートウェイの役を果たしてもよい。図示されていないが、１つ以上のゲートウェイ・コンポーネントがＰＳＴＮ１３０を介する通信を容易化する場合もある。例えば、ＳＩＰ−ＰＳＴＮゲートウェイが、コンピュータ装置と電話機との間の呼を容易化するために備えられてもよい。

設備を実装するコンピュータ装置は、中央制御装置、記憶装置、入力装置（例えば、キーボードおよびポインティングデバイス）、出力装置（例えば、表示装置）、および蓄積装置（例えば、ディスク駆動装置）を備えてもよい。記憶装置および蓄積装置は、システムを実現する命令を収容できるコンピュータ可読型媒体である。加えて、データ構造およびメッセージ構造を、通信回線上の信号等のデータ伝送媒体を介して蓄積したりまたは伝送したりしてもよい。多様な通信回線、つまり、インターネット、ＬＡＮ、ＷＡＮ、ポイントツーポイントのダイアルアップ接続、携帯電話網等、を使用してもよい。

設備の実施形態は多様な動作環境で実現されてもよく、それは、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドコンピュータまたはラップトップ装置、多重プロセッサシステム、マイクロプロセッサ・ベースのシステム、プログラム可能な情報家電装置、デジタルカメラ、ネットワークパソコン、ミニコンピュータ、大型コンピュータ、以上のシステムまたは装置の任意のものを含む分散型コンピューティング環境、等を含む。コンピュータシステムは、携帯電話機、携帯情報端末、スマートホン、パーソナルコンピュータ、プログラム可能な情報家電、デジタルカメラ、等であってもよい。

システムは、１つ以上のコンピュータまたはその他の装置により実行されるプログラムモジュールなどの、コンピュータ実行可能な命令の観点から一般的に述べられてもよい。一般に、プログラムモジュールは、特定のタスクを実行または特定の抽象データ型を実現する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。一般にプログラムモジュールの機能は、多様な実施形態での所望に応じて、結合したり分解したりしてもよい。

図２は、（図１のクライアントＡ１５０およびクライアントＢ１７５、等の）２つのクライアント間のＳＩＰダイアログ確立プロセス２００における通信（例えば、メソッドおよびレスポンスを含むメッセージ）のフローを示すネットワーク図であり、ここで、クライアントＡがクライアントＢにＰＳＴＮを介して電話をかけている。図２の通信の流れは、（電話しようとする第３者が引き起こすような）競合状態が存在しない場合に生起する。図示の実施形態では、ＰＳＴＮのシグナリング（点線の矢印で示す）は、（ＰＢＸ等の交換システムを監視および制御するコンピュータ・アプリケーションによって使用される）ＣＳＴＡ ＥＣＭＡ−２６９呼制御抽象化（call control abstraction）（非特許文献３参照）を介して行われる。ある実施形態では、そのようなシグナリングがそれぞれのＰＢＸで実装され、遠隔呼制御サーバと協同する場合もある。クライアントからクライアントへ伝わるよう描かれているが、図２に描かれたＳＩＰメッセージ（すなわち、実線で示されたもの）は、そうではなく、図１のライブ通信サーバ１００などの共用サーバを経由して通信されてもよい。時間は図を下方へと進むので、図の上部のメッセージは下部のメッセージより送信時期が早い。

プロセスは、標準的なＳＩＰ招待ヘッダおよび呼情報ヘッダを有するＳＩＰ ＩＮＶＩＴＥ ２０５をクライアントＡが送信するところで始まる。このメッセージ２０５中のフィールドは、発呼側電話機のＵＲＩ（Uniform Resource Identifier）、着呼側電話機のＵＲＩ、オプショナルな発呼者ＩＤ（会社名、等）、呼のタイプ（例えば、レギュラ、コンサルタント、コンファレンス、等）、等を含んでもよい。クライアントＡとクライアントＢとの間でＳＩＰを介する接続が可能なものとすると、応答として、クライアントＢは、“ｓｕｐｐｏｒｔｅｄ ｔｅｌｅｐｈｏｎｅ“ヘッダを含むＳＩＰ １８３（ｉｎ ｐｒｏｇｒｅｓｓ）レスポンス２１０を送信する。これはシグナリング・フェーズのＳＩＰダイアログの開始を意味する。この時点で、クライアントＢはクライアントＡからの呼の受信を予期できる。クライアントＡがＳＩＰを介してクライアントＢと通信できない場合（例えば、利用可能なアドレスがない、連携がない、等）、クライアントＡはＳＩＰ １８３（ｉｎ ｐｒｏｇｒｅｓｓ）レスポンスを受信する代わりに、（誤りを示す）４ｘｘレスポンス・コードを受信する。

次の５つの通信（２１５、２２０、２２５、２３０、および２３５）は、シグナリングがＰＳＴＮに関して行われることを意味する。遠隔呼制御サーバが使用される場合、これらの通信は遠隔呼制御サーバとそれぞれのクライアントとの間で授受されてもよい。あるいは、それらはＰＢＸとそれぞれのクライアントとの間で直接に授受されてもよい。図示の実施形態では、これらの通信の最初はＭＡＫＥ ＣＡＬＬサービス・リクエスト信号２１５である。この信号は、発呼側装置に接続ＩＤを割当てることに対応してもよい。クライアントＡは、ＭＡＫＥ ＣＡＬＬレスポンス信号２２０を、次にＯｒｉｇｉｎａｔｅｄ信号２２５を受信する。クライアントＢが受信するＤｅｌｉｖｅｒｅｄ信号２３０（クライアントＢのＰＢＸまたはＲＣＣから受信する）は、クライアントＢの電話機の呼び出し中（ringing）に対応する。クライアントＡもまた、呼び出し中イベントを意味するＤｅｌｉｖｅｒｅｄ信号２３５を受信する。

クライアントＡとクライアントＢの両方がＤｅｌｉｖｅｒｅｄ信号を受信した後、クライアントＢはＳＩＰ １８０ （ｒｉｎｇｉｎｇ）レスポンス２４０を送信する。このレスポンスは、ｓｕｐｐｏｒｔｅｄ ｔｅｌｅｐｈｏｎｅヘッダを含んでもよい。同様に、クライアントＢがＳＩＰ １８０ （ｒｉｎｇｉｎｇ）レスポンスをクライアントＡに送信する前に、クライアントＡがＳＩＰ １８０ （ｒｉｎｇｉｎｇ）レスポンスを、誰が発呼しているかがクライアントＢにわかるよう識別情報を含めて、クライアントＢに送信してもよい実施形態もある。

クライアントＢに対応するユーザが呼び出し中の電話機に実際に応えると、クライアントＢはＳＩＰ ２００ ＯＫレスポンス２４５を送信する。ｓｕｐｐｏｒｔｅｄ ｔｅｌｅｐｈｏｎｅヘッダに加えて、このレスポンス２４５中のフィールドは、発呼側電話機のＵＲＩ、着呼側電話機のＵＲＩ、および状態フィールドを含んでもよい。

呼び出し中の電話機に応えることにより、クライアントＢに対応するユーザは次のＰＳＴＮシグナリングを開始する。例えば、クライアントＢとクライアントＡの両方ともが、それぞれのＰＢＸ／ＲＣＣからＥｓｔａｂｌｉｓｈｅｄ信号（それぞれ、２５０および２５５）を受信してもよい。このシグナリングの結果、クライアントＡはＳＩＰ ＡＣＫ ２６０を送信する。ＳＩＰ ＡＣＫ ２６０は、ＩＮＶＩＴＥトランザクションの終了およびシグナリング・フェーズのダイアログ終了を意味する。ヘッダ情報に加えて、このＡＣＫはマッチフラグに関する情報を含んでもよい。これは、クライアントＢがその呼をＳＩＰ ＵＲＩおよび会話ウインドウに対応付けることを可能にし、それによりＳＩＰ通話フェーズのダイアログを確立できるようにする。

図３は、（図１のクライアントＡ１５０およびクライアントＢ１７５、等の）２つのクライアント間のＳＩＰダイアログ確立プロセス３００における通信（例えば、メソッドおよびレスポンスを含むメッセージ）のフローを示すネットワーク図であり、ここで、クライアントＡがクライアントＢにＰＳＴＮを介して電話をかけている。図３の通信のフローは競合状態が存在する場合に生起する。より具体的には、第３の発呼者ＣがクライアントＢに対応する電話機に、クライアントＡがクライアントＢに電話をかけようとしている同じ時に、電話をかけようとしている。図２に関するのと同様に、図３に示す実施形態では、ＰＳＴＮのシグナリング（点線の矢印で示す）は、ＥＣＭＡ−２６９呼制御抽象化を介して行われる。そのようなシグナリングがそれぞれのＰＢＸで実装され、遠隔呼制御サーバと協同する場合もある実施形態もある。クライアントからクライアントへ伝わるよう描かれているが、図３に描かれたＳＩＰメッセージ（すなわち、実線で示されたもの）は、そうではなく、図１のライブ通信サーバなどの共用サーバを経由して通信されてもよい。

プロセスは、標準的なＳＩＰ招待ヘッダおよび呼情報ヘッダを有するＳＩＰ ＩＮＶＩＴＥ ３０５をクライアントＡが送信するところで始まり、こうしてＳＩＰシグナリング・ダイアログを開始する。それに応えて、クライアントＢは“ｓｕｐｐｏｒｔｅｄ ｔｅｌｅｐｈｏｎｅ”ヘッダを含むＳＩＰ １８３（ｉｎ ｐｒｏｇｒｅｓｓ）レスポンス３１０を送信する。次の３つの通信（３１５、３２０、および３２５）において、クライアントＡはＰＳＴＮ呼の設定を試みてＰＢＸ／ＲＣＣとシグナリング通信を行う。しかし、これが行われる前に、発呼者ＣがクライアントＢの電話機に電話をかけてしまった。その結果、ＭＡＫＥ Ｃａｌｌサービス・リクエスト信号３１５、ＭＡＫＥ Ｃａｌｌレスポンス信号３２０、およびＯｒｉｇｉｎａｔｅｄ信号３２５は正常に行われたものの、クライアントＢの電話機へ発呼者Ｃの呼が届いた（信号３３０）直後、クライアントＡはＦａｉｌｅｄ信号３３５を受信する。この時点では、クライアントＢは呼び出し中の電話はクライアントＡからであると予期している。そこでクライアントＢは、それがクライアントＡからではないとは殆ど用心せずに電話に応えることができよう。それに応えて、クライアントＡはＳＩＰ Ｃａｎｃｅｌ ３４０をクライアントＢに送出する。この時点で、クライアントＢはその呼がクライアントＡからではないことを知る。これは、ＳＩＰ通話フェーズのダイアログ確立のプロセスを終了させる。その間に、クライアントＢに対応するユーザは発呼者Ｃからの電話呼に応え、発呼者Ｃの呼に関してＰＢＸ／ＲＣＣからＥｓｔａｂｌｉｓｈｅｄ信号３４５を受信する。

図４は、ある実施形態における、第１のＳＩＰクライアント（発呼側）から第２のＳＩＰクライアント（着呼側）へライブ通信サーバを介して送信されるＩＮＶＩＴＥメッセージ４００の内容を示す。ＩＮＶＩＴＥメッセージ４００は、ＩＰヘッダ４０５、ＴＣＰヘッダ４１０、およびＳＩＰメッセージ４１２を含む。ＴＣＰ／ＩＰ以外のプロトコルが下位の転送に使用されてもよい。ＳＩＰメッセージ４１２は、ＳＵＢＳＣＲＩＢＥメソッドのリクエスト行４１５、Ｆｒｏｍヘッダ４２０、Ｔｏヘッダ４２５、Ｃａｌｌｅｒ Ｔｅｌ ＵＲＩヘッダ４３０、Ｃａｌｌｅｄ Ｔｅｌ ＵＲＩヘッダ４３５、Ｓｕｐｐｌｅｍｅｎｔａｌ Ｃａｌｌｅｒ ＩＤヘッダ４４０、Ｃａｌｌ Ｔｙｐｅヘッダ４４５、Ｓｕｐｐｏｒｔｅｄヘッダ４５０、およびＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ４５５を含む。Ｆｒｏｍヘッダ４２０は送信クライアントのコンピュータ装置（発呼者）を特定する。Ｔｏヘッダ４２５はこのパケットの送信者がどのエンドポイントに通知を申し込むか（着呼側パーティ）を指定する。Ｃａｌｌｅｒ Ｔｅｌ ＵＲＩヘッダ４３０は発呼側の電話機を指定し、Ｃａｌｌｅｄ Ｔｅｌ ＵＲＩヘッダ４３５は着呼側の電話機を指定する。Ｓｕｐｐｌｅｍｅｎｔａｌ Ｃａｌｌｅｒ ＩＤヘッダ４４０は代替の発呼者ＩＤ（例えば、発呼者が所属する会社のＩＤ）を提示するものであり、オプションである。Ｃａｌｌ Ｔｙｐｅヘッダ４４５は呼のタイプを指定し、これは例えば、レギュラ呼、コンファレンス呼、コンサルタント呼、等であってよい。Ｓｕｐｐｏｒｔｅｄヘッダ４５０は発呼者がサポートする任意の特有の動作を指定する。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ４５５はそのＳＩＰメッセージ・ヘッダの後にはデータがないことを示す値０を有する。しかしながら、ヘッダに含まれるデータのあるもの（例えば、Ｃａｌｌｅｒ Ｔｅｌ ＵＲＩ、Ｓｕｐｐｌｅｍｅｎｔａｌ Ｃａｌｌｅｒ ＩＤ、等）が、上記とは異なって、メッセージ・データ中で提示される別の実装もあってよい。

図５は、ある実施形態における、着呼側が（ライブ通信サーバを介して）ＳＩＰクライアントへ送信するＩＮＶＩＴＥレスポンス５００の内容を示す。ＩＮＶＩＴＥメッセージ５００は、ＩＰヘッダ５０５、ＴＣＰヘッダ５１０、およびＳＩＰメッセージ５１５を含む。ＴＣＰ／ＩＰ以外のプロトコルが下位の転送に使用されてもよい。ＳＩＰメッセージ５１５は、ＳＩＰレスポンス識別子５２０、Ｔｏヘッダ５２５、Ｆｒｏｍヘッダ５３０、Ｃａｌｌｅｒ Ｔｅｌ ＵＲＩヘッダ５３１、Ｃａｌｌｅｄ Ｔｅｌ ＵＲＩヘッダ５３２、Ｓｔａｔｕｓヘッダ５３３、ＣＳｅｑヘッダ５３５、Ｓｕｐｐｏｒｔｅｄヘッダ５４０、およびＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ５４５を含む。ＳＩＰレスポンス識別子５２０は、ＳＩＰバージョン２．０および通知の申し込みが成功したことを示すリクエスト状態（例えば、２０２ Ａｃｃｅｐｔｅｄ）を指定する。Ｔｏヘッダ５２５は、リクエストの元々の送信者が通知を申し込んだエンドポイントを指定する。Ｆｒｏｍヘッダ５３０は、リクエストの元々の送信者を指定する。Ｃａｌｌｅｒ Ｔｅｌ ＵＲＩヘッダ５３１は、発呼側の電話機を指定し、Ｃａｌｌｅｄ Ｔｅｌ ＵＲＩヘッダ５３２は着呼側の電話機を指定する。Ｓｔａｔｕｓヘッダ５３３は着呼側の電話システムの状態を指定する。ＣＳｅｑヘッダ５３５は、ライブ通信サーバからのリクエストおよびレスポンスの全メッセージに含まれ、そのサーバからのメッセージの相対順序を決める順序番号として使用される。各ＳＩＰダイアログに対して異なる順序番号が生成され、その順序番号は一般にそのダイアログを作ったリクエストのタイプを指定する。例えば、ＣＳｅｑヘッダ５３５は、これが、ＴｏヘッダとＦｒｏｍヘッダが指定するエンドポイント間のＩＮＶＩＴＥリクエストによって作られたダイアログ中の、当該サーバからの第１のメッセージであることを示す値１ ＩＮＶＩＴＥを有する。順序番号が小さいメッセージは、順序番号が大きいメッセージよりサーバから早期に送信されたものである。Ｓｕｐｐｏｒｔｅｄヘッダ５４０は、送信者がサポートする任意の特有の動作を指定する。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ５４５はそのＳＩＰメッセージ・ヘッダの後には０バイトのデータが続くことを示す値０を有する。しかしながら、ヘッダに含まれるデータのあるもの（例えば、Ｃａｌｌｅｒ Ｔｅｌ ＵＲＩ、Ｃａｌｌｅｄ Ｔｅｌ ＵＲＩ、マッチフラグ、等）が、上記とは異なって、メッセージ・データ中で提示される別の実装もあってよい。

図６は、発呼側パーティのクライアント・コンピュータ装置における、電話呼と関連付けられたＳＩＰダイアログを確立するためのルーチン６００を示すフロー図である。ルーチン６００は、発呼側パーティが、彼または彼女のクライアント・コンピュータ装置において、通信アプリケーションを使用して電話をかけようとするときに呼び出される。ブロック６０５で、ルーチン６００はＳＩＰ ＩＮＶＩＴＥメッセージを作成して送信し、それが、例えば、ライブ通信サーバへ送信され、着呼側パーティのクライアント・コンピュータ装置との接続を確立する。このシナリオは、着呼側パーティのクライアント・コンピュータ装置がＳＩＰ通信向きに構成されていることを前提としている。そうでない場合、その呼の電話呼態様はさらに続くかもしれないが、ＳＩＰダイアログが確立することはない。

ブロック６１０で、ＳＩＰシグナリング・フェーズのダイアログが確立して、ルーチンはサーバからＳＩＰ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ（１８３）レスポンスを受信する。ブロック６１５で、発呼側パーティのクライアント・コンピュータ装置は１つ以上のＰＳＴＮ信号を送受信するが、それらは、Ｍａｋｅ Ｃａｌｌ信号、Ｍａｋｅ Ｃａｌｌレスポンス信号、Ｏｒｉｇｉｎａｔｅｄレスポンス信号、Ｄｅｌｉｖｅｒｅｄレスポンス信号、等を含んでもよい。以上で論じたように、これらの信号は、クライアントとＰＢＸとの間で直接または遠隔呼制御（ＲＣＣ）インタフェースを介して通信されてもよい。判断ブロック６２０で、ブロック６１５における信号がＦａｉｌｅｄレスポンス信号を含む場合、これはＰＳＴＮの呼処理が失敗したことを示すものであり、ルーチンはブロック６２５へと続き、ＳＩＰＣａｎｃｅｌメッセージを送信する。これによりＳＩＰダイアログを確立しようという試みはそれ以上は終わりになろう。（あるいは、ＳＩＰダイアログを継続して、呼が試みられたという事実のログ記録を、着呼側パーティのクライアント・コンピュータ装置で取ることになる。）
しかしながら、判断ブロック６２０で、ブロック６１５における信号がＦａｉｌｅｄレスポンス信号を含まない場合、ルーチン６００はブロック６３０へと続き、そこでＳＩＰ呼び出し中（１８０）レスポンスを受信する。着呼側パーティが呼に応えた後、ブロック６３５で、ルーチン６００は、トランザクションが成功したことを示すＳＩＰ ＯＫ （２００）レスポンスを受信する。具体的には示されていないが、着呼側パーティが応えない場合、ルーチン６００は（ブロック６３５へ進むことなく）最終的にＯＫレスポンスの待ち合わせが時間切れとなり、ルーチン６００を終了させてもよい。

ブロック６４０で、ルーチン６００はＰＳＴＮ Ｅｓｔａｂｌｉｓｈｅｄ信号をＰＢＸ／ＲＣＣから受信する。これに応えて、ルーチン６００は、ＳＩＰダイアログが確立したことを示すＳＩＰ ＡＣＫを送信する（ブロック６４５）。ＳＩＰダイアログはその後、呼の間中、場合によっては呼の後も、継続してよい。それを使ってメッセージ（例えば、発呼者ＩＤメッセージ、呼転送メッセージ、コールウェイティング・メッセージ、等）を送信してもよく、ＰＳＴＮシグナリングに頼らなくてもよい。

図７は、着呼側パーティのクライアント・コンピュータ装置における、電話呼と関連付けられたＳＩＰダイアログを確立するためのルーチン７００を示すフロー図である。ルーチン７００は、発呼側パーティが、彼または彼女のクライアント・コンピュータ装置において、通信アプリケーションを使用して電話をかけようとするときに呼び出される。ブロック７０５で、ルーチン７００はＳＩＰ ＩＮＶＩＴＥメッセージを受信するが、それは、例えば、発呼側パーティのクライアントが着呼側パーティのクライアント・コンピュータ装置との接続を確立しようと試みた後、ライブ通信サーバから送信されたものである。このシナリオは、着呼側パーティのクライアント・コンピュータ装置がＳＩＰ通信向きに構成されていることを前提としている。そうでない場合、その呼の電話呼態様はさらに続くかもしれないが、ＳＩＰダイアログが確立することはない。

ブロック７１０で、ルーチン７００はＳＩＰ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ（１８３）レスポンスを作成してサーバから送信するが、これは、ＳＩＰシグナリング・フェーズのダイアログの開始を意味する。ブロック７１５で、ルーチン７００はＰＳＴＮ Ｄｅｌｉｖｅｒｅｄ信号を受信するが、これは、着呼側パーティにＰＳＴＮ上で電話がかけられたことを示す。この信号は、ルーチン７００とＰＢＸとの間で直接または遠隔呼制御（ＲＣＣ）インタフェースを介して通信されてよい。判断ブロック７２０で、ルーチンがＳＩＰ Ｃａｎｃｅｌを受信した場合、これは発呼側パーティのクライアントがＰＳＴＮ呼の設定の失敗を検知したことを示しており、それ以上のＳＩＰ通信は行われないであろう（ルーチン７００を終了させる）。しかしながら、判断ブロック７２０でＳＩＰ Ｃａｎｃｅｌメッセージを受信しない場合、ＳＩＰ通信はブロック７２５に続き、そこでルーチン７００はＳＩＰ呼び出し中（１８０）レスポンスを作成して送信する。

着呼側パーティが電話に応えた後、ブロック７３０で、ルーチン７００はＳＩＰ ＯＫ（２００）レスポンスを生成して送信するが、これはＳＩＰトランザクションの実行が成功したことを示す。具体的には示されていないが、着呼側パーティが応えない場合、ルーチン７００は（ブロック７３０へ進むことなく）最終的にＯＫレスポンスの待ち合わせが時間切れとなり、ルーチン７００を終了させてもよい。

ブロック７３５で、ルーチン７００はＰＳＴＮ Ｅｓｔａｂｌｉｓｈｅｄ信号をＰＢＸ／ＲＣＣから受信する。発呼側パーティのクライアントもまた同様の信号を受信することを前提に、ルーチン７００は、ＳＩＰ通話フェーズのダイアログが確立したことを示すＳＩＰ ＡＣＫを受信する（ブロック７４０）。確立したＳＩＰダイアログはその後、呼の間中、場合によっては呼の後も、継続してもよい。それを使ってメッセージ（例えば、発呼者ＩＤメッセージ、呼転送メッセージ、コールウェイティング・メッセージ、等）を送信してもよく、ＰＳＴＮシグナリングに頼らなくてもよい。

主題について構造的特徴および／または方法論的動作に特有の専門用語で説明がなされたが、当然のことながら、添付の特許請求の範囲で規定される主題は、以上で説明した特有の特徴または動作に必ずしも限定されるものではない。むしろ、以上で説明した特有の特徴または動作は、特許請求の範囲を実現する事例的形態として開示されたものである。したがって、本発明は添付の特許請求の範囲による以外に限定されるものではない。

ある実施形態における、電話呼をＳＩＰダイアログと関連付けるためのシステムのコンポーネントを示すブロック図である。 ある実施形態における、電話呼と関連付けられたＳＩＰダイアログを確立するための通信のフローを示すネットワーク図である。 競合状態が存在する場合の、電話呼と関連付けられたＳＩＰダイアログを確立するための通信のフローを示すネットワーク図である。 ある実施形態における、発呼側パーティのクライアントから送信されたＳＩＰ ＩＮＶＩＴＥメッセージの内容を示す図である。 ある実施形態における、着呼側パーティのクライアントから送信されたＳＩＰ ＩＮＶＩＴＥレスポンスメッセージの内容を示す図である。 ある実施形態における、発呼側コンピュータ装置での電話呼と関連付けられたＳＩＰダイアログを確立するルーチンを示すフロー図である。 ある実施形態における、着呼側パーティのコンピュータ装置での電話呼と関連付けられたＳＩＰダイアログを確立するルーチンを示すフロー図である。

Claims (12)

1. 発呼側のコンピュータ装置において、電話呼が前記発呼側からであることを着呼側のコンピュータ装置が判定できるように電話呼を発呼側と関連付ける方法であって、
   前記方法は、
   前記着呼側に電話をかけるためのインプットを前記発呼側から受信するステップであって、電話呼は公衆電話網を介して確立される、ステップと、
   前記公衆電話網に関して帯域外である帯域外通信メカニズムを介して、前記着呼側のコンピュータ装置に、着呼が前記発呼側からであることを前記着呼側が予測することができるように前記公衆電話網を介して前記発呼側が電話呼を前記着呼側と開始するというインジケーションを送信するステップと、
   前記発呼側が電話呼を前記着呼側と開始するというインジケーションを送信することに応答して、前記帯域外通信メカニズムを介して前記着呼側のコンピュータ装置から応答を受信するステップと、
   前記発呼側のコンピュータ装置において前記応答を受信した後、および前記電話呼が開始された後、
   開始された電話呼が前記公衆電話網によって報告されるように前記着呼側に届けられたというインジケーションを受信したら、前記着呼側のコンピュータ装置が前記電話呼が前記発呼側からであることを認識できるように前記届けられた電話呼が前記発呼側からであるというインジケーションを、前記帯域外通信メカニズムを介して前記発呼側のコンピュータ装置から前記着呼側のコンピュータ装置に送信するステップと、
   開始された電話呼が前記公衆電話網によって報告されるように前記着呼側に届けられなかったというインジケーションを受信したら、前記着呼側のコンピュータ装置が前記届けられた電話呼が前記発呼側からでないことを認識できるように前記電話呼が前記発呼側に届けられなかったというインジケーションを、前記帯域外通信メカニズムを介して前記発呼側のコンピュータ装置から前記着呼側のコンピュータ装置に送信するステップと
   を備えることを特徴とする方法。
2. 前記公衆電話網に関して帯域外である帯域外通信メカニズムは、ＳＩＰ（session initiation protocol）に基づくことを特徴とする請求項１に記載の方法。
3. 前記電話呼を前記着呼側と開始することは、ＳＩＰ ＩＮＶＩＴＥメッセージを送信することを含むことを特徴とする請求項１または２に記載の方法。
4. 前記電話呼を前記着呼側と開始することは、前記着呼側に関連付けられる識別子のインジケーションを提供するＳＩＰレスポンスを送信することを含むことを特徴とする請求項１または２に記載の方法。
5. 公衆電話網のコンポーネントに対して公衆電話網の信号を送受信するステップであって、当該信号は、前記公衆電話網を介して前記電話呼を確立することに関連する、ステップをさらに備えることを特徴とする請求項１乃至４のいずれかに記載の方法。
6. ＳＩＰ ＡＣＫを前記着呼側のコンピュータ装置から受信するステップであって、前記ＳＩＰ ＡＣＫは、ＳＩＰ ＩＮＶＩＴＥトランザクションの終了、および前記発呼側のコンピュータ装置と前記着呼側のコンピュータ装置の間のＳＩＰ通話フェーズダイアログの開始を表す、ステップをさらに備えることを特徴とする請求項１乃至５のいずれかに記載の方法。
7. 着呼側のコンピュータ装置において、公衆交換電話網で行われる発呼側から着呼側への電話呼に関連付けられる少なくとも１つのコンピュータ・ダイアログを提供する方法であって、
   前記方法は、
   ＳＩＰ ＩＮＶＩＴＥメッセージを受信するステップであって、前記ＳＩＰ ＩＮＶＩＴＥメッセージは、発呼側から着呼側への電話呼の開始と関連付けられ、前記ＳＩＰ ＩＮＶＩＴＥメッセージは、前記発呼側に関連付けられる発呼側のコンピュータ装置から送信される、ステップと、
   前記ＳＩＰ ＩＮＶＩＴＥメッセージを受信することに応答して、前記着呼側のコンピュータ装置が前記ＳＩＰ ＩＮＶＩＴＥメッセージを受信したことを示すＳＩＰレスポンスを前記発呼側のコンピュータ装置に送信するステップと、
   前記着呼側に届けられた電話呼が前記発呼側からであることを示すＳＩＰメッセージを前記発呼側のコンピュータ装置から受信するステップと、
   前記届けられた電話呼が前記発呼側からであることを前記着呼側に知らせるステップと
   を備えることを特徴とする方法。
8. 公衆交換電話網を介して電話呼を確立するステップは、
   前記発呼者のコンピュータ装置からＭａｋｅ Ｃａｌｌ信号を送信するステップであって、前記Ｍａｋｅ Ｃａｌｌ信号は、前記公衆交換電話網のコンポーネントによる受信を意図する、ステップと、
   前記発呼者のコンピュータ装置においてＭａｋｅ Ｃａｌｌ信号を受信するステップであって、前記Ｍａｋｅ Ｃａｌｌ信号は、前記公衆交換電話網の前記コンポーネントにおいて発信される、ステップと、
   前記発呼者のコンピュータ装置においてＯｒｉｇｉｎａｔｅｄ信号を受信するステップであって、前記Ｏｒｉｇｉｎａｔｅｄ信号は、前記公衆交換電話網の前記コンポーネントにおいて発信される、ステップと、
   前記発呼者のコンピュータ装置においてＤｅｌｉｖｅｒｅｄ信号を受信するステップであって、前記Ｄｅｌｉｖｅｒｅｄ信号は、前記公衆交換電話網の前記コンポーネントにおいて発信され、かつ第２の電話機が呼び出し中であることを示す、ステップと
   を含むことを特徴とする請求項７に記載の方法。
9. 前記公衆交換電話網の前記コンポーネントは構内電話交換機（ＰＢＸ）であることを特徴とする請求項８に記載の方法。
10. 前記公衆交換電話網の前記コンポーネントは構内電話交換機（ＰＢＸ）であり、
    前記Ｍａｋｅ Ｃａｌｌ信号、前記Ｏｒｉｇｉｎａｔｅｄ信号、および前記Ｄｅｌｉｖｅｒｅｄ信号は、遠隔コールセンタ・インタフェースから受信されることを特徴とする請求項８に記載の方法。
11. 前記ＳＩＰ ＩＮＶＩＴＥメッセージは通信サーバにおいて受信され、前記通信サーバが該ＳＩＰ ＩＮＶＩＴＥメッセージ前記着呼者のコンピュータ装置に渡すことを特徴とする請求項７乃至１０のいずれかに記載の方法。
12. 前記公衆交換電話網のコンポーネントから発信されるＦａｉｌｅｄ信号の受信によって示されるように前記電話呼が届けられなかった場合、ＳＩＰダイアログを開始するＣａｎｃｅｌ要求を送信するステップであって、前記Ｃａｎｃｅｌ要求はシグナリング・フェーズの間に送信される、ステップをさらに備えることを特徴とする請求項７乃至１１のいずれかに記載の方法。

Images