JP2015535414A - 未準備端末の呼 - Google Patents

Abstract

発呼者と被発呼者との間に、呼確立要求とそれに対応する呼受諾応答とを含む呼フローに基づいて、音声またはビデオ呼を確立する。第１の呼確立要求が、受信時に呼を受諾する準備ができていない被発呼者の被発呼端末に送信される。被発呼端末が呼を受諾する準備ができると、呼受諾応答ではなく、呼に対するリバース呼確立要求を被発呼端末から受信する。リバース呼確立要求は、一定の制限時間内に被発呼端末から受信したことを条件に、発呼者に代わって自動的に受諾される。そうすると、被発呼端末に呼受諾応答のインスタンスを送信することにより、呼が受諾される。

Description

インターネットなどのパケット交換ネットワーク上で様々なタイプの通信を実装でき、これにはボイス・オーバー・ＩＰ（ＶｏＩＰ）などのパケットベースのボイスまたはビデオ呼及びインスタントメッセージング（ＩＭ）チャットセッションなどのテキストベースの通信が含まれる。それぞれが異なるタイプの通信を用いる様々な通信システムもある。例えば、一通信システムはＶｏＩＰまたはＶｏＩＰとＩＭの両方を提供するが、他の一システムはＩＭのみを提供し、異なる非互換プロトコルによりＶｏＩＰを提供する。

ネットワーク上で実装された異なる各通信システムは、それ自体のユーザグループ（ｓｅｔ ｏｆ ｕｓｅｒｓ）（ユーザベース）を有し、これはユーザ名その他のユーザ識別子の体系により識別される。異なる各通信システムは、それぞれのユーザベースのユーザのユーザ端末にインストールするクライアントアプリケーションを提供し、ユーザが通信システムにアクセスできるようにする。例えば、ユーザは、例えば、自分のユーザ端末上でＶｏＩＰまたはＶｏＩＰとＩＭを提供する第１の通信システムのクライアントアプリケーションのインスタンスをインストールして、第１の通信システム内で自分を一意的に識別するユーザ名その他の識別子を取得するため、第１の通信システムに登録する。ユーザは、この一意的な識別子（及び、潜在的に、パスワードや認証証明書などのその他の認証情報）に基づき第１の通信システムにアクセスし、ユーザ名または識別子に基づき識別された他のユーザと、もし当該ユーザがユーザのコンタクト相手（ｃｏｎｔａｃｔ）となることに同意していれば、通信できる。同様に、ユーザは、例えば、自分のユーザ端末上でＩＭのみを提供する第２の通信システムのクライアントアプリケーションのインスタンスをインストールして、第２の通信システム内で自分を一意的に識別するユーザ名その他の識別子を取得するため、第２の通信システムに登録する。ユーザは、この一意的な識別子（及び、潜在的に、パスワードや認証証明書などのその他の認証情報）に基づきアクセスでき、第２の通信システムを用いてコンタクト相手と通信できる。

ユーザは、二以上の異なる通信システムに登録し、それぞれのユーザ名または識別子を有してもよい。通信システムに登録してユーザ名その他の識別子を取得したユーザは、その通信システムにアカウント（多くの通信システムが無料なので、これは必ずしも金銭的な意味ではない）を持つと言う。今日では、異なる通信システムのアカウントをリンクすることも可能である。例えば、第１の通信システムのユーザが、第２の通信システムのアカウントも有し、これらのアカウントをリンクして、第２の通信システムのコンタクト相手（ｃｏｎｔａｃｔｓ）が第１の通信システムのクライアントに見えるようにできる。ユーザは、第１の通信システムのクライアントを用いて、第２の通信システムのコンタクトのクライアントを介して、コンタクト相手と通信できる。

このようなシナリオでは、一システム（例えば、ＶｏＩＰ）のユーザは、関連する通信タイプを処理できるクライアントを有していない（例えば、今のところＩＭユーザであるため、ＶｏＩＰ対応のクライアントをインストールしていない）他の一ユーザを発呼（ｃａｌｌ）することを試みてもよい。この場合、呼を受けたユーザ（被発呼者）には、呼を受けられるようにするため、ＶｏＩＰアプリケーションのインスタンスをダウンロードしインストールする（例えば、自分のウェブブラウザにプラグインするプラグインアプリケーションをインストールする）オプションが与えられる。その間にも、発呼しているユーザ（発呼者）は、被発呼者が新しいプラグインをインストールしており、インストールが完了したら折り返し発呼する旨のメッセージを提示されるだけである。

一般的に、被発呼者の端末が着呼を受ける準備ができていない理由は他にもある。

本開示によると、発呼者と被発呼者との間に、呼確立要求とそれに対応する呼受諾応答とを含む呼フローに基づいて、音声またはビデオ呼を確立する。例えば、これはＶｏＩＰ呼、またはパケット交換ネットワーク上での他のパケットベースの音声またはビデオ呼であってもよい。第１の呼確立要求が、この第１の呼確立要求の受信時に、この呼を受諾する準備ができていない被発呼端末（被発呼者のユーザ端末）に送信される。例えば、被発呼端末は、呼を行う前に、プラグインなどの補足的ＶｏＩＰアプリケーションをダウンロード及び／またはインストールしなければならず、またはバックグラウンド状態からウェークアップしなければならない。

しかし、被発呼端末が呼を受諾する準備ができると、呼受諾応答ではなく、呼に対するリバース呼確立要求を被発呼端末から受信する。これを処理するため、発呼端末（発呼者のユーザ端末）において実施される適切に構成された発呼エンジンを設ける。この発呼エンジンは、発呼者に代わってリバース呼確立要求を自動的に受諾するが、リバース呼確立要求を一定の制限時間内に被発呼端末から受信（ｒｅｃｅｉｖｅｄ ｂａｃｋ）したことを条件とするように構成される。そうすると、被発呼端末に呼受諾応答のインスタンスを送信することにより、呼が受諾される。呼は関連ネットワーク上で行われ得る。

本欄では、発明の詳細な説明で詳しく説明するコンセプトの一部を選んで、簡単に説明する。本欄は、特許を請求する主題の重要な特徴や本質的な特徴を特定するものではなく、特許を請求する主題の範囲を限定するものでもない。請求項の主題は背景技術欄に記載した欠点の一部または全部を解決する実施形態に限定されない。

本開示をよく理解し、実施形態において本開示をどのように実施するか示すため、一例として添付した図面を参照する。図面中、
通信ネットワークを示す概略図である。 ユーザ端末を示す概略ブロック図である。 発呼者のユーザ端末の要素を示す概略ブロック図である。 被発呼者のユーザ端末の要素を示す概略ブロック図である。 関連呼フローの模式的表現を含む通信ネットワーク上で実施されたリンクされた２つの通信システムの要素を示す概略ブロック図である。

