JP2007520920A - オペレータ、サービス、及び位置ポータビリティを持つ異種システム間の、リモートサービス転送（ｒｓｆ）のための方法 - Google Patents

Abstract

利用者が異なるシステムにアクセスする、又は異種の電話装置、又は異なるサービスプロバイダを使用する場合でさえも、リモートサービス転送（ＲＳＦ）システムは、電話サービス利用者が、サービスの損失又は変更なく、様々なアクセスデバイスを介して、加入サービスにアクセスすることを、可能にする。

Description

本発明は、デジタル電話に関するものである。特に、本発明は、モバイル交換センタ、ＩＰ電話、ホストＰＢＸ、及び企業のＰＨＳネットワークに関するものである。

（優先権主張）
本出願は、２００３年１２月５日に出願された米国仮特許出願第６０／５２７，３６１号に基づく優先権を主張するものであり、その明細書は、引用により本出願に組み入れられる。

リモート呼転送（ＲＣＦ）の１つの既知の解決策では、顧客が、その発呼者も知らない、新しい場所へ転送される電話番号に電話をかける。顧客の起点市内交換局は、明らかな終端市内交換局との信号メッセージを開始する間、その呼を待機させておく。信号メッセージが、ＣＣＳ７ネットワークを介して、最初の終端市内交換局に到着した時、スイッチが、顧客の回線をポーリングして、その状況（例えば、顧客の回線が、利用可能か、使用中か、又は転送されるかのいずれであるか）を特定する。回線が転送された場合には、ルックアップ表を調べて、その番号の新しい位置を特定し、新たな信号経路が確立される。新たな信号経路を確立するために、新しい明らかな終端市内交換局へ更なる信号メッセージが送られ、正しい終端顧客回線が特定されるまで、このプロセスを繰り返す。その回線が利用可能である場合には、スイッチは、呼の完成のために全てが準備完了であることを示すメッセージを、起点交換局に返す。次に、起点スイッチにより、呼が解放され、前に信号ネットワークに関して横断されたのと同じ経路に沿って、転送される。

リモート呼転送のこのオンスイッチ解決策での問題は、サービスの単一システムへの制限を含む。さらに、ポート番号を認識する前に、呼の経路（或いは、少なくとも信号経路）を完成させなければならない。これは、大量のポート番号が受け入れられなくなり得る、効率の悪い呼転送という結果になる。

オフスイッチとして知られる更なる解決策では、呼のセットアップ段階の早期に関与するスイッチは、ポート番号についての情報にアクセスすることが可能である。この解決策では、顧客が、新しい場所へポートされ得る、又はされ得ない電話番号に、電話をかける。サービス制御ポイント,ＳＳＰにおいて、ＩＮデータベースへのＣＣＳ７信号メッセージを開始する間、顧客の起点市内交換局（ＩＮアーキテクチャにおいて、サービス交換ポイント、又はＳＳＰとして知られる）は、呼を待機させる。信号メッセージがＳＣＰに到着した時、データベースを調べて、ダイヤルされた電話番号と関連付けられるネットワークアドレス、又は転送番号を特定する。ＳＣＰは、経路選択情報をＳＳＰに返す。次に、ＳＳＰが、終端交換局へ信号メッセージを送信して、呼ばれたパーティが利用可能であるかどうかを判断する。ＳＳＰによって呼が解放され、終端市内交換局までの最適経路全体にわたって、呼の経路が確立される。

そのようなオフスイッチ解決策では、地理的でないサービスの終端データベース解決策と均等な物は全く存在しない。さらに、それらは、１つのデバイス、アプリケーション、又は位置で複数のサービスプロバイダに加入しているユーザの、サービスをつなぐための方法も提供しない。

前の解決策はまた、その場限りのインターネット接続には存在しない、高品質の回路接続という前提条件の不利な点にも苦しむ。そのかわり、サービスの品質は、終点まで前提とされる。

