JP2015532984A

JP2015532984A - アプリケーションプラットフォームおよびアプリケーション間でログインステータスを共有するためのシステムおよび方法

Info

Publication number: JP2015532984A
Application number: JP2015530285A
Authority: JP
Inventors: リャン・マ; ジチャン・ヒ; チェン・グオ; リンボ・ザン; シャオジン・ツ
Original assignee: テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド
Priority date: 2012-09-11
Filing date: 2013-09-10
Publication date: 2015-11-16
Anticipated expiration: 2033-09-10
Also published as: EP2895981A4; JP5867841B2; EP2895981B1; KR20150052286A; CN103685175B; CN103685175A; TWI510272B; KR101556619B1; EP2895981A1; TW201410304A; WO2014040522A1

Abstract

両方がクライアントデバイス上で動作するアプリケーションプラットフォームおよびアプリケーション間でログインステータスを共有するための方法がコンピュータで実行される。クライアントデバイスからのログインリクエストに応答して、コンピュータがログインリクエストを分析し、ログインリクエストがアプリケーションプラットフォームまたはアプリケーションに関連付けられるかを決定する。ログインリクエストがアプリケーションプラットフォームに関連付けられる場合、コンピュータがその時アプリケーションプラットフォームサーバとの第１の接続を確立し、アプリケーションプラットフォームサーバへログインリクエストを転送する。アプリケーションプラットフォームサーバからのログインキーの受信時、コンピュータがクライアントデバイスへログインキーを戻す。

Description

本願は、２０１２年９月１１日に出願された中国特許出願第２０１２１０３３４２８９．１号の「ＳＹＳＴＥＭＡＮＤＭＥＴＨＯＤＦＯＲＳＨＡＲＩＮＧＬＯＧＩＮＳＴＡＴＵＳＢＥＴＷＥＥＮＡＮＡＰＰＬＩＣＡＴＩＯＮＰＬＡＴＦＯＲＭＡＮＤＡＮＡＰＰＬＩＣＡＴＩＯＮ」の優先権を主張し、その全体が参照によって本明細書に組込まれる。

本発明は一般に、インターネット技術に関し、特に情報交換を介してアプリケーションプラットフォームおよびアプリケーション間でログインステータスを共有するためのシステムおよび方法に関する。

クライアント−サーバ環境では、クライアントデバイスでのユーザは、リモートサーバによって管理されるデータにアクセスするためにリモートサーバへリクエストを提出する。リモートサーバは、データ上で対応する動作を実行し、クライアントデバイスへ処理結果を戻す。典型的なリクエストは、ログインリクエスト、ログアウトリクエスト等を含む。オンラインゲームアプリケーションは、このタイプの環境で実装される例である。オンラインゲームアプリケーションのユーザは、ゲームをプレイするために自分のアカウントへログインする必要がある。しかし、オンラインゲームベンダーがエンドユーザへ複数のゲームを提供して、これらゲームが異なるネットワークドメインで異なるサーバによってホストされる場合、ユーザは、自分のログイン情報を繰り返し入力することによって別々に異なるサーバへログインする必要がありうる。いくつかの場合では、ベンダーは、クライアントデバイスへダウンロードされるべきオンラインゲームプラットフォームを提供することがあり、それによりエンドユーザは、自分がプレイできる全てのゲームを見ることができる。このオンラインゲームプラットフォームによりエンドユーザは、自分が登録したゲームアプリケーションを管理し易くなるが、例えばゲームアプリケーションのクライアントエンドがゲームプラットフォームによって管理される一方で、ゲームプラットフォームと通信するサーバが特定のゲームアプリケーションをサポートするゲームサーバと異なる場合、エンドユーザは、異なるゲームサーバへログインすることを要求しうる。この構成は、ドメイン間訪問（ｃｒｏｓｓ−ｄｏｍａｉｎｖｉｓｉｔ）を要求しうる。

現在、ドメイン間訪問を達成するための技術は、（ｉ）１つのネットワークドメイン内でサーバにエージェントを確立し、それによりクライアントデバイスがエージェントにリクエストを送信する時、エージェントは、異なるネットワークドメイン内で目標サーバへ新規リクエストを自動的に提出し、次いで更新して、または更新しないで、目標サーバからクライアントデバイスへ応答を戻し、（ｉｉ）オンデマンドＪａｖａ（登録商標）ｓｃｒｉｐｔを使用して新規＜スクリプト＞オブジェクトを動的に生成し、目標サーバのアドレスをソース属性で特定し、それは次いで、例えばＪＳＯＮメッセージを使用してＪａｖａ（登録商標）ｓｃｒｉｐｔのフォーマットで応答を戻し、（ｉｉｉ）目標サーバを示すアイフレームをウェブページへ動的に埋め込み、それにより２つのサーバは、互いのアンカーハッシュフラグメントを変更することによってメッセージを交換できる。しかし、上記手法のどれも、異なるドメイン内のサーバ間でログインステータス情報を共有する問題を容易に解決できない。

異なるサーバ間で情報を共有する従来の手法に関連付けられる上記欠点および他の問題は、以下に説明される本発明によって少なくされるか除かれる。いくつかの実施形態では、本発明は、１つまたは複数のプロセッサ、メモリ、および１つまたは複数のモジュール、複数の機能を実行するためにメモリに格納されるプログラムまたは一組の命令を有するコンピュータシステムで実装される。これら機能を実行するための命令は、１つまたは複数のプロセッサによって実行するように構成されるコンピュータプログラム製品に含まれうる。

本発明の１つの局面は、１つまたは複数のプロセッサおよびメモリを有するコンピュータによって実行されるコンピュータ実装方法を含む。コンピュータ実装方法は、クライアントデバイスからログインリクエストを受信するステップと、ログインリクエストがクライアントデバイスでのアプリケーションプラットフォームまたはクライアントデバイスでのアプリケーションに関連付けられるかを決定するためにログインリクエストを分析するステップであって、アプリケーションがアプリケーションプラットフォームによって管理されるステップと、ログインリクエストがアプリケーションプラットフォームに関連付けられる場合、アプリケーションプラットフォームサーバとの第１の接続を確立するステップと、アプリケーションプラットフォームサーバへログインリクエストを転送するステップと、アプリケーションプラットフォームサーバからログインキーを受信するステップと、クライアントデバイスへログインキーを戻すステップであって、ログインキーがアプリケーションプラットフォームに関連付けられるステップと、ログインリクエストがアプリケーションに関連付けられる場合、アプリケーションサーバとの第２の接続を確立するステップであって、アプリケーションサーバがアプリケーションプラットフォームサーバと異なるステップと、アプリケーションサーバへログインリクエストを転送するステップと、アプリケーションサーバからログインキーを受信するステップと、クライアントデバイスへログインキーを戻すステップであって、ログインキーがアプリケーションに関連付けられるステップとを含む。

本発明のもう１つの局面は、コンピュータシステムを含む。コンピュータシステムは、メモリ、１つまたは複数のプロセッサ、およびメモリに格納されて１つまたは複数のプロセッサによって実行するように構成される１つまたは複数のプログラムを含む。１つまたは複数のプログラムは、クライアントデバイスからログインリクエストを受信するステップと、ログインリクエストがクライアントデバイスでのアプリケーションプラットフォームまたはクライアントデバイスでのアプリケーションに関連付けられるかを決定するためにログインリクエストを分析するステップであって、アプリケーションがアプリケーションプラットフォームによって管理されるステップと、ログインリクエストがアプリケーションプラットフォームに関連付けられる場合、アプリケーションプラットフォームサーバとの第１の接続を確立するステップと、アプリケーションプラットフォームサーバへログインリクエストを転送するステップと、アプリケーションプラットフォームサーバからログインキーを受信するステップと、クライアントデバイスへログインキーを戻すステップであって、ログインキーがアプリケーションプラットフォームに関連付けられるステップと、ログインリクエストがアプリケーションに関連付けられる場合、アプリケーションサーバとの第２の接続を確立するステップであって、アプリケーションサーバがアプリケーションプラットフォームサーバと異なるステップと、アプリケーションサーバへログインリクエストを転送するステップと、アプリケーションサーバからログインキーを受信するステップと、クライアントデバイスへログインキーを戻すステップであって、ログインキーがアプリケーションに関連付けられるステップとを含む。