本開示の実施形態は、第１のユーザベースと、音声及び／またはビデオ呼及びＩＭチャットへのアクセスを提供する第１の通信クライアントアプリケーションとに基づくインターネットなどのパケットベースネットワーク上で実施される第１の通信システムと、第２のユーザベースと、それ自体はＩＭチャットへのアクセスのみを提供する（または、少なくとも、それ自体は音声またはビデオ呼へのアクセスは提供しない、またはそれ自体は第１の通信システムと互換性を有する音声またはビデオ呼へのアクセスを提供しない）第２の通信クライアントアプリケーションとに基づくパケットベースネットワーク上で実施される第２の通信システムとに関する。実施形態では、第２のＩＭのみに対応した（ＩＭ−ｏｎｌｙ）システムはレガシー（ｌｅｇａｃｙ）ＩＭシステムであると考えられ、第２のＩＭのみに対応したクライアントはレガシーＩＭクライアントであると考えられる（ＶｏＩＰとＩＭを両方とも扱う第１の通信システム及び第１のクライアントとは対照的である）。

例えば、遠端でプラグインをダウンロードすることが必要であるため、すぐには呼を受けられないエンドポイントを第１のクライアントが発呼した場合、遠端クライアントは、バックグラウンド化（ｂａｃｋｇｒｏｕｎｄｅｄ）され、第１のクライアントから呼要求を受信するのに応じて、リバース呼（ｒｅｖｅｒｓｅ ｃａｌｌ）確立要求を送信する。第１のクライアントにおいて、リバース呼要求を受信すると、そのリバース呼要求メッセージを所定時間内に受信したときには、自動的にその呼を受け付け、元の発呼者により開始された呼セットアップフロー中に、認証情報チェックとダウンロードを行う。

実施形態では、レガシーＩＭユーザはＶｏＩＰクライアントにアップグレードするように勧誘される。ＶｏＩＰクライアントは、主要なコンシューマー向けの機能が充実した通信アプリケーションとなる。ネットワークの社会的中心が動くと、ＩＭの世界はこれらのハブコンタクト相手とのオーディオ・ビデオ機能を事実上失う。そうすると、（すべてのユーザが移行するまで、劣っていると見なされるので）残りのネットワークの崩壊、不要な混乱、移行割合の低下などにつながる。統合サービスは、不都合な点を制限する役に立ち、第１のＶｏＩＰ通信システムへの移行を加速する。これは、移行したユーザでもレガシーＩＭユーザに発呼（ｃａｌｌ）できるというウェブベースの発呼体験を提供することにより、行える。

統合サービスは、以前ＶｏＩＰを使っていなかったユーザや、以前は第１の通信システムのユーザでなかったユーザが、ブラウザをプラグインとともに用いて、ビデオ及びオーディオの呼をできるようにする。この体験によりユーザはフルクライアントをダウンロードして使うよう促される。既存のＶｏＩＰクライアントのユーザは、話したいと思う、ＩＭシステムメッセージングクライアントのコンタクト相手もいるかも知れない。高レベルでは、ＶｏＩＰユーザ（招待主すなわち発呼者）は、コンタクト相手がオンラインであるとわかり、一定の条件がそろうと、コンタクト相手とビデオ呼を開始することができなければならない。コンタクト相手（被招待者すなわち被発呼者）は、適当なＶｏＩＰクライアントがアクティブでない場合、ウェブブラウザを用いて発呼できるプラグインのダウンロードをトリガーしインストールするＵＲＬを送信できる。

図１は、第１と第２の通信システムを実装できるパケット交換ネットワーク１０１を、実施形態ではインターネット等のワイドエリアインターネットワークを示す図である。ネットワーク１０１は、一以上の第１のサーバ１０４ｉを有する第１の通信システムのインフラストラクチャと、一以上のサーバ１０４ｉｉを有する第２の通信システムのインフラストラクチャとを有する。また、ネットワーク１０１に接続されて、第１のユーザ端末１０２ａと第２のユーザ端末１０２ｂを含む複数のユーザ端末がある。各ユーザ端末は、例えば、デスクトップコンピュータの、または携帯電話、タブレット、またはラップトップコンピュータなどの携帯ユーザ端末の形式である。図１にはタブレットとラップトップを示したが、これは例示を目的としたものであり、それぞれはどんな種類のユーザ端末であってもよい。下記の例を目的として、第１のユーザ端末１０２ａは（発呼者の）発呼端末であり、第２のユーザ端末１０２ｂは（被発呼者の）被発呼端末である。

図２は、ユーザ端末１０２を示すブロック図であり、第１のユーザ端末１０２ａと第２のユーザ端末１０２ｂに見いだされるコンポーネントを示している。ユーザ端末１０２は、一以上の実行部を有するプロセッサ２０４の形式の処理装置と、電子的記憶媒体及び／または磁気的記憶媒体などの一以上の記憶媒体を有するメモリ２０２の形式の記憶手段とを有する。ユーザ端末１０２は、複数の入出力（Ｉ／Ｏ）デバイス、すなわち、例えばマイクロホン２０８、スピーカ２１０、ビデオカメラ２１４及び／または画面２１４など（それぞれ端末１０２の内部または外部にあるもの）も有する。さらに、ユーザ端末１０２は、他のユーザ端末１０２と、及び第１と第２の通信システムのサーバ１０４ｉ、１０４ｉｉと、パケット交換ネットワーク１０１により通信する一以上の送受信デバイスを有する。一以上の送受信デバイスは、無線ローカルエリアネットワークの無線ルータ無線アクセスポイントを介してネットワーク１０１に接続するＷｉＦｉその他の短距離ローカル送受信器２０８と、電話の地上通信線またはケーブル接続などの有線接続を介してネットワーク１０１に接続する内部モデム２１６と、セルラ基地局（ｎｏｄｅＢと呼ぶこともある）を介してネットワーク１０１に接続する３ＧＰＰ送受信器などのセルラ送受信器と、外部モデムを介してネットワーク１０１に接続するＵＳＢインタフェースその他の外部インタフェースとのうちの一以上を有し得る。メモリ２０２、Ｉ／Ｏデバイス２０８，２１０，２１２，２１４，及び一以上の送受信器２０６，２１６，２１８，２２０は、それぞれプロセッサ２０４と動作可能に結合している。