本技術分野では、様々なＩＰ電話解決策が知られている。例えば、Ｗｈｉｔｅ他著,米国特許第６,０６９,８０９号は、インターネット上での電話型サービスを教示している。Ｗｈｉｔｅ他著,米国特許第６,０２１,１２６号は、電気通信番号ポータビリティのためにインターネットを使用すること、を教示している。Ｗｈｉｔｅ、及びＦｅｒｒｉｓ著,米国特許第６,０１４,３７９号は、インターネット上での電気通信カスタム着呼サービスを教示している。Ｋａｌｍａｎｅｋ他著,米国特許第６,３２４,２７９号は、ＩＰ電話通信のために、２つの異なるシステムをつなぐための信号送信を教示している。これらの開示の全ては、引用により、本出願に組み入れられる。しかしながら、これらの解決策は、１つのデバイス上で複数のサービスプロバイダに加入しているユーザのサービスをつなぐための方法を、提供しない。

（要約）
利用者が異なるシステムにアクセスする、又は異種の電話装置、又は異なるサービスプロバイダを使用する場合でさえも、リモートサービス転送（ＲＳＦ）システムは、電話サービス利用者が、サービスの損失又は変更なく、様々なアクセスデバイスを介して、加入サービスにアクセスすることを、可能にする。

リモートサービス転送システムの動作では、第１の送出サービスプロバイダが、電話番号への呼を受け取る。システムは、その呼を転送すべきかどうか判断して、そうである場合には、その電話番号と対応付けられるインターネットプロトコル（ＩＰ）アドレスを特定し、そのＩＰアドレスへ呼を転送する。

本システムは、複数の異種システムから単一のユーザデバイスまで、呼を転送することができる。結果として、本システムは、異なる送出サービスプロバイダにおいて、異なる電話番号への、第２の呼を受け取ることができる。それにもかかわらず、本システムは、同じユーザへのその呼の転送のために、同じＩＰアドレスを特定することができる。

本システムは、ユーザのＩＰデバイスへの呼の、送出サービスプロバイダから受入サービスプロバイダへの転送を可能にするだけではない。電話の発呼、及びボイスメールのようなサービスを含む、送出サービスプロバイダによって提供されるサービスに、ユーザがアクセスすることもまた可能にする。

（詳細な説明）
Ｉ. リモートサービス転送システムの概要
利用者が異なるシステムにアクセスする、或いは、異種の電話装置、又は異なるサービスプロバイダを使用する場合でさえも、リモートサービス転送（ＲＳＦ）システムは、電話サービス利用者が、サービスの損失又は変更なく、様々なアクセスデバイスを介して、加入サービスにアクセスすることを、可能にする。

一例は、ＰＢＸ、又はセントレックスサービス拡張である。利用者は、彼のデスクでは、彼の通常のハードウェア電話を使用することができる、仕事場を動き回る時には、Ｗｉ−Ｆｉ（又はＰＨＳ）イネーブル無線ＩＰ電話を使用することができる、或いは仕事場から離れる時には、（ＧＳＭ、ＣＤＭＤ、又はＰＨＳ電話のような）通常の携帯電話を使用することができる。ＲＳＦシステムは、ＰＢＸユーザに提供されるサービスを、ユーザが異種のデバイスを使用している時に、これらの異種のデバイスに配信することを可能にする。

更なる例としては、ユーザがホームサービスプロバイダの領域から離れる時、彼はまだ、どうにかして、ＩＰデバイスを用いてサービスにアクセスすることができる。ＩＰデバイスは、例えば、ＩＰ接続を有するパソコン（ＰＣ）上で実行されるアプリケーション、とすることができる。そのアプリケーションは、電話ボタンを持つ電話装置の接触部分をまねたグラフィックユーザインターフェースを含む。このアプリケーションは、（Ｃｏｍｃａｓｔのような）アクセスサービスプロバイダを介して、（Ｖｅｒｉｚｏｎのような）ホームサービスプロバイダに、ユーザを登録して、その登録が取り消されるまで、そのアプリケーションに通常の無線サービスを配信することを要求する。

そのシステムは、ＩＰアプリケーション又はＩＰデバイス内で、ばらばらのオペレータのオフィス電話、及び携帯電話によるサービスを、（集中メールボックスのような）単一の集中表示に、集中させる。そのシステムはまた、本出願で説明するように、携帯、又は企業内固定有線電話までのドロップバックを使用して、集中ＩＰアプリケーションが接続に失敗した時に利用されることができる。ライフラインサービスを、効果的にに回避させるのに充分満たす、或いは強化するような方法で、このドロップバックを実装する。