本発明のもう１つの局面は、コンピュータシステムの１つまたは複数のプロセッサによって実行するための１つまたは複数のプログラムをその中に格納して有する非一時的コンピュータ読取可能な格納媒体を含み、１つまたは複数のプログラムは、クライアントデバイスからログインリクエストを受信するステップと、ログインリクエストがクライアントデバイスでのアプリケーションプラットフォームまたはクライアントデバイスでのアプリケーションに関連付けられるかを決定するためにログインリクエストを分析するステップであって、アプリケーションがアプリケーションプラットフォームによって管理されるステップと、ログインリクエストがアプリケーションプラットフォームに関連付けられる場合、アプリケーションプラットフォームサーバとの第１の接続を確立するステップと、アプリケーションプラットフォームサーバへログインリクエストを転送するステップと、アプリケーションプラットフォームサーバからログインキーを受信するステップと、クライアントデバイスへログインキーを戻すステップであって、ログインキーがアプリケーションプラットフォームに関連付けられるステップと、ログインリクエストがアプリケーションに関連付けられる場合、アプリケーションサーバとの第２の接続を確立するステップであって、アプリケーションサーバがアプリケーションプラットフォームサーバと異なるステップと、アプリケーションサーバへログインリクエストを転送するステップと、アプリケーションサーバからログインキーを受信するステップと、クライアントデバイスへログインキーを戻すステップであって、ログインキーがアプリケーションに関連付けられるステップのための命令を含む。

本発明の上記特徴および利点とそのさらなる特徴および利点は、図に関連付けて好ましい実施形態の詳細な説明の結果として以下より明確に理解されるだろう。

いくつかの実施形態によるアプリケーションプラットフォームおよびアプリケーション間でログインステータス情報を共有する方法を示すフローチャートである。いくつかの実施形態によるログインリクエストのソースを決定する方法を示すフローチャートである。いくつかの実施形態によるアプリケーションプラットフォームサーバまたはアプリケーションサーバとの接続を確立し、ログインリクエストのソースに基づきサーバでログイン動作を完了する方法を示すフローチャートである。いくつかの実施形態によるアプリケーションプラットフォームサーバおよびアプリケーションサーバ間でログインステータスを共有する機構を実装するためのクライアント−サーバネットワーク環境を示すブロック図である。いくつかの実施形態によるアプリケーションプラットフォームおよびアプリケーション間でログインステータス情報を共有する方法を示すもう１つのフローチャートである。いくつかの実施形態による図３に示すプロキシサーバの構成要素を示すブロック図である。いくつかの実施形態による図５に示すプロキシサーバのログインリクエスト分析モジュールの構成要素を示すブロック図である。いくつかの実施形態による図５に示すプロキシサーバのログインステータス共有モジュールの構成要素を示すブロック図である。いくつかの実施形態による図３に示すプロキシサーバの構成要素を示すもう１つのブロック図である。いくつかの実施形態によるアプリケーションプラットフォームサーバおよびアプリケーションサーバ間でログインステータスを共有する機構を実装するためのクライアント−サーバネットワーク環境を示すもう１つのブロック図である。いくつかの実施形態による図３に示すプロキシサーバの構成要素を示すさらにもう１つのブロック図である。

同一の参照番号は、いくつかの図にわたり対応する部分に言及する。

参照は、実施形態に対して詳細に行われ、その例は、添付図で示される。以下の詳細な説明では、多数の特定の詳細が説明され、本明細書に示される主題の完全な理解を提供する。しかし当業者にとって、これら特定の詳細なしで主題を実施しうることが明らかである。他の例では、周知の方法、手順、構成要素、および回路は、実施形態の局面を不必要に曖昧にしないため、詳細に説明されない。

上記の通り、異なるドメイン内で２つのサーバでそのログインステータス情報を安全に共有するためにクライアント側で動作する２つのプログラムに関する課題がある。説明の目的で、本願は一例として、ＱＱのオンラインゲームアプリケーションプラットフォームおよびオンラインゲームアプリケーションプラットフォームによって管理される特定のゲームアプリケーションを使用する。この場合、オンラインゲームアプリケーションプラットフォームおよび特定のゲームアプリケーションの両方は、デスクトップ、ノートＰＣ、タブレット、またはスマートフォン等のクライアントデバイス上にインストールされ、クライアントデバイスおよびリモートプロキシサーバ間にウェブソケット接続がある。オンラインゲームアプリケーションプラットフォームおよび特定のゲームアプリケーションの両方は、ウェブソケット接続を介してプロキシサーバとデータを交換する。プロキシサーバは、それがクライアントデバイスから受信するデータがオンラインゲームアプリケーションプラットフォームまたは特定のゲームアプリケーションからであるかを決定する。サーバ側で、プロキシサーバは、異なるドメイン内でサーバとの接続を維持する。データがオンラインゲームアプリケーションプラットフォームからである場合、プロキシサーバはその時、１つのドメイン内で対応するオンラインゲームアプリケーションプラットフォームサーバへデータを転送し、データが特定のゲームアプリケーションからである場合、プロキシサーバはその時、もう１つのドメイン内で対応するゲームアプリケーションサーバへデータを転送する。プロキシサーバはまた、各サーバでオンラインゲームアプリケーションプラットフォームおよび特定のゲームアプリケーションのログインステータス情報を追跡し、それにより２つのクライアント側のプログラムは、互いにその各々のログインステータス情報を共有できる。そうすることによって、１つのドメイン内でオンラインゲームアプリケーションプラットフォームを介して自分のアカウントへログインしたユーザは、特定のゲームアプリケーションサーバが対応するオンラインゲームアプリケーションプラットフォームサーバでユーザのログインステータスを有する限り、サーバへ自分のログイン情報を提供する必要なく、特定のゲームアプリケーションサーバへアクセスできる。

以下は、本発明によって使用される技術のリストである。

ＷｅｂＳｏｃｋｅｔ
ウェブソケットは、単一のＴＣＰ接続を介して全二重通信チャネルを提供するウェブ技術である。ウェブソケットは、ウェブブラウザおよびウェブサーバで実装されるように設計されるが、それは、任意のクライアントまたはサーバアプリケーションによって使用されうる。ウェブソケットプロトコルは、独立のＴＣＰベースプロトコルである。ＨＴＴＰとのその唯一の関係は、そのハンドシェイクがＵｐｇｒａｄｅリクエストとしてＨＴＴＰサーバによって解釈されることである。ウェブソケットプロトコルは、ブラウザおよびウェブサイト間のさらなる相互作用を可能にし、生コンテンツおよびリアルタイムゲームの作成を容易にする。これは、クライアントによって求められることなくブラウザへコンテンツを送信するためにサーバへ標準的方法を提供することによって可能になり、接続をオープンに維持する一方で往復してメッセージを送ることができる。この方法では、２方向（双方向）の継続中の対話がブラウザおよびサーバ間で行われうる。