メモリ２０２は、プロセッサ２０４で実行されるように構成されたコンピュータ読み取り可能コードを記憶している。これには、オペレーティングシステムと、そのオペレーティングシステムの制御下で実行され、一般的にはオペレーティングシステムにより実行のスケジューリングがされる一以上のアプリケーションとが含まれる。第１と第２の端末１０２ａ、１０２ｂのそれぞれにおいて、それぞれのメモリ２０２は、パケット交換ネットワーク１０１により、例えば、インターネットにより実装された通信システムを用いて他のユーザ端末と通信する少なくとも１つの通信クライアントを有する。

図３は、第１のユーザ端末１０２ａ上で実行されるように構成されたオペレーティングシステムとアプリケーションを例示している。第１の端末１０２ａは、オペレーティングシステム３０２と、そのオペレーティングシステム３０２の制御下で実行される、第１の通信システムの通信クライアントアプリケーションである第１のクライアントアプリケーション３１０のインスタンスと、任意的に、一以上の他のアプリケーション３０４、例えば、ウェブブラウザ、電子メールクライアント、及び／またはビデオゲームとを有する。アプリケーション３０４、３１０は、オペレーティングシステム３０２により第１の端末１０２ａのプロセッサ２０４上で実行するスケジューリングがされ、例えば、複数のアプリケーションが、インターリーブされ、及び／またはプロセッサの異なるスレッドまたは実行ユニットを用いて、並行して実行されるようスケジューリングされる。

第１のクライアント３１０は、パケット交換ネットワーク１０１により音声及び／またはビデオの符号化と伝送をするためのユーザインタフェース（ＵＩ）レイヤ３１６、クライアントエンジン３１４、及びオーディオ及び／またはビデオ（Ａ／Ｖ）レイヤを有する。例えば、Ｈ２６３やＨ２６４などの適当な符号化標準を用いて符号化し、ＶｏＩＰなどの適当なパケットベースの方法を用いて伝送するため、符号化したビデオをパッケージングする。クライアントエンジン３１４は、少なくとも、第１の通信システムを用いて他のユーザ端末と呼を確立するための呼設定シグナリング（ｃａｌｌ ｓｅｔ−ｕｐ ｓｉｇｎａｌｌｉｎｇ）をする役割を果たす発呼エンジンを有する。発呼エンジンは、２つの区別できるメッセージタイプ（呼確立要求（ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ ｒｅｑｕｅｓｔ）とそれに対応する呼受諾応答（ｃａｌｌ ａｃｃｅｐｔａｎｃｅ ｒｅｓｐｏｎｓｅ））を用いる呼確立イベントの発呼フロー（ｃａｌｌ ｆｌｏｗ）を確定する呼設定プロトコルで設定されている。

クライアントエンジン３１４とＡ／Ｖレイヤ３１２とを用いて、第１のユーザ端末１０２ａ上で実行された第１のクライアント３１０は、第１の通信システム（例えば、ＶｏＩＰ）を用いて、第１の端末１０２ａの送受信器２０６、２１６、２１８、２２０のうちの１つと、パケット交換ネットワーク１０１とを介して、他のユーザ端末上のクライアントと通話（ｃａｌｌｓ）できる。すなわち、ライブの、リアルタイムの通話（ｐｈｏｎｅ ｃａｌｌｓ）をできる。以下、ＶｏＩＰについて説明するが、言うまでもなくこれは単なる例である。

実施形態では、第１のクライアント３１０がＩＭと音声及びビデオ通話（ｖｏｉｃｅ ａｎｄ ｖｉｄｅｏ ｃａｌｌｓ）の機能も有しているとき、クライアントエンジンは、第１の通信システムを用いてＩＭシグナリングするためのプロトコル（第２の通信システムのＩＭと互換性を有していてもよいが、必ずしも互換である必要はない）も有する。

さらに、第１のＶｏＩＰクライアント３１０のクライアントエンジン３１４は、タイマー３１７を有し、その機能は後で詳細に説明する。

図４は、第２のユーザ端末１０２ｂ上で実行されるように構成されたオペレーティングシステムとアプリケーションを例示している。第２の端末１０２ｂは、オペレーティングシステム３１８と、そのオペレーティングシステム３１８の制御下で実行される、（第２の通信システムの通信クライアントアプリケーションである）第２のクライアントアプリケーション３２０のインスタンスと、任意的に、ウェブブラウザ３２４、補足的ＶｏＩＰアプリケーション（ＶｏＩＰプラグインなど）、及び／またはその他の一以上のアプリケーション３２６（電子メールクライアント及び／またはビデオゲームなど）を有する。アプリケーション３２０、３２２、３２４、３２６は、オペレーティングシステム３１８により第２の端末１０２ｂのプロセッサ２０４上で実行するスケジューリングがされ、例えば、複数のアプリケーションが、インターリーブされ、及び／またはプロセッサの異なるスレッドまたは実行ユニットを用いて、並行して実行されるようスケジューリングされる。

第２のユーザ端末１０２ｂのプロセッサ２０４上で実行された時、第２のクライアントは、第２のユーザ端末１０２ｂの送受信器２０６、２１６、２１８、２２０のうちの１つと、パケット交換ネットワーク１０１とを介して、第２の通信システム（例えば、レガシーＩＭシステム）により、他のユーザ端末と、ライブ通話（ｌｉｖｅ ｃａｌｌｓ）以外に通信（ＩＭチャットセッションなど）をできる。以下、ＩＭについて説明するが、言うまでもなくこれは単なる例である。

補助的ＶｏＩＰアプリケーション３２２は、最初は無かったりアクティブでなかったりするが、第１の端末１０２ａからの呼要求の着信（ｉｎｃｏｍｉｎｇ ｃａｌｌ ｒｅｑｕｅｓｔ）に応じて、ダウンロード及び／またはインストールできる。補足的ＶｏＩＰアプリケーション３２２は、第１のクライアント３１０のものと互換性を有する発呼エンジンとＡ／Ｖレイヤとを有し、第２のユーザ端末１０２ｂ上にインストールされ実行された時、第１の通信システムを用いて、それぞれの送受信器とパケット交換ネットワーク１０１とを介して、他のユーザ端末上のクライアントと、一以上のライブの音声またはビデオ通話を行える。これは、少なくとも、第１の端末１０２ａ上の第１のクライアント３１０とのライブの音声またはビデオ通話（ｖｏｉｃｅ ｏｒ ｖｉｄｅｏ ｃａｌｌ）を含むが、実施形態では、補足的ＶｏＩＰクライアント３２２も第２の端末１０２ｂのユーザに他の端末の他のユーザと通話できるようにするように構成され、着信（ｉｎｃｏｍｉｎｇ ｃａｌｌ）によりトリガーされたインストールの後に、このユーザとそのユーザ端末１０２ｂは、第２の通信システムに加えて（またはその替わりに）第１のＶｏＩＰ通信システムに組み込まれる。実施形態では、補足的ＶｏＩＰアプリケーション３２２は、第２の端末１０２ｂ上のアプリケーション（例えば、ウェブブラウザ２２４など）へのプラグインとして提供されるが、スタントアロンアプリケーションでもよい。以下、ウェブブラウザ３２４へのプラグインに関して説明するが、言うまでもなくこれは単なる例である。

