(57)【要約】  少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮する方法。本方法は、システムの第１の内部サーバで、コール側からの第１の通信であって、被コール側との接続を開始する試行を含むプッシュ要求である、第１の通信を受信することと、第１の内部サーバを介して被コール側にプッシュ通知を送出することであって、第１の内部サーバが少なくとも２つのインターフェースを有し、これらの少なくとも２つのインターフェースの各々のインターフェースが、ユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、この送出が、被コール側が接続することが可能な、少なくとも２つのインターフェースの外部ＵＤＰ（ＩＰ、ポート）対を、第１の内部サーバによって、かつプッシュ通知の内部に埋め込むことを含む、プッシュ通知を送出することと、を含む。【選択図】図１Ａ
2015525018.tif 000002
【特許請求の範囲】
【請求項１】
実行されると、少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮する方法をコンピュータプロセッサに行わせる命令を記憶した非一時的コンピュータ読み取り可能記憶媒体であって、前記方法が、
システムの第１の内部サーバで、コール側からの第１の通信であって、被コール側との接続を開始する試行を含むプッシュ要求である、第１の通信を受信することと、
前記第１の内部サーバを介して前記被コール側にプッシュ通知を送出することであって、前記第１の内部サーバが少なくとも２つのインターフェースを有し、前記少なくとも２つのインターフェースの各々のインターフェースが、ユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、前記送出が、
前記被コール側が接続することが可能な、前記少なくとも２つのインターフェースの外部ＵＤＰ（ＩＰ、ポート）対を、前記第１の内部サーバによって、かつ前記プッシュ通知の内部に埋め込むことを含む、プッシュ通知を送出することと、を含む、非一時的コンピュータ読み取り可能記憶媒体。
【請求項２】
前記システムの第２の内部サーバ、前記コール側、および前記被コール側のうちの少なくとも１つから通信を受信することであって、
バンドル化された情報であって、その個別の部分が、前記第１の内部サーバと、前記第２の内部サーバと、前記コール側と、前記被コール側との間で連続的に送出されるまたは受信されることが可能である、バンドル化された情報を受信することを含む、通信を受信すること、のための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項３】
コールを開始するまたはコールを受け付けるために、前記ＵＤＰポートおよび送信制御プロトコル（ＴＣＰ）ポートを同時並行に用いることであって、前記少なくとも２つのインターフェースの前記各々が前記ＴＣＰポートを含む、同時並行に用いることと、
少なくとも前記ＵＤＰポートおよび前記ＴＣＰポートのデフォルトポートとして前記ＵＤＰポートを利用することと、
前記ＵＤＰポートが作動していると決定された場合、前記ＴＣＰポートの使用を終了することと、のための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項４】
前記被コール側および前記コール側と関連するネットワークタイプ間を、前記ＵＤＰポートを利用して絶え間なく切り替えるための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項５】
前記第１の内部サーバによって、前記コール側と、第２の内部サーバと、および前記被コール側との間における通信の集合であって、少なくとも前記第１の通信を含む、通信の集合を中継するための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項６】
前記プッシュ要求の一部として送出された制御パケット内に含まれる情報を、前記第１の内部サーバによって解釈するための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項７】
前記第１の内部サーバで受信された制御パケットであって、前記プッシュ要求の一部である、制御パケットを、前記第１の内部サーバによって復号化するための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項８】
前記制御パケットのヘッダー中にカプセル化されたパスワードに、前記第１の内部サーバによってアクセスすることと、
前記パスワードを用いて前記制御パケットを、前記第１の内部サーバによって復号化することと、のための命令をさらに含む、請求項７に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項９】
前記コール側に対応する第１の署名を前記ヘッダー中に位置付けられた第２の署名と、前記第１の内部サーバによって比較することと、
前記第１の署名が前記第２の署名と一致し、かつ前記復号化が成功であれば、前記第１の内部サーバによって、前記制御パケットを認証することと、のための命令をさらに含む、請求項８に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項１０】
動的構成情報を前記システムの第２の内部サーバから受信することであって、前記動的構成情報が、コール側情報および被コール側情報に基づいて利用するために選択されたプロトコルを含み、前記コール側情報および前記被コール側情報が、前記コール側および前記被コール側のデバイス時間およびメモリ時間を含み、前記選択されたプロトコルが、最良適合方法を含み、前記選択されたプロトコルが、オーディオ／ビデオプロトコルを含む、受信すること、のための命令をさらに含む、請求項１に記載の非一時的コンピュータ読み取り可能記憶媒体。
【請求項１１】
少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮するシステムであって、前記システムが、
第１の内部サーバであって、第２の内部サーバと連結され、
システムの第１の内部サーバで、コール側からの第１の通信を受信するように構成されたプッシュ要求受信機であって、前記第１の通信がプッシュ要求であって、被コール側との接続を開始する試行である、受信機と、
前記第１の内部サーバを介して第１のプッシュ通知を前記被コール側に送出するように構成されたプッシュ通知送出機であって、前記第１の内部サーバが少なくとも２つのインターフェースを有し、前記少なくとも２つのインターフェースの各々のインターフェースが、ユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、前記少なくとも２つのインターフェースの外部ＵＤＰポートが、記被コール側が前記外部ＵＤＰポートに接続することが可能なように前記プッシュ通知の内部に埋め込まれている、プッシュ通知送出機と、を備える、第１の内部サーバを備える、システム。
【請求項１２】
前記第１の内部サーバが、
前記システムの前記第２の内部サーバ、前記コール側、および前記被コール側のうちの少なくとも１つから通信を受信するように構成された通信受信機をさらに備え、前記通信が、
バンドル化された情報を含み、前記バンドル化された情報の個別の部分が、前記第１の内部サーバと、前記第２の内部サーバと、前記コール側と、前記被コール側との間で連続的に送出または受信されることが可能である、請求項１１に記載のシステム。
【請求項１３】
前記第１の内部サーバが、
前記第１の内部サーバと連結し、かつ制御パケットを含むセキュリティモジュールをさらに備え、前記制御パケット解釈器が、前記プッシュ要求の一部として送出された制御パケット内に含まれる情報を解釈するように構成される、請求項１１に記載のシステム。
【請求項１４】
前記セキュリティモジュールが、
前記第１の内部サーバで受信された制御パケットを復号化するように構成された復号器をさらに備え、前記制御パケットが前記プッシュ要求の一部である、請求項１３に記載のシステム。
【請求項１５】
前記セキュリティモジュールが、
前記制御パケットのヘッダー中にカプセル化されたパスワードにアクセスするように構成されたパスワードアクセス機構をさらに備え、前記復号器が、前記パスワードを用いて前記制御パケットを復号化するようにさらに構成される、請求項１４に記載のシステム。
【請求項１６】
前記セキュリティモジュールが、
前記コール側に対応する第１の署名を前記ヘッダー中に位置付けられた第２の署名と比較するように構成された署名比較器と、
前記署名比較器と連結された制御パケット認証器であって、前記第１の署名が前記第２の署名と一致し、かつ前記復号化が成功であれば、前記制御パケットを認証するように構成される、制御パケット認証器と、をさらに備える、請求項１５に記載のシステム。
【請求項１７】
前記第１の内部サーバが、
動的構成情報を前記第２の内部サーバから受信するように構成された動的構成情報受信機をさらに備え、前記動的構成情報が、コール側情報および被コール側情報に基づいて利用される選択されたプロトコルを含み、前記コール側情報および前記被コール側情報が、前記コール側および前記被コール側のデバイス時間およびメモリ時間を含み、前記選択されたプロトコルが、最良適合方法を含み、かつオーディオ／ビデオプロトコルである、請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、「ＳＥＣＵＲＥＤ  ＷＩＲＥＬＥＳＳ  ＳＥＳＳＩＯＮ  ＩＮＩＴＩＡＴＥ  ＦＲＡＭＥＷＯＲＫ」というタイトルの２０１２年５月１０日に出願された米国仮特許出願第６１／６４５，２４９号に関連し、かつそれに対する優先権を主張するものである。本出願はまた、「ＳＥＣＵＲＥＤ  ＷＩＲＥＬＥＳＳ  ＳＥＳＳＩＯＮ  ＩＮＩＴＩＡＴＥ  ＦＲＡＭＥＷＯＲＫ」というタイトルの２０１３年３月１５日に出願された米国特許出願第１３／８３４，１５２号に関連し、かつそれに対する優先権を主張するものである。前述の出願の各々は、参照により本明細書に組み込まれる。
【背景技術】
【０００２】
現行の技術および方法は、ＸＭＰＰ／ＴＵＲＮ／ＳＴＵＭ／ＩＣＥ「ｊａｂｂｅｒ」プロトコル（インスタントメッセージ時代に起源がある）に依存して、直接的にピアツーピアで（ＮＡＴをうまく横断することによって）またはネットワークの中継（ＴＵＲＮ）によって、２つのクライエントを接続する。より具体的には、現行の技術は、次のｊａｂｂｅｒベースのソリューションを含む：ｅｊａｂｂｅｒｄ（Ｅｒｌａｎｇに基づいた既存の、一般に普及しているＸＭＭＰサーバソリューション）；ＯｐｅｎＦｉｒｅ；Ｔｉｇａｓｅ；ｌｉｂｊｉｎｇｌｅ（ｐ２ｐクライエント用のＧｏｏｇｌｅのオープンソース実装物）；ＴＵＲＮサーバ（ｈｔｔｐ：／／ｔｕｒｎｓｅｒｖｅｒ．ｓｏｕｒｃｅｆｏｒｇｅ．ｎｅｔ／）；およびＳＴＵＮサーバ（ｈｔｔｐ：／／ｓｏｕｒｃｅｆｏｒｇｅ．ｎｅｔ／ｐｒｏｊｅｃｔ／ｓｔｕｎ）。実装されるかどうかを問わず、現行のＸＭＰＰベースの技術は、長い接続時間および多くのラウンドトリップに悩まされている。
【０００３】
コール側と被コール側との間のコール確立（接続）時間が長いほど、焦燥および不満からコール側がコールを中断する可能性が高くなる。したがって、接続時間が早いほど、コール接続が確立される可能性が高くなる。
【図面の簡単な説明】
【０００４】
【図１Ａ】ある実施形態による、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮する安全な無線セッション開始フレームワークタンゴ（「ＳＷＩＦＴ」）システムを示す。
【図１Ｂ】ある実施形態による、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮するＳＷＩＦＴサーバを示す。
【図２】ある実施形態による、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮する方法のフローチャートを示す。
【図３Ａ】ある実施形態による、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮する方法のフローチャートを示す。
【図３Ｂ】ある実施形態による、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮する方法のフローチャートを示す。
【０００５】
本明細書で参照される図面は、具体的に注記される場合を除き、原寸に比例して描かれてはいないと理解すべきである。
【発明を実施するための形態】
【０００６】
ここでは、添付図面にその例が図示されている本発明の実施形態について詳細に触れる。様々な実施形態と関連して技術を説明するが、これらの実施形態は、本技術をこれら実施形態に制限することを意図するものではないことが理解されるであろう。逆に、本技術は、添付の請求項によって定義される様々な実施形態の精神および範囲内に含まれ得る代替例、修正例、および等価物を範囲に含むことを意図するものである。
【０００７】
さらにそのうえ、実施形態の以下の説明において、多くの具体的な詳細が、本技術の完全な理解を提供するために記載されている。しかしながら、本技術は、これらの具体的な詳細なしで実施され得る。多くの事例で、公知の方法、手順、構成要素、および回路が、本実施形態の態様を不必要に曖昧化しないために詳細には説明されていない。
【０００８】
以下の検討は、最初に従来の技術の概要を説明し、次に、従来の技術を改善する実施形態の簡単な説明を提供する。本検討は次に、様々な実施形態による、コール確立時間を短縮する、図１Ａ、図１Ｂ、図２、図３Ａ、図３Ｂ、システム、および方法の説明に移る。
【０００９】
（概要）
２つのクライエント間にリアルタイムの接続を確立する際における従来のＸＭＰＰベースの技術の実装には、長い接続時間および多くのラウンドトリップという問題がある。例えば、コールの確立のための従来のプロトコルは、シリアル化されている：数多くの前後の通信が、コール接続が確立される前にクライエントとサーバとの間で生じるようなシリアル化された態様でステップが行われる。
【００１０】
コール側と被コール側との間のコール確立（接続）時間が長いほど、焦燥および不満からコール側がコールを中断する可能性が高くなる。逆に、接続時間が早いほど、コール側がコールを中断せずに、コール確立が実現する確率が高くなる。コール確立時間は、実際に接続されるコールの割合に関する重要な要素となる。
【００１１】
さらに、携帯ネットワークは、異なったネットワークタイプ（例えば、３Ｇ、ｗｉｆｉ）であり得る。従来のセッション開始プロトコルは、コールが確立する間にネットワークスイッチのうちの１つを再度切り抜ける必要があり、クライエントに、自分のコールが「行き詰まった」ように感じさせる。実施形態では、著しく少ない接続オーバーヘッド（例えば、ラウンドトリップ）で、そして結局、「行き詰まった」感じを軽減して、２つのクライエント間にリアルタイムの通信の接続を達成するシステムおよび方法が提供される。
【００１２】
ＴＵＲＮ／ＳＴＵＮサーバおよびｊａｂｂｅｒサーバに対して個別の接続を必要とする従来の技術とは逆に、実施形態では、ＮＡＴの横断、コールの確立、およびトラヒック中継に対して同じサーバを用いることで、コールを再確立（例えば、２Ｇ／ｗｉｆｉスイッチ上で）する助けとなり、さらに、コール確立過程中にクライエントがオープンするおよび／または管理する必要がある接続の数がさらに減少する。
【００１３】
さらに、実施形態では、デフォルトでＵＤＰベースのプロトコルを含むため、無線チャネルを完全に利用することが可能である。移動体通信ネットワーク上でのパケット損失は通常はランダムであり、渋滞の兆候というより無線障害によるものであるため、ＴＣＰベースのプロトコルは、移動体通信ネットワーク上での利用可能な帯域幅を最高に利用するには不適切であるが、それは、これらが、このようなパケット損失を渋滞と解釈して、後退りするという反応をするからである。このお粗末な挙動は、接続の確立が大量の（例えば、従来のコール確立プロトコルでは１７の）ラウンドトリップに依存するときには増幅される。我々はデフォルトではＵＤＰを用いるため、我々は、このような無意味な待機を回避することが可能で、かつ、移動体通信ネットワーク上でのランダムなパケット損失に対してはるかに抵抗力があるＵＤＰに対して、我々自身の再送信制御を利用することが可能である。したがって、我々は、はるかに速い接続速度を獲得する。このことに加えて、ネットワークインターフェースが独立して切り替えられる（例えば、ＷｉｆｉからＣｅｌｌｕｌａｒへ、または、その逆）ときに利点がある：サーバが接続は前と同じであると分かるように「クライエントのコンテキスト」を再確立するためには、完全なＴＣＰ接続を再確立しなければならない。ＵＤＰの使用はＴＣＰの使用よりはるかに容易であるが、それは、各々のパケットが、サーバが新しいインターフェースからＵＤＰパケットを受信するやいなや即座の切り替えをするために、このようなコンテキストに関する十分な情報を含んでいるからである。
【００１４】
要するに、実施形態では、コール設定時間の短縮を可能にする。従来のコール確立時間は、１７〜約２８回のラウンドトリップを要しパケットのほとんどはＴＣＰ接続を介して送信されるが、それ自体が、ＴＣＰ再送信タイムアウトが大きいという欠点を有する。実施形態では、コール確立時間を、約３回のラウンドトリップにまで短縮することを可能とし、デフォルトではＵＤＰを用いる。したがって、ラウンドトリップ回数がより少なく、ＵＤＰプロトコルを用いているため、現在すべてのコール確立試行の約６パーセントを占める従来の「ｊａｂｂｅｒログイン不成功」および他のＸＭＰＰ関連のタイムアウトを減少させることによってコール確立成功率が増加する。
【００１５】
（実施形態の詳細な説明）
図１Ａは、ある実施形態による、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮する安全な無線セッション開始フレームワークタンゴ（「ＳＷＩＦＴ」）システム１００を示す。図１Ｂは、ある実施形態によるＳＷＩＦＴサーバ１１０Ｂを示す。図２は、ＳＷＩＦＴシステム１００によって実施される方法２００のフローチャートを示すが、方法２００は、リアルタイム通信における２つのクライエントの接続中の接続確立時間を短縮させる。
【００１６】
手短に言えば、ＳＷＩＦＴシステム１００は、ファシリテータ１０５（ＳＷＩＦＴシステム１００の内部のサーバ）ならびに少なくとも１つのＳＷＩＦＴサーバ１１０Ａ、１１０Ｂ、１１０Ｃ、および１１０ｎ．．．を含む（別途記載のない限り「ＳＷＩＦＴサーバ１１０」を含む。ＳＷＩＦＴサーバ１１０はまた、「第１の内部デバイス１１０」という文脈で以下に記載される。ＳＷＩＦＴサーバ１１０は、第１の内部デバイス１１０の例である。ファシリテータ１０５は、一部の実施形態では、「第２の内部デバイス１０５」という文脈で以下に記載されている）。
【００１７】
各々のＳＷＩＦＴサーバ１１０は、２つのインターフェースを含む。これらインターフェースのうちの一方１４５は、仮想ＩＰ（「ＶＩＰ」）（内部ＩＰ）であり、他方のインターフェース１５０は、外部のオープンＩＰである。ＶＩＰは、ＩＰトラヒックを複数のサーバ間で分割することを許容する負荷バランシングインスタンスである。ＶＩＰはＩＰアドレスを有するが、これは、使用可能なように一般に入手可能でなければならない。ＶＩＰは自身に対して割り当てられた少なくとも１つのリアルサーバを有するが、それに対するトラヒックを省いている。通常は、複数のリアルサーバが存在し、ＶＩＰはそれらの間にトラヒックを拡散させる。
【００１８】
実施形態では、各々のインターフェースが、送信制御プロトコル（ＴＣＰ）ポートおよびユーザデータグラムプロトコル（ＵＤＰ）ポートを含む。
【００１９】
全体として、ＳＷＩＦＴサーバ１１０は、２つのクライエント間でのセッションの開始と、それらの間でのトラヒックの中継との双方を必要であれば支援する。（ＳＷＩＦＴサーバ１１０は、ユーザ名をクライエントの特定のＵＤＰ  ＩＰ／ポートまたはＴＣＰソケットに対してマッピングするルーティング表を維持する。ルーティング表に対する各々のエントリは、クライエントのトラヒックから更新される。特定のＴＣＰソケットまたはＵＤＰ  ＩＰポートから６０秒以内にパケットが受信されない場合、それは、ルーティング表から除去される。この表以外は、ｓｗｉｆｔサーバ１１０は、クライエントからのいかなるステートも保持せず、したがって、我々はＳＷＩＦＴサーバ１１０をステートレスサーバと呼ぶ。ＳＷＩＦＴサーバ１１０がダウンするまたはクラッシュするとき、それは、クライエントのトラヒックを受信することによってルーティング表全体を迅速に生成して、サーバを速やかに回復する。この同じステートレス特徴のおかげで、それは、当然ながら、クライエントの絶え間ないＷｉＦｉ／３Ｇ切り替えをサポートする。
【００２０】
ここで図１Ａ、図１Ｂ、および図２を参照すると、動作２２２で、コール側クライエント１１５（「コール側１１５」と呼ぶ）は、ＳＷＩＦＴサーバ１１０にプッシュ要求を送出して最初にＳＷＩＦＴサーバ１１０の負荷平衡器に接続を試みることによって、コールを開始する。コール側１１５から被コール側１２０へのこのプッシュ要求は、コール側１１５の口座確認を含む。負荷平衡器は、このコールをＳＷＩＦＴサーバ２１０のうちの１つに方向付けする。ＤＮＳエニーキャストを用いて、異なる付加平衡器（サイト）間での適当なサイトを発見する。
【００２１】
動作２２４で、ＳＷＩＦＴサーバ１１０は、口座確認情報を含む動作２２２のプッシュ要求を、ＳＷＩＦＴサーバ１１０とファシリテータ１０５との間のＨＴＴＰのレストフルＡＰＩを介してファシリテータ１０５に送出する。
【００２２】
動作２２６で、ファシリテータ１０５は、被コール側１２０の情報リストおよび動的構成情報をＳＷＩＦＴサーバ１１０に送出する。この動的構成情報は、コール側１１５だけのデバイスタイプおよびネットワークタイプ（３Ｇ／ＷｉＦｉ）に基づいている。
【００２３】
動作２２８で、ＳＷＩＦＴサーバ１１０は、この機において、「高速プッシュ」（プッシュ通知）を被コール側１２０に即座に送出する。この高速プッシュは、被コール側１２０がすでにＳＷＩＦＴサーバ１１０に接続されていれば、被コール側１２０を呼び起こす。ＳＷＩＦＴサーバ１１０は、被コール側１２０に送出されたそれ自身の外部ＴＣＰよびＵＤＰ  ＩＰ／ポートを「高速プッシュ」ペイロードの内側に埋め込む。被コール側１２０は、これで、この外部ＩＰポートに接続することが可能となる。「高速プッシュ」は、デフォルトではＵＤＰベースであり、したがって、それは被コール側に複数回送出される。
【００２４】
高速プッシュが動作２２８で被コール側１２０に送出されると同時に、動作２３２では、ファシリテータ１０５は、第三者またはＴａｎｇｏによって提供されたプッシュサービス（例えば、Ａｐｐｌｅ（商標）、Ｇｏｏｇｌｅ（商標）（ＧＣＭ／Ｃ２ＤＭ）、Ｍｉｃｒｏｓｏｆｔ（商標）、Ｔａｎｇｏ（商標）によって提供されたプッシュサービス）に対してプッシュ要求を送出し、すると、プッシュ通知が被コール側１２０に送出されてそれを呼び起こす。「高速プッシュ」のように、このプッシュ通知は、ＳＷＩＦＴサーバ１１０のＴＣＰおよびＵＤＰ  ＩＰ／ポートを含む。
【００２５】
注目すべきことに、１つの実施形態では、ファシリテータ１０５がプッシュ通知をＳＷＩＦＴサーバ１１０に送出する動作２２６の後、動作２２８での高速プッシュと動作２３２での第三者の通知プッシュとの双方が同時に発生する。動作２２８での高速プッシュ通知は、動作２３２での第三者の通知プッシュよりも迅速に被コール側１２０に到達する。別の実施形態では、動作２３２で、ファシリテータ１０５は、プッシュ通知を複数のデバイスに送出する。
【００２６】
加えて、動作２３６で、ＳＷＩＦＴサーバ１１０は、プッシュ応答をコール側１１５に送出するが、その応答で、被コール側２２０の情報およびその動的構成がコール側１１５に送出される。
【００２７】
動作２３８で、被コール側１２０は、ＳＷＩＦＴサーバ１１０の正確なＵＤＰおよびＴＣＰ  ＩＰ／ポートを含むプッシュ通知を（動作２２８または動作２３２を介して）受信し、さらに「接続」メッセージをＳＷＩＦＴサーバ１１０に送出する。あるｉＯＳおよびＷｉｎｐｈｏｎｅの場合では、それはまた、それ１２０がコール側１１５からの通信を受け入れることを意味する被コール側１２０によって設定された「受け入れフラグ」を含む。一部の状況では、被コール側１２０は、意図された通信の自身の受け入れを、自身のコールデバイス（例えば、Ａｎｄｒｏｉｄ、ＰＣ）上の自身の表示スクリーンによって表示し、したがって、「受け入れ」メッセージは個別に送出される。
【００２８】
動作２４０で、ＳＷＩＦＴサーバ１１０は、被コール側１２０（例えば、使用されているネットワークインターフェース）に関する情報をファシリテータ１０５に送出し、ファシリテータ１０５に対して、コール側１１５と被コール側１２０との間でのビデオ／オーディオ／ネットワークレート制御に用いられる最良のアルゴリズムについて問い合わせる。  注目すべきことに、ファシリテータ１０５は、動作２２４で収集されたコール側１１５の情報をすでに有している。動作２４２で、ファシリテータ１０５は、コール側１１５と被コール側１２０との間での通信接続で用いるべき最良のアルゴリズムを含む動的構成をＳＷＩＦＴサーバ１１０に送出する。例えば、コール側１１５および被コール側１２０の双方がｗｉｆｉを用いる場合、彼らは、異なるネットワーク制御アルゴリズムを用いる。用いるべき最良のアルゴリズムを決定し、かつコール側１１５および被コール側１２０による異なるネットワークの使用に対応するためには、ファシリテータ１０５は、コール側１１５および被コール側１２０の双方の構成を知る必要がある。
【００２９】
動作２４４で、動作２４２でＳＷＩＦＴサーバ１１０に送出された動的構成は、コール側１１５に転送される。さらにまた、ＳＷＩＦＴサーバ１００は、動作２４４で、被コール側１２０の外部ＩＰ／ポートをこのメッセージに埋め込むが、それは、後になってコール側１１５と被コール側１２０との間でピアツーピア直接チャネルを生成するためにＮＡＴ横断用に用いられる。加えて、動作２４６で、動作２４２でＳＷＩＦＴサーバ１１０に送出された動的構成は、被コール側１２０に送出される。
【００３０】
注目すべきことに、コール側１１５および被コール側１２０は、ＳＷＩＦＴサーバ１１０と通信する（または第三者２６０からの通信を受信する）だけである。しかしながら、ＳＷＩＦＴサーバ１１０は、コール側１１５および被コール側１２０に対応する動的構成情報に対応する情報をファシリテータ１０５から獲得する。
【００３１】
動作２４８で、コール側１１５は、ＳＷＩＦＴサーバ１１０に信号を送出して、動作２４４で被コール側１２０からＳＷＩＦＴサーバ１１０によってコール側１１５に転送されたデータの受信を肯定応答する。
【００３２】
動作２５０で、ＳＷＩＦＴサーバ１１０は、動作２４８の肯定応答通信を被コール側１２０に送出する。ＳＷＩＦＴサーバ１１０はまた、被コール側１２０のＮＡＴ横断（ピアツーピア直接接続生成）目的で、動作２５０で、メッセージ中にコール側１１５の外部ＩＰ／ポートを位置付ける。
【００３３】
動作２５２で、１つの実施形態では、Ａｎｄｒｏｉｄ（商標）またはＰＣの場合、動作２２８（または類似の動作）で送出されたプッシュ通知は、被コール側１２０が使用中のデバイスの画面上には表示されない。被コール側１２０は、被コール側１２０のデバイスディスプレイ上にプッシュ通知を示す別の仕方で、プッシュ通知を通知される。この状況下では、被コール側１２０は、コール側１１５にさらなる受け入れを送出して、被コール側１２０がコール側１１５との通信を受け入れたことを示す。
【００３４】
ＳＷＩＦＴサーバ１１０は、１つの実施形態では、中継チャネルとして機能し、このチャネルは、コール側１１５と被コール側１２０との間でビデオ／オーディオデータを送信するために用いられる。
【００３５】
１つの実施形態では、中継チャネルが生成された後、コール側１１５および被コール側１２０は、直接ピアツーピアチャネルを生成するために、相互の外部ＩＰ／ポートを用いようとする。このような試行が成功した場合、ＳＷＩＦＴシステム１００は、ＳＷＩＦＴサーバ１１０の中継チャネルの使用からピアツーピアチャネルの使用に切り替える。ピアツーピアチャネルは、コール側１１５と被コール側１２０（クライエント）との間の直接チャネルである。中継チャネルからピアツーピアチャネルに切り替えることによって、実施形態では、コール側１１５と被コール側１２０との間の通信を含むパケットが走行し得るより直接的な経路が作成されている。このより直接的な経路は、パケットのより高速な横断、より少ない遅延、およびサーバに対する負荷の減少を提供する。この切り替えは途切れなく、そのため、中継チャネルを用いて実施されている動作からピアツーピアチャネル上で実施されている動作への変更に対するユーザが知覚可能な兆候（オーディオ／ビデオ不調）は存在しない。コール側１１５および被コール側１２０は、たとえピアツーピアチャネルが使用中であっても、接触中のＳＷＩＦＴサーバ１１０を保持し、したがって、切り替え中に中継チャネル上にあるパケットが行方不明にはならない。
【００３６】
図２、図３Ａ、および図３Ｂを参照すると、ある実施形態による、リアルタイム通信における２つのクライエントの接続中のコール設定時間を短縮する方法のフローチャートが示されている。様々な実施形態では、方法２００および３００は、コンピュータ読み取り可能でかつコンピュータ実行可能な命令の制御下にある１つ以上のプロセッサおよび電気的構成要素によって実行される。コンピュータ読み取り可能でかつコンピュータ実行可能な命令は、例えば、コンピュータが使用可能な揮発性および不揮発性のメモリなどの有形のデータ記憶機能に置かれる。しかしながら、コンピュータ読み取り可能でかつコンピュータ実行可能な命令は、任意のタイプのコンピュータ読み取り可能記憶媒体に置かれてもよい。一部の実施形態では、方法２００および３００は、図１Ａおよび図１Ｂに関連して説明したようにファシリテータ１０５およびＳＷＩＦＴサーバ１１０によって、または、本明細書に説明するＳＷＩＦＴシステム１００などのシステムによって実施される。
【００３７】
図１Ａを参照すると、１つの実施形態では、そして、本明細書中で既に説明したように、１１０Ｂと呼ばれる第１の内部サーバはＳＷＩＦＴサーバ１１０である。ＳＷＩＦＴサーバ１１０Ｂは、クライエント（コール側１１５と被コール側１２０との）間で中継デバイスとして作動する。ここで図１Ａおよび図１Ｂを参照すると、ある実施形態による（ＳＷＩＦＴサーバ１１０の）ＳＷＩＦＴサーバ１１０Ｂが示されている。ＳＷＩＦＴサーバ１１０Ｂは、次の構成要素を含む：プッシュ要求受信機１５５およびプッシュ通知送出機１７５。ＳＷＩＦＴサーバ１１０はまた、オプションとして、次の構成要素を含む：プッシュ要求送出機１６０、通信受信機１７０、セキュリティモジュール１４０、動的構成情報受信機１６５、インターフェース１４５、インターフェース１５０、およびプッシュ通知応答機（図示せず）。セキュリティモジュール１４０は、オプションとして、第１の内部サーバで受信された制御パケットを復号化するように構成された復号器であって、制御パケットがプッシュ要求の一部である、復号器と、制御パケットのヘッダー中にカプセル化されたパスワードにアクセスするように構成されたパスワードアクセス機構であって、復号器がパスワードを用いて制御パケットを復号化するように更に構成される、パスワードアクセス機構と、署名比較器および制御パケット認証器と、を含む。署名比較器は、コール側に対応する第１の署名をヘッダー中に位置付けられた第２の署名と比較するように構成されている。制御パケット認証器は署名比較器と連結されていて、第１の署名が第２の署名と一致し、復号化が成功すれば、制御パケットを認証するように構成される。
【００３８】
ＳＷＩＦＴサーバ１１０は、例えば次の、コール側１１５からのプッシュ要求を受信するために動作２２２に関連して用いられるプッシュ要求受信機１５５、被コール側１２０にプッシュ通知を送出するために動作２２４、２２８、２３０と関連して用いられるプッシュ通知送出機１７５、被コール側１２０の情報をコール側１１５に送出することによって動作２３８で送出された接続フラグに応答するために動作２３６と関連して用いられるプッシュ通知応答器、ならびに２つのインターフェース１４５および１５０などの、ＳＷＩＦＴサーバ１１０内の様々なモジュールを介してプッシュ要求を受信し、送出し、これらに応答する。
【００３９】
たとえＳＷＩＦＴサーバ１１０が、コール側１１５と、被コール側１２０と、ファシリテータ１０５との間で情報を概して単に中継するとはいえ、ＳＷＩＦＴサーバ１１０は、実際には、制御パケット中の情報を解釈する（制御パケットは、コールの確立中にクライエントとファシリテータ１０５間で送出されている情報を含む。例えば、コール側１１５からの動作２２２のプッシュ要求は、制御パケットを含む（または、制御パケットである）。）（このプッシュ要求は、プッシュ要求送出機１６０からＳＷＩＦＴサーバ１１０によってファシリテータ１０５に送出される。）
【００４０】
実施形態ではまた、セキュリティを犠牲にすることなく接続確立時間を短縮する、コール側１１５から被コール側１２０にパケットを通信するシステムおよび方法を提供する。ＳＷＩＦＴシステム１００は、ＳＳＬに依存せず、しかりより軽量である。ＳＷＩＦＴシステム１００は、次の方法２００を用いる：（１）クライエントが、暗号化された｛ユーザ名、パスワード｝対を含む「プロビジョニングセンター」から認証トークンを獲得する。暗号化鍵は、ＳＷＩＦＴサーバ２１０Ａ〜２１０ｎ、・・・の全てで共有され、クライエントに周知では無いが、クライエントは｛ユーザ名、パスワード｝の平文値を知っている、（２）制御パケットの全てが、クライエントによって上述のパスワードで暗号化される。ＳＷＩＦＴサーバは、各々の制御パケット中の認証トークンを暗号化鍵で復号化し、特定のクライエントのパスワードを誘導し、次に、このパスワードを用いて、制御パケットのペイロードを復号化する、（３）データパケットはＳＷＩＦＴシステム２００によって暗号化されないが、しかし、２つのクライエントパーティー間で、エンドツーエンドで暗号化可能である、（４）「再生攻撃」を防止するため、各々のクライエントは、時刻印を推定し、それにそれ自身のパスワードを署名する。サーバが適切なウインドウ中でその時刻印が正しいと見なせば、制御パケットは検査をパスする。そうでなければ、サーバは、クライエントに異議申し立てするため、ノンスを送出する。ノンスは、クライエントの送出元のＩＰポートおよび現行のサーバ時刻印を含む。クライエントは、時刻印のゆがみのために再び異議申し立てされないように、それ自身のクロックとサーバの時刻印との差をそれのローカルストレージに記憶する、ならびに（５）サーバが、クライエントはサーバにデータをアップロードするために異なるＵＤＰ  ＩＰポートまたはＴＣＰソケットを用いていると検出すると、それは常にノンス異議申し立てを即座に得ることになる。後続のパケットでサーバに送出されると予期されるノンスがクライエントによってうまく署名されると、サーバは、対応するクライエントエントリをこの新しいＴＣＰソケットまたはＵＤＰ  ＩＰポートに切り替える。
【００４１】
制御パケットがＳＷＩＦＴサーバ１１０に送出されるとき、クライエントのパスワードを用いて、制御パケットを暗号化し、かつパケット署名をカプセル化してこのパケット署名を制御パケットのヘッダー中に位置付ける。ＳＷＩＦＴサーバ１１０は、いったんそれが制御パケットヘッダー中の認証トークンを受信すると、パスワードを用いて制御パケットを復号化する。ＳＷＩＦＴサーバ１１０はまた、それが有するクライエントの署名を制御パケットのヘッダーに位置付けられた署名と比較する。署名が一致して、暗号化が成功であれば、ＳＷＩＦＴサーバ１１０は、制御パケットを認証した。認証の後、ＳＷＩＦＴサーバ１１０は、制御パケットを受け入れて処理（中継）する。ＳＷＩＦＴサーバ１１０は、制御パケットが特定のクライエントから来るようにして、次に、制御パケットを復号化する。したがって、実施形態によれば、ラウンドトリップ回数の減少および接続確立時間の高速化を犠牲にすることによって、セキュリティが犠牲になることはない。
【００４２】
クライエントとＳＷＩＦＴサーバ１１０との間でのいかなるファイアウオールによってもＵＤＰが遮断されることがないようにするには、ＴＣＰをまた用いて、ファイアウオール横断と呼ばれるコールを確立すればよい。ファイアウオールを迅速に横断するために、クライエントは常にＵＤＰおよびＴＣＰを同時に用いる。いったんＵＤＰが作動するとの証拠があれば、ＴＣＰは停止される。ステートマシンは、ＴＣＰ接続を閉じる正確な時間を算定する助けとなる。
【００４３】
サーバの責任の１つは、直接的なピアツーピアチャネルを確立すること、したがって、コール側１１５および被コール側１２０のＩＰおよびポートが外界からどのように見えるかを決定する助けとなることである。これを決定する際の従来の方法は、「Ｐ２Ｐ候補」を獲得するために個別の要求を「ＴＵＲＮ／ＳＴＵＮ」サーバに送出することである。従来の方法とは対照的に、ＳＷＩＦＴシステム２００は、本明細書に記載する方法２００中でＵＤＰ  ＩＰポートを固有に発見し、それにより、コール側１１５および被コール側１２０のＩＰ／ポートが外側からどのように見えるかを決定する際の余分のステップ（または所要時間）を回避する。
【００４４】
ファシリテータ１０５（本明細書では「第２の内部サーバ１０５」とも呼ばれる）は、オプションとして、次のうちのいずれかを含む：プッシュ要求受信機１２５、第１の動的構成送出機１３０、第２の動的構成送出機１４０、および情報受信機１３５。プッシュ要求受信機１２５は、プッシュ要求をＳＷＩＦＴサーバ１１０から受信する。第１の動的構成送出機１３０は、被コール側１２０の動的構成（コール確立中の最良のアルゴリズム）をＳＷＩＦＴサーバ１１０に送出する。第２の動的構成送出機１４０は、被コール側１２０とコール側１１５の双方の動的構成をＳＷＩＦＴサーバ１１０に送出する。情報受信機１３５は、コール側１１５と被コール側１２０の双方に関連する情報をＳＷＩＦＴサーバ１１０から受信する。
【００４５】
ファシリテータ１０５は、プッシュ通知用のＡｐｐｌｅ（商標）およびＧｏｏｇｌｅ（商標）のようなシステムとの少なくともインターフェースなどの機能を遂行するために用いられる。本明細書に記述するように、ファシリテータ１０５は、被コール側１２０を呼び起こすプッシュ通知を送出するために、第三者２６０と通信する。
【００４６】
したがって、実施形態では、デフォルトでＵＤＰベースである方法およびシステムが提供される。実施形態では、したがって、ＴＣＰベースの方法またはシステムを用いる場合ほどにはパケット損失に対して脆弱ではない。さらに、実施形態では、パケットの送信中に情報をバンドル化するようにしていて、したがって、バンドル化された情報が収集されるラウンドトリップをより節約される。従来のシステムおよび方法で連続して実行されるステップは、実施形態では同時並行に実行され、それにより、コールの確立中に聞かされる無意味な機械的な音の量が最小化する。
【００４７】
ここで図３Ａおよび図３Ｂを参照すると、ある実施形態による少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮する方法３００が図示されている。動作３０５で、コール側からの第１の通信が、システムの第１の内部サーバで受信されるが、第１の通信は、被コール側との接続を開始する試行を含むプッシュ要求である。動作３１０で、プッシュ通知が前述の内部サーバを介して被コール側に送出され、第１の内部サーバは少なくとも２つのインターフェースを有し、これら少なくとも２つのインターフェースの各々のインターフェースは、ユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、この送出は、被コール側が接続することが可能な少なくとも２つのインターフェースの外部ＵＤＰ  ＩＰ／ポートを、第１の内部サーバによって、かつプッシュ要求の内部に埋め込むことを含む。
【００４８】
動作３１５で、本システムの第２の内部サーバ、コール側、および被コール側のうちの少なくとも１つからの通信が受信され、この通信を受信することは、バンドル化された情報を受信することを含み、バンドル化された情報の個別の部分は、第１の内部サーバと、第２の内部サーバと、コール側と、被コール側との間で連続的に送出または受信されることが可能である。
【００４９】
動作３２０で、ＵＤＰポートおよび送信制御プロトコル（ＴＣＰ）ポートを同時並行に用いて、コールを開始するまたはコールを受け入れ、少なくとも２つのインターフェースの各々がＴＣＰポートを含む。ＵＤＰ  ＩＰ／ポートは、少なくともＵＤＰ  ＩＰ／ポートおよびＴＣＰポートのデフォルトポートとして利用され、ＵＤＰ  ＩＰ／ポートが作動していると決定されると、ＴＣＰポートの使用は終了される。
【００５０】
動作３２５で、ＵＤＰ  ＩＰ／ポートは、被コール側およびコール側と関連するネットワークタイプ間での絶え間ない切り替えのために利用される。
【００５１】
動作３３０で、コール側と、第２の内部サーバと、被コール側との間での通信の集合が、第１の内部サーバによって中継され、この通信の集合は少なくとも第１の通信を含む。
【００５２】
動作３３５で、プッシュ要求の一部として送出される制御パケット内に含まれる情報が、第１の内部サーバによって解釈される。
【００５３】
動作３４０で、第１の内部サーバで受信された制御パケットが第１の内部サーバによって復号化されるが、この制御パケットはプッシュ要求の一部である。更なる実施形態では、制御パケットのヘッダー中にカプセル化されたパスワードがアクセスされ、制御パケットは、このパスワードを用いて第１の内部サーバによって復号化される。さらなる実施形態では、コール側に対応する第１の署名をヘッダー中に位置付けられた第２の署名と、第１の内部サーバによって比較することと、第１の署名と第２の署名とが一致し、復号化が成功であれば、第１の内部サーバによって制御パケットを認証することと、が含まれる。
【００５４】
動作３４５で、動的構成情報が、本システムの第２の内部サーバによって受信され、この動的構成情報は、コール側情報および被コール側情報に基づいて、選択された利用すべきプロトコルを含み、コール側情報および被コール側情報は、コール側および被コール側のデバイス時間およびメモリ時間を含み、選択されたプロトコルは、コール側と被コール側との間での接続確立時間中のラウンドトリップを最小化する最良適合方法を含む。
【００５５】
本開示は、少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮する方法を説明する。本方法は、システムの第１の内部サーバで、コール側からの第１の通信であって、被コール側との接続を開始する試行を含むプッシュ要求である、第１の通信を受信することと、プッシュ通知を、第１の内部サーバを介して、被コール側に送出することであって、第１の内部サーバが少なくとも２つのインターフェースを有し、２つのインターフェースの各々のインターフェースがユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、この送出が、被コール側が接続することが可能な少なくとも２つのインターフェースの外部ＵＤＰ（ＩＰ、ポート）対を、第１の内部サーバによって、かつプッシュ通知の内側に埋め込むことを含む、送出することと、を含む。
【００５６】
リアルタイム通信でのコール確立時間を短縮する安全な無線セッション開始フレームワークならびにシステムおよび方法の様々な実施形態を説明した。特定の実施形態を説明したが、これらの実施形態はこのような説明を制限するものと解釈すべきではなく、むしろ、次の請求の範囲にしたがって解釈されるべきであると認識すべきである。
【００５７】
本明細書に記述するすべての要素、部品、およびステップを含むことが好ましい。これらの要素、部品、およびステップのいずれも、当業者には明らかな程度に、他の要素、部品、およびステップと交換されたり、または、まとめて削除されたりし得る。
概念
この文書は、少なくとも次の概念を開示する：
概念１．  実行されると、少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮する方法をコンピュータプロセッサに行わせる命令を記憶した非一時的コンピュータ読み取り可能記憶媒体であって、前記方法が、
システムの第１の内部サーバで、コール側からの第１の通信であって、被コール側との接続を開始する試行を含むプッシュ要求である、第１の通信を受信することと、
前記第１の内部サーバを介して前記被コール側にプッシュ通知を送出することであって、前記第１の内部サーバが少なくとも２つのインターフェースを有し、前記少なくとも２つのインターフェースの各々のインターフェースが、ユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、前記送出が、
前記被コール側が接続することが可能な、前記少なくとも２つのインターフェースの外部ＵＤＰ（ＩＰ、ポート）対を、前記第１の内部サーバによって、かつ前記プッシュ通知の内部に埋め込むことを含む、プッシュ通知を送出することと、を含む、非一時的コンピュータ読み取り可能記憶媒体。
概念２．  前記システムの第２の内部サーバ、前記コール側、および前記被コール側のうちの少なくとも１つから通信を受信することであって、
バンドル化された情報であって、その個別の部分が、前記第１の内部サーバと、前記第２の内部サーバと、前記コール側と、前記被コール側との間で連続的に送出されるまたは受信されることが可能である、バンドル化された情報を受信することを含む、通信を受信すること、のための命令をさらに含む、概念１に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念３．  コールを開始するまたはコールを受け付けるために、前記ＵＤＰポートおよび送信制御プロトコル（ＴＣＰ）ポートを同時並行に用いることであって、前記少なくとも２つのインターフェースの前記各々が前記ＴＣＰポートを含む、同時並行に用いることと、
少なくとも前記ＵＤＰポートおよび前記ＴＣＰポートのデフォルトポートとして前記ＵＤＰポートを利用することと、
前記ＵＤＰポートが作動していると決定された場合、前記ＴＣＰポートの使用を終了することと、のための命令をさらに含む、概念１または２に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念４．  前記被コール側および前記コール側と関連するネットワークタイプ間を、前記ＵＤＰポートを利用して絶え間なく切り替えるための命令をさらに含む、概念１、２または３に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念５．  前記第１の内部サーバによって、前記コール側と、第２の内部サーバと、および前記被コール側との間における通信の集合であって、少なくとも前記第１の通信を含む、通信の集合を中継するための命令をさらに含む、概念１、２、３または４に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念６．  前記プッシュ要求の一部として送出された制御パケット内に含まれる情報を、前記第１の内部サーバによって解釈するための命令をさらに含む、概念１、２、３、４または５に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念７．  前記第１の内部サーバで受信された制御パケットであって、前記プッシュ要求の一部である、制御パケットを、前記第１の内部サーバによって復号化するための命令をさらに含む、概念１、２、３、４、５または６に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念８．  前記制御パケットのヘッダー中にカプセル化されたパスワードに、前記第１の内部サーバによってアクセスすることと、
前記パスワードを用いて前記制御パケットを、前記第１の内部サーバによって復号化することと、のための命令をさらに含む、概念１、２、３、４、５、６または７に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念９．  前記コール側に対応する第１の署名を前記ヘッダー中に位置付けられた第２の署名と、前記第１の内部サーバによって比較することと、
前記第１の署名が前記第２の署名と一致し、かつ前記復号化が成功であれば、前記第１の内部サーバによって、前記制御パケットを認証することと、のための命令をさらに含む、概念１、２、３、４、５、６、７または８に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念１０．  動的構成情報を前記システムの第２の内部サーバから受信することであって、前記動的構成情報が、コール側情報および被コール側情報に基づいて利用するために選択されたプロトコルを含み、前記コール側情報および前記被コール側情報が、前記コール側および前記被コール側のデバイス時間およびメモリ時間を含み、前記選択されたプロトコルが、最良適合方法を含み、前記選択されたプロトコルが、オーディオ／ビデオプロトコルを含む、受信すること、のための命令をさらに含む、概念１、２、３、４、５、６、７、８または９に記載の非一時的コンピュータ読み取り可能記憶媒体。
概念１１．  少なくとも２つのデバイス間でのリアルタイム通信におけるコール確立時間を短縮するシステムであって、前記システムが、
第１の内部サーバであって、第２の内部サーバと連結され、
システムの第１の内部サーバで、コール側からの第１の通信を受信するように構成されたプッシュ要求受信機であって、前記第１の通信がプッシュ要求であって、被コール側との接続を開始する試行である、受信機と、
前記第１の内部サーバを介して第１のプッシュ通知を前記被コール側に送出するように構成されたプッシュ通知送出機であって、前記第１の内部サーバが少なくとも２つのインターフェースを有し、前記少なくとも２つのインターフェースの各々のインターフェースが、ユーザデータグラムプロトコル（ＵＤＰ）ポートを含み、前記少なくとも２つのインターフェースの外部ＵＤＰポートが、記被コール側が前記外部ＵＤＰポートに接続することが可能なように前記プッシュ通知の内部に埋め込まれている、プッシュ通知送出機と、を備える、第１の内部サーバを備える、システム。
概念１２．  前記第１の内部サーバが、
前記システムの前記第２の内部サーバ、前記コール側、および前記被コール側のうちの少なくとも１つから通信を受信するように構成された通信受信機をさらに備え、前記通信が、
バンドル化された情報を含み、前記バンドル化された情報の個別の部分が、前記第１の内部サーバと、前記第２の内部サーバと、前記コール側と、前記被コール側との間で連続的に送出または受信されることが可能である、概念１１に記載のシステム。
概念１３．  前記第１の内部サーバが、
前記第１の内部サーバと連結し、かつ制御パケットを含むセキュリティモジュールをさらに備え、前記制御パケット解釈器が、前記プッシュ要求の一部として送出された制御パケット内に含まれる情報を解釈するように構成される、概念１１または１２に記載のシステム。
概念１４．  前記セキュリティモジュールが、
前記第１の内部サーバで受信された制御パケットを復号化するように構成された復号器をさらに備え、前記制御パケットが前記プッシュ要求の一部である、概念１１、１２または１３に記載のシステム。
概念１５．  前記セキュリティモジュールが、
前記制御パケットのヘッダー中にカプセル化されたパスワードにアクセスするように構成されたパスワードアクセス機構をさらに備え、前記復号器が、前記パスワードを用いて前記制御パケットを復号化するようにさらに構成される、概念１１、１２、１３または１４に記載のシステム。
概念１６．  前記セキュリティモジュールが、
前記コール側に対応する第１の署名を前記ヘッダー中に位置付けられた第２の署名と比較するように構成された署名比較器と、
前記署名比較器と連結された制御パケット認証器であって、前記第１の署名が前記第２の署名と一致し、かつ前記復号化が成功であれば、前記制御パケットを認証するように構成される、制御パケット認証器と、をさらに備える、概念１１、１２、１３、１４または１５に記載のシステム。
概念１７．  前記第１の内部サーバが、
動的構成情報を前記第２の内部サーバから受信するように構成された動的構成情報受信機をさらに備え、前記動的構成情報が、コール側情報および被コール側情報に基づいて利用される選択されたプロトコルを含み、前記コール側情報および前記被コール側情報が、前記コール側および前記被コール側のデバイス時間およびメモリ時間を含み、前記選択されたプロトコルが、最良適合方法を含み、かつオーディオ／ビデオプロトコルである、概念１１、１２、１３、１４、１５または１６に記載のシステム。
【図１Ａ】
2015525018.tif 000003
【図１Ｂ】
2015525018.tif 000004
【図２】
2015525018.tif 000005
【図３Ａ】
2015525018.tif 000006
【図３Ｂ】
2015525018.tif 000007
【国際調査報告】
2015525018.tif 000008
2015525018.tif 000009