Ａｊａｘ
アヤックスは、“ａｓｙｎｃｈｒｏｎｏｕｓＪａｖａ（登録商標）ＳｃｒｉｐｔａｎｄＸＭＬ”の頭字語であり、非同期ウェブアプリケーションを作成するためにクライアント側で使用される相互関係のあるウェブ開発技術のグループである。アヤックスを用いて、ウェブアプリケーションは、既存ページの表示および動作を妨げることなく（バックグラウンドで）非同期的にサーバに対してデータを送信し、データを検索することができる。データは、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトを用いて検索されうる。アヤックスは、単一の技術ではなく、技術のグループであることに留意すべきである。ＨＴＭＬおよびＣＳＳは、情報をマークアップおよびスタイルするために組み合わせて使用されうる。ＤＯＭは、提示される情報を動的に表示するために、およびユーザがそれと相互作用できるようにするためにＪａｖａ（登録商標）Ｓｃｒｉｐｔでアクセスされる。Ｊａｖａ（登録商標）ＳｃｒｉｐｔおよびＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトは、全ページリロードを回避するためにブラウザおよびサーバ間で非同期的にデータを交換するための方法を提供する。

ＪＣＥ
ＪＣＥは、“Ｊａｖａ（登録商標）ＣｒｙｐｔｏｇｒａｐｈｙＥｘｔｅｎｓｉｏｎ”を表し、暗号化、キー生成およびキーの共有、およびメッセージ認証コード（ＭＡＣ）アルゴリズムに関するフレームワークおよび実装を提供する。ＪＣＥは、Ｊａｖａ（登録商標）プラットフォームを補足し、メッセージダイジェストおよびデジタル署名のインタフェースおよび実装を予め含む。

ＬｏｃａｌＳｔｏｒａｇｅ
ローカルストレージは、インターネット上のウェブデータストレージプロトコルの一部である。ローカルストレージに位置するデータは、オリジン毎（同一生成源ポリシーで定められるプロトコル、ホスト名、およびポート番号の組み合わせ）であり、データは、データを予め格納した同一生成源からのウェブページから読み込まれる全スクリプトに対し利用可能であり、それは、ウェブブラウザが閉じられた後で続く。

ＪＳＯＮ
ＪＳＯＮは、“Ｊａｖａ（登録商標）ＳｃｒｉｐｔＯｂｊｅｃｔＮｏｔａｔｉｏｎ”の頭字語であり、人間に解読可能なデータ交換のために設計された、ライトウェイトでテキストベースのオープンスタンダードである。それは、オブジェクトと呼ばれる単一のデータ構造および連想配列を表すためのＪａｖａ（登録商標）Ｓｃｒｉｐｔスクリプト言語から導かれる。そのＪａｖａ（登録商標）Ｓｃｒｉｐｔとの関係によらず、それは、言語非依存であって、パーサが多数の言語に利用可能である。

ＬｏｇｉｎＫｅｙ
ログインキーは、クライアントデバイスからのログインリクエストがバックエンドサーバで成功した後、クライアントデバイスへバックエンドサーバによって公開される暗号化キーである。ログインキーは、寿命の制限期間を有し、その間、クライアントデバイスは、さらにログイン情報を提供する必要なく、バックエンドサーバにアクセスできる。

図１は、いくつかの実施形態に従うアプリケーションプラットフォームおよびアプリケーション間でログインステータス情報を共有する方法を示すフローチャートである。この例では、アプリケーションプラットフォームおよびアプリケーションの両方が、ワイヤードまたはワイヤレスでプロキシサーバへ接続されるクライアントデバイス上にインストールされると仮定する。アプリケーションプラットフォームは、多数のアプリケーションを管理する特定のアプリケーションである。しかし、（アプリケーションプラットフォームを含む）異なるアプリケーションは、異なるネットワークドメイン内で異なるバックエンドサーバに対応しうる。例えば、アプリケーションプラットフォームは、１つのドメイン内でアプリケーションプラットフォームサーバに対応することができ、クライアントデバイスでアプリケーションプラットフォームによって管理されるアプリケーションは、異なるネットワークドメイン内でアプリケーションサーバに対応することができる。通常、ユーザは、２つのサーバによって提供されるサービスにアクセスするために、別々に２つの異なるサーバで自分のアカウントにログインする必要がある。しかし、以下に説明する通り、方法は、他のサーバ（例えば、アプリケーションプラットフォームサーバ）によって提供されるログインステータス情報（例えば、ログインキー）を使用する１つのサーバ（例えば、アプリケーションサーバ）にユーザがアクセスできるようにするプロキシサーバで実装される。

ステップＳ１０１で、プロキシサーバは、クライアントデバイスからログインリクエストを受信する。上記の通り、クライアントデバイスおよびプロキシサーバ間にウェブソケット接続がある。ユーザは先ず、ユーザが以前にどのサーバにもログインしてなかった場合、ウェブソケット接続を使用してプロキシサーバへアプリケーションプラットフォームおよびアプリケーションの１つからログインリクエストを提出する。いくつかの実施形態では、ログインリクエストは、１つまたは複数の関連データパケットを含み、データパケットの少なくとも１つは、ログインリクエストがアプリケーションプラットフォームまたはアプリケーションによって開始されるかを決定するために、プロキシサーバのためのログインリクエストタイプビットを含む。

ステップＳ１０２で、プロキシサーバは、ログインリクエストのソースを決定するためにログインリクエストを分析する。例えば、プロキシサーバは、ログインリクエストを伝えるデータパケットからログインリクエストタイプビットを要求（ｅｘａｃｔ）することができる。以下に説明の通り、ログインリクエストタイプビットに格納されたデータは、ログインリクエストがアプリケーションプラットフォームまたはアプリケーションからであるかを示す。そのような情報に基づき、プロキシサーバは、それがアプリケーションプラットフォームサーバまたはアプリケーションサーバへログインリクエストを通信すべきかを決定する。

ステップＳ１０３で、ログインリクエストのソースに基づき、プロキシサーバは、アプリケーションプラットフォームおよびアプリケーション間でログインステータスを共有するために、アプリケーションプラットフォームサーバまたはアプリケーションサーバとの接続を確立する。例えば、ログインリクエストがアプリケーションプラットフォームからである時、プロキシサーバは、アプリケーションプラットフォームサーバとの接続を確立し、ログインリクエストがアプリケーションからである時、プロキシサーバは、アプリケーションサーバとの接続を確立する。そうすることで、プロキシサーバは、その各サーバとの通信のために、アプリケーションプラットフォームおよびアプリケーションによって共有される“コンジット（ｃｏｎｄｕｉｔ）”になる。アプリケーションプラットフォームまたはアプリケーションが対応するサーバにログインした後、プロキシサーバは、サーバから対応するログインキーを受信し、アプリケーションプラットフォームまたはアプリケーションのログインステータスを記録する。また、プロキシサーバはさらに、２つの異なるネットワークドメイン内にありうる２つのサーバが互いにログインステータス情報を共有できるように、他のサーバへログインキーを転送する。

図２Ａは、いくつかの実施形態によるログインリクエストのソースを決定する方法を示すフローチャートである。上記の通り、プロキシサーバは、どのプログラム、アプリケーションプラットフォームまたはアプリケーションがログインリクエストを開始することに関与するかを決定するために、ログインリクエストを分析する必要がある。そうするために、プロキシサーバは先ず、ログインリクエストを伝えるデータパケットを特定する。ステップＳ１０２１で、プロキシサーバは、ログインリクエストを伝えるデータパケットからヘッダを抽出する。以下に説明の通り、アプリケーションプラットフォームに関連付けられるデータパケットおよびアプリケーションに関連付けられるデータパケット間でフォーマットの違いがある。例えば、アプリケーションプラットフォームに関連付けられるデータパケットは通常、テキストフレームのフォーマットであり、アプリケーションに関連付けられるデータパケットは通常、バイナリフレームのフォーマットである。ステップＳ１０２２で、プロキシサーバは、データパケットのヘッダでログインリクエストタイプビットを特定する。このステップのさらなる詳細は、以下で提供される。ステップＳ１０２３で、プロキシサーバは、ログインリクエストがログインリクエストタイプビットに従いアプリケーションプラットフォームまたはアプリケーションに関連付けられるかを決定する。