このシステムは、無線オペレータ又は企業内通信が、電話番号をポートし、呼をユーザ規定のＵＲＬへ転送する、或いはユーザ規定のＵＲＬから呼を転送するように、特定の加入者の呼をｖｏiｃｅ ｏｖｅｒ ＩＰ（ＶｏＩＰ）に変換するための手段を、提供する。そのＵＲＬは、ユーザのためのＰＣ、又は他のＩＰデバイス上のスピーカフォンアプリケーションと関連付けられることができる。このデバイスは、最初の終点の代わりに、呼、及びサービスを一時的かつシームレスに開始、又は終了させるための代用の終点として働くことができる。

地理的でない送出サービスプロバイダのスイッチを介して、ポート番号までの呼の経路を確立するリモート呼転送を使って、ＶｏＩＰ電話ネットワークにおいて、このサービスを作り出すことができる。送出サービスプロバイダは、そのサービスデータベースを使って、ＩＰアドレス、又はＵＲＬによって、受入サービスプロバイダを特定し、次に、その呼がＩＰに変換され、そのサービスプロバイダのソフトスイッチへ転送される。そのかわりに、呼を変換せず、関連するメディアゲートウェイに転送することもある。地理的でない送出サービスプロバイダのスイッチを介して、ポート番号までの信号経路が確立されるドロップバックにより、起点オペレータのネットワークのネットワーク内、及び冗長のための転送ネットワーク内の両方で、呼の経路を確立することができる。

例えば、呼より前に、Ｃｏｍｃａｓｔのようなブロードバンドサービスプロバイダ（ＢＳＰ）が、ユーザの携帯電話番号と対応付けられるユーザのＩＰアドレス、又はＵＲＬを登録する。Ｖｅｒｉｚｏｎのようなモバイルサービスプロバイダ（ＭＳＰ）は、加入者ボイスメールへのＩＰアクセスを、ＢＳＰに提供する。ＭＳＰ加入者によって提供される刺激時、メディアゲートウェイへのリモート呼転送（ＲＣＦ）、又は分岐呼のいずれかについてのデータベース入力が記録される。ＭＳＰへの着信は、ＭＳＰデータベースへのデータベース問い合わせを起動して、番号がポートされたかどうか判断する。ＲＣＦは、ＭＳＰ、又はＢＳＰのいずれかと地理的に関連付けられるメディアゲートウェイ、及びＵＲＬへの転送を起動する。ＭＳＰ、又はＢＳＰは、ユーザのＩＰデバイスに呼を送信する。分岐は、上で説明したＲＣＦ、及びモバイル交換センタを通したドロップバック接続、の両方を作動させる呼のフローを引き起こす。

分岐する場合、ドロップバックをどのように監視するかについて、規定を確立することができる。その規定は、例えば、ポートが利用可能であるかどうか、又はユーザがどちらかの電話装置において呼び出しに答えるかどうか、に基づくことができる。

ＢＳＰ上のＩＰデバイスからの発呼がＭＳＰからポートされた時、（ボタンの押しのような）ユーザ刺激が、ＢＳＰ加入者データベース内に示すように、ＳＰ間でハンドシェ−ク（課金）情報のみを共有する、単純な呼を開始することができる。そのかわりに、ボイスメール、又はＭＳＰサービスパッケージに適切な他のトランザクションをＩＰのパケットに変換するために、ユーザ刺激は、ＭＳＰデータベースへの複雑な問い合わせを開始することもできる。

同様に、ＢＳＰがＣＣＰユーザを登録することができる、或いは反対に、ライフラインの代用として、ＭＳＰが、ＢＳＰ又はＣＣＰユーザを登録することができる。

