(57)【要約】ＯＴＴネットワークとＴＴＮネットワークとをシームレスに接続する方法であって、ＴＳＰによって、発呼者から、被呼者のダイヤルされた番号を受信すること、ＴＳＰによって、ダイヤルされた番号をＯＴＴサービスプロバイダに伝達すること、ＯＴＴサービスプロバイダによって、それが呼を着信可能かどうか確認すること、及び確認の結果をＴＳＰに伝達すること、を含み、障害の際、ＴＳＰは、発呼者と被呼者の両者に対してシームレスに、呼を再ルーティング可能である方法が提供される。【選択図】図５
2016506136.tif 000002
【特許請求の範囲】
【請求項１】
Ｏｖｅｒ−Ｔｈｅ−Ｔｏｐ（ＯＴＴ）ネットワークと従来型電気通信ネットワーク（Ｔｒａｄｉｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋｓ、ＴＴＮ）とをシームレスに接続する方法であって、
ＴＴＮ電気通信サービスプロバイダ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ、ＴＳＰ）によって、発呼者から、被呼者のダイヤルされた番号を受信するステップと、
前記ＴＴＮＴＳＰによって、前記ダイヤルされた番号をＯＴＴサービスプロバイダに伝達するステップと、
前記ＯＴＴサービスプロバイダによって、それが呼を着信可能かどうか確認するステップであって、通信試験を行うこと、及び通信がＷｉ−Ｆｉであるかどうかを確認することの少なくともいずれかに基づいて、前記ＯＴＴサービスプロバイダと前記被呼者との間の接続性が十分であるかどうかを確認することを含む、ステップと、
前記確認の結果を前記ＴＳＰに伝達するステップと、を含み、
障害の際、前記ＴＳＰは、前記発呼者と前記被呼者の両者に対してシームレスに、前記呼を再ルーティング可能である、
方法。
【請求項２】
請求項１に記載の方法であって、
前記ＴＳＰによって、前記ＯＴＴサービスプロバイダを前記呼の呼着信として選択するステップと
前記ＯＴＴサービスプロバイダによって、前記呼を着信するステップと、
を更に含む、方法。
【請求項３】
請求項１に記載の方法であって、
前記確認するステップは、前記ダイヤルされた番号が、前記ＯＴＴサービスの登録済み番号に関連付けられているかどうかを確認することを含む、方法。
【請求項４】
請求項１に記載の方法であって、
前記確認するステップは、前記被呼者がオンラインであるかどうかを確認することを含む、方法。
【請求項５】
請求項１に記載の方法であって、
前記確認するステップは、被呼ユーザによってどの通信ネットワークが現在使用されているかを確認することを含む、方法。
【請求項６】
請求項１に記載の方法であって、
前記確認するステップは、前記被呼者のルーティング設定を確認することを含む、方法。
【請求項７】
ＯＴＴネットワークとＴＴＮネットワークとをシームレスに接続する方法であって、
ＴＳＰによって、発呼者から、被呼者のダイヤルされた番号を受信すること、
前記ＴＳＰによって、前記ダイヤルされた番号を、ＯＴＴサービスプロバイダ及びＴＴＮサービスプロバイダに同時に伝達するステップと、
前記ＯＴＴサービスプロバイダによって、それが呼を着信可能かどうか確認するステップと、
前記確認の結果を前記ＴＳＰに伝達するステップと、
前記ＴＴＮサービスプロバイダによって、それが前記呼を着信可能かどうか確認するステップと、
前記確認の結果を前記ＴＳＰに伝達するステップと、
前記ＯＴＴサービスプロバイダ及び前記ＴＴＮサービスプロバイダのいずれかによって前記呼を着信するステップと、
を含む、方法。
【請求項８】
請求項７に記載の方法であって、
前記ＯＴＴサービスプロバイダによって確認するステップは、前記ダイヤルされた番号が、前記ＯＴＴサービスの登録済み番号に関連付けられているかどうかを確認することを含む、方法。
【請求項９】
請求項８に記載の方法であって、
前記ＯＴＴサービスプロバイダによって確認するステップは、前記被呼者がオンラインであるかどうかを確認することを含む、方法。
【請求項１０】
請求項９に記載の方法であって、
前記ＯＴＴサービスプロバイダによって確認するステップは、前記ＯＴＴサービスプロバイダと前記被呼者との間の接続性が十分であるかどうかを確認することを含む、方法。
【請求項１１】
請求項１０に記載の方法であって、
通信が十分であるかどうかを確認するステップは、通信試験を行うことを含む、方法。
【請求項１２】
請求項１０に記載の方法であって、
通信が十分であるかどうかを確認するステップは、集約された履歴データのデータベースを参照することを含む、方法。
【請求項１３】
請求項１０に記載の方法であって、
通信が十分であるかどうかを確認するステップは、前記通信がＷｉ−Ｆｉであるかどうかを確認することを含む、方法。
【請求項１４】
請求項７に記載の方法であって、
前記ＯＴＴサービスプロバイダによって確認するステップは、被呼ユーザによってどの通信ネットワークが現在使用されているかを確認することを含む、方法。
【請求項１５】
請求項９に記載の方法であって、
前記確認するステップは、前記被呼者のルーティング設定を確認することを含む、方法。
【請求項１６】
コンピュータ格納媒体であって、
請求項１に記載の方法を行うためにデジタル処理装置によって実行可能な、機械読み取り可能命令のプログラムを実体的に具体化する、媒体。
【請求項１７】
コンピュータ格納媒体であって、
請求項７に記載の方法を行うためにデジタル処理装置によって実行可能な、機械読み取り可能命令のプログラムを実体的に具体化する、媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼の着信の分野に関し、より具体的には、ＯＴＴ又は非ＯＴＴ端末から発呼され、ＯＴＴ又は非ＯＴＴ端末でシームレスに着信する呼の着信に関する。
関連出願の参照
本出願は、本明細書において参照によりその全体が援用される２０１２年１２月５日出願の米国仮出願第６１／７３３，４３６号の優先権を主張する。
【背景技術】
【０００２】
呼の着信（Ｃａｌｌ  ｔｅｒｍｉｎａｔｉｏｎ）は通話の着信（ｖｏｉｃｅ  ｔｅｒｍｉｎａｔｉｏｎ）とも呼ばれ、電話の呼を、一の電話会社（キャリア、又はプロバイダとも呼ばれる）から別の電話会社へとルーティングすることを指す。
【０００３】
着信ポイントは被呼者又はエンドポイントである。発信ポイントは呼を開始する発呼者である。
【０００４】
従来型電気通信ネットワーク（Ｔｒａｄｉｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋｓ、ＴＴＮ）は、ＧＳＭ（登録商標）、ＣＤＭＡ、ＷＣＤＭＡ（登録商標）、ＰＳＴＮ等の技術を用い、エンドユーザの装置への音声通信の最終ホップにＶｏＩＰ技術を用いないネットワークである。
【０００５】
これらのネットワークは、通常、ユーザの識別情報を表すものとしてＥ．１６４電話番号フォーマットを用いる（例：１８０９２００５１５１）。
【０００６】
従来型端末アプリケーション（Ｔｒａｄｉｔｉｏｎａｌ  Ｔｅｒｍｉｎａｌ  Ａｐｐｌｉｃａｔｉｏｎ、ＴＴＡ）は、従来型電気通信ネットワーク（ＴＴＮ）上の呼を受信可能な端末アプリケーションである。
【０００７】
ＯＴＴは、Ｏｖｅｒ−Ｔｈｅ−Ｔｏｐの略語であり、基礎にある通信基盤技術とは独立したアプリケーション及びサードパーティのサービスを通じて送信される広範囲のコンテンツを包含する。ＯＴＴは通常、電気通信サービスプロバイダ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ、ＴＳＰ）の基盤を用い、時として従来型のＴＳＰのサービスと競合しつつ、ネットワークの加入者にサービス及びアプリケーションを提供するアプリケーションを指すのに用いられる。Ｏｖｅｒ−Ｔｈｅ−Ｔｏｐのコンテンツは、ＰＣ、ラップトップ、タブレット、スマートフォン、及びその他のＷｅｂ利用可能装置等のインターネットに接続されたプラットフォームを通じて直接アクセス可能である。ＯＴＴサービスの例として、ＶｏＩＰ、メッセージング、及び／又は動画のサービスを運営及び提供するＳｋｙｐｅ、Ｇｏｏｇｌｅ  Ｖｏｉｃｅ、及びＶｉｂｅｒが挙げられる。
【０００８】
ＯＴＴ端末アプリケーション（ＯＴＡ）は、ＯＴＴネットワークに接続され、ＶｏＩＰ技術を用いて音声呼を受信することが可能なエンドユーザアプリケーションである。
【０００９】
ある人が日本に国際電話をかけたいと仮定する。発呼者は、国際電話プリフィックス、続いて国番号（例：日本は８１）、続いて（一般的には）冒頭のゼロを省略又は減らした地域コード、その後に市内電話番号、からなる番号をダイヤルする。
【００１０】
ここで、発呼者の電気通信サービスプロバイダ（ＴＳＰ）は、ダイヤルされた番号への呼を着信可能な日本のサービスプロバイダ、例えばＮＴＴ（日本電信電話株式会社）、もしくはＡＴ＆Ｔ、Ｏｒａｎｇｅ、０２、Ｖｏｄａｆｏｎｅ、ＢＴ、Ｆｒａｎｃｅ  Ｔｅｌｅｃｏｍ等のその他の電気通信サービスプロバイダ、又は、発呼者のＴＳＰと取引関係があり呼をエンドポイントまでルーティング可能な任意のＴＳＰ、を探索する。
【００１１】
これは、取引のあるキャリア（コンピュータ対コンピュータ）へ呼をルーティングすることで行われる。キャリアは、指定された番号へ呼を成立させられるかどうか確認する。可能であれば、呼はユーザ、又はサードパーティキャリアへとルーティングされる。呼をルーティングできない場合、呼を拒否し、発呼者のＴＳＰは次のホップ（すなわち、別のキャリア）を試す。この工程は、キャリアからキャリアへと順に行われる。
【００１２】
図１は、ＴＴＡ端末１０５から別のＴＴＡ端末１４０への呼を扱う、従来技術のシステム１００の模式図である。発呼者の現地ＴＳＰ（ＴＳＰ１  １１０）は、発呼者がダイヤルした標準ＴＴＮ番号を受信して、呼を着信するための他のＴＴＮキャリア（例：ＴＳＰ２  １２０）の逐次的な探索を開始する。ＴＳＰ２が呼を拒否した場合、ＴＳＰ１は、呼をＯＴＡ１４０へ着信させることのできる非ＯＴＴのＴＳＰｉ  １３０に行き当たるまで、逐次的な探索を続ける。
【００１３】
図２は、ＴＴＡ端末２０５からＯＴＡ２３０への呼を扱う、別の従来技術のシステム２００の模式図である。発呼者の現地ＴＳＰ（ＴＳＰ１  ２１０）は、発呼者がダイヤルしたＯＴＴ番号を受信し、呼を着信させる他のＴＴＮキャリア（例：ＴＳＰ２  ２２０）の逐次的な探索を開始する。ＴＳＰ２が呼を拒否した場合、ＴＳＰ１は、利用可能なＴＳＰリストの末尾に達するまで、逐次的な探索を続ける。呼は着信できない。その理由は、ＯＴＴキャリアとＴＳＰが同じユーザ識別情報（番号フォーマット）を共有していないのがその理由である。
【００１４】
図３は、ＴＴＡ端末３０５からＯＴＡ３４０への呼を扱う、別の従来技術のシステム３００の模式図である。この構成において、ＯＴＡ３４０は、標準的な識別情報とは異なる、ＴＴＮからＯＴＴへの通信のための特殊な番号を割り当てられている。発呼者の現地ＴＳＰ（ＴＳＰ１  ３１０）は、発呼者がダイヤルしたＯＴＴ番号を受信し、それをＯＴＴゲートウェイ３２０に伝達する。ＯＴＴゲートウェイ３２０は、ダイヤルされた番号を、ＯＴＴのＴＳＰ３３０に属するものとして認識し、ＯＴＴのＴＳＰ３３０は、ダイヤルされた番号をＯＴＴ（例：Ｓｋｙｐｅ）のユーザ３４０に一致させることができる。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
ＴＴＡからＯＴＡへのスムーズな通信を提供するためには、ＴＴＡから発呼された呼がシームレスにＯＴＡに着信する必要がある。
【課題を解決するための手段】
【００１６】
本発明の一の態様によれば、ＯＴＴとＴＴＮ（非ＯＴＴネットワーク）とをシームレスに接続する方法であって、ＴＳＰによって、発呼者から、被呼者のダイヤルされた番号を受信するステップと、前記ＴＳＰによって、前記ダイヤルされた番号をＯＴＴサービスプロバイダに伝達するステップと、前記ＯＴＴサービスプロバイダによって、それが前記呼を着信可能かどうか確認するステップと、前記確認の結果を前記ＴＳＰに伝達するステップと、を含み、障害の際、前記ＴＳＰは、前記発呼者と前記被呼者の両者に対してシームレスに、前記呼を再ルーティング可能である方法が提供される。
【００１７】
上記方法は、前記ＴＳＰによって、前記ＯＴＴサービスプロバイダを前記電話呼の呼着信（ｃａｌｌ  ｔｅｒｍｉｎａｔｏｒ）として選択するステップと、前記ＯＴＴサービスプロバイダによって前記呼を着信するステップと、を更に含み得る。
【００１８】
前記確認するステップは、前記ダイヤルされた番号が、前記ＯＴＴサービスの登録済み番号に関連付けられているかどうかを確認することを含み得る。
【００１９】
前記確認するステップは、前記被呼者がオンラインであるかどうかを確認することを含み得る。
【００２０】
前記確認するステップは、前記ＯＴＴサービスプロバイダと前記被呼者との間の接続性が十分であるかどうかを確認することを含み得る。
【００２１】
前記通信が十分であるかどうかを確認するステップは、通信試験を行うことを含み得る。
【００２２】
前記通信が十分であるかどうかを確認するステップは、集約された履歴データのデータベースを参照することを含み得る。
【００２３】
前記通信が十分であるかどうかを確認するステップとは、前記通信がＷｉ−Ｆｉであるかどうかを確認することを含み得る。
【００２４】
前記ＯＴＴサービスプロバイダによって確認するステップは、前記被呼ユーザによってどの通信ネットワークが現在使用されているかを確認することを含み得る。
【００２５】
前記ＯＴＴサービスプロバイダによって確認するステップは、ＯＴＴのエンドユーザが、ＴＴＮからの呼をそのＯＴＡで受信することを希望しているかどうかを確認することを含み得る。
【００２６】
本発明の別の態様によれば、ＯＴＴネットワークと非ＯＴＴネットワークとをシームレスに接続する方法であって、ＴＳＰによって、発呼者から、被呼者のダイヤルされた番号を受信するステップと、前記ＴＳＰによって、前記ダイヤルされた番号を、ＯＴＴサービスプロバイダ及びＴＴＮサービスプロバイダに同時に伝達するステップと、前記ＯＴＴサービスプロバイダによって、それが前記電話呼を着信可能かどうか確認するステップと、前記確認の結果を前記ＴＳＰに伝達するステップと、前記ＴＴＮサービスプロバイダによって、それが前記電話呼を着信可能かどうか確認するステップと、前記確認の結果を前記ＴＳＰに伝達するステップと、前記ＯＴＴサービスプロバイダ及び前記ＴＴＮサービスプロバイダのいずれかによって前記呼を着信するステップと、を含む、方法が提供される。
【００２７】
前記ＯＴＴサービスプロバイダによって確認するステップは、前記ダイヤルされた番号が、前記ＯＴＴサービスの登録済み番号に関連付けられているかどうかを確認することを含み得る。
【００２８】
前記ＯＴＴサービスプロバイダによって確認するステップは、前記被呼者がオンラインであるかどうかを確認することを含み得る。
【００２９】
前記ＯＴＴサービスプロバイダによって確認するステップは、前記ＯＴＴサービスプロバイダと前記被呼者との間の接続性が十分であるかどうかを確認することを含み得る。
【００３０】
前記通信が十分であるかどうかを確認するステップは、通信試験を行うことを含み得る。
【００３１】
前記通信が十分であるかどうかを確認するステップは、集約された履歴データのデータベースを参照することを含み得る。
【００３２】
前記通信が十分であるかどうかを確認するステップは、前記通信がＷｉ−Ｆｉであるかどうかを確認することを含み得る。
【００３３】
前記ＯＴＴサービスプロバイダによって確認するステップは、前記被呼ユーザによってどの通信ネットワークが現在使用されているかを確認することを含み得る。
【００３４】
前記ＯＴＴサービスプロバイダによって確認するステップは、ＯＴＴのエンドユーザが、ＴＴＮからの呼をそのＯＴＡで受信することを希望しているかどうかを確認することを含み得る。
【図面の簡単な説明】
【００３５】
本発明のよりよい理解のために、また、本発明がいかに実施され得るかを示すために、純粋に例示として添付の図面が参照される。
【００３６】
図面を詳細に参照しつつ、図示される事項は、本発明の好適な実施形態の例示ならびに説明的考察のためでしかなく、本発明の原理及び概念的側面の、最も有用かつ容易に理解可能と考えられる説明を提供する目的で掲示されていることが強調される。そのため、本発明の構造的詳細は、本発明の基礎的理解に必要とされる以上に詳細に示されることは意図されず、図面による説明は、実運用において本発明の複数の形態がいかに実施され得るかを当業者に対して明らかにする。添付の図面は以下のようなものである。
【００３７】
【図１】一のＴＴＡから他のＴＴＡへの呼を扱う、従来技術のシステムの模式図である。
【図２】ＴＴＡからＯＴＡへの呼を扱う、従来技術のシステムの模式図である。
【図３】ＴＴＡからＯＴＡへの呼を扱う、別の従来技術のシステムの模式図である。
【図４】Ａ及びＢは、ＴＴＡ電話番号をダイヤルするＴＴＡ発呼者を含む、本発明による呼着信システムの模式図である。
【図５】ＴＴＡ電話番号をダイヤルするＴＴＡ発呼者を含む、本発明による別の呼着信システムの模式図である。
【図６】図５の実施形態で示される本発明の手順のフロー図である。
【発明を実施するための形態】
【００３８】
本発明は、必ずしもＯＴＴ呼として開始されていない呼に対して、ＯＴＴサービスプロバイダがＯＴＴネットワーク上で最終ホップの呼の着信地として機能することを可能にする。非ＯＴＴ（ＴＴＮ）通信とＯＴＴ通信とを融合することで、呼の効率性、呼の完了可能性、及び接続可能な宛先装置数を向上し、同時呼び出し機能を可能にする。
【００３９】
ＯＴＴサービスのユーザは、非ＯＴＴからの呼を自らのＯＴＴアプリケーションにルーティングすることを許可したいかどうかを決めることができる。これにより、ＯＴＴユーザはどのネットワークで呼を受信するかを決めることができ、このユーザはネットワークルーティングの決定においてアクティブな要素（ａｃｔｉｖｅ  ｅｌｅｍｅｎｔ）となる。
【００４０】
これは、ＯＴＡユーザインタフェース上で、他のＯＴＴクライアントからではないインバウンド呼を自らのＯＴＡ上で受け入れるか否かをユーザに選択させることによって行われる。ユーザの選択に従って、ＯＴＡはＯＴＴネットワークにユーザの選択を知らせ、ＯＴＴネットワークはそれに従って呼をルーティングする。
【００４１】
ＴＴＮからインバウンド呼リクエストを受信すると、ＯＴＴネットワークは、その呼をネットワークにルーティングするか拒否するかを決定する前に、ユーザ設定を確認する必要がある。
【００４２】
図４Ａは、標準ＴＴＮ電話番号をダイヤルするＴＴＡ発呼端末４６０を含む、本発明による呼着信システム４５５の模式図である。発呼者のダイヤルした番号を受信する、発呼者の現地ＴＴＮであるＴＳＰ１  ４６５は、まず呼着信リクエストをＯＴＴであるＴＳＰ２  ４７０に伝達する。ＴＳＰ  ４７０は、呼び出された番号が自らのＯＴＴサービスのユーザに属しているかどうかを確認し、ＯＴＴネットワークがその呼を接続可能かどうか決定し得る。接続可能でなく、ＯＴＴであるＴＳＰ２  ４７０が呼を拒否すると、ＴＴＮであるＴＳＰ１  ４６５は、呼を着信可能な、例えばＴＴＮであるＴＳＰ３  ４４０を見つけるまで、他のＴＳＰ（ＯＴＴ又はＴＴＮ）の逐次的な探索を続け得る。
【００４３】
図４Ｂは、標準ＴＴＮ電話番号をダイヤルするＴＴＡ発呼端末４０５を含む、本発明による同様の呼着信システム４００の模式図である。発呼者のダイヤルした番号を受信する、発呼者の現地ＴＴＮであるＴＳＰ１  ４１０は、まず呼着信リクエストをＴＴＮであるＴＳＰ３  ４４０に伝達する。ＴＳＰ３  ４４０は自らがその呼を着信できるかどうかを確認し得る。着信可能でなく、ＴＳＰ３  ４４０が呼を拒否すると、ＴＳＰ１  ４１０は、呼を着信可能な、例えばＯＴＴであるＴＳＰ２  ４３０を見つけるまで、他のＴＳＰ（ＯＴＴ又はＴＴＮ）の逐次的な探索を続ける。
【００４４】
図５は、標準ＴＴＮ電話番号をダイヤルするＴＴＡ発呼端末５０５を含む、本発明による別の呼着信システム５００の模式図である。発呼者のダイヤルした番号を受信する、発呼者の現地ＴＴＮであるＴＳＰ１  ５１０は、呼着信リクエストを、ＯＴＴであるＴＳＰ２  ５２０とＴＴＮであるＴＳＰ３  ５４０とに平行して伝達する。ＴＳＰ２  ５２０は、呼び出された番号が自らのＯＴＴサービスのユーザに属しているかどうかを確認し、ユーザが現在オンラインである場合、ユーザ設定に従って、その呼を接続可能かどうか決定し得る。同時に、ＴＳＰ３  ５４０が、呼を着信可能かどうか確認し得る。
【００４５】
その後、２種類のシナリオが考えられる：
１．ＴＴＮであるＴＳＰ及び／又はＯＴＴであるＴＳＰが、この宛先への呼を受信できないという理由で呼を拒否し、呼の試みは、他のＴＴＮであるＴＳＰ／ＯＴＴであるＴＳＰで継続するか、又は拒否される。
２．ＴＳＰネットワークに接続された装置とＯＴＴネットワークに接続された装置の両方で同時に呼び出し音が鳴り：
ａ．ユーザが一方の電話に応答すると、他方の呼び出し音はキャンセルされる。
ｂ．ユーザがいずれの電話にも応答しないと、タイムアウト後に呼はキャンセルされる。
【００４６】
図６は、図５の実施形態で示される本発明の手順を示すフロー図である。
【００４７】
ステップ６００において、発呼者は、例えば、標準ＴＴＮ番号である国際電話番号をダイヤルする。
【００４８】
ステップ６１０において、発呼者の現地ＴＳＰは、ダイヤルされた番号を受信し、接続されている着信プロバイダのリストから、呼を着信するプロバイダを探索する。リストは、ＯＴＴ及びＴＴＮプロバイダを含み得る。現地ＴＳＰは、複数の潜在的着信プロバイダに並行して伝達し、現在の呼を着信させるために１つを選択する。
【００４９】
ステップ６２０において、現地のＴＳＰプロバイダによって接触されたＯＴＴサービスプロバイダＴＳＰ２は、被呼者がＯＴＴサーバ（ステップ６３０）の登録ユーザであるかどうかをサーバデータベースで確認して、自らが確実かつ素早くサービスを提供できるかどうかの確認を開始する。提供可能でない場合、ＯＴＴプロバイダは、現在の呼の呼着信（ｃａｌｌ  ｔｅｒｍｉｎａｔｏｒ）としての役割を果たす提案を拒否する。
【００５０】
ステップ６３０において、ＯＴＴサービスプロバイダは、被呼者がそのＯＴＴサービスの登録ユーザであることを確認すると、被呼者が現在オンラインであるかどうか（ステップ６３５）、及び、ユーザのルーティング設定が、ＴＴＮで開始された呼をそのＯＴＡへルーティングすることを許可するかどうか、の確認に移る。ルーティングできない場合、ＯＴＴサービスプロバイダは、現在の呼の呼着信（ｃａｌｌ  ｔｅｒｍｉｎａｔｏｒ）としての役割を果たす提案を拒否する。
【００５１】
ステップ６３８において、被呼者が現在オンラインであることと、ユーザのルーティング設定が、ＴＴＮで開始された呼をそのＯＴＡへルーティングすることを許可することと、をＯＴＴサービスプロバイダが確認すると、例えば短い性能テスト（少量（例えば１０個）のパケットを可能な限り高速で送信し、宛先端末からの返信を待機し、返信の到着時間をテストすることで、接続性を推定する、及び／又は、その装置が前回呼び出し又はインタラクション（チャット等）された時をチェックして、前回のインタラクションで測定された品質パラメータを用いる）によって、接続性が十分であるかどうかを確認し得る（ステップ６４０）。品質パラメータには、パケット遅延率、パケット損失率、ジッタバッファ率、品質についてのユーザの意見（インタラクション完了後に提供される）が含まれ得る。別法として、もしくは追加で、ＯＴＴサービスプロバイダは、集約された履歴データのデータベースを参照することで、現在の接続品質を判断し得る。接続性が不十分であると判断された場合、ＯＴＴプロバイダは、現在の呼の呼着信（ｃａｌｌ  ｔｅｒｍｉｎａｔｏｒ）としての役割を果たす提案を拒否する。別法として、もしくは追加で、ＯＴＴサービスプロバイダは、利用されているネットワークの種類（例：Ｗｉ−Ｆｉ又は３Ｇ）を確認することで、現在の接続性が十分であるかを判断し得る。
【００５２】
接続性が十分であると判断された場合、ＯＴＴであるＴＳＰ２は呼を着信させる（ステップ６４５）。
【００５３】
ステップ６２５において、発呼者のＴＳＰは、呼着信リクエストを、ＴＴＮであるＴＳＰ３に並行して伝達する。ステップ６６０において、ＴＳＰ３は、呼を着信可能かどうか確認する。着信が可能でない場合、ＴＳＰ３は、現在の呼の呼着信としての役割を果たす提案を拒否する。可能である場合、ＴＳＰ３は、呼を着信させる（ステップ６６５）。
【００５４】
なお、呼を着信可能な最初のＴＳＰを発見するとただちに、発呼者のＴＳＰは、並行して接触している他のＴＳＰに対して「キャンセル」メッセージを伝達し得る。
【００５５】
別段の指定がない限り、本稿で用いられる全ての技術用語及び科学用語は本発明が属する技術分野の当業者によって通常理解されるものと同じ意味を有する。本発明の実運用又は試験においては、本稿に記載のものと同様又は等価の方法が利用可能であるが、適切な方法が本稿に記載される。
【００５６】
本稿に記載の主題の少なくとも一部は、デジタル電子回路、コンピュータソフトウェア、ファームウェア、ハードウェア、又はこれらの組み合わせ、において実装され得る。本稿に記載の主題は、データ処理装置（プログラム可能プロセッサ、コンピュータ、又は複数台のコンピュータ）により実行される、またはその動作を制御する、１以上のコンピュータプログラム製品、すなわち非一時的媒体（例えば機械読み取り可能な格納装置）に実体的に具体化された１以上のコンピュータプログラム、として実装され得る。コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードともいう）は任意のプログラミング言語で書かれてよい。コンピュータプログラムは必ずしも１つのファイルに対応する必要はない。コンピュータプログラムは１台のコンピュータ、又は、一箇所又は分散環境にある複数台のコンピュータ上で実行されてよい。
【００５７】
当業者には、本発明は具体的に上掲及び上述されたものに限定されないことが理解される。本発明の範囲は、添付の請求の範囲によって定義され、上述の多様な機能の組み合わせとサブコンビネーションの両方、更に、上述の説明に接した当業者によって発想されるその変異及び変形を含む。
【図１】
2016506136.tif 000003
【図２】
2016506136.tif 000004
【図３】
2016506136.tif 000005
【図４Ａ】
2016506136.tif 000006
【図４Ｂ】
2016506136.tif 000007
【図５】
2016506136.tif 000008
【図６】
2016506136.tif 000009
【国際調査報告】
2016506136.tif 000010
2016506136.tif 000011
2016506136.tif 000012