図２Ｂは、いくつかの実施形態による、アプリケーションプラットフォームサーバまたはアプリケーションサーバとの接続を確立し、ログインリクエストのソースに基づきサーバでログイン動作を完了する方法を示すフローチャートである。ステップＳ１０３１で、プロキシサーバは、ログインリクエストのソースを決定する。ログインリクエストがアプリケーションプラットフォームからである場合、プロキシサーバはその時、ステップＳ１０３２へ移動し、ログインリクエストがアプリケーションからである場合、プロキシサーバはその時、ステップＳ１０３６に対応する動作を実行する。ステップＳ１０３２で、プロキシサーバは、例えばＨＴＴＰプロキシサービスを使用してアプリケーションプラットフォームサーバとの短期的な接続を確立する。ステップＳ１０３３で、プロキシサーバは、接続を介してアプリケーションプラットフォームサーバへログインリクエストを送信する。ステップＳ１０３４で、プロキシサーバは、ログインリクエストが成功した後、アプリケーションプラットフォームサーバからログインキーを受信する。ステップＳ１０３５で、プロキシサーバは、ログインリクエストを提出するクライアントデバイスへログインキーを戻す。いくつかの実施形態では、ログインキーは、クライアントデバイス（例えば、ローカルストレージ）でキャッシュされ、アプリケーションへ提供される。ユーザがアプリケーションを起動する時、アプリケーションは、クライアントデバイスのメモリからログインキーを検索し、まだ有効か否かをチェックする。ログインキーがまだ有効な（例えば、寿命期間がまだ満了してない）場合、アプリケーションは、ログイン情報（例えば、ユーザ名およびパスワード）を提供するようにユーザを促さない。代わりに、アプリケーションは、直接プロキシサーバへログインキーを含むアクセスリクエストを送信する。アクセスリクエストの受信時、プロキシサーバはまた、アクセスリクエストが有効なログインキーを含むかどうかをチェックし、そうである場合、対応するアプリケーションサーバへアクセスリクエストを転送する。最後に、アプリケーションサーバは、アクセスリクエストの受信時、そのログインキーと、それが以前にプロキシサーバから受信したログインキーとを比較することによって認証動作を実行する。一致が確認された場合、アプリケーションサーバは、プロキシサーバまたはクライアントデバイスからアクセスリクエストの有効性のさらなる証明をリクエストすることなく、アクセスリクエストの命令に従い動作を実行する。

同様に、ステップＳ１０３６で、プロキシサーバは、例えばウェブソケットプロキシサービスを使用してアプリケーションプラットフォームサーバとの長期的な接続を確立する。ステップＳ１０３７で、プロキシサーバは、接続を介してアプリケーションサーバへログインリクエストを送信する。ステップＳ１０３８で、プロキシサーバは、ログインリクエストが成功した後、アプリケーションサーバからログインキーを受信する。ステップＳ１０３９で、プロキシサーバは、ログインリクエストを提出するクライアントデバイスへログインキーを戻す。いくつかの実施形態では、ログインキーは、クライアントデバイス（例えば、ローカルストレージ）でキャッシュされ、アプリケーションプラットフォームへ提供される。ユーザがアプリケーションプラットフォームを起動する時、アプリケーションプラットフォームは、クライアントデバイスのメモリからログインキーを検索し、それがまだ有効か否かをチェックする。ログインキーがまだ有効（例えば、寿命期間がまだ満了してない）場合、アプリケーションプラットフォームは、ログイン情報（例えば、ユーザ名およびパスワード）を提供するようにユーザを促さない。代わりに、アプリケーションプラットフォームは、直接プロキシサーバへログインキーを含むアクセスリクエストを送信する。アクセスリクエストの受信時、プロキシサーバはまた、アクセスリクエストが有効なログインキーを含むかどうかをチェックし、そうである場合、対応するアプリケーションプラットフォームサーバへアクセスリクエストを転送する。最後に、アプリケーションプラットフォームサーバは、アクセスリクエストの受信時、そのログインキーと、それが以前にプロキシサーバから受信したログインキーとを比較することによって認証動作を実行する。一致が確認された場合、アプリケーションプラットフォームサーバは、プロキシサーバまたはクライアントデバイスからアクセスリクエストの有効性のさらなる証明をリクエストすることなく、アクセスリクエストの命令に従い動作を実行する。

いくつかの実施形態では、アプリケーションプラットフォームおよびアプリケーション間の関係は、非対称である。即ち、アプリケーションプラットフォームサーバによって提供されるログインキーは、アプリケーションサーバへアクセスするために使用されうるが、アプリケーションサーバによって提供されるログインキーは、アプリケーションプラットフォームサーバへアクセスするために使用されないか、またはアプリケーションプラットフォームサーバの情報へのアクセス制限を提供しうる。例えば、アプリケーションサーバでユーザアカウント情報と異なることがある、アプリケーションプラットフォームサーバで登録されたユーザ名およびパスワードをユーザが提供しない限り、ユーザに関連付けられてアプリケーションプラットフォームサーバに格納された金融情報（例えば、銀行アカウントまたはクレジットカード番号）へユーザがアクセスすることを許可しないことがある。

図３は、いくつかの実施形態によるアプリケーションプラットフォームサーバおよびアプリケーションサーバ間でログインステータスを共有する機構を実装するためのクライアント−サーバネットワーク環境を示すブロック図である。この例では、クライアントデバイス１０は、オンラインゲームプラットフォーム１３および特定のオンラインゲーム１５等の多数のプログラムを有する。特に特定のオンラインゲーム１５は、オンラインゲームプラットフォーム１３によって管理される多数のゲームの１つである。オンラインゲームプラットフォーム１３は、（ネットワークドメインＢでの）アプリケーションプラットフォームサーバ４０に対応し、ゲーム１５は、（ネットワークドメインＡでの）アプリケーションサーバ３０に対応する。オンラインゲームプラットフォーム１３およびゲーム１５にログインステータス情報を共有させるために、プロキシサーバ２０は、クライアントデバイス１０とサーバ３０および４０との間に位置付けられる。クライアントデバイス１０およびプロキシサーバ２０間にウェブソケット接続がある。（ログインリクエストを含む）アクセスリクエストの分析に基づき、プロキシサーバ２０は、リクエストがオンラインゲームプラットフォーム１３またはゲーム１５からであるかを決定し、アプリケーションサーバ３０またはアプリケーションプラットフォームサーバ４０との接続のために対応する動作モードを呼出す。

例えば、アクセスリクエストがオンラインゲームプラットフォーム１３からのログインリクエストである場合、プロキシサーバ２０は、ＨＴＴＰプロキシサービス２５を使用してアプリケーションプラットフォームサーバ４０との短期的な接続を確立し、それは、ＡＪＡＸ技術を使用して実現されてもよく、アクセスリクエストがゲーム１５からのログインリクエストである場合、プロキシサーバ２０は、ウェブソケットプロキシサービス２３を使用してアプリケーションサーバ３０との長期的な接続を確立する。いくつかの実施形態では、オンラインゲームプラットフォーム１３に関連付けられるウェブページは、埋め込まれた＜アイフレーム＞オブジェクトを含む＜Ｗｉｎｄｏｗ＞オブジェクトを有する。両方のオブジェクトは、プロキシサーバ２０とのウェブソケット接続を共有する。ログインリクエストがオンラインゲームプラットフォーム１３からである場合、そうであることを示すデータパケットに対応するビットがあり、プロキシサーバ２０は次いで、アプリケーションプラットフォームサーバ４０と通信する。しかし、ユーザが同じウェブページを使用してアプリケーションサーバ３０へアクセスする時、アクセスリクエストは、そのビットを異なるビットに置換する。相応して、プロキシサーバ２０は、対応する接続を介してアプリケーションサーバ３０と通信する。