以下は、リモートサービス転送システムにおいて見出され得る、或いは維持され得る実体関係の幾つかを示している。図１は、リモートサービス転送システムを準備し、管理するために使用されるデータ関係を示している。加入者は、一又はそれ以上のサービスプロファイル、製品、及びプロファイル群へマッピングするために必要とされる、電話番号のポータビリティ情報を提供する。これらのプロファイルは、所望の終点の性質、並びにセッションにおけるサービスの品質、又はライフライン属性を実効的に供給するために使用される、それらの関連機能、及びポリシーについての情報を含む。そして次に、これらは、アプリケーションマネージャ（例えば、ＳＩＰ機能サーバ）のデータベース、及び／又はポリシー管理システムにマッピングすることができる。

起動時に、加入者は、位置情報を送り、着信時に呼び出されるべきサービスプロバイダ、及びプロファイルを特定する。この情報は、動作命令及びクライアントデータベースにマッピングされて、サービス及び課金情報を発行し、また任意で、アプリケーションマネージャとＲＳＦ終点との間で、ある程度の品質のサービスポリシーインターフェース、及び／又はセッションプロトコルの挙動を起動する。

ネットワークサービス、及びネットワークトポロジの発見を使用して、統一メールサービスにおけるＶＰＩＭインターフェース、及び高品質のサービスの目的のためのアクセスルータ形式、のような問題に対処する。

電話、又はウェブブラウザのようなシードデバイスは、以下で説明するような要素を実装することができるであろう。

自動供給モデルを使って、顧客は、リモートサービスエリア内の終端装置を介して、ログイン保護サイトにアクセスすることができる。交信サーバは、ブラウザのＣＧＩ、Ｊａｖａ、又は（クライアントのダウンロード、又はクライアントルーチンの埋め込みのような）他の手法によって、シードデバイスのプログラムを実行することができる。この発見は、ローカルＬＡＮ情報を発見すること、及びローカルサイトのネットワークトポロジを発見することで、構成される。

ローカルサイトのＬＡＮ情報を発見するために、Ｐｉｎｇ、ＡＲＰ−ａ、ウィンドウズレジストリのＬＯＣＡＬ Ｍａｃｈｉｎｅ ｑｕｅｒｉｅｓ等のような、受信及び送信サブネット発見の仕組みを提供する。

ローカルサイトのネットワークトポロジを発見するために、顧客の構内からＲＳＦポリシー管理要素に向けた、トレースルートのような仕組みの報告が作成されて、送信パケット経路上の初めの幾つかのルーティングネットワーク要素のＩＰアドレスを発見する（例えば、 Ｔｒａｃｅｒｏｕｔｅ −ｄ ＲＳＦｓｅｒｖｅｒ）。これらの報告は、受け取られ、送信される。（発見された最初の１〜３個の要素、のような）候補のアクセスルーティング要素、及びまたポリシーサーバによる任意の制御も持ち得る、候補の基盤構造ルータの選択されたＩＰアドレスについて、逆引きＤＮＳルックアップを調べることができる。ドメインのデータベースを発見して、ＲＳＦ機能と関連付けられるポリシー管理要素の制御、又はサービスの契約範囲内で、ルーティング、及び集合デバイス、それらの機能、及びアクセス形式（例えば、ＣＭＴＳケーブルルータ、ＤＳＬ、ＤＳＬＡＭ、Ｄｉａｌ ＲＡＳ、未知／ベストエフォート）を見つけることができる。

セッション／ポリシーにおいて、呼のフローのスクリプトが作成される。適切な品質のサービスポリシーメッセージの構成、及びこの特定のアクセス形式に基づく特定のクライアント形式のためのインターフェース（例えば、ＣＭＴＳ ＤＱｏＳポリシー、ＤＳＬＡＭ ＡＴＭ仮想回路の準備、ＩｎｔＳｅｒｖｅ／ＤｉｆｆＳｅｒｖ ＭＰＬＳ、ＲＳＶＰ プロキシターゲットルーチン／セッティング等）。必要なポリシーインターフェースを用いたアクセス方法のスクリプティングは、発見されたＲＳＦメディアに要求されるように提供される。

一例では、パケットケーブルマルチメディアアーキテクチャが、アプリケーションマネージャの要求によるポリシーマネージャからのＱｏＳプロキシの配信のための、様々なポリシー要素を起動する方法を示している。これは、リモートサービス転送システムについて上記で定めた方法により発見された、ポリシーの実施形態の例である。

