JP6280471B2 - 接続管理方法、プログラムおよび接続管理システム - Google Patents

Description

本発明は、サーバ側でクライアントとサーバのバックエンドモジュール間の接続を媒介する接続管理方法およびシステムに関する。

モバイルインターネット（ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ）とは、スマートフォンやノートパンコンのようなモバイルデバイスを利用することで、移動中でもインターネットを媒介としてコミュニケーション、交際、情報検索、取引、娯楽などのサービスの提供を受けることができる、発展したインターネットサービスを指称するものである。最近では、インターネットのサービスであるワールドワイドウェブと本来のインターネットを区別せずにワールドワイドウェブをインターネットの代名詞のように使用するように、モバイルウェブ（ｍｏｂｉｌｅ Ｗｅｂ）が実質的なモバイルインターネットであると言える。

最近、このようなモバイルインターネットなどのモバイルネットワーク技術の発達によって大容量のマルチメディアデータの高速送信が可能となり、モバイルネットワークに接続可能なユーザ端末機の普遍的な普及により、検索、ショッピング、ゲーム、チャットなどのような多様な種類のモバイルコンテンツがユーザに提供されている。

しかし、従来技術では、サービスの海外進出により、国（国家）毎の通信／ネットワーク環境に応じて全体サーバを構築してサービスを提供しなければならないため、多くの初期費用が発生するという問題がある。

本発明は、サービスの海外進出時に、フロント（ｆｒｏｎｔ）サーバである接続管理サーバのみを国毎に構築し、接続管理サーバを介して海外のクライアントと国内に既に構築されているバックエンド（ｂａｃｋｅｎｄ）サーバとを仲介してサービスを提供することができる接続管理方法および接続管理システムを提供することを目的とする。

接続管理システムが実行する接続管理方法であって、クライアントから要請メッセージを受信し、前記要請メッセージに接続（ｃｏｎｎｅｃｔｉｏｎ）の認証タグおよびサービスタグを追加し、前記要請メッセージのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を利用して前記認証タグおよび前記サービスタグの権限を確認し、前記ＵＲＩを利用して前記要請メッセージに対応するサービスを検索し、前記検索されたサービスに前記要請メッセージを伝達することを含む接続管理方法が提供される。

一実施形態によると、前記要請メッセージは前記サービスを提供するサーバに送信され、前記サーバと前記接続管理システムの位置は、国単位の地理的な違いを有してもよい。

他の一実施形態によると、前記認証タグおよび前記サービスタグの権限を確認することは、前記接続管理システムに登録されたサービスに関する情報の許可レベルと前記認証タグの許可レベルとを比べて前記認証タグの権限を確認し、前記サービスタグと前記ＵＲＩに含まれたサービスタグとを比べて前記サービスタグの権限を確認することを含むことを特徴としてもよい。

さらに他の一実施形態によると、前記接続管理方法は、前記要請メッセージを伝達したサービスから応答メッセージを受信し、前記応答メッセージを前記クライアントに伝達することをさらに含んでもよい。

さらに他の一実施形態によると、前記接続管理方法は、前記要請メッセージおよび前記応答メッセージを選択的に記録することをさらに含んでもよい。

さらに他の一実施形態によると、前記サービスで前記認証タグを利用して前記要請メッセージが認証されることを特徴としてもよい。

少なくとも一つのプログラムを格納する少なくとも一つのストレージユニットと、少なくとも一つのプロセッサと、を備え、前記少なくとも一つのプロセッサは、前記少なくとも一つのプログラムの制御に応じて、クライアントから要請メッセージを受信するプロセスと、前記要請メッセージに接続（ｃｏｎｎｅｃｔｉｏｎ）の認証タグおよびサービスタグを追加するプロセスと、前記要請メッセージのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を利用して前記認証タグおよび前記サービスタグの権限を確認するプロセスと、前記ＵＲＩを利用して前記要請メッセージに対応するサービスを検索するプロセスと、前記検索されたサービスに前記要請メッセージを伝達するプロセスと、を処理することを特徴とする接続管理システムが提供される。