ここで図５を参照する。図５は、第１と第２の通信システム間の統合に関わる様々な要素を示すブロック図であり、これらのコンポーネントに関連する対応呼フロー（ｃａｌｌ ｆｌｏｗ）も示している。

第１の通信システムのインフラストラクチャは、第１の通信システムの一以上のサーバ１０４ｉ上に実装される統合サービス（ｉｎｔｅｇｒａｔｉｏｎ ｓｅｒｖｉｃｅ）５０２と、実施形態では第１の通信システムの一以上のサーバ１０４ｉ上に実装される呼インフラストラクチャ５０４とを有する。別の一実施形態では、呼インフラストラクチャは、その他の複数のユーザ端末１０２に分散したピア・ツー・ピアインフラストラクチャとして、またはサーバベース及びピア・ツー・ピアのトポロジを組み合わせて（ｍｉｘ）実装できる。しかし、一実施形態として、以下、呼インフラストラクチャ５０４について完全にサーバベースのトポロジに関して説明する。

統合サービス５０２と呼インフラストラクチャ５０４はそれぞれ、パケット交換ネットワーク１０２と、第１のユーザ端末１０２ａの送受信器２０６、２１６、２１８、２２０のうちの１つとを介して、第１のユーザ端末１０２ａ上の第１のＶｏＩＰクライアント３１０のクライアントエンジン３１４に、動作可能に結合されている。統合サービス５０２は、パケット交換ネットワーク１０１と、第２のユーザ端末１０２ｂの送受信器２０６、２１６、２１８、２２０のうちの１つとを介して、第２のユーザ端末１０２ｂ上の第２のレガシーＩＭクライアント３２０に動作可能に結合されている。呼インフラストラクチャ５０４は、インストールされると、パケット交換ネットワーク１０２と、第２のユーザ端末１０２ｂの送受信器２０６、２１６、２１８、２２０のうちの１つとを介して、第２のユーザ端末１０２ｂ上のＶｏＩＰプラグイン３２２に動作可能に結合されている。

第２の通信システムのインフラストラクチャは、第２の通信システムの一以上のサーバ１０４ｉｉに実装されたレガシーＩＭサーバシステムを有する。レガシーＩＭサーバシステムは、パケット交換ネットワーク１０１と第１のユーザ端末１０２ａの送受信器２０６、２１６、２１８、２２０のうちの１つとを介して、第１のユーザ端末１０２ａ上の第１のＶｏＩＰクライアント３１０のクライアントエンジン３１４に動作可能に結合され、パケット交換ネットワーク１０１と第２のユーザ端末１０２ｂの送受信器２０６、２１６、２１８、２２０のうちの１つとを介して、第２のユーザ端末１０２ｂ上の第２のレガシーＩＭクライアント３２０に動作可能に結合される。

これらの要素が実行するように構成される動作を、図５に示したステップＳ１０ないしＳ７０を参照して、例として説明する。

ステップＳ１０の始めに、被発呼者（ｃａｌｌｅｅ）は、例えば、オペレーティングシステム３０２のデスクトップ上で実行されている第１のユーザ端末１０２ａ上の第１のＶｏＩＰクライアント３１０にログインする。被発呼者は、第１の通信システムの自分のユーザ名その他のユーザ識別子（及びパスワードなどのその他の任意の認証情報）を含む、第１のＶｏＩＰ通信システムの自分の認証情報（ｃｒｅｄｅｎｔｉａｌｓ）でログインできる。

被発呼者は、第２のレガシーＩＭ通信システムにリンクしたＶｏＩＰ通信システムに自分のアカウントを有している。実施形態では、これは、レガシーＩＭシステムにおいてユーザ名またはその他の識別子を有する発呼者も含み、ＶｏＩＰシステムの発呼者のユーザ名または識別子と、レガシーＩＭシステムにおける同じ発呼者のユーザ名または識別子との間にはマッピングが設けられている。発呼者のＶｏＩＰアカウントはレガシーＩＭシステムにリンクされているので、これによりＶｏＩＰクライアント３１０は、レガシーＩＭシステムにおける被発呼者のコンタクト相手リストにアクセスできる。発呼者のＶｏＩＰクライアント３１０は、それらのコンタクト相手のプレゼンス情報（ｐｒｅｓｅｎｃｅ ｉｎｆｏｒｍａｔｉｏｎ）にもアクセスできる。プレゼンス情報は、どのコンタクト相手がオンラインまたはオフラインか、または連絡不可（ｕｎａｖａｉｌａｂｌｅ）を選択しているかを示す。実施形態では、プレゼンス情報は、呼フローで用いる他の情報も含む。これは後で詳しく説明する。ＩＭレガシーシステムのユーザ識別子、コンタクト相手リスト、アカウントをリンクするマッピング、及び／またはプレゼンス情報は、レガシーＩＭサーバシステム１０４ｉｉに記憶され、発呼者のＶｏＩＰクライアント３１０によりそこからアクセスすることができる。

このように、ステップＳ１０において、第１の端末１０２ａ上の発呼者のクライアントアプリケーション３１０は、レガシーＩＭサーバシステム１０４ｉｉにアクセスして、レガシーＩＭシステムから一以上のコンタクト相手のユーザ名またはその他の識別子と、任意的に一以上のコンタクト相手のプレゼンス情報の一部または全部を取得する。

ステップＳ２０において、発呼者は、レガシーＩＭシステム上にいる一以上のコンタクト相手、すなわち被発呼者の１人と話すことを選択する。それがトリガーになり、発呼者のクライアント３１０が、ネットワーク１０１を介して統合サービス５０２にシグナリングし、呼要求リファレンス（ｃａｌｌ ｒｅｑｕｅｓｔ ｒｅｆｅｒｅｎｃｅ）を生成する。これは、統合サービス５０２において少なくとも一時的に記憶され、被発呼者の端末１０２ｂ上のレガシーＩＭクライアント３２０に対して利用可能にされる。