以下は、リモートサービス転送について上記で定めた方法を使って、終端装置のアプリケーション（ＳＩＰ）終点機能プログラミングを実行する選択肢についての実施形態の例として示された、アプリケーション管理インターフェース（ＳＩＰヘッダーの例）である。

ＳＩＰプロキシとＲＳＦ終点との間のプロトコルは、例えば、Ｘ‐ｍｕｌｔｉｍｅｄｉａ‐ｓｅｒｖｉｃｅ‐ｅｎａｂｌｅｄと呼ばれる、新しいＳＩＰヘッダーを使用することができる。ＳＩＰプロキシ（ネットワークコアデバイス）からＳＩＰ電話（終端装置）へのメッセージに、このヘッダーを付加することができる。このヘッダーは、何のマルチメディアサービスをどのように提供すべきか、を示している。登録、又は呼のセットアップ時に、その情報を、終点に送ることができる。

例１
２００ ＯＫ
・ ・ ・
ＣＳｅｑ： １ ＲＥＧＩＳＴＥＲ
・ ・ ・
Ｘ‐ｍｕｌｔｉｍｅｄｉａ‐ｓｅｒｖｉｃｅ‐ｅｎａｂｌｅｄ： ＣＷ＝ｙｅｓ, ＣＣＷ＝ｙｅｓ, ＣＮＤ＝ｎｏ, ＤＶＣ＝ＷＤ６０３５, ＳＰ＝ＳＰＴ
例１は、このアカウントは、通話中着信（ＣＷ）、及び通話中着信取り消し（ＣＣＷ）サービスに加入しているだけであり、発信番号配信（ＣＮＤ）のサービスには加入していないということを通知する、（レジストラとして働く）ＳＩＰプロキシから送信されたメッセージである。エミュレートするデバイスは、京セラ ６０３５ ｐｈｏｎｅ（ＤＶＣ＝ＷＤ６０３５）であり、サービスはスクリプト使用法（ＳＰ＝ＳＰＴ）に従うはずである。ＲＥＧＩＳＴＥＲメッセージへの「２００ ＯＫ」において、このヘッダーを受け取った後、ＳＩＰ電話は、たとえ電話がそのような機能を内蔵していたとしても、登録の存続期間全体を通して、発呼者番号をユーザに示すのを止めるはずである。クライアントデバイスは、この電話の人がスプリントフレーバ機能のためにそれらを使用するようにボタンをマッピングした、Ｓｐｒｉｎｔ Ｋｙｏｃｅｒａ ６０３５ デバイスを使用するであろう。

例２
ＩＮＶＩＴＥ ｃｕｓｔｏｍｅｒ＠ｘ.ｃｏｍ ＳＩＰ／２．０
・ ・ ・
Ｘ‐ｍｕｌｔｉｍｅｄｉａ‐ｓｅｒｖｉｃｅ‐ｅｎａｂｌｅｄ： ＣＷ＝ｎｏ, ＤＶＣ＝ＳＥＩ２０２, ＳＰ＝ＶＲＺＮ
図２は、それがＩＮＶＩＴＥメッセージ、又はＩＮＶＩＴＥメッセージの応答内に表示される時の、毎呼ベースで終点に送信され得るヘッダーを示している。そのメッセージは、ＳＩＰプロキシから、呼ばれる人、及びデバイスへ送られる。たとえユーザが通話中着信サービスに加入していたとしても、この着呼については、そのサービスを提供すべきではないということを、そのヘッダーは示している。呼ばれる人がその呼を待機させたくない時、これは有用である。受信ＩＮＶＩＴＥメッセージにおいて、このヘッダーを受け取った後、ＳＩＰ電話は、呼ばれる人があたかも通話中着信機能を有していないかのように、その着信を扱うはずである。終端装置のマッピングは、ユーザのプロファイルが呼び出される側に存在していると述べている、Ｓｉｅｍｅｎｓ ＳＮＯ２０２ ＳＩＰ電話のマッピングであるべきであるということ、及び、Ｖｅｒｉｚｏｎ機能のように働くようにサービスをマッピングすべきであるということもまた、示している。