クライアントから受信された要請メッセージに認証タグおよびサービスタグを追加し、前記要請メッセージのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を利用して認証タグおよびサービスタグの権限を確認する確認部と、前記ＵＲＩを利用して前記要請メッセージとサービスをマッピングするマッピング部と、前記要請メッセージをマッピングされたサービスに伝達する接続部と、を備える接続管理システムが提供される。

サービスの海外進出時に、フロント（ｆｒｏｎｔ）サーバである接続管理サーバのみを国毎に構築し、接続管理サーバを介して海外のクライアントと国内に既に構築されているバックエンド（ｂａｃｋｅｎｄ）サーバとを仲介してサービスを提供することができる。

本発明の一実施形態において、接続管理システムの概括的な様子の一例を示した図である。 本発明の一実施形態において、接続管理システムの概括的な様子の他の例を示した図である。 本発明の一実施形態において、接続管理システムの内部構成を説明するためのブロック図である。 本発明の一実施形態において、要請および応答のプロセスを説明するためのフローチャートである。 本発明の一実施形態において、クライアントの動作を説明するためのフローチャートである。 本発明の他の実施形態において、接続管理方法を示したフローチャートである。

以下、本発明の実施形態について、添付の図面を参照しながら詳細に説明する。

図１は、本発明の一実施形態において、接続管理システムの概括的な様子の一例を示した図であり、図２は、本発明の一実施形態において、接続管理システムの概括的な様子の他の例を示した図である。接続管理システム１００は、デバイスがサービス利用のために最初にアクセスするサーバであって、一例としてリバースプロキシ（ｒｅｖｅｒｓｅ ｐｒｏｘｙ）であってもよい。このような接続管理システム１００は、マッシュアップ（ｍａｓｈｕｐ）１１０によってＬＮＣ（Ｌｏｃａｌ Ｎｅｔｗｏｒｋ Ｃｅｎｔｅｒ）、ログイン、プロファイル、ランキング、マーケット、決済などに関する多様なサービス１２０とデバイスとの接続を管理してもよい。ここで、マッシュアップ１１０はゲートウェイを含んでもよく、サービス１２０はそれぞれのサービスを提供するサーバを含んでもよい。

このとき、図１の実施形態では、クライアント１３０またはゲームサーバ１４０とサービス１２０との接続例を示している。例えば、図１では、クライアント１３０がゲームサーバ１４０からゲームサービスの提供を受けるにあたり、接続管理システム１００を介してログイン、ランキング、プロファイル、決済などのサービス提供を受けることを示している。もし、ゲームサーバ１４０が提供するゲームサービスが海外進出するとき、海外には国毎に、サーバ１４０と接続管理システム１００が構築されてもよく、国内に既に構築されているログインやランキングなどのサービス１２０とゲームサーバ１４０またはクライアント１３０とを接続管理システム１００を介して接続して処理することにより、初期構築費用を節減することができる。さらに、図２の実施形態では、ゲームサーバ１４０のゲームサービスに関する機能もサービス１２０に含まれるようにして、海外進出時には、国毎に接続管理システム１００のみを構築して全体サービスを提供できる例を示している。

このために、接続管理システム１００は、メッセージ送信、認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）や許可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）のようなセキュリティなどのように、デバイスとサービスの間の接続に関連する多様な種類の処理を実行してもよい。例えば、モバイル環境におけるデバイスとサービスの間の無線接続は、有線接続に比べると安定的でない。したがって、本発明の実施形態において、接続管理システム１００を介してログイン、セキュリティ、アクセスレベルサポートなどのためにデバイスとの接続を処理し、接続管理システム１００とサービス１２０を提供するサーバとの接続は安定的な有線接続を利用することにより、デバイスとサービス１２０の間の接続を安定的に処理してもよい。

また、ログインプロセスのためには、複数の接続と通信が必要となる。しかし、本発明の一実施形態によれば、ログインプロセスは接続管理システム１００で大部分が先に処理され、サービス１２０の観点では一度の接続（一例として、接続管理システム１００との一度の有線接続）のみで、クライアント１３０とのログインプロセスが処理されてもよい。

また、従来は、クライアント１３０への多数の認証チェックによる負荷が発生していたが、本発明の一実施形態によれば、接続管理システム１００で認証チェックのための大部分のプロセスが先に処理（一例として、接続管理システム１００で認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）と許可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）をコントロール）されるため、サービス１２０の観点では接続管理システム１００との一度の認証チェックによってクライアント１３０を認証できるようになる。