ステップＳ３０において、また発呼者のクライアント３１０は、第１の呼確立要求を、被発呼者の端末１０２ｂ上のレガシーＩＭクライアント３２０に送信する。実施形態では、この第１の呼確立要求は、ネットワーク１０１により、レガシーＩＭサーバシステム１０４ｉｉを介して送信でき、または代替的に、ネットワーク１０１により直接送信してもよい。

実施形態では、発呼者の端末１０２ａ上の発呼者クライアント３１０により生成された第１の呼確立要求は、被発呼者端末１０２ｂ上のレガシーＩＭクライアント３２０を、プラグイン３２２などの補足的ＶｏＩＰアプリケーションをダウンロード及び／またはインストールさせるように構成された特性を有する。これは、被発呼者端末がプラグイン３２２を取得できるネットワークアドレスを指定する、第１の呼確立要求中に含まれるリンク（例えば、インターネットアドレスを指定するＵＲＬなどのパケット交換ネットワーク１０１上のアドレスを（この場合、ＤＮＳなどの適当なアドレスルックアップを介して代わりに）指定するリンク）により行える。発呼者端末１０２ａの発呼者クライアント３１０によりリンクを直接挿入してもよいし、発呼者端末から送信された第１の呼要求が、レガシーＩＭサーバシステム１０４ｉｉに適当なリンクを挿入させる信号を含んでいてもよい。別の一実施形態では、被発呼者クライアント３２２または端末１０２ｂがプラグインのロケーションを事前に知っていれば、リンクは必要ない。他の一実施形態では、ダウンロードは必要ないかも知れない。例えば、被発呼者端末１０２ｂには潜在的にまだインストールされていないプラグイン３２２がすでに記憶されていて、被発呼者端末１０２ｂ上で実行するためには、インストール（例えば、解凍も含む）だけすればよく、ダウンロードしなくてもよいかも知れない。

被発呼者端末１０２ｂにおいて第１の呼確立要求を受信した時、ダウンロード及び／またはインストール（ｉｎｓｔａｌｌａｔｉｏｎ）の起動は完全に自動であってもよいし、ユーザにＶｏＩＰプラグイン３２２をダウンロード及び／またはインストールをするかマニュアル選択するように問うプロンプトの表示を含んでいてもよい。マニュアルプロンプトの場合、これは被発呼者が呼に応えたいか問うプロンプトと同じであってもよい。被発呼者のレガシーＩＭクライアント３２０は、第１の呼確立要求に適宜反応するように構成されている。

ステップＳ４０において、被発呼者は、（マニュアルプロンプトが関わる場合）クリックするか、その他の方法で、第１の呼確立要求により起動された動作（ａｃｔｉｖｉｔｙ）を選択する。これにより、レガシーＩＭシステムにログインし、発呼者と被発呼者に関する識別子情報を有するＩＭクライアント３１０中の内部ブラウザが開く。あるいは、ダウンロード及び／またはインストールは、被発呼者からのマニュアル入力を必要とせずに、完全に自動で生じてもよい。

実施形態では、発呼者クライアントからの第１の呼確立要求は、第１のＶｏＩＰ通信システム中の被発呼者のユーザ名またはその他の識別子の生成を起動するように構成され、それにより被発呼者がＶｏＩＰ通信システムにアクセスで、（少なくとも発呼者と）通話をできる特性を有するように構成されていている。再び、この起動は、被発呼者クライアント３２０による第１の呼確立要求の受信時に完全に自動的に行われても良いし、被発呼者に提示されるマニュアルユーザプロンプトを介して行われても良い（例えば、これは、ダウンロード及び／またはインストールをするか問うのと同じプロンプトであってもよいし、被発呼者に、呼に応えたいか問うのと同じプロンプトであってもよいし、別のプロンプトであってもよい）。ＶｏＩＰ通信システムにおいて被発呼者を識別する被発呼者の新しい識別子は、レガシーＩＭシステムにおけるその被発呼者のアイデンティティ（ｉｄｅｎｔｉｔｙ）にリンクしている（例えば、１０４ｉ及び／または１０４ｉｉなどのサーバにおけるマッピングによる）。幾つかの実施形態では、新しい識別子は、自動的に生成及びリンクされ、被発呼者はこれを見る必要はなく、両方のシステムで古いユーザ名または識別子を、外見上シームレスに統合されたかのように、利用し続けることができる。

ステップＳ５０において、被発呼者端末１０２ｂ上のブラウザ３２４は、統合サービス５０２で、呼要求参照（ｃａｌｌ ｒｅｑｕｅｓｔ ｒｅｆｅｒｅｎｃｅ）を確認（ｖｅｒｉｆｙ）する。代替的実施形態では、統合サービス５０２で参照を確認するステップは省略することもできるし、代替的な確認装置（ｖｅｒｉｆｉｃａｔｉｏｎ ａｒｒａｎｇｅｍｅｎｔｓ）を導入することもできる。

必要な確認がうまくいけば、ステップＳ６０において、被発呼者端末１０２ｂでＶｏＩＰプラグイン３２２がインストールされる。

ステップＳ７０において、プラグイン３２２は、標準ＶｏＩＰ呼インフラストラクチャ５０２を用いて、発呼者端末１０２ｂ上に発呼者ＶｏＩＰクライアント３１０に、コールバック（ｃａｌｌ ｂａｃｋ）を開始する。コールバックは、呼設定プロトコルの呼受諾応答の返信は含まず、新しくインストールされたＶｏＩＰクライアント３２２から返送される他の呼設定プロトコルの呼確立要求を含む。実施形態では、プラグイン３２２は、前のステップで取得した（例えば、ステップＳ３０の第１の呼設定要求に含まれていた、またはステップＳ２０とＳ５０で提供された参照から取得した）、第１の通信システムにおいて発呼者を識別するユーザ名その他の識別子に基づいて、発呼者端末１０２ａに要求を送信できる。プラグイン３２２は、第１のＶｏＩＰ通信システムにおける発呼者のユーザ名または識別子と、ユーザ名をアドレスにマッピングする呼インフラストラクチャ５０４とを用いたアドレスルックアップ（ａｄｄｒｅｓｓ ｌｏｏｋ ｕｐ）に基づき、パケット交換ネットワーク１０１上の発呼者のネットワークアドレス（例えば、ＩＰアドレス）を発見できる。このコールバックは、完全に自動的であっても、被発呼者の確認を求めるマニュアルプロンプトを含むものであってもよい。マニュアルプロンプトの場合、これは、プラグイン３２２をダウンロード及び／またはインストールし、新しいユーザ名を生成するのと同じプロンプトであってもよいし、被発呼者に、その呼に応えたいか問うのと同じプロンプトであってもよいし、あるいは、別のプロンプトであってもよい。