ＩＩ. リモートサービス転送システムの例
図１に示すように、ユーザは、ＩＰ（インターネットプロトコル）デバイス１０を通して、リモートサービス転送システムの機能にアクセスする。ＩＰデバイス１０は、例えば、ＩＰ接続を有するＷｉ‐Ｆｉ（或いは、ＰＨＳ）イネーブルの無線ＩＰ電話、又はパソコン（ＰＣ）、とすることができる。ＩＰデバイス１０は、インターフェースソフトウェア１２を含む。インターフェースソフトウェアは、例えば、ユーザのＰＣ上のグラフィカルユーザインターフェースアプリケーションとすることができる。この場合、インターフェースソフトウェアは、電話ボタンを持つ電話装置のインターフェースを模倣したグラフィカルインターフェースを持つことが好ましく、それは、例えば、ユーザのオフィスにおけるＰＢＸ、又はセントレックス電話機器の概観をまねることができる。このように、ユーザは、様々なデバイス上での使用のためのに、電話の操作を再学習する必要はない。

図１に示すように、ユーザは、複数のサービスプロバイダ（「送出サービスプロバイダ」１６及び１８）の加入者とすることができるが、リモートサービス転送を用いて、そのユーザは、それらのサービスプロバイダにより提供されたサービスに、単一の受入サービスプロバイダ１４を通してアクセスすることができる。

例えば、ユーザが、第２の送出サービスプロバイダ１８からのリモート呼転送の手はずが整えられた場合には、以下のように、起点電話２０からの電話の呼を、受入サービスプロバイダ１４を介してユーザに転送することができる。起点電話は、第２の送出サービスプロバイダ１８上のユーザの電話番号に対応する電話番号に、ダイヤルする。例えば、第２の送出サービスプロバイダ１８がモバイルサービスプロバイダである場合、そのサービスプロバイダ上でのユーザの電話番号は、彼の携帯電話の番号である。呼は、公衆電話交換ネットワークをわたって、生じることができる。

起点電話からの呼を受け取った時、第２の送出サービスプロバイダ１８は、呼び出された電話番号と関連付けられる情報について、サービスデータベース２４に問い合わせる。サービスデータベース２４は、電話番号を、ＩＰアドレス、及び／又はＵＲＬと対応付ける。問い合わせの結果が、呼び出された電話番号への呼は更なるサービスプロバイダに転送されるということを、示している場合には、第２の送出サービスプロバイダ１８が、その呼び出された電話番号と関連付けられるＩＰアドレスを検索する。ＩＰアドレスを、送出サービスプロバイダ、又は受入サービスプロバイダのいずれかと、地理的に対応付けることができる。転送された呼は、受入サービスプロバイダ１４へ送られる。例えば、ブロードバンドサービスプロバイダとすることのできる受入サービスプロバイダ１４は、ユーザのＩＰデバイス１０へ呼を送る。

第１の送出サービスプロバイダ１６は、第２の送出サービスプロバイダ１８と同様に動作する。サービスプロバイダ１８のように、サービスプロバイダ１６は、それ自身のサービスデータベース２６を含み、それは、ユーザの電話番号を、ＩＰアドレス及び／又はＵＲＬと対応付ける。第１の送出サービスプロバイダ１６は、例えば、ユーザのオフィスにおいて実装されるＰＢＸ、又はセントレックスシステムとすることができる。

異なるサービスプロバイダでは、単一ユーザの電話番号は異なる。例えば、（第１のサービスプロバイダ上の）ユーザのオフィスの番号は、（第２のサービスプロバイダ上の）ユーザの携帯電話の番号とは異なる。それにも関わらず、本出願で説明したシステムにより、様々なサービスプロバイダを通るユーザへの呼を、同じＩＰデバイス１０へ送信することができる。例えば、異なるネットワーク上の発呼者について特有の呼び出し音を使用することにより、ＩＰデバイス１０は、様々なサービスプロバイダを通って到着した呼を識別することができる。同様に、インターフェースソフトウェア１２は、異なるサービスプロバイダを通って到着した呼に対して、異なる電話をエミュレートすることができる。