これだけでなく、クライアント１３０またはゲームサーバ１４０と接続管理システム１００の間の通信には、ウェブソケット（ｗｅｂｓｏｃｋｅｔ）やＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などのようなウェブプロトコル、ＭＲＳ（Ｍｅｓｓａｇｅ Ｒｏｕｔｉｎｇ Ｓｙｓｔｅｍ）プロトコルのような様々なプロトコルが利用されてもよい。一例として、ウェブソケットのみを利用したり選択的にＨＴＴＰを利用したりするなど、様々なプロトコルが様々な形態で利用されてもよい。この反面、接続管理システム１００とサービス１２０との間の通信には、ＭＲＳ（Ｍｅｓｓａｇｅ Ｒｏｕｔｉｎｇ Ｓｙｓｔｅｍ）プロトコルが利用されてもよい。この場合、ウェブソケットを使用したウェブブラウザの支援が可能となり、ＷＳＳ（Ｗｅｂ Ｓｏｃｋｅｔ Ｓｅｃｕｒｅ）を活用したＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）の使用が可能となる。

さらに、図２では、接続管理システム１００を管理するための管理ページ２１０を開示している。このとき、接続管理システム１００と管理ページ２１０との間の通信には、一例としてＨＴＴＰが利用されてもよい。

ここで、接続管理システム１００の位置とサービス１２０を提供するサーバの位置は、国単位の地理的な違いを有してもよい。例えば、サービス１２０を提供するサーバは韓国に構築されてもよく、接続管理システム１００はアメリカに構築されてもよい。したがって、サービスのアメリカ進出のために全体システムをアメリカにすべて構築する必要はなく、接続管理システム１００の構築のみで海外サービスが可能となる。

図３は、本発明の一実施形態において、接続管理システムの内部構成を説明するためのブロック図である。本実施形態に係る接続管理システム３００は、図１または図２を参照しながら説明した接続管理システム１００に対応してもよく、確認部３１０、マッピング部３２０、接続部３３０、および記録部３４０を備えてもよい。例えば、接続管理システム３００は、少なくとも一つのプログラムを格納する少なくとも一つのストレージユニットおよび少なくとも一つのプロセッサを備えてもよく、確認部３１０、マッピング部３２０、接続部３３０、および記録部３４０は、少なくとも一つのプロセッサを少なくとも一つのプログラムの制御に応じて動作させるためのモジュールであってもよい。

確認部３１０は、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）とタグを確認する。一例として、タグは、接続のタギングのための認証タグおよびサービスタグを含んでもよい。接続管理システム３００でクライアントからの要請を受信した場合に、確認部３１０は、要請メッセージのヘッダに接続のタギングのためのタグを追加してもよい。このとき、確認部３１０は、ＵＲＩによって確認されるサービスの許可レベルとクライアントに許容された許可レベル（認証タグの許可レベル（ａｕｔｈｚ））を利用してクライアントを認証してもよい。クライアントからの要請は、「クライアントインタフェース」によって接続管理システム３００に受信されてもよい。

マッピング部３２０は、クライアントからの要請とサービスをマッピングする。例えば、マッピング部３２０は、クライアントから要請メッセージが受信されると、この要請メッセージがどのようなサービスに伝達されなければならないかを確認して、この要請メッセージとサービスとを互いにマッピングしてもよい。例えば、マッピング部３２０は、接続管理システム３００に登録されたサービスに関する情報と要請メッセージのＵＲＩを利用して要請メッセージに対応するサービスを検索およびマッピングしてもよい。接続管理システム３００に登録されたサービスに関する情報は、後述する表３のように、ＵＲＩとサービスのアドレス（サービスを提供するサーバのアドレス）とを互いに関連して含んでもよい。接続管理システム３００は、制御インタフェースを利用し、図２を参照しながら説明した管理ページ２１０と接続してもよい。管理者は、管理ページ２１０を利用して接続管理システム３００にサービスを登録したり、アプリケーションをインストール（一例として、ホットデプロイ設定（ｈｏｔ ｄｅｐｌｏｙ ｓｅｔｔｉｎｇ））したり、または接続管理システム３００をモニタリングしてもよい。