このように、発呼者端末１０２ａ上のＶｏＩＰクライアント３１０のクライアントエンジン３１４は、被発呼者端末１０２ｂ上のプラグイン３２２から、リバース呼（ｒｅｖｅｒｓｅ ｃａｌｌ）確立要求の返信を受ける。クライアントエンジン３１４は、呼設定（ｃａｌｌ ｓｅｔ−ｕｐ）を完了するため、これを受けなくてはならない。ここに開示した実施形態では、クライアントエンジン３１４は、タイマー３１７を有し、このタイマー３１７を用いて、所定制限時間以内に被発呼者端末１０２ｂから返信されることを条件に、リバース呼確立要求で指定された呼を自動的に受けるように構成されている。呼を受けると、発呼者クライアント３１０のクライアントエンジン３１４は、被発呼者端末１０２ｂ上のプラグイン３２２に呼受諾応答（ｃａｌｌ ａｃｃｅｐｔａｎｃｅ ｒｅｓｐｏｎｓｅ）を自動的に送信し、こうして呼が確立される。ＶｏＩＰクライアント３１０と３２２はそれぞれ発呼者と被発呼者にこの趣旨の表示を出力するように構成されている。呼は、関連するＩ／Ｏデバイス２０８、２１０、２１２及び／または２１４により進行する。

実施形態では、この呼のセッションは、呼と同時に設定され、すなわち、セッション確立要求と受諾応答が、それぞれリバース呼確立要求と呼受諾応答とともに交換される。

プロセス中、例えば、被発呼者端末１０２ｂがプラグイン３２２をダウンロードしインストールするのを待っている間に、実施形態では、発呼者クライアント３１０は、リバース呼確立プロセスを含まない従来の電話発信でするように、同じ電話発信（「リンギング」）メッセージまたはインジケーションを表示する。プロセスは被発呼者側でも自動化されるので、呼に、他の呼と何らかの違いがあることを知る必要がある発呼者から完全に隠すこともできる。例えば、発呼者は、被発呼者が新しいクライアント３２２をダウンロードまたはインストールしており、または新しいユーザ名を生成していることを知る必要はなく、システムは、発呼者に対して、通常の呼に対して被発呼者が応えるのを単に待っているように見せかける。

所定制限時間は、発呼者またはそのＶｏＩＰクライアント３１０による呼フロー（ｃａｌｌ ｆｌｏｗ）の勧め（ｉｎｓｔｉｇａｔｉｏｎ）から、例えば、発呼者によるクライアント３１０のユーザインタフェースにおけるコントロールの選択から、またはクライアント３１０による第１の呼確立要求の生成または送信から、またはかかるイベントに関する他の適当な時点から測る。所定制限時間は一定であってもよいし、発呼者により、または第１のＶｏＩＰ通信システムのプロバイダーにより設定された（例えば、クライアント３１０のインタフェースを介して設定された）、設定であってもよい。実施形態では、制限時間は３０秒ないし９０秒であり、これは一般的にユーザががまんできる範囲を表している。一実施形態では、制限時間は６０秒である。

発呼側の近端端末において他の着信呼要求を受信した場合、遠端はｒｅａｄｙではなく、元の要求には単純なａｃｃｅｐｔａｎｃｅで応えられないので、第２の呼要求が、同じ呼フローの一部として、一定の時間ウィンドウ内に到着すれば、近端端末により自動的に受諾される。すなわち、発信元の発呼者は、コールバック要求を、所定時間内に受信すれば、自動的に受諾し、発信元の発呼者には一回の呼設定の一部であるように見える。

そうでなく、リバース呼確立要求を制限時間内に受け取らなければ、発呼者クライアント３１０のクライアントエンジンは、呼をタイムアウト（ｔｉｍｅ ｏｕｔ）とし、呼確立の試みは失敗する。発呼者クライアント３１０は、発呼者に、その旨のメッセージその他の表示を提示するように構成されていてもよい。実施形態では、発呼者には、単に被発呼者が呼に応えなかったように見える。

上記の通り、実施形態では、発呼者端末１０２ａ上のＶｏＩＰクライアント３１０のクライアントエンジン３１４は、被発呼者端末１０２ｂのプレゼンス情報にアクセスできる。これは、被発呼者端末１０２ｂが現在、呼を受ける準備ができているかに関する情報を含む。代替的または追加的に、プレゼンス情報は、被発呼者端末１０２ｂ上の第２のレガシーＩＭクライアント３２０が、リバース呼確立に基づき上で説明した種類のプロセスをサポートしているか、例えば、プラグイン３２２へのリンク時に、または第１の呼確立要求におけるかかる他の起動時に動作することができるか、またはかかるリンクまたは起動は認識されない。

かかるプレゼンス情報を用いて、発呼者端末上のクライアント３１０のクライアントエンジン３１４は、その振る舞いを適宜適合するように構成され得る。例えば、プレゼンス情報から被発呼者側が関連プロセスをサポートしていないと判断すると、被発呼者端末１０２ｂにおいてプラグイン３２２のダウンロード及び／またはインストールを起動する上記種類の第１の呼確立要求のインスタンスを送信する。他方、発呼者クライアント３１０がプレゼンス情報から、かかるプロセスがサポートされていない、または被発呼者端末１０２ｂが呼を受けられる（例えば、適当なＶｏＩＰクライアントがインストールされている）ため、かかるプロセスが必要ないと判断すると、発呼者クライアント３１０は従来の種類の呼確立要求を送信し得る。

さらに別の代替的または追加的実施形態では、発呼者クライアント３１０は、プレゼンス情報から、コールバックプロセスがサポートされている、及び／または第１の要求が送信された時に被発呼者端末が準備できていないと判断すると、自分の状態を適宜適合させられる。すなわち、被発呼者端末１０２ｂからメッセージを受信すると、タイミング条件を適用することを含む自動受諾プロセスを適用することを知っている。他方、発呼者クライアント３１０が、プレゼンスから、第１の要求が送信された時に、被発呼者端末の準備ができている（例えば、適切なＶｏＩＰクライアントがすでにインストールされている）と判断すると、被発呼者端末１０２ｂからメッセージを受信（ｒｅｃｅｉｖｅｄ ｂａｃｋ）した時、自動受諾プロセスや時間条件は適用しない。

言うまでもなく、上記の実施形態は単なる例として説明したものである。