上記の通り、アクセスリクエストがオンラインゲームプラットフォーム１３またはゲーム１５からであるかに依存して、データパケットは、各々表１および２で以下に示す通り、テキストフレームまたはバイナリフレームのフォーマットでもよい。

いくつかの実施形態では、テキストフレームは、１バイト０ｘ００で開始し、１バイト０ｘＦＦで終了する。テキストフレームのメッセージボディは、ＵＴＦ８フォーマットへ変換され、ラベル“ｊ”は、メッセージがＪＳＯＮ標準を使用して符号化されることをメッセージが示すことを示す。これに対し、バイナリフレームは、１バイト０ｘ８０で開始し、ヌルで終了する。ラベル“ｂ”は、メッセージがベース６４標準を使用して符号化されることをメッセージが示すことを示す。

ログインリクエストの受信時、プロキシサーバ２０は、オンラインゲームプラットフォーム１３からのリクエストを示す“０ｘ００”若しくは“ｊ”、およびゲーム１５からのリクエストを示す“０ｘ８０”若しくは“ｂ”で、リクエストがオンラインゲームプラットフォーム１３またはゲーム１５からであるかを判断する。例えば、プロキシサーバは、データパケットを分析し、ログインリクエストがオンラインゲームプラットフォーム１３からであることを示す、第２のバイトのラベルが“ｊ”であることを決定する。次にプロキシサーバ２０は、ＨＴＴＰプロキシサービス２５へリクエストを転送する。そうでなければ、または第２のバイトのラベルが“ｂ”である場合、プロキシサーバ２０は、ウェブソケットプロキシサービス２３へリクエストを転送する。ログインリクエストのソースを決定した後、プロキシサーバ２０は、対応するサーバとの接続を確立し、サーバへ後続のデータパケットを伝える。この場合、プロキシサーバ２０は、データパケットの任意のさらなる分析を実行する必要はない。それがサーバから（ログインリクエストに対する応答でもよい）データパケットを受信する時、プロキシサーバ２０は、データパケットが対応するラベル“ｊ”または“ｂ”を含むかどうかをチェックし、そうでない場合、データパケットへラベルを追加し、それによりクライアントデバイスは、応答がアプリケーションプラットフォームサーバ４０（ラベル“ｊ”）またはアプリケーションサーバ３０（ラベル“ｂ”）からであるかを決定しうる。

オンラインゲームプラットフォーム１３がアプリケーションプラットフォームサーバ４０へログインした後、プロキシサーバ２０はまた、ローカルストレージを使用してサーバ４０によって戻されるログインキーを格納する。次いで、ユーザが同じクライアントデバイス１０からアプリケーションサーバ３０へアクセスしようとする時、プロキシサーバ２０は、アプリケーションサーバ３０に関連付けられたＵＲＬへログインキーを追加し、それによりユーザは、アプリケーションプラットフォームサーバ４０によって提供されるログインキーを使用してアプリケーションサーバ３０へアクセスできる。いくつかの実施形態では、バックエンドサーバ３０または４０がログインリクエストを認証する時、それは、所定の状況（例えば、頻繁なログインリクエスト）が引起される場合、クライアントデバイス１０へ証明コードを送出することによって、証明プロセスを呼出してもよい。ログインリクエストは、証明コードがテストにパスした後のみ認証される。ログインリクエストが認証された後、クライアントデバイス１０は、対応するバックエンドサーバに対しさらにデータを通信することができる。

図４は、いくつかの実施形態によるアプリケーションプラットフォームおよびアプリケーション間でログインステータス情報を共有する方法を示すもう１つのフローチャートである。ステップＳ１０１の前、プロキシサーバは、ステップＳ１００でクライアントデバイスとのウェブソケット接続を確立する。ステップＳ１０３の後、プロキシサーバは、ステップＳ１０４で各接続を介してクライアントデバイスとアプリケーションプラットフォームサーバまたはアプリケーションサーバとの間のデータ交換を容易にする。例えば、プロキシサーバ２０は、クライアントデバイス１０からデータ交換に対応するデータパケットを分析し、それらが上記ラベルに基づきゲームプラットフォーム１３またはゲーム１５からであるかを決定する。

図５は、いくつかの実施形態による図３に示すプロキシサーバ２０の構成要素を示すブロック図である。この例では、プロキシサーバ２０は、ログインリクエスト受信モジュール５０１と、ログインリクエスト分析モジュール５０２と、ログインステータス共有モジュール５０３とを含む。

ログインリクエスト受信モジュール５０１は、クライアントデバイスからログインリクエストを受信するように構成される。上記の通り、クライアントデバイスおよびプロキシサーバ間にウェブソケット接続がある。ユーザが以前にどのサーバへもログインしてない場合、ユーザは先ず、ウェブソケット接続を用いてプロキシサーバへアプリケーションプラットフォームおよびアプリケーションの１つからログインリクエストを提出する。いくつかの実施形態では、ログインリクエストは、１つまたは複数の関連データパケットを含み、データパケットの少なくとも１つは、プロキシサーバに関するログインリクエストタイプビットを含んで、ログインリクエストがアプリケーションプラットフォームまたはアプリケーションによって開始されるかを決定する。

ログインリクエスト分析モジュール５０２は、ログインリクエストを分析してログインリクエストのソースを決定するように構成される。例えば、ログインリクエスト分析モジュール５０２は、ログインリクエストを伝えるデータパケットからログインリクエストタイプビットを要求する。以下に説明の通り、ログインリクエストタイプビットに格納されるデータは、ログインリクエストがアプリケーションプラットフォームまたはアプリケーションからであるかを示す。そのような情報に基づき、ログインリクエスト分析モジュール５０２は、それがアプリケーションプラットフォームサーバまたはアプリケーションサーバへログインリクエストを通信すべきかを決定する。

ログインステータス共有モジュール５０３は、ログインリクエストのソースに基づきアプリケーションプラットフォームサーバまたはアプリケーションサーバとの接続を確立して、アプリケーションプラットフォームおよびアプリケーション間でログインステータスを共有するように構成される。例えば、ログインリクエストがアプリケーションプラットフォームからである時、ログインステータス共有モジュール５０３は、アプリケーションプラットフォームサーバとの接続を確立し、ログインリクエストがアプリケーションからである時、ログインステータス共有モジュール５０３は、アプリケーションサーバとの接続を確立する。そうすることによって、プロキシサーバは、その各サーバと通信するためにアプリケーションプラットフォームおよびアプリケーションによって共有される“コンジット”になる。アプリケーションプラットフォームまたはアプリケーションが対応するサーバへログインした後、ログインステータス共有モジュール５０３は、サーバから対応するログインキーを受信し、アプリケーションプラットフォームまたはアプリケーションのログインステータスを記録する。また、ログインステータス共有モジュール５０３はさらに、他のサーバへログインキーを転送し、それにより２つの異なるネットワークドメイン内にありうる２つのサーバが互いにログインステータス情報を共有しうる。