接続部３３０は、メッセージサービスを接続してクライアントからの要請を確認されたサービスに伝達する。一例として、メッセージサービスは、ＭＲＳ（Ｍｅｓｓａｇｅ Ｒｏｕｔｉｎｇ Ｓｙｓｔｅｍ）プロトコルを利用するサービスであってもよい。図３は、接続部３３０がサービスと通信するための「サービスインタフェース」を示している。また、図３に示された「接続インタフェース」は、タグの接続またはクライアントへのリアルタイムメッセージプッシュ（ｐｕｓｈ）のために利用されてもよい。メッセージプッシュは、一例として、サービスからの応答メッセージを伝達するために利用されてもよい。

記録部３４０は、要請および応答のうち少なくとも一つを選択的に記録（ｌｏｇｇｉｎｇ）する。要請や応答は、イベント、データベース、ローカルストレージなどの様々な方式で記録されてもよい。

また、図３で説明した機能の他にも、接続管理システム３００は、クライアントとの接続が切れた場合、クライアントの再接続を誘導するための機能、パケット暗号化機能、またはプラグイン機能などを含んでもよい。これだけでなく、クライアント側ではエックスベース（ＸＢａｓｅ）互換性を取り除くことにより、「ＸＩｎＮｅｔｗｏｒｋ」を取り除き、ライブラリの大きさを減らすことができる。

図４は、本発明の一実施形態において、要請および応答のプロセスを説明するためのフローチャートである。本実施形態に係るプロセスは、接続管理システムによって実行されてもよい。ここで、接続管理システムは、図１または図２を参照しながら説明した接続管理システム１００または図３を参照しながら説明した接続管理システム３００に対応してもよい。

ステップ４１０で、接続管理システムは、クライアントから要請を受信する。例えば、クライアントは接続管理システムに要請メッセージを送信し、接続管理システムは要請メッセージの受信によってクライアントから要請を受信する。

ステップ４２０で、接続管理システムは、接続のタグを要請のヘッドに追加する。例えば、接続管理システムは、要請メッセージのヘッドに接続のためのタグ（認証タグおよびサービスタグ）を追加してもよい。

ステップ４３０で、接続管理システムは、ＵＲＩから許可（Ａｕｔｈｏｒｉｚａｔｉｏｎ）を確認する。一例として、後述する表３では、サービス登録の例として、ＵＲＩと許可レベルが互いに関連した様子を示している。接続管理システムは、ＵＲＩを利用して関連する許可レベルを確認してもよい。例えば、接続管理システムは、後述する表２の認証タグに含まれた許可レベルと表３の許可レベルとを比べてクライアント要請を許可するか否かを決めてもよい。もし、クライアントの要請が許可されなければ、接続管理システムは、クライアントにエラー応答を送信してもよい。

ステップ４４０で、接続管理システムは、ＵＲＩからクライアントの要請に対応するサービスを検索する。例えば、表３では、ＵＲＩとサービスのアドレスが互いに関連した様子を示している。接続管理システムは、表３のように、登録されたサービスに関する情報を利用してＵＲＩから要請に対応するサービスを検索してもよい。

ステップ４５０で、接続管理システムは、検索されたサービスにクライアントの要請を伝達する。例えば、接続管理システムは、検索されたサービスのアドレスにクライアントの要請メッセージを送信してもよい。

ステップ４６０で、接続管理システムは、サービスから応答を受信する。例えば、接続管理システムは、サービスから送信される応答メッセージを受信してもよい。

ステップ４７０で、接続管理システムは、応答に対応するクライアントを検索してもよい。

ステップ４８０で、接続管理システムは、検索されたクライアントに応答を伝達してもよい。例えば、接続管理システムは、応答メッセージをクライアントに送信してもよい。

下の表１は、許可レベルの例を示している。

ここで、表１は、許可（ａｕｔｈｚ）レベルの値が大きいほど高いセキュリティレベルをもつことを示している。

下の表２は、接続の認証タグ（ａｕｔｈｔａｇ）を説明するための一例を示している。