例えば、本開示は、被発呼者クライアントが、適切な音声またはビデオ発呼クライアントアプリケーションをインストールされていないため、呼を受ける準備ができていない場合には限定されない。他の一シナリオでは、発呼者と被発呼者がそれぞれのユーザ端末にインストールされた同じ通信システムのクライアントのインスタンスを有していても（例えば、両者が互換性のあるＶｏＩＰクライアントを有していても）、発呼者は、被発呼者がバックグラウンド状態にあり、その呼をすぐには取れない時に、発呼を試みるかも知れない。オペレーティングシステムは、その制御下で通信クライアントなどのアプリケーションが実行されるが、アプリケーションをバックグラウンド状態にして、それによりアプリケーションの実行が停止され、またはフォアグラウンド（ｆｏｒｅｇｒｏｕｎｄ）状態と比較して限られた数の処理サイクルしか割り当てられない。この状態では、通信クライアントは、ネットワークポートにアクセスしない。すなわち、入来する呼確立要求を受け取ることができず、または入来する呼確立要求を処理するリソースを有しない。

よって、他の実施形態では、被発呼者端末は、すでに音声またはビデオクライアント（例えば、ＶｏＩＰクライアント）のインスタンス全部がインストールされているが、このクライアントアプリケーションは、停止され、またはフォアグラウンド状態と比較して限られた数のプロセッササイクルをスケジューリングされるバックグラウンド状態（一般的には、アプリケーションが実行されているオペレーティングシステムによりそのアプリケーションはこの状態にされる）になっているため第１の呼確立要求の時に呼を受けることができない。例えば、被発呼者クライアントは、フルスクリーンアプリケーション（例えば、ビデオゲーム）などの他のアプリケーションを優先して、または被発呼者端末がスタンバイモードにパワーダウンされている間に、停止または抑制される。かかるシナリオでは、被発呼者クライアントは、呼を受けることができるようになる前に、ウェークアップしなければならない。実施形態では、第１の呼確立要求は、被発呼者のクライアントが発呼者端末上の発信クライアントにリバース呼確立要求を送信（ｓｅｎｄ ｂａｃｋ）するのに応じて、被発呼者の音声またはビデオ呼クライアントに、バックグラウンド状態からウェークアップさせる。

かかる実施形態では、第１の呼確立要求は、オペレーティングシステムのプッシュ通知サービス（ｐｕｓｈ ｎｏｔｉｆｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ）を介してプッシュ通知のペイロードで配信でき、またはプッシュ通知サービスのプッシュ通知を少なくとも利用して、被発呼クライアントをウェークアップする。プッシュ通知サービスは、プッシュ通知要求が発呼者クライアントなどの他の要素により送信されたときに、ウェークアップさせるバックグラウンド状態のアプリケーションをトリガーする目標オペレーティングシステムへのプッシュ通知を生成する、オペレーティングシステムのプロバイダーにより提供される、またはサポートされるネットワーク要素である。幾つかの場合に、プッシュ通知サービスは、ウェークアップ時にアプリケーションに配信できるペイロードを有する拡張プッシュ通知（ａｕｇｍｅｎｔｅｄ ｐｕｓｈ ｎｏｔｉｆｉｃａｔｉｏｎ）をサポートできる。あるいは、バックグラウンド状態化されたクライアントにまだネットワークポートまたは、要求を受ける（ｌｉｓｔｅｎ）するのに十分なリソースが割り当てられている場合、サーバ１０４ｉまたは１０４ｉｉを介して第１の呼確立要求を配信できる。

他の一変形例では、被発呼者は、第１の通信システムの音声またはビデオ呼クライアントをインストールされているが、そのクライアントにはログインしておらず、例えば、ＩＭシステムなどの第２の通信システムのクライアントにログインしているだけである。その場合、被発呼者がログインすると、リバース呼確立メッセージが送信される。第１の呼確立メッセージは、被発呼者端末をトリガーして、被発呼者にログインするように促す。

さらに、上記の説明は、発呼者端末１０２ａのクライアント３１０において実施される自動受諾プロセスに関するものである。しかし、別の実施形態では、一以上の通信システムの一以上のサーバ１０４ｉ及び／または１０４ｉｉなどの中間ネットワーク要素において実施することもできる。かかる代替案では、中間サーバは、第１の呼確立要求を発呼者端末から受信し、それを被発呼者端末に転送し、サーバで、リバース呼確立要求を受信し、時間条件と自動受諾とをこれに適用する。この中間サーバは、制限時間内に受信すると、呼受諾応答のインスタンスを、発呼者端末と被発呼者端末に送信することにより、呼設定を完了する。

さらに別の実施形態では、第２の通信システムは必ずしもＩＭだけではない。例えば、被発呼者端末は、第１のシステムと互換性がないレガシーＶｏＩＰのクライアントを有してもよい。また、実施形態では、ＩＭ「のみ」とは、ＶｏＩＰを除くことを意味し、ファイル転送などのその他の通信形式を排除する必要はない（ユーザ間の他のすべての通信形式を排除することも可能である）。

統合サービス５０２は、第１のＶｏＩＰ通信システムのインフラストラクチャの一部として上で説明したが、別の実施形態では、統合サービス５０２は、（もしあれば）第２のレガシーＩＭシステムのインフラストラクチャの一部であると考えても良いし、または２つのシステムのインフラストラクチャ間で共有されても良いし、第三者により提供されてもよい。

さらに、ノードＡとＢの間で（例えば、ユーザ端末間またはサーバとユーザ端末間で）呼確立要求または呼受諾応答などのメッセージを送信することは、メッセージの本質的な意味または機能が搬送される限り、メッセージの形式をそれらのノード間で修正したり変換したりできないことを意味するものではない。

一般的に、ここに説明する機能はどれも、ソフトウェア、ファームウェア、ハードウェア（例えば、固定的な論理回路）、またはこれらの組合せで実装できる。ここで用いる「モジュール」、「機能」、「コンポーネント」及び「ロジック」との用語は、一般的に、ハードウェア、ソフトウェア、ファームウェア、ハードウェアまたはこれらの組み合わせを表す。ソフトウェア実装の場合、モジュール、機能、またはロジックは、プロセッサ（例えば、ＣＰＵ）により実行された時、タスクを実行するプログラムコードを表す。プログラムコードは、一または複数のコンピュータ読み取り可能メモリデバイスに格納できる。下記の手法の特徴は、プラットフォームに依存しない。すなわち、これらの手法は様々なプロセッサを有する様々な商業的コンピューティングプラットフォームで実装し得る。