様々なサービスプロバイダから転送された電話の呼を受け取ることができることに加えて、本システムのユーザは、様々なネットワーク上で提供される発呼、及び／又はアクセスサービスを作ることができる。そうするために、電話番号をダイヤルする、又は「＊」コマンドを入力することにより、ユーザは、ＩＰデバイス１０上で発呼を開始する。ＩＰデバイス１０は、ユーザによって情報が入力された受入サービスプロバイダ１４と交信し、その受入サービスプロバイダ１４は、それ自身のサービスデータベース２８を調べて、送出サービスプロバイダの１つとの通信を確立するのに必要とされる情報を特定する。次に、ＩＰデバイス１０のユーザは、送出サービスプロバイダの１つを通して、発呼を実施することができる、或いは、それらのサービスプロバイダによって格納されるボイスメールメッセージをチェックする、又は処理するというような、それらのプロバイダの他のサービスを利用することができる。

ＩＩＩ． リモートサービス転送方法の例
リモート転送システムを作動させる方法を、図２〜４に示す。図２は、サービス転送をセットアップする際に含まれるステップを示している。特に、ステップ３０におけるユーザ要求に応じて、システムは、ポーティング情報を、（ステップ３２において）受入サービスプロバイダ、及び（ステップ３４において）送出サービスプロバイダの両方と関連付けられるデータベース内に格納する。このように、送出サービスプロバイダへの呼を、受入サービスプロバイダ上のユーザに転送することができるだけでなく、ユーザは、受入サービスプロバイダにおいて、送出サービスプロバイダによって提供されるサービスにアクセスすることもできる。一より多い送出サービスプロバイダが存在する場合、受入サービスプロバイダにおけるポーティング情報は、異なる送出サービスプロバイダを識別することができる。

着呼を転送するプロセスを、図３に示す。ステップ３６において、呼は、送出サービスプロバイダにおいて受け取られる。次に、ステップ３８において、送出サービスプロバイダは、チェックして、呼を転送すべきかどうかを判断する。転送すべきでない場合には、呼は通常に処理され、さもなければ、ステップ４０において、その呼を転送すべきＩＰアドレス、及び／又はＵＲＬを、送出サービスプロバイダが突き止め、ステップ４２において、呼をそのＩＰアドレスに転送する。

受入サービスプロバイダ上のＩＰデバイスを使って、送出サービスプロバイダ上のサービスにアクセスするプロセスを、図４に示している。ステップ５０において、ユーザが呼を開始し、その呼開始が、受入サービスプロバイダによって受け取られる。ステップ５２において、サービスプロバイダはユーザ情報を検索し、それは、ユーザが加入する様々な送出サービスプロバイダを識別する情報を含むことができる。ステップ５４において、受入サービスプロバイダは、手近でその呼のために使用される送出サービスプロバイダを特定する。例えば、ユーザが複数の送出サービスプロバイダを準備した場合、そのシステムは、ボイス発呼のためにどのサービスプロバイダを使用するか、或いはどのシステムが「＊」コマンドに応答するか、を特定することができる。それが、必要なデータを検索し、送出サービスプロバイダを特定すると、ステップ５６において、受入サービスプロバイダが、その送出サービスプロバイダとハンドシェ−ク情報を交換する。この情報は、課金情報を含むことができる。受入サービスプロバイダが、ボイスメールのような、送出サービスプロバイダによって提供されるサービスにアクセスするために、何らかの更なる情報が必要とされる場合には、ステップ５８において、その情報を交換することができる。それが必要な情報を受け取った後、ステップ６０において、受入サービスプロバイダは、ＩＰネットワークによって、ユーザにサービスをポートする。例えば、受入サービスプロバイダがブロードバンドサービスプロバイダであり、送出サービスプロバイダが携帯電話サービスプロバイダである場合、ユーザは、例えばＰＣから、ＩＰネットワークによって、彼の携帯電話のボイスメールにアクセスすることができる。