図６は、いくつかの実施形態による図５に示すプロキシサーバのログインリクエスト分析モジュール５０２の構成要素を示すブロック図である。この例では、ログインリクエスト分析モジュール５０２は、データパケット抽出ユニット５０２１、ログインリクエストタイプ特定ユニット５０２２、およびログインリクエストタイプ決定ユニット５０２３を含む。データパケット抽出ユニット５０２１は、ログインリクエストを伝えるデータパケットからヘッダを抽出するように構成される。ログインリクエストタイプ特定ユニット５０２２は、データパケットのヘッダでログインリクエストタイプビットを特定するように構成される。ログインリクエストタイプ決定ユニット５０２３は、ログインリクエストがログインリクエストタイプビットに従ってアプリケーションプラットフォームまたはアプリケーションに関連付けられるかを決定するように構成される。

図７は、いくつかの実施形態による図５に示すプロキシサーバのログインステータス共有モジュール５０３の構成要素を示すブロック図である。この例では、ログインステータス共有モジュール５０３は、接続確立ユニット５０３１、ログインリクエスト提出ユニット５０３２、ログイン応答受信ユニット５０３３、およびログインステータス共有ユニット５０３４を含む。接続確立ユニット５０３１は、例えばＨＴＴＰプロキシサービスを使用してアプリケーションプラットフォームサーバとの短期的な接続を確立するか、または例えばウェブソケットプロキシサービスを使用してアプリケーションプラットフォームサーバとの長期的な接続を確立するように構成される。ログインリクエスト提出ユニット５０３２は、対応する接続を介してアプリケーションプラットフォームサーバへログインリクエストを送信するか、または対応する接続を介してアプリケーションサーバへログインリクエストを送信するように構成される。ログイン応答受信ユニット５０３３は、ログインリクエストが成功した後、アプリケーションプラットフォームサーバまたはアプリケーションサーバからログインキーを受信するように構成される。ログインステータス共有ユニット５０３４は、ログインリクエストを提出するクライアントデバイスへログインキーを戻すように構成される。

図８は、いくつかの実施形態による図３に示すプロキシサーバの構成要素を示すもう１つのブロック図である。図５に関連して上記説明したモジュールに加えて、プロキシサーバはまた、クライアントデバイスとのウェブソケット接続を確立するための接続確立モジュール５００と、各接続を介してクライアントデバイスとアプリケーションプラットフォームサーバまたはアプリケーションサーバとの間のデータ交換を容易にするための通信プロキシモジュール５０４とを含む。

図９は、いくつかの実施形態によるアプリケーションプラットフォームサーバおよびアプリケーションサーバ間でログインステータスを共有する機構を実装するためのクライアント−サーバネットワーク環境を示すもう１つのブロック図である。クライアントデバイス１０は、プロキシサーバ２０へログインリクエストを送信する。ログインリクエストの受信時、プロキシサーバは、リクエストがアプリケーション１５またはアプリケーションプラットフォーム１３からであるかを決定し、次いで相応して対応するサーバ（アプリケーションサーバ３０またはアプリケーションプラットフォームサーバ４０）との接続を確立する。リクエストがアプリケーションプラットフォームサーバ４０へ向けられる場合、アプリケーションプラットフォームサーバ４０は、アプリケーションプラットフォームサーバ４０へのユーザのアクセスを認証するためにログインリクエストを処理し、リクエストがアプリケーションサーバ３０へ向けられる場合、アプリケーションサーバ３０は、アプリケーションサーバ３０へのユーザのアクセスを認証するためにログインリクエストを処理する。アプリケーションプラットフォームサーバ３０またはアプリケーションサーバ４０は次いで、プロキシサーバ２０へログインキーを戻す。他方で、プロキシサーバ２０は、クライアントデバイス１０へログインキーを戻し、それにより将来のアクセスリクエストは、さらにユーザアカウント情報を提供する必要なく、ログインキーを使用しうる。これは、サーバに格納された秘密情報のセキュリティをかなり高めうる。他方で、プロキシサーバ２０は、そのローカルストレージでログインキーを保存し、将来の認証目的のため他のサーバへログインキーを転送する。そうすることによって、さらにネットワーク帯域幅は、従来のドメイン間訪問によって要求される認証を実行することから免れる。

図１０は、いくつかの実施形態による図３に示すプロキシサーバの構成要素を示すさらにもう１つのブロック図である。コンピューティングデバイス６００は通常、１つまたは複数の処理ユニット（ＣＰＵ）６０２、１つまたは複数のネットワークまたは他の通信インタフェース６０４、メモリ６１０、およびこれら構成要素を相互接続するために１つまたは複数の通信バス６０９を含む。通信バス６０９は、システム構成要素間の通信を相互接続および制御する（時々チップセットと呼ばれる）回路を含みうる。コンピューティングデバイス６００は、ユーザ入力デバイス６０５、例えばディスプレイ６０６およびキーボード６０８を含みうる。メモリ６１０は、高速ランダムアクセスメモリでもよく、また１つまたは複数の磁気ディスク格納デバイス等の不揮発性メモリを含みうる。メモリ６１０は、ＣＰＵ６０２から遠隔に位置する大容量ストレージを含みうる。いくつかの実施形態では、メモリ６０２、または代わりにメモリ６０２内の（複数の）不揮発性メモリデバイスは、非一時的コンピュータ読取可能な格納媒体を含む。メモリ６０２またはメモリ６０２のコンピュータ読取可能な格納媒体は、以下の要素、またはこれら要素のサブセットを格納し、また追加の要素を含みうる。

・各種基本システムサービスを扱うための、およびハードウェア依存タスクを実行するための手順を含むオペレーティングシステム６１２。
・インターネット、他の広域ネットワーク、ローカルエリアネットワーク、都市ネットワーク等のような１つまたは複数の通信ネットワーク（ワイヤードまたはワイヤレス）を介してリモートサーバ（例えば、オンラインゲームサーバ）または他のコンピュータへコンピューティングデバイス６００を接続するために使用されるネットワーク接続モジュール６１４。
・ユーザインタフェース６０５を介してユーザ入力を受信するように構成されるユーザインタフェースモジュール６１６。
・クライアントデバイスでの異なるプログラムがそのログインステータス情報を共有できるようにするためのログインステータス共有アプリケーション６１８であって、いくつかの実施形態では、ログインステータス共有アプリケーション６１８はさらに以下を含む。
○図１および５に関連して上記説明したログインリクエスト受信モジュール５０１。
○図１および５に関連して上記説明したログインリクエスト分析モジュール５０２であって、図６に関連して上記説明した通り、ログインリクエスト分析モジュール５０２はまた、パケット抽出ユニット５０２１、情報特定ユニット５０２２、およびログインリクエストソース決定ユニット５０２３を含む。
○図１および５に関連して上記説明したログインステータス共有モジュール５０３であって、図７に関連して上記説明した通り、ログインステータス共有モジュール５０３はまた、提出ユニット５０３２、応答ユニット５０３３、および情報共有ユニット５０３４を含む。

上記方法およびシステムは、音声ファイルからイベントトリガ型（ｅｖｅｎｔ−ｔｒｉｇｇｅｒｉｎｇ）の時間および音声ファイルの再生時間を検索し、イベントトリガ型の時間および再生時間を比較することによってグラフィカルユーザインタフェース上のイベント位置の表示を制御する点に留意すべきである。再生時間は、異なるフレームに関連付けられた時間の蓄積の結果ではないが音声ファイルの現在の再生位置に対応するので、従来の手法に関連付けられた再生時間とイベントトリガ型の時間との間の時間間隔は、効率的に避けられうる。