例えば、ユーザ端末は、例えば、プロセッサ、機能ブロックなどのそのユーザ端末のハードウェアに動作を実行させるエンティティ（例えば、ソフトウェア）を含んでいてもよい。例えば、ユーザ端末は、そのユーザ端末に、より具体的にはそのユーザ端末のオペレーティングシステム及び関連ハードウェアに動作を実行させる命令を保持するように構成されたコンピュータ読み取り可能媒体を含んでもよい。このように、命令は、動作を実行するようにオペレーティングシステム及び関連ハードウェアを設定するように機能し、このようにオペレーティングシステム及び関連ハードウェアが機能を実行するように変換する。命令は、異なる様々な構成により、コンピュータ読み取り可能媒体によりユーザ端末に提供される。

コンピュータ読み取り可能媒体のかかる一構成は、信号搬送媒体であり、ネットワークなどを介してコンピューティングデバイスに命令を（例えば、搬送波のように）伝送するように構成される。また、コンピュータ読み取り可能媒体は、コンピュータ読み取り可能記憶媒体として構成でき、信号搬送媒体ではない。コンピュータ読み取り可能記憶媒体の例には、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、光ディスク、フラッシュメモリ、ハードディスクメモリ、及びその他のメモリデバイスであって磁気、光、その他の技術を用いて命令その他のデータを記憶するものが含まれる。

本主題を個別の構造的特徴及び／又は方法動作を用いて説明したが、言うまでもなく、添付した特許請求の範囲に規定する主題は、上記の特定の特徴や動作には必ずしも限定されない。上記の特定の特徴や動作は、請求項を実施する形式例を開示するものである。

Claims (10)

1. 呼確立要求とそれに対応する呼受諾応答とを含む呼フローに基づき、発呼者と被発呼者との間に、ネットワークを介して音声またはビデオ呼を確立する装置であって、
   前記ネットワークを介して通信する送受信器と、
   第１の呼確立要求を受信した時、呼を受ける準備ができていない被発呼端末に第１の呼確立要求を送信するように構成された、前記被発呼端末は被発呼者のユーザ端末である、発呼エンジンと、を有し、
   被発呼端末が呼を受ける準備ができると、前記発呼エンジンは前記被発呼端末から、呼受諾応答ではなく、前記呼に対するリバース呼確立要求を受信し、
   前記発呼エンジンは、リバース呼確立要求を制限時間内に前記被発呼端末から受信することを条件に、被発呼端末に呼受諾応答を送信することにより、前記発呼者に代わって前記リバース呼確立要求を自動的に受けるように構成されている、装置。
2. 前記発呼エンジンは、前記発呼をするクライアントアプリケーションが被発呼端末にインストールされていないとき、被発呼端末に第１の呼確立要求を送信するように構成され、被発呼端末は、呼を受けるために、前記第１の呼確立要求を受信すると、補足的クライアントアプリケーションをダウンロード及び／またはインストールしなければならず、前記第１の呼確立要求は被発呼端末への補足的クライアントのダウンロード及び／またはインストールを起動する、
   請求項１に記載の装置。
3. 第１の呼確立要求は前記補足的クライアントアプリケーションをダウンロードするネットワークロケーションへのリンクを提供する、請求項２に記載の装置。
4. 前記発呼は、第１の通信システムにおいてユーザを識別する第１のユーザ識別子システムに基づいて、前記ネットワーク上に実装された第１の通信システムを用いて行われ、第２の通信システムにおいてユーザを識別する第２のユーザ識別子システムに基づいて、前記ネットワーク上に実装された前記第２の通信システムもあり、前記発呼者は第１のユーザ識別子システムのうちの１つを有する第１の通信システムのユーザであり、前記被発呼者は第２のユーザ識別子システムのうちの１つを有する第２の通信システムのユーザである、
   請求項１ないし３いずれか一項に記載の方法。
5. 発呼エンジンは、被発呼者が第１の通信システムのユーザではなく、第１のユーザ識別子システムのうちの１つを有しないとき、第１の呼確立要求を被発呼端末に送信するように構成され、第１の呼受諾要求は、被発呼端末に、前記呼を通じさせるために、被発呼者のために、第１の通信システムのユーザ識別子を取得させる、
   請求項４に記載の装置。
6. 被発呼者は、第１の通信システムにおける発呼者のユーザ識別子を第２の通信システムにリンクするアカウントを有し、それにより、発呼エンジンが第２のシステムのユーザである発呼者のコンタクト相手にアクセスできるようにし、コンタクト相手は被発呼者を含み、前記アカウントを通してアクセスされる第２の通信システムにおける被発呼者のユーザ識別子に基づいて、第１の呼確立要求は被発呼端末に送信される、
   請求項４または５に記載の装置。
7. 被発呼端末は前記呼を行うためクライアントアプリケーションがインストールされ、発呼エンジンは、被発呼端末のクライアントアプリケーションがバックグラウンド状態にあり、呼を受けるためにバックグラウンド状態からウェークアップしなければならないとき、第１の呼確立要求を発呼端末に送信するように構成され、一旦ウェークアップすると、リバース呼確立要求が受信される、
   請求項１に記載の装置。
8. 前記装置は発呼者の端末である発呼端末に実装される、
   請求項１ないし７いずれか一項に記載の装置。
9. 前記装置はサーバにおいて実施され、
   発呼エンジンは、発呼者の端末である発呼端末から呼確立要求を受信し、第１の呼確立要求の被発呼端末への送信に応じて、第２の呼確立要求を受信し、前記制限時間内に受信すると、発呼者の代わりに呼を自動的に受諾し、呼を受諾すると、発呼端末と被発呼端末との両方に呼受諾応答を送信する、
   請求項１ないし７いずれか一項に記載の装置。
10. 呼確立要求とそれに対応する呼受諾応答とを含む呼フローに基づき、発呼者と被発呼者との間に、音声またはビデオ呼を確立するコンピュータプログラム製品であって、コンピュータ読み取り可能記憶媒体に記憶され、実行されると、一以上の処理ユニットに
    第１の呼確立要求を受信した時、呼を受ける準備ができていない被発呼端末に第１の呼確立要求を送信する、前記被発呼端末は被発呼者のユーザ端末である、ステップと、
    被発呼端末が呼を受ける準備ができると、呼受諾応答ではなく、前記呼に対するリバース呼確立要求を被発呼端末から受信するステップと、
    リバース呼確立要求を制限時間内に前記被発呼端末から受信することを条件に、被発呼端末に呼受諾応答を送信することにより、前記発呼者に代わって前記リバース呼確立要求を自動的に受けるステップと、
    を含む動作を実行させるように構成されたコードを有する、
    コンピュータプログラム製品。

Images