本明細書は、本発明の様々な実装を明らかにすることを意図した特定の例、及び実施形態を示しているが、これらを、本発明を限定するように理解すべきではなく、その実践は、本出願で説明するそれらのシステム及び方法の変形を含んでいる。むしろ、本発明の技術的範囲は、幾つかの以下の請求項により定められる。

サービスプロバイダとユーザデバイスとの間の接続を示す、概略ブロック図である。 リモートサービス転送システムにおけるサービスセットアップを示す、概略フローチャートである。 リモートサービス転送システムにおける着呼処理を示す、概略フローチャートである。 リモートサービス転送システムにおける発呼処理を示す、概略フローチャートである。

Claims (15)

1. 第１の送出サービスプロバイダにおいて、第１の電話番号への第１の呼を受け取るステップと、
   前記第１の電話番号と対応付けられる第１のインターネットプロトコルアドレスを特定するステップと、
   前記第１の呼を、前記第１のインターネットプロトコルアドレスへ転送するステップと、
   を含むことを特徴とする、リモートサービス転送を提供するための方法。
2. 第２の送出サービスプロバイダにおいて、第２の電話番号への第２の呼を受け取るステップと、
   前記第２の電話番号と対応付けられる第２のインターネットプロトコルアドレスを特定するステップと、
   前記第２の呼を、前記第２のインターネットプロトコルアドレスへ転送するステップと、
   をさらに含むことを特徴とする、請求項１に記載する方法。
3. 前記第１の電話番号、及び前記第２の電話番号は異なる
   ことを特徴とする、請求項２に記載の方法。
4. 前記第１のインターネットプロトコルアドレス、及び前記第２のインターネットプロトコルアドレスが同じである
   ことを特徴とする、請求項３に記載の方法。
5. 送出サービスプロバイダから受入サービスプロバイダへ呼をポートするような、第１のポーティング要求を受け取るステップと、
   前記送出サービスプロバイダと関連付けられる第１のデータベース内に、前記受入サービスプロバイダの加入者と対応付けられるＩＰアドレスを格納するステップと、
   前記受入サービスプロバイダと関連付けられる第２のデータベース内に、前記送出サービスプロバイダにおいて提供されるサービスと関連付けられるサービス情報を格納するステップと、
   を含むことを特徴とする、リモートサービス転送を提供するための方法。
6. 前記送出サービスプロバイダが、モバイルサービスプロバイダである
   ことを特徴とする、請求項５に記載の方法。
7. 前記受入サービスプロバイダが、ブロードバンドサービスプロバイダである
   ことを特徴とする、請求項６に記載の方法。
8. 前記送出サービスプロバイダにおいて提供される前記サービスが、ボイスメールである
   ことを特徴とする、請求項７に記載の方法。
9. 送出サービスプロバイダにおいて、第１の電話番号へ向けられた呼を受け取るステップと、
   前記第１の電話番号と対応付けられるインターネットプロトコルアドレスを特定するステップと、
   前記第１の電話番号と関連付けられる第２の電話番号を特定するステップと、
   前記呼を、前記インターネットプロトコルアドレス、及び前記第２の電話番号へ転送することを要求することにより、該呼を分岐するステップと、
   を含むことを特徴とする、リモートサービス転送を提供するための方法。
10. ユーザから転送メッセージを受け取るステップと、
    前記ユーザと対応付けられるハードウェア電話に向けられた着呼を受信するステップと、
    前記呼を、前記ユーザと対応付けられる携帯電話に転送するステップと、
    を含むことを特徴とする、リモートサービス転送を提供するための方法。
11. 前記転送メッセージが、呼を転送すべきＵＲＬを特定する
    ことを特徴とする、請求項１０に記載の方法。
12. 前記転送メッセージが、呼を転送すべきＩＰアドレスを特定する
    ことを特徴とする、請求項１０に記載の方法。
13. 前記ハードウェア電話が構内交換電話である
    ことを特徴とする、請求項１０に記載の方法。
14. 前記携帯電話が、無線インターネットプロトコル電話である
    ことを特徴とする、請求項１０に記載の方法。
15. 前記携帯電話、及び前記ハードウェア電話が、様々なサービスプロバイダにより作動される
    ことを特徴とする、請求項１０に記載の方法。

Images