特定の実施形態が上記説明されたが、これら特定の実施形態へ本発明を制限することを意図しないことが分かる。むしろ、本発明は、添付の特許請求の範囲および精神内にある代替、修正、および均等物を含む。多数の特定の詳細は、ここに提示される主題の完全な理解を提供するために説明される。しかし、当業者であれば、主題がこれら特定の詳細なく実施しうることが分かるだろう。他の例では、周知の方法、手順、構成要素、および回路は、実施形態の局面を不必要に曖昧にしないように詳細に説明されない。

本発明の説明で使用される用語は、特定の実施形態を説明する目的のためだけであり、本発明の制限を意図しない。本発明の説明および添付の特許請求の範囲で使用される通り、単一の形式“ａ”，“ａｎ”および“ｔｈｅ”は、特に明確な指示がない限り、複数の形式も含むことを意図する。また、ここで使用される用語“ａｎｄ／ｏｒ”は、１つまたは複数の関連付けられたリスト項目の任意のまたは全ての可能な組み合わせに言及し、包含することが分かる。また、用語“ｉｎｃｌｕｄｅｓ”，“ｉｎｃｌｕｄｉｎｇ”，“ｃｏｍｐｒｉｓｅｓ”および“ｃｏｍｐｒｉｓｉｎｇ”は、本明細書で使用される時、述べた特徴、動作、要素、および／または構成要素の存在を特定するが、１つまたは複数の他の特徴、動作、要素、構成要素、および／またはそれらのグループを除外しないことが分かる。

ここで使用される通り、用語“場合”は、“時（ｗｈｅｎ）”，“時（ｕｐｏｎ）”，または“決定に応じて”または“決定に従って”または“検出に応じて”を意味すると解釈され、述べた前提条件が内容に応じて真である。同様に、用語“［述べた前提条件が真である］と決定された場合”または“［述べた前提条件が真である］場合”または“［述べた前提条件が真である］時”は、“決定時”または“決定に応じて”または“決定に従って”または“検出時”または“検出に応じて”を意味すると解釈され、述べた前提条件が内容に応じて真である。

いくつかの各種図が特定の順序で複数の論理的段階を示すが、順序的に依存しない段階が並び替えられてよく、他の段階が結合または除外されてもよい。いくつかの並び替えまたは他のグループ化が特に言及される一方で、その他に関しては当業者にとって明らかなので、代替の排他的リストを提供しない。また、段階は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの任意の組み合わせで実装されうることが認められる。

上記説明は、説明目的のために、特定の実施形態を参照して説明された。しかし、上記例示的な検討は、本発明を開示された正確な形式へ排他的または制限することを意図しない。多数の修正および変形は、上記教示を鑑みて可能である。実施形態は、本発明の原則およびその実用的用途を最良に説明するために選択および記述され、それにより当業者が本発明を最良に利用できるようにし、各種修正を伴う各種実施形態は、考慮される特定の使用に適応される。

１０クライアントデバイス
２０プロキシサーバ
３０アプリケーションサーバ
４０アプリケーションプラットフォームサーバ

Claims

