(57)【要約】本発明は、安全性が保証されたデバイスと安全性が保証されないデバイスとの間のセキュア通信を提供するシステム及び方法に関する。特に、本発明は、安全性が保証されない接続に亘る実装を要求する通信プロトコルを用いて、セキュアデバイスとアンセキュアデバイスとの間の通信を可能にするシステム及び方法に関する。
2020528189.tif 000002
【特許請求の範囲】
【請求項１】
安全性が保証されたデバイスと安全性が保証されないデバイスとの間のセキュア通信を提供する方法において、
セキュア接続を経由してプロキシサービスにて、サブスクライバデバイス上でクライアントからの接続リクエストを受信するステップであって、前記接続リクエストはターゲットのパブリッシャデバイスのためのノードアドレスを含む、受信するステップと、
アンセキュア接続を経由して、プロキシサービスをターゲットのパブリッシャデバイスへ接続するステップと、
サブスクライバデバイスとターゲットのパブリッシャデバイスとの間のブリッジを、プロキシサービスを経由して確立するステップと、
サブスクライバデバイス間の接続をネゴシエートするために、ブリッジに亘ってプロキシチャネルを利用するステップと、及び、
サブスクライバデバイス間の前記接続に亘ってサブスクライバデバイスとパブリッシャデバイスの間でデータを交換するステップと
を含む、方法。
【請求項２】
ドメイン名とセキュアソケットレイヤ（ＳＳＬ）サーティフィケイトを伴って構成されるストリームマネジャサーバ上で、プロキシサービスが実装されている、請求項１に記載の方法。
【請求項３】
ストリームマネジャはクラウドインフラストラクチャ上に実装されている、請求項２に記載の方法。
【請求項４】
前記ブリッジを確立するステップは、相互作用接続確立（ＩＣＥ）技術を用いてサブスクライバデバイスとパブリッシャデバイスとの間でセッションセットアップ情報をネゴシエートするステップを含む、請求項１に記載の方法。
【請求項５】
ブリッジは、
ＷｅｂＳｏｃｋｅｔセキュア（ＷＳＳ）接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、サブスクライバデバイスとプロキシサービスとの間の接続と、及び、
ＷｅｂＳｏｃｋｅｔ（ＷＳ）アンセキュア接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、パブリッシャデバイスとプロキシサービスとの間の接続と
を含む、請求項１に記載の方法。
【請求項６】
ブリッジにより、セキュアデータがセキュアサブスクライバデバイスからアンセキュアパブリッシャデバイスへ流れることが可能になる、請求項１に記載の方法。
【請求項７】
サブスクライバデバイスは、ウエブブラウザクライアントからプロキシサービスへ接続する、請求項１に記載の方法。
【請求項８】
パブリッシャデバイスは、ドメインもＳＳＬサーティフィケイトも伴わないメディアサーバであり、マルチメディアを、接続されたサブスクライバデバイスへブロードキャストするように構成されている、請求項１に記載の方法。
【請求項９】
接続はサブスクライバデバイスとパブリッシャデバイスとの間の直接接続であり、若しくは、接続はネットワークアドレストランスレーション（ＮＡＴ）接続であり、及び、
接続はサブスクライバデバイスとパブリッシャデバイスとの間でマルチメディアを交換するように構成されている、
請求項１に記載の方法。
【請求項１０】
プロキシサービスは、ピンガー機構を用いて、サブスクライバデバイスとパブリッシャデバイスとの間のマルチメディアデータの交換の間に、ブリッジをオープンのまま維持するように構成されている、請求項１に記載の方法。
【請求項１１】
更に、ロードバランサにより、サブスクライバデバイスとパブリッシャデバイスとの間の負荷をバランスするステップを含む、請求項１に記載の方法。
【請求項１２】
プロキシサービスが、効率性及び信頼性のために、安全性が保証されたデバイスと安全性が保証されないデバイスとの間で、ＷｅｂＲＴＣ情報交換を提供する、請求項１に記載の方法。
【請求項１３】
パブリッシャデバイスは、複数の物理的ノード若しくはバーチャルインスタンスを含むストリーミングクラスタを含む、請求項１に記載の方法。
【請求項１４】
更に、サブスクライバデバイスとパブリッシャデバイスのための元のクライアント情報を追跡するためにカスタムヘッダを作成するステップを含む、請求項１に記載の方法。
【請求項１５】
安全性が保証されたデバイスと安全性が保証されないデバイスとの間のセキュア通信を提供するシステムにおいて、システムは、
セキュア接続を経由してサブスクライバデバイスと電子通信するプロキシサービスと、及び、
アンセキュア接続を経由してプロキシサービスと電子接続するターゲットのパブリッシャデバイスと
を含み、
クライアントデバイスから接続リクエストを受信することに応答して、プロキシサービスは、
サブスクライバデバイスとターゲットのパブリッシャデバイスとの間のブリッジを、プロキシサービスを経由して確立し、及び、
サブスクライバデバイス間の接続をネゴシエートするために、ブリッジに亘ってプロキシチャネルを利用して、サブスクライバデバイス間の前記接続に亘ってサブスクライバデバイスとパブリッシャデバイスの間でマルチメディアのデータの交換を促進する
ように構成されている、システム。
【請求項１６】
ドメイン名とセキュアソケットレイヤ（ＳＳＬ）サーティフィケイトを伴って構成されるストリームマネジャサーバ上で、プロキシサービスが実装されている、請求項１５に記載のシステム。
【請求項１７】
ストリームマネジャはクラウドインフラストラクチャ上に実装されている、請求項１６に記載のシステム。
【請求項１８】
前記ブリッジを確立することは、相互作用接続確立（ＩＣＥ）技術を用いてサブスクライバデバイスとパブリッシャデバイスとの間でセッションセットアップ情報をネゴシエートすることを含む、請求項１５に記載のシステム。
【請求項１９】
ブリッジは、
ＷｅｂＳｏｃｋｅｔセキュア（ＷＳＳ）接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、サブスクライバデバイスとプロキシサービスとの間の接続と、及び、
ＷｅｂＳｏｃｋｅｔ（ＷＳ）アンセキュア接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、パブリッシャデバイスとプロキシサービスとの間の接続と
を含む、請求項１５に記載のシステム。
【請求項２０】
ブリッジにより、セキュアデータがセキュアサブスクライバデバイスからアンセキュアパブリッシャデバイスへ流れることが可能になる、請求項１５に記載のシステム。
【請求項２１】
サブスクライバデバイスは、ウエブブラウザクライアントからプロキシサービスへ接続する、請求項１５に記載のシステム。
【請求項２２】
パブリッシャデバイスは、ドメインもＳＳＬサーティフィケイトも伴わないメディアサーバであり、マルチメディアを、接続されたサブスクライバデバイスへブロードキャストするように構成されている、請求項１５に記載のシステム。
【請求項２３】
接続はサブスクライバデバイスとパブリッシャデバイスとの間でマルチメディアを交換するように構成されており、及び、
接続はサブスクライバデバイスとパブリッシャデバイスとの間の直接接続であり、若しくは、ネットワークアドレストランスレーション（ＮＡＴ）接続である、
請求項１５に記載のシステム。
【請求項２４】
プロキシサービスは、ピンガー機構を用いて、サブスクライバデバイスとパブリッシャデバイスとの間のマルチメディアデータの交換の間に、ブリッジをオープンのまま維持するように構成されている、請求項１５に記載のシステム。
【請求項２５】
プロキシサービスは、更に、ロードバランスにより、サブスクライバデバイスとパブリッシャデバイスとの間の負荷をバランスするように構成されている、請求項１５に記載のシステム。
【請求項２６】
プロキシサービスが、効率性及び信頼性のために、安全性が保証されたデバイスと安全性が保証されないデバイスとの間で、ＷｅｂＲＴＣ情報交換を提供する、請求項１５に記載のシステム。
【請求項２７】
パブリッシャデバイスは、複数の物理的ノード若しくはバーチャルインスタンスを含むストリーミングクラスタを含む、請求項１５に記載のシステム。
【請求項２８】
プロキシサービスは、更に、サブスクライバデバイスとパブリッシャデバイスのための元のクライアント情報を追跡するためにカスタムヘッダを作成するように構成されている、請求項１５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２０１７年７月２１日出願の米国特許仮出願第６２／５３５２６３号の優先権及びその利益を主張するものであり、該仮出願は参照の上全体として本明細書に組み込まれる。
【０００２】
本発明は、セキュアデバイスとアンセキュアデバイスとの間の通信を確立するのに適したシステム及び方法に関する。特に、本発明は、安全性が保証された通信に亘る実装を要求する通信プロトコルを利用して、セキュアデバイスとアンセキュアデバイスとの間の通信を可能にするシステム及び方法に関する。
【背景技術】
【０００３】
インターネットの出現及びコンピュータネットワークへのアクセスの増加により、サービスプロバイダ及びエンドユーザが、様々なサービス（例えば、ストリーミング、ゲーミング、コミュニケーション、ファイルトランスファ等）へのアクセスを提供するインターネットにおいてシームレスに通信を行うことを可能にすることが、促進されてきた。サービスプロバイダ及びエンドユーザは、様々な通信プロトコルを用いて実に様々に通信をすることができる。トランスミッションプロトコル（ＴＣＰ）及びインターネットプロトコル（ＩＰ）は、例えば、インターネット及びネットワークにおいて通信を行うのに用いられる多数のプロトコルのための根本的なプロトコルである。インターネットの利用が増大し、様々なタイプのインターネット利用可能デバイスが入手可能となってくるにつれて、デバイス間の安全な通信を簡素化するための、他の通信プロトコルが創作されてきた。例えば、エンドユーザは、別のエンドユーザ若しくはサービスプロバイダとの直接の接続を統合する必要無く、ウエブブラウザ及び／又はモバイルアプリケーションを介して、コンテンツ及びサービスにアクセスできる。
【０００４】
サービスがユーザに即座に入手可能であり、更に未知のデバイス間の接続が容易であることから、それらのデバイス間の接続に関してリスクが増加している。悪意のある振る舞いからサービスプロバイダ及びエンドユーザを保護するために、デバイス間で通信するに当たり、様々なセキュリティ及び制約のスタンダード、並びにプロトコルが、利用のために開発されてきた。インターネットオープンスタンダードは、そのようなスタンダードの例であり、ウエブブラウザクライアントから作成される、接続に関する或る制約（例えば、ＴＣＰ及びユーザデータグラムプロトコル（ＵＤＰ）接続プロトコル）を配置する。これらの制約は、クロスオリジンリソースシェアリング（ＣＯＲＳ）スタンダード内でカバーされ、様々なウエブブラウザに亘って様々に解釈され得る。ＣＯＲの一つの実装では、ブラウザクライアントは、セキュアサイトからアンセキュアエンドポイントへの接続を確立できない。この要件は、（例えば、グーグルクロムなどの）メインストリームブラウザによる採用を介して、スタンダードと成りつつあり、オフィシャルのＨＴＭＬ５使用の一部として、全てのブラウザに適用し得るものとなる。このことは、あるウエブブラウザが関連するときにデータがデバイス間でどのように共有され得るか、ということに、広範な影響がある。
【０００５】
そのような制約の一例は、デバイスで用いられるウエブブラウザが、ウエブリアルタイムコミュニケーション（ＷｅｂＲＴＣ）によるエンドポイントへの遠隔接続を作成しようと試みるときに、発生する。なぜなら、ブラウザクライアントは、リモートサーバへ接続するときに（例えば、カメラやマイクロホンから）マルチメディアを発行するためのアクセスを制約しているからである。サーバエンドポイントはＳＳＬサーティフィケイトにより安全性が保証される必要があるので、アクセスは制約され得る。特に、ＣＯＲＳと同様に、ＷｅｂＲＴＣアーキテクチャも、メカニズムフローのための制約及び境界を規定するオープンスタンダードにより規定される、それ自身のルールのセットを付随する。安全性が保証される接続（ＳＳＬ使用可能）であるコアポリシの一つは、遠隔メディアサーバエンドポイントへ接続するＷｅｂＲＴＣクライアントにより要求される（例えば、接続は、セキュアプロトコル（通常、セキュアウエブソケット若しくはＷＳＳ）を用いて確立されなければならない。よって、ＷｅｂＲＴＣ接続は、ＳＳＬサーティフィケイトが、接続される遠隔サーバにインストールされることを要求する。大量のメディアトラフィックを処理するのに、クラスタリングコンフィギュレーション及び／又はクラウドコンフィギュレーションでの多数のメディアサーバが必要とされる状況では、ブラウザが接続する必要がある、クラスタ内のすべてのサーバインスタンスは、ＷｅｂＲＴＣ下で機能する、安全性が保証された接続（ＳＳＬ使用可能）に亘って、アクセス可能である。これらの制約は、広範な問題となる可能性がある。なぜなら、ＷｅｂＲＴＣは、近年にてウイルスのための採用がされた、通信のための最適低遅延フレームワークを提示し、利用が増え続けている、からである。従って、ＷｅｂＲＴＣは、デバイス間でマルチメディアをシェアする多数の実装にとって好適なものではあるが、クラスタ／クラウドコンピューティングを用いるインフラストラクチャにて、現在、効率的には利用され得ない。
【０００６】
クライアント、ブラウザを発行する際に配置される上記のサーチの制約は、セキュアクライアントとアンセキュアクライアントの間の接続を妨げるものであり、大抵のウエブページが今日安全に配信されるので、このことは、全てのブラウザ通信のために安全性が保証された接続が絶対的に用いられなければならない、ということを意味する。サービスプロバイダが、（単独のインスタンスにより処理され得るよりも多くのインターネットトラフィックを処理するために）アーキテクチャを外部に拡大することを開始するにつれて、クラスタ内の多数のインスタンスのためにＳＳＬサーティフィケイトを管理しなければならないことに関して問題が発生し、このことにより次は、個々のインスタンスが、ＳＳＬサーティフィケイトだけでなくそれ自身のドメインを有することが要求される。特に、ＳＳＬは、ドメイン名を使用し、サーティフィケイトを認証するエンティティを認可し、これにより、設定内の個々のサーバインスタンスは、通常、異なるドメイン及びそれ自身のＳＳＬサーティフィケイトを要求するものである。
【０００７】
クラウドコンピューティングの発展も、類似の問題点を付随する。クラウドプラットフォームは、それらのアプリケーションプログラムインタフェース（ＡＰＩ)を用いて動的インスタンスマネジメントを提示し、ストリームマネジャ、若しくは他のマネジメントツールを用いるストリーミングセットアップは、クラウドプラットフォームのオートスケーリングフィーチャを利用でき、ネットワークトラフィックが変化するにつれて、サーバノードをリアルタイムで動的に付加／除去し得る。クラスタが手動でセットアップされるのかどうか、若しくは、オートスケーリングにより作成されるのかどうか、に関わりなく、問題点は依然同じである。特に、個々の動的クラウドインスタンスのために、及び、オートスケーリングを介して管理されるインスタンスのために、ドメインをセットアップしてサーティフィケイトをインストールすることは、単調であり、実用的ではない。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
セキュア接続を要求するプロトコルを実装する際、安全性が保証されたデバイスと安全性が保証されないデバイスとの間のセキュア通信の提供を改善する必要がある。この必要に対処する種々の形態の解決策にて、本発明は、更に、他の所望の特性を有するものである。
【課題を解決するための手段】
【０００９】
セキュア接続を要求するプロトコルを実装する際に安全性が保証されたデバイスと安全性が保証されないデバイスとの間にセキュア通信を提供するための改善策のニーズがある。種々の実施形態にて、本発明は、他の望ましい特徴と有することに加えて、このニーズに対処する解決策を提供する。
【００１０】
本発明の例示の実施形態により、安全性が保証されたデバイスと安全性が保証されないデバイスとの間のセキュア通信を提供する方法が、提示される。方法は、セキュア接続を経由してプロキシサービスにて、サブスクライバデバイス上でクライアントからの接続リクエストを受信するステップであって、接続リクエストはターゲットのパブリッシャデバイスのためのノードアドレスを含む、受信するステップと、アンセキュア接続を経由して、プロキシサービスをターゲットのパブリッシャデバイスへ接続するステップと、及び、  サブスクライバデバイスとターゲットのパブリッシャデバイスとの間のブリッジを、プロキシサービスを経由して確立するステップとを含む。方法は、サブスクライバデバイス間の接続をネゴシエートするために、ブリッジに亘ってプロキシチャネルを利用するステップと、及び、サブスクライバデバイス間の接続に亘ってサブスクライバデバイスとパブリッシャデバイスの間でデータを交換するステップとを含む。
【００１１】
本発明の形態により、ドメイン名とセキュアソケットレイヤ（ＳＳＬ）サーティフィケイトを伴って構成されるストリームマネジャサーバ上で、プロキシサービスが実装されている。ストリームマネジャはクラウドインフラストラクチャ上に実装されている。ブリッジを確立するステップは、相互作用接続確立（ＩＣＥ）技術を用いてサブスクライバデバイスとパブリッシャデバイスとの間でセッションセットアップ情報をネゴシエートするステップを含む。
【００１２】
本発明の形態により、ブリッジは、ＷｅｂＳｏｃｋｅｔセキュア（ＷＳＳ）接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、サブスクライバデバイスとプロキシサービスとの間の接続と、及び、ＷｅｂＳｏｃｋｅｔ（ＷＳ）アンセキュア接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、パブリッシャデバイスとプロキシサービスとの間の接続とを含み得る。ブリッジにより、セキュアデータがセキュアサブスクライバデバイスからアンセキュアパブリッシャデバイスへ流れることが可能になる。
【００１３】
本発明の形態により、サブスクライバデバイスは、ウエブブラウザクライアントからプロキシサービスへ接続する。パブリッシャデバイスは、ドメインもＳＳＬサーティフィケイトも伴わないメディアサーバであってよく、マルチメディアを、接続されたサブスクライバデバイスへブロードキャストするように構成されている。接続はサブスクライバデバイスとパブリッシャデバイスとの間の直接接続であってよく、若しくは、接続はネットワークアドレストランスレーション（ＮＡＴ）接続であり、及び、接続はサブスクライバデバイスとパブリッシャデバイスとの間でマルチメディアを交換するように構成されている。
【００１４】
本発明の形態により、プロキシサービスは、ピンガー機構を用いて、サブスクライバデバイスとパブリッシャデバイスとの間のマルチメディアデータの交換の間に、ブリッジをオープンのまま維持するように構成されている。方法は更に、ロードバランサにより、サブスクライバデバイスとパブリッシャデバイスとの間の負荷をバランスするステップを含む。プロキシサービスが、効率性及び信頼性のために、安全性が保証されたデバイスと安全性が保証されないデバイスとの間で、ＷｅｂＲＴＣ情報交換を提供し得る。パブリッシャデバイスは、複数の物理的ノード若しくはバーチャルインスタンスを含むストリーミングクラスタを含み得る。方法は更に、サブスクライバデバイスとパブリッシャデバイスのための元のクライアント情報を追跡するためにカスタムヘッダを作成するステップを含み得る。
【００１５】
本発明の例示の実施形態により、安全性が保証されたデバイスと安全性が保証されないデバイスとの間のセキュア通信を提供するシステムが、提供される。システムは、セキュア接続を経由してサブスクライバデバイスと電子通信するプロキシサービスと、及び、アンセキュア接続を経由してプロキシサービスと電子接続するターゲットのパブリッシャデバイスとを含む。プロキシサービスは、クライアントデバイスから接続リクエストを受信することに応答して、プロキシサービスは、サブスクライバデバイスとターゲットのパブリッシャデバイスとの間のブリッジを、プロキシサービスを経由して確立し、及び、サブスクライバデバイス間の接続をネゴシエートするために、ブリッジに亘ってプロキシチャネルを利用して、サブスクライバデバイス間の前記接続に亘ってサブスクライバデバイスとパブリッシャデバイスの間でマルチメディアのデータの交換を促進するように構成されている。
【００１６】
本発明の形態により、ドメイン名とセキュアソケットレイヤ（ＳＳＬ）サーティフィケイトを伴って構成されるストリームマネジャサーバ上で、プロキシサービスが実装されている。ストリームマネジャは、クラウドインフラストラクチャ上に実装され得る。前記ブリッジを確立するためのプロセスは、相互作用接続確立（ＩＣＥ）技術を用いてサブスクライバデバイスとパブリッシャデバイスとの間でセッションセットアップ情報をネゴシエートすることを含み得る。ブリッジは、ＷｅｂＳｏｃｋｅｔセキュア（ＷＳＳ）接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、サブスクライバデバイスとプロキシサービスとの間の接続と、及び、ＷｅｂＳｏｃｋｅｔ（ＷＳ）アンセキュア接続若しくはハイパーテキストトランスファプロトコルセキュア（ＨＴＴＰ）接続を用いる、パブリッシャデバイスとプロキシサービスとの間の接続とを含み得る。ブリッジにより、セキュアデータがセキュアサブスクライバデバイスからアンセキュアパブリッシャデバイスへ流れることが可能になり得る。
【００１７】
本発明の形態により、サブスクライバデバイスは、ウエブブラウザクライアントからプロキシサービスへ接続する。パブリッシャデバイスは、ドメインもＳＳＬサーティフィケイトも伴わないメディアサーバであり得、マルチメディアを、接続されたサブスクライバデバイスへブロードキャストするように構成されている。接続は、サブスクライバデバイスとパブリッシャデバイスとの間でマルチメディアを交換するように構成され得、及び、接続は、サブスクライバデバイスとパブリッシャデバイスとの間の直接接続であり得、若しくは、ネットワークアドレストランスレーション（ＮＡＴ）接続であり得る。本発明の形態により、プロキシサービスは、ピンガー機構を用いて、サブスクライバデバイスとパブリッシャデバイスとの間のマルチメディアの交換の間に、ブリッジをオープンのまま維持するように構成されている。
【００１８】
プロキシサービスは、更に、ロードバランスにより、サブスクライバデバイスとパブリッシャデバイスとの間の負荷をバランスするように構成され得る。プロキシサービスが、効率性及び信頼性のために、安全性が保証されたデバイスと安全性が保証されないデバイスとの間で、ＷｅｂＲＴＣ情報交換を提供し得る。パブリッシャデバイスは、複数の物理的ノード若しくはバーチャルインスタンスを含むストリーミングクラスタを含み得る。プロキシサービスは、更に、サブスクライバデバイスとパブリッシャデバイスのための元のクライアント情報を追跡するためにカスタムヘッダを作成するように構成され得る。
【図面の簡単な説明】
【００１９】
本発明のこれらの及び他の特性は、以下のような添付の図面と併せて、発明の詳細な説明を参照することにより、より十分に理解されるものである。
【図１Ａ】本発明に係る、ストリーミングクラスタタイプネットワークのための例示の構成である。
【図１Ｂ】本発明に係る、デイジーチェーンクラスタリングタイプネットワークのための例示の構成である。
【図２】本発明に係る、ストリームマネジャルーティングオペレーションのための例示のプロセスである。
【図３】本発明に係る、ストリームマネジャプロキシサーバを用いてマルチメディアセッションを確立するための例示のプロセスである。
【図４】本発明に係る、ストリームマネジャによりオートスケーリングを実装するための例示のプロセスである。
【図５】本発明に係る、ストリームマネジャプロキシサーバの例示のオペレーションである。
【図６】本発明に係る、ストリームマネジャプロキシサーバによりロードバランシングを実装するための例示のプロセスである。
【図７】本発明に係る、例示のコンピュータアーキテクチャである。
【発明を実施するための形態】
【００２０】
本発明の例示の実施形態は、ソケットプロキシングを介して安全性が保証されたデバイスと安全性が保証されないデバイスとの間の通信を提供して、クライアントデバイス（例えば、サブスクライバデバイス）上のクライアントウエブブラウザに、種々のオープンスタンダードにより規定されるセキュリティポリシー（例えばＷｅｂＲＴＣ、ＣＯＲＳ等のポリシー）と適合させる、方法及びシステムに関する。本発明は、セキュアウエブブラウザと、サーバサイド（例えば、パブリッシャサーバデバイス）のアンセキュア接続との間で、データをパスし得るストリームマネジャサーバにより実装される、プロキシサービスを提供する。特に、例示の実施形態では、本発明は、ストリームマネジャデバイスにより実装される仲介プロキシサーバを介してプロキシされるメディアサーバノードに基づく、ウエブブラウザクライアントからＷｅｂＲＴＣ（若しくは類似のプロトコル）へのＷｅｂＳｏｃｋｅｔ通信を利用する。
【００２１】
ＷｅｂＲＴＣ、ＨＴＴＰＳ等のプロトコルを実装する際、サーバが、安全性が保証されて（ＳＳＬ使用可能で）ないならば、通信は機能しなくなる。この問題は、クライアント−サーバ（パブリッシュ）データフローと、サーバ−クライアント（サブスクライブ）データフローとの、両方に当てはまる。本発明のストリームマネジャプロキシサーバは、アンセキュアサーバ内部にホストされるプロキシサーバを提供することによって、アンセキュアサーバアクセス問題を解決する。更に、ＷｅｂＲＴＣセキュリティポリシーは、アンセキュア接続上のクライアント−サーバの接続性のみをブロックするが、サーバ−サーバの接続性をブロックしない。ＷｅｂＲＴＣのこの形態を利用して、ストリームマネジャプロキシサーバは、クライアント−アンセキュアデバイスの通信に改良を生じる、固有の組み合わせのステップを用いるＷｅｂＳｏｃｋｅｔを用いて確立される、あらゆるＷｅｂＲＴＣクライアントの接続に対して、ストリームマネジャプロキシサーバ自身とＷｅｂＲＴＣメディアサーバとの間の、サーバ−サーバのアンセキュア接続を生成する。
【００２２】
本発明のストリームマネジャプロキシサーバを初期化するために、ブラウザクライアントは、クライアントとストリームマネジャプロキシサーバとの間で生成されるセキュアＷｅｂＳｏｃｋｅｔ接続に亘って、ターゲットメディアサーバアプリケーションスコープと共に、ストリームマネジャプロキシサーバが接続することを欲するメディアサーバのパブリックＩＰアドレスを、ストリームマネジャプロキシサーバに提供する。ストリームマネジャプロキシサーバは続いて、それ自身とターゲットメディアサーバとの間のサーバ−サーバ接続を同期して作成する。ストリームマネジャプロキシサーバ−メディアサーバの接続と、クライアント−ストリームマネジャプロキシサーバの接続との対は、セキュアクライアントに、アンセキュアメディアサーバへのトークをさせる、ブリッジを生成する。
【００２３】
ブリッジが確立されると、セキュアクライアントにより通過する全てのパラメータは、アンセキュアターゲットメディアサーバに転送され、全てのパラメータはストリームマネジャプロキシサーバチャネルに到着し、メディアサーバから受けたレスポンスはストリームマネジャプロキシサーバを経由してクライアントへ中継されて戻される。この解決策により、セキュアクライアントは、どこにでも配置されるアンセキュアサーバにトークすることが可能になる。更に、プロキシチャネルは、サーバとクライアントの間のＩＣＥデータ交換及び任意の通信のために、初期化され得る。接続性が確立され、ＩＣＥ交換が成功して完了すると、直接に、若しくは（必要により）ＮＡＴを用いて、オーディオ／ビデオが、クライアントとサーバの間で流れる。プロキシチャネルは、クライアントとメディアサーバとの間の任意の将来の通信に対してアクティブを維持し、アクティブ／オープンを維持した後、クライアントが接続を閉じるときに、若しくは、メディアサーバがプロキシ接続を閉じるときに、終了となる。例えば、セキュア接続とアンセキュア接続の両方は特別の「ピンポン」若しくはピンガー機構を用いて、有益なデータがそれらを介して流れないときでも、ＷｅｂＳｏｃｋｅｔ接続のアライブを保持する。「ピンポン」若しくはピンガー機構は、周知のアクティブステータストラッキングの、例えば、デバイス（及び別のデバイスとの接続）が依然アクティブであるかどうかを見るために周期的にデバイスのネットワーク接続を確認することの、任意の組み合わせを含み得る。この解決策は、クラウドインスタンスと共にマネージドのインスタンスに関して、等しく十分に機能する。
【００２４】
プロキシサービスの実装を介して、本発明は、周知の複数の問題点に対処する、固有の組み合わせのステップを提供する。特に、本発明は、セキュアロケーションから一つ若しくはそれ以上のアンセキュアロケーションにマルチメディアデータが転送される必要がある、リアルタイムのデータ指向アプリケーションに対して、解決策を提供する固有の組み合わせのステップ及び技術を提供する。本発明は、リアルタイムロケーション情報がセキュアアプリケーションからアンセキュアサーバに転送される必要がある、ジオロケーションアプリケーションに関する問題にも対処する。更に、本発明は、アプリケーションが、非パーマネントのＩＰアドレス（パーマネントドメイン名は、ＳＳＬサーティフィケイトに対しては利用可能では無い）によりバーチャルマシンと連動し、セキュアエンドポイントからアンセキュアエンドポイントへＷｅｂＳｏｃｋｅｔに亘ってサーバ間にて転送される必要があるデータを有する、クラウドベースのＷｅｂＳｏｃｋｅｔアプリケーションによって、実装され得る。よって、本発明は、技術の向上（例えば、コンピューティングデバイス及びインターネット）により必要とされる、少なくとも一つの技術エリアへ向上を提供する。
【００２５】
更に、本発明は、ＷｅｂＲＴＣに亘るウエブブラウザを含む例示の実装に、通常、言及するが、ＷｅｂＲＴＣは、モバイルプラットフォーム及びＩｏＴデバイスを含む、非ブラウザデバイスのためのアプリケーションを有しており、よって、本発明は、ウエブブラウザによる利用に限定される意図はない。例えば、本発明は、クラウドフォン若しくはウエブフォンとも称される、ブラウザベースのボイスオーバーＩＰ（ＶｏＩＰ）電話によって利用可能であり、該電話は、ソフトフォン若しくは他の類似の技術をダウンロードしてインストールする、という前提条件に取って換わって、ウエブブラウザ内部から、コールが為されて受信され得る。更に、本発明により提供される解決策は、メディアサーバにより提供されるサービスの範囲に含まれる全てのＷｅｂＲＴＣストリーミングシナリオに対して包括的である。例えば、本発明により提供される解決策は、ＷｅｂＲＴＣに亘る１−多のストリーミング（１パブリッシャ−多サブスクライバ）、ＷｅｂＲＴＣに亘る１−１のストリーミング（チャット）、ＷｅｂＲＴＣに亘る多−多のストリーミング（コンフェレンシング）、ＷｅｂＲＴＣベースのオンラインビデオレコーディング（サブスクライバ無しのパブリッシャ）、接続性のルールがセキュア起源のポリシーに適合するがサーバのためのＳＳＬ使用可能なドメインをセットアップすることができない任意のＷｅｂＳｏｃｋｅｔオービトラリデータトランスミッション等に、適用可能であるが、これらに限定されるものではない。更に、本発明は、ＷｅｂＲＴＣの使用に限定されず、クライアントにアンセキュアデバイスに接続させないプロトコルの任意の組み合わせの範囲内で実装され得る。
【００２６】
図１〜図７では、全体を通して同じ部位には同じ参照数字が割り当てられており、本発明に係る、安全性が保証されたデバイスと安全性が保証されていないデバイスとの間に安全性が保証された通信を提供する、改良されたオペレーションについての、例示の実施形態若しくは複数の実施形態を示す。図面に示す例示の実施形態若しくは複数の実施形態を参照して、本発明を説明するが、当然ながら、多数の別途の形式が本発明を具体化し得るものである。本発明の精神および範囲と共に、依然保持するように開示される実施形態のパラメータを変更する様々な態様を、当業者であれば更に理解するところである。
【００２７】
本発明は、現存の及び将来のストリームマネジャ構成の範囲内での実装のためのプロキシソリューションを提供する、方法及びシステムに関する。当業者には理解されるところであるが、ストリームマネジャは、マルチメディアストリーミングの周囲に集中するアプリケーションプログラムインタフェース（ＡＰＩ）として構成されるアクトであってもよい、ウエブサーバ若しくは他のコンピューティングインフラストラクチャ上で稼働する、ソフトウエアアプリケーションである。本発明により提供されるプロキシソリューションは、マルチメディアを（例えば、ウエブブラウザを介して）エンドユーザデバイスに提供するように構成された、ストリームマネジャ及び他のマルチメディアマネジメントソリューションの、任意の組み合わせにより実装され得る。例えば、本発明により提供されるプロキシソリューションは、（クラウド上に提供されるバーチャルマシンの代りに、マネージドの物理ハードウエアから成る）クラウドインフラストラクチャ、若しくはホスト型の／マネージドのインフラストラクチャ上で実装されるストリームマネジャの内部で、展開され得る。更に、本発明により提供されるプロキシソリューションは、ストリームマネジャ用語と併せて、説明され得る。なぜなら、技術的改良はストリームマネジャ上に実装され、他のサービスと同時に稼働するからである。しかしながら、本発明のプロキシソリューションは、ストリームマネジャの性能に直接的に依存する、というものではなく、データがセキュアエンドポイントとアンセキュアエンドポイントとの間で転送される、任意のブラウザベースのアプリケーションに、拡張され得る。
【００２８】
ストリームマネジャプロキシソリューションは、拡張可能なバーチャルシステムにより動作するようにも適用され得る。クラウドインフラストラクチャでは、例えば、ストリームマネジャは、接続クライアントによりシステムにて（例えば、サブスクライバデバイスにて）負担する負荷に基づいて、バーチャルマシンイメージから動的にクラウドインスタンスをスピンアップしスピンダウンする管理を行うことができる。特に、ストリームマネジャは、クラウドプラットフォームのＡＰＩを用いて、インスタンスタイプ、インスタンスタグ（メタ）、マシンイメージ識別子などの、更なるパラメータを提供することによりインスタンスの創作を、及び／又は、削除を要求し得る。クラウドインフラストラクチャ内でストリーミングインフラストラクチャをスケールアップすることは、（図４に示すような）メディアサーバノードのクラスタを創作して、単独のサーバインスタンスにより処理され得るよりも多くのインターネットトラフィックを処理することを、含み得る。本発明は、任意の組み合わせのネットワーク構成で実装され得る。
【００２９】
図１Ａは、サーバノードの意図される役割及び能力に基づいて、ストリーミングマネジメントのために集められたサーバノードを含む従来のストリーミングクラスタ１００の例を示す。特に、図１Ａは、パブリッシャデバイス１０２が、消費のためにサブスクライバデバイス１０４にコンテンツをどのように発行し得るかを示す。当業者に理解されるように、パブリッシャデバイス１０２は、要求するユーザ／デバイスに対するマルチメディアを提供する／受け取るように構成されている任意の組み合わせのコンピューティングデバイスを、含み得る。同様に、サブスクライバデバイス１０４は、他のデバイスに対してマルチメディアを要求する／マルチメディアを提供するクライアントにより構成されている任意の組み合わせのコンピューティングデバイスを、含み得る。例えば、パブリッシャデバイス１０２は、他のユーザ（例えば、サブスクライバ）に提供されるワンウエイストリーミングサービスを、又は、ツーウエイストリーミングサービス（例えば、データ、ビデオ、オーディオ、若しくはそれらの組み合わせ）を、ホストするように構成されたサーバであってもよい。図１Ａの例示のシステム１００では、パブリッシャデバイス１０２は、発端デバイス１０６（若しくは取り込みエンドポイント）を介してネットワークに亘って通信し、サブスクライバデバイス１０４は、エッジデバイス１０８を介してネットワークに亘って通信する。当業者に理解されるように、発端デバイス１０６及びエッジデバイス１０８は、周知の、コンピューティングデバイス若しくはバーチャルマシンのインスタンスの、任意の組み合わせでもよく、１台のパブリッシャデバイス１０２若しくはサブスクライバデバイス１０４よりも多くの台数を扱うように構成されてもよい。発端若しくはエッジデバイスは、遠隔デバイス（例えば、サブスクライバ／パブリッシャデバイス）の間にて信頼性のある接続を確立するように提供され得る。
【００３０】
当業者に理解されるように、システム１００は、相互に直接接続する発端ノード１０６とエッジノード１０８との二重システムに限定されない。ある構成では、図１Ｂに示されるように、一つ以上の仲介ノード１１０が、遠隔発端ノード１０６とエッジノード１０８エンドポイントとの間のトラフィックをブリッジする、デイジーチェーンの形式で、発端ノード１０６とエッジノード１０６が、繋がり得る。ストリーミングシステムでの仲介ノード１１０の使用は、通常、地理的配布のためであり、多数の分散配置からのクライアントに最小限の待ち時間で接続させるため、である。ストリーミングシステムにて仲介ノード１１０を使用することにより、単独の発端ノード１０６が多数のエッジノード１０８に配信できるものの容量が、拡張されることも可能になる。更に、ノード若しくはサーバを中継することが、発端ノード１０６とエッジノード１０８との間で初期化されると、個々の中継が処理し得るエッジノード１０８の接続の数により、容量が拡張し得る。  
【００３１】
ネットワーク構成に関わらず、最初は、パブリッシャデバイス１０２とサブスクライバデバイス１０４は、（例えば、ストリーミングセッションの前に）必ずしも相互に直接接続しない。従って、パブリッシャデバイス１０２とサブスクライバデバイス１０４との間を調整してマルチメディアを交換するための接続を確立するメカニズムが、要求され得る。ある実施形態では、ストリームマネジャデバイス２１０が、パブリッシャデバイス１０２とサブスクライバデバイス１０４との間で、接続を確立して通信を管理するように構成され得る。ある実施形態では、ストリームマネジャデバイス２１０は、ドメイン名を伴うプロキシサーバであってもよく、ＳＳＬサーティフィケイトがインストールされている。ストリームマネジャプロキシサーバ２１０は、到来するクライアント接続を処理し、パブリッシャデバイス１０２とサブスクライバデバイス１０４との間のプロキシ接続を管理し、及び、受信される内容を何ら変更すること無く、パブリッシャデバイス１０２とサブスクライバデバイス１０４との各々から受信される情報の全てをプロキシする、ように、ＷｅｂＳｏｃｋｅｔデータリスナを登録するように、構成されてもよい。ストリームマネジャデバイス２１０は、プロキシ接続に亘る遠隔プロシジャコール（ＲＰＣ）を許可し、遠隔メディアサーバからのクライアント方法の起動を許可し、ネゴシエーションが完了した後でさえ接続がアライブを保持されてオブザーバとなることを保証し、接続若しくはプロキシ接続のいずれかが終了するならば通信ブリッジを終了する、ように構成されてもよい。当業者に理解されるように、デバイス間の通信は双方向であってもよく、これによりいずれかのデバイスは情報の交換を開始できる。例えば、パブリッシャデバイス１０２若しくはサブスクライバデバイス１０４（クライアント）は、ストリームマネジャデバイス２１０（サーバ）上の何かをコールすることができ、ストリームマネジャデバイス２１０は、特定のパブリッシャデバイス１０２若しくはサブスクライバデバイス１０４をコールでき、又は、パブリッシャデバイス１０２若しくはサブスクライバデバイス１０４はお互いにコールできる。同様に、単独のストリームに接続する全ての、パブリッシャデバイス１０２若しくはサブスクライバデバイス１０４に、通知を送ることができる。
【００３２】
図２は、発端ノード１０６とエッジデバイス１０８の利用を介してパブリッシャデバイス１０２とサブスクライバデバイス１０４との間の接続を確立する、ストリームマネジャプロキシサーバ２１０についての例示の実装及びプロセス２００を示す。当業者に理解されるように、プロセス２００を利用し、任意の組み合わせの仲介の発端デバイス１０６及び（もしあれば）エッジデバイス１０８を用いて、任意の数のパブリッシャデバイス１０２若しくはサブスクライバデバイス１０４を接続し得るが、プロセス２００は図２に示す構成に限定されることは意図されていない。
【００３３】
プロセス２００のステップ１では、ストリームマネジャプロキシサーバ２１０が、パブリッシャデバイス１０２からのリクエストを受信し得る。例えば、パブリッシャデバイス１０２は、ストリームマネジャプロキシサーバ２１０にリクエストを転送し、サブスクライバに利用可能なマルチメディアストリームを作成する。プロセス２００のステップ２ではストリームマネジャプロキシサーバ２１０は、（例えば、データストア２２０から）ブロードキャストのために利用可能な発端ノード１０６を検索し、利用すべき発端ノード１０６を選択する。当業者に理解されるように、任意の組み合わせの選択方法及び基準は、ノードを選択するのに利用され得る。例えば、ストリームマネジャプロキシサーバ２１０は、ラウンドロビン、ロジスティック回帰、又は、帯域幅などの乱数ジェネレータ及び基準、ＣＰＵ、ＲＡＭ負荷、ジオロケーションなどを利用して、利用可能な発端ノード１０６のリストから発端ノード１０６を選択できる。プロセス２００のステップ３では、ストリームマネジャプロキシサーバ２１０は、選択された発端ノードを、リクエストするパブリッシャデバイス１０２に戻す。プロセス２００のステップ４では、パブリッシャデバイス１０２は、ストリームマネジャプロキシサーバ２１０により提供される情報を利用して、選択された発端ノード１０６に接続する。
【００３４】
プロセス２００は、リクエストするサブスクライバデバイス１０４のためにエッジノード１０８を確立するとき、同様のステップのセットを追随する。特に、プロセス２００のステップ５では、ストリームマネジャプロキシサーバ２１０は、サブスクライバデバイス１０４からリクエストを受信し得る。例えば、サブスクライバデバイス１０４は、リクエストをストリームマネジャプロキシサーバ２１０に転送して、マルチメディアブロードキャストにアクセスするための、エッジノード１０８への接続アクセスを作成することができる。プロセス２００のステップ５の間に、ストリームマネジャプロキシサーバ２１０は、（例えば、データストア２２０から）利用可能なエッジノード１０８を検索し、（例えば、発端ノード１０６を介して）ブロードキャストに接続するために利用するエッジノード１０８を選択することができる。例えば、ストリームマネジャプロキシサーバ２１０は、ラウンドロビンや乱数ジェネレータを利用して、利用可能なエッジノード１０８のリストからエッジノード１０８を選択することができる。
【００３５】
プロセス２００のステップ６では、ストリームマネジャプロキシサーバ２１０は、リクエストするサブスクライバデバイス１０４に、選択されたエッジノード１０８を戻す。プロセス２００のステップ７では、サブスクライバデバイス１０４は、ストリームマネジャプロキシサーバ２１０により提供された情報を利用して、選択されたエッジノード１０８に接続することができる。プロセス２００のステップ７の後、ストリームマネジャプロキシサーバ２１０によって個々のデバイス１０２、１０４に提供された発端ノード１０６とエッジノード１０８を経由して、パブリッシャデバイス１０２とサブスクライバデバイス１０４との間にて接続が確立された。この後、この接続を利用してデバイス間でマルチメディアをストリームし得る。更に、当業者に理解されるように、プロセス２００は、（例えば、図３に示すように）発端ノード１０６及び／又はエッジノードを含まないシステムで、実装され得る。
【００３６】
ある実施形態では、本発明は、ブラウザクライアント（例えば、サブスクライバデバイス１０４）と、マルチメディアコンテンツを提供するメディアサーバ（例えば、パブリッシャデバイス１０２）との間にて、信頼性のある双方向通信を可能にするように構成されてもよい。例えば、本発明は、本発明は、（例えば、プロセス３００を用いて）クラウドコンピューティングプラットフォーム上のブラウザクライアントとサーバとの間のＷｅｂＲＴＣ情報交換を利用することにより、モバイルコンピューティングデバイス上のブラウザとクラウドプラットフォーム上のサーバとの間に、双方向の通信を提供し得る。ＷｅｂＲＴＣ通信をセットアップする際、ＷｅｂＲＴＣ信号伝達を利用して、２参加者間で相互に情報が交換され、マルチメディアストリーミングセッションがセットアップされる。このことは、信号伝達及びネゴシエーションとしても周知であり、信号伝達及びネゴシエーションが製鋼するために、ＷｅｂＲＴＣ通信は、参加者の一がセキュア接続状態であることを要求する。
【００３７】
図３は、システム１００にてＷｅｂＲＴＣ通信をセットアップするための信号伝達及びネゴシエーションのプロセス６００の例示の実装を示す。特に、図３は、仲介としてストリームマネジャプロキシサーバ２１０を用いて、サブスクライバデバイス１０４とパブリッシャデバイス１０２との間のＷｅｂＲＴＣ通信を確立するための、例示のプロセス３００の概観を示す。最初に、ストリームマネジャプロキシサーバ２１０は、セキュアサーバとしてセットアップされる。例えば、ストリームマネジャプロキシサーバ２１０は、セキュア接続の一部として用いられ得るように、ドメイン名及びＳＳＬサーティフィケイトを伴って作成される。ストリームマネジャプロキシサーバ２１０は、（例えば、サブスクライバデバイス１０４とエッジノード１０８の間にて、及び／又は、ブロードキャスタ１０２と発端ノード１０６との間にて）ブロードキャスタデバイス１０２とサブスクライバデバイス１０４のためのエントリポイントとして、構成され得る。ＳＳＬサーティフィケイトは、（例えば、ＷｅｂＲＴＣ通信を経由して）リアルタイム通信のセットアップを許容し、ウエブブラウザにより強制されるルールによるコンプライアンス（例えば、クロスオリジンリソースシェアリング（ＣＯＲＳ））を許容する。更に、ＳＳＬは、ＷｅｂＲＴＣの信号伝達フェーズのために要求され、該フェーズは、ＨＴＴＰＳ、若しくはＷｅｂＳｏｃｋｅｔセキュア（ＷＳＳ）に関して為され得る。信号伝達が完了すると、ストリームマネジャプロキシサーバ２１０プロキシノードは最早要求されず、（例えば、サブスクライバデバイス１０４上の）ブラウザは別のノード（例えば、発端ノード１０６若しくはパブリッシャデバイス１０２）と直接接続して、マルチメディアを交換できる。このことは、ＷｅｂＲＴＣなどのプロトコルの利益をもたらすものであり、このときこのプロトコルを利用しようとするセキュアデバイス及びアンセキュアデバイスにより作られる制約は無い。
【００３８】
プロセス３００のステップ１では、サブスクライバデバイス１０４上のクライアントは、セキュア接続に亘ってストリームマネジャプロキシサーバ２１０に接続する。サブスクライバデバイス１０４は、マルチメディアを交換することを欲する、意図されるパブリッシャデバイス１０２（例えば、メディアサーバ）に対して、送信も対処も行う。例えば、ＷｅｂＳｏｃｋｅｔセキュア（ＷＳＳ）を用いてストリームマネジャプロキシサーバ２１０への接続をネゴシエートし得、パブリッシャデバイス１０２のメディアサーバに対してターゲットＩＰを提供し得る。
【００３９】
プロセス３００のステップ２では、（クライアントのサブスクライバデバイス１０４により提供される）パブリッシャデバイス１０２のためのターゲットアドレスを用いて、ストリームマネジャプロキシサーバ２１０は、（ターゲットのパブリッシャデバイス１０２メディアサーバがドメイン名／ＳＳＬを有しないときの）アンセキュア接続では無く、それ自身とターゲットのパブリッシャデバイス１０２メディアサーバとの間のサーバ−サーバ接続を確立することができる。例えば、ストリームマネジャプロキシサーバ２１０は、プライベートクラウドネットワーク上のアンセキュアデバイスへ接続するＷｅｂＳｏｃｋｅｔ（ＷＳ）プロトコルを用いて、サーバ−サーバ接続を確立することができる。サブスクライバデバイス１０４によるセキュアＷｅｂＳｏｃｋｅｔ接続と、パブリッシャデバイス１０２によるサーバ−サーバ接続との、組み合わせは、ストリームマネジャプロキシサーバ２１０を経由して（例えば、ＷｅｂＳｏｃｋｅｔに亘る双方向メッセージングを経由して）サブスクライバデバイス１０４とパブリッシャデバイス１０２との間に、トラバースブリッジを創作する。確立されると、ブリッジは、セキュアデータがアンセキュアエンドポイントへフローすること、及びアンセキュアデータがセキュアエンドポイントへフローすることを、通常それら機能を許可しないプロトコル（例えば、ＷｅｂＲＴＣ）内部に実装されても、可能にするプロキシチャネルを提供する。従って、ストリームマネジャプロキシサーバ２１０は、（例えば、サブスクライバデバイス１０４上の）ウエブブラウザ
と、通常許容されないアンセキュアメディアデバイス（例えば、パブリッシャデバイス１０２）との間にてＷｅｂＲＴＣ通信確立するのに用いられ得る。本明細書に提示される例は、信号伝達及びプロキシのためにＷｅｂＳｏｃｋｅｔを利用することに関連するが、本発明は、ＷｅｂＲＴＣ信号伝達のためにＷｅｂＳｏｃｋｅｔを用いることに限定されるものでは無い。本発明の範囲から乖離すること無く、デバイス間にて信号伝達データを送信する技術の任意の組み合わせが利用され得る。例えば、ＨＴＴＰはＷｅｂＳｏｃｋｅｔと同様の機能及び制約を有するので、本発明は、クラスタノード上の非セキュアＨＴＴＰ接続へセキュアＨＴＴＰＳコールをセキュアするのに用いられ得る。
【００４０】
ある実施形態では、ストリームマネジャプロキシサーバ２１０は、プロキシチャネルに亘って通信するために、ソケットプロキシサービス、ターゲットメディアサーバインスタンス、及びクライアントをホストするように、構成されている。例えば、ＷｅｂＲＴＣの実装では、ストリームマネジャプロキシサーバ２１０は、プロキシに亘って通信するＪａｖａＳｃｒｉｐｔ（登録商標）を用いて、ターゲットメディアサーバインスタンス、及びＷｅｂＲＴＣクライアントにより、ＷｅｂＳｏｃｋｅｔプロキシプロトコルをホストする。特に、ストリームマネジャプロキシサーバ２１０は、二つのピアデバイス（例えば、サブスクライバデバイス１０４とパブリッシャデバイス１０２）がオープンＷｅｂＲＴＣスタンダードを用いて相互に通信をする、全てのサービス及びプロトコルを促進するように、構成され得る。
【００４１】
ＷｅｂＲＴＣセッションを初期化するために、ストリームマネジャプロキシサーバ２１０へのプロキシチャネル接続が確立された後には、ピアデバイスの両方は、相互のロケーション、性能、及び他方の必要な詳細（例えば、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）スタンダード）について、知らなければならない。このステップは、ピアディスカバリとして知られており、ある実施形態では、信号伝達は、ピアディスカバリのためのプロキシチャネルに亘って、サブスクライバデバイス１０４とパブリッシャデバイス１０２との間で、交換される。通常、ＷｅｂＲＴＣプロトコルを利用する際には、交換される、少なくとも二つのタイプの信号伝達データがある。それらタイプは、セッションディスクリプションプロトコル（ＳＤＰ）セッションコントロールメッセージとＩＣＥ候補を含む。ＳＤＰは、メディア可能デバイスの性能を記述するためのフォーマットである。本発明では、メディア可能デバイスは、発端ノード１０６、エッジノード１０８、サブスクライバデバイス１０４、及び、パブリッシャデバイス１０２のうちの、いずれでもよい。信号伝達／ピアディスカバリプロセスの間に、ＳＤＰを用いて、デバイスは、相互に、それらの性能のリスト（例えば、どのコードをそれが使用できるか、それが生成できる解決策、及び、ストリームをセットアップするための他の詳細な情報、等）を各々送信できる。
【００４２】
共有する情報及び性能に基づいて、デバイスの各々が、相互に通信する方法について同意すると、プロセス３００は、ＩＣＥ候補フェーズ（ステップ３）に移る。ＩＣＥは、インターネットに亘ってデバイス間で接続を確立する助けをするのに用いられるプロトコルである。ＩＣＥ候補内の情報は、転送のためにＵＤＰを用いるのかＴＣＰを用いるのか、クライアントのＩＰアドレス、及び、ピアへの直接接続を作成するための他のディテールを、含む。特に、ＩＣＥは、ピアデバイスを接続するための最良のパスを見出すのに利用される。当業者に理解されるように、最良のパスは、デバイス間の直接接続であることもあり、直接接続が可能でない場合にも（即ち、ネットワークアドレストランスレーション（ＮＡＴｓ）の背後で）提供され得る。
【００４３】
ＩＣＥは、デバイスを接続する助けとなる、ＮＡＴに対するセッショントラバーサルユーティリティ（ＳＴＵＮ）、及び、ＮＡＴ周りのトラバーサルユージングリレイ（ＴＵＲＮ）として知られる、二つのサブプロトコルも含み得る。ＳＴＵＮサーバは、ファイアウオール／ＮＡＴｓをバイパスするのに用いられ、ＴＵＲＮサーバは、直接のピアツーピア（Ｐ２Ｐ）接続がＳＴＵＮを用いても確立され得ないならば用いられ得る、ＳＴＵＮの拡張である。それらの個々の機能を可能にするため、ＳＴＵＮサーバにより、クライアントは、それらのパブリックアドレス、それが背後にあるＮＡＴのタイプ、及びＮＡＴにより特定のローカルポートと関連するインターネットサイドポートを、見出すことができ、また、ＴＵＲＮサーバは、クライアントがそのようなリレイからＩＰアドレス及びポートを入手できる、プロトコルを用いる。ＳＴＵＮサーバ及びＴＵＲＮサーバは、本発明に係る、ＷｅｂＲＴＣ接続をセットアップし得る基礎となり得る。ＩＣＥ候補、及びＳＴＵＮ／ＴＵＲＮサーバの詳細は、信号伝達ステージの間に、通信され得る。更に、ブラウザクライアントは、利用されることが望ましいＳＴＵＮ／ＴＵＲＮサーバを規定するＡＰＩを含むことがある。
【００４４】
ピアディスカバリが完了し、ＩＣＥデータが取得されると、ピアデバイスはこのデータを相互に交換し、これによりＷｅｂＲＴＣセッション（例えば、マルチメディアストリーミング）がそれらデバイス間で確立され得る。ＩＣＥデータは、クライアントとメディアサーバとの間の標準のＷｅｂＳｏｃｋｅｔプロキシ接続に関して、完遂され得る。ある実施形態では、ピアデバイス間でＩＣＥデータをリレイするべく適切なメッセージフォーマットを生成するために、ＷｅｂＳｏｃｋｅｔチャネルが、サブスクライバデバイス１０４と、プロキシチャネル上のパブリッシャデバイス１０２との間で、確立される。
【００４５】
その後、プロセス３００のステップ４では、デバイス間で接続が確立され得、それらの間で直接、又は、直接のデータフローが可能でないならばＳＴＵＮサーバ／ＴＵＲＮサーバに亘るＮＡＴを経由して、マルチメディアストリームが流れ得る。留意すべきことであるが、プロキシチャネルは、ディスカバリを管理し、セキュアデバイスとアンセキュアデバイスとの間の接続を確立して維持するのに、用いられ得、一方で、デバイス間の（若しくは、ＮＡＴに亘る）接続はデバイス間でマルチメディアを共有するのに利用される。
【００４６】
ある実施形態では、ストリームマネジャプロキシサーバ２１０は、ＷｅｂＳｏｃｋｅｔに亘っていつでも多数のＷｅｂＳｏｃｋｅｔプロキシブリッジを生成する接続マネジメントのための、標準のメカニズムを実装し得る。これにより、ストリームマネジャプロキシサーバ２１０は動的環境（例えば、バーチャルデバイス）で利用されることが可能となり、多数のインスタンスが特定のパブリッシャに対して稼働する。例えば、ストリームマネジャプロキシサーバ２１０は、クラウド環境に実装されたパブリッシャデバイス１０２により稼働するように構成される。クラウドインフラストラクチャ上のストリーミング、若しくは、任意の大規模展開を稼働する際、クラウドコンピューティングで用いられる最も有用で効果的な特徴は「オートスケーリング」である。オートスケーリングにより、システムは、トラフィック／ディマンドが縮小若しくは拡張する際にメディアサーバインスタンスを加えること、及び／又は除去することにより、サーバフリートのサイズを動的にスケールすることができる。例えば、メディアサーバはより多くのクライアントリクエストを有するので、システムは、オートスケールしてバーチャルマシンの数を拡張し、リクエストを促進してマルチメディアのストリームクオリティを維持することができる。
【００４７】
図４は、ストリームマネジャプロキシサーバ２１０を用いてオートスケーリングすることの例を示す。図４の例示の実装では、図４の左部のクラスタは、到来するストリームにために用いられる発端サーバ１０６、及び二つのエッジノード１０８を有する。閾値に到達し、エッジノードへ接続するサブスクライバクライアントのためにクラスタがより多くの容量を必要とすることが、（ストリームマネジャ２１０上の構成に基づいて）ストリームマネジャ２１０により検出されると、システムは、「スケールアウト」する。スケールアウトは、ストリームマネジャ２１０が（例えば、クラウドネットワークＡＰＩを用いて）新しいバーチャルインスタンスをスピンアップし、図４の右部上のクラスタに示すように、役割を新しいインスタンスに割り当てることを、意味する。ある実施形態では、図４に示すように、エッジノード１０８は、エントリポイントとして新しいインスタンスに割り当てられ得る。同様に、ノード上の負荷が（ストリームマネジャ２１０で再び規定される）最小限閾値に到達すると、ストリームマネジャ２１０はエントリエッジノード１０８を余分のクラスタに「スピンダウン」し、クラスタを除去する（例えばスケールインする）ことができる。当業者に理解されるように、図４は（インスタンスのクラスタにアクセスする）エッジノード１０８によりスケールインしスケールアウトすることを示すが、同じシステム１００は、システム１００上により多くのパブリッシングクライアントを許容する必要に基づいて、新しい発端ノード１０６をスピンアップしスピンダウンするのに、用いられ得る。更に、当業者に理解されるように、提示されるシステムは、仮想化されたマシンインスタンスを伴うクラウドインフラストラクチャのみに限定されるものでは無い。同じように物理的ハードウエアベースのホストされるノードによっても用いられ得る。例えば、同じインフラストラクチャは、物理的ハードウエアのために用いられ得、メディアサーバノードのこれらの物理的インスタンスをオンライン及びオフラインの状態にし得る。
【００４８】
続いて図４に関して、複数のエッジデバイス１０８及び発端デバイス１０６を含む、多数のクラスタにより、クラウドコンピューティング環境が示される。クラウドコンピューティングの一つの利点は、複数のコンピューティングエンティティをオートスケールすることができることである。当業者に理解されるように、クラウドコンピューティング環境でオートスケールする際には、サーバインスタンスは動的インスタンスとしてリアルタイムで創作され除去される。しかしながら、動的インスタンスは、それらのＩＰアドレスがシステムスタートアップの間に変化するので、真に「動的」であり、これにより、時間及び利用可能性の複雑性を前提とすると、システムアドミニストレータが、セキュアソケットレイヤ（ＳＳＬ）サーティフィケイトをこれらのインスタンス上にインストールすることは、可能では無い。システムがオートスケーリングシステムを使用しなくとも、手動で管理されるセットアップ上であってもＳＳＬ使用可能ノードをスケールすることについての問題点がなお存在する。あらゆる現存するＷｅｂＲＴＣサーバのために手動でインスタンス上にＳＳＬをインストールしなければならないことと、新しいインスタンスを加える際に同じことをしなければならないこととは、非常に時間を浪費し実現困難となり得る。従って、発端ノード１０６及びエッジノード１０８を含むストリーミングクラスタは、それらの上にＳＳＬを添えないことがある。それらは、一時的にアロケートされるＩＰアドレスを伴う動的クラウドインスタンスであるからである。従って、発端ノード１０６及びエッジノード１０８は、ＷｅｂＲＴＣインタフェースによるセキュア接続とは、考慮されないことがあり、本発明のプロキシサーバを利用して相互作用し得る。
【００４９】
ある実施形態では、ストリームマネジャプロキシサーバ２１０は、クラウドプラットフォームのＡＰＩと連結して設けられ、ストリーミングアーキテクチャに動的オートスケーリング機能を提供する。言い換えれば、アンセキュアエンドポイント（例えば、動的エンドポイント）からＷｅｂＲＴＣ通信を可能にするために、本発明は、ストリームマネジャプロキシサーバ２１０を介して、ＷｅｂＲＴＣ参加者とクラウド／バーチャルインスタンスとの間のネゴシエーションを提供する。このことにより、ＷｅｂＲＴＣプロトコルを利用することの利点を犠牲にすることなく、ネットワークの負荷に依存して、システムは、効率的にスケールアウトしスケールインすること（例えば、ロードバランシング）が可能になる。図３に関して説明したように、この構成では、ストリームマネジャプロキシサーバ２１０インスタンス自身は、ＷｅｂＲＴＣサービスをホストするための登録パブリックドメイン名によりＳＳＬ使用可能であり、（例えばアンセキュアデバイスが参加者であることから）それら自身上では為し得無いデバイスに対してＷｅｂＳｏｃｋｅｔプロキシサービスを提供できる。よって、ストリームマネジャプロキシサーバ２１０は、クラウド（若しくは類似の）環境内の、複数のセキュアサブスクライバデバイス１０４クライアントとアンセキュアパブリッシャデバイス１０２との間でＷｅｂＲＴＣセッションセットアップ情報をパスするように構成されたネゴシエータとして動作し得、このことにより、パブリッシャデバイス１０２がセキュア接続（例えば、ドメイン名をインストールしたＳＳＬ）を提供するか否かに拘わり無く、強制的セキュア接続性ポリシーをバイパスする。
【００５０】
ある実施形態では、プロキシサーバ２１０は、パブリッシャデバイス１０２のための複数の発端ノード１０６の間の接続をセットアップするのに用いられ得る。図５は、ストリームマネジャプロキシサーバ２１０が、パブリッシャデバイス１０２（例えば、メディアサーバ）のための、複数のサブスクライバデバイス１０４と複数の発端ノード１０６との間の接続をセットアップするのにどのように用いられ得るかを、示す。図５に示すように、ストリームマネジャプロキシサーバ２１０は、ドメイン名（例えば、ＤＯＭＡＩＮ１.ＣＯＭ）と関連し得、ＳＳＬサーティフィケイトを有し得る。動作時には、サブスクライバデバイス１０４は、ＷＳＳを用いてストリームマネジャプロキシサーバ２１０へ直接接続し、サブスクライバデバイスがマルチメディアを共有することを望むパブリッシャのために発端ノード１０６のＩＰアドレスを共有する。この後、ストリームマネジャプロキシサーバ２１０は、提供されたＩＰアドレス及びＷＳを用いて、特定された発端ノード１０６と直接接続して、サーバ−サーバ接続を確立できる。そのプロセスが完了すると、（発端ノード１０６を経由する）ブロードキャスタデバイス１０２とサブスクライバデバイス１０４は、図５に示すように、相互にマルチメディアを直接共有し得る。又別に、直接の共有が可能で無いならば、ブロードキャスタデバイス１０２とサブスクライバデバイス１０４は、図３に関して本明細書でより詳細に説明したように、ＮＡＴに亘ってマルチメディアを共有し得る。図５は、サブスクライバデバイス１０４と発端ノード１０６の利用を示すが、本発明の範囲から乖離すること無く、デバイス接続の任意の組み合わせが利用され得る。例えば、ストリームマネジャプロキシサーバ２１０が、サブスクライバデバイス１０４とパブリッシャデバイス１０２の間の唯一の接続であってもよいし、（例えば、図１Ａ、１Ｂ及び２に関して説明した構造と類似する、）サブスクライバデバイス１０４とパブリッシャデバイス１０２の間の接続を促進する、発端ノード１０６とエッジノード１０８のネットワークがあってもよい。
【００５１】
ある実施形態では、ストリームマネジャプロキシサーバ２１０は、カスタムヘッダを用いてプロキシ接続に亘って、クライアントのオリジナルＩＰアドレスを獲得して伝達することを、促進し得る。一般に、プロキシにより、発信元のクライアントＩＰアドレスは、プロキシのＩＰアドレスにより上書きされ、ヘッダは、プロキシの背後の元クライアントについての情報の詳細を提供し得る。クライアントの元ＩＰがサーバに転送されないならば、異なる位置から接続を区別して追跡することは困難である。固有のヘッダを利用し、ストリームマネジャプロキシサーバ２１０は、カスタマヘッダを用いて元クライアント情報を保存して転送することができ、これにより、ネットワークに亘るメディアサーバノードは、クライアントの元ＩＰアドレスを知る。これは、分析の、ジオマッピングのロケーションベースの認証に対して、有益及びそれ以上である。
【００５２】
本発明に係る、使用のためのヘッダの例は、以下の通りである。
［数１］
{Sec-WebSocket-Key=XsuhAp80WSWenevmuVlFeQ==,X-Forwarded-For-Meta-Port=52965, X-Forwarded-For-Meta-Type=WEB, User-Agent=Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0, Sec-WebSocket-Version=13, X-Forwarded-For=192.168.1.45, X-Forwarded-For-Meta-Secure=false, Sec-WebSocket-Protocol=json}
【００５３】
Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒブロックは、発信元のクライアントのＩＰアドレスのために用いられてもよい。Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ−Ｍｅｔａ−Ｓｅｃｕｒｅブロックは、クライアントセッションがセキュア接続を超えるか（否か）をリレイするのに用いられてもよい。この情報は、ＷｅｂＳｏｃｋｅｔ接続オブジェクトを介して取得され得る。Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ−Ｍｅｔａ−Ｐｏｒｔブロックは、発信元のクライアントのポートを関連付けるのに用いられてもよく、Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒ−Ｍｅｔａ−Ｔｙｐｅブロックは、発信元のクライアントの接続タイプについての情報を提供するのに用いられてもよい。
【００５４】
ある実施形態では、ストリームマネジャプロキシサーバ２１０は、クラウドロードバランサソリューションにより稼働して、それを通過するネットＷｅｂＲＴＣプロキシ接続のための容量をスケールアップする助けとなるように設計されている。当業者に理解されるように、任意のロードバランスするＴＣＰ／ＵＤＰベースのシステム、及び、アーキテクチャ（クラウド若しくは非クラウド環境）の組み合わせが、本発明の範囲から乖離すること無く、用いられ得る。動作時には、一つ以上のストリームマネジャプロキシサーバ２１０インスタンスは、クラウドインフラストラクチャ上で創作され得、クラウドプラットフォームにより提供されるロードバランサを用いてインスタンスをロードバランスし得る。個々のストリームマネジャプロキシサーバ２１０インスタンスは、メディアサーバエンドポイント（例えば、パブリッシャデバイス１０２若しくは発端ノード１０６）へのそれ自身のプロキシ接続を管理し得、プロキシするための個々のクライアントＷｅｂＳｏｃｋｅｔ接続（例えば、サブスクライバデバイス１０４若しくはエッジノード１０８）は、ロードバランサに亘って確立される。
【００５５】
図６は、ロードバランサ２３０がシステム１００内部に実装される、例示の実装を示す。特に、図６は、ロードバランサ２３０を伴うシステム１００の例示の実装を示し、ロードバランサ２３０がサブスクライバデバイス１０４及びパブリッシャデバイス１０２とどのように相互作用するかを示す。動作時には、マルチメディアデータは、ウエブブラウザクライアントＷｅｂＳｏｃｋｅｔ接続から受信され、ロードバランサを介してプロキシされ、続いて、意図するメディアサーバノードに到達する前にストリームマネジャプロキシサーバ２１０を介してプロキシされる。最初に、サブスクライバデバイス１０４上のクライアントは、消費プロキシサーバに対する（例えば、ウエブブラウザを経由するアンセキュアメディアサーバへの接続に対する）リクエストを提出する。クライアントにより提出される個々のプロキシリクエストに対して、ロードバランサ２３０は、それらの各々に対する、現存のトラフィック／ネットワークステータスに基づいて、使用すべき異なるストリームマネジャプロキシサーバ２１０インスタンスを選択し得る。その後、クライアントは、ターゲットのパブリッシャデバイス１０４に対するＩＰアドレスを提供することにより、ストリームマネジャプロキシサーバ２１０により提供されるプロキシサービスへ接続し、（例えば、図２〜図５に関して説明したような、）ＩＣＥのネゴシエート及び信号伝達プロセスを開始する。ＩＣＥ情報を受信した後、相互の間の接続をセットアップし、直接に、若しくは必要ならばＮＡＴを用いて、メディア転送を初期化する。メディア転送の間に何らかのデータ転送が必要とされれば、ストリームマネジャプロキシサーバ２１０により提供される、確立されたプロキシブリッジに亘って、データが流れる。
【００５６】
ある実施形態では、ストリームマネジャプロキシサーバ２１０は、生きていることを保証するためにクライアント接続を継続的にピングすることにより、ロードバランサがＷｅｂＳｏｃｋｅｔ接続を閉じることを防ぎ続ける、特別の「ピンガー」メカニズムを用いる。更に、ロードバランサ２３０を用いる際には、転送は二度プロキシされる。特に、転送は、ロードバランサ２３０を通過する際最初にプロキシされ、ストリームマネジャプロキシサーバ２１０を通過する際二度目にプロキシされる。転送のプロトコルはリアルタイムであるから、データが二つのサーバを通過しているときでも、遅延は無い。
【００５７】
任意の適切なコンピューティングデバイスが、本明細書に記載の、（例えば、パブリッシャデバイス１０２、サブスクライバデバイス１０４、発端ノード１０６、エッジノード１０８、ストリームマネジャプロキシサーバ２１０等を介して）コンピューティングデバイスを、及び、方法／機能を、実装するのに用いられ得、更に、当業者に理解されるように、一般的コンピューティングデバイス上でソフトウエアを単に実行することよりもより有意に、ハードウエア、ソフトウエア、及びファームウエアを介して、本明細書に記載の操作及び特徴を実行するための特定のシステムに、変換され得る。そのようなコンピューティングデバイス７００の一つの例示は、図７に示される。コンピューティングデバイス７００は、適切なコンピューティング環境の例示に過ぎず、本発明の範囲を限定するものでは無い。図７に示す「コンピューティングデバイス」は、当業者に理解されるように、「ワークステーション」、「サーバ」、「ラップトップ」、「ハンドヘルドデバイス」、「モバイルデバイス」、「タブレットコンピュータ」、若しくは他のコンピューティングデバイスを、含む。コンピューティングデバイス７００が例示の目的で示されているとしても、本発明の実施形態は、本発明の単独の実施形態を実装する様々なやり方についての任意の数にて、任意の数のコンピューティングデバイス７００を利用し得る。従って、当業者に理解されるように、本発明の実施形態は単独のコンピューティングデバイス７００に限定されるものでは無く、例のコンピューティングデバイス７００の実装若しくは構成についての、単独のタイプに限定されるものでも無い。
【００５８】
コンピューティングデバイス７００は、以下の例示のコンポーネントの一つ以上のものに直接的に若しくは間接的に結合し得るバス７１０、メモリ７１２、一つ以上のプロセッサ７１４、一つ以上のプレゼンテーションコンポーネント７１６、インプット／アウトプットポート７１８、インプット／アウトプットコンポーネント７２０、及び電源７２４を、含み得る。当業者であれば理解し得るが、バス７１０は、アドレスバス、データバス、若しくはそれらの任意の組み合わせ等の、一つ以上のバスを含み得る。更に、当業者であれば理解し得るが、意図するアプリケーション、及び、特定の実施形態の使用に依存して、これらのコンポーネントの数倍が単独のデバイスにより実装され得る。同様に、ある例では、単独のコンポーネントが多数のデバイスにより実装され得る。よって、図７は、本発明の一つ以上の実施形態を実装するのに用いられ得る例のコンピューティングデバイスの例示に過ぎず、本発明を限定するものでは無い。
【００５９】
コンピューティングデバイス７００は、種々のコンピュータ読み取り可能媒体を含み得、若しくは、それらと相互作用する。例えば、コンピュータ読み取り可能媒体は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的消却プログラム可能型読取専用メモリ（ＥＥＰＲＯＭ)、フラッシュメモリ若しくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）若しくは他の光学若しくはホログラフィック媒体、磁気カセット、磁気テープ、磁気ディスク記憶若しくは他の磁気記憶デバイスを含むことができ、それらは、情報をエンコードするのに用いられ得、コンピューティングデバイス７００によりアクセスされ得る。
【００６０】
メモリ７１２は、揮発性及び／又は不揮発性メモリの形式のコンピュータ記憶媒体を含み得る。メモリ７１２は、リムーバブルでも、非リムーバブルでも、それらの任意の組み合わせでもよい。例示のハードウエアデバイスは、ハードドライブ、ソリッドステートメモリ、光学ディスクドライブなどの、デバイスである。コンピューティングデバイス７００は、メモリ７１２、種々のＩ／Ｏコンポーネント７２０等の、コンポーネントからデータを読み出す一つ以上のプロセッサを含み得る。プレゼンテーションコンポーネント７１６は、ユーザや他のデバイスにデータ表示を示す。例示のプレゼンテーションコンポーネントは、ディスプレイデバイス、スピーカ、プリントコンポーネント、振動コンポーネント等を、含む。
【００６１】
Ｉ／Ｏポート７１８により、コンピューティングデバイス７００は、Ｉ／Ｏコンポーネント７２０等の、他のデバイスと論理的に結合することができる。Ｉ／Ｏコンポーネント７２０の例は、マイクロホン、ジョイスティック、記録装置、ゲームパッド、サテライトディッシュ、プリンタ、ワイヤレスデバイス、ネットワークデバイス等を、含む。
【００６２】
本明細書で利用されるように、用語「含む(comprise)」及び「含むこと(comprising)」は、排他的では無く、包括的であると解釈されることを意図する。本明細書で利用されるように、用語「例示(exemplary)」、「例(example)」及び「事例的(illustrative)」は、「例、事例若しくは実例として機能すること」を意味することを意図し、他の構成に関連する好適な若しくは利点のある構成を示すものとして、若しくは示さないものとして、解釈されるべきではない。本明細書で利用されるように、用語「約(about)」、「およそ(generally)」及び「概略(approximately)」は、特性、パラメータ、サイズ、及び寸法における変数などの、客観値若しくは主観値の範囲の上限内及び下限内に存在し得る変数をカバーすることを意図する。一つの非限定的な例では、用語「約(about)」、「およそ(generally)」及び「概略(approximately)」は、丁度、若しくは＋１０％未満、若しくは−１０％未満を、意味する。一つの非限定な例では、用語「約(about)」、「およそ(generally)」及び「概略(approximately)」は、一人の、含まれるべき関連分野の当業者により、十分に近いと考えられることを意味する。本明細書で利用されるように、用語「実質的に(substantively)」は、当業者に理解されるように、行動、特徴、特性、状態、構造、項目、若しくは結果の、完全な、若しくはほぼ完全な範囲若しくは程度を示す。例えば、「実質的に」円形である物は、その物が、数学的に判断可能な限度まで完全な円であるか、当業者に認識される程若しくは理解される程ほぼ円であるか、のいずれかであることを、意味する。絶対的完全性からの偏差の、正確な許容可能な程度は、幾つかの例では、具体的な内容に依存し得る。しかしながら、一般的に、完全性の近似は、あたかも絶対的な且つ全体的な完全性が達成される若しくは獲得されるような、同様の全般的な結果を有するべきものである。当業者に理解されるように、行動、特徴、特性、状態、項目、若しくは結果についての完全性の欠如又は完全性の欠如の近傍に言及する、否定的な意味合いで利用される際に、「実質的に」の使用は等しく適用可能である。
【００６３】
前述の記載に接すれば、当業者には本発明に係る多数の修正や代替の実施形態が明らかである。従って、本明細書の記載は、例示としてのみ解釈されるべきものであり、当業者に本発明を実施するためのベストモードを教示するためのものである。本発明の精神から乖離すること無く、詳細な構成は実質的に変更可能であり、特許請求の範囲の内部に在る全ての修正の排他的な使用が用意されている。本明細書では、明確かつ簡潔な記載の記述を可能にするように実施形態を記述してきたが、複数の実施形態は本発明から離れることなく様々に組み合わされたり分離されたり、され得ることが、意図されており、また認められるものである。特許請求の範囲及び適用される法規により要求される範囲にのみ、本発明は限定されることが、意図されている。
【００６４】
当然ながら、請求項は、本明細書に記載の発明の全ての、包括的な及び具体的な特徴を、更には、言葉の問題として、行間に存在すると言及され得る、発明の範囲の全ての記述を、カバーするべきものである。
【図１Ａ】
2020528189.tif 000003
【図１Ｂ】
2020528189.tif 000004
【図２】
2020528189.tif 000005
【図３】
2020528189.tif 000006
【図４】
2020528189.tif 000007
【図５】
2020528189.tif 000008
【図６】
2020528189.tif 000009
【図７】
2020528189.tif 000010
【国際調査報告】
2020528189.tif 000011