例えば、接続「３」の要請ヘッダまたは応答ヘッダには、認証「４０１０００００３５２５２５（６４ビット）」とＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）ナンバー「１（ＩＯＳ）」、さらにゲームナンバー「１００３１」が含まれてもよい。他の例として、接続「５」の要請ヘッダまたは応答ヘッダには、認証「１０．３５．２５．１１：２１３３２（６４ビット）」、ＯＳナンバー「０（ｓｅｒｖｅｒ）」、さらにゲームナンバー「１０００３」が含まれてもよい。

このとき、要請ＵＲＩを利用して許可（ａｕｔｈｚ）タグ権限が確認されてもよい。例えば、下の表３は、サービス登録の例を示している。

表３では、ＵＲＩと許可レベルが互いに関連しているため、ＵＲＩによって許可タグ権限が確認されてもよい。

下の表４は、接続のＳＶＣ（ｓｅｒｖｉｃｅ）タグの例を示している。

例えば、接続「３」の要請ヘッダまたは応答ヘッダには、ＳＶＣ−ｍａｓｈｕｐのためのタグの値「ｍａｓｈｕｐ＿ｔａｇ＿１」とＳＶＣ−ｒａｎｋのためのタグの値「ｒａｎｋ＿ｔａｇ＿１」が含まれてもよい。他の例として、接続「５」の要請ヘッダまたは応答ヘッダには、ＳＶＣ−ｒａｎｋのためのタグの値「ｒａｎｋ＿ｔａｇ＿３」が含まれてもよい。このとき、要請ＵＲＩを利用してＳＶＣタグの権限が確認されてもよい。

一実施形態として、接続管理システムは、クライアントから受信された要請メッセージのヘッダに接続のタグ（認証タグ（表２参照）とサービスタグ（表４参照））を追加してもよい。認証タグは、ユーザの認証のための情報（ａｕｔｈｎ）とアクセス許可のための情報（ａｕｔｈｚ）とを含んでもよい。このとき、接続管理システムは、要請メッセージに含まれたサービスのＵＲＩ（一例として、表３の／ｍａｓｈｕｐ＿１＿３／ｇｅｔＰｈｏｎｅＮｏ）を利用してサービスのアドレス（一例として、表３のＡ：０：８２０１：０：０：０）とサービスの許可レベル（一例として、表３の３０（ａｕｔｈｚ））を確認してもよく、クライアントに許容されたアクセスレベルが許可レベルを満たすかを確認してもよい。一例として、クライアントが表２の接続「６」に該当する「サーバ」である場合、クライアントに許容されたアクセスレベルが「３０」であり、このサービスの許可レベル「３０」を満たすためサービスへのアクセスが許容されてもよく、接続管理システムは該当のサービスに要請メッセージを伝達してもよい。この反面、クライアントが表２の接続「３」に該当する「クライアント」である場合、クライアントに許容されたアクセスレベルは「１０」であり、このサービスの許可レベル「３０」を満たすことができないため、接続管理システムはクライアントにエラー応答メッセージを送信してもよい。また、接続管理システムは、認証タグに関する情報を接続別に表２のように管理するのと同様に、サービスタグに関する情報も表４のように接続別に管理してもよい。これだけでなく、ＵＲＩはサービスに関する情報を含んでおり、接続管理システムは、ＵＲＩに含まれたサービスに関する情報と表４を利用してサービスタグに対する権限を確認してもよい。

図５は、本発明の一実施形態において、クライアントの動作を説明するためのフローチャートである。

ステップ５１０で、クライアントは、接続管理システムとの接続を試みる。例えば、クライアントは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のようなプロトコルを利用して接続管理システムとの接続を試みてもよい。このとき、接続管理システムは、ＭＲＳのためのソケットを割り当ててもよい。

ステップ５２０で、クライアントは、要請に対する認証プロセスを処理する。この場合、接続管理システムは、タグを認証および許可してもよい。

ステップ５３０で、クライアントは、接続管理システムにサービスのための要請を送信する。このとき、接続管理システムはＵＲＩを確認し、要請のためのサービスハンドラ（ｓｅｒｖｉｃｅ ｈａｎｄｌｅｒ）を検索して許可（ａｕｔｈｚ）を確認し、サービスに要請を送信してもよい。

