(57)【要約】  様々な実施例が、サービスポイントを変更する方法を提供する。方法に基づくと、サービングサービスポイントは、変更要求を取得するとともに、変更要求からユーザＩＤを取得し、変更要求を使用することによって、ターゲットサービスポイントを位置付け、ユーザＩＤに対応するサービングユーザデータを取得し、サービングユーザデータをターゲットサービスポイントに送信し、ターゲットサービスポイントによって返される変更応答を受信し、ターゲットサービスポイントに接続するために、ユーザＩＤに対応するクライアントをリダイレクトする。様々な実施例はまた、サービスポイントを変更するシステムを提供する。上述の方法及びシステムは、サービスポイントをリアルタイムで変更することができる。
2015519844.tif 000002
【特許請求の範囲】
【請求項１】
サービスポイントを変更する方法であって、
サービングサービスポイントによって、変更要求を取得するとともに、前記変更要求からユーザＩＤを取得するステップと、
前記サービングサービスポイントによって、前記変更要求を使用することによって、ターゲットサービスポイントを位置付けるステップと、
前記サービングサービスポイントによって、前記ユーザＩＤに対応するサービングユーザデータを取得し、前記サービングユーザデータを、前記ターゲットサービスポイントに送信するステップと、
前記サービングサービスポイントによって、前記ターゲットサービスポイントから変更応答を受信し、前記ターゲットサービスポイントに接続するために、前記ユーザＩＤに対応するクライアントをリダイレクトするステップと、
を有する方法。
【請求項２】
前記サービングサービスポイントによって、前記変更要求を使用することによって、前記ターゲットサービスポイントを位置付ける前記ステップは、
前記サービングサービスポイントによって、経路取得要求を、ルーティングポイントに送信するステップと、
前記経路取得要求を受信した後、前記ルーティングポイントによって、前記ターゲットサービスポイントを前記サービングサービスポイントに振り当て、前記ターゲットサービスポイントに対応する経路情報を取得し、前記経路情報を、前記サービングサービスポイントに返すステップと
を有する、請求項１に記載の方法。
【請求項３】
前記サービングサービスポイントによって、前記変更要求を使用することによって、前記ターゲットサービスポイントを位置付ける前記ステップは
前記サービングサービスポイントによって、前記変更要求から前記ターゲットサービスポイントのＩＤを取得するステップと、
前記サービングサービスポイントによって、前記ターゲットサービスポイントの前記ＩＤを使用することによって、事前に定義されたルーティングポイントから前記ターゲットサービスポイントまでの経路に関する経路情報を取得するステップと
を有する、請求項１に記載の方法。
【請求項４】
前記経路情報は、少なくとも１つのプロキシポイントの少なくとも１つのＩＤ及び前記少なくとも１つのプロキシポイントのホッピングシーケンスを有し、
前記サービングサービスポイントによって、前記サービングユーザデータを、前記ターゲットサービスポイントに送信するステップは、
前記サービングサービスポイントによって、前記経路情報における前記少なくとも１つのプロキシポイントの前記少なくとも１つのＩＤを使用することによって、データを転送するための少なくとも１つのプロキシポイントを決定するステップと、
前記サービングサービスポイントによって、前記経路情報に基づいて、前記サービングユーザデータを前記少なくとも１つのプロキシポイントに送信するステップと、
前記少なくとも１つのプロキシポイントによって、前記経路情報における前記ホッピングシーケンスに基づいて、ホップ・バイ・ホップで、前記サービングユーザデータを前記ターゲットサービスポイントに転送するステップと
を有する、請求項３に記載の方法。
【請求項５】
前記少なくとも１つのプロキシポイントは、少なくとも１つの階層に属し、
前記少なくとも１つのプロキシポイントによって、前記経路情報における前記ホッピングシーケンスに基づいて、ホップ・バイ・ホップで、前記サービングユーザデータを前記ターゲットサービスポイントに転送する前記ステップは、
前記少なくとも１つのプロキシポイントによって、前記経路情報における前記ホッピングシーケンスに基づいて、ホップ・バイ・ホップで、且つ階層ずつ、前記サービングユーザデータを前記ターゲットサービスポイントに転送するステップ
を有する、請求項４に記載の方法。
【請求項６】
前記サービングサービスポイントによって、前記サービングユーザデータを前記ターゲットサービスポイントに送信するステップの前に、
前記経路情報を使用することによって、前記経路情報において識別された前記少なくとも１つのプロキシポイントの負荷に関する第１情報と、前記ターゲットサービスポイントの負荷に関する第２情報とを取得するステップと、
前記サービングサービスポイントによって、前記第１情報及び前記第２情報に基づくブロッキングキューを使用することによって、前記変更要求を処理するステップと
をさらに有する、請求項４に記載の方法。
【請求項７】
前記サービングサービスポイントによって、前記第１情報及び前記第２情報に基づくブロッキングキューを使用することによって、前記変更要求を処理する前記ステップは、
前記第１情報及び前記第２情報と事前に定義された重みとを使用することによって、負荷容量を計算するか、前記負荷容量が、閾値よりも大きい場合、前記サービングユーザデータによって、前記ターゲットサービスポイントに送信する前記ステップを実行するか、又は前記負荷容量が、前記閾値よりも大きくない場合、前記変更要求を事前に定義されたブロッキングキューに追加するステップ
を有する、請求項６に記載の方法。
【請求項８】
前記サービングサービスポイントによって、前記第１情報及び前記第２情報に基づくブロッキングキューを使用することによって、前記変更要求を処理する前記ステップは、
前記サービングサービスポイントによって、間隔を置いて前記ブロッキングキューから変更要求を取得するとともに、前記変更要求を使用することによって、前記ターゲットサービスポイントを位置付ける前記ステップを実行するステップ
を有する、請求項７に記載の方法。
【請求項９】
前記サービングサービスポイントによって、前記サービングユーザデータを前記ターゲットサービスポイントに送信するステップの前に、
前記サービングサービスポイントによって、サービス要件に基づいて、前記サービングユーザデータをフィルタリングするステップ
をさらに有する、請求項１から８のいずれか1項に記載の方法。
【請求項１０】
前記ターゲットサービスポイントによって、前記サービングサービスポイントを位置付けるステップと、
前記ターゲットサービスポイントによって、前記ターゲットサービスポイント内に格納された前記ユーザＩＤに対応するターゲットユーザデータを取得するとともに、前記ターゲットユーザデータを前記サービングサービスポイントに送信するステップと、
前記サービングサービスポイントによって、前記ターゲットユーザデータを受信し、前記ターゲットユーザデータを前記サービングユーザデータと統合し、ポイント返還応答を、前記ターゲットサービスポイントに返すとともに前記クライアントとの接続を回復するステップと
をさらに有する、請求項１から８のいずれか1項に記載の方法。
【請求項１１】
前記サービングサービスポイントによって、応答を前記ターゲットサービスポイントに返すステップの後に、
前記ターゲットサービスポイントによって、前記ポイント返還応答を受信するとともに、前記ターゲットユーザデータを削除するステップ
をさらに有する、請求項１０に記載の方法。
【請求項１２】
前記サービングサービスポイントによって、前記ターゲットサービスポイントを位置付ける前記ステップは、
前記ターゲットサービスポイントによって、変更応答を前記サービングサービスポイントに返すとともに、サービング期間を監視するステップと、
前記サービング期間がタイムアウト時期に達したと判断された後、前記ターゲットサービスポイントによって、前記サービングサービスポイントを位置付ける前記ステップを実行するステップと
を有する、請求項１０に記載の方法。
【請求項１３】
前記サービングサービスポイントによって、前記ターゲットサービスポイントによって返された前記ポイント返還応答を受信するステップの後に、
前記サービングサービスポイントによって、前記サービングユーザデータをロックするステップと、
前記ターゲットユーザデータを前記サービングユーザデータと統合する前に、
前記サービングサービスポイントによって、前記サービングユーザデータをアンロックするステップと
をさらに有する、請求項１０に記載の方法。
【請求項１４】
前記サービングサービスポイントによって、前記ターゲットサービスポイントによって返された前記変更応答を受信するステップの後に、
前記ターゲットサービスポイントによって、前記サービングサービスポイント及び前記ユーザＩＤに基づく暗号鍵を生成するステップ
をさらに有する、請求項１から８のいずれか１項に記載の方法。
【請求項１５】
前記ターゲットサービスポイントに接続するために、前記ユーザＩＤに対応する前記クライアントをリダイレクトする前記ステップは、
前記サービングサービスポイントによって、前記変更要求に対応する前記ターゲットサービスポイントへの接続を、前記暗号鍵に基づいてリダイレクトするステップと、リダイレクト手続中に、前記暗号鍵が有効であると判断された場合は、サービスポイントの前記変更は成功であると判断するとともに、前記クライアントと前記ターゲットサービスポイントとの接続を確立するステップと、前記暗号鍵が無効であると判断された場合は、サービスポイントの前記変更は失敗であると判断するステップ
を有する、請求項１４に記載の方法。
【請求項１６】
サービスポイントを変更するシステムであって、サービスポイントを有し、前記サービスポイントは、サービングサービスポイントを含み、前記サービングサービスポイントは、
変更要求を取得するとともに、前記変更要求からユーザＩＤを取得するために適用される、変更要求取得モジュールと、
前記変更要求を使用することによって、ターゲットサービングポイントを位置付けるために適用される、サービングポイント位置付けモジュールと、
前記ユーザＩＤに対応するサービングユーザデータを取得するために適用される、サービングユーザデータ取得モジュールと、
前記サービングユーザデータを、ターゲットサービスポイントに送信するとともに、前記ターゲットサービスポイントによって返される変更応答を受信するために適用される、サービングユーザデータ送信モジュールと、
前記ターゲットサービスポイントに接続するために、前記ユーザＩＤに対応するクライアントをリダイレクトするために適用される、接続制御モジュールと
を有する、システム。
【請求項１７】
前記サービングポイント位置付けモジュールはさらに、経路取得要求を、ルーティングポイントに送信するために適用され、
前記ルーティングポイントは、前記経路取得要求を受信した後、前記ターゲットサービスポイントを前記サービングサービスポイントに振り当て、前記ターゲットサービスポイントに対応する経路情報を取得し、前記経路情報を、前記サービングサービスポイントに返すために適用される、
請求項１６に記載のシステム。
【請求項１８】
前記サービスポイント間の接続に関する経路情報を格納するために適用されるルーティングポイントをさらに有し、
前記サービングポイント位置付けモジュールはさらに、前記変更要求から前記ターゲットサービスポイントのＩＤを取得するとともに、前記ターゲットサービスポイントの前記ＩＤを使用することによって、事前に定義されたルーティングポイントから前記ターゲットサービスポイントまでの経路に関する経路情報を取得するために適用される、
請求項１６に記載のシステム。
【請求項１９】
少なくとも１つのプロキシポイントをさらに有し、前記経路情報は、前記少なくとも１つのプロキシポイントの少なくとも１つのＩＤ及び前記少なくとも１つのプロキシポイントのホッピングシーケンスを有し、
前記サービングユーザデータ送信モジュールはさらに、前記経路情報における前記少なくとも１つのプロキシＩＤを使用することによって、前記サービングユーザデータを転送するための前記少なくとも１つのプロキシポイントを決定するとともに、前記経路情報に基づいて、前記サービングユーザデータを前記少なくとも１つのプロキシポイントに送信するために適用され、
前記少なくとも１つのプロキシポイントは、前記経路情報における前記ホッピングシーケンスに基づいて、ホップ・バイ・ホップで、前記サービングユーザデータを前記ターゲットサービスポイントに転送するために適用される、
請求項１８に記載のシステム。
【請求項２０】
前記少なくとも１つのプロキシポイントは、少なくとも１つの階層に属し、
前記少なくとも１つのプロキシポイントは、前記経路情報における前記ホッピングシーケンスに基づいて、ホップ・バイ・ホップで、且つ階層ずつ、前記サービングユーザデータを前記ターゲットサービスポイントに転送するために適用される、
請求項１９に記載のシステム。
【請求項２１】
前記サービングサービスポイントはさらに、前記経路情報に基づいて、前記経路情報において識別された前記少なくとも１つのプロキシポイントの負荷に関する第１情報と前記ターゲットサービスポイントの負荷に関する第２情報とを取得するために適用される、負荷情報取得モジュールを有し、
前記サービングサービスポイントはさらに、前記第１情報及び前記第２情報に基づくブロッキングキューを使用することによって、前記変更要求を処理するために適用される、キュー処理モジュールを有する、
請求項１９に記載のシステム。
【請求項２２】
前記キュー処理モジュールは、前記第１情報及び前記第２情報と事前に定義された重みとを使用することによって、負荷容量を計算するか、前記負荷容量が、閾値よりも大きい場合、前記サービングユーザデータを送信するために、データ送信モジュールを呼び出すか、又は前記負荷容量が、前記閾値よりも大きくない場合、前記変更要求を事前に定義されたブロッキングキューに追加するために適用される、
請求項２１に記載の方法。
【請求項２３】
前記キュー処理モジュールはさらに、間隔を置いて前記ブロッキングキューから変更要求を取得するとともに、前記ターゲットサービスポイントを位置付けるために前記サービングポイント位置付けモジュールを呼び出すために適用される、
請求項２２に記載の方法。
【請求項２４】
前記サービングサービスポイントはまた、サービス要件に基づいて、前記サービングユーザデータをフィルタリングするために適用される、サービングユーザデータフィルタリングモジュールを有する、
請求項１６から２３のいずれか１項に記載のシステム。
【請求項２５】
前記サービスポイントはさらに、ターゲットサービスポイントを有し、前記ターゲットサービスポイントは、ターゲットポイント位置付けモジュールと、ターゲットユーザデータ取得モジュールと、ターゲットユーザデータ送信モジュールとを有し、
前記ターゲットポイント位置付けモジュールは、前記サービングサービスポイントを位置付けるために適用され、
前記ターゲットユーザデータ取得モジュールは、前記ターゲットサービスポイント内に格納された前記ユーザＩＤに対応するターゲットユーザデータを取得するために適用され、
前記ターゲットユーザデータ送信モジュールは、前記ターゲットユーザデータを前記サービングサービスポイントに送信するために適用され、
前記サービングサービスポイントはさらに、前記ターゲットユーザデータを前記サービングユーザデータと統合するために適用される、サービングユーザデータ統合モジュールを有し、
前記サービングユーザデータ送信モジュールはさらに、ポイント返還応答を、前記ターゲットサービスポイントに返すために適用され、
前記接続制御モジュールはさらに、前記クライアントとの接続を回復するために適用される、
請求項１６から２３のいずれか1項に記載のシステム。
【請求項２６】
前記ターゲットユーザデータ送信モジュールはさらに、前記ポイント返還応答を受信するために適用され、
前記ターゲットサービスポイントはさらに、前記ターゲットユーザデータを削除するために適用される、ターゲットユーザデータ削除モジュールを有する、
請求項２５に記載のシステム。
【請求項２７】
前記ターゲットユーザデータ送信モジュールはさらに、変更応答を前記サービングサービスポイントに返すために適用され、
前記ターゲットサービスポイントはさらに、サービス期間を監視するとともに、前記サービス期間がタイムアウト時期に達したという判断に応答して、前記サービングポイント位置付けモジュールを呼び出すために適用される、タイムアウト検出モジュールを有する、
請求項２５に記載のシステム。
【請求項２８】
前記サービングサービスポイントはさらに、サービングデータ送信モジュールが前記変更応答を受信した後に、前記サービングユーザデータをロックするとともに、前記サービングユーザデータ統合モジュールが、前記ターゲットユーザデータを前記サービングユーザデータと統合する前に、前記サービングユーザデータをアンロックするために適用される、データ保護モジュールを有する、
請求項２５に記載のシステム。
【請求項２９】
前記ターゲットサービスポイントはさらに、前記サービングサービスポイント及び前記ユーザＩＤに基づく暗号鍵を生成するために適用される、暗号鍵生成モジュールを有する、
請求項１６から２３のいずれか１項に記載の方法。
【請求項３０】
前記接続制御モジュールはさらに、前記変更要求に対応する前記ターゲットサービスポイントへの接続を、前記暗号鍵に基づいてリダイレクトし、リダイレクト処理中に、前記暗号鍵が有効であると判断された場合は、サービスポイントの前記変更は成功であると判断するとともに、前記クライアントと前記ターゲットサービスポイントとの間の接続を確立し、又は、前記暗号鍵が無効であると判断された場合は、サービスポイントの前記変更は失敗であると判断するために適用される、
請求項２９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、中華人民共和国の特許庁に２０１２年５月３０に出願された、“method and apparatus of changing service points”と題する、中国特許出願番号201210173581.Xの優先権を主張し、その開示が、参照によって組み込まれる。
【０００２】
本開示は、インターネット技術に関するとともに、特に、サービスポイントを変更する方法及びシステムに関する。
【背景技術】
【０００３】
従来のインターネット技術に基づくと、単一のサーバは、限られた計算能力を持つとともに、同時に大量のデータ要求を処理できないため、一般的に、複数のサービスポイント（データ要求を処理するためのサーバポイント）が、負荷分散のために採用される。例えば、複数のサービスポイントは、地理的領域に基づいて配置されてもよく、例えば、サービスポイントは、各省（ｐｒｏｖｉｎｃｅ）内に配置されるとともに、各サービスポイントは、サービスポイントが位置する領域からユーザによって開始されたデータ要求を処理する。
【０００４】
従来のマルチサービスポイント負荷分散スキームでは、ユーザは、それぞれの専用サービスポイントによってサービスされ、ユーザのユーザデータはまた、それぞれのサービスポイント内に格納され、異なるサービスポイントによってサービスされるユーザは、通常、互いに直接通信できない。例えば、オンラインゲームでは、異なるサービスゾーンにおけるゲームのプレイヤーは、同じゲームプロセスで一緒にゲームをすることができない（同じサーバによってサービスされるプレイヤーは、同じゲームプロセスで一緒にゲームをすることができる）。
【０００５】
ユーザデータのクロスサーバ交換を可能にするために、ユーザは、サービングサービスポイントを変更する必要があり得る。従来のメカニズムに基づくと、サービスポイントＡによってサービスされるユーザ１が、サービスポイントＢによってサービスされるユーザ２とデータを交換する必要がある場合、ユーザ１は、サービスポイントの変更を申請するために申請書を記入する必要がある。その後、管理者はユーザ１のサービングサービスポイントを、サービスポイントＡからサービスポイントＢに変更するために設定ファイルを修正するとともに、ユーザ１のユーザデータを、サービスポイントＡからサービスポイントＢに転送する。ユーザ１が、サービスポイントＢを介するユーザ２とのデータ交換を終了した後、ユーザ１は、他の申請書を記入する必要があり、管理者は、ユーザ１のサービングサービスポイントを、サービスポイントＡに戻るように変更するとともに、ユーザ１のユーザデータを、サービスポイントＡに転送するために同じ処理を再び行う。
【０００６】
従って、従来のサービスポイントを変更する方法では、ユーザは、サービスポイントの変更を申請する申請書を記入する必要があるとともに、申請は、管理者によって承認される必要がある。申請書が正しく記入されていると判断した後、管理者は、ユーザのサービングサービスポイントを再設定するために、設定ファイルを手動で修正する。変更プロセスは、リアルタイムで完了されることはできない。
【発明の概要】
【課題を解決するための手段】
【０００７】
本開示の様々な実施例は、サービスポイントを変更する方法を提供し、リアルタイムでサービスポイントを変更する。
【０００８】
サービスポイントを変更する方法に基づくと、
サービングサービスポイントは、変更要求を取得するとともに、変更要求からユーザＩＤを取得し、
サービングサービスポイントは、変更要求を使用することによって、ターゲットサービスポイントを決定し、
サービングサービスポイントは、ユーザＩＤに対応するサービングユーザデータを取得し、サービングユーザデータを、ターゲットサービスポイントに送信し、
サービングサービスポイントは、ターゲットサービスポイントから変更応答を受信し、ターゲットサービスポイントに接続するために、ユーザＩＤに対応するクライアントをリダイレクトする。
【０００９】
例では、サービングサービスポイントは、以下の手順を介して、変更要求を使用することによってターゲットサービスポイントを決定してもよい：
サービングサービスポイントは、変更要求を使用することによって、ターゲットサービスポイントのＩＤを取得し、
サービングサービスポイントは、ターゲットサービスポイントのＩＤを使用することによって、事前に定義されたルーティングポイントからターゲットサービスポイントにアクセスするための経路情報を取得する。
【００１０】
例では、経路情報はプロキシポイントのプロキシＩＤ及びプロキシポイントのホッピングシーケンスを有してもよく、
サービングサービスポイントは、以下の手順を介して、サービングユーザデータを、ターゲットサービスポイントに送信してもよい：
サービングサービスポイントは、経路情報におけるプロキシポイントのＩＤを使用することによって、データを転送するためのプロキシポイントを取得し、
サービングサービスポイントは、経路情報に基づいて、サービングユーザデータをプロキシポイントに送信し、
プロキシポイントは、経路情報におけるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップでサービングユーザデータを、ターゲットサービスポイントに転送する。
【００１１】
例では、プロキシポイントは、少なくとも１つの階層に属してもよく、
プロキシポイントは、以下の手順を介して、経路情報におけるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、サービングユーザデータをターゲットサービスポイントに転送してもよい：
プロキシポイントは、経路情報におけるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、且つ階層ずつ、サービングユーザデータをターゲットサービスポイントに転送する。
【００１２】
例では、サービングユーザデータをターゲットサービスポイントに送信するステップの前に、サービングサービスポイントは、
経路情報を使用することによって、経路情報において識別されたプロキシポイントの負荷に関する第１情報と、ターゲットサービスポイントの負荷に関する第２情報とを取得し、
第１情報及び第２情報に基づくブロッキングキューを使用することによって、変更要求を処理してもよい。
【００１３】
例では、サービングユーザデータをターゲットサービスポイントに送信するステップの前に、サービングサービスポイントは、
サービス要件に基づいて、サービングユーザデータをフィルタリングしてもよい。
【００１４】
例では、ターゲットサービスポイントは、サービングサービスポイントを位置付けてもよく、
ターゲットサービスポイントは、ターゲットサービスポイント内に格納されたユーザＩＤに対応するターゲットユーザデータを取得するとともに、ターゲットユーザデータをサービングサービスポイントに送信してもよく、
サービングサービスポイントは、ターゲットユーザデータを受信し、ターゲットユーザデータをサービングユーザデータと統合し、ポイント返還応答を、ターゲットサービスポイントに返し、クライアントとの接続を回復する。
【００１５】
例では、サービングサービスポイントが、ポイント返還応答をターゲットサービスポイントに返した後、
ターゲットサービスポイントは、ポイント返還応答を受信するとともに、ターゲットユーザデータを削除してもよい。
例では、サービングサービスポイントを位置付けるステップの前に、ターゲットサービスポイントは、
変更応答をサービングサービスポイントに返すとともに、サービング期間を監視し、
サービング期間がタイムアウト時期に達したと判断された後、サービングサービスポイントを位置付ける手順を実行してもよい。
【００１６】
例では、ターゲットサービスポイントによって返された変更応答を受信するステップの後に、サービングサービスポイントは、
サービングユーザデータをロックしてもよいとともに、
ターゲットユーザデータをサービングユーザデータと統合するステップの前に、サービングサービスポイントは、
サービングユーザデータをアンロックしてもよい。
【００１７】
本開示の様々な実施例は、サービスポイントを変更するシステムを提供し、リアルタイムでサービスポイントを変更する。
【００１８】
サービスポイントを変更するシステムは、サービスポイントを有してもよい。サービスポイントは、サービングサービスポイントを有する。サービングサービスポイントは、
変更要求を取得するとともに、変更要求からユーザＩＤを取得するために適用される、変更要求取得モジュールと、
変更要求を使用することによって、ターゲットサービングポイントを位置付けるために適用される、サービングポイント位置付けモジュールと、
ユーザＩＤに対応するサービングユーザデータを取得するために適用される、サービングユーザデータ取得モジュールと、
サービングユーザデータを、ターゲットサービスポイントに送信するとともに、ターゲットサービスポイントによって返される変更応答を受信するために適用される、サービングユーザデータ送信モジュールと、
ターゲットサービスポイントに接続するために、ユーザＩＤに対応するクライアントをリダイレクトするために適用される、接続制御モジュールと
を有してもよい。
【００１９】
例では、システムはまた、ルーティングポイントを有してもよく、サービスポイント間の経路に関する経路情報を格納するために適用される。サービングポイント位置付けモジュールはまた、変更要求からターゲットサービスポイントのＩＤを取得するとともに、ターゲットサービスポイントのＩＤを使用することによって、事前に定義されたルーティングポイントからターゲットサービスポイントまでの経路に関する経路情報を取得するために適用される。
【００２０】
例では、システムはまた、複数のプロキシポイントを有してもよく、経路情報は、プロキシポイントのプロキシＩＤ及びプロキシポイントのホッピングシーケンスを有してもよく、
サービングユーザデータ送信モジュールはまた、経路情報におけるプロキシＩＤを使用することによって、サービングユーザデータを転送するためのプロキシポイントを取得するとともに、経路情報に基づいて、サービングユーザデータをプロキシポイントに送信するために適用され、
プロキシポイントは、経路情報におけるホッピングシーケンスに基づいて、ホップ・バイ・ホップでサービングユーザデータを、ターゲットサービスポイントに転送するために適用される。
【００２１】
例では、プロキシポイントは、少なくとも１つの階層に属してもよく、
プロキシポイントは、経路情報におけるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、且つ階層ずつサービングユーザデータを、ターゲットサービスポイントに転送するために適用される。
【００２２】
例では、サービングサービスポイントはまた、経路情報において識別されたプロキシポイントの負荷に関する第１情報とターゲットサービスポイントの負荷に関する第２情報とを取得するために適用される、負荷取得モジュールを有してもよく、
サービングサービスポイントはまた、第１情報及び第２情報に基づくブロッキングキューを使用することによって、変更要求を処理するために適用される、キュー処理モジュールを有してもよい。
【００２３】
例では、サービングサービスポイントはまた、サービス要件に基づいて、サービングユーザデータをフィルタリングするために適用される、サービングユーザデータフィルタリングモジュールを有してもよい。
【００２４】
例では、サービスポイントはまた、ターゲットサービスポイントを有してもよい。ターゲットサービスポイントは、ターゲットポイント位置付けモジュールと、ターゲットユーザデータ取得モジュールと、ターゲットユーザデータ送信モジュールとを有してもよい。
【００２５】
前記ターゲットポイント位置付けモジュールは、サービングサービスポイントを位置付けるために適用される。
【００２６】
前記ターゲットユーザデータ取得モジュールは、ターゲットサービスポイント内に格納されたユーザＩＤに対応するターゲットユーザデータを取得するために適用される。
【００２７】
前記ターゲットユーザデータ送信モジュールは、ターゲットユーザデータをサービングサービスポイントに送信するために適用される。
【００２８】
前記サービングサービスポイントはまた、ターゲットユーザデータをサービングユーザデータと統合するために適用される、サービングユーザデータ統合モジュールを有してもよい。
【００２９】
前記サービングユーザデータ送信モジュールはまた、ポイント返還応答を、ターゲットサービスポイントに返すために適用される。
【００３０】
前記接続制御モジュールはまた、クライアントとの接続を回復するために適用される。
【００３１】
例では、ターゲットユーザデータ送信モジュールはまた、サービングサービスポイントからポイント返還応答を受信するために適用される。
【００３２】
前記ターゲットサービスポイントはまた、ターゲットユーザデータを削除するために適用される、ターゲットユーザデータ削除モジュールを有してもよい。
【００３３】
例では、ターゲットユーザデータ送信モジュールはまた、変更応答をサービングサービスポイントに返すために適用される。
【００３４】
前記ターゲットサービスポイントはまた、サービス期間を監視するとともに、サービス期間がタイムアウト時期に達したという判断に応答して、サービングポイント位置付けモジュールを呼び出すために適用される、タイムアウト検出モジュールを有してもよい。
【００３５】
態様では、サービングサービスポイントはまた、サービングデータ送信モジュールが変更応答を受信した後に、サービングユーザデータをロックするとともに、サービングユーザデータ統合モジュールが、ターゲットユーザデータをサービングユーザデータと統合する前に、サービングユーザデータをアンロックするために適用される、データ保護モジュールを有してもよい。
【００３６】
サービスポイントを変更する方法及びシステムに基づくと、クライアントから変更要求を受信した後、サービングサービスポイントは、変更要求を使用することによって、リアルタイムでターゲットサービスポイントを位置付けてもよいとともに、ユーザデータをターゲットサービスポイントに送信してもよい。サービングサービスポイントは、ターゲットサービスポイントによって送信された変更応答（変更承認）を受信した後、自動的にクライアントとの接続をターゲットサービスポイントにリダイレクトする。そのように、ユーザの変更要求はリアルタイムで処理されることができるとともに、サービスポイントの変更はリアルタイムで実施されることができる。
【図面の簡単な説明】
【００３７】
【図１】図１は、本開示の実施例に従った、サービスポイントを変更する方法を示すフローチャートである。
【図２】図２は、本開示の実施例に従った、サービスポイントがルーティングポイント、プロキシポイントに接続される、ネットワークトポロジを示す概略図である。
【図３】図３は、本開示の実施例に従った、サービスポイントがプロキシポイントに接続される、ネットワークトポロジを示す概略図である。
【図４】図４は、本開示の実施例に従った、サービスポイントを変更する方法を示すシーケンス図である。
【図５】図５は、本開示の実施例に従った、サービスポイントを変更する方法におけるポイントへの返還のプロセスを示すフローチャートである。
【図６】図６は、本開示の実施例に従った、サービスポイントを変更する方法におけるポイントへの返還のプロセスを示すシーケンス図である。
【図７】図７は、本開示の実施例に従った、サービスポイントを変更する方法におけるポイントへの返還の手順を示すシーケンス図である。
【図８】図８は、本開示の実施例に従った、サービスポイントを変更するシステムを示す概略図である。
【図９】図９は、本開示の実施例に従った、サービスポイントを変更するシステムを示す概略図である。
【発明を実施するための形態】
【００３８】
図１において示されるような実施例では、サービスポイントを変更する方法は、以下の手順を有してもよい。
【００３９】
ブロックＳ１０２では、サービングサービスポイントが、変更要求を取得するとともに、変更要求からユーザＩＤを取得する。
【００４０】
前記サービングサービスポイントは、サービスポイントの変更の前に、クライアントが接続されているサービスポイントを指す。実施例では、ユーザは、サービスポイントの変更を申請するために、クライアントを介して変更要求をサービングサービスポイントに送信してもよい。変更要求は、変更要求を送信するクライアントに対応するユーザＩＤを有してもよい。
【００４１】
例えば、ユーザは、変更要求をクライアントが接続されているサービスポイント（すなわち、サービングサービスポイント）に送信するようにクライアントに命令を入力してもよい。例えば、オンラインゲームでは、ユーザは、変更要求をユーザが接続されているサービスポイント（すなわち、サービングサービスポイント）に送信するように、事前に決定されたＮＰＣ（ｎｏｎ  ｐｌａｙｅｒ  ｃｏｎｔｒｏｌｌｅｄ  ｃｈａｒａｃｔｅｒ）に話しかけてもよい。
【００４２】
他の実施例では、変更要求は、制御ポイントによって送信されてもよい。制御ポイントは、サービスポイントの処理を制御するための事前に定義されたデバイスであってもよいとともに、サービス要件に基づいて、ユーザＩＤに対応するクライアントがサービスポイントを変更するように強制してもよい。
【００４３】
ブロックＳ１０４では、サービングサービスポイントが、変更要求を使用することによって、ターゲットサービスポイントを位置付ける。
【００４４】
前記ターゲットサービスポイントは、サービスポイントの変更の後、クライアントが接続されるべきサービスポイントを指す。実施例では、変更要求はまた、ターゲットサービスポイントのＩＤを有してもよい。
【００４５】
実施例では、変更要求を使用することによって、サービングサービスポイントがターゲットサービスポイントを位置付ける手順は、
サービングサービスポイントは、変更要求からターゲットサービスポイントのＩＤを取得し、サービングサービスポイントは、ターゲットサービスポイントのＩＤを使用することによって、事前に定義されたルーティングポイントからターゲットサービスポイントまでの経路に関する経路情報を取得することを有してもよい。
【００４６】
図２に示されるように、ルーティングポイントは事前に定義されたポイントであり、サービスポイントに接続され、ポイント間の接続に関する経路情報を格納するために適用される。サービングサービスポイントは、経路情報を使用することによって、ターゲットサービスポイントを位置付けてもよい。
【００４７】
実施例では、サービスポイントは、ルーティングポイントに接続され続けるために、間隔を置いてハートビートメッセージを送信してもよい。
【００４８】
実施例では、ターゲットサービスポイントＩＤを使用することによって、サービングサービスポイントが、ルーティングポイントからターゲットサービスポイントへのルーティングのために、経路情報を取得する手順は、
サービングサービスポイントは、ローカルマシン内で、ターゲットサービスポイントＩＤに対応する経路情報を検索し、経路情報がローカルマシン内で見つからなかった場合、ターゲットサービスポイントＩＤを使用することによって、事前に定義されたルーティングポイントから経路情報を取得することを有してもよい。
【００４９】
実施例では、サービングサービスポイントは、ターゲットサービスポイントＩＤを使用することによって、事前に定義されたルーティングポイントからターゲットサービスポイントへの経路に関する経路情報を取得した後、経路情報をキャッシュするとともにローカルマシン内に経路情報をキャッシュしてもよい。
【００５０】
実施例では、変更要求を使用することによって、サービングサービスポイントがターゲットサービスポイントを位置付ける手順は、サービングサービスポイントは、経路取得要求をルーティングポイントに送信し、経路取得要求を受信した後、ルーティングポイントは、ターゲットサービスポイントをサービングサービスポイントに振り当て、振り当てられたターゲットサービスポイントに対応する経路情報を取得し、経路情報をサービングサービスポイントに送信することを有してもよい。
【００５１】
実施例では、ルーティングポイントは、ルーティングポイントに接続されたサービスポイントの負荷情報を格納してもよい。経路取得要求がターゲットサービスポイントＩＤを識別しない場合、ルーティングポイントは、負荷情報に基づいて、ターゲットサービスポイントとして、最小の負荷を有するサービスポイント（すなわち、最も使用されていないサービスポイント）をサービングサービスポイントに振り当ててもよい。実施例では、ルーティングポイントは、ターゲットサービスポイントをサービングサービスポイントにランダムに振り当ててもよい。
【００５２】
実施例では、ルーティングポイントは、メイン／バックアップモードで配置されてもよい。図２に示されるように、メインルーティングポイント及びバックアップルーティングポイントは同一の経路情報を格納する。メインルーティングポイントは、データをバックアップルーティングポイントと定期的に同期させてもよい。サービングサービスポイントがメイン経路情報から経路情報を取得することを失敗した場合、サービングサービスポイントは、バックアップルーティングポイントからターゲットサービスポイントへの経路に関する経路情報を取得してもよい。
【００５３】
１つのルーティングポイントの障害がある場合、サービングサービスポイントが依然として経路情報を取得できるように、ルーティングポイントは、メイン／バックアップモードで確立されてもよい。従って、データ損失が防止されるとともに、データのセキュリティが改善される。
【００５４】
ブロックＳ１０６では、サービングサービスポイントが、ユーザＩＤに対応するサービングユーザデータを取得し、サービングユーザデータをターゲットサービスポイントに送信する。
【００５５】
前記クライアントがサービスポイントに接続された後、サービスポイントは、クライアントによって送信されるデータ要求を処理し、処理結果に基づいてユーザデータを生成及び格納してもよい。サービングユーザデータは、サービングサービスポイント内に格納されたユーザデータを指す。ユーザデータは、サービングポイント内のディスク又はデータベース内に格納されるとともに、ユーザＩＤに関連付けられてもよい。
【００５６】
実施例では、サービングサービスポイントは、サービングユーザデータをターゲットサービスポイントに送信する前に、サービス要件に基づいて、サービングユーザデータをフィルタリングしてもよい。
【００５７】
前記サービス要件は、クライアントとターゲットサービスポイントとの間のデータ交換において必要とされるサービングユーザデータを識別してもよい。サービングサービスポイントは、サービス要件に基づいてサービングユーザデータをフィルタリングするとともに、クライアントとターゲットサービスポイントとの間のデータ交換において必要とされるフィルタリングから取得されるサービングユーザデータの一部を、ターゲットサービスポイントに送信する。そのように、転送されるデータ量は、大幅に低減されることができ、データの冗長性が低減され、帯域幅の利用率は向上することができる。
【００５８】
実施例では、経路情報は、プロキシポイントのプロキシＩＤ及びプロキシポイントのホッピングシーケンスを有してもよい。
【００５９】
前記サービングサービスポイントがサービングユーザデータをターゲットサービスポイントに送信する手順は、
サービングサービスポイントは、経路情報におけるプロキシＩＤを使用することによってデータを転送するためのプロキシポイントを取得するとともに、経路情報に基づいて、サービングユーザデータをプロキシポイントに送信することを有してもよい。
【００６０】
前記プロキシポイントは、経路情報において識別されるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、サービングユーザデータをターゲットサービスポイントに転送する。
【００６１】
実施例では、プロキシポイントは、少なくとも１つの階層に属してもよい。プロキシポイントが、経路情報において識別されるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、サービングユーザデータをターゲットサービスポイントに転送する手順は、
プロキシポイントは、経路情報におけるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、且つ階層ずつサービングユーザデータをターゲットサービスポイントに転送することを有してもよい。
【００６２】
図２に示されるように、サービスポイントは複数のグループに分割されるとともに、各グループにおけるサービスポイントは、プロキシポイントと接続される。実施例では、図３に示されるように、プロキシポイントは、少なくとも１つの階層、すなわち、レベル１のプロキシポイント、レベル２のプロキシポイント、・・・、レベルＮのプロキシポイントに属してもよい。同じレベルのプロキシポイントはまた、複数のグループに分割されてもよく、１つのグループにおけるプロキシポイントは、マルチレイヤのピラミッド型の構造を形成するために、上位レベルからプロキシポイントに接続されてもよい。最下位レベルの各プロキシポイントは、サービスポイントの各グループに接続される。
【００６３】
実施例では、サービングサービスポイントは、データパケットでサービングユーザデータを送信してもよい。サービングサービスポイントは、経路情報を使用することによって、サービングユーザデータに対するデータパケットのヘッダを生成してもよい。表１に示されるように、データパケットのヘッダは、バージョン情報、総ホップ数、現在のホップ数、サービングサービスポイントのＩＤ、プロキシポイントのＩＤ，プロキシポイントのホッピングシーケンスを有してもよい。
【００６４】
【表１】
2015519844.tif 000003
【００６５】
ポイントＩＤは、プロキシポイントのＩＤ又はサービスポイントのＩＤであってもよい。プロキシポイントのホッピングシーケンスは、特定の順序で配列されたポイントＩＤの形態であってもよい。
【００６６】
表１は、単に、パケットヘッダにおける経路情報の例であり、データパケットのペイロードは、表１と同一の又は類似の表を必ずしも有する必要はない。
【００６７】
実施例では、プロキシポイントが、経路情報におけるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップでサービングユーザデータをターゲットサービスポイントに転送する手順は、
プロキシポイントは、サービングサービスポイントによって送信されるサービングユーザデータを有するデータパケットを受信し、データパケットのヘッダを解析し、現在のホップ数に基づいて、次のホップのポイントのＩＤ（プロキシポイントのＩＤ又はターゲットサービスポイントのＩＤであってもよい）を取得し、次のホップのポイント（プロキシポイント又はターゲットサービスポイントであってもよい）にパケットを送信し、プロキシポイントは、パケットがターゲットサービスポイントに送信されるまで、プロセスを繰り返すことを有してもよい。
【００６８】
事前に設定するプロキシポイントによって、サービスポイントは、網目状ネットワークを形成するために互いに接続される必要はない。実施例では、プロキシポイントは、プロキシポイントが網目状ネットワークを形成することを防ぐために、複数の階層に分割されてもよい。サービスポイントが追加される場合、サービスポイントは、各プロキシポイントとの接続を確立する代わりに、プロキシポイントの１つとの接続を確立するだけでよい。従って、ネットワーク容量は、容易に増加されることができる。
【００６９】
事前に設定するプロキシポイントは、複数のサブネットワークを有するとともにＮＡＴを必要とするネットワークにおけるデータ転送を容易にすることができる。例えば、複数のサブネットワークは、地理的領域に基づいて事前に設定されてもよい。各サブネットワークは、地理的領域にサービスを提供するサービスポイントを有してもよい。サブネットワークのゲートウェイは、プロキシポイントとして機能してもよい。サービスポイントが、他の地理的領域におけるサブネットワーク内のサービスポイントにデータを転送する場合、データは、サービスポイントが互いに直接接続されている場合に必要であるＮＡＴを避けるために、プロキシポイントによって、階層ずつ転送されてもよい。
【００７０】
図２において示されるような実施例では、プロキシポイントは、メイン／バックアップモードで構成されてもよい。メインプロキシポイント内で障害が発生した場合、データは、バックアッププロキシポイントによって転送されてもよい。
【００７１】
メイン／バックアップモードでプロキシポイントを構成することによって、メインプロキシポイントに障害が発生した場合に、データは依然として、バックアッププロキシポイントによって転送されることができる。従って、システムが、１つのポイントにおける障害が原因となって麻痺になることを防止するとともに、データのセキュリティを改善する。
【００７２】
実施例では、ポイントＩＤは、ポイントのＩＰアドレスであってもよい。サービングサービスポイントは、ＩＰアドレスに基づいて、データパケットをターゲットサービスポイント又はプロキシポイントに送信してもよい。実施例では、プロキシポイントは、ルーティングポイント内で、ポイントＩＤに対応するＩＰアドレスを検索するとともに、ＩＰアドレスを使用することによって、データパケットをポイントに送信してもよい。
【００７３】
実施例では、サービングユーザデータをターゲットサービスポイントに送信する前に、サービングサービスポイントは、経路情報に対応するプロキシポイントの負荷情報及びターゲットサービスポイントの負荷情報を取得してもよい。サービングサービスポイントは、負荷情報に基づくブロッキングキューを使用することによって、変更要求を処理してもよい。
【００７４】
前記サービングユーザデータを転送する予定のプロキシポイントは、経路情報を使用することによって決定されてもよい。プロキシポイントの負荷情報は、プロキシポイントの帯域幅の利用率、計算能力、キャッシュサイズを有してもよい。ターゲットサービスポイントの負荷情報は、ターゲットサービスポイントの帯域幅の利用率、計算能力、キャッシュサイズを有してもよい。プロキシポイント及びターゲットサービスポイントの負荷情報は、ルーティングポイント内に格納されてもよいとともに、間隔を置いてアップデートされてもよい。サービングサービスポイントは、ルーティングポイントから負荷情報を取得してもよい。
【００７５】
前記サービングサービスポイントが負荷情報に基づくブロッキングキューを使用することによって、変更要求を処理するプロセスは、負荷情報及び事前に定義された重みを使用することによって、負荷容量を計算するか、負荷容量が、閾値よりも大きい場合、サービングユーザデータを、ターゲットサービスポイントに送信するステップを実行するか、又は負荷容量が、閾値よりも大きくない場合、変更要求を事前に定義されたブロッキングキューに追加することを有してもよい。サービングサービスポイントが負荷情報に基づくブロッキングキューを使用することによって、変更要求を処理するステップはまた、サービングサービスポイントは、間隔を置いてブロッキングキューから変更要求を取得するとともに、変更要求を使用することによって、ターゲットサービスポイントを位置付けるステップを実行することを有してもよい。
【００７６】
大量の同時の変更要求が取得される場合、変更要求のわずかな部分のみ、同時に処理される。それらの受信されたが処理されない変更要求は、変更要求が受信された順に、事前に定義されたブロッキングキュー内に格納される。プロキシポイント及びターゲットサービスポイントがあまりビジーでない場合、ブロッキングキュー内の変更要求は、非常に同時の変更要求の場合に、システムが、オーバーロードなサービスポイント及びプロキシポイントによって麻痺されることを回避するために、順番に処理され、従って、システムはより安定であることができる。
【００７７】
実施例では、サービングサービスポイントは、ブロッキングキューにおける変更要求の位置のシーケンス番号を、クライアントに送信してもよい。クライアントは、シーケンス番号を表示してもよい。シーケンス番号は、変更要求が処理される前の待機時間を推定するためにユーザによって使用されてもよく、ユーザがプロセスを制御することを容易にする。
【００７８】
実施例では、サービングユーザデータはユーザＩＤを有してもよい。プロセスはまた、サービングユーザデータを受信した後、ターゲットサービスポイントは、受信されたサービングユーザデータを検証し、サービングユーザデータ及び対応するユーザＩＤを格納し、変更応答をサービングサービスポイントに返すことを有してもよい。
【００７９】
ブロックＳ１０８では、サービングサービスポイントが、ターゲットサービスポイントから変更応答を受信し、ターゲットサービスポイントに接続するために、ユーザＩＤに対応するクライアントをリダイレクトする。
【００８０】
前記ターゲットサービスポイントから変更応答を受信した後、サービングサービスポイントは、ターゲットサービスポイントのＩＰアドレス及びポートを取得し、ユーザＩＤに対応するクライアント、すなわち、変更要求に対応するクライアントに送信してもよい。クライアントは、変更要求を送信するクライアント又は、変更要求内のユーザＩＤによって識別されるクライアントであってもよい。クライアントは、ＩＰアドレス及びポートを使用することによって、ターゲットサービスポイントとの接続を確立してもよい。
【００８１】
実施例では、変更応答はまた、暗号鍵を有してもよい。変更応答をサービングサービスポイントに送信する前に、ターゲットサービスポイントは、サービングサービスポイント及びユーザＩＤに基づいて、暗号鍵を生成してもよい。
【００８２】
前記サービングサービスポイントが、ターゲットサービスポイントに接続するために、クライアントをリダイレクトする手順は、サービングサービスポイントは、暗号鍵を使用することによって、変更要求に対応する接続をターゲットサービスポイントにリダイレクトしてもよいことを有してもよい。リダイレクト手続中に、暗号鍵が有効であると判断された場合は、サービスポイントの変更は成功であるとともに、クライアントとターゲットサービスポイントとの間で接続が確立される。暗号鍵が無効であると判断された場合は、サービスポイントの変更は失敗である。ターゲットサービスポイントは、サービングユーザデータを削除してもよい。
【００８３】
図３において示されるような実施例では、サービスポイントａ１は、サービングサービスポイントであるとともに、サービスポイントａ２は、ターゲットサービスポイントである。サービスポイントａ１及びａ２は、共にプロキシポイントＡ１に接続されている。図４は、ユーザがクライアントを介して、変更要求をサービスポイントａ１に送信した後、ａ１からａ２に、サービスポイントを変更するプロセスを示すシーケンス図である。
【００８４】
図３において示されるような実施例では、サービスポイントａ１がサービングサービスポイントであるとともに、サービスポイントａ２がターゲットサービスポイントである場合、サービングユーザデータは、ａ１からｂ１にサービスポイントを変更するプロセス中、プロキシポイントＡ１、プロキシポイントＡ，プロキシポイントＢ、プロキシポイントＢ３を順番に介して、サービスポイントｂ１に転送されてもよい。
【００８５】
図５において示されるような実施例では、サービスポイントを変更する方法はまた、以下の手順を有してもよい。
【００８６】
ブロックＳ２０２では、ターゲットサービスポイントが、サービングサービスポイントを位置付ける。
【００８７】
前記ターゲットサービスポイントがサービングサービスポイントを位置付ける方法は、サービングサービスポイントがターゲットサービスポイントを位置付ける方法と同様であってもよく、従って、さらにここで説明はされない。
【００８８】
ブロックＳ２０４では、ターゲットサービスポイントが、ターゲットサービスポイント内に格納されたユーザＩＤに対応するターゲットユーザデータを取得し、ターゲットユーザデータをサービングサービスポイントに送信してもよい。
【００８９】
前記ターゲットユーザデータは、ターゲットサービスポイント内に格納されたユーザデータを指してもよく、すなわち、サービスポイントの変更の後、ターゲットサービスポイントがクライアントによって送信されたデータ要求を処理するときに生成される新しいデータを指す。ターゲットサービスポイントが、ターゲットユーザデータをサービングサービスポイントに送信する方法は、サービングサービスポイントが、サービングユーザデータをターゲットサービスポイントに送信する方法と同様であってもよく、従って、ここでさらに説明はされない。
【００９０】
ブロックＳ２０６では、サービングサービスポイントが、ターゲットユーザデータを受信し、ターゲットユーザデータをサービングユーザデータと統合し、ポイント返還応答を、ターゲットサービスポイントに返し、クライアントとの接続を回復する。
【００９１】
前記サービングサービスポイントが、ターゲットユーザデータをサービングユーザデータと統合する手順は、サービングサービスポイントが、ターゲットユーザデータを使用することによって、サービングユーザデータをアップデートすることを有してもよい。
【００９２】
実施例では、サービングサービスポイントは、クライアントとの接続を回復するために、リダイレクトを停止するとともに、接続回復要求を送信してもよい。実施例では、ターゲットサービスポイントは、クライアントとの接続をサービングサービスポイントにリダイレクトしてもよいとともに、サービングサービスポイントは、クライアントとの接続を受動的に回復してもよい。
【００９３】
実施例では、サービングサービスポイントを位置付ける前に、ターゲットサービスポイントはまた、ポイント返還要求を取得し、その後サービングサービスポイントを位置付けるステップを実行してもよい。
【００９４】
実施例では、ポイント返還要求は、クライアントによって開始されてもよい。サービスポイントの変更の後、ユーザがターゲットサービスポイントとのデータインタラクション（ｄａｔａ  ｉｎｔｅｒａｃｔｉｏｎ）を終了する場合、ユーザは、クライアントを介してポイント返還要求を開始してもよい。例えば、オンラインゲームでは、ユーザは、サービングサービスポイントへの返還を要求するために、ＮＰＣに話しかけることによって、ポイント返還要求を開始してもよい。ポイント返還要求を受信した後、ターゲットサービスポイントは、ユーザＩＤに対応するクライアントがサービングサービスポイントに戻るように、サービングサービスポイントを位置付けるステップを実行してもよい。
【００９５】
他の実施例では、変更要求は、制御ポイントによって送信されてもよい。サービングサービスポイントは、ユーザＩＤに対応するクライアントが、サービス要件に基づいて、サービングサービスポイントに戻るように強制してもよい。
【００９６】
他の実施例では、サービングサービスポイントを位置付ける前に、ターゲットサービスポイントは、
変更応答をサービングサービスポイントに返し、サービス期間を監視し、サービス期間がタイムアウト時期に達したと検出した場合、サービングサービスポイントを位置付けるステップを実行してもよい。
【００９７】
前記サービス期間は、クライアントがターゲットサービスポイントに接続された後、ターゲットサービスデータが、クライアントからのデータ要求を処理してきた時間の長さを指す。ターゲットサービスポイントは、変更応答を送信した後、時間のカウントを開始するとともに、サービス期間がタイムアウト時期に達したと検出するとき（例えば、事前に定義された時間の長さよりも長いか、又は等しいとき）、クライアントをサービングサービスポイントに返すために、サービングサービスポイントを位置付けるステップを実行してもよい。
【００９８】
前記サービングサービスポイントが、ターゲットサービスポイントにポイント返還応答を送信した後、ターゲットサービスポイントは、ポイント返還応答を受信するとともにターゲットユーザデータを削除してもよい。
【００９９】
前記クライアントは、サービングサービスポイントからターゲットサービスポイントにサービスポイントを変更するとともに、一時的なデータインタラクションの後、ターゲットサービスポイントからサービングサービスポイントに戻り、一時的なデータインタラクションの間に生成されたターゲットユーザデータは一時的なユーザデータである。ターゲットユーザデータは、サービングサービスデータによってサービングユーザデータと統合された後、格納されるだけであり、バックアップされる必要はない。従って、ターゲットユーザデータを削除することは、サービスポイント内の記憶容量を節約することができるとともに、データの冗長性を低減することができる。
【０１００】
図３において示されるような実施例では、サービスポイントａ１は、サービングサービスポイントであるとともに、サービスポイントａ２は、ターゲットサービスポイントである。サービスポイントａ１及びａ２は、共にプロキシポイントＡ１に接続されている。本実施例では、ユーザはサービスポイントをａ１からａ２に変更した。
【０１０１】
図６は、ユーザがクライアントを介して、サービスポイントａ２にポイント返還要求を送信した後、サービスポイントをａ２からａ１に変更するプロセスを示すシーケンス図である。
【０１０２】
他の実施例では、図７は、サービスポイントａ２が、サービス期間がタイムアウト時期に達したと検出した後、サービスポイントをａ２からａ１に変更するプロセスを示すシーケンス図である。
【０１０３】
実施例では、ターゲットサービスポイントによって返された変更応答を受信した後、サービングサービスポイントは、サービングサービスポイントをロックしてもよい。
【０１０４】
前記ターゲットユーザデータをサービングユーザデータと統合する前に、サービングサービスポイントは、サービングユーザデータをアンロックしてもよい。
【０１０５】
実施例では、フラグが、サービングユーザデータのロック及びアンロックを示すために追加されてもよい。フラグが「ロックされている」と示す場合、プロセス又はスレッドによって開始されたサービングユーザデータを書き込む処理は拒否されてもよく、フラグが「アンロックされている」と示す場合、プロセス又はスレッドは、サービングユーザデータに対して書き込み処理を実行するためにウェイクアップされてもよい。
【０１０６】
図８において示されるような実施例では、サービスポイントを変更するシステムは、サービスポイントを有してもよい。サービスポイントは、サービングサービスポイント１０を有してもよい。サービングサービスポイント１０は、変更要求取得モジュール１０２と、サービングポイント位置付けモジュール１０４と、サービングユーザデータ取得モジュール１０６と、サービングユーザデータ送信モジュール１０８と、接続制御モジュール１１０とを有してもよい。
【０１０７】
前記変更要求取得モジュール１０２は、変更要求を取得するとともに、変更要求からユーザＩＤを取得する。
【０１０８】
前記サービングサービスポイントは、サービスポイントの変更の前に、クライアントが接続されているサービスポイントを指す。実施例では、ユーザは、サービスポイントの変更を申請するために、クライアントを介して変更要求をサービングサービスポイントに送信してもよい。変更要求は、変更要求を送信するクライアントに対応するユーザＩＤを有してもよい。
【０１０９】
例えば、ユーザは、変更要求をクライアントが接続されているサービスポイント（すなわち、サービングサービスポイント）に送信するようにクライアントに命令を入力してもよい。例えば、オンラインゲームでは、ユーザは、変更要求を開始するために特定のＮＰＣに話しかけてもよい。
【０１１０】
他の実施例では、変更要求は、制御ポイントによって送信されてもよい。制御ポイントは、サービスポイントの処理を制御するための事前に定義されたデバイスであってもよいとともに、サービス要件に基づいて、ユーザＩＤに対応するクライアントがサービスポイントを変更するように強制してもよい。
【０１１１】
前記サービングポイント位置付けモジュール１０４は、変更要求を使用することによってターゲットサービングポイントを位置付けるために適用されてもよい。
【０１１２】
前記ターゲットサービスポイントは、サービスポイントの変更の後、クライアントが接続されるべきサービスポイントを指す。実施例では、変更要求はまた、ターゲットサービスポイントのＩＤを有してもよい。
【０１１３】
図９において示されるような実施例では、システムはまた、サービスポイント間の接続に関する経路情報を格納するために適用されるルーティングポイント２０を有してもよい。サービングポイント位置付けモジュール１０４は、変更要求からターゲットサービスポイントのＩＤを取得してもよいとともに、ターゲットサービスポイントのＩＤを使用することによって、事前に定義されたルーティングポイントからターゲットサービスポイントへの経路に関する経路情報を取得してもよい。
【０１１４】
図２に示されるように、ルーティングポイントは事前に定義されたポイントであり、サービスポイントに接続され、ポイント間の接続に関する経路情報を格納するために適用される。サービングポイント位置付けモジュール１０４は、変更要求を使用することによって、ターゲットサービングポイントを位置付けるために適用される。
【０１１５】
実施例では、サービングサービスポイント１０はまた、ルーティングポイントに接続され続けるために、間隔を置いてハートビートメッセージを送信するために適用される、接続維持モジュール（図中に示されず）を有してもよい。
【０１１６】
実施例では、サービングポイント位置付けモジュール１０４は、ローカルマシン内で、ターゲットサービスポイントのＩＤに対応する経路情報を検索し、経路情報がローカルマシン内で見つからなかった場合、ターゲットサービスポイントのＩＤを使用することによって、事前に定義されたルーティングポイントから経路情報を取得してもよい。
【０１１７】
実施例では、サービングポイント位置付けモジュール１０４は、ターゲットサービスポイントのＩＤを使用することによって、ルーティングポイントから経路情報を取得した後、ターゲットサービスポイントのＩＤをキャッシュするとともにローカルマシン内に対応する経路情報をキャッシュしてもよい。
【０１１８】
他の実施例では、サービングポイント位置付けモジュール１０４は、ルーティングポイントに経路取得要求を送信してもよい。ルーティングポイント２０は、経路取得要求を受信した後、ターゲットサービスポイントをサービングサービスポイント１０に振り当て、ターゲットサービスポイントに対応する経路情報を取得し、経路情報をサービングサービスポイント１０に返してもよい。
【０１１９】
実施例では、ルーティングポイント２０は、ルーティングポイントに接続されたサービスポイントの負荷情報を格納してもよい。経路取得要求がターゲットサービスポイントのＩＤを識別しない場合、ルーティングポイント２０は、負荷情報に基づいて、ターゲットサービスポイントとして最小の負荷を有するサービスポイント（すなわち、最も使用されていないサービスポイント）を、サービングサービスポイント１０に振り当ててもよい。他の実施例では、ルーティングポイントは、ターゲットサービスポイントをサービングサービスポイントにランダムに振り当ててもよい。
【０１２０】
実施例では、ルーティングポイント２０は、メイン／バックアップモードで配置されてもよい。図２に示されるように、メインルーティングポイント及びバックアップルーティングポイントは同一の経路情報を格納してもよい。メインルーティングポイントは、データをバックアップルーティングポイントと定期的に同期させてもよい。サービングサービスポイントがメイン経路情報から経路情報を取得することを失敗した場合、サービングサービスポイント１０は、バックアップルーティングポイントからターゲットサービスポイントへの経路に関する経路情報を取得してもよい。
【０１２１】
１つのルーティングポイントの障害がある場合、サービングサービスポイントが依然として経路情報を取得できるように、ルーティングポイントは、メイン／バックアップモードで確立されてもよい。従って、データ損失が防止されるとともに、データのセキュリティが改善される。
【０１２２】
前記サービングユーザデータ取得モジュール１０６は、ユーザＩＤに対応するサービングユーザデータを取得してもよい。
【０１２３】
前記ユーザがクライアントを介してサービスポイントに接続された後、サービスポイントは、クライアントによって送信されるデータ要求を処理し、処理結果に基づいてユーザデータを生成及び格納してもよい。サービングユーザデータは、サービングサービスポイント１０内に格納されたユーザデータを指す。ユーザデータは、サービングポイント内のディスク又はデータベース内に格納されるとともに、ユーザＩＤに関連付けられてもよい。
【０１２４】
図９において示されるような実施例では、サービングサービスポイント１０はまた、サービス要件に基づいて、サービングユーザデータをフィルタリングするために適用される、サービングユーザデータフィルタリングモジュール１１２を有してもよい。
【０１２５】
前記サービス要件は、クライアントとターゲットサービスデータとの間のデータインタラクションにおいて必要とされるサービングユーザデータの一部を識別してもよい。サービングユーザデータフィルタリングモジュール１１２は、転送された不適切なデータ量を低減するために、サービス要件に基づいてサービングユーザデータをフィルタリングしてもよい。そのように、データの冗長性が低減され、帯域幅の利用率は向上する。
【０１２６】
前記サービングユーザデータ送信モジュール１０８は、サービングユーザデータをターゲットサービスポイントに送信し、ターゲットサービスポイントによって返される変更応答を受信してもよい。
【０１２７】
図９において示されるような実施例では、システムはまた、少なくとも１つのプロキシポイント３０を有してもよい。経路情報は、プロキシポイント３０のＩＤ及びプロキシポイント３０のホッピングシーケンスを有してもよい。
【０１２８】
前記サービングユーザデータ送信モジュール１０８は、経路情報におけるプロキシＩＤを使用することによってデータを転送するためのプロキシポイントを取得するとともに、経路情報に基づいて、サービングユーザデータをプロキシポイントに送信してもよい。
【０１２９】
前記プロキシポイント３０は、経路情報において識別されるプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、サービングユーザデータをターゲットサービスポイントに転送してもよい。
【０１３０】
実施例では、プロキシポイント３０は、少なくとも１つの階層に属してもよい。プロキシポイント３０は、経路情報において識別されたプロキシポイントのホッピングシーケンスに基づいて、ホップ・バイ・ホップで、且つ階層ずつサービングユーザデータをターゲットサービスポイントに転送してもよい。
【０１３１】
図２に示されるように、サービスポイントは複数のグループに分割されるとともに、各グループにおけるサービスポイントは、プロキシポイントと接続されてもよい。図３において示されるような実施例では、プロキシポイントは、少なくとも１つの階層、すなわち、レベル１のプロキシポイント、レベル２のプロキシポイント、・・・、レベルＮのプロキシポイントに属してもよい。同じレベルのプロキシポイントはまた、複数のグループに分割されてもよく、１つのグループにおけるプロキシポイントは、マルチレイヤのピラミッド型の構造を形成するために、上位レベルからプロキシポイントに接続されてもよい。最下位レベルの各プロキシポイントは、サービスポイントの各グループに接続される。
【０１３２】
実施例では、サービングユーザデータ送信モジュール１０８は、データパケットでサービングユーザデータを送信してもよい。サービングサービスポイントは、経路情報を使用することによって、サービングユーザデータに対するデータパケットのヘッダを生成してもよい。表２に示されるように、データパケットのヘッダは、バージョン情報、総ホップ数、現在のホップ数、サービングサービスポイントのＩＤ、プロキシポイントのＩＤ，プロキシポイントのホッピングシーケンスを有してもよい。
【０１３３】
【表２】
2015519844.tif 000004
【０１３４】
ポイントＩＤは、プロキシポイントのＩＤ又はサービスポイントのＩＤであってもよい。プロキシポイントのホッピングシーケンスは、特定の順序で配列されたポイントＩＤの形態であってもよい。
【０１３５】
表１は、単に、パケットヘッダにおける経路情報の例であり、データパケットのペイロードは、表１と同一の又は類似の表を必ずしも有しなくてもよい。
プロキシポイントは、サービングサービスポイントによって送信されるサービングユーザデータを有するデータパケットを受信し、データパケットのヘッダを解析し、現在のホップ数に基づいて、次のホップのポイントのＩＤ（プロキシポイントのＩＤ又はターゲットサービスポイントのＩＤであってもよい）を取得し、次のホップのポイント（プロキシポイント又はターゲットサービスポイントであってもよい）にパケットを送信する。プロキシポイントは、パケットがターゲットサービスポイントに送信されるまで、プロセスを繰り返す。
【０１３６】
事前に設定するプロキシポイントによって、サービスポイントは、網目状ネットワークを形成するために互いに接続される必要はない。実施例では、プロキシポイントは、プロキシポイントが網目状ネットワークを形成することを防ぐために、複数の階層に分割されてもよい。サービスポイントが追加される場合、サービスポイントは、各プロキシポイントとの接続を確立する代わりに、プロキシポイントの１つとの接続を確立するだけでよい。従って、ネットワーク容量は、容易に増加されることができる。
【０１３７】
事前に設定するプロキシポイントは、複数のサブネットワークを有するとともにＮＡＴを必要とするネットワークにおけるデータ転送を容易にする。例えば、複数のサブネットワークは、地理的領域に基づいて事前に設定されてもよい。各サブネットワークは、地理的領域にサービスを提供するサービスポイントを有してもよい。サブネットワークのゲートウェイは、プロキシポイントとして機能してもよい。サービスポイントが、他の地理的領域におけるサブネットワーク内のサービスポイントにデータを転送する場合、データは、サービスポイントが互いに直接接続されている場合に必要であるＮＡＴを避けるために、プロキシポイントによって、階層ずつ転送されてもよい。
【０１３８】
図２において示されるような実施例では、プロキシポイント３０は、メイン／バックアップモードで構成されてもよい。メインプロキシポイント内で障害が発生した場合、データは、バックアッププロキシポイントによって転送されてもよい。
【０１３９】
メイン／バックアップモードでプロキシポイントを構成することによって、メインプロキシポイントに障害が発生した場合に、データは依然として、バックアッププロキシポイントによって転送されることができる。従って、システムが、１つのポイントにおける障害が原因となって麻痺になることを防止するとともに、データのセキュリティを改善する。
【０１４０】
実施例では、ポイントＩＤは、ポイントのＩＰアドレスであってもよいとともに、ＩＰアドレスを使用することによって、データパケットを送信してもよい。他の実施例では、プロキシポイント３０は、ルーティングポイント２０内で、ポイントＩＤに対応するＩＰアドレスを検索するとともに、ＩＰアドレスを使用することによって、データパケットをポイントに送信してもよい。
【０１４１】
図９において示されるような実施例では、サービングサービスポイント１０はまた、経路情報において識別されるプロキシポイントの負荷に関する第１情報及びターゲットサービスポイントの負荷に関する第２情報を取得するために適用される、負荷取得モジュール１１４を有してもよい。
【０１４２】
図９に示されるように、サービングサービスポイント１０はまた、負荷情報に基づくブロッキングキューを使用することによって変更要求を処理するために適用される、キュー処理モジュール１１６を有してもよい。
【０１４３】
前記負荷取得モジュール１１４は、サービングユーザデータを転送する予定のプロキシポイントを、経路情報を使用することによって決定してもよい。プロキシポイントの負荷情報は、プロキシポイントの帯域幅の利用率、計算能力、キャッシュサイズを有してもよい。ターゲットサービスポイントの負荷情報は、ターゲットサービスポイントの帯域幅の利用率、計算能力、キャッシュサイズを有してもよい。プロキシポイント３０及びターゲットサービスポイントの負荷情報は、ルーティングポイント２０内に格納されてもよいとともに、間隔を置いてアップデートされてもよい。負荷取得モジュール１１４は、ルーティングポイントから負荷情報を取得してもよい。
【０１４４】
前記キュー処理モジュール１１６は、負荷情報及び事前に定義された重みを使用することによって、負荷容量を計算してもよい。負荷容量が、閾値よりも大きい場合、データ送信モジュール１０８が、サービングユーザデータを送信するために呼び出される。負荷容量が、閾値よりも大きくない場合、変更要求が、事前に定義されたブロッキングキューに追加される。キュー処理モジュール１１６は、間隔を置いてブロッキングキューから変更要求を出力するとともに、ターゲットサービスポイントを位置付けるためにサービングポイント位置付けモジュール１０４を呼び出してもよい。
【０１４５】
多くのユーザが変更要求を同時に送信する場合、変更要求のわずかな数のみ、同時に処理される。それらの受信されたが処理されない変更要求は、変更要求が受信された順に、事前に定義されたブロッキングキュー内に格納される。プロキシポイント及びターゲットサービスポイントがあまりビジーでない場合、ブロッキングキュー内の変更要求は、非常に同時の変更要求の場合に、システムが、オーバーロードなサービスポイント及びプロキシポイントによって麻痺されることを回避するために、順番に処理され、従って、システムはより安定であることができる。
【０１４６】
実施例では、キュー処理モジュール１１６は、ブロッキングキューにおける変更要求の位置のシーケンス番号を、クライアントに送信してもよい。クライアントは、シーケンス番号を表示してもよい。シーケンス番号は、変更要求が処理される前の待機時間を推定するためにユーザによって使用されてもよく、ユーザがプロセスを制御することを容易にする。
【０１４７】
実施例では、サービングユーザデータはユーザＩＤを有してもよい。ターゲットサービスポイントは、サービングユーザデータを検証し、サービングユーザデータ及び対応するユーザＩＤを格納し、変更応答をサービングサービスポイント１０に返してもよい。
【０１４８】
前記接続制御モジュール１１０は、ターゲットサービスポイントに接続するために、ユーザＩＤに対応するクライアントをリダイレクトしてもよい。
【０１４９】
前記ターゲットサービスポイントから変更応答を受信した後、サービングユーザデータ送信モジュール１０８は、ターゲットサービスポイントのＩＰアドレス及びポートを取得し、ユーザＩＤに対応するクライアント、すなわち、変更要求に対応するクライアントに送信してもよい。クライアントは、変更要求を送信するクライアント又は、変更要求内のユーザＩＤによって識別されるクライアントであってもよい。クライアントは、ＩＰアドレス及びポートを使用することによって、ターゲットサービスポイントとの接続を確立してもよい。
【０１５０】
実施例では、ターゲットサービスポイントはまた、暗号鍵生成モジュール（図中には示さず）を有してもよい。変更応答はまた、暗号鍵を有してもよい。変更応答をサービングサービスポイントに送信する前に、暗号鍵生成モジュールは、サービングサービスポイント及びユーザＩＤを使用することによって、暗号鍵を生成してもよい。
【０１５１】
前記接続制御モジュール１１０は、暗号鍵に基づいて、変更要求に対応する接続をターゲットサービスポイントにリダイレクトしてもよい。リダイレクト手続中に、暗号鍵が有効であると判断された場合は、サービスポイントの変更は成功であるとともに、クライアントとターゲットサービスポイントとの間で接続が確立される。暗号鍵が無効であると判断された場合は、サービスポイントの変更は失敗であるとともに、ターゲットサービスポイントは、受信されたサービングユーザデータを削除してもよい。
【０１５２】
図９において示されるような実施例では、サービスポイントはまた、ターゲットサービスポイント４０を有してもよい。ターゲットサービスポイント４０は、ターゲットポイント位置付けモジュール４０２と、ターゲットユーザデータ取得モジュール４０４と、ターゲットユーザデータ送信モジュール４０６とを有してもよい。
【０１５３】
前記ターゲットポイント位置付けモジュール４０２は、サービングサービスポイントを位置付けてもよい。
【０１５４】
前記ターゲットポイント位置付けモジュール４０２は、サービングサービスポイント１０におけるサービングポイント位置付けモジュール１０４がターゲットサービスポイントを位置付ける方法と同様の方法を使用することによって、サービングサービスポイント１０を位置付けてもよい。
【０１５５】
前記ターゲットユーザデータ取得モジュール４０４は、ターゲットサービスポイント内に格納されたユーザＩＤに対応するターゲットユーザデータを取得してもよい。
【０１５６】
前記ターゲットユーザデータは、ターゲットサービスポイント４０内に格納されたユーザデータを指してもよく、すなわち、サービスポイントの変更の後、ターゲットサービスポイント４０がクライアントによって送信されたデータ要求を処理するときに生成される新しいデータを指す。
【０１５７】
前記ターゲットユーザデータ送信モジュール４０６は、ターゲットユーザデータをサービングサービスポイントに送信してもよい。
【０１５８】
前記ターゲットユーザデータ送信モジュール４０６は、サービングユーザデータ送信モジュール１０８がサービングユーザデータをターゲットサービスポイントに送信する方法と同様の方法を使用することによって、ターゲットユーザデータをサービングサービスポイントに送信してもよい。
【０１５９】
前記サービングサービスポイント１０はまた、ターゲットユーザデータをサービングユーザデータと統合するために適用されるサービングユーザデータ統合モジュール１１８を有してもよい。サービングユーザデータ統合モジュール１１８は、ターゲットユーザデータを使用することによって、サービングユーザデータをアップデートしてもよい。
【０１６０】
前記サービングユーザデータ送信モジュール１０８はまた、ターゲットサービスポイントにポイント返還応答を返してもよい。
【０１６１】
前記接続制御モジュール１１０はまた、クライアントとの接続を回復してもよい。
【０１６２】
実施例では、接続制御モジュール１１０は、クライアントとの接続を回復するために、リダイレクトを停止するとともに、接続回復要求を送信してもよい。実施例では、ターゲットサービスポイント４０は、クライアントとの接続をサービングサービスポイント１０にリダイレクトしてもよいとともに、サービングサービスポイント１０は、クライアントとの接続を受動的に回復してもよい。
【０１６３】
実施例では、ターゲットサービスポイント４０はまた、ポイント返還要求を取得するとともに、ターゲットポイント位置付けモジュール４０２を呼び出すために適用される、返還要求取得モジュール（図中には示されず）を有してもよい。
【０１６４】
実施例では、ポイント返還要求は、クライアントによって開始されてもよい。サービスポイントの変更の後、ユーザがターゲットサービスポイントとのデータインタラクションを終了する場合、ユーザは、クライアントを介してポイント返還要求を送信してもよい。例えば、オンラインゲームでは、ユーザは、サービングサービスポイントへの返還を要求するために、ＮＰＣに話しかけることによって、ポイント返還要求を開始してもよい。ポイント返還要求を受信した後、ターゲットサービスポイントは、ユーザがサービングサービスポイントに戻るように、サービングサービスポイントを位置付けるステップを実行してもよい。
【０１６５】
他の実施例では、ポイント返還要求は、制御ポイントによって開始されてもよい。サービングサービスポイントは、ユーザが、サービス要件に基づいて、サービングサービスポイントに戻るように強制してもよい。
【０１６６】
図９において示されるような他の実施例では、ターゲットサービスポイント４０はまた、変更応答を返した後、サービス期間を監視するとともに、サービス期間がタイムアウト時期に達したと検出した場合、ターゲットポイント位置付けモジュール４０２を呼び出すために適用される、タイムアウト検出モジュール４０８を有してもよい。
【０１６７】
前記サービス期間は、ターゲットサービスポイントが、ユーザのデータ要求を処理している時間の長さを指す。タイムアウト検出モジュール４０８は、変更応答を送信した後、時間のカウントを開始するとともに、サービス期間がタイムアウト時期に達したと検出するとき（例えば、事前に定義された時間の長さよりも長いか、又は等しいとき）、クライアントをサービングサービスポイント１０に返すために、サービングサービスポイントを位置付けるために、サービングポイント位置付けモジュール１０４を呼出してもよい。
【０１６８】
図９において示されるような実施例では、ポイント返還応答を受信した後、ターゲットサービスポイント４０は、ターゲットユーザデータを削除するために適用される、ユーザデータ削除モジュール４１０を有してもよい。
【０１６９】
前記ユーザは、サービングサービスポイント１０からターゲットサービスポイント４０にサービスポイントを変更するとともに、一時的なデータインタラクションの後、ターゲットサービスポイントからサービングサービスポイントに戻り、一時的なデータインタラクションの間に生成されたターゲットユーザデータは一時的なユーザデータである。ターゲットユーザデータは、サービングサービスポイント１０内のみに格納されてよく、バックアップされる必要はない。従って、ターゲットユーザデータを削除することは、ターゲットサービスポイント４０の記憶容量を節約することができるとともに、データの冗長性を低減することができる。
【０１７０】
図９において示されるような実施例では、サービングサービスポイント１０はまた、
サービングデータ送信モジュール１０８が変更応答を受信した後、サービングユーザデータをロックするとともに、サービングユーザデータ統合モジュール１０８がターゲットユーザデータをサービングユーザデータと統合する前に、サービングユーザデータをアンロックするために適用された、データ保護モジュール１２０を有してもよい。
【０１７１】
実施例では、データ保護モジュール１２０は、サービングユーザデータのロック及びアンロック状態を示すフラグを追加してもよい。フラグが「ロックされている」と示す場合、プロセス又はスレッドによって開始されたサービングユーザデータを書き込む処理は拒否されてもよく、フラグが「アンロックされている」と示す場合、プロセス又はスレッドは、サービングユーザデータに対して書き込み処理を実行するためにウェイクアップされてもよい。
【０１７２】
実施例では、サービングサービスポイント１０及びターゲットサービスポイント４０は、サービスポイントを変更するプロセスにおける２つのタイプのデバイスか、又は同一のタイプのデバイスの２つの役割であってもよく、すなわち、サービスポイントは、サービングサービスポイントとして機能してもよいとともに、ターゲットサービスポイントとしても機能してもよい。サービングサービスポイント１０の機能とターゲットサービスポイント４０の機能は、１つのデバイス内に統合されてもよく、前記デバイスは、処理において、サービングサービスポイントとして機能してもよいとともに、ターゲットサービスポイントとしても機能してもよい。
【０１７３】
サービスポイントを変更する方法及びシステムに基づくと、クライアントから変更要求を受信した後、サービングサービスポイントは、変更要求を使用することによって、リアルタイムでターゲットサービスポイントを位置付けてもよいとともに、ユーザデータをターゲットサービスポイントに送信してもよい。サービングサービスポイントは、ターゲットサービスポイントによって送信された変更応答（変更承認）を受信した後、自動的にクライアントとの接続をターゲットサービスポイントにリダイレクトする。そのように、ユーザの変更要求はリアルタイムで処理されることができるとともに、サービスポイントの変更はリアルタイムで実施されることができる。
【０１７４】
上述の実施形態は、単に本発明の実施例であるとともに、不要な詳細を含んでもよく、従って、本発明の保護範囲を限定するために使用されるべきではない。当業者には、本発明の主旨内のいかなる修正及び改良も、本発明の保護範囲内に包含されるべきであることは明らかである。従って、本発明の保護範囲は、特許請求の範囲内に記載された不可欠な技術的特徴によって定義された範囲によって決定されるべきである。
【符号の説明】
【０１７５】
１０  サービングサービスポイント
２０  ルーティングポイント
３０  プロキシポイント
４０  ターゲットサービスポイント
１０２  変更要求取得モジュール
１０４  サービングポイント位置付けモジュール
１０６  サービングユーザデータ取得モジュール
１０８  サービングユーザデータ送信モジュール
１１０  接続制御モジュール
１１２  サービングユーザデータフィルタリングモジュール
１１４  負荷取得モジュール
１１６  キュー処理モジュール
１１８  サービングユーザデータ統合モジュール
１２０  データ保護モジュール
４０２  ターゲットポイント位置付けモジュール
４０４  ターゲットユーザデータ取得モジュール
４０６  ターゲットユーザデータ送信モジュール
４０８  タイムアウト検出モジュール
４１０  ユーザデータ削除モジュール
【図１】
2015519844.tif 000005
【図２】
2015519844.tif 000006
【図３】
2015519844.tif 000007
【図４】
2015519844.tif 000008
【図５】
2015519844.tif 000009
【図６】
2015519844.tif 000010
【図７】
2015519844.tif 000011
【図８】
2015519844.tif 000012
【図９】
2015519844.tif 000013
【手続補正書】
【提出日】平成26年11月28日(2014.11.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サービスポイントを変更する方法であって、
サービングサービスポイントによって、変更要求を取得するとともに、前記変更要求からユーザＩＤを取得するステップと、
前記サービングサービスポイントによって、前記変更要求を使用することによって、ターゲットサービスポイントを位置付けるステップと、
前記サービングサービスポイントによって、前記ユーザＩＤに対応するサービングユーザデータを取得し、前記サービングユーザデータを、前記ターゲットサービスポイントに送信するステップと、
前記サービングサービスポイントによって、前記ターゲットサービスポイントから変更応答を受信し、前記ターゲットサービスポイントに接続するために、前記ユーザＩＤに対応するクライアントをリダイレクトするステップと、
を有する方法。
【請求項２】
前記サービングサービスポイントによって、前記変更要求を使用することによって、前記ターゲットサービスポイントを位置付ける前記ステップは、
前記サービングサービスポイントによって、経路取得要求を、ルーティングポイントに送信するステップと、
前記経路取得要求を受信した後、前記ルーティングポイントによって、前記ターゲットサービスポイントを前記サービングサービスポイントに振り当て、前記ターゲットサービスポイントに対応する経路情報を取得し、前記経路情報を、前記サービングサービスポイントに返すステップと
を有する、請求項１に記載の方法。
【請求項３】
前記サービングサービスポイントによって、前記変更要求を使用することによって、前記ターゲットサービスポイントを位置付ける前記ステップは
前記サービングサービスポイントによって、前記変更要求から前記ターゲットサービスポイントのＩＤを取得するステップと、
前記サービングサービスポイントによって、前記ターゲットサービスポイントの前記ＩＤを使用することによって、事前に定義されたルーティングポイントから前記ターゲットサービスポイントまでの経路に関する経路情報を取得するステップと
を有する、請求項１に記載の方法。
【請求項４】
前記経路情報は、少なくとも１つのプロキシポイントの少なくとも１つのＩＤ及び前記少なくとも１つのプロキシポイントのホッピングシーケンスを有し、
前記サービングサービスポイントによって、前記サービングユーザデータを、前記ターゲットサービスポイントに送信するステップは、
前記サービングサービスポイントによって、前記経路情報における前記少なくとも１つのプロキシポイントの前記少なくとも１つのＩＤを使用することによって、データを転送するための少なくとも１つのプロキシポイントを決定するステップと、
前記サービングサービスポイントによって、前記経路情報に基づいて、前記サービングユーザデータを前記少なくとも１つのプロキシポイントに送信するステップと、
前記少なくとも１つのプロキシポイントによって、前記経路情報における前記ホッピングシーケンスに基づいて、ホップ・バイ・ホップで、前記サービングユーザデータを前記ターゲットサービスポイントに転送するステップと
を有する、請求項３に記載の方法。
【請求項５】
前記サービングサービスポイントによって、前記サービングユーザデータを前記ターゲットサービスポイントに送信するステップの前に、
前記経路情報を使用することによって、前記経路情報において識別された前記少なくとも１つのプロキシポイントの負荷に関する第１情報と、前記ターゲットサービスポイントの負荷に関する第２情報とを取得するステップと、
前記サービングサービスポイントによって、前記第１情報及び前記第２情報に基づくブロッキングキューを使用することによって、前記変更要求を処理するステップと
をさらに有する、請求項４に記載の方法。
【請求項６】
前記サービングサービスポイントによって、前記第１情報及び前記第２情報に基づくブロッキングキューを使用することによって、前記変更要求を処理する前記ステップは、
前記第１情報及び前記第２情報と事前に定義された重みとを使用することによって、負荷容量を計算するか、前記負荷容量が、閾値よりも大きい場合、前記サービングユーザデータによって、前記ターゲットサービスポイントに送信する前記ステップを実行するか、又は前記負荷容量が、前記閾値よりも大きくない場合、前記変更要求を事前に定義されたブロッキングキューに追加するステップ
を有する、請求項５に記載の方法。
【請求項７】
前記サービングサービスポイントによって、前記サービングユーザデータを前記ターゲットサービスポイントに送信するステップの前に、
前記サービングサービスポイントによって、サービス要件に基づいて、前記サービングユーザデータをフィルタリングするステップ
をさらに有する、請求項１から６のいずれか1項に記載の方法。
【請求項８】
前記ターゲットサービスポイントによって、前記サービングサービスポイントを位置付けるステップと、
前記ターゲットサービスポイントによって、前記ターゲットサービスポイント内に格納された前記ユーザＩＤに対応するターゲットユーザデータを取得するとともに、前記ターゲットユーザデータを前記サービングサービスポイントに送信するステップと、
前記サービングサービスポイントによって、前記ターゲットユーザデータを受信し、前記ターゲットユーザデータを前記サービングユーザデータと統合し、ポイント返還応答を、前記ターゲットサービスポイントに返すとともに前記クライアントとの接続を回復するステップと
をさらに有する、請求項１から６のいずれか1項に記載の方法。
【請求項９】
前記サービングサービスポイントによって、前記ターゲットサービスポイントによって返された前記変更応答を受信するステップの後に、
前記ターゲットサービスポイントによって、前記サービングサービスポイント及び前記ユーザＩＤに基づく暗号鍵を生成するステップ
をさらに有する、請求項１から６のいずれか１項に記載の方法。
【請求項１０】
前記ターゲットサービスポイントに接続するために、前記ユーザＩＤに対応する前記クライアントをリダイレクトする前記ステップは、
前記サービングサービスポイントによって、前記変更要求に対応する前記ターゲットサービスポイントへの接続を、前記暗号鍵に基づいてリダイレクトするステップと、リダイレクト手続中に、前記暗号鍵が有効であると判断された場合は、サービスポイントの前記変更は成功であると判断するとともに、前記クライアントと前記ターゲットサービスポイントとの接続を確立するステップと、前記暗号鍵が無効であると判断された場合は、サービスポイントの前記変更は失敗であると判断するステップ
を有する、請求項９に記載の方法。
【請求項１１】
サービスポイントを変更するシステムであって、サービスポイントを有し、前記サービスポイントは、サービングサービスポイントを含み、前記サービングサービスポイントは、
変更要求を取得するとともに、前記変更要求からユーザＩＤを取得するために適用される、変更要求取得モジュールと、
前記変更要求を使用することによって、ターゲットサービングポイントを位置付けるために適用される、サービングポイント位置付けモジュールと、
前記ユーザＩＤに対応するサービングユーザデータを取得するために適用される、サービングユーザデータ取得モジュールと、
前記サービングユーザデータを、ターゲットサービスポイントに送信するとともに、前記ターゲットサービスポイントによって返される変更応答を受信するために適用される、サービングユーザデータ送信モジュールと、
前記ターゲットサービスポイントに接続するために、前記ユーザＩＤに対応するクライアントをリダイレクトするために適用される、接続制御モジュールと
を有する、システム。
【請求項１２】
前記サービングポイント位置付けモジュールはさらに、経路取得要求を、ルーティングポイントに送信するために適用され、
前記ルーティングポイントは、前記経路取得要求を受信した後、前記ターゲットサービスポイントを前記サービングサービスポイントに振り当て、前記ターゲットサービスポイントに対応する経路情報を取得し、前記経路情報を、前記サービングサービスポイントに返すために適用される、
請求項１１に記載のシステム。
【請求項１３】
前記サービスポイント間の接続に関する経路情報を格納するために適用されるルーティングポイントをさらに有し、
前記サービングポイント位置付けモジュールはさらに、前記変更要求から前記ターゲットサービスポイントのＩＤを取得するとともに、前記ターゲットサービスポイントの前記ＩＤを使用することによって、事前に定義されたルーティングポイントから前記ターゲットサービスポイントまでの経路に関する経路情報を取得するために適用される、
請求項１１に記載のシステム。
【請求項１４】
前記サービングサービスポイントはまた、サービス要件に基づいて、前記サービングユーザデータをフィルタリングするために適用される、サービングユーザデータフィルタリングモジュールを有する、
請求項１１から１３のいずれか１項に記載のシステム。
【請求項１５】
前記サービスポイントはさらに、ターゲットサービスポイントを有し、前記ターゲットサービスポイントは、ターゲットポイント位置付けモジュールと、ターゲットユーザデータ取得モジュールと、ターゲットユーザデータ送信モジュールとを有し、
前記ターゲットポイント位置付けモジュールは、前記サービングサービスポイントを位置付けるために適用され、
前記ターゲットユーザデータ取得モジュールは、前記ターゲットサービスポイント内に格納された前記ユーザＩＤに対応するターゲットユーザデータを取得するために適用され、
前記ターゲットユーザデータ送信モジュールは、前記ターゲットユーザデータを前記サービングサービスポイントに送信するために適用され、
前記サービングサービスポイントはさらに、前記ターゲットユーザデータを前記サービングユーザデータと統合するために適用される、サービングユーザデータ統合モジュールを有し、
前記サービングユーザデータ送信モジュールはさらに、ポイント返還応答を、前記ターゲットサービスポイントに返すために適用され、
前記接続制御モジュールはさらに、前記クライアントとの接続を回復するために適用される、
請求項１１から１３のいずれか1項に記載のシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本開示は、２０１３年５月３日に出願された、係属中の国際出願PCT/CN2013/075115の国内段階出願であって、中華人民共和国の特許庁に２０１２年５月３０に出願された、“method and apparatus of changing service points”と題する、中国特許出願番号201210173581.Xの優先権を主張し、その開示が、参照によって組み込まれる。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００３４
【補正方法】変更
【補正の内容】
【００３４】
前記ターゲットサービスポイントはまた、サービス期間を監視するとともに、サービス期間がタイムアウト時期に達したという判断に応答して、ターゲットポイント位置付けモジュールを呼び出すために適用される、タイムアウト検出モジュールを有してもよい。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０１６７
【補正方法】変更
【補正の内容】
【０１６７】
前記サービス期間は、ターゲットサービスポイントが、ユーザのデータ要求を処理している時間の長さを指す。タイムアウト検出モジュール４０８は、変更応答を送信した後、時間のカウントを開始するとともに、サービス期間がタイムアウト時期に達したと検出するとき（例えば、事前に定義された時間の長さよりも長いか、又は等しいとき）、クライアントをサービングサービスポイント１０に返すために、サービングサービスポイントを位置付けるために、ターゲットポイント位置付けモジュール１０４を呼出してもよい。
【国際調査報告】
2015519844.tif 000014
2015519844.tif 000015
2015519844.tif 000016
2015519844.tif 000017