１つまたは複数のプロセッサと前記１つまたは複数のプロセッサによって実行されるプログラムを格納するメモリとを有するコンピュータで、
クライアントデバイスからログインリクエストを受信するステップと、
前記ログインリクエストが前記クライアントデバイスでのアプリケーションプラットフォームまたは前記クライアントデバイスでのアプリケーションに関連付けられるかを決定するために前記ログインリクエストを分析するステップであって、前記アプリケーションは、前記アプリケーションプラットフォームによって管理されるステップと
前記ログインリクエストが前記アプリケーションプラットフォームに関連付けられる場合、
アプリケーションプラットフォームサーバとの第１の接続を確立するステップと、
前記アプリケーションプラットフォームサーバへ前記ログインリクエストを転送するステップと、
前記アプリケーションプラットフォームサーバからログインキーを受信するステップと、
前記クライアントデバイスへ前記ログインキーを戻すステップであって、前記ログインキーは、前記アプリケーションプラットフォームに関連付けられるステップと
前記ログインリクエストが前記アプリケーションに関連付けられる場合、
アプリケーションサーバとの第２の接続を確立するステップであって、前記アプリケーションサーバは、前記アプリケーションプラットフォームサーバとは異なるステップと、
前記アプリケーションサーバへ前記ログインリクエストを転送するステップと、
前記アプリケーションサーバからログインキーを受信するステップと、
前記クライアントデバイスへ前記ログインキーを戻すステップであって、前記ログインキーは、前記アプリケーションに関連付けられるステップと
を含むことを特徴とするコンピュータ実装された方法。
前記ログインリクエストを分析するステップは、
前記ログインリクエストを伝えるデータパケットからヘッダを抽出するステップと、
前記ヘッダのログインリクエストタイプビットを特定するステップと、
前記ログインリクエストが前記ログインリクエストタイプビットに従って前記アプリケーションプラットフォームまたは前記アプリケーションに関連付けられるかを決定するステップと
をさらに含むことを特徴とする請求項１に記載のコンピュータ実装された方法。
前記アプリケーションプラットフォームに関連付けられる前記ログインリクエストを伝える前記データパケットは、１つまたは複数のテキストフレームの形式であり、前記アプリケーションに関連付けられる前記ログインリクエストを伝える前記データパケットは、１つまたは複数のバイナリフレームの形式であることを特徴とする請求項２に記載のコンピュータ実装された方法。
前記ログインリクエストが前記アプリケーションプラットフォームに関連付けられる場合、
前記アプリケーションサーバへ前記ログインキーを転送するステップであって、前記ログインキーは、前記アプリケーションに関連付けられるアクセスリクエストを認証するために使用されるステップと、
前記ログインリクエストが前記アプリケーションに関連付けられる場合、
前記アプリケーションプラットフォームサーバへ前記ログインキーを転送するステップであって、前記ログインキーは、前記アプリケーションプラットフォームに関連付けられるアクセスリクエストを認証するために使用されるステップと
をさらに含むことを特徴とする請求項１に記載のコンピュータ実装された方法。
前記アプリケーションプラットフォームサーバおよび前記アプリケーションサーバの１つから前記ログインリクエストへの応答を受信するステップと、
前記応答へログインリクエストタイプビットを追加することによって前記応答を更新するステップであって、前記ログインリクエストタイプビットは、前記応答が前記アプリケーションプラットフォームサーバまたは前記アプリケーションサーバからであるかを示すステップと、
前記クライアントデバイスへ前記更新された応答を転送するステップであって、前記ログインリクエストタイプビットは、前記応答が前記アプリケーションプラットフォームまたは前記アプリケーションによって処理されるべきかを示すステップと
をさらに含むことを特徴とする請求項１に記載のコンピュータ実装された方法。
前記ログインリクエストは、ウェブソケットプロトコルベースの接続を介して前記クライアントデバイスから前記コンピュータへ送信されることを特徴とする請求項１に記載のコンピュータ実装された方法。
前記アプリケーションプラットフォームサーバとの前記第１の接続は、短期的な接続であり、前記アプリケーションサーバとの前記第２の接続は、長期的な接続であることを特徴とする請求項１に記載のコンピュータ実装された方法。
前記第１の接続は、ＡＪＡＸプロトコルに従って実装され、前記第２の接続は、ウェブソケットプロトコルに従って実装されることを特徴とする請求項７に記載のコンピュータ実装された方法。
１つまたは複数のプロセッサと、
メモリと、
前記メモリに格納され、前記１つまたは複数のプロセッサによって実行するように構成される１つまたは複数のプログラムであって、
クライアントデバイスからログインリクエストを受信するステップと、
前記ログインリクエストが前記クライアントデバイスでのアプリケーションプラットフォームまたは前記クライアントデバイスでのアプリケーションに関連付けられるかを決定するために前記ログインリクエストを分析するステップであって、前記アプリケーションは、前記アプリケーションプラットフォームによって管理されるステップと
前記ログインリクエストが前記アプリケーションプラットフォームに関連付けられる場合、
アプリケーションプラットフォームサーバとの第１の接続を確立するステップと、
前記アプリケーションプラットフォームサーバへ前記ログインリクエストを転送するステップと、
前記アプリケーションプラットフォームサーバからログインキーを受信するステップと、
前記クライアントデバイスへ前記ログインキーを戻すステップであって、前記ログインキーは、前記アプリケーションプラットフォームに関連付けられるステップと、
前記ログインリクエストが前記アプリケーションに関連付けられる場合、
アプリケーションサーバとの第２の接続を確立するステップであって、前記アプリケーションサーバは、前記アプリケーションプラットフォームサーバとは異なるステップと、
前記アプリケーションサーバへ前記ログインリクエストを転送するステップと、
前記アプリケーションサーバからログインキーを受信するステップと、
前記クライアントデバイスへ前記ログインキーを戻すステップであって、前記ログインキーは、前記アプリケーションに関連付けられるステップと
のための命令を含む前記１つまたは複数のプログラムと
を含むことを特徴とするコンピュータシステム。
前記ログインリクエストを分析するための前記命令は、
前記ログインリクエストを伝えるデータパケットからヘッダを抽出するステップと、
前記ヘッダのログインリクエストタイプを特定するステップと、
前記ログインリクエストが前記ログインリクエストタイプビットに従って前記アプリケーションプラットフォームまたは前記アプリケーションに関連付けられるかを決定するステップと
のための命令をさらに含むことを特徴とする請求項９に記載のコンピュータシステム。
前記１つまたは複数のプログラムは、
前記ログインリクエストが前記アプリケーションプラットフォームに関連付けられる場合、
前記アプリケーションサーバへ前記ログインキーを転送するステップであって、前記ログインキーは、前記アプリケーションに関連付けられるアクセスリクエストを認証するために使用されるステップと、
前記ログインリクエストが前記アプリケーションに関連付けられる場合、
前記アプリケーションプラットフォームサーバへ前記ログインキーを転送するステップであって、前記ログインキーは、前記アプリケーションプラットフォームに関連付けられるアクセスリクエストを認証するために使用されるステップと
のための命令をさらに含むことを特徴とする請求項９に記載のコンピュータシステム。
前記１つまたは複数のプログラムは、
前記アプリケーションプラットフォームサーバおよび前記アプリケーションサーバの１つから前記ログインリクエストへの応答を受信するステップと、
前記応答へログインリクエストタイプビットを追加することによって、前記応答を更新するステップであって、前記ログインリクエストタイプビットは、前記応答が前記アプリケーションプラットフォームサーバまたは前記アプリケーションサーバからであるかを示すステップと、
前記クライアントデバイスへ前記更新された応答を転送するステップであって、前記ログインリクエストタイプビットは、前記応答が前記アプリケーションプラットフォームまたは前記アプリケーションによって処理されるべきかを示すステップと
のための命令をさらに含むことを特徴とする請求項９に記載のコンピュータシステム。
前記ログインリクエストは、ウェブソケットプロトコルベースの接続を介して前記クライアントデバイスから前記コンピュータへ送信されることを特徴とする請求項９に記載のコンピュータシステム。
前記アプリケーションプラットフォームサーバとの前記第１の接続は、短期的な接続であり、前記アプリケーションサーバとの前記第２の接続は、長期的な接続であることを特徴とする請求項９に記載のコンピュータシステム。
前記第１の接続は、ＡＪＡＸプロトコルに従って実装され、前記第２の接続は、ウェブソケットプロトコルに従って実装されることを特徴とする請求項１４に記載のコンピュータシステム。
コンピュータシステムの１つまたは複数のプロセッサによって実行するための１つまたは複数のプログラムを格納する非一時的コンピュータ読取可能な格納媒体であって、前記１つまたは複数のプログラムは、
前記クライアントデバイスからログインリクエストを受信するステップと、
前記ログインリクエストが前記クライアントデバイスでのアプリケーションプラットフォームまたは前記クライアントデバイスでのアプリケーションに関連付けられるかを決定するために前記ログインリクエストを分析するステップであって、前記アプリケーションは、前記アプリケーションプラットフォームによって管理されるステップと、
前記ログインリクエストが前記アプリケーションプラットフォームに関連付けられる場合、
アプリケーションプラットフォームサーバとの第１の接続を確立するステップと、
前記アプリケーションプラットフォームサーバへ前記ログインリクエストを転送するステップと、
前記アプリケーションプラットフォームサーバからログインキーを受信するステップと、
前記クライアントデバイスへ前記ログインキーを戻すステップであって、前記ログインキーが前記アプリケーションプラットフォームに関連付けられるステップと
前記ログインリクエストが前記アプリケーションに関連付けられる場合、
アプリケーションサーバとの第２の接続を確立するステップであって、前記アプリケーションサーバが前記アプリケーションプラットフォームサーバと異なるステップと、
前記アプリケーションサーバへ前記ログインリクエストを転送するステップと、
前記アプリケーションサーバからログインキーを受信するステップと、
前記クライアントデバイスへ前記ログインキーを戻すステップであって、前記ログインキーが前記アプリケーションに関連付けられるステップと
のための命令を含むことを特徴とする非一時的コンピュータ読取可能な格納媒体。
前記ログインリクエストを分析するための前記命令は、
前記ログインリクエストを伝えるデータパケットからヘッダを抽出するステップと、
前記ヘッダのログインリクエストタイプビットを特定するステップと、
前記ログインリクエストが前記ログインリクエストタイプビットに従って前記アプリケーションプラットフォームまたは前記アプリケーションに関連付けられるかを決定するステップと
のための命令をさらに含むことを特徴とする請求項１６に記載の非一時的コンピュータ読取可能な格納媒体。
前記１つまたは複数のプログラムは、
前記ログインリクエストが前記アプリケーションプラットフォームに関連付けられる場合、
前記アプリケーションサーバへ前記ログインキーを転送するステップであって、前記ログインキーは、前記アプリケーションに関連付けられるアクセスリクエストを認証するために使用されるステップと、
前記ログインリクエストが前記アプリケーションに関連付けられる場合、
前記アプリケーションプラットフォームサーバへ前記ログインキーを転送するステップであって、前記ログインキーは、前記アプリケーションプラットフォームに関連付けられるアクセスリクエストを認証するために使用されるステップと
のための命令をさらに含むことを特徴とする請求項１６に記載の非一時的コンピュータ読取可能な格納媒体。
前記１つまたは複数のプログラムは、
前記アプリケーションプラットフォームサーバおよび前記アプリケーションサーバの１つから前記ログインリクエストへの応答を受信するステップと、
前記応答へログインリクエストタイプビットを追加することによって、前記応答を更新するステップであって、前記ログインリクエストタイプビットは、前記応答が前記アプリケーションプラットフォームサーバまたは前記アプリケーションサーバからであるかを示すステップと、
前記クライアントデバイスへ前記更新された応答を転送するステップであって、前記ログインリクエストタイプビットは、前記応答が前記アプリケーションプラットフォームまたは前記アプリケーションによって処理されるべきかを示すステップと
のための命令をさらに含むことを特徴とする請求項１６に記載の非一時的コンピュータ読取可能な格納媒体。
前記アプリケーションプラットフォームサーバとの前記第１の接続は、短期的な接続であり、前記アプリケーションサーバとの前記第２の接続は、長期的な接続であることを特徴とする請求項１６に記載の非一時的コンピュータ読取可能な格納媒体。