図６は、本発明の他の実施形態において、接続管理方法を示したフローチャートである。本実施形態に係る接続管理方法は、接続管理システムによって実行されてもよい。ここで、接続管理システムは、図１または図２を参照しながら説明した接続管理システム１００または図３を参照しながら説明した接続管理システム３００に対応してもよい。このような接続管理システムは、少なくとも一つのストレージユニットと少なくとも一つのプロセッサを備えてもよく、接続管理方法に含まれた各ステップは、少なくとも一つのプロセッサによって処理されてもよい。

ステップ６１０で、接続管理システムは、サービスを提供する複数のサーバそれぞれに対して登録されるサービス情報を管理する。一例として、サービス情報は、接続管理システムが含む少なくとも一つのストレージユニットに格納されて管理されてもよい。

ステップ６２０で、接続管理システムは、クライアントとの無線通信接続を管理し、無線通信接続によってクライアントから要請メッセージを受信する。一例として、接続管理システムは、無線通信接続を管理するため、クライアントとの無線通信接続が切れる場合には、クライアントに再接続を要請する信号を送信してもよい。

ステップ６３０で、接続管理システムは、サービス情報を利用して要請メッセージに対応するサービスを検索する。上述した表３を参照しながら登録されたサービス情報についての例を説明し、要請メッセージが含むＵＲＩを利用して要請メッセージに対応するサービスを検索できることを説明した。

ステップ６４０で、接続管理システムは、検索されたサービスを提供するサーバとの有線通信接続を利用し、要請メッセージを検索されたサービスを提供するサーバに伝達する。

このように、本発明の実施形態では、接続管理システムでモバイル環境のクライアントとの無線通信接続を管理し、接続管理システムとサービスを提供するサーバとの間には有線通信接続を利用することにより、クライアントとサービスを提供するサーバとが安定して接続する環境を提供することができる。

他の実施形態として、接続管理方法は、図６を参照しながら説明したステップ（６１０ないし６４０）の他に、サービス情報を利用して要請メッセージに対応するサービスへのアクセス許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）権限を確認するステップをさらに含んでもよい。このとき、ステップ６４０は、アクセス許可権限に基づいて要請メッセージが対応するサービスへのアクセスが許可されるかを決めるステップ（図示せず）、およびアクセスが許可された場合、要請メッセージを検索されたサービスを提供するサーバに伝達するステップ（図示せず）を含んでもよい。上述した図に示されていないステップも接続管理システムによって実行されてもよく、接続管理システムが含む少なくとも一つのプロセッサによって処理されてもよい。

このように、本発明の実施形態によると、サービスの海外進出時に、フロント（ｆｒｏｎｔ）サーバである接続管理サーバのみを国毎に構築し、接続管理サーバを介して海外のクライアントと国内に既に構築されているバックエンド（ｂａｃｋｅｎｄ）サーバとを仲介してサービスを提供することができる。

上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素およびソフトウェア構成要素の組み合わせによって実現されてもよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ、ＦＰＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行して応答することができる他のデバイスのように、１つ以上の汎用コンピュータまたは特殊目的用のコンピュータを利用して実現されてもよい。処理装置は、Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してもよい。また、処理装置は、ソフトウェアの実行に応答し、データをアクセス、保存、操作、処理、および生成してもよい。理解の便宜のために、処理装置は１つが使用されると説明される場合もあるが、この技術分野において通常の知識を有する者は、処理装置が複数の処理要素（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ）および／または複数類型の処理要素を含んでもよい。例えば、処理装置は、複数のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでもよい。また、並列プロセッサ（ｐａｒａｌｌｅｌ ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成（ｐｒｏｃｅｓｓｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）も可能である。

ソフトウェアは、コンピュータプログラム（ｃｏｍｐｕｔｅｒ ｐｒｏｇｒａｍ）、コード（ｃｏｄｅ）、命令（ｉｎｓｔｒｕｃｔｉｏｎ）、またはこれらのうちの１つ以上の組み合わせを含んでもよく、所望とおりに動作するように処理装置を構成したり、独立的または結合的に（ｃｏｌｌｅｃｔｉｖｅｌｙ）処理装置を命令したりしてもよい。ソフトウェアおよび／またはデータは、処理装置によって解釈されたり処理装置に命令またはデータを提供したりするために、ある類型の機械、構成要素（ｃｏｍｐｏｎｅｎｔ）、物理的装置、仮想装置（ｖｉｒｔｕａｌ ｅｑｕｉｐｍｅｎｔ）、コンピュータ記録媒体または装置、または送信される信号波（ｓｉｇｎａｌ ｗａｖｅ）に永久的または一時的に具体化（ｅｍｂｏｄｙ）されてもよい。ソフトウェアは、ネットワークによって接続したコンピュータシステム上に分散し、分散した方法によって格納されたり実行されたりしてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてもよい。

実施形態に係る方法は、様々なコンピュータ手段によって実行が可能なプログラム命令形態で実現されてコンピュータで読み取り可能な媒体に記録されてもよい。コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独または組み合わせて含んでもよい。媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよく、コンピュータソフトウェアの当業者に公知されて使用可能なものであってもよい。コンピュータで読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体（ｍａｇｎｅｔｉｃ ｍｅｄｉａ）、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体（ｏｐｔｉｃａｌ ｍｅｄｉａ）、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような磁気−光媒体（ｍａｇｎｅｔｏ−ｏｐｔｉｃａｌ ｍｅｄｉａ）、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例としては、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。上述したハードウェア装置は、実施形態の動作を実行するために１つ以上のソフトウェアモジュールとして作動するように構成されてもよく、その逆も同じである。

以上のように、実施形態を限定された実施形態と図面に基づいて説明したが、該当する技術分野において通常の知識を有する者であれば、上述した記載から多様な修正および変形が可能であることが理解できるであろう。例えば、説明された技術が説明された方法とは異なる順序で実行されたり、および／または説明されたシステム、構造、装置、回路などの構成要素が説明された方法とは異なる形態で結合または組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

１００、３００：接続管理システム
３１０：確認部
３２０：マッピング部
３３０：接続部
３４０：記録部

Claims (12)

1. 接続管理システムが実行する接続管理方法であって、
   クライアントから要請メッセージを受信し、
   前記要請メッセージに接続（ｃｏｎｎｅｃｔｉｏｎ）の認証タグおよびサービスタグを追加し、
   前記要請メッセージに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を利用して、前記接続管理システムに登録されたサービスに関する情報の許可レベルと前記認証タグに含まれる許可レベルとを比べて、前記認証タグの権限を確認し、
   前記ＵＲＩに含まれるサービスに関する情報と前記サービスタグとを比べて、前記サービスタグの権限を確認し、
   前記サービスに対して確認した前記認証タグの権限に基づいて前記クライアントを認証し、
   前記ＵＲＩを利用して前記要請メッセージに対応するサービスを検索し、
   前記検索されたサービスに前記要請メッセージを伝達すること
   を含む、接続管理方法。
2. 前記要請メッセージは、前記サービスを提供するサーバに送信され、
   前記サーバと前記接続管理システムの位置は、国単位の地理的な違いを有することを特徴とする、請求項１に記載の接続管理方法。
3. 前記要請メッセージを伝達したサービスから応答メッセージを受信し、
   前記応答メッセージを前記クライアントに伝達すること
   をさらに含む、請求項１に記載の接続管理方法。
4. 前記要請メッセージおよび前記応答メッセージを選択的に記録すること
   をさらに含む、請求項３に記載の接続管理方法。
5. 接続管理システムが実行する接続管理方法であって、
   サービスを提供する複数のサーバそれぞれに対して登録されるサービス情報を管理し、
   クライアントとの無線通信接続を管理し、前記無線通信接続によって前記クライアントから要請メッセージを受信し、
   前記要請メッセージに接続（ｃｏｎｎｅｃｔｉｏｎ）の認証タグおよびサービスタグを追加し、
   前記サービス情報を利用して、前記要請メッセージに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）に対応する許可レベルと前記認証タグに含まれる許可レベルとを比べて、サービスへのアクセス許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）権限を確認し、
   前記ＵＲＩに含まれるサービスに関する情報と前記サービスタグとを比べて、前記アクセス許可権限を確認し、
   前記アクセス許可権限に基づいて前記要請メッセージが前記対応するサービスへのアクセスが許可されるかを決め、
   前記アクセスが許可された場合、前記サービス情報を利用して前記要請メッセージに対応するサービスを検索し、
   前記検索されたサービスを提供するサーバとの有線通信接続を利用し、前記要請メッセージを前記検索されたサービスを提供するサーバに伝達すること
   を含む、接続管理方法。
6. 請求項１ないし請求項５のうちいずれか一項の方法をコンピュータに実行させるためのプログラム。
7. 少なくとも一つのプログラムを格納する少なくとも一つのストレージユニットと、
   少なくとも一つのプロセッサと、を備え、
   前記少なくとも一つのプロセッサは、前記少なくとも一つのプログラムの制御に応じて、
   クライアントから要請メッセージを受信するプロセスと、
   前記要請メッセージに接続（ｃｏｎｎｅｃｔｉｏｎ）の認証タグおよびサービスタグを追加するプロセスと、
   前記要請メッセージに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を利用して、接続管理システムに登録されたサービスに関する情報の許可レベルと前記認証タグに含まれる許可レベルとを比べて、前記認証タグの権限を確認するプロセスと、
   前記ＵＲＩに含まれるサービスに関する情報と前記サービスタグとを比べて、前記サービスタグの権限を確認するプロセスと、
   前記サービスに対して確認した前記認証タグの権限に基づいて前記クライアントを認証するプロセスと、
   前記ＵＲＩを利用して前記要請メッセージに対応するサービスを検索するプロセスと、
   前記検索されたサービスに前記要請メッセージを伝達するプロセスと、
   を処理することを特徴とする、接続管理システム。
8. 前記要請メッセージは、前記サービスを提供するサーバに送信され、
   前記サーバとは、位置が国単位の地理的な違いを有することを特徴とする、請求項７に記載の接続管理システム。
9. クライアントから受信された要請メッセージに認証タグおよびサービスタグを追加し、前記要請メッセージに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を利用して、接続管理システムに登録されたサービスに関する情報の許可レベルと前記認証タグに含まれる許可レベルとを比べて、前記認証タグの権限を確認し、前記ＵＲＩに含まれるサービスに関する情報と前記サービスタグとを比べて、前記サービスタグの権限を確認し、前記サービスに対して確認した前記認証タグの権限に基づいて前記クライアントを認証する確認部と、
   前記ＵＲＩを利用して前記要請メッセージとサービスをマッピングするマッピング部と、
   前記要請メッセージをマッピングされたサービスに伝達する接続部と、
   を備える、接続管理システム。
10. 前記接続部は、
    前記サービスから前記要請メッセージに対する応答メッセージを受信し、
    前記要請メッセージおよび前記応答メッセージを選択的に記録する記録部
    をさらに含む、請求項９に記載の接続管理システム。
11. 前記要請メッセージは、前記マッピングされたサービスを提供するサーバに送信され、
    前記サーバとは、位置が国単位の地理的な違い差を有することを特徴とする、請求項９に記載の接続管理システム。
12. サービスを提供する複数のサーバそれぞれに対して登録されるサービス情報を格納する少なくとも一つのストレージユニットと、
    少なくとも一つのプロセッサと、
    を含み、
    前記少なくとも一つのプロセッサは、
    クライアントとの無線通信接続を管理し、前記無線通信接続によって前記クライアントから要請メッセージを受信するプロセスと、
    前記要請メッセージに接続（ｃｏｎｎｅｃｔｉｏｎ）の認証タグおよびサービスタグを追加するプロセスと、
    前記サービス情報を利用して、前記要請メッセージに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）の許可レベルと前記認証タグに含まれる許可レベルとを比べて、サービスへのアクセス許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）権限を確認するプロセスと、
    前記ＵＲＩに含まれるサービスに関する情報と前記サービスタグとを比べて、前記アクセス許可権限を確認するプロセスと、
    前記アクセス許可権限に基づいて前記要請メッセージが対応するサービスへのアクセスが許可されるかを決め、前記アクセスが許可された場合、前記サービス情報を利用して前記要請メッセージに対応するサービスを検索するプロセスと、
    前記検索されたサービスを提供するサーバとの有線通信接続を利用し、前記要請メッセージを前記検索されたサービスを提供するサーバに伝達するプロセスと、
    を処理することを特徴とする、接続管理システム。
    
    
    

Images