分散ＩＤ管理方法および分散ＩＤ管理システム
【課題】同一の管理対象に紐付くものの、日時やドメインによって異なる値を取り得る識別子間の相互変換を可能とし、かつ、管理すべきデータ量を抑えた上で、スケールアウトを可能とする。
【解決手段】分散ＩＤ管理システムのデータ管理装置３は、識別子、ドメイン、日時を含むデータを、インデックスキー（識別子とドメインの組）およびサブルートキー（ルートキーとドメインの組）の２種類のキーを用いて管理する。そして、クライアント装置１からＩＤ変換要求を受け付けると、ゲートウェイ装置２が、インデックスキーを用いてルートキーを検索するデータ管理装置３（３Ａ）を決定する。そして、そのデータ管理装置３（３Ａ）は、サブルートキーを用いて、変換先の識別子を検索するデータ管理装置３（３Ｄ）を決定し、データ管理装置３（３Ｄ）から変換先の識別子を取得して、クライアント装置１に返信する。
【解決手段】分散ＩＤ管理システムのデータ管理装置３は、識別子、ドメイン、日時を含むデータを、インデックスキー（識別子とドメインの組）およびサブルートキー（ルートキーとドメインの組）の２種類のキーを用いて管理する。そして、クライアント装置１からＩＤ変換要求を受け付けると、ゲートウェイ装置２が、インデックスキーを用いてルートキーを検索するデータ管理装置３（３Ａ）を決定する。そして、そのデータ管理装置３（３Ａ）は、サブルートキーを用いて、変換先の識別子を検索するデータ管理装置３（３Ｄ）を決定し、データ管理装置３（３Ｄ）から変換先の識別子を取得して、クライアント装置１に返信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散ＩＤ管理方法および分散ＩＤ管理システムに関する。
【背景技術】
【０００２】
情報システムにおいて物品や人またはそれらに関わるデータを管理する際、管理対象を一意に特定可能な符号、すなわちＩＤ（Identification：識別子）を用いることで、管理の自動化や効率化が図られることが多い。例えば、図書にはＩＳＢＮ（International Standard Book Number：国際標準図書番号）と呼ばれる世界共通の番号が振られており、当該番号を用いれば、全世界でただ一つの書籍を特定することが可能となっている。また、一部の国・地域では、当該国・地域内の個人に納税者番号や住民番号等と呼ばれる識別子を割り当てることで、各個人に紐付くデータと当該個人との関係を一意に識別可能とし、税務や社会保障制度の効率的な運営を図っている。
【０００３】
一般に、管理対象（物品若しくは人等）に対して割り当てられている識別子は、利用される範囲（以下、「ドメイン」と呼ぶ）および時間によって異なる値を取り得る。例えば、ある管理対象に対して、２００９年３月の時点では、Ａ工場で"０"という識別子で管理されていた管理対象が、２０１０年６月の時点では、Ｂ工場で"ａ"という識別子で管理されている状況が存在し得る。この場合、両識別子が同一の管理対象を指しているものであることを把握し、必要に応じて両識別子を相互に変換可能であると、時間やドメインをまたがった効率的な管理が可能となる。また、管理体系の一貫性を保つためには、識別子の更新（例えばＡ工場での識別子が２０１１年９月以降"９"に更新される等）についても把握し、相互変換の際に反映できることが望ましい。
【０００４】
上記のような、相互変換、更新処理を実現するに当たっては、（管理対象、ドメイン、時間）の三次元空間の各点に値（識別子）を対応付けたデータベースを構築し、データ登録・変換・更新のインタフェースを備えることが必要となる。当該データベースは、管理対象の数、ドメインの数、識別子の更新頻度が前もって分かっている場合にはリレーショナルデータベースを用いて実現することが比較的容易であるが、そうでない場合、設計段階でテーブルのサイズやハードウェアの性能要件を定めにくいために、リレーショナルデータベースの利用が必ずしも最適でない可能性がある。このような状況下では、サービス開始後に同装置を一台ないし複数台追加するだけで、要求される容量や性能要件を満足できること（スケールアウト）を可能とする分散データ管理システムが利用されることが多い。
【０００５】
スケールアウト可能な分散データ管理システムの例としては、Consistent Hashingと呼ばれる手法（コンシステントハッシュ法）を応用した方式が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−７４６０４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載された技術では、データ名（キー）に基づいてデータの分散管理が実現されるものの、分散したデータを当該データが含む情報（日時・ドメイン・識別子等）に基づいて効率良く特定する機能を備えていない。例えば前述したように、ある管理対象（物品若しくは人等）に対して、２００９年３月時点では、Ａ工場で"０"という識別子で管理されていた管理対象が、２０１０年６月時点では、Ｂ工場で"ａ"という識別子で管理されているような状況において、変換元の識別子（例えば、"０"）と、変換元のドメイン（例えば、Ａ工場）と、変換元の日時（例えば、２００９年３月）と、変換先のドメイン（例えば、Ｂ工場）と、変換先の日時（例えば、２０１０年６月）と、を指定して、変換先の識別子（ここでは、"ａ"）を得るような処理を実現する場合、"変換元ＩＤ，変換元ドメイン，変換元日時，変換先ドメイン，変換先日時" をデータ名（キー）として、データ内に変換先ＩＤを格納するという方法を用いることにより可能ではある。しかし、このような構成をとった場合には、データ管理システムで保存すべきデータの量や、ＩＤの更新時の書き換えが必要になるデータの量が多くなるという問題がある。また、日時の間隔が広い場合、例えば、月単位や日単位等の場合、上記のようなデータ名を構成することは比較的容易であるが、間隔が細かい場合、例えば、分単位や秒単位等の場合には、管理すべきデータの量が膨大になってしまうという問題がある。
【０００８】
このような背景に鑑みて本発明がなされたのであり、本発明は、同一の管理対象に紐付くものの、日時やドメインによって異なる値を取り得る識別子間の相互変換を可能とし、かつ、管理すべきデータ量を抑えた上で、スケールアウトを可能とする、分散ＩＤ管理方法および分散ＩＤ管理システムを提供することを課題とする。
【課題を解決するための手段】
【０００９】
本発明の分散ＩＤ管理システムにおけるデータ管理装置は、識別子、ドメイン、日時を含むデータを、インデックスキー（識別子とドメインの組）およびサブルートキー（ルートキーとドメインの組）の２種類のキーを用いて管理する。そして、クライアント装置からＩＤ変換要求を受け付けると、ゲートウェイ装置が、インデックスキーを用いてルートキーを保持するデータ管理装置を複数のデータ管理装置の中から決定する。そして、そのデータ管理装置は、サブルートキーを用いて、変換先の識別子を保持する他のデータ管理装置を決定し、他のデータ管理装置から変換先の識別子を取得して、ゲートウェイ装置を介して、クライアント装置に、その変換先の識別子を含むメッセージを送信する。
【発明の効果】
【００１０】
本発明によれば、同一の管理対象に紐付くものの、日時やドメインによって異なる値を取り得る識別子間の相互変換を可能とし、かつ、管理すべきデータ量を抑えた上で、スケールアウトを可能とする、分散ＩＤ管理方法および分散ＩＤ管理システムを提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態に係る分散ＩＤ管理システムの全体の構成例を説明するための図である。
【図２】本実施形態に係るクライアント装置の構成例を示す機能ブロック図である。
【図３】本実施形態に係るゲートウェイ装置の構成例を示す機能ブロック図である。
【図４】本実施形態に係るノード決定部が行うデータの振り分け先となるノードの決定処理を説明するための図である。図４（ａ）は、本実施形態に係るノード情報記憶領域に格納されるノード情報のデータ構成の一例を示す図である。また、図４（ｂ）は、本実施形態に係るノード決定部による、データの振り分け先の決定処理を説明するための図である。
【図５】本実施形態に係るデータ管理装置の構成例を示す機能ブロック図である。
【図６】本実施形態に係る各装置（クライアント装置、ゲートウェイ装置、データ管理装置）のハードウェア構成図である。
【図７】本実施形態に係る分散ＩＤ管理システムが行うＩＤ登録処理の全体の流れを示すシーケンス図である。
【図８】本実施形態に係るデータ管理システムが行うＩＤ登録処理で送受信されるメッセージ例を示す図である。
【図９】本実施形態に係るデータ管理装置のデータ記憶領域に記憶されるインデックスおよびルート情報の例を示す図である。
【図１０】本実施形態に係るＩＤ登録処理におけるゲートウェイ装置の処理の流れを示すフローチャートである。
【図１１】本実施形態に係るノード決定処理の流れを示すフローチャートである。
【図１２】本実施形態に係るＩＤ登録処理における担当ノード（データ管理装置Ａ）の処理の流れを示すフローチャートである。
【図１３】本実施形態に係るＩＤ登録処理における担当ノード（データ管理装置Ａ）の処理の流れを示すフローチャートである。
【図１４】本実施形態に係るインデックス保存処理におけるデータ管理装置の処理の流れを示すフローチャートである。
【図１５】本実施形態に係るルート情報保存処理におけるデータ管理装置の処理の流れを示すフローチャートである。
【図１６】本実施形態に係る分散ＩＤ管理システムが行うＩＤ変換処理の全体の流れを示すシーケンス図である。
【図１７】本実施形態に係るデータ管理システムが行うＩＤ変換処理で送受信されるメッセージ例を示す図である。
【図１８】本実施形態に係るＩＤ変換処理におけるゲートウェイ装置の処理の流れを示すフローチャートである。
【図１９】本実施形態に係るＩＤ変換処理におけるデータ管理装置Ａの処理の流れを示すフローチャートである。
【図２０】本実施形態に係るＩＤ取得処理におけるデータ管理装置Ｄの処理の流れを示すフローチャートである。
【図２１】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理の全体の流れを示すシーケンス図である。
【図２２】本実施形態に係るデータ管理システムが行うＩＤ更新処理で送受信されるメッセージ例を示す図である。
【図２３】本実施形態に係るデータ管理装置の、ＩＤ更新処理後のデータ記憶領域に記憶されるインデックスおよびルート情報の例を示す図である。
【図２４】本実施形態に係るＩＤ更新処理におけるゲートウェイ装置の処理の流れを示すフローチャートである。
【図２５】本実施形態に係るＩＤ更新処理におけるデータ管理装置Ａの処理の流れを示すフローチャートである。
【図２６】本実施形態に係るＩＤ更新処理におけるデータ管理装置Ａの処理の流れを示すフローチャートである。
【図２７】本実施形態に係るＩＤ更新処理におけるデータ管理装置Ｂのルート情報更新処理の流れを示すフローチャートである。
【図２８】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理後のＩＤ変換処理（１）の全体の流れを示すシーケンス図である。
【図２９】本実施形態に係るデータ管理システムが行うＩＤ更新処理後のＩＤ変換処理（１）で送受信されるメッセージ例を示す図である。
【図３０】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理後のＩＤ変換処理の全体の流れ（２）を示すシーケンス図である。
【図３１】本実施形態に係るデータ管理システムが行うＩＤ更新処理後のＩＤ変換処理（２）で送受信されるメッセージ例を示す図である。
【図３２】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理後のＩＤ変換処理（失敗例）の全体の流れを示すシーケンス図である。
【図３３】本実施形態に係るデータ管理システムが行うＩＤ更新処理後のＩＤ変換処理（失敗例）で送受信されるメッセージ例を示す図である。
【発明を実施するための形態】
【００１２】
まず、本実施形態に係る分散ＩＤ管理システム５の構成について説明する。
図１は、本実施形態に係る分散ＩＤ管理システム５の全体の構成例を説明するための図である。
【００１３】
図１に示すように、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１と接続されたゲートウェイ装置２と、そのゲートウェイ装置２と通信ネットワーク４を介して接続された複数のデータ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，…）とを含んで構成される。このデータ管理装置３は、図１に示したように５つに限定されず、複数のデータ管理装置３であればよい。また各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，…）それぞれは、通信ネットワーク４を介して通信可能に接続されている。
【００１４】
クライアント装置１は、分散ＩＤ管理システム５（ゲートウェイ装置２）に対して、後記するＩＤ登録要求メッセージ１０（図８（ａ）参照）、ＩＤ変換要求メッセージ４０（図１７（ａ）参照）、ＩＤ更新要求メッセージ６０（図２２（ａ）参照）を送信し、その結果を受信する装置である。また、ゲートウェイ装置２は、クライアント装置１から上記の各メッセージを受信し、そのメッセージを担当するデータ管理装置３に振り分けて送信し、データ管理装置３からの処理結果を、クライアント装置１へ返信する装置である。データ管理装置３は、ゲートウェイ装置２から取得したメッセージに従い、データの登録、変換、更新等を行う装置である。次に、各装置の詳細な構成について説明する。
【００１５】
≪クライアント装置≫
図２は、本実施形態に係るクライアント装置１の構成例を示す機能ブロック図である。図２に示すように、クライアント装置１は、制御部１１０と、入出力部１３０と、送受信部１４０と、記憶部１５０とを含んで構成される。
【００１６】
また、制御部１１０は、ＩＤ登録要求部１１１と、ＩＤ変換要求部１１２と、ＩＤ更新要求部１１３とを備えている。
【００１７】
ＩＤ登録要求部１１１は、後記するＩＤ登録要求メッセージ１０（図８（ａ）参照）を生成し、そのＩＤ登録要求メッセージ１０を、送受信部１４０を介して、ゲートウェイ装置２に送信する。また、ＩＤ登録要求部１１１は、ＩＤ登録応答メッセージ１１（図８（ｂ）参照）を、送受信部１４０を介して受信する。
【００１８】
ＩＤ変換要求部１１２は、後記するＩＤ変換要求メッセージ４０（図１７（ａ）参照）を生成し、そのＩＤ変換要求メッセージ４０を、送受信部１４０を介して、ゲートウェイ装置２に送信する。また、ＩＤ変換要求部１１２は、ＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を、送受信部１４０を介して受信する。
【００１９】
ＩＤ更新要求部１１３は、後記するＩＤ更新要求メッセージ６０（図２２（ａ）参照）を生成し、そのＩＤ更新要求メッセージ６０を、送受信部１４０を介して、ゲートウェイ装置２に送信する。また、ＩＤ更新要求部１１３は、ＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を、送受信部１４０を介して受信する。
【００２０】
入出力部１３０は、不図示のキーボードやマウス等の入力手段や、モニタ等の出力手段と接続され、利用者から入力手段を介して入力情報を受け付け、その入力情報や処理結果をモニタ等の出力手段に出力する処理を行う。
【００２１】
送受信部１４０は、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）通信を可能とするプロトコルスタックや、プロセス間通信を可能とするモジュール等のように、ネットワークや通信路を介して送受信する情報の制御を行う。
【００２２】
記憶部１５０は、ゲートウェイ情報記憶領域１００を含んで構成される。ゲートウェイ情報記憶領域１００は、ＩＤ登録要求メッセージ１０、ＩＤ変換要求メッセージ４０、ＩＤ更新要求メッセージ６０の送信先となるゲートウェイ装置２の接続情報（例えば、ＩＰアドレスとポート番号の組）を記憶する領域である。この接続情報は、前もって静的に登録するようにしてもよいし、ゲートウェイ装置２や他の装置からの情報に基づいて動的に接続先を決定し記憶するようにしてもよい。
【００２３】
≪ゲートウェイ装置≫
図３は、本実施形態に係るゲートウェイ装置２の構成例を示す機能ブロック図である。図３に示すように、ゲートウェイ装置２は、制御部２１０と、入出力部２３０と、送受信部２４０と、記憶部２５０とを含んで構成される。
【００２４】
また、制御部２１０は、ノード管理部２１１と、ノード決定部２１２と、ＩＤ登録転送部２１３と、ＩＤ変換転送部２１４と、ＩＤ更新転送部２１５とを備えている。
【００２５】
ノード管理部２１１は、データ管理装置３の後記するノード管理部３１１と相互通信し、後記するノード情報記憶領域２００内のノードの接続情報（例えば、ＩＰアドレスとポート番号の組）を同期する処理を行う。具体的には、ノード管理部２１１は、新たにデータ管理装置３が追加された場合には、その接続情報をノード情報記憶領域２００内に追加し、あるデータ管理装置３が削除された場合には、そのデータ管理装置３の接続情報を削除する。
【００２６】
ノード決定部２１２は、他の処理部から検索キーを取得した場合に、ノード情報記憶領域２００に格納されたノード情報に基づいて、検索キーが担当するノード（データ管理装置３）を決定し、そのノードの接続情報を、要求のあった処理部に返す処理を行う。以下、具体的にノード決定部２１２が行う処理を説明する。
【００２７】
図４（ａ）は、本実施形態に係るノード情報記憶領域２００に格納されるノード情報のデータ構成の一例を示す図である。また、図４（ｂ）は、本実施形態に係るノード決定部２１２による、データの振り分け先の決定処理を説明するための図である。
【００２８】
図４（ａ）に示すように、ノード情報記憶領域２００のノード情報には、各データ管理装置３について、ノードＩＤと、ノード名と、接続情報（例えば、ＩＰアドレスとポート番号の組）とが記憶されている。このノードＩＤは、ノード決定部２１２が、例えば、接続情報を所定のハッシュ関数に導入することにより得られたハッシュ値であり、図４（ｂ）に示すリング（閉じたハッシュ空間）４００上の値に対応付けられる。なお、このノード情報記憶領域２００内のノード情報は、ゲートウェイ装置２のノード管理部２１１およびデータ管理装置３のノード管理部３１１により、ゲートウェイ装置２とすべてのデータ管理装置３との間で定期的に同期をとることで、同じノード情報が共有されている。
【００２９】
ノード決定部２１２は、図４（ｂ）に示すように、例えば、検索キーとして"０＠Ｄ０"を取得すると、その検索キーをハッシュ関数Ｈに導入しハッシュ値を計算する。そして、ノード決定部２１２は、その計算したハッシュ値（図４（ｂ）では、「２１３３」）の値より大きく、最も近いノードＩＤ（ハッシュ値）である「３０５０」のデータ管理装置Ａを、その検索キーのデータの振り分け先のノードとして決定する。
なお、このとき、ノード決定部２１２は、振り分け先として決定したノードの次に値が近いノードＩＤ（ハッシュ値）を持つノード（ここでは、例えば、ノードＩＤが「５９８８」のデータ管理装置３Ｂ）をさらに選択（さらに、次に値の近いノードＩＤを含むようにして、１つ以上選択するようにしてもよい）することで、後記する各メッセージの送信先を冗長化し、システムの信頼性を高めることも可能である。
【００３０】
図３に戻り、ＩＤ登録転送部２１３は、受信したＩＤ登録要求メッセージ１０（図８（ａ）参照）の先頭の識別子（例えば、"０"）とドメイン（例えば、"Ｄ０"）を結合した値としてインデックスキー（例えば、"０＠Ｄ０"）を生成し、ノード決定部２１２に出力する。そして、ＩＤ登録転送部２１３は、ノード決定部２１２が決定した担当ノードとなるデータ管理装置３に、送受信部２４０を介してＩＤ登録要求メッセージ１０を送信する。ここで、担当ノードとは、ＩＤ登録要求メッセージ１０の先頭の識別子とドメインを結合したインデックスキーをkeyとする後記するインデックスを保存するノード（データ管理装置３）のことをいう。また、ＩＤ登録転送部２１３は、送受信部２４０を介して、担当ノードからＩＤ登録応答メッセージ１１（図８（ｂ）参照）を受信し、クライアント装置１に送信する。
【００３１】
ＩＤ変換転送部２１４は、受信したＩＤ変換要求メッセージ４０（図１７（ａ）参照）の変換元識別子（例えば、"０"）と変換元ドメイン（例えば、"Ｄ０"）を結合した値としてインデックスキー（例えば、"０＠Ｄ０"）を生成し、ノード決定部２１２に出力する。そして、ＩＤ変換転送部２１４は、ノード決定部２１２が決定したインデックスノード（インデックスを保存するノードであり、詳細は後記する）となるデータ管理装置３に、送受信部２４０を介して、ＩＤ変換要求メッセージ４０を送信する。また、ＩＤ変換転送部２１４は、送受信部２４０を介して、インデックスノードからＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を受信し、クライアント装置１に送信する。
【００３２】
ＩＤ更新転送部２１５は、受信したＩＤ更新要求メッセージ６０（図２２（ａ）参照）の更新対象識別子（例えば、"０"）と更新対象ドメイン（例えば、"Ｄ０"）を結合した値としてインデックスキー（例えば、"０＠Ｄ０"）を生成し、ノード決定部２１２に出力する。そして、ＩＤ更新転送部２１５は、ノード決定部２１２が決定したインデックスノードとなるデータ管理装置３に、送受信部２４０を介して、ＩＤ更新要求メッセージ６０を送信する。また、ＩＤ更新転送部２１５は、送受信部２４０を介して、インデックスノードからＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を受信し、クライアント装置１に送信する。
【００３３】
入出力部２３０は、不図示のキーボードやマウス等の入力手段や、モニタ等の出力手段と接続され、利用者から入力手段を介して入力情報を受け付け、その入力情報や処理結果をモニタ等の出力手段に出力する処理を行う。
【００３４】
送受信部２４０は、ＴＣＰ／ＩＰ通信を可能とするプロトコルスタックや、プロセス間通信を可能とするモジュール等のように、ネットワークや通信路を介して送受信する情報の制御を行う。
【００３５】
記憶部２５０は、前記したノード情報記憶領域２００（図４（ａ）参照）を含んで構成される。
【００３６】
なお、本実施形態ではゲートウェイ装置２をクライアント装置１やデータ管理装置３とは独立した装置として扱っているが、本発明はこのような態様に限定されない。ゲートウェイ装置２を構成する各機能をクライアント装置１またはデータ管理装置３の中に実装することで、ゲートウェイ装置２を排した分散ＩＤ管理システム５を実現することも可能である。
【００３７】
≪データ管理装置≫
図５は、本実施形態に係るデータ管理装置３の構成例を示す機能ブロック図である。
図５に示すように、データ管理装置３は、制御部３１０と、入出力部３３０と、送受信部３４０と、記憶部３５０とを含んで構成される。
【００３８】
また、制御部３１０は、ノード管理部３１１と、ノード決定部３１２と、ルートキー生成部３１３と、ＩＤ登録処理部３１４と、ＩＤ変換処理部３１５と、ＩＤ更新処理部３１６と、ＩＤ取得処理部３１７と、インデックス登録処理部３１８と、ルート情報登録処理部３１９と、ルート情報更新処理部３２０と、データ管理部３２１とを備えている。
【００３９】
ノード管理部３１１およびノード決定部３１２の処理は、ゲートウェイ装置２のノード管理部２１１およびノード決定部２１２と同様であるので、説明を省略する。
【００４０】
ルートキー生成部３１３は、擬似乱数生成器等を利用して、ルートキー（例えば、"Ｒ０"）を生成する。ここでルートキーとは、分散ＩＤ管理システム５内で管理対象を一意に特定するための識別子を指すものである。
【００４１】
ＩＤ登録処理部３１４は、ＩＤ登録処理の全般を制御する。以下、具体的に説明する。
ＩＤ登録処理部３１４は、識別子とドメインとを結合した値（例えば、"０＠Ｄ０"）をインデックスキーとして生成し、ノード決定部３１２に出力する。そして、ＩＤ登録処理部３１４は、ノード決定部３１２が決定したインデックスノードとなるデータ管理装置３に、送受信部３４０を介して、インデックス登録要求メッセージ３０（後記する図８（ｅ）参照）を送信する。
また、ＩＤ登録処理部３１４は、ルートキー（例えば、"Ｒ０"）とドメイン（例えば、、"Ｄ０"）とを結合した値（例えば、"Ｒ０＠Ｄ０"）をサブルートキーとして生成し、ノード決定部３１２に出力する。そして、ＩＤ登録処理部３１４は、ノード決定部３１２が決定したルートノードとなるデータ管理装置３に、送受信部３４０を介して、ルート情報登録要求メッセージ２０（後記する図８（ｃ）参照）を送信する。ここでルートノードとは、サブルートキーをkeyとする後記するルート情報を保存するノード（データ管理装置３）のことをいう。そして、ＩＤ登録処理部３１４は、ルートノードからルート情報登録応答メッセージ２１（後記する図８（ｄ）参照）を受信すると、ＩＤ登録応答メッセージ１１（後記する図８（ｂ）参照）を生成し、ゲートウェイ装置２へ送信する。
【００４２】
ＩＤ変換処理部３１５は、ＩＤ変換処理の全般を制御する。以下、具体的に説明する。
ＩＤ変換処理部３１５は、ＩＤ変換要求メッセージ４０（図１７（ａ）参照）から、変換元識別子（例えば、"０"）と変換元ドメイン（例えば、"Ｄ０"）とを結合した値（例えば、"０＠Ｄ０"）としてインデックスキーを生成する。そして、ＩＤ変換処理部３１５は、生成したインデックスキー（"０＠Ｄ０"）と、変換元日時（例えば、"Ｔ１"）とを、データ管理部３２１に出力することにより、データ記憶領域３３０内のインデックスから、ルートキー（例えば、"Ｒ０"）を取得する。
ＩＤ変換処理部３１５は、取得したルートキー（"Ｒ０"）と変換先ドメイン（例えば、"Ｄ１"）を結合した値（例えば、"Ｒ０＠Ｄ１"）としてサブルートキーを生成し、ノード決定部３１２が決定したルートノードとなるデータ管理装置３に、ＩＤ取得要求メッセージ５０（後記する図１７（ｃ）参照）を送信する。
また、ＩＤ変換処理部３１５は、ルートノードから、送受信部３４０を介して、ＩＤ取得応答メッセージ５１（後記する図１７（ｄ）参照）を受信する。そして、ＩＤ変換処理部３１５は、ＩＤ取得応答メッセージ５１から取得したＩＤ（識別子）を含む、ＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を生成し、送受信部３４０を介して、ゲートウェイ装置２に送信する。
【００４３】
ＩＤ更新処理部３１６は、ＩＤ更新処理の全般を制御する。以下、具体的に説明する。
ＩＤ更新処理部３１６は、ＩＤ更新要求メッセージ６０（図２２（ａ）参照）から、更新対象識別子（例えば、"０"）と更新対象ドメイン（例えば、"Ｄ０"）とを結合した値（例えば、"０＠Ｄ０"）としてインデックスキーを生成する。そして、ＩＤ更新処理部３１６は、生成したインデックスキー（"０＠Ｄ０"）と、更新対象日時（例えば、"Ｔ１"）とを、データ管理部３２１に出力することにより、ルートキー（例えば、"Ｒ０"）を取得する。
また、ＩＤ更新処理部３１６は、データ管理部３２１を介して、当該行の失効日時（"∞"）を更新日時（例えば、"Ｔ２"）に更新する。
次に、ＩＤ更新処理部３１６は、ルートキー（"Ｒ０"）と更新対象ドメイン（"Ｄ０"）とを結合した値（例えば、"Ｒ０＠Ｄ０"）としてサブルートキーを生成し、ノード決定部３１２が決定したルートノードとなるデータ管理装置３に、ルート情報更新要求メッセージ７０（後記する図２２（ｃ）参照）を送信する。
ＩＤ更新処理部３１６は、ルートノードから、送受信部３４０を介して、ルート情報更新応答メッセージ７１（後記する図２２（ｄ）参照）を受信する。
また、ＩＤ更新処理部３１６は、更新後識別子（例えば、"９"）と更新対象ドメイン（"Ｄ０"）とを結合した値（例えば、"９＠Ｄ０"）としてインデックスキーを生成し、ノード決定部３１２が決定したインデックスノードとなるデータ管理装置３に、インデックス登録要求メッセージ３０（図２２（ｅ）参照）を送信する。
そして、ＩＤ更新処理部３１６は、インデックスノードから、送受信部３４０を介して、インデックス登録応答メッセージ３１（図２２（ｆ）参照）を受信する。続いて、ＩＤ更新処理部３１６は、ＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を生成し、送受信部３４０を介して、ゲートウェイ装置２に送信する。
【００４４】
ＩＤ取得処理部３１７は、ＩＤ取得要求メッセージ５０（図１７（ｃ）参照）から、サブルートキー（例えば、"Ｒ０＠Ｄ１"）と、変換先日時（例えば、"Ｔ１"）とを取得し、データ管理部３２１に出力することにより、変換先となる識別子（例えば、"ａ"）を取得する。そして、ＩＤ取得処理部３１７は、変換先となる識別子（"ａ"）を含むＩＤ取得応答メッセージ５１（図１７（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４５】
インデックス登録処理部３１８は、受信したインデックス登録要求メッセージ３０（図８（ｅ）参照）に基づいて、インデックス登録処理を行い、当該処理結果（例えば、"success"）を含むインデックス登録応答メッセージ３１（図８（ｆ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４６】
ルート情報登録処理部３１９は、受信したルート情報登録要求メッセージ２０（例えば、図８（ｃ）参照）に基づいて、ルート情報登録処理を行い、当該処理結果（例えば、"success"）を含むルート情報登録応答メッセージ２１（図８（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４７】
ルート情報更新処理部３２０は、受信したルート情報更新要求メッセージ７０（図２２（ｃ）参照）に基づいて、ルート情報更新処理を行い、当該処理結果（例えば、"success"）を含むルート情報更新応答メッセージ７１（図２２（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４８】
データ管理部３２１は、他の処理部からの要求を受けて、データ記憶領域３００内のデータの作成、検索、更新、削除等を行う。
【００４９】
入出力部３３０は、不図示のキーボードやマウス等の入力手段や、モニタ等の出力手段と接続され、利用者から入力手段を介して入力情報を受け付け、その入力情報や処理結果をモニタ等の出力手段に出力する処理を行う。
【００５０】
送受信部３４０は、ＴＣＰ／ＩＰ通信を可能とするプロトコルスタックや、プロセス間通信を可能とするモジュール等のように、ネットワークや通信路を介して送受信する情報の制御を行う。
【００５１】
記憶部３５０は、前記したノード情報記憶領域２００（図４（ａ）参照）と、データ記憶領域３００とを含んで構成される。
このデータ記憶領域３００は、key、登録日時、失効日時、valueの４つの組のデータが、インデックス若しくはルート情報として記憶される領域である。詳細は後記において説明する。
【００５２】
≪ハードウェア構成≫
図６は、本実施形態に係る各装置（クライアント装置１、ゲートウェイ装置２、データ管理装置３）のハードウェア構成図である。
【００５３】
図６に示すように、本実施形態に係る各装置は、一般的なコンピュータ１０００により実現される。
コンピュータ１０００は、ＣＰＵ１００１と、メモリ１００２と、ハードディスク等の外部記憶装置１００３と、通信ネットワークに接続するためのＮＩＣ（Network Interface Card）等の送受信装置１００４と、モニタ等の出力装置１００５と、キーボードやマウス等の入力装置１００６と、CD-ROMやDVD-ROM等の可搬性を有する記憶媒体１００８から情報を読み取る読取装置１００７とを含んで構成される。
【００５４】
そして、各装置の記憶部内の記憶領域は、ＣＰＵ１００１がメモリ１００２または外部記憶装置１００３を利用することにより実現可能となる。また、各制御部は、外部記憶装置１００３に記憶されている所定のプログラムをメモリ１００２にロードすることによりＣＰＵ１００１で実現可能となる。この所定のプログラムは、読取装置１００７を介して記憶媒体１００８から取得してもよいし、送受信装置１００４を介してネットワークから外部記憶装置１００３にダウンロードされ、メモリ１００２にロードされてＣＰＵ１００１により実行されるようにしてもよい。また、読取装置１００７を介して記憶媒体１００８から、あるいは、送受信装置１００４を介してネットワークから、メモリ１００２に直接ロードされ、ＣＰＵ１００１により実行されるようにしてもよい。
【００５５】
≪分散ＩＤ管理方法≫
次に、本実施形態に係る分散ＩＤ管理システム５による分散ＩＤ管理方法について説明する。具体的には、分散ＩＤ管理システム５による、（１）ＩＤ登録処理、（２）ＩＤ変換処理、（３）ＩＤ更新処理について説明する。
（１）ＩＤ登録処理は、クライアント装置１から取得したＩＤ登録要求メッセージ１０（図８（ａ）参照）に含まれる「識別子」「ドメイン」「登録日時」を含む登録情報を、ゲートウェイ装置２を介して、インデックスおよびルート情報という保存形式により、分散させてデータ管理装置３に保存する処理である。
（２）ＩＤ変換処理は、クライアント装置１から取得したＩＤ変換要求メッセージ４０（図１７（ａ）参照）に含まれる「変換元識別子」「変換元ドメイン」「変換元日時」「変換先ドメイン」「変換先日時」のパラメータを用いて、「変換元識別子」を「変換先識別子」に変換する、つまり、「変換先識別子」を検索する処理である。
（３）ＩＤ更新処理は、クライアント装置１から取得したＩＤ更新要求メッセージ６０（図２２（ａ）参照）に基づき、ある「更新対象ドメイン」における「更新日時」以降の識別子を、それまで登録されていた「更新対象識別子」から新たな識別子である「更新後識別子」に更新する処理である。
以下、各処理について詳細に説明する。
【００５６】
＜ＩＤ登録処理＞
まず、図７〜図１５を参照して、クライアント装置１がゲートウェイ装置２に対してＩＤの登録を要求（ＩＤ登録要求）した際に、ゲートウェイ装置２およびデータ管理装置３が実行するＩＤ登録処理について説明する。
【００５７】
ここでは、クライアント装置１が要求するＩＤ登録処理の例として、ドメイン"Ｄ０"の日時"Ｔ０"における識別子"０"と、ドメイン"Ｄ１"の日時"Ｔ０"における識別子"ａ"が、同じ管理対象を示す識別子であることを分散ＩＤ管理システム５に登録する処理を例に説明する。
【００５８】
（ＩＤ登録処理の全体の流れ）
図７は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ登録処理の全体の流れを示すシーケンス図である。
【００５９】
まず、クライアント装置１は、ＩＤ登録要求メッセージ１０をゲートウェイ装置２へ送信する（ステップＳ１０１）。
【００６０】
図８（ａ）は、ＩＤ登録要求メッセージ１０を例示する図である。図８（ａ）に示すように、ＩＤ登録要求メッセージ１０は、「識別子」，「ドメイン」，「登録日時」の３つのパラメータで１つの登録情報を示し、符号１０−１は、当該ＩＤ登録要求が、ドメイン"Ｄ０"の登録日時"Ｔ０"における識別子"０"を含むことを示し、符号１０−２は、当該ＩＤ登録要求が、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"を含むことを示す。そして、このＩＤ登録要求メッセージ１０が要求するＩＤ登録処理では、ドメイン"Ｄ０"の登録日時"Ｔ０"における識別子"０"と、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"が、同じ管理対象を示す識別子であることを登録する処理を行う。
なお、本例では、「識別子」，「ドメイン」，「登録日時」の組となる登録情報について、２組の例を説明するが、２組に限定されるものではなく、３組以上の登録情報を同時に登録するようにしてもよい。
また、図７以下に示す図において、例えば、日時"Ｔ０"におけるドメイン"Ｄ０"の識別子"０"の情報を、［０＠Ｄ０：Ｔ０］のように表記するものとする。
【００６１】
図７に戻り、次に、ゲートウェイ装置２は、担当ノードの決定処理を行う（ステップＳ１０２）。ここで、担当ノードとは、受信したＩＤ登録要求メッセージ１０の先頭のインデックスキー（ここでは、先頭の識別子"０"とドメイン"Ｄ０"とを結合した値として"０＠Ｄ０"）をkeyとする後記するインデックスを保存するノード（データ管理装置３）を指す。ゲートウェイ装置２のノード決定部２１２は、インデックスキー"０＠Ｄ０"をキーとして、コンシステントハッシュ法により、担当ノードを決定する。ここでは、ノード決定部２１２が、データ管理装置３Ａを担当ノードとして決定したものとする。
【００６２】
続いて、ゲートウェイ装置２は、ＩＤ登録要求メッセージ１０を、担当ノードとして決定したデータ管理装置３Ａに送信する（ステップＳ１０３）。
【００６３】
データ管理装置３Ａは、ＩＤ登録要求メッセージ１０を受信すると、ルートキーの生成処理を行う（ステップＳ１０４）。ルートキーは、例えば、ドメイン"Ｄ０"の日時"Ｔ０"における識別子"０"と、ドメイン"Ｄ１"の日時"Ｔ０"における識別子"ａ"とが指し示す同一の管理対象を、分散ＩＤ管理システム５内で一意に特定するための識別子を指すものである。ここでは、例えば、データ管理装置３Ａのルートキー生成部３１３が、擬似乱数生成器等を用いてルートキーとして"Ｒ０"を生成する。
【００６４】
次に、データ管理装置３Ａは、インデックスの保存（登録）処理を行う（ステップＳ１０５）。ここで、インデックスとは、インデックスキー（識別子とドメインの結合値。例えば、"０＠Ｄ０"）と、登録日時（例えば、"Ｔ０"）と、ルートキー（例えば、"Ｒ０"）とを含む情報を指すものである（例えば、後記する図９（ａ）参照）。
具体的には、まず、データ管理装置３Ａは、識別子"０"、ドメイン"Ｄ０"に関するインデックスを保存するインデックスノード（データ管理装置３）を決定する。インデックスノードの決定処理は、インデックスキー（"０＠Ｄ０"）を検索キーとして、担当ノードの決定処理と同様にノード決定部３１２により実行される。そして、ノード決定部３１２は、コンシステントハッシュ法を用いて、データ管理装置３Ａ自身をインデックスノードとして決定する。そして、データ管理装置３Ａは、自身のデータ記憶領域３００Ａ（３００）に対して、インデックスの保存処理を行う。
【００６５】
図９（ａ）は、インデックスが保存（登録）されたデータ管理装置３Ａのデータ記憶領域３００Ａの例を示す。このデータ記憶領域３００Ａに保存されたインデックスには、keyとしてのインデックスキー"０＠Ｄ０"、登録日時としての"Ｔ０"、失効日時として（"０＠Ｄ０"がまだ失効されていないことを示す）"∞"、valueとしてのルートキー"Ｒ０"がそれぞれ格納される。
【００６６】
図７に戻り、次に、データ管理装置３Ａは、ドメイン"Ｄ０"に関するルートノードの決定処理を行う（ステップＳ１０６）。ここでルートノードとは、サブルートキー（ルートキーとドメインの結合値。例えば、"Ｒ０＠Ｄ０"）をkeyとする後記するルート情報を保存すべきノード（データ管理装置３）を指す。このルートノード決定処理は、サブルートキーを検索キーとして、ノード決定部３１２が、コンシステントハッシュ法により、ルートノードを決定する。ここでは、例えば、サブルートキー"Ｒ０＠Ｄ０"に対応するノードとしてデータ管理装置３Ｂが、ルートノードして決定されたものとする。
【００６７】
続いて、データ管理装置３Ａは、ルート情報登録要求メッセージ２０ａ（２０）を、ルートノードとして決定したデータ管理装置３Ｂに送信する（ステップＳ１０７）。
【００６８】
図８（ｃ）は、ルート情報登録要求メッセージ２０を例示する図である。図８（ｃ）に示すように、ルート情報登録要求メッセージ２０は、「サブルートキー」，「識別子」，「登録日時」のパラメータを含んで構成される。図８（ｃ）に例示するルート情報登録要求メッセージ２０ａ（２０）は、ルートキー"Ｒ０"と、ドメイン"Ｄ０"の登録日時"Ｔ０"における識別子"０"とを対応付けて管理するように要求するものである。
【００６９】
図７に戻り、ルート情報登録要求メッセージ２０ａ（２０）を受信したデータ管理装置３Ｂは、ルート情報の保存（登録）処理を行う（ステップＳ１０８）。ここで、ルート情報とは、サブルートキー（ルートキーとドメインの結合値。例えば、"Ｒ０＠Ｄ０"）と、登録日時（例えば、"Ｔ０"）と、識別子（例えば、"０"）とを含む情報を指すものである。
【００７０】
図９（ｂ）は、ルート情報が保存（登録）されたデータ管理装置３Ｂのデータ記憶領域３００Ｂの例を示す。このデータ記憶領域３００Ｂに保存されたルート情報には、keyとしてのサブルートキー"Ｒ０＠Ｄ０"、登録日時としての"Ｔ０"、失効日時として（"Ｒ０＠Ｄ０"がまだ失効されていないことを示す）"∞"、valueとしての識別子"０"がそれぞれ格納される。
【００７１】
図７に戻り、データ管理装置３Ｂは、ルート情報登録応答メッセージ２１ａ（２１）を、データ管理装置３Ａに送信する（ステップＳ１０９）。図８（ｄ）に示すように、ルート情報登録応答メッセージ２１は、処理結果を示すパラメータで構成される。ここでは、ルート情報登録応答メッセージ２１ａとして、ルート情報の登録処理が成功したことを示す"success"が付されるものとする。
【００７２】
次に、データ管理装置３Ａは、識別子"ａ"、ドメイン"Ｄ１"に関するインデックスノードの決定処理を行う（ステップＳ１１０）。ここでは、例えば、インデックスキー"ａ＠Ｄ１"に対応するノードであるデータ管理装置３Ｃが、ノード決定部３１２によりインデックスノードとして決定される。
【００７３】
続いて、データ管理装置３Ａは、インデックス登録要求メッセージ３０ａ（３０）を、インデックスノードとして決定したデータ管理装置３Ｃに送信する（ステップＳ１１１）。
【００７４】
図８（ｅ）は、インデックス登録要求メッセージ３０を例示する図である。図８（ｅ）に示すように、インデックス登録要求メッセージ３０は、「インデックスキー」，「ルートキー」，「登録日時」のパラメータを含んで構成される。図８（ｅ）に例示するインデックス登録要求メッセージ３０ａ（３０）は、ルートキー"Ｒ０"と、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"とを対応付けて管理するように要求するものである。
【００７５】
図７に戻り、インデックス登録要求メッセージ３０ａ（３０）を受信したデータ管理装置３Ｃは、インデックスの保存（登録）処理を行う（ステップＳ１１２）。
【００７６】
図９（ｃ）は、インデックスが保存（登録）されたデータ管理装置３Ｃのデータ記憶領域３００Ｃの例を示す。このデータ記憶領域３００Ｃに保存されたインデックスには、keyとしてのインデックスキー"ａ＠Ｄ１"、登録日時としての"Ｔ０"、失効日時として（"ａ＠Ｄ１"がまだ失効されていないことを示す）"∞"、valueとしてのルートキー"Ｒ０"がそれぞれ格納される。
【００７７】
図７に戻り、データ管理装置３Ｃは、インデックス登録応答メッセージ３１ａ（３１）を、データ管理装置３Ａに送信する（ステップＳ１１３）。図８（ｆ）に示すように、インデックス登録応答メッセージ３１は、処理結果を示すパラメータで構成される。ここでは、インデックス登録応答メッセージ３１ａ（３１）として、インデックスの登録処理が成功したことを示す"success"が付されるものとする。
【００７８】
図７に戻り、データ管理装置３Ａは、ドメイン"Ｄ１"に関するルートノードの決定処理を行う（ステップＳ１１４）。ここでは、ノード決定部３１２が、サブルートキー"Ｒ０＠Ｄ１"に対応するノードとして、データ管理装置３Ｄをルートノードとして決定したものとする。
【００７９】
続いて、データ管理装置３Ａは、ルート情報登録要求メッセージ２０ｂ（２０）を、ルートノードとして決定したデータ管理装置３Ｄに送信する（ステップＳ１１５）。
【００８０】
ルート情報登録要求メッセージ２０ｂは、図８（ｇ）に示すように、サブルートキー"Ｒ０＠Ｄ１"と、識別子"ａ"と、登録日時"Ｔ０"とを含んで構成される。そして、このルート情報登録要求メッセージ２０ｂは、ルートキー"Ｒ０"と、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"とを対応付けて管理するように要求するものである。
【００８１】
図７に戻り、ルート情報登録要求メッセージ２０ｂ（２０）を受信したデータ管理装置３Ｄは、ルート情報の保存（登録）処理を行う（ステップＳ１１６）。
【００８２】
図９（ｄ）は、ルート情報が保存（登録）されたデータ管理装置３Ｄのデータ記憶領域３００Ｄの例を示す。このデータ記憶領域３００Ｄに保存されたルート情報には、keyとしてサブルートキー"Ｒ０＠Ｄ１"、登録日時としての"Ｔ０"、失効日時として（"Ｒ０＠Ｄ１"がまだ失効されていないことを示す）"∞"、valueとしての識別子"ａ"がそれぞれ格納される。
【００８３】
図７に戻り、データ管理装置３Ｄは、ルート情報登録応答メッセージ２１ｂ（２１）を、データ管理装置３Ａに送信する（ステップＳ１１７）。図８（ｈ）に示すように、ルート情報登録応答メッセージ２１ｂには、ルート情報の登録処理が成功したことを示す"success"が付される。
【００８４】
図７に戻り、ルート情報登録応答メッセージ２１ｂ（２１）を受信したデータ管理装置３Ａは、ＩＤ登録応答メッセージ１１をゲートウェイ装置２に送信する（ステップＳ１１８）。図８（ｂ）に示すように、ＩＤ登録応答メッセージ１１には、ＩＤ登録処理が成功したことを示す"success"が付される。
【００８５】
図７に戻り、ゲートウェイ装置２は、ＩＤ登録応答メッセージ１１をクライアント装置１に送信し（ステップＳ１１９）、処理を終える。
【００８６】
このＩＤ登録処理により、各データ管理装置３のデータ記憶領域３００には、図９（ａ）〜（ｄ）に示すようなインデックスおよびルート情報が格納される。これらの情報は、図９（ｅ）に示すような日時"Ｔ０"における変換テーブルを仮想的に表現したものとみなすことができる。例えば、図９（ｅ）の一行目のデータは、ドメイン"Ｄ０"の列に識別子"０"が格納され、ドメイン"Ｄ１"の列に識別子"ａ"が格納されているが、これは、日時"Ｔ０"において、ある管理対象が、ドメイン"Ｄ０"では識別子"０"であることを示し、ドメイン"Ｄ１"では識別子"ａ"であることを示す。
【００８７】
次に、このＩＤ登録処理におけるゲートウェイ装置２およびデータ管理装置３が行う処理についてさらに詳細に説明する。
【００８８】
（ＩＤ登録処理におけるゲートウェイ装置の処理）
最初に、図７のＩＤ登録処理における、ゲートウェイ装置２の処理を詳細に説明する。図１０は、本実施形態に係るＩＤ登録処理におけるゲートウェイ装置２の処理の流れを示すフローチャートである。
【００８９】
まず、ゲートウェイ装置２の送受信部２４０が、ＩＤ登録要求メッセージ１０（図８（ａ）参照）をクライアント装置１から受信し、受信したＩＤ登録要求メッセージ１０をＩＤ登録転送部２１３に出力する（ステップＳ１２１）。
【００９０】
ＩＤ登録転送部２１３は、受信したＩＤ登録要求メッセージ１０の先頭の識別子（"０"）とドメイン（"Ｄ０"）を結合した値としてインデックスキー"０＠Ｄ０"を生成し、ノード決定部２１２に出力する（ステップＳ１２２）。
【００９１】
ノード決定部２１２が、コンシステントハッシュ法により担当ノードを決定し、決定した担当ノードの接続情報を、記憶部２５０内のノード情報記憶領域２００から取得して、ＩＤ登録転送部２１３に出力する（ステップＳ１２３）。
【００９２】
ＩＤ登録転送部２１３が、送受信部２４０を介してＩＤ登録要求メッセージ１０（図８（ａ）参照）を担当ノードに送信する（ステップＳ１２４）。
【００９３】
そして、ＩＤ登録転送部２１３が、送受信部２４０を介して、担当ノードからＩＤ登録応答メッセージ１１（図８（ｂ）参照）を受信する（ステップＳ１２５）。
【００９４】
続いて、ＩＤ登録転送部２１３は、送受信部２４０を介して、ＩＤ登録応答メッセージ１１を、クライアント装置１に送信して処理を終える（ステップＳ１２６）。
【００９５】
（ノード決定部によるノード決定処理）
次に、ノード決定部２１２，３１２によるノード決定処理について説明する（適宜図４参照）。図１１は、本実施形態に係るノード決定処理の流れを示すフローチャートである。なお、このノード決定部２１２，３１２は、ゲートウェイ装置２およびデータ管理装置３の双方の存在し、同様の処理を行うものである。また、ノード決定部２１２，３１２が参照するノード情報記憶領域２００も同じ情報がゲートウェイ装置２およびデータ管理装置３の双方に記憶される。
【００９６】
まず、ノード決定部２１２，３１２が、検索キー（ここでは、「ｑ」とする）を入力として呼び出される（ステップＳ１３１）。
【００９７】
次に、ノード決定部２１２，３１２が、ハッシュ関数Ｈに基づき、検索キーｑのハッシュ値Ｈ（ｑ）を計算する（ステップＳ１３２）。
【００９８】
続いて、ノード決定部２１２，３１２は、ノード情報記憶領域２００のノード情報に基づくリング（図４（ｂ）の閉じたハッシュ空間）４００を参照し、ハッシュ値Ｈ（ｑ）より大きい値で最も近いハッシュ値（ノードＩＤ）のノードを、その検索キーｑに関するデータの振り分け先のノードとして決定する（ステップＳ１３３）。
【００９９】
そして、ノード決定部２１２，３１２は、決定したノードの接続情報を、ノード情報記憶領域２００を参照して取得し、呼出し元に出力し処理を終える（ステップＳ１３４）。
【０１００】
（ＩＤ登録処理における担当ノードの処理）
次に、図７のＩＤ登録処理における、担当ノードであるデータ管理装置３Ａの処理を詳細に説明する。図１２および図１３は、本実施形態に係るＩＤ登録処理における担当ノード（データ管理装置３Ａ）の処理の流れを示すフローチャートである。
【０１０１】
図１２に示すように、まず、担当ノードであるデータ管理装置３（ここでは、データ管理装置３Ａ）の送受信部３４０が、ゲートウェイ装置２からＩＤ登録要求メッセージ１０（図８（ａ）参照）を受信し、受信したＩＤ登録要求メッセージ１０をＩＤ登録処理部３１４に出力する（ステップＳ１４１）。
【０１０２】
次に、ルートキー生成部３１３が、ルートキー（ここでは、「ｒ」とする）を生成する（ステップＳ１４２）。例えば、図７のステップＳ１０４のように、データ管理装置３Ａのルートキー生成部３１３が、擬似乱数生成器等を用いてルートキーｒとして"Ｒ０"を生成する。
【０１０３】
続いて、ＩＤ登録処理部３１４は、ＩＤ登録要求メッセージ１０内に、識別子，ドメイン，登録日時の組が存在するか否かを判定する（ステップＳ１４３）。そして、ＩＤ登録処理部３１４は、識別子，ドメイン，登録日時の組が存在しない場合には（ステップＳ１４３→Ｎｏ）、図１３のステップＳ１５２に進む。一方、識別子，ドメイン，登録日時の組が存在する場合には（ステップＳ１４３→Ｙｅｓ）、識別子，ドメイン，登録日時の組のうちの１つを選択し、次のステップＳ１４４に進む。
【０１０４】
ステップＳ１４４において、ＩＤ登録処理部３１４は、選択した１組の情報について、識別子とドメインとを結合した値（例えば、"０＠Ｄ０"）をインデックスキーとして生成し、ノード決定部３１２に出力する。
【０１０５】
次に、ノード決定部３１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ登録処理部３１４に出力する（ステップＳ１４５）。
【０１０６】
そして、ＩＤ登録処理部３１４は、インデックスキー、ルートキー、登録日時のパラメータを含んだインデックス登録要求メッセージ３０（図８（ｅ）参照）を、送受信部３４０を介して、インデックスノードに送信する（ステップＳ１４６）。
【０１０７】
続いて、ＩＤ登録処理部３１４は、インデックスノードからインデックス登録応答メッセージ３１（図８（ｆ）参照）を受信する（ステップＳ１４７）。
【０１０８】
図１３に移り、ＩＤ登録処理部３１４は、ルートキーとドメインとを結合した値（例えば、"Ｒ０＠Ｄ０"）をサブルートキーとして生成し、ノード決定部３１２に出力する（ステップＳ１４８）。
【０１０９】
次に、ノード決定部３１２は、コンシステントハッシュ法によりルートノードを決定し、決定したルートノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ登録処理部３１４に出力する（ステップＳ１４９）。
【０１１０】
続いて、ＩＤ登録処理部３１４は、サブルートキー、識別子、登録日時のパラメータを含んだルート情報登録要求メッセージ２０（図８（ｃ）（ｇ）参照）を、送受信部３４０を介して、ルートノードに送信する（ステップＳ１５０）。
【０１１１】
そして、ＩＤ登録処理部３１４は、ルートノードからルート情報登録応答メッセージ２１（図８（ｄ）（ｈ）参照）を受信する（ステップＳ１５１）。
【０１１２】
図１２のステップＳ１４３に戻り、ＩＤ登録処理部３１４は、識別子，ドメイン，登録日時の組が存在しない場合に（ステップＳ１４３→Ｎｏ）、図１３のステップＳ１５２に進む。そして、ＩＤ登録処理部３１４は、全ての処理が成功したか否かを判定する（ステップＳ１５２）。この判定は、例えば、ＩＤ登録処理部３１４が、所定時間以内に、要求メッセージに対する正しい応答がなされたか否かで判定する。そして、ＩＤ登録処理部３１４は、全ての処理が成功した場合には（ステップＳ１５２→Ｙｅｓ）、送受信部３４０を介して、ゲートウェイ装置２へＩＤ登録応答メッセージ１１（図８（ｂ）参照）を送信して処理を終了する（ステップＳ１５３）。一方、全ての処理が成功した場合でないときは（ステップＳ１５２→Ｎｏ）、ＩＤ登録処理部３１４は、送受信部３４０を介して、ゲートウェイ装置２にエラーメッセージを送信して処理を終了する（ステップＳ１５４）。
【０１１３】
（インデックス保存処理）
次に、図７のＩＤ登録処理のステップＳ１１２で行われる、データ管理装置３（ここでは、データ管理装置３Ｃ）のインデックスの保存（登録）処理を詳細に説明する。図１４は、本実施形態に係るインデックス保存処理におけるデータ管理装置３の処理の流れを示すフローチャートである。
【０１１４】
まず、送受信部３４０が、他のデータ管理装置３からインデックス登録要求メッセージ３０を受信すると、その受信したインデックス登録要求メッセージ３０（図８（ｅ）参照）をインデックス登録処理部３１８に出力する（ステップＳ１６１）。
【０１１５】
次に、インデックス登録処理部３１８は、インデックス登録要求メッセージ３０から、インデックスキー（ここでは"ｋ"とする），ルートキー（ここでは"ｒ"とする），登録日時（ここでは"ｔ"とする）を取得し、データ管理部３２１に出力する（ステップＳ１６２）。
【０１１６】
データ管理部３２１は、自身のデータ記憶領域３００のインデックスに、keyとしてインデックスキー"ｋ"、登録日時"ｔ"、失効日時として"∞"、valueとしてルートキー"ｒ"となる行と追加する（ステップＳ１６３）。
【０１１７】
そして、インデックス登録処理部３１８は、インデックスが保存されたことを示す"success"を含むインデックス登録応答メッセージ３１（図８（ｆ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ１６４）。
【０１１８】
（ルート情報保存処理）
次に、図７のＩＤ登録処理のステップＳ１０８，Ｓ１１６で行われる、データ管理装置３（ここでは、データ管理装置３Ｂ，３Ｄ）のルート情報の保存（登録）処理を詳細に説明する。図１５は、本実施形態に係るルート情報保存処理におけるデータ管理装置３の処理の流れを示すフローチャートである。
【０１１９】
まず、送受信部３４０が、他のデータ管理装置３からルート情報登録要求メッセージ２０（図８（ｃ）（ｇ）参照）を受信すると、その受信したルート情報登録要求メッセージ２０をルート情報登録処理部３１９に出力する（ステップＳ１７１）。
【０１２０】
次に、ルート情報登録処理部３１９は、ルート情報登録要求メッセージ２０から、サブルートキー（ここでは"ｓ"とする），識別子（ここでは"ｉ"とする），登録日時（ここでは"ｔ"とする）を取得し、データ管理部３２１に出力する（ステップＳ１７２）。
【０１２１】
データ管理部３２１は、自身のデータ記憶領域３００のルート情報に、keyとしてサブルートキー"s"、登録日時"ｔ"、失効日時として"∞"、valueとして識別子"ｉ"となる行を追加する（ステップＳ１７３）。
【０１２２】
そして、ルート情報登録処理部３１９は、ルート情報が保存されたことを示すルート情報登録応答メッセージ２１（図８（ｄ）（ｈ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ１７４）。
【０１２３】
このようにすることで、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１から取得したＩＤ登録要求メッセージ１０（図８（ａ）参照）に含まれる登録情報を、ゲートウェイ装置２を介して、インデックスおよびルート情報という保存形式により、分散させてデータ管理装置３に保存することができる。
【０１２４】
なお、本例では、「識別子」，「ドメイン」，「登録日時」の組となる登録情報について、図８（ａ）に示すように、第１の登録情報（符号１０−１）と第２の登録情報（符号１０−２）の２組を登録する場合を例に説明した。しかし、本発明は、登録情報について２組に限定されるものではなく、２組以上であれば、例えば、第３の登録情報、第４の登録情報、第５の登録情報のように、第ｉ（ｉ番目）の登録情報までを含めて本実施形態に係るＩＤ登録処理で、各データ管理装置３に登録することもできる。
【０１２５】
その場合、ゲートウェイ装置２から、ｉ個の登録情報が含まれるＩＤ登録要求メッセージ１０を受信した第１のデータ管理装置３（３Ａ）のノード決定部３１２は、第ｉ（ｉ番目：ｉは１以上の整数）の登録情報についてＩＤ登録処理部３１４が生成した第ｉインデックスキーにハッシュ関数を適用してハッシュ値を算出し、ノード情報のノードＩＤを参照して決定したデータ管理装置３として、第ｉインデックスの登録先を、（２×ｉ−１）番目のデータ管理装置３に決定することができる。また、第１のデータ管理装置３（３Ａ）のノード決定部３１２は、第ｉ（ｉ番目）の登録情報についてＩＤ登録処理部３１４が生成した第ｉ（ｉ番目）サブルートキーにハッシュ関数を適用してハッシュ値を算出し、ノード情報のノードＩＤを参照して決定したデータ管理装置３として、第ｉルート情報の登録先を、（２×ｉ）番目のデータ管理装置３に決定することができる。
つまり、本実施形態に係る分散ＩＤ管理システム５は、ｉ個の登録情報が含まれるＩＤ登録要求メッセージ１０を受信した場合であっても、ｉ個の登録情報を、インデックスおよびルート情報という形式で分散して複数のデータ管理装置３に保存することができる。
【０１２６】
＜ＩＤ変換処理＞
次に、図１６〜図２０を参照して、図７に示したＩＤ登録処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理について説明する。
【０１２７】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン"Ｄ０"の日時"Ｔ１"における識別子"０"を、ドメイン"Ｄ１"の同日時"Ｔ１"における識別子へ変換する処理（つまり、ドメイン"Ｄ０"の日時"Ｔ１"における識別子"０"に対応する、ドメイン"Ｄ１"の同日時"Ｔ１"における識別子を検索する処理）、について説明する。ここで、"Ｔ１"は、"Ｔ０"よりも未来の日時を示すものとする。
【０１２８】
（ＩＤ変換処理の全体の流れ）
図１６は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ変換処理の全体の流れを示すシーケンス図である。
【０１２９】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ａ（４０）をゲートウェイ装置２に送信する（ステップＳ２０１）。
【０１３０】
図１７（ａ）は、ＩＤ変換要求メッセージ４０を例示する図である。図１７（ａ）に示すように、ＩＤ変換要求メッセージ４０は、「変換元識別子」，「変換元ドメイン」，「変換元日時」，「変換先ドメイン」，「変換先日時」のパラメータを含んで構成される。図１７（ａ）に例示するＩＤ変換要求メッセージ４０ａ（４０）は、変換元であるドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ１"における識別子（変換元識別子）"０"を、ドメイン（変換先ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ１"における識別子へ変換する（変換先となる識別子を検索する）処理を要求するものである。
【０１３１】
図１６に戻り、ＩＤ変換要求メッセージ４０ａ（４０）を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ２０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"０＠Ｄ０"に対応するノードであるデータ管理装置３Ａが、インデックスノードとして決定される。
【０１３２】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ａ（４０）を、インデックスノードとして決定したデータ管理装置３Ａに送信する（ステップＳ２０３）。
【０１３３】
ＩＤ変換要求メッセージ４０ａ（４０）を受信したデータ管理装置３Ａは、ルートキーの取得処理を行う（ステップＳ２０４）。ルートキーの取得は、インデックスキー（"０＠Ｄ０"）をキーとして、データ格納領域３００Ａ内のインデックス（図９（ａ）参照）を検索し、変換元日時Ｔ１が登録日時と失効日時の間に含まれる行から行われる。ここでは、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０１３４】
次に、データ管理装置３Ａは、ルートノードの決定処理を行う（ステップＳ２０５）。ここでは、サブルートキー"Ｒ０＠Ｄ１"に対応するノードとして、データ管理装置３Ｄが、ルートノードとして決定される。
【０１３５】
続いて、データ管理装置３Ａは、ＩＤ取得要求メッセージ５０ａ（５０）を、ルートノードとして決定したデータ管理装置３Ｄに送信する（ステップＳ２０６）。
【０１３６】
図１７（ｃ）は、ＩＤ取得要求メッセージ５０を例示する図である。図１７（ｃ）に示すように、ＩＤ取得要求メッセージ５０は、「サブルートキー」，「変換先日時」のパラメータを含んで構成される。図１７（ｃ）に例示するＩＤ取得要求メッセージ５０ａ（５０）は、サブルートキー"Ｒ０＠Ｄ１"に紐付く識別子の内、変換先日時"Ｔ１"で有効なものの取得を要求するものであることを示す。
【０１３７】
図１６に戻り、ＩＤ取得要求メッセージ５０ａ（５０）を受信したデータ管理装置３Ｄは、ＩＤ（識別子）の取得処理を行う（ステップＳ２０７）。ＩＤ（識別子）の取得は、サブルートキー"Ｒ０＠Ｄ１"をキーとして、データ格納領域３００Ｄ内のルート情報（図９（ｄ）参照）を検索し、変換先日時Ｔ１が、登録日時と失効日時の間に含まれるような行から行われる。ここでは、図９（ｄ）に示すルート情報から、識別子として"ａ"が取得される。
【０１３８】
次に、データ管理装置３Ｄは、ＩＤ取得応答メッセージ５１ａ（５１）を生成し、データ管理装置３Ａに送信する（ステップＳ２０８）。図１７（ｄ）に示すように、ＩＤ取得応答メッセージ５１ａには、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０１３９】
続いて、データ管理装置３Ａは、ＩＤ変換応答メッセージ４１ａ（４１）を生成し、ゲートウェイ装置２に送信する（ステップＳ２０９）。図１７（ｂ）に示すように、ＩＤ変換応答メッセージ４１ａには、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０１４０】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ａ（４１）をクライアント装置１に送信し、処理を終える（ステップＳ２１０）。
【０１４１】
次に、このＩＤ変換処理におけるゲートウェイ装置２およびデータ管理装置３が行う処理についてさらに詳細に説明する。
【０１４２】
（ＩＤ変換処理におけるゲートウェイ装置の処理）
最初に、図１６のＩＤ変換処理における、ゲートウェイ装置２の処理の詳細を説明する。図１８は、本実施形態に係るＩＤ変換処理におけるゲートウェイ装置２の処理の流れを示すフローチャートである。
【０１４３】
まず、ゲートウェイ装置２の送受信部２４０が、ＩＤ変換要求メッセージ４０（図１７（ａ）参照）をクライアント装置１から受信し、受信したＩＤ変換要求メッセージ４０をＩＤ変換転送部２１４に出力する（ステップＳ２２１）。
【０１４４】
ＩＤ変換転送部２１４は、受信したＩＤ変換要求メッセージ４０の変換元識別子"０"と変換元ドメイン"Ｄ０"を結合した値としてインデックスキー"０＠Ｄ０"を生成し、ノード決定部２１２に出力する（ステップＳ２２２）。
【０１４５】
ノード決定部２１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部２５０内のノード情報記憶領域２００から取得して、ＩＤ変換転送部２１４に出力する（ステップＳ２２３）。
【０１４６】
ＩＤ変換転送部２１４は、送受信部２４０を介して、ＩＤ変換要求メッセージ４０を、決定したインデックスノードに送信する（ステップＳ２２４）。
【０１４７】
そして、ＩＤ変換転送部２１４は、送受信部２４０を介して、インデックスノードからＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を受信する（ステップＳ２２５）。
【０１４８】
続いて、ＩＤ変換転送部２１４は、送受信部２４０を介して、ＩＤ変換応答メッセージ４１を、クライアント装置１に送信して処理を終える（ステップＳ２２６）。
【０１４９】
（ＩＤ変換処理におけるデータ管理装置の処理）
次に、図１６のＩＤ変換処理における、データ管理装置３（ここでは、データ管理装置３Ａ）の処理を詳細に説明する。図１９は、本実施形態に係るＩＤ変換処理におけるデータ管理装置３（３Ａ）の処理の流れを示すフローチャートである。
【０１５０】
まず、データ管理装置３（ここでは、データ管理装置３Ａ）の送受信部３４０が、ゲートウェイ装置２からＩＤ変換要求メッセージ４０（図１７（ａ）参照）を受信し、ＩＤ変換処理部３１５に出力する（ステップＳ２３１）。
【０１５１】
次に、ＩＤ変換処理部３１５は、ＩＤ変換要求メッセージ４０に含まれる、変換元識別子（ここでは、「ｉ」とする），変換元ドメイン（ここでは、「ｄ」とする），変換元日時（ここでは、「ｔ」とする），変換先ドメイン（ここでは、「ｄ'」とする），変換先日時（ここでは「ｔ'」とする）を取得する。ＩＤ変換処理部３１５は、変換元識別子ｉと変換元ドメインｄとを結合した値（ｉ＠ｄ）としてインデックスキーを生成する。具体的には、ＩＤ変換処理部３１５は、インデックスキー"０＠Ｄ０"を生成する。そして、ＩＤ変換処理部３１５は、生成したインデックスキー（ｉ＠ｄ）と、変換元日時ｔとを、データ管理部３２１に出力する（ステップＳ２３２）。
【０１５２】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、図９（ａ）のデータ記憶領域３００Ａ）に記憶されたインデックスから、条件［key＝ｉ＠ｄ かつ 登録日時≦ｔ＜失効日時］を満たす行を検索する（ステップＳ２３３）。
【０１５３】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ２３４）、条件を満たす行が存在しない場合には（ステップＳ２３４→Ｎｏ）、ステップＳ２４２に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ２３４→Ｙｅｓ）、次のステップＳ２３５へ進む。
【０１５４】
ステップＳ２３５において、データ管理部３２１は、条件を満たす行のvalueの値からルートキー（「ｒ」）を取得し、ＩＤ変換処理部３１５に出力する。ここでは、データ管理部３２１が、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"を取得し、ＩＤ変換処理部３１５に出力する。
【０１５５】
次に、ＩＤ変換処理部３１５は、ルートキーｒと変換先ドメインｄ'を結合した値（ｒ＠ｄ'）としてサブルートキーを生成する。ここでは、ＩＤ変換処理部３１５は、サブルートキー"Ｒ０＠Ｄ１"を生成する。そして、ＩＤ変換処理部３１５は、生成したサブルートキー（ｒ＠ｄ'）をノード決定部３１２に出力する（ステップＳ２３６）。
【０１５６】
続いて、ノード決定部３１２が、コンシステントハッシュ法によりルートノードとなるノードを決定し、決定したルートノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ変換処理部３１５に出力する（ステップＳ２３７）。
【０１５７】
ＩＤ変換処理部３１５は、サブルートキー（ｒ＠ｄ'）と変換先日時ｔ'とを含むＩＤ取得要求メッセージ５０（図１７（ｃ）参照）を生成し、送受信部３４０を介して、ルートノードに送信する（ステップＳ２３８）。
【０１５８】
そして、ＩＤ変換処理部３１５は、ルートノードから、送受信部３４０を介して、変換先のＩＤ（識別子）を含むＩＤ取得応答メッセージ５１（図１７（ｄ）参照）を受信する（ステップＳ２３９）。
【０１５９】
ＩＤ変換処理部３１５は、ＩＤ（識別子）の取得に成功したか否かを判定し（ステップＳ２４０）、成功していない場合には（ステップＳ２４０→Ｎｏ）、ステップＳ２４２に進む。一方、ＩＤ変換処理部３１５は、ＩＤ（識別子）の取得に成功した場合には（ステップＳ２４０→Ｙｅｓ）、次のステップＳ２４１へ進む。
【０１６０】
ステップＳ２４１において、ＩＤ変換処理部３１５は、ＩＤ取得応答メッセージ５１から取得したＩＤ（識別子）を含む、ＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を生成し、送受信部３４０を介して、ゲートウェイ装置２に送信し、処理を終える。
【０１６１】
また、ステップＳ２３４において条件を満たす行がない場合（ステップＳ２３４→Ｎｏ）、または、ステップＳ２４０においてＩＤ（識別子）の取得に成功していない場合（ステップＳ２４０→Ｎｏ）には、ＩＤ変換処理部３１５が、エラーメッセージを生成し、送受信部３４０を介して、ゲートウェイ装置２に送信し、処理を終える（ステップＳ２４２）。
【０１６２】
（ＩＤ取得処理）
次に、図１６のＩＤ変換処理のステップＳ２０７で行われる、ＩＤ取得処理を詳細に説明する。図２０は、本実施形態に係るＩＤ取得処理におけるデータ管理装置３（ここでは、データ管理装置３Ｄ）の処理の流れを示すフローチャートである。
【０１６３】
まず、送受信部３４０が、他のデータ管理装置３からＩＤ取得要求メッセージ５０（図１７（ｃ）参照）を受信すると、その受信したＩＤ取得要求メッセージ５０をＩＤ取得処理部３１７に出力する（ステップＳ２５１）。
【０１６４】
次に、ＩＤ取得処理部３１７は、ＩＤ取得要求メッセージ５０から、サブルートキー（ｒ＠ｄ）と、変換先日時ｔ'とを取得し、データ管理部３２１に出力する（ステップＳ２５２）。
【０１６５】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、データ記憶領域３００Ｄ）に記憶されたルート情報から、条件［key＝ｒ＠ｄ かつ 登録日時≦ｔ'＜失効日時］を満たす行を検索する（ステップＳ２５３）。
【０１６６】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ２５４）、条件を満たす行が存在しない場合には（ステップＳ２５４→Ｎｏ）、ステップＳ２５７に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ２５４→Ｙｅｓ）、次のステップＳ２５５へ進む。
【０１６７】
ステップＳ２５５において、データ管理部３２１は、条件を満たす行のvalueの値から識別子ｉを取得し、ＩＤ取得処理部３１７に出力する。ここでは、データ管理部３２１が、図９（ｄ）に示すルート情報から、変換先の識別子（変換先識別子）ｉとして"ａ"を取得し、ＩＤ取得処理部３１７に出力する。
【０１６８】
次に、ＩＤ取得処理部３１７は、変換先の識別子ｉ（ここでは"ａ"）を含むＩＤ取得応答メッセージ５１（図１７（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ２５６）。
【０１６９】
また、ステップＳ２５４において、条件を満たす行が存在しない場合には（ステップＳ２５４→Ｎｏ）、ＩＤ取得処理部３１７は、エラーメッセージを生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ２５７）。
【０１７０】
このようにすることで、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１から取得したＩＤ変換要求メッセージ４０（図１７（ａ）参照）に含まれる「変換元識別子」「変換元ドメイン」「変換元日時」「変換先ドメイン」「変換先日時」のパラメータを用いて、「変換元識別子」を「変換先識別子」に変換する、つまり、「変換先識別子」を検索することができる。
【０１７１】
＜ＩＤ更新処理＞
次に、図２１〜図２７を参照して、図７に示したＩＤ登録処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの更新を要求（ＩＤ更新要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ更新処理について説明する。
【０１７２】
ここでは、クライアント装置１が要求するＩＤ更新処理の例として、ドメイン（更新対象ドメイン）"Ｄ０"の日時（更新対象日時）"Ｔ１"における識別子（更新対象識別子）"０"を、日時（更新日時）"Ｔ２"以降は識別子（更新後識別子）"９"に置き換える（更新する）処理について説明する。ここで、"Ｔ２"は"Ｔ１"よりも未来の日時を示すものとする。
【０１７３】
（ＩＤ更新処理の全体の流れ）
図２１は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理の全体の流れを示すシーケンス図である。
【０１７４】
まず、クライアント装置１は、ＩＤ更新要求メッセージ６０をゲートウェイ装置２に送信する（ステップＳ３０１）。
【０１７５】
図２２（ａ）は、ＩＤ更新要求メッセージ６０を例示する図である。図２２（ａ）に示すように、ＩＤ更新要求メッセージ６０は、「更新対象識別子」，「更新対象ドメイン」，「更新対象日時」，「更新後識別子」，「更新日時」のパラメータを含んで構成される。図２２（ａ）に例示するＩＤ更新要求メッセージ６０は、ドメイン（更新対象ドメイン）"Ｄ０"の日時（更新対象日時）"Ｔ１"における識別子（更新対象識別子）"０"を更新元として、日時（更新日時）"Ｔ２"以降は識別子（更新後識別子）"９"に置き換える（更新する）処理を要求するものである。
【０１７６】
図２１に戻り、ＩＤ更新要求メッセージ６０を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ３０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"０＠Ｄ０"に対応するノードであるデータ管理装置３Ａが、インデックスノードとして決定される。
【０１７７】
続いて、ゲートウェイ装置２は、ＩＤ更新要求メッセージ６０を、インデックスノードとして決定したデータ管理装置３Ａに送信する（ステップＳ３０３）。
【０１７８】
ＩＤ更新要求メッセージ６０を受信したデータ管理装置３Ａは、ルートキーの取得処理を行う（ステップＳ３０４）。ルートキーの取得は、インデックスキー（"０＠Ｄ０"）をキーとして、データ格納領域３００Ａ内のインデックス（図９（ａ）参照）を検索し、更新対象日時"Ｔ１"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０１７９】
次に、データ管理装置３Ａは、インデックスの失効処理を行う（ステップＳ３０５）。このインデックスの失効処理は、ステップＳ３０４において、インデックスから、ルートキー"Ｒ０"を取得した行の失効日時を更新日時で更新することにより行う。
【０１８０】
図２３（ａ）に、インデックスの失効処理後のデータ管理装置３Ａのデータ記憶領域３００Ａの例を示す。ここでは、インデックス"０＠Ｄ０"に対応する行において、失効日時が"∞"から"Ｔ２"に更新されている。
【０１８１】
図２１に戻り、次に、データ管理装置３Ａは、更新対象のルートノードの決定処理を行う（ステップＳ３０６）。ここでは、ノード決定部３１２が、サブルートキー"Ｒ０＠Ｄ０"に対応するノードとして、データ管理装置３Ｂを、ルートノードとして決定する。
【０１８２】
続いて、データ管理装置３Ａは、ルート情報更新要求メッセージ７０を、ルートノードとして決定したデータ管理装置３Ｂに送信する（ステップＳ３０７）。
【０１８３】
図２２（ｃ）は、ルート情報更新要求メッセージ７０を例示する図である。図２２（ｃ）に示すように、ルート情報更新要求メッセージ７０は、「サブルートキー」，「更新後識別子」，「更新日時」のパラメータを含んで構成される。図２２（ｃ）に示すルート情報更新要求メッセージ７０は、日時（更新日時）"Ｔ２"以降、サブルートキー"Ｒ０＠Ｄ０"に紐付く識別子（更新後識別子）として"９"を用いるように更新することを要求するものである。
【０１８４】
図２１に戻り、ルート情報更新要求メッセージ７０を受信したデータ管理装置３Ｂは、ルート情報の更新処理を行う（ステップＳ３０８）。
【０１８５】
図２３（ｂ）に、ルート情報更新後のデータ管理装置３Ｂのデータ記憶領域３００Ｂの例を示す。ここでは、サブルートキー"Ｒ０＠Ｄ０"に対応する行において、登録日時"Ｔ０"の行では、失効日時が"∞"から更新日時である"Ｔ２"に更新されている。また、サブルートキー"Ｒ０＠Ｄ０"の新たな行が追加され、keyとしてサブルートキー"Ｒ０＠Ｄ０"、登録日時として更新後日時"Ｔ２"、失効日時として"∞"、valueとして識別子（更新後識別子）"９"が、それぞれ格納される。
【０１８６】
図２１に戻り、データ管理装置３Ｂは、ルート情報更新応答メッセージ７１（図２２（ｄ）参照）を、データ管理装置３Ａに送信する（ステップＳ３０９）。図２２（ｄ）に示すように、ルート情報更新応答メッセージ７１には、ルート情報の更新処理が成功したことを示す"success"が付される。
【０１８７】
次に、データ管理装置３Ａは、インデックスノードの決定処理を行う（ステップＳ３１０）。ここでは、例えば、インデックスキー"９＠Ｄ０"に対応するノードであるデータ管理装置３Ｅが、インデックスノードとして決定される。
【０１８８】
続いて、データ管理装置３Ａは、インデックス登録要求メッセージ３０ｂ（３０）を、インデックスノードとして決定したデータ管理装置３Ｅに送信する（ステップＳ３１１）。
【０１８９】
図２２（ｅ）は、インデックス登録要求メッセージ３０を例示する図である。図２２（ｅ）に例示するインデックス登録要求メッセージ３０ｂは、ルートキー"Ｒ０"と、ドメイン"Ｄ０"の登録日時"Ｔ２"における識別子"９"とを対応付けて管理するように要求するものである。
【０１９０】
図２１に戻り、インデックス登録要求メッセージ３０ｂを受信したデータ管理装置３Ｅは、インデックスの保存処理を行う（ステップＳ３１２）。
【０１９１】
図２３（ｅ）は、インデックスが保存されたデータ管理装置３Ｅのデータ記憶領域３００Ｅの例を示す。このデータ記憶領域３００Ｅに保存されたインデックスには、keyとしてのインデックスキー"９＠Ｄ０"、登録日時としての"Ｔ２"、失効日時として（"９＠Ｄ０"がまだ失効されていないことを示す）"∞"、valueとしてのルートキー"Ｒ０"がそれぞれ格納される。
【０１９２】
図２１に戻り、データ管理装置３Ｅは、インデックス登録応答メッセージ３１ｂ（３１）を生成し、データ管理装置３Ａに送信する（ステップＳ３１３）。図２２（ｆ）に示すように、インデックス登録応答メッセージ３１ｂは、インデックスの登録処理が成功したことを示す"success"が付される。
【０１９３】
インデックス登録応答メッセージ３１ｂを受信したデータ管理装置３Ａは、ＩＤ更新応答メッセージ６１を生成し、ゲートウェイ装置２に送信する（ステップＳ３１４）。図２２（ｂ）に示すように、ＩＤ更新応答メッセージ６１には、ＩＤ更新処理が成功したことを示す"success"が付される。
【０１９４】
そして、ゲートウェイ装置２は、ＩＤ更新応答メッセージ６１をクライアント装置１に送信し（ステップＳ３１５）、処理を終える。
【０１９５】
このＩＤ更新処理により、各データ管理装置３のデータ記憶領域３００には、図２３（ａ）〜（ｅ）に示すような値が格納される。これらの値は、図２３（ｆ）に示すような日時"Ｔ２"における変換テーブルを仮想的に実現したものとみなすことができる。例えば、図２３（ｆ）の一行目のデータは、ドメイン"Ｄ０"の列に識別子"９"が格納され、ドメイン"Ｄ１"の列に識別子"ａ"が格納されているが、これは、日時"Ｔ２"において、ある管理対象が、ドメイン"Ｄ０"では識別子"９"を持ち、ドメイン"Ｄ１"では識別子"ａ"を持つことを示す。
【０１９６】
次に、このＩＤ更新処理におけるゲートウェイ装置２およびデータ管理装置３が行う処理についてさらに詳細に説明する。
【０１９７】
（ＩＤ更新処理におけるゲートウェイ装置の処理）
次に、図２１のＩＤ更新処理における、ゲートウェイ装置２の処理の詳細を説明する。
図２４は、本実施形態に係るＩＤ更新処理におけるゲートウェイ装置２の処理の流れを示すフローチャートである。
【０１９８】
まず、ゲートウェイ装置２の送受信部２４０が、ＩＤ更新要求メッセージ６０（図２２（ａ）参照）をクライアント装置１から受信し、受信したＩＤ更新要求メッセージ６０をＩＤ更新転送部２１５に出力する（ステップＳ３２１）。
【０１９９】
ＩＤ更新転送部２１５は、受信したＩＤ更新要求メッセージ６０の更新対象識別子"０"と更新対象ドメイン"Ｄ０"を結合した値としてインデックスキー"０＠Ｄ０"を生成し、ノード決定部２１２に出力する（ステップＳ３２２）。
【０２００】
ノード決定部２１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部２５０内のノード情報記憶領域２００から取得して、ＩＤ更新転送部２１５に出力する（ステップＳ３２３）。
【０２０１】
ＩＤ更新転送部２１５は、送受信部２４０を介して、ＩＤ更新要求メッセージ６０を、決定したインデックスノードに送信する（ステップＳ３２４）。
【０２０２】
そして、ＩＤ更新転送部２１５は、送受信部２４０を介して、インデックスノードから、ＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を受信する（ステップＳ３２５）。
【０２０３】
続いて、ＩＤ更新転送部２１５は、送受信部２４０を介して、ＩＤ更新応答メッセージ６１を、クライアント装置１に送信して処理を終える（ステップＳ３２６）。
【０２０４】
（ＩＤ更新処理におけるデータ管理装置の処理）
次に、図２１のＩＤ更新処理における、データ管理装置３（ここでは、データ管理装置３Ａ）の処理の詳細に説明する。図２５および図２６は、本実施形態に係るＩＤ更新処理におけるデータ管理装置３（３Ａ）の処理の流れを示すフローチャートである。
【０２０５】
図２５において、まず、データ管理装置３（ここでは、データ管理装置３Ａ）の送受信部３４０が、ゲートウェイ装置２からＩＤ更新要求メッセージ６０（図２２（ａ）参照）を受信し、ＩＤ更新処理部３１６に出力する（ステップＳ３３１）。
【０２０６】
次に、ＩＤ更新処理部３１６は、ＩＤ更新要求メッセージ６０に含まれる、更新対象識別子（ここでは、「ｉ」とする），更新対象ドメイン（ここでは、「ｄ」とする），更新対象日時（ここでは、「ｔ」とする），更新後識別子（ここでは、「ｉ'」とする），更新日時（ここでは、「ｔ'」とする）を取得する。ＩＤ更新処理部３１６は、更新対象識別子ｉと更新対象ドメインｄとを結合した値（ｉ＠ｄ）としてインデックスキーを生成する。ここでは、ＩＤ更新処理部３１６は、インデックスキー"０＠Ｄ０"を生成する。そして、ＩＤ更新処理部３１６は、生成したインデックスキー（ｉ＠ｄ）と、更新対象日時ｔとを、データ管理部３２１に出力する（ステップＳ３３２）。
【０２０７】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、データ記憶領域３００Ａ）に記憶されたインデックスから、条件［key＝ｉ＠ｄ かつ 登録日時≦ｔ＜失効日時］を満たす行を検索する（ステップＳ３３３）。
【０２０８】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ３３４）、条件を満たす行が存在しない場合には（ステップＳ３３４→Ｎｏ）、図２６のステップＳ３４７に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ３３４→Ｙｅｓ）、次のステップＳ３３５へ進む。
【０２０９】
ステップＳ３３５において、データ管理部３２１は、条件を満たす行のvalueの値からルートキー（「ｒ」）を取得し、ＩＤ更新処理部３１６に出力する。ここでは、データ管理部３２１が、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"を取得し、ＩＤ更新処理部３１６に出力する。
【０２１０】
次に、ＩＤ更新処理部３１６は、データ管理部３２１を介して、当該行の失効日時を"∞"から更新日時ｔ'に更新する（ステップＳ３３６）。
【０２１１】
続いて、ＩＤ更新処理部３１６は、ルートキーｒと更新対象ドメインｄとを結合した値（ｒ＠ｄ）としてサブルートキーを生成する。ここでは、ＩＤ更新処理部３１６は、サブルートキー"Ｒ０＠Ｄ０"を生成する。そして、ＩＤ更新処理部３１６は、生成したサブルートキー（ｒ＠ｄ）をノード決定部３１２に出力する（ステップＳ３３７）。
【０２１２】
そして、ノード決定部３１２は、コンシステントハッシュ法によりルートノードとなるノードを決定し、決定したルートノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ更新処理部３１６に出力する（ステップＳ３３８）。
【０２１３】
ＩＤ更新処理部３１６は、サブルートキー（ｒ＠ｄ）、更新後識別子ｉ'、更新日時ｔ'を含むルート情報更新要求メッセージ７０（図２２（ｃ）参照）を生成し、送受信部３４０を介して、ルートノードに送信する（ステップＳ３３９）。
【０２１４】
そして、ＩＤ更新処理部３１６は、ルートノードから、送受信部３４０を介して、ルート情報更新応答メッセージ７１（図２２（ｄ）参照）を受信する（ステップＳ３４０）。
【０２１５】
図２６に移り、ＩＤ更新処理部３１６は、更新後識別子ｉ'と更新対象ドメインｄとを結合した値（ｉ'＠ｄ）としてインデックスキーを生成する。ここでは、ＩＤ更新処理部３１６は、インデックスキー"９＠Ｄ０"を生成する。そして、ＩＤ更新処理部３１６は、生成したインデックスキー"９＠Ｄ０"をノード決定部３１２に出力する（ステップＳ３４１）。
【０２１６】
次に、ノード決定部３１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ更新処理部３１６に出力する（ステップＳ３４２）。
【０２１７】
そして、ＩＤ更新処理部３１６は、インデックス登録処理部３１８を介して、インデックス登録要求メッセージ３０ｂ（図２２（ｅ）参照）を生成し、インデックスノードへ送信する（ステップＳ３４３）。このインデックス登録要求メッセージ３０ｂには、インデックスキー"９＠Ｄ０"、ルートキー"Ｒ０"、登録日時"Ｔ２"の情報が含まれる。
【０２１８】
続いて、ＩＤ更新処理部３１６は、インデックスノードから、受信部３４０を介して、インデックス登録応答メッセージ３１ｂ（図２２（ｆ）参照）を受信する（ステップＳ３４４）。
【０２１９】
次に、ＩＤ更新処理部３１６は、ＩＤ更新処理に関する全ての処理が成功したが否かを判定し（ステップＳ３４５）、１つでも成功していない処理がある場合には（ステップＳ３４５→Ｎｏ）、ステップＳ３４７に進む。一方、ＩＤ更新処理部３１６は、全ての処理が成功した場合には（ステップＳ３４５→Ｙｅｓ）、次のステップＳ３４６に進む。
【０２２０】
ステップＳ３４６において、ＩＤ更新処理部３１６は、送受信部３４０を介して、ゲートウェイ装置２へＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を送信して、処理を終了する。
【０２２１】
また、図２５のステップＳ３３４において条件を満たす行が存在しない場合（ステップＳ３３４→Ｎｏ）、または、図２６のステップＳ３４５において１つでも成功していない処理がある場合（ステップＳ３４５→Ｎｏ）には、ＩＤ更新処理部３１６は、ゲートウェイ装置２へエラーメッセージを送信して、処理を終了する（ステップＳ３４７）。
【０２２２】
（ルート情報更新処理）
次に、図２１のＩＤ更新処理のステップＳ３０８で行われる、データ管理装置３（ここでは、データ管理装置３Ｂ）のルート情報更新処理を詳細に説明する。図２７は、本実施形態に係るＩＤ更新処理におけるデータ管理装置３（３Ｂ）のルート情報更新処理の流れを示すフローチャートである。
【０２２３】
まず、送受信部３４０が、他のデータ管理装置３からルート情報更新要求メッセージ７０（図２２（ｃ）参照）を受信すると、その受信したルート情報更新要求メッセージ７０をルート情報更新処理部３２０に出力する（ステップＳ３５１）。
【０２２４】
次に、ルート情報更新処理部３２０は、ルート情報更新要求メッセージ７０から、サブルートキー（ｒ＠ｄ）と、更新後識別子（ｉ'）と、更新日時（ｔ'）とを取得し、データ管理部３２１に出力する（ステップＳ３５２）。
【０２２５】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、データ記憶領域３００Ｂ）に記憶されたルート情報から、条件［key＝ｒ＠ｄ かつ 登録日時≦ｔ'＜失効日時］を満たす行を検索する（ステップＳ３５３）。
【０２２６】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ３５４）、条件を満たす行が存在しない場合には（ステップＳ３５４→Ｎｏ）、ステップＳ３５８に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ３５４→Ｙｅｓ）、次のステップＳ３５５へ進む。
【０２２７】
ステップＳ３５５において、ルート情報更新処理部３２０は、データ管理部３２１を介して、条件を満たす行の失効日時を"∞"から更新日時ｔ'に更新する。
【０２２８】
次に、データ管理部３２１は、データ記憶領域３００のルート情報に、keyとしてサブルートキー（ｒ＠ｄ）、登録日時として更新日時（ｔ'）、失効日時として"∞"、valueとして更新後識別子（ｉ'）となる行と追加する（ステップＳ３５６）。
【０２２９】
そして、ルート情報更新処理部３２０は、ルート情報が更新されたことを示すルート情報更新応答メッセージ７１（図２２（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ３５７）。
【０２３０】
また、ステップＳ３５４において、条件を満たす行がない場合には（ステップＳ３５４→Ｎｏ）、ルート情報更新処理部３２０は、エラーメッセージを生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ３５８）。
【０２３１】
このようにすることで、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１から取得したＩＤ更新要求メッセージ６０（図２２（ａ）参照）に基づき、ある「更新対象ドメイン」における「更新日時」以降の識別子を、それまで登録されていた「更新対象識別子」から新たな識別子である「更新後識別子」に更新することができる。
【０２３２】
≪ＩＤ更新処理後のＩＤ変換処理の具体例≫
次に、本実施形態に係る分散ＩＤ管理システム５において、図２１で示したＩＤ更新処理が行われた後における、ＩＤ変換処理を３例説明する。１例目と２例目は、ＩＤ更新処理後のＩＤ変換処理が正常に行われる例を示し、３例目は、不正なＩＤ変換処理の要求を受けたため、ＩＤ変換処理が失敗する例を示す。これらは、ＩＤ更新処理後においても、正常にＩＤ変換処理が実行できることを説明するための例である。
【０２３３】
＜ＩＤ更新処理後のＩＤ変換処理（１）＞
まず、図２８，図２９を参照して、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理（１）について説明する。
【０２３４】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"９"を、ドメイン（変換先ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理（つまり、ドメイン"Ｄ０"の日時"Ｔ３"における識別子"９"に対応する、ドメイン"Ｄ１"の同日時"Ｔ３"における識別子を検索する処理）、について説明する。ここで、"Ｔ３"は"Ｔ２"よりも未来の日時を示すものとする。
【０２３５】
（ＩＤ変換処理の全体の流れ）
図２８は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理後のＩＤ変換処理（１）の全体の流れを示すシーケンス図である。ここでは、前記した図２１に示すＩＤ更新処理がすでに行われ、各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ）のデータ記憶領域３００には、図２３に示すデータが記憶されているものとして説明する。
【０２３６】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ｂ（４０）をゲートウェイ装置２に送信する（ステップＳ４０１）。
【０２３７】
図２９（ａ）は、ＩＤ変換要求メッセージ４０ｂ（４０）を例示する図である。図２９（ａ）に示すＩＤ変換要求メッセージ４０ｂ（４０）は、変換元であるドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"９"を、ドメイン（変換後ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理を要求するものである。
【０２３８】
図２８に戻り、ＩＤ変換要求メッセージ４０ｂを受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ４０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"９＠Ｄ０"に対応するノードであるデータ管理装置３Ｅが、インデックスノードとして決定される。
【０２３９】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ｂ（４０）を、インデックスノードとして決定したデータ管理装置３Ｅに送信する（ステップＳ４０３）。
【０２４０】
ＩＤ変換要求メッセージ４０ｂ（４０）を受信したデータ管理装置３Ｅは、ルートキーの取得処理を行う（ステップＳ４０４）。ルートキーの取得は、インデックスキー"９＠Ｄ０"をキーとして、データ格納領域３００Ｅ（図２３（ｅ）参照）内を検索し、変換元日時"Ｔ３"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図２３（ｅ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０２４１】
次に、データ管理装置３Ｅは、ルートノードの決定処理を行う（ステップＳ４０５）。ここでは、サブルートキー"Ｒ０＠Ｄ１"に対応するノードとして、データ管理装置３Ｄが、ルートノードとして決定される。
【０２４２】
続いて、データ管理装置３Ｅは、ＩＤ取得要求メッセージ５０ｂ（５０）を、ルートノードとして決定したデータ管理装置３Ｄに送信する（ステップＳ４０６）。
【０２４３】
図２９（ｃ）は、ＩＤ取得要求メッセージ５０ｂ（５０）を例示する図である。図２９（ｃ）に示すように、ＩＤ取得要求メッセージ５０ｂ（５０）は、サブルートキー"Ｒ０＠Ｄ１"に紐付く識別子の内、変換先日時"Ｔ３"で有効なものの取得を要求するものであることを示す。
【０２４４】
図２８に戻り、ＩＤ取得要求メッセージ５０ｂ（５０）を受信したデータ管理装置３Ｄは、ＩＤ（識別子）の取得処理を行う（ステップＳ４０７）。ＩＤ（識別子）の取得は、サブルートキー"Ｒ０＠Ｄ１"をキーとして、データ格納領域３００Ｄ（図２３（ｄ）参照）内を検索し、変換先日時"Ｔ３"が、登録日時と失効日時の間に含まれるような行から行われる。ここでは、図２３（ｄ）に示すルート情報から、識別子（変換先識別子）として"ａ"が取得される。
【０２４５】
次に、データ管理装置３Ｄは、ＩＤ取得応答メッセージ５１ｂ（５１）を、データ管理装置３Ｅに送信する（ステップＳ４０８）。図２９（ｄ）に示すように、ＩＤ取得応答メッセージ５１ｂには、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０２４６】
続いて、データ管理装置３Ｅは、ＩＤ変換応答メッセージ４１ｂ（４１）を、ゲートウェイ装置２に送信する（ステップＳ４０９）。図２９（ｂ）に示すように、ＩＤ変換応答メッセージ４１ｂ（４１）には、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０２４７】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ｂ（４１）をクライアント装置１に送信し、処理を終える（ステップＳ４１０）。
【０２４８】
このようにして、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤ変換要求した際に、ＩＤ更新処理の結果を反映した、正しい変換結果として変換先識別子を得ることができる。
【０２４９】
＜ＩＤ更新処理後のＩＤ変換処理（２）＞
次に、図３０，図３１を参照して、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理（２）について説明する。
【０２５０】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン（変換元ドメイン）"Ｄ１"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"ａ"を、ドメイン（変換先ドメイン）"Ｄ０"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理（つまり、ドメイン"Ｄ１"の日時"Ｔ３"における識別子"ａ"に対応する、ドメイン"Ｄ０"の同日時"Ｔ３"における識別子を検索する処理）、について説明する。ここで、"Ｔ３"は"Ｔ２"よりも未来の日時を示すものとする。
【０２５１】
（ＩＤ変換処理の全体の流れ）
図３０は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理後のＩＤ変換処理の全体の流れ（２）を示すシーケンス図である。ここでは、前記した図２１に示すＩＤ更新処理がすでに行われ、各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ）のデータ記憶領域３００には、図２３に示すデータが記憶されているものとして説明する。
【０２５２】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ｃ（４０）をゲートウェイ装置２に送信する（ステップＳ５０１）。
【０２５３】
図３１（ａ）は、ＩＤ変換要求メッセージ４０ｃ（４０）を例示する図である。図３１（ａ）に示すＩＤ変換要求メッセージ４０ｃ（４０）は、変換元であるドメイン（変換元ドメイン）"Ｄ１"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"ａ"を、ドメイン（変換後ドメイン）"Ｄ０"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理を要求するものである。
【０２５４】
図３０に戻り、ＩＤ変換要求メッセージ４０ｃ（４０）を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ５０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"ａ＠Ｄ１"に対応するノードであるデータ管理装置３Ｃが、インデックスノードとして決定される。
【０２５５】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ｃ（４０）を、インデックスノードとして決定したデータ管理装置３Ｃに送信する（ステップＳ５０３）。
【０２５６】
ＩＤ変換要求メッセージ４０ｃ（４０）を受信したデータ管理装置３Ｃは、ルートキーの取得処理を行う（ステップＳ５０４）。ルートキーの取得は、インデックスキー"ａ＠Ｄ１"をキーとして、データ格納領域３００Ｃ（図２３（ｃ）参照）内を検索し、変換元日時"Ｔ３"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図２３（ｃ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０２５７】
次に、データ管理装置３Ｃは、ルートノードの決定処理を行う（ステップＳ５０５）。ここでは、サブルートキー"Ｒ０＠Ｄ０"に対応するノードとして、データ管理装置３Ｂが、ルートノードとして決定される。
【０２５８】
続いて、データ管理装置３Ｃは、ＩＤ取得要求メッセージ５０ｃ（５０）を、ルートノードとして決定したデータ管理装置３Ｂに送信する（ステップＳ５０６）。
【０２５９】
図３１（ｃ）は、ＩＤ取得要求メッセージ５０ｃ（５０）を例示する図である。図３１（ｃ）に示すように、ＩＤ取得要求メッセージ５０ｃ（５０）は、サブルートキー"Ｒ０＠Ｄ０"に紐付く識別子の内、変換先日時"Ｔ３"で有効なものの取得を要求するものであることを示す。
【０２６０】
図３０に戻り、ＩＤ取得要求メッセージ５０ｃ（５０）を受信したデータ管理装置３Ｂは、ＩＤ（識別子）の取得処理を行う（ステップＳ５０７）。ＩＤ（識別子）の取得は、サブルートキー"Ｒ０＠Ｄ０"をキーとして、データ格納領域３００Ｂ（図２３（ｂ）参照）内を検索し、変換先日時"Ｔ３"が、登録日時と失効日時の間に含まれるような行から行われる。ここでは、図２３（ｂ）に示すルート情報から、識別子（変換先識別子）として"９"が取得される。
【０２６１】
次に、データ管理装置３Ｂは、ＩＤ取得応答メッセージ５１ｃ（５１）を、データ管理装置３Ｃに送信する（ステップＳ５０８）。図３１（ｄ）に示すように、ＩＤ取得応答メッセージ５１ｃ（５１）には、ＩＤ変換処理の結果取得された識別子（変換先識別子）"９"が含まれる。
【０２６２】
続いて、データ管理装置３Ｃは、ＩＤ変換応答メッセージ４１ｃ（４１）を、ゲートウェイ装置２に送信する（ステップＳ５０９）。図３１（ｂ）に示すように、ＩＤ変換応答メッセージ４１ｃ（４１）には、ＩＤ変換処理の結果取得された識別子（変換先識別子）"９"が含まれる。
【０２６３】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ｃをクライアント装置１に送信し、処理を終える（ステップＳ５１０）。
【０２６４】
このようにして、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤ変換要求した際に、ＩＤ更新処理の結果を反映した、正しい変換結果として変換先識別子を得ることができる。
【０２６５】
＜ＩＤ更新処理後のＩＤ変換処理（失敗例）＞
次に、図３２，図３３を参照して、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理（失敗例）について説明する。
【０２６６】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"０"を、ドメイン（変換先ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）に変換する処理（つまり、ドメイン"Ｄ０"の日時"Ｔ３"における識別子"０"に対応する、ドメイン"Ｄ１"の同日時"Ｔ３"における識別子を検索する処理）、について説明する。ここで、"Ｔ３"は"Ｔ２"よりも未来の日時を示すものとする。
【０２６７】
また、ここでは、前記した図２１に示すＩＤ更新処理がすでに行われ、各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ）のデータ記憶領域３００には、図２３に示すデータが記憶されていることを前提とするが、このＩＤ更新処理が行われた結果、ドメイン"Ｄ０"の日時"Ｔ３"における識別子は"０"ではなく、更新され"９"になっているため、当該ＩＤ変換処理は、失敗する。その場合の処理例を示すものである。
【０２６８】
（ＩＤ変換処理（失敗例）の全体の流れ）
図３２は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理後のＩＤ変換処理（失敗例）の全体の流れを示すシーケンス図である。
【０２６９】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ｄ（４０）をゲートウェイ装置２に送信する（ステップＳ６０１）。
【０２７０】
図３３（ａ）は、ＩＤ変換要求メッセージ４０ｄ（４０）を例示する図である。図３３（ａ）に示すＩＤ変換要求メッセージ４０ｄは、変換元であるドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"０"を、ドメイン（変換後ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理を要求するものである。
【０２７１】
図３２に戻り、ＩＤ変換要求メッセージ４０ｄ（４０）を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ６０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"０＠Ｄ０"に対応するノードであるデータ管理装置３Ａが、インデックスノードとして決定される。
【０２７２】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ｄ（４０）を、インデックスノードとして決定したデータ管理装置３Ａに送信する（ステップＳ６０３）。
【０２７３】
ＩＤ変換要求メッセージ４０ｄ（４０）を受信したデータ管理装置３Ａは、ルートキーの取得処理を行う（ステップＳ６０４）。ルートキーの取得は、インデックスキー（"０＠Ｄ０"）をキーとして、データ格納領域３００Ａ（図２３（ａ）参照）内を検索し、変換元日時"Ｔ３"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図２３（ａ）に示すインデックスに基づき、変換元日時Ｔ３が登録日時Ｔ０と失効日時Ｔ２の間に含まれるような行が存在しないため、ルートキーの取得に失敗する。
【０２７４】
次に、データ管理装置３Ａは、ＩＤ変換応答メッセージ４１ｄ（４１）を、ゲートウェイ装置２に送信する（ステップＳ６０５）。図３３（ｂ）に示すように、ＩＤ変換応答メッセージ４１ｄ（４１）には、ＩＤ変換処理の結果が存在しないことを示す"null"が含まれる。なお、当該メッセージには、"null"だけでなく、より詳細なエラー内容を含めるようにしてもよい。
【０２７５】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ｄ（４１）をクライアント装置１に送信し、処理を終える（ステップＳ６０６）。
【０２７６】
このようにして、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求した際に、存在しない識別子を用いた変換処理に対しては、エラーが返されることが示された。
【０２７７】
以上説明したように、本実施形態に係る分散ＩＤ管理方法および分散ＩＤ管理システムによれば、管理対象に紐付く識別子であって、かつ、ドメインや日時ごとに変化し得るような識別子を管理するシステムにおいて、識別子を各データ管理装置３に分散配置し、ドメイン、日時を指定した識別子の変換処理や更新処理が可能となる。また、同一機能を備えたデータ管理装置３を複数配置し、インデックスおよびルート情報を各データ管理装置３に分散することで、管理すべきデータ量を抑えた上で、容易にスケールアウトを可能とすることができる。
【符号の説明】
【０２７８】
１ クライアント装置
２ ゲートウェイ装置
３ データ管理装置
４ 通信ネットワーク
５ 分散ＩＤ管理システム
１０ ＩＤ登録要求メッセージ
１１ ＩＤ登録応答メッセージ
２０ ルート情報登録要求メッセージ
２１ ルート情報登録応答メッセージ
３０ インデックス登録要求メッセージ
３１ インデックス登録応答メッセージ
４０ ＩＤ変換要求メッセージ
４１ ＩＤ変換応答メッセージ
５０ ＩＤ取得要求メッセージ
５１ ＩＤ取得応答メッセージ
６０ ＩＤ更新要求メッセージ
６１ ＩＤ更新応答メッセージ
７０ ルート情報更新要求メッセージ
７１ ルート情報更新応答メッセージ
１００ ゲートウェイ情報記憶領域
１１０，２１０，３１０ 制御部
１１１ ＩＤ登録要求部
１１２ ＩＤ変換要求部
１１３ ＩＤ更新要求部
１３０，２３０，３３０ 入出力部
１４０，２４０，３４０ 送受信部
１５０，２５０，３５０ 記憶部
２００ ノード情報記憶領域
２１１，３１１ ノード管理部
２１２，３１２ ノード決定部
２１３ ＩＤ登録転送部
２１４ ＩＤ変換転送部
２１５ ＩＤ更新転送部
３００ データ記憶領域
３１３ ルートキー生成部
３１４ ＩＤ登録処理部
３１５ ＩＤ変換処理部
３１６ ＩＤ更新処理部
３１７ ＩＤ取得処理部
３１８ インデックス登録処理部
３１９ ルート情報登録処理部
３２０ ルート情報更新処理部
３２１ データ管理部
【技術分野】
【０００１】
本発明は、分散ＩＤ管理方法および分散ＩＤ管理システムに関する。
【背景技術】
【０００２】
情報システムにおいて物品や人またはそれらに関わるデータを管理する際、管理対象を一意に特定可能な符号、すなわちＩＤ（Identification：識別子）を用いることで、管理の自動化や効率化が図られることが多い。例えば、図書にはＩＳＢＮ（International Standard Book Number：国際標準図書番号）と呼ばれる世界共通の番号が振られており、当該番号を用いれば、全世界でただ一つの書籍を特定することが可能となっている。また、一部の国・地域では、当該国・地域内の個人に納税者番号や住民番号等と呼ばれる識別子を割り当てることで、各個人に紐付くデータと当該個人との関係を一意に識別可能とし、税務や社会保障制度の効率的な運営を図っている。
【０００３】
一般に、管理対象（物品若しくは人等）に対して割り当てられている識別子は、利用される範囲（以下、「ドメイン」と呼ぶ）および時間によって異なる値を取り得る。例えば、ある管理対象に対して、２００９年３月の時点では、Ａ工場で"０"という識別子で管理されていた管理対象が、２０１０年６月の時点では、Ｂ工場で"ａ"という識別子で管理されている状況が存在し得る。この場合、両識別子が同一の管理対象を指しているものであることを把握し、必要に応じて両識別子を相互に変換可能であると、時間やドメインをまたがった効率的な管理が可能となる。また、管理体系の一貫性を保つためには、識別子の更新（例えばＡ工場での識別子が２０１１年９月以降"９"に更新される等）についても把握し、相互変換の際に反映できることが望ましい。
【０００４】
上記のような、相互変換、更新処理を実現するに当たっては、（管理対象、ドメイン、時間）の三次元空間の各点に値（識別子）を対応付けたデータベースを構築し、データ登録・変換・更新のインタフェースを備えることが必要となる。当該データベースは、管理対象の数、ドメインの数、識別子の更新頻度が前もって分かっている場合にはリレーショナルデータベースを用いて実現することが比較的容易であるが、そうでない場合、設計段階でテーブルのサイズやハードウェアの性能要件を定めにくいために、リレーショナルデータベースの利用が必ずしも最適でない可能性がある。このような状況下では、サービス開始後に同装置を一台ないし複数台追加するだけで、要求される容量や性能要件を満足できること（スケールアウト）を可能とする分散データ管理システムが利用されることが多い。
【０００５】
スケールアウト可能な分散データ管理システムの例としては、Consistent Hashingと呼ばれる手法（コンシステントハッシュ法）を応用した方式が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−７４６０４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載された技術では、データ名（キー）に基づいてデータの分散管理が実現されるものの、分散したデータを当該データが含む情報（日時・ドメイン・識別子等）に基づいて効率良く特定する機能を備えていない。例えば前述したように、ある管理対象（物品若しくは人等）に対して、２００９年３月時点では、Ａ工場で"０"という識別子で管理されていた管理対象が、２０１０年６月時点では、Ｂ工場で"ａ"という識別子で管理されているような状況において、変換元の識別子（例えば、"０"）と、変換元のドメイン（例えば、Ａ工場）と、変換元の日時（例えば、２００９年３月）と、変換先のドメイン（例えば、Ｂ工場）と、変換先の日時（例えば、２０１０年６月）と、を指定して、変換先の識別子（ここでは、"ａ"）を得るような処理を実現する場合、"変換元ＩＤ，変換元ドメイン，変換元日時，変換先ドメイン，変換先日時" をデータ名（キー）として、データ内に変換先ＩＤを格納するという方法を用いることにより可能ではある。しかし、このような構成をとった場合には、データ管理システムで保存すべきデータの量や、ＩＤの更新時の書き換えが必要になるデータの量が多くなるという問題がある。また、日時の間隔が広い場合、例えば、月単位や日単位等の場合、上記のようなデータ名を構成することは比較的容易であるが、間隔が細かい場合、例えば、分単位や秒単位等の場合には、管理すべきデータの量が膨大になってしまうという問題がある。
【０００８】
このような背景に鑑みて本発明がなされたのであり、本発明は、同一の管理対象に紐付くものの、日時やドメインによって異なる値を取り得る識別子間の相互変換を可能とし、かつ、管理すべきデータ量を抑えた上で、スケールアウトを可能とする、分散ＩＤ管理方法および分散ＩＤ管理システムを提供することを課題とする。
【課題を解決するための手段】
【０００９】
本発明の分散ＩＤ管理システムにおけるデータ管理装置は、識別子、ドメイン、日時を含むデータを、インデックスキー（識別子とドメインの組）およびサブルートキー（ルートキーとドメインの組）の２種類のキーを用いて管理する。そして、クライアント装置からＩＤ変換要求を受け付けると、ゲートウェイ装置が、インデックスキーを用いてルートキーを保持するデータ管理装置を複数のデータ管理装置の中から決定する。そして、そのデータ管理装置は、サブルートキーを用いて、変換先の識別子を保持する他のデータ管理装置を決定し、他のデータ管理装置から変換先の識別子を取得して、ゲートウェイ装置を介して、クライアント装置に、その変換先の識別子を含むメッセージを送信する。
【発明の効果】
【００１０】
本発明によれば、同一の管理対象に紐付くものの、日時やドメインによって異なる値を取り得る識別子間の相互変換を可能とし、かつ、管理すべきデータ量を抑えた上で、スケールアウトを可能とする、分散ＩＤ管理方法および分散ＩＤ管理システムを提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態に係る分散ＩＤ管理システムの全体の構成例を説明するための図である。
【図２】本実施形態に係るクライアント装置の構成例を示す機能ブロック図である。
【図３】本実施形態に係るゲートウェイ装置の構成例を示す機能ブロック図である。
【図４】本実施形態に係るノード決定部が行うデータの振り分け先となるノードの決定処理を説明するための図である。図４（ａ）は、本実施形態に係るノード情報記憶領域に格納されるノード情報のデータ構成の一例を示す図である。また、図４（ｂ）は、本実施形態に係るノード決定部による、データの振り分け先の決定処理を説明するための図である。
【図５】本実施形態に係るデータ管理装置の構成例を示す機能ブロック図である。
【図６】本実施形態に係る各装置（クライアント装置、ゲートウェイ装置、データ管理装置）のハードウェア構成図である。
【図７】本実施形態に係る分散ＩＤ管理システムが行うＩＤ登録処理の全体の流れを示すシーケンス図である。
【図８】本実施形態に係るデータ管理システムが行うＩＤ登録処理で送受信されるメッセージ例を示す図である。
【図９】本実施形態に係るデータ管理装置のデータ記憶領域に記憶されるインデックスおよびルート情報の例を示す図である。
【図１０】本実施形態に係るＩＤ登録処理におけるゲートウェイ装置の処理の流れを示すフローチャートである。
【図１１】本実施形態に係るノード決定処理の流れを示すフローチャートである。
【図１２】本実施形態に係るＩＤ登録処理における担当ノード（データ管理装置Ａ）の処理の流れを示すフローチャートである。
【図１３】本実施形態に係るＩＤ登録処理における担当ノード（データ管理装置Ａ）の処理の流れを示すフローチャートである。
【図１４】本実施形態に係るインデックス保存処理におけるデータ管理装置の処理の流れを示すフローチャートである。
【図１５】本実施形態に係るルート情報保存処理におけるデータ管理装置の処理の流れを示すフローチャートである。
【図１６】本実施形態に係る分散ＩＤ管理システムが行うＩＤ変換処理の全体の流れを示すシーケンス図である。
【図１７】本実施形態に係るデータ管理システムが行うＩＤ変換処理で送受信されるメッセージ例を示す図である。
【図１８】本実施形態に係るＩＤ変換処理におけるゲートウェイ装置の処理の流れを示すフローチャートである。
【図１９】本実施形態に係るＩＤ変換処理におけるデータ管理装置Ａの処理の流れを示すフローチャートである。
【図２０】本実施形態に係るＩＤ取得処理におけるデータ管理装置Ｄの処理の流れを示すフローチャートである。
【図２１】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理の全体の流れを示すシーケンス図である。
【図２２】本実施形態に係るデータ管理システムが行うＩＤ更新処理で送受信されるメッセージ例を示す図である。
【図２３】本実施形態に係るデータ管理装置の、ＩＤ更新処理後のデータ記憶領域に記憶されるインデックスおよびルート情報の例を示す図である。
【図２４】本実施形態に係るＩＤ更新処理におけるゲートウェイ装置の処理の流れを示すフローチャートである。
【図２５】本実施形態に係るＩＤ更新処理におけるデータ管理装置Ａの処理の流れを示すフローチャートである。
【図２６】本実施形態に係るＩＤ更新処理におけるデータ管理装置Ａの処理の流れを示すフローチャートである。
【図２７】本実施形態に係るＩＤ更新処理におけるデータ管理装置Ｂのルート情報更新処理の流れを示すフローチャートである。
【図２８】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理後のＩＤ変換処理（１）の全体の流れを示すシーケンス図である。
【図２９】本実施形態に係るデータ管理システムが行うＩＤ更新処理後のＩＤ変換処理（１）で送受信されるメッセージ例を示す図である。
【図３０】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理後のＩＤ変換処理の全体の流れ（２）を示すシーケンス図である。
【図３１】本実施形態に係るデータ管理システムが行うＩＤ更新処理後のＩＤ変換処理（２）で送受信されるメッセージ例を示す図である。
【図３２】本実施形態に係る分散ＩＤ管理システムが行うＩＤ更新処理後のＩＤ変換処理（失敗例）の全体の流れを示すシーケンス図である。
【図３３】本実施形態に係るデータ管理システムが行うＩＤ更新処理後のＩＤ変換処理（失敗例）で送受信されるメッセージ例を示す図である。
【発明を実施するための形態】
【００１２】
まず、本実施形態に係る分散ＩＤ管理システム５の構成について説明する。
図１は、本実施形態に係る分散ＩＤ管理システム５の全体の構成例を説明するための図である。
【００１３】
図１に示すように、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１と接続されたゲートウェイ装置２と、そのゲートウェイ装置２と通信ネットワーク４を介して接続された複数のデータ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，…）とを含んで構成される。このデータ管理装置３は、図１に示したように５つに限定されず、複数のデータ管理装置３であればよい。また各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，…）それぞれは、通信ネットワーク４を介して通信可能に接続されている。
【００１４】
クライアント装置１は、分散ＩＤ管理システム５（ゲートウェイ装置２）に対して、後記するＩＤ登録要求メッセージ１０（図８（ａ）参照）、ＩＤ変換要求メッセージ４０（図１７（ａ）参照）、ＩＤ更新要求メッセージ６０（図２２（ａ）参照）を送信し、その結果を受信する装置である。また、ゲートウェイ装置２は、クライアント装置１から上記の各メッセージを受信し、そのメッセージを担当するデータ管理装置３に振り分けて送信し、データ管理装置３からの処理結果を、クライアント装置１へ返信する装置である。データ管理装置３は、ゲートウェイ装置２から取得したメッセージに従い、データの登録、変換、更新等を行う装置である。次に、各装置の詳細な構成について説明する。
【００１５】
≪クライアント装置≫
図２は、本実施形態に係るクライアント装置１の構成例を示す機能ブロック図である。図２に示すように、クライアント装置１は、制御部１１０と、入出力部１３０と、送受信部１４０と、記憶部１５０とを含んで構成される。
【００１６】
また、制御部１１０は、ＩＤ登録要求部１１１と、ＩＤ変換要求部１１２と、ＩＤ更新要求部１１３とを備えている。
【００１７】
ＩＤ登録要求部１１１は、後記するＩＤ登録要求メッセージ１０（図８（ａ）参照）を生成し、そのＩＤ登録要求メッセージ１０を、送受信部１４０を介して、ゲートウェイ装置２に送信する。また、ＩＤ登録要求部１１１は、ＩＤ登録応答メッセージ１１（図８（ｂ）参照）を、送受信部１４０を介して受信する。
【００１８】
ＩＤ変換要求部１１２は、後記するＩＤ変換要求メッセージ４０（図１７（ａ）参照）を生成し、そのＩＤ変換要求メッセージ４０を、送受信部１４０を介して、ゲートウェイ装置２に送信する。また、ＩＤ変換要求部１１２は、ＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を、送受信部１４０を介して受信する。
【００１９】
ＩＤ更新要求部１１３は、後記するＩＤ更新要求メッセージ６０（図２２（ａ）参照）を生成し、そのＩＤ更新要求メッセージ６０を、送受信部１４０を介して、ゲートウェイ装置２に送信する。また、ＩＤ更新要求部１１３は、ＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を、送受信部１４０を介して受信する。
【００２０】
入出力部１３０は、不図示のキーボードやマウス等の入力手段や、モニタ等の出力手段と接続され、利用者から入力手段を介して入力情報を受け付け、その入力情報や処理結果をモニタ等の出力手段に出力する処理を行う。
【００２１】
送受信部１４０は、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）通信を可能とするプロトコルスタックや、プロセス間通信を可能とするモジュール等のように、ネットワークや通信路を介して送受信する情報の制御を行う。
【００２２】
記憶部１５０は、ゲートウェイ情報記憶領域１００を含んで構成される。ゲートウェイ情報記憶領域１００は、ＩＤ登録要求メッセージ１０、ＩＤ変換要求メッセージ４０、ＩＤ更新要求メッセージ６０の送信先となるゲートウェイ装置２の接続情報（例えば、ＩＰアドレスとポート番号の組）を記憶する領域である。この接続情報は、前もって静的に登録するようにしてもよいし、ゲートウェイ装置２や他の装置からの情報に基づいて動的に接続先を決定し記憶するようにしてもよい。
【００２３】
≪ゲートウェイ装置≫
図３は、本実施形態に係るゲートウェイ装置２の構成例を示す機能ブロック図である。図３に示すように、ゲートウェイ装置２は、制御部２１０と、入出力部２３０と、送受信部２４０と、記憶部２５０とを含んで構成される。
【００２４】
また、制御部２１０は、ノード管理部２１１と、ノード決定部２１２と、ＩＤ登録転送部２１３と、ＩＤ変換転送部２１４と、ＩＤ更新転送部２１５とを備えている。
【００２５】
ノード管理部２１１は、データ管理装置３の後記するノード管理部３１１と相互通信し、後記するノード情報記憶領域２００内のノードの接続情報（例えば、ＩＰアドレスとポート番号の組）を同期する処理を行う。具体的には、ノード管理部２１１は、新たにデータ管理装置３が追加された場合には、その接続情報をノード情報記憶領域２００内に追加し、あるデータ管理装置３が削除された場合には、そのデータ管理装置３の接続情報を削除する。
【００２６】
ノード決定部２１２は、他の処理部から検索キーを取得した場合に、ノード情報記憶領域２００に格納されたノード情報に基づいて、検索キーが担当するノード（データ管理装置３）を決定し、そのノードの接続情報を、要求のあった処理部に返す処理を行う。以下、具体的にノード決定部２１２が行う処理を説明する。
【００２７】
図４（ａ）は、本実施形態に係るノード情報記憶領域２００に格納されるノード情報のデータ構成の一例を示す図である。また、図４（ｂ）は、本実施形態に係るノード決定部２１２による、データの振り分け先の決定処理を説明するための図である。
【００２８】
図４（ａ）に示すように、ノード情報記憶領域２００のノード情報には、各データ管理装置３について、ノードＩＤと、ノード名と、接続情報（例えば、ＩＰアドレスとポート番号の組）とが記憶されている。このノードＩＤは、ノード決定部２１２が、例えば、接続情報を所定のハッシュ関数に導入することにより得られたハッシュ値であり、図４（ｂ）に示すリング（閉じたハッシュ空間）４００上の値に対応付けられる。なお、このノード情報記憶領域２００内のノード情報は、ゲートウェイ装置２のノード管理部２１１およびデータ管理装置３のノード管理部３１１により、ゲートウェイ装置２とすべてのデータ管理装置３との間で定期的に同期をとることで、同じノード情報が共有されている。
【００２９】
ノード決定部２１２は、図４（ｂ）に示すように、例えば、検索キーとして"０＠Ｄ０"を取得すると、その検索キーをハッシュ関数Ｈに導入しハッシュ値を計算する。そして、ノード決定部２１２は、その計算したハッシュ値（図４（ｂ）では、「２１３３」）の値より大きく、最も近いノードＩＤ（ハッシュ値）である「３０５０」のデータ管理装置Ａを、その検索キーのデータの振り分け先のノードとして決定する。
なお、このとき、ノード決定部２１２は、振り分け先として決定したノードの次に値が近いノードＩＤ（ハッシュ値）を持つノード（ここでは、例えば、ノードＩＤが「５９８８」のデータ管理装置３Ｂ）をさらに選択（さらに、次に値の近いノードＩＤを含むようにして、１つ以上選択するようにしてもよい）することで、後記する各メッセージの送信先を冗長化し、システムの信頼性を高めることも可能である。
【００３０】
図３に戻り、ＩＤ登録転送部２１３は、受信したＩＤ登録要求メッセージ１０（図８（ａ）参照）の先頭の識別子（例えば、"０"）とドメイン（例えば、"Ｄ０"）を結合した値としてインデックスキー（例えば、"０＠Ｄ０"）を生成し、ノード決定部２１２に出力する。そして、ＩＤ登録転送部２１３は、ノード決定部２１２が決定した担当ノードとなるデータ管理装置３に、送受信部２４０を介してＩＤ登録要求メッセージ１０を送信する。ここで、担当ノードとは、ＩＤ登録要求メッセージ１０の先頭の識別子とドメインを結合したインデックスキーをkeyとする後記するインデックスを保存するノード（データ管理装置３）のことをいう。また、ＩＤ登録転送部２１３は、送受信部２４０を介して、担当ノードからＩＤ登録応答メッセージ１１（図８（ｂ）参照）を受信し、クライアント装置１に送信する。
【００３１】
ＩＤ変換転送部２１４は、受信したＩＤ変換要求メッセージ４０（図１７（ａ）参照）の変換元識別子（例えば、"０"）と変換元ドメイン（例えば、"Ｄ０"）を結合した値としてインデックスキー（例えば、"０＠Ｄ０"）を生成し、ノード決定部２１２に出力する。そして、ＩＤ変換転送部２１４は、ノード決定部２１２が決定したインデックスノード（インデックスを保存するノードであり、詳細は後記する）となるデータ管理装置３に、送受信部２４０を介して、ＩＤ変換要求メッセージ４０を送信する。また、ＩＤ変換転送部２１４は、送受信部２４０を介して、インデックスノードからＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を受信し、クライアント装置１に送信する。
【００３２】
ＩＤ更新転送部２１５は、受信したＩＤ更新要求メッセージ６０（図２２（ａ）参照）の更新対象識別子（例えば、"０"）と更新対象ドメイン（例えば、"Ｄ０"）を結合した値としてインデックスキー（例えば、"０＠Ｄ０"）を生成し、ノード決定部２１２に出力する。そして、ＩＤ更新転送部２１５は、ノード決定部２１２が決定したインデックスノードとなるデータ管理装置３に、送受信部２４０を介して、ＩＤ更新要求メッセージ６０を送信する。また、ＩＤ更新転送部２１５は、送受信部２４０を介して、インデックスノードからＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を受信し、クライアント装置１に送信する。
【００３３】
入出力部２３０は、不図示のキーボードやマウス等の入力手段や、モニタ等の出力手段と接続され、利用者から入力手段を介して入力情報を受け付け、その入力情報や処理結果をモニタ等の出力手段に出力する処理を行う。
【００３４】
送受信部２４０は、ＴＣＰ／ＩＰ通信を可能とするプロトコルスタックや、プロセス間通信を可能とするモジュール等のように、ネットワークや通信路を介して送受信する情報の制御を行う。
【００３５】
記憶部２５０は、前記したノード情報記憶領域２００（図４（ａ）参照）を含んで構成される。
【００３６】
なお、本実施形態ではゲートウェイ装置２をクライアント装置１やデータ管理装置３とは独立した装置として扱っているが、本発明はこのような態様に限定されない。ゲートウェイ装置２を構成する各機能をクライアント装置１またはデータ管理装置３の中に実装することで、ゲートウェイ装置２を排した分散ＩＤ管理システム５を実現することも可能である。
【００３７】
≪データ管理装置≫
図５は、本実施形態に係るデータ管理装置３の構成例を示す機能ブロック図である。
図５に示すように、データ管理装置３は、制御部３１０と、入出力部３３０と、送受信部３４０と、記憶部３５０とを含んで構成される。
【００３８】
また、制御部３１０は、ノード管理部３１１と、ノード決定部３１２と、ルートキー生成部３１３と、ＩＤ登録処理部３１４と、ＩＤ変換処理部３１５と、ＩＤ更新処理部３１６と、ＩＤ取得処理部３１７と、インデックス登録処理部３１８と、ルート情報登録処理部３１９と、ルート情報更新処理部３２０と、データ管理部３２１とを備えている。
【００３９】
ノード管理部３１１およびノード決定部３１２の処理は、ゲートウェイ装置２のノード管理部２１１およびノード決定部２１２と同様であるので、説明を省略する。
【００４０】
ルートキー生成部３１３は、擬似乱数生成器等を利用して、ルートキー（例えば、"Ｒ０"）を生成する。ここでルートキーとは、分散ＩＤ管理システム５内で管理対象を一意に特定するための識別子を指すものである。
【００４１】
ＩＤ登録処理部３１４は、ＩＤ登録処理の全般を制御する。以下、具体的に説明する。
ＩＤ登録処理部３１４は、識別子とドメインとを結合した値（例えば、"０＠Ｄ０"）をインデックスキーとして生成し、ノード決定部３１２に出力する。そして、ＩＤ登録処理部３１４は、ノード決定部３１２が決定したインデックスノードとなるデータ管理装置３に、送受信部３４０を介して、インデックス登録要求メッセージ３０（後記する図８（ｅ）参照）を送信する。
また、ＩＤ登録処理部３１４は、ルートキー（例えば、"Ｒ０"）とドメイン（例えば、、"Ｄ０"）とを結合した値（例えば、"Ｒ０＠Ｄ０"）をサブルートキーとして生成し、ノード決定部３１２に出力する。そして、ＩＤ登録処理部３１４は、ノード決定部３１２が決定したルートノードとなるデータ管理装置３に、送受信部３４０を介して、ルート情報登録要求メッセージ２０（後記する図８（ｃ）参照）を送信する。ここでルートノードとは、サブルートキーをkeyとする後記するルート情報を保存するノード（データ管理装置３）のことをいう。そして、ＩＤ登録処理部３１４は、ルートノードからルート情報登録応答メッセージ２１（後記する図８（ｄ）参照）を受信すると、ＩＤ登録応答メッセージ１１（後記する図８（ｂ）参照）を生成し、ゲートウェイ装置２へ送信する。
【００４２】
ＩＤ変換処理部３１５は、ＩＤ変換処理の全般を制御する。以下、具体的に説明する。
ＩＤ変換処理部３１５は、ＩＤ変換要求メッセージ４０（図１７（ａ）参照）から、変換元識別子（例えば、"０"）と変換元ドメイン（例えば、"Ｄ０"）とを結合した値（例えば、"０＠Ｄ０"）としてインデックスキーを生成する。そして、ＩＤ変換処理部３１５は、生成したインデックスキー（"０＠Ｄ０"）と、変換元日時（例えば、"Ｔ１"）とを、データ管理部３２１に出力することにより、データ記憶領域３３０内のインデックスから、ルートキー（例えば、"Ｒ０"）を取得する。
ＩＤ変換処理部３１５は、取得したルートキー（"Ｒ０"）と変換先ドメイン（例えば、"Ｄ１"）を結合した値（例えば、"Ｒ０＠Ｄ１"）としてサブルートキーを生成し、ノード決定部３１２が決定したルートノードとなるデータ管理装置３に、ＩＤ取得要求メッセージ５０（後記する図１７（ｃ）参照）を送信する。
また、ＩＤ変換処理部３１５は、ルートノードから、送受信部３４０を介して、ＩＤ取得応答メッセージ５１（後記する図１７（ｄ）参照）を受信する。そして、ＩＤ変換処理部３１５は、ＩＤ取得応答メッセージ５１から取得したＩＤ（識別子）を含む、ＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を生成し、送受信部３４０を介して、ゲートウェイ装置２に送信する。
【００４３】
ＩＤ更新処理部３１６は、ＩＤ更新処理の全般を制御する。以下、具体的に説明する。
ＩＤ更新処理部３１６は、ＩＤ更新要求メッセージ６０（図２２（ａ）参照）から、更新対象識別子（例えば、"０"）と更新対象ドメイン（例えば、"Ｄ０"）とを結合した値（例えば、"０＠Ｄ０"）としてインデックスキーを生成する。そして、ＩＤ更新処理部３１６は、生成したインデックスキー（"０＠Ｄ０"）と、更新対象日時（例えば、"Ｔ１"）とを、データ管理部３２１に出力することにより、ルートキー（例えば、"Ｒ０"）を取得する。
また、ＩＤ更新処理部３１６は、データ管理部３２１を介して、当該行の失効日時（"∞"）を更新日時（例えば、"Ｔ２"）に更新する。
次に、ＩＤ更新処理部３１６は、ルートキー（"Ｒ０"）と更新対象ドメイン（"Ｄ０"）とを結合した値（例えば、"Ｒ０＠Ｄ０"）としてサブルートキーを生成し、ノード決定部３１２が決定したルートノードとなるデータ管理装置３に、ルート情報更新要求メッセージ７０（後記する図２２（ｃ）参照）を送信する。
ＩＤ更新処理部３１６は、ルートノードから、送受信部３４０を介して、ルート情報更新応答メッセージ７１（後記する図２２（ｄ）参照）を受信する。
また、ＩＤ更新処理部３１６は、更新後識別子（例えば、"９"）と更新対象ドメイン（"Ｄ０"）とを結合した値（例えば、"９＠Ｄ０"）としてインデックスキーを生成し、ノード決定部３１２が決定したインデックスノードとなるデータ管理装置３に、インデックス登録要求メッセージ３０（図２２（ｅ）参照）を送信する。
そして、ＩＤ更新処理部３１６は、インデックスノードから、送受信部３４０を介して、インデックス登録応答メッセージ３１（図２２（ｆ）参照）を受信する。続いて、ＩＤ更新処理部３１６は、ＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を生成し、送受信部３４０を介して、ゲートウェイ装置２に送信する。
【００４４】
ＩＤ取得処理部３１７は、ＩＤ取得要求メッセージ５０（図１７（ｃ）参照）から、サブルートキー（例えば、"Ｒ０＠Ｄ１"）と、変換先日時（例えば、"Ｔ１"）とを取得し、データ管理部３２１に出力することにより、変換先となる識別子（例えば、"ａ"）を取得する。そして、ＩＤ取得処理部３１７は、変換先となる識別子（"ａ"）を含むＩＤ取得応答メッセージ５１（図１７（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４５】
インデックス登録処理部３１８は、受信したインデックス登録要求メッセージ３０（図８（ｅ）参照）に基づいて、インデックス登録処理を行い、当該処理結果（例えば、"success"）を含むインデックス登録応答メッセージ３１（図８（ｆ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４６】
ルート情報登録処理部３１９は、受信したルート情報登録要求メッセージ２０（例えば、図８（ｃ）参照）に基づいて、ルート情報登録処理を行い、当該処理結果（例えば、"success"）を含むルート情報登録応答メッセージ２１（図８（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４７】
ルート情報更新処理部３２０は、受信したルート情報更新要求メッセージ７０（図２２（ｃ）参照）に基づいて、ルート情報更新処理を行い、当該処理結果（例えば、"success"）を含むルート情報更新応答メッセージ７１（図２２（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信する。
【００４８】
データ管理部３２１は、他の処理部からの要求を受けて、データ記憶領域３００内のデータの作成、検索、更新、削除等を行う。
【００４９】
入出力部３３０は、不図示のキーボードやマウス等の入力手段や、モニタ等の出力手段と接続され、利用者から入力手段を介して入力情報を受け付け、その入力情報や処理結果をモニタ等の出力手段に出力する処理を行う。
【００５０】
送受信部３４０は、ＴＣＰ／ＩＰ通信を可能とするプロトコルスタックや、プロセス間通信を可能とするモジュール等のように、ネットワークや通信路を介して送受信する情報の制御を行う。
【００５１】
記憶部３５０は、前記したノード情報記憶領域２００（図４（ａ）参照）と、データ記憶領域３００とを含んで構成される。
このデータ記憶領域３００は、key、登録日時、失効日時、valueの４つの組のデータが、インデックス若しくはルート情報として記憶される領域である。詳細は後記において説明する。
【００５２】
≪ハードウェア構成≫
図６は、本実施形態に係る各装置（クライアント装置１、ゲートウェイ装置２、データ管理装置３）のハードウェア構成図である。
【００５３】
図６に示すように、本実施形態に係る各装置は、一般的なコンピュータ１０００により実現される。
コンピュータ１０００は、ＣＰＵ１００１と、メモリ１００２と、ハードディスク等の外部記憶装置１００３と、通信ネットワークに接続するためのＮＩＣ（Network Interface Card）等の送受信装置１００４と、モニタ等の出力装置１００５と、キーボードやマウス等の入力装置１００６と、CD-ROMやDVD-ROM等の可搬性を有する記憶媒体１００８から情報を読み取る読取装置１００７とを含んで構成される。
【００５４】
そして、各装置の記憶部内の記憶領域は、ＣＰＵ１００１がメモリ１００２または外部記憶装置１００３を利用することにより実現可能となる。また、各制御部は、外部記憶装置１００３に記憶されている所定のプログラムをメモリ１００２にロードすることによりＣＰＵ１００１で実現可能となる。この所定のプログラムは、読取装置１００７を介して記憶媒体１００８から取得してもよいし、送受信装置１００４を介してネットワークから外部記憶装置１００３にダウンロードされ、メモリ１００２にロードされてＣＰＵ１００１により実行されるようにしてもよい。また、読取装置１００７を介して記憶媒体１００８から、あるいは、送受信装置１００４を介してネットワークから、メモリ１００２に直接ロードされ、ＣＰＵ１００１により実行されるようにしてもよい。
【００５５】
≪分散ＩＤ管理方法≫
次に、本実施形態に係る分散ＩＤ管理システム５による分散ＩＤ管理方法について説明する。具体的には、分散ＩＤ管理システム５による、（１）ＩＤ登録処理、（２）ＩＤ変換処理、（３）ＩＤ更新処理について説明する。
（１）ＩＤ登録処理は、クライアント装置１から取得したＩＤ登録要求メッセージ１０（図８（ａ）参照）に含まれる「識別子」「ドメイン」「登録日時」を含む登録情報を、ゲートウェイ装置２を介して、インデックスおよびルート情報という保存形式により、分散させてデータ管理装置３に保存する処理である。
（２）ＩＤ変換処理は、クライアント装置１から取得したＩＤ変換要求メッセージ４０（図１７（ａ）参照）に含まれる「変換元識別子」「変換元ドメイン」「変換元日時」「変換先ドメイン」「変換先日時」のパラメータを用いて、「変換元識別子」を「変換先識別子」に変換する、つまり、「変換先識別子」を検索する処理である。
（３）ＩＤ更新処理は、クライアント装置１から取得したＩＤ更新要求メッセージ６０（図２２（ａ）参照）に基づき、ある「更新対象ドメイン」における「更新日時」以降の識別子を、それまで登録されていた「更新対象識別子」から新たな識別子である「更新後識別子」に更新する処理である。
以下、各処理について詳細に説明する。
【００５６】
＜ＩＤ登録処理＞
まず、図７〜図１５を参照して、クライアント装置１がゲートウェイ装置２に対してＩＤの登録を要求（ＩＤ登録要求）した際に、ゲートウェイ装置２およびデータ管理装置３が実行するＩＤ登録処理について説明する。
【００５７】
ここでは、クライアント装置１が要求するＩＤ登録処理の例として、ドメイン"Ｄ０"の日時"Ｔ０"における識別子"０"と、ドメイン"Ｄ１"の日時"Ｔ０"における識別子"ａ"が、同じ管理対象を示す識別子であることを分散ＩＤ管理システム５に登録する処理を例に説明する。
【００５８】
（ＩＤ登録処理の全体の流れ）
図７は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ登録処理の全体の流れを示すシーケンス図である。
【００５９】
まず、クライアント装置１は、ＩＤ登録要求メッセージ１０をゲートウェイ装置２へ送信する（ステップＳ１０１）。
【００６０】
図８（ａ）は、ＩＤ登録要求メッセージ１０を例示する図である。図８（ａ）に示すように、ＩＤ登録要求メッセージ１０は、「識別子」，「ドメイン」，「登録日時」の３つのパラメータで１つの登録情報を示し、符号１０−１は、当該ＩＤ登録要求が、ドメイン"Ｄ０"の登録日時"Ｔ０"における識別子"０"を含むことを示し、符号１０−２は、当該ＩＤ登録要求が、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"を含むことを示す。そして、このＩＤ登録要求メッセージ１０が要求するＩＤ登録処理では、ドメイン"Ｄ０"の登録日時"Ｔ０"における識別子"０"と、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"が、同じ管理対象を示す識別子であることを登録する処理を行う。
なお、本例では、「識別子」，「ドメイン」，「登録日時」の組となる登録情報について、２組の例を説明するが、２組に限定されるものではなく、３組以上の登録情報を同時に登録するようにしてもよい。
また、図７以下に示す図において、例えば、日時"Ｔ０"におけるドメイン"Ｄ０"の識別子"０"の情報を、［０＠Ｄ０：Ｔ０］のように表記するものとする。
【００６１】
図７に戻り、次に、ゲートウェイ装置２は、担当ノードの決定処理を行う（ステップＳ１０２）。ここで、担当ノードとは、受信したＩＤ登録要求メッセージ１０の先頭のインデックスキー（ここでは、先頭の識別子"０"とドメイン"Ｄ０"とを結合した値として"０＠Ｄ０"）をkeyとする後記するインデックスを保存するノード（データ管理装置３）を指す。ゲートウェイ装置２のノード決定部２１２は、インデックスキー"０＠Ｄ０"をキーとして、コンシステントハッシュ法により、担当ノードを決定する。ここでは、ノード決定部２１２が、データ管理装置３Ａを担当ノードとして決定したものとする。
【００６２】
続いて、ゲートウェイ装置２は、ＩＤ登録要求メッセージ１０を、担当ノードとして決定したデータ管理装置３Ａに送信する（ステップＳ１０３）。
【００６３】
データ管理装置３Ａは、ＩＤ登録要求メッセージ１０を受信すると、ルートキーの生成処理を行う（ステップＳ１０４）。ルートキーは、例えば、ドメイン"Ｄ０"の日時"Ｔ０"における識別子"０"と、ドメイン"Ｄ１"の日時"Ｔ０"における識別子"ａ"とが指し示す同一の管理対象を、分散ＩＤ管理システム５内で一意に特定するための識別子を指すものである。ここでは、例えば、データ管理装置３Ａのルートキー生成部３１３が、擬似乱数生成器等を用いてルートキーとして"Ｒ０"を生成する。
【００６４】
次に、データ管理装置３Ａは、インデックスの保存（登録）処理を行う（ステップＳ１０５）。ここで、インデックスとは、インデックスキー（識別子とドメインの結合値。例えば、"０＠Ｄ０"）と、登録日時（例えば、"Ｔ０"）と、ルートキー（例えば、"Ｒ０"）とを含む情報を指すものである（例えば、後記する図９（ａ）参照）。
具体的には、まず、データ管理装置３Ａは、識別子"０"、ドメイン"Ｄ０"に関するインデックスを保存するインデックスノード（データ管理装置３）を決定する。インデックスノードの決定処理は、インデックスキー（"０＠Ｄ０"）を検索キーとして、担当ノードの決定処理と同様にノード決定部３１２により実行される。そして、ノード決定部３１２は、コンシステントハッシュ法を用いて、データ管理装置３Ａ自身をインデックスノードとして決定する。そして、データ管理装置３Ａは、自身のデータ記憶領域３００Ａ（３００）に対して、インデックスの保存処理を行う。
【００６５】
図９（ａ）は、インデックスが保存（登録）されたデータ管理装置３Ａのデータ記憶領域３００Ａの例を示す。このデータ記憶領域３００Ａに保存されたインデックスには、keyとしてのインデックスキー"０＠Ｄ０"、登録日時としての"Ｔ０"、失効日時として（"０＠Ｄ０"がまだ失効されていないことを示す）"∞"、valueとしてのルートキー"Ｒ０"がそれぞれ格納される。
【００６６】
図７に戻り、次に、データ管理装置３Ａは、ドメイン"Ｄ０"に関するルートノードの決定処理を行う（ステップＳ１０６）。ここでルートノードとは、サブルートキー（ルートキーとドメインの結合値。例えば、"Ｒ０＠Ｄ０"）をkeyとする後記するルート情報を保存すべきノード（データ管理装置３）を指す。このルートノード決定処理は、サブルートキーを検索キーとして、ノード決定部３１２が、コンシステントハッシュ法により、ルートノードを決定する。ここでは、例えば、サブルートキー"Ｒ０＠Ｄ０"に対応するノードとしてデータ管理装置３Ｂが、ルートノードして決定されたものとする。
【００６７】
続いて、データ管理装置３Ａは、ルート情報登録要求メッセージ２０ａ（２０）を、ルートノードとして決定したデータ管理装置３Ｂに送信する（ステップＳ１０７）。
【００６８】
図８（ｃ）は、ルート情報登録要求メッセージ２０を例示する図である。図８（ｃ）に示すように、ルート情報登録要求メッセージ２０は、「サブルートキー」，「識別子」，「登録日時」のパラメータを含んで構成される。図８（ｃ）に例示するルート情報登録要求メッセージ２０ａ（２０）は、ルートキー"Ｒ０"と、ドメイン"Ｄ０"の登録日時"Ｔ０"における識別子"０"とを対応付けて管理するように要求するものである。
【００６９】
図７に戻り、ルート情報登録要求メッセージ２０ａ（２０）を受信したデータ管理装置３Ｂは、ルート情報の保存（登録）処理を行う（ステップＳ１０８）。ここで、ルート情報とは、サブルートキー（ルートキーとドメインの結合値。例えば、"Ｒ０＠Ｄ０"）と、登録日時（例えば、"Ｔ０"）と、識別子（例えば、"０"）とを含む情報を指すものである。
【００７０】
図９（ｂ）は、ルート情報が保存（登録）されたデータ管理装置３Ｂのデータ記憶領域３００Ｂの例を示す。このデータ記憶領域３００Ｂに保存されたルート情報には、keyとしてのサブルートキー"Ｒ０＠Ｄ０"、登録日時としての"Ｔ０"、失効日時として（"Ｒ０＠Ｄ０"がまだ失効されていないことを示す）"∞"、valueとしての識別子"０"がそれぞれ格納される。
【００７１】
図７に戻り、データ管理装置３Ｂは、ルート情報登録応答メッセージ２１ａ（２１）を、データ管理装置３Ａに送信する（ステップＳ１０９）。図８（ｄ）に示すように、ルート情報登録応答メッセージ２１は、処理結果を示すパラメータで構成される。ここでは、ルート情報登録応答メッセージ２１ａとして、ルート情報の登録処理が成功したことを示す"success"が付されるものとする。
【００７２】
次に、データ管理装置３Ａは、識別子"ａ"、ドメイン"Ｄ１"に関するインデックスノードの決定処理を行う（ステップＳ１１０）。ここでは、例えば、インデックスキー"ａ＠Ｄ１"に対応するノードであるデータ管理装置３Ｃが、ノード決定部３１２によりインデックスノードとして決定される。
【００７３】
続いて、データ管理装置３Ａは、インデックス登録要求メッセージ３０ａ（３０）を、インデックスノードとして決定したデータ管理装置３Ｃに送信する（ステップＳ１１１）。
【００７４】
図８（ｅ）は、インデックス登録要求メッセージ３０を例示する図である。図８（ｅ）に示すように、インデックス登録要求メッセージ３０は、「インデックスキー」，「ルートキー」，「登録日時」のパラメータを含んで構成される。図８（ｅ）に例示するインデックス登録要求メッセージ３０ａ（３０）は、ルートキー"Ｒ０"と、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"とを対応付けて管理するように要求するものである。
【００７５】
図７に戻り、インデックス登録要求メッセージ３０ａ（３０）を受信したデータ管理装置３Ｃは、インデックスの保存（登録）処理を行う（ステップＳ１１２）。
【００７６】
図９（ｃ）は、インデックスが保存（登録）されたデータ管理装置３Ｃのデータ記憶領域３００Ｃの例を示す。このデータ記憶領域３００Ｃに保存されたインデックスには、keyとしてのインデックスキー"ａ＠Ｄ１"、登録日時としての"Ｔ０"、失効日時として（"ａ＠Ｄ１"がまだ失効されていないことを示す）"∞"、valueとしてのルートキー"Ｒ０"がそれぞれ格納される。
【００７７】
図７に戻り、データ管理装置３Ｃは、インデックス登録応答メッセージ３１ａ（３１）を、データ管理装置３Ａに送信する（ステップＳ１１３）。図８（ｆ）に示すように、インデックス登録応答メッセージ３１は、処理結果を示すパラメータで構成される。ここでは、インデックス登録応答メッセージ３１ａ（３１）として、インデックスの登録処理が成功したことを示す"success"が付されるものとする。
【００７８】
図７に戻り、データ管理装置３Ａは、ドメイン"Ｄ１"に関するルートノードの決定処理を行う（ステップＳ１１４）。ここでは、ノード決定部３１２が、サブルートキー"Ｒ０＠Ｄ１"に対応するノードとして、データ管理装置３Ｄをルートノードとして決定したものとする。
【００７９】
続いて、データ管理装置３Ａは、ルート情報登録要求メッセージ２０ｂ（２０）を、ルートノードとして決定したデータ管理装置３Ｄに送信する（ステップＳ１１５）。
【００８０】
ルート情報登録要求メッセージ２０ｂは、図８（ｇ）に示すように、サブルートキー"Ｒ０＠Ｄ１"と、識別子"ａ"と、登録日時"Ｔ０"とを含んで構成される。そして、このルート情報登録要求メッセージ２０ｂは、ルートキー"Ｒ０"と、ドメイン"Ｄ１"の登録日時"Ｔ０"における識別子"ａ"とを対応付けて管理するように要求するものである。
【００８１】
図７に戻り、ルート情報登録要求メッセージ２０ｂ（２０）を受信したデータ管理装置３Ｄは、ルート情報の保存（登録）処理を行う（ステップＳ１１６）。
【００８２】
図９（ｄ）は、ルート情報が保存（登録）されたデータ管理装置３Ｄのデータ記憶領域３００Ｄの例を示す。このデータ記憶領域３００Ｄに保存されたルート情報には、keyとしてサブルートキー"Ｒ０＠Ｄ１"、登録日時としての"Ｔ０"、失効日時として（"Ｒ０＠Ｄ１"がまだ失効されていないことを示す）"∞"、valueとしての識別子"ａ"がそれぞれ格納される。
【００８３】
図７に戻り、データ管理装置３Ｄは、ルート情報登録応答メッセージ２１ｂ（２１）を、データ管理装置３Ａに送信する（ステップＳ１１７）。図８（ｈ）に示すように、ルート情報登録応答メッセージ２１ｂには、ルート情報の登録処理が成功したことを示す"success"が付される。
【００８４】
図７に戻り、ルート情報登録応答メッセージ２１ｂ（２１）を受信したデータ管理装置３Ａは、ＩＤ登録応答メッセージ１１をゲートウェイ装置２に送信する（ステップＳ１１８）。図８（ｂ）に示すように、ＩＤ登録応答メッセージ１１には、ＩＤ登録処理が成功したことを示す"success"が付される。
【００８５】
図７に戻り、ゲートウェイ装置２は、ＩＤ登録応答メッセージ１１をクライアント装置１に送信し（ステップＳ１１９）、処理を終える。
【００８６】
このＩＤ登録処理により、各データ管理装置３のデータ記憶領域３００には、図９（ａ）〜（ｄ）に示すようなインデックスおよびルート情報が格納される。これらの情報は、図９（ｅ）に示すような日時"Ｔ０"における変換テーブルを仮想的に表現したものとみなすことができる。例えば、図９（ｅ）の一行目のデータは、ドメイン"Ｄ０"の列に識別子"０"が格納され、ドメイン"Ｄ１"の列に識別子"ａ"が格納されているが、これは、日時"Ｔ０"において、ある管理対象が、ドメイン"Ｄ０"では識別子"０"であることを示し、ドメイン"Ｄ１"では識別子"ａ"であることを示す。
【００８７】
次に、このＩＤ登録処理におけるゲートウェイ装置２およびデータ管理装置３が行う処理についてさらに詳細に説明する。
【００８８】
（ＩＤ登録処理におけるゲートウェイ装置の処理）
最初に、図７のＩＤ登録処理における、ゲートウェイ装置２の処理を詳細に説明する。図１０は、本実施形態に係るＩＤ登録処理におけるゲートウェイ装置２の処理の流れを示すフローチャートである。
【００８９】
まず、ゲートウェイ装置２の送受信部２４０が、ＩＤ登録要求メッセージ１０（図８（ａ）参照）をクライアント装置１から受信し、受信したＩＤ登録要求メッセージ１０をＩＤ登録転送部２１３に出力する（ステップＳ１２１）。
【００９０】
ＩＤ登録転送部２１３は、受信したＩＤ登録要求メッセージ１０の先頭の識別子（"０"）とドメイン（"Ｄ０"）を結合した値としてインデックスキー"０＠Ｄ０"を生成し、ノード決定部２１２に出力する（ステップＳ１２２）。
【００９１】
ノード決定部２１２が、コンシステントハッシュ法により担当ノードを決定し、決定した担当ノードの接続情報を、記憶部２５０内のノード情報記憶領域２００から取得して、ＩＤ登録転送部２１３に出力する（ステップＳ１２３）。
【００９２】
ＩＤ登録転送部２１３が、送受信部２４０を介してＩＤ登録要求メッセージ１０（図８（ａ）参照）を担当ノードに送信する（ステップＳ１２４）。
【００９３】
そして、ＩＤ登録転送部２１３が、送受信部２４０を介して、担当ノードからＩＤ登録応答メッセージ１１（図８（ｂ）参照）を受信する（ステップＳ１２５）。
【００９４】
続いて、ＩＤ登録転送部２１３は、送受信部２４０を介して、ＩＤ登録応答メッセージ１１を、クライアント装置１に送信して処理を終える（ステップＳ１２６）。
【００９５】
（ノード決定部によるノード決定処理）
次に、ノード決定部２１２，３１２によるノード決定処理について説明する（適宜図４参照）。図１１は、本実施形態に係るノード決定処理の流れを示すフローチャートである。なお、このノード決定部２１２，３１２は、ゲートウェイ装置２およびデータ管理装置３の双方の存在し、同様の処理を行うものである。また、ノード決定部２１２，３１２が参照するノード情報記憶領域２００も同じ情報がゲートウェイ装置２およびデータ管理装置３の双方に記憶される。
【００９６】
まず、ノード決定部２１２，３１２が、検索キー（ここでは、「ｑ」とする）を入力として呼び出される（ステップＳ１３１）。
【００９７】
次に、ノード決定部２１２，３１２が、ハッシュ関数Ｈに基づき、検索キーｑのハッシュ値Ｈ（ｑ）を計算する（ステップＳ１３２）。
【００９８】
続いて、ノード決定部２１２，３１２は、ノード情報記憶領域２００のノード情報に基づくリング（図４（ｂ）の閉じたハッシュ空間）４００を参照し、ハッシュ値Ｈ（ｑ）より大きい値で最も近いハッシュ値（ノードＩＤ）のノードを、その検索キーｑに関するデータの振り分け先のノードとして決定する（ステップＳ１３３）。
【００９９】
そして、ノード決定部２１２，３１２は、決定したノードの接続情報を、ノード情報記憶領域２００を参照して取得し、呼出し元に出力し処理を終える（ステップＳ１３４）。
【０１００】
（ＩＤ登録処理における担当ノードの処理）
次に、図７のＩＤ登録処理における、担当ノードであるデータ管理装置３Ａの処理を詳細に説明する。図１２および図１３は、本実施形態に係るＩＤ登録処理における担当ノード（データ管理装置３Ａ）の処理の流れを示すフローチャートである。
【０１０１】
図１２に示すように、まず、担当ノードであるデータ管理装置３（ここでは、データ管理装置３Ａ）の送受信部３４０が、ゲートウェイ装置２からＩＤ登録要求メッセージ１０（図８（ａ）参照）を受信し、受信したＩＤ登録要求メッセージ１０をＩＤ登録処理部３１４に出力する（ステップＳ１４１）。
【０１０２】
次に、ルートキー生成部３１３が、ルートキー（ここでは、「ｒ」とする）を生成する（ステップＳ１４２）。例えば、図７のステップＳ１０４のように、データ管理装置３Ａのルートキー生成部３１３が、擬似乱数生成器等を用いてルートキーｒとして"Ｒ０"を生成する。
【０１０３】
続いて、ＩＤ登録処理部３１４は、ＩＤ登録要求メッセージ１０内に、識別子，ドメイン，登録日時の組が存在するか否かを判定する（ステップＳ１４３）。そして、ＩＤ登録処理部３１４は、識別子，ドメイン，登録日時の組が存在しない場合には（ステップＳ１４３→Ｎｏ）、図１３のステップＳ１５２に進む。一方、識別子，ドメイン，登録日時の組が存在する場合には（ステップＳ１４３→Ｙｅｓ）、識別子，ドメイン，登録日時の組のうちの１つを選択し、次のステップＳ１４４に進む。
【０１０４】
ステップＳ１４４において、ＩＤ登録処理部３１４は、選択した１組の情報について、識別子とドメインとを結合した値（例えば、"０＠Ｄ０"）をインデックスキーとして生成し、ノード決定部３１２に出力する。
【０１０５】
次に、ノード決定部３１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ登録処理部３１４に出力する（ステップＳ１４５）。
【０１０６】
そして、ＩＤ登録処理部３１４は、インデックスキー、ルートキー、登録日時のパラメータを含んだインデックス登録要求メッセージ３０（図８（ｅ）参照）を、送受信部３４０を介して、インデックスノードに送信する（ステップＳ１４６）。
【０１０７】
続いて、ＩＤ登録処理部３１４は、インデックスノードからインデックス登録応答メッセージ３１（図８（ｆ）参照）を受信する（ステップＳ１４７）。
【０１０８】
図１３に移り、ＩＤ登録処理部３１４は、ルートキーとドメインとを結合した値（例えば、"Ｒ０＠Ｄ０"）をサブルートキーとして生成し、ノード決定部３１２に出力する（ステップＳ１４８）。
【０１０９】
次に、ノード決定部３１２は、コンシステントハッシュ法によりルートノードを決定し、決定したルートノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ登録処理部３１４に出力する（ステップＳ１４９）。
【０１１０】
続いて、ＩＤ登録処理部３１４は、サブルートキー、識別子、登録日時のパラメータを含んだルート情報登録要求メッセージ２０（図８（ｃ）（ｇ）参照）を、送受信部３４０を介して、ルートノードに送信する（ステップＳ１５０）。
【０１１１】
そして、ＩＤ登録処理部３１４は、ルートノードからルート情報登録応答メッセージ２１（図８（ｄ）（ｈ）参照）を受信する（ステップＳ１５１）。
【０１１２】
図１２のステップＳ１４３に戻り、ＩＤ登録処理部３１４は、識別子，ドメイン，登録日時の組が存在しない場合に（ステップＳ１４３→Ｎｏ）、図１３のステップＳ１５２に進む。そして、ＩＤ登録処理部３１４は、全ての処理が成功したか否かを判定する（ステップＳ１５２）。この判定は、例えば、ＩＤ登録処理部３１４が、所定時間以内に、要求メッセージに対する正しい応答がなされたか否かで判定する。そして、ＩＤ登録処理部３１４は、全ての処理が成功した場合には（ステップＳ１５２→Ｙｅｓ）、送受信部３４０を介して、ゲートウェイ装置２へＩＤ登録応答メッセージ１１（図８（ｂ）参照）を送信して処理を終了する（ステップＳ１５３）。一方、全ての処理が成功した場合でないときは（ステップＳ１５２→Ｎｏ）、ＩＤ登録処理部３１４は、送受信部３４０を介して、ゲートウェイ装置２にエラーメッセージを送信して処理を終了する（ステップＳ１５４）。
【０１１３】
（インデックス保存処理）
次に、図７のＩＤ登録処理のステップＳ１１２で行われる、データ管理装置３（ここでは、データ管理装置３Ｃ）のインデックスの保存（登録）処理を詳細に説明する。図１４は、本実施形態に係るインデックス保存処理におけるデータ管理装置３の処理の流れを示すフローチャートである。
【０１１４】
まず、送受信部３４０が、他のデータ管理装置３からインデックス登録要求メッセージ３０を受信すると、その受信したインデックス登録要求メッセージ３０（図８（ｅ）参照）をインデックス登録処理部３１８に出力する（ステップＳ１６１）。
【０１１５】
次に、インデックス登録処理部３１８は、インデックス登録要求メッセージ３０から、インデックスキー（ここでは"ｋ"とする），ルートキー（ここでは"ｒ"とする），登録日時（ここでは"ｔ"とする）を取得し、データ管理部３２１に出力する（ステップＳ１６２）。
【０１１６】
データ管理部３２１は、自身のデータ記憶領域３００のインデックスに、keyとしてインデックスキー"ｋ"、登録日時"ｔ"、失効日時として"∞"、valueとしてルートキー"ｒ"となる行と追加する（ステップＳ１６３）。
【０１１７】
そして、インデックス登録処理部３１８は、インデックスが保存されたことを示す"success"を含むインデックス登録応答メッセージ３１（図８（ｆ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ１６４）。
【０１１８】
（ルート情報保存処理）
次に、図７のＩＤ登録処理のステップＳ１０８，Ｓ１１６で行われる、データ管理装置３（ここでは、データ管理装置３Ｂ，３Ｄ）のルート情報の保存（登録）処理を詳細に説明する。図１５は、本実施形態に係るルート情報保存処理におけるデータ管理装置３の処理の流れを示すフローチャートである。
【０１１９】
まず、送受信部３４０が、他のデータ管理装置３からルート情報登録要求メッセージ２０（図８（ｃ）（ｇ）参照）を受信すると、その受信したルート情報登録要求メッセージ２０をルート情報登録処理部３１９に出力する（ステップＳ１７１）。
【０１２０】
次に、ルート情報登録処理部３１９は、ルート情報登録要求メッセージ２０から、サブルートキー（ここでは"ｓ"とする），識別子（ここでは"ｉ"とする），登録日時（ここでは"ｔ"とする）を取得し、データ管理部３２１に出力する（ステップＳ１７２）。
【０１２１】
データ管理部３２１は、自身のデータ記憶領域３００のルート情報に、keyとしてサブルートキー"s"、登録日時"ｔ"、失効日時として"∞"、valueとして識別子"ｉ"となる行を追加する（ステップＳ１７３）。
【０１２２】
そして、ルート情報登録処理部３１９は、ルート情報が保存されたことを示すルート情報登録応答メッセージ２１（図８（ｄ）（ｈ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ１７４）。
【０１２３】
このようにすることで、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１から取得したＩＤ登録要求メッセージ１０（図８（ａ）参照）に含まれる登録情報を、ゲートウェイ装置２を介して、インデックスおよびルート情報という保存形式により、分散させてデータ管理装置３に保存することができる。
【０１２４】
なお、本例では、「識別子」，「ドメイン」，「登録日時」の組となる登録情報について、図８（ａ）に示すように、第１の登録情報（符号１０−１）と第２の登録情報（符号１０−２）の２組を登録する場合を例に説明した。しかし、本発明は、登録情報について２組に限定されるものではなく、２組以上であれば、例えば、第３の登録情報、第４の登録情報、第５の登録情報のように、第ｉ（ｉ番目）の登録情報までを含めて本実施形態に係るＩＤ登録処理で、各データ管理装置３に登録することもできる。
【０１２５】
その場合、ゲートウェイ装置２から、ｉ個の登録情報が含まれるＩＤ登録要求メッセージ１０を受信した第１のデータ管理装置３（３Ａ）のノード決定部３１２は、第ｉ（ｉ番目：ｉは１以上の整数）の登録情報についてＩＤ登録処理部３１４が生成した第ｉインデックスキーにハッシュ関数を適用してハッシュ値を算出し、ノード情報のノードＩＤを参照して決定したデータ管理装置３として、第ｉインデックスの登録先を、（２×ｉ−１）番目のデータ管理装置３に決定することができる。また、第１のデータ管理装置３（３Ａ）のノード決定部３１２は、第ｉ（ｉ番目）の登録情報についてＩＤ登録処理部３１４が生成した第ｉ（ｉ番目）サブルートキーにハッシュ関数を適用してハッシュ値を算出し、ノード情報のノードＩＤを参照して決定したデータ管理装置３として、第ｉルート情報の登録先を、（２×ｉ）番目のデータ管理装置３に決定することができる。
つまり、本実施形態に係る分散ＩＤ管理システム５は、ｉ個の登録情報が含まれるＩＤ登録要求メッセージ１０を受信した場合であっても、ｉ個の登録情報を、インデックスおよびルート情報という形式で分散して複数のデータ管理装置３に保存することができる。
【０１２６】
＜ＩＤ変換処理＞
次に、図１６〜図２０を参照して、図７に示したＩＤ登録処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理について説明する。
【０１２７】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン"Ｄ０"の日時"Ｔ１"における識別子"０"を、ドメイン"Ｄ１"の同日時"Ｔ１"における識別子へ変換する処理（つまり、ドメイン"Ｄ０"の日時"Ｔ１"における識別子"０"に対応する、ドメイン"Ｄ１"の同日時"Ｔ１"における識別子を検索する処理）、について説明する。ここで、"Ｔ１"は、"Ｔ０"よりも未来の日時を示すものとする。
【０１２８】
（ＩＤ変換処理の全体の流れ）
図１６は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ変換処理の全体の流れを示すシーケンス図である。
【０１２９】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ａ（４０）をゲートウェイ装置２に送信する（ステップＳ２０１）。
【０１３０】
図１７（ａ）は、ＩＤ変換要求メッセージ４０を例示する図である。図１７（ａ）に示すように、ＩＤ変換要求メッセージ４０は、「変換元識別子」，「変換元ドメイン」，「変換元日時」，「変換先ドメイン」，「変換先日時」のパラメータを含んで構成される。図１７（ａ）に例示するＩＤ変換要求メッセージ４０ａ（４０）は、変換元であるドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ１"における識別子（変換元識別子）"０"を、ドメイン（変換先ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ１"における識別子へ変換する（変換先となる識別子を検索する）処理を要求するものである。
【０１３１】
図１６に戻り、ＩＤ変換要求メッセージ４０ａ（４０）を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ２０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"０＠Ｄ０"に対応するノードであるデータ管理装置３Ａが、インデックスノードとして決定される。
【０１３２】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ａ（４０）を、インデックスノードとして決定したデータ管理装置３Ａに送信する（ステップＳ２０３）。
【０１３３】
ＩＤ変換要求メッセージ４０ａ（４０）を受信したデータ管理装置３Ａは、ルートキーの取得処理を行う（ステップＳ２０４）。ルートキーの取得は、インデックスキー（"０＠Ｄ０"）をキーとして、データ格納領域３００Ａ内のインデックス（図９（ａ）参照）を検索し、変換元日時Ｔ１が登録日時と失効日時の間に含まれる行から行われる。ここでは、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０１３４】
次に、データ管理装置３Ａは、ルートノードの決定処理を行う（ステップＳ２０５）。ここでは、サブルートキー"Ｒ０＠Ｄ１"に対応するノードとして、データ管理装置３Ｄが、ルートノードとして決定される。
【０１３５】
続いて、データ管理装置３Ａは、ＩＤ取得要求メッセージ５０ａ（５０）を、ルートノードとして決定したデータ管理装置３Ｄに送信する（ステップＳ２０６）。
【０１３６】
図１７（ｃ）は、ＩＤ取得要求メッセージ５０を例示する図である。図１７（ｃ）に示すように、ＩＤ取得要求メッセージ５０は、「サブルートキー」，「変換先日時」のパラメータを含んで構成される。図１７（ｃ）に例示するＩＤ取得要求メッセージ５０ａ（５０）は、サブルートキー"Ｒ０＠Ｄ１"に紐付く識別子の内、変換先日時"Ｔ１"で有効なものの取得を要求するものであることを示す。
【０１３７】
図１６に戻り、ＩＤ取得要求メッセージ５０ａ（５０）を受信したデータ管理装置３Ｄは、ＩＤ（識別子）の取得処理を行う（ステップＳ２０７）。ＩＤ（識別子）の取得は、サブルートキー"Ｒ０＠Ｄ１"をキーとして、データ格納領域３００Ｄ内のルート情報（図９（ｄ）参照）を検索し、変換先日時Ｔ１が、登録日時と失効日時の間に含まれるような行から行われる。ここでは、図９（ｄ）に示すルート情報から、識別子として"ａ"が取得される。
【０１３８】
次に、データ管理装置３Ｄは、ＩＤ取得応答メッセージ５１ａ（５１）を生成し、データ管理装置３Ａに送信する（ステップＳ２０８）。図１７（ｄ）に示すように、ＩＤ取得応答メッセージ５１ａには、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０１３９】
続いて、データ管理装置３Ａは、ＩＤ変換応答メッセージ４１ａ（４１）を生成し、ゲートウェイ装置２に送信する（ステップＳ２０９）。図１７（ｂ）に示すように、ＩＤ変換応答メッセージ４１ａには、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０１４０】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ａ（４１）をクライアント装置１に送信し、処理を終える（ステップＳ２１０）。
【０１４１】
次に、このＩＤ変換処理におけるゲートウェイ装置２およびデータ管理装置３が行う処理についてさらに詳細に説明する。
【０１４２】
（ＩＤ変換処理におけるゲートウェイ装置の処理）
最初に、図１６のＩＤ変換処理における、ゲートウェイ装置２の処理の詳細を説明する。図１８は、本実施形態に係るＩＤ変換処理におけるゲートウェイ装置２の処理の流れを示すフローチャートである。
【０１４３】
まず、ゲートウェイ装置２の送受信部２４０が、ＩＤ変換要求メッセージ４０（図１７（ａ）参照）をクライアント装置１から受信し、受信したＩＤ変換要求メッセージ４０をＩＤ変換転送部２１４に出力する（ステップＳ２２１）。
【０１４４】
ＩＤ変換転送部２１４は、受信したＩＤ変換要求メッセージ４０の変換元識別子"０"と変換元ドメイン"Ｄ０"を結合した値としてインデックスキー"０＠Ｄ０"を生成し、ノード決定部２１２に出力する（ステップＳ２２２）。
【０１４５】
ノード決定部２１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部２５０内のノード情報記憶領域２００から取得して、ＩＤ変換転送部２１４に出力する（ステップＳ２２３）。
【０１４６】
ＩＤ変換転送部２１４は、送受信部２４０を介して、ＩＤ変換要求メッセージ４０を、決定したインデックスノードに送信する（ステップＳ２２４）。
【０１４７】
そして、ＩＤ変換転送部２１４は、送受信部２４０を介して、インデックスノードからＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を受信する（ステップＳ２２５）。
【０１４８】
続いて、ＩＤ変換転送部２１４は、送受信部２４０を介して、ＩＤ変換応答メッセージ４１を、クライアント装置１に送信して処理を終える（ステップＳ２２６）。
【０１４９】
（ＩＤ変換処理におけるデータ管理装置の処理）
次に、図１６のＩＤ変換処理における、データ管理装置３（ここでは、データ管理装置３Ａ）の処理を詳細に説明する。図１９は、本実施形態に係るＩＤ変換処理におけるデータ管理装置３（３Ａ）の処理の流れを示すフローチャートである。
【０１５０】
まず、データ管理装置３（ここでは、データ管理装置３Ａ）の送受信部３４０が、ゲートウェイ装置２からＩＤ変換要求メッセージ４０（図１７（ａ）参照）を受信し、ＩＤ変換処理部３１５に出力する（ステップＳ２３１）。
【０１５１】
次に、ＩＤ変換処理部３１５は、ＩＤ変換要求メッセージ４０に含まれる、変換元識別子（ここでは、「ｉ」とする），変換元ドメイン（ここでは、「ｄ」とする），変換元日時（ここでは、「ｔ」とする），変換先ドメイン（ここでは、「ｄ'」とする），変換先日時（ここでは「ｔ'」とする）を取得する。ＩＤ変換処理部３１５は、変換元識別子ｉと変換元ドメインｄとを結合した値（ｉ＠ｄ）としてインデックスキーを生成する。具体的には、ＩＤ変換処理部３１５は、インデックスキー"０＠Ｄ０"を生成する。そして、ＩＤ変換処理部３１５は、生成したインデックスキー（ｉ＠ｄ）と、変換元日時ｔとを、データ管理部３２１に出力する（ステップＳ２３２）。
【０１５２】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、図９（ａ）のデータ記憶領域３００Ａ）に記憶されたインデックスから、条件［key＝ｉ＠ｄ かつ 登録日時≦ｔ＜失効日時］を満たす行を検索する（ステップＳ２３３）。
【０１５３】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ２３４）、条件を満たす行が存在しない場合には（ステップＳ２３４→Ｎｏ）、ステップＳ２４２に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ２３４→Ｙｅｓ）、次のステップＳ２３５へ進む。
【０１５４】
ステップＳ２３５において、データ管理部３２１は、条件を満たす行のvalueの値からルートキー（「ｒ」）を取得し、ＩＤ変換処理部３１５に出力する。ここでは、データ管理部３２１が、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"を取得し、ＩＤ変換処理部３１５に出力する。
【０１５５】
次に、ＩＤ変換処理部３１５は、ルートキーｒと変換先ドメインｄ'を結合した値（ｒ＠ｄ'）としてサブルートキーを生成する。ここでは、ＩＤ変換処理部３１５は、サブルートキー"Ｒ０＠Ｄ１"を生成する。そして、ＩＤ変換処理部３１５は、生成したサブルートキー（ｒ＠ｄ'）をノード決定部３１２に出力する（ステップＳ２３６）。
【０１５６】
続いて、ノード決定部３１２が、コンシステントハッシュ法によりルートノードとなるノードを決定し、決定したルートノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ変換処理部３１５に出力する（ステップＳ２３７）。
【０１５７】
ＩＤ変換処理部３１５は、サブルートキー（ｒ＠ｄ'）と変換先日時ｔ'とを含むＩＤ取得要求メッセージ５０（図１７（ｃ）参照）を生成し、送受信部３４０を介して、ルートノードに送信する（ステップＳ２３８）。
【０１５８】
そして、ＩＤ変換処理部３１５は、ルートノードから、送受信部３４０を介して、変換先のＩＤ（識別子）を含むＩＤ取得応答メッセージ５１（図１７（ｄ）参照）を受信する（ステップＳ２３９）。
【０１５９】
ＩＤ変換処理部３１５は、ＩＤ（識別子）の取得に成功したか否かを判定し（ステップＳ２４０）、成功していない場合には（ステップＳ２４０→Ｎｏ）、ステップＳ２４２に進む。一方、ＩＤ変換処理部３１５は、ＩＤ（識別子）の取得に成功した場合には（ステップＳ２４０→Ｙｅｓ）、次のステップＳ２４１へ進む。
【０１６０】
ステップＳ２４１において、ＩＤ変換処理部３１５は、ＩＤ取得応答メッセージ５１から取得したＩＤ（識別子）を含む、ＩＤ変換応答メッセージ４１（図１７（ｂ）参照）を生成し、送受信部３４０を介して、ゲートウェイ装置２に送信し、処理を終える。
【０１６１】
また、ステップＳ２３４において条件を満たす行がない場合（ステップＳ２３４→Ｎｏ）、または、ステップＳ２４０においてＩＤ（識別子）の取得に成功していない場合（ステップＳ２４０→Ｎｏ）には、ＩＤ変換処理部３１５が、エラーメッセージを生成し、送受信部３４０を介して、ゲートウェイ装置２に送信し、処理を終える（ステップＳ２４２）。
【０１６２】
（ＩＤ取得処理）
次に、図１６のＩＤ変換処理のステップＳ２０７で行われる、ＩＤ取得処理を詳細に説明する。図２０は、本実施形態に係るＩＤ取得処理におけるデータ管理装置３（ここでは、データ管理装置３Ｄ）の処理の流れを示すフローチャートである。
【０１６３】
まず、送受信部３４０が、他のデータ管理装置３からＩＤ取得要求メッセージ５０（図１７（ｃ）参照）を受信すると、その受信したＩＤ取得要求メッセージ５０をＩＤ取得処理部３１７に出力する（ステップＳ２５１）。
【０１６４】
次に、ＩＤ取得処理部３１７は、ＩＤ取得要求メッセージ５０から、サブルートキー（ｒ＠ｄ）と、変換先日時ｔ'とを取得し、データ管理部３２１に出力する（ステップＳ２５２）。
【０１６５】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、データ記憶領域３００Ｄ）に記憶されたルート情報から、条件［key＝ｒ＠ｄ かつ 登録日時≦ｔ'＜失効日時］を満たす行を検索する（ステップＳ２５３）。
【０１６６】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ２５４）、条件を満たす行が存在しない場合には（ステップＳ２５４→Ｎｏ）、ステップＳ２５７に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ２５４→Ｙｅｓ）、次のステップＳ２５５へ進む。
【０１６７】
ステップＳ２５５において、データ管理部３２１は、条件を満たす行のvalueの値から識別子ｉを取得し、ＩＤ取得処理部３１７に出力する。ここでは、データ管理部３２１が、図９（ｄ）に示すルート情報から、変換先の識別子（変換先識別子）ｉとして"ａ"を取得し、ＩＤ取得処理部３１７に出力する。
【０１６８】
次に、ＩＤ取得処理部３１７は、変換先の識別子ｉ（ここでは"ａ"）を含むＩＤ取得応答メッセージ５１（図１７（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ２５６）。
【０１６９】
また、ステップＳ２５４において、条件を満たす行が存在しない場合には（ステップＳ２５４→Ｎｏ）、ＩＤ取得処理部３１７は、エラーメッセージを生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ２５７）。
【０１７０】
このようにすることで、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１から取得したＩＤ変換要求メッセージ４０（図１７（ａ）参照）に含まれる「変換元識別子」「変換元ドメイン」「変換元日時」「変換先ドメイン」「変換先日時」のパラメータを用いて、「変換元識別子」を「変換先識別子」に変換する、つまり、「変換先識別子」を検索することができる。
【０１７１】
＜ＩＤ更新処理＞
次に、図２１〜図２７を参照して、図７に示したＩＤ登録処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの更新を要求（ＩＤ更新要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ更新処理について説明する。
【０１７２】
ここでは、クライアント装置１が要求するＩＤ更新処理の例として、ドメイン（更新対象ドメイン）"Ｄ０"の日時（更新対象日時）"Ｔ１"における識別子（更新対象識別子）"０"を、日時（更新日時）"Ｔ２"以降は識別子（更新後識別子）"９"に置き換える（更新する）処理について説明する。ここで、"Ｔ２"は"Ｔ１"よりも未来の日時を示すものとする。
【０１７３】
（ＩＤ更新処理の全体の流れ）
図２１は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理の全体の流れを示すシーケンス図である。
【０１７４】
まず、クライアント装置１は、ＩＤ更新要求メッセージ６０をゲートウェイ装置２に送信する（ステップＳ３０１）。
【０１７５】
図２２（ａ）は、ＩＤ更新要求メッセージ６０を例示する図である。図２２（ａ）に示すように、ＩＤ更新要求メッセージ６０は、「更新対象識別子」，「更新対象ドメイン」，「更新対象日時」，「更新後識別子」，「更新日時」のパラメータを含んで構成される。図２２（ａ）に例示するＩＤ更新要求メッセージ６０は、ドメイン（更新対象ドメイン）"Ｄ０"の日時（更新対象日時）"Ｔ１"における識別子（更新対象識別子）"０"を更新元として、日時（更新日時）"Ｔ２"以降は識別子（更新後識別子）"９"に置き換える（更新する）処理を要求するものである。
【０１７６】
図２１に戻り、ＩＤ更新要求メッセージ６０を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ３０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"０＠Ｄ０"に対応するノードであるデータ管理装置３Ａが、インデックスノードとして決定される。
【０１７７】
続いて、ゲートウェイ装置２は、ＩＤ更新要求メッセージ６０を、インデックスノードとして決定したデータ管理装置３Ａに送信する（ステップＳ３０３）。
【０１７８】
ＩＤ更新要求メッセージ６０を受信したデータ管理装置３Ａは、ルートキーの取得処理を行う（ステップＳ３０４）。ルートキーの取得は、インデックスキー（"０＠Ｄ０"）をキーとして、データ格納領域３００Ａ内のインデックス（図９（ａ）参照）を検索し、更新対象日時"Ｔ１"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０１７９】
次に、データ管理装置３Ａは、インデックスの失効処理を行う（ステップＳ３０５）。このインデックスの失効処理は、ステップＳ３０４において、インデックスから、ルートキー"Ｒ０"を取得した行の失効日時を更新日時で更新することにより行う。
【０１８０】
図２３（ａ）に、インデックスの失効処理後のデータ管理装置３Ａのデータ記憶領域３００Ａの例を示す。ここでは、インデックス"０＠Ｄ０"に対応する行において、失効日時が"∞"から"Ｔ２"に更新されている。
【０１８１】
図２１に戻り、次に、データ管理装置３Ａは、更新対象のルートノードの決定処理を行う（ステップＳ３０６）。ここでは、ノード決定部３１２が、サブルートキー"Ｒ０＠Ｄ０"に対応するノードとして、データ管理装置３Ｂを、ルートノードとして決定する。
【０１８２】
続いて、データ管理装置３Ａは、ルート情報更新要求メッセージ７０を、ルートノードとして決定したデータ管理装置３Ｂに送信する（ステップＳ３０７）。
【０１８３】
図２２（ｃ）は、ルート情報更新要求メッセージ７０を例示する図である。図２２（ｃ）に示すように、ルート情報更新要求メッセージ７０は、「サブルートキー」，「更新後識別子」，「更新日時」のパラメータを含んで構成される。図２２（ｃ）に示すルート情報更新要求メッセージ７０は、日時（更新日時）"Ｔ２"以降、サブルートキー"Ｒ０＠Ｄ０"に紐付く識別子（更新後識別子）として"９"を用いるように更新することを要求するものである。
【０１８４】
図２１に戻り、ルート情報更新要求メッセージ７０を受信したデータ管理装置３Ｂは、ルート情報の更新処理を行う（ステップＳ３０８）。
【０１８５】
図２３（ｂ）に、ルート情報更新後のデータ管理装置３Ｂのデータ記憶領域３００Ｂの例を示す。ここでは、サブルートキー"Ｒ０＠Ｄ０"に対応する行において、登録日時"Ｔ０"の行では、失効日時が"∞"から更新日時である"Ｔ２"に更新されている。また、サブルートキー"Ｒ０＠Ｄ０"の新たな行が追加され、keyとしてサブルートキー"Ｒ０＠Ｄ０"、登録日時として更新後日時"Ｔ２"、失効日時として"∞"、valueとして識別子（更新後識別子）"９"が、それぞれ格納される。
【０１８６】
図２１に戻り、データ管理装置３Ｂは、ルート情報更新応答メッセージ７１（図２２（ｄ）参照）を、データ管理装置３Ａに送信する（ステップＳ３０９）。図２２（ｄ）に示すように、ルート情報更新応答メッセージ７１には、ルート情報の更新処理が成功したことを示す"success"が付される。
【０１８７】
次に、データ管理装置３Ａは、インデックスノードの決定処理を行う（ステップＳ３１０）。ここでは、例えば、インデックスキー"９＠Ｄ０"に対応するノードであるデータ管理装置３Ｅが、インデックスノードとして決定される。
【０１８８】
続いて、データ管理装置３Ａは、インデックス登録要求メッセージ３０ｂ（３０）を、インデックスノードとして決定したデータ管理装置３Ｅに送信する（ステップＳ３１１）。
【０１８９】
図２２（ｅ）は、インデックス登録要求メッセージ３０を例示する図である。図２２（ｅ）に例示するインデックス登録要求メッセージ３０ｂは、ルートキー"Ｒ０"と、ドメイン"Ｄ０"の登録日時"Ｔ２"における識別子"９"とを対応付けて管理するように要求するものである。
【０１９０】
図２１に戻り、インデックス登録要求メッセージ３０ｂを受信したデータ管理装置３Ｅは、インデックスの保存処理を行う（ステップＳ３１２）。
【０１９１】
図２３（ｅ）は、インデックスが保存されたデータ管理装置３Ｅのデータ記憶領域３００Ｅの例を示す。このデータ記憶領域３００Ｅに保存されたインデックスには、keyとしてのインデックスキー"９＠Ｄ０"、登録日時としての"Ｔ２"、失効日時として（"９＠Ｄ０"がまだ失効されていないことを示す）"∞"、valueとしてのルートキー"Ｒ０"がそれぞれ格納される。
【０１９２】
図２１に戻り、データ管理装置３Ｅは、インデックス登録応答メッセージ３１ｂ（３１）を生成し、データ管理装置３Ａに送信する（ステップＳ３１３）。図２２（ｆ）に示すように、インデックス登録応答メッセージ３１ｂは、インデックスの登録処理が成功したことを示す"success"が付される。
【０１９３】
インデックス登録応答メッセージ３１ｂを受信したデータ管理装置３Ａは、ＩＤ更新応答メッセージ６１を生成し、ゲートウェイ装置２に送信する（ステップＳ３１４）。図２２（ｂ）に示すように、ＩＤ更新応答メッセージ６１には、ＩＤ更新処理が成功したことを示す"success"が付される。
【０１９４】
そして、ゲートウェイ装置２は、ＩＤ更新応答メッセージ６１をクライアント装置１に送信し（ステップＳ３１５）、処理を終える。
【０１９５】
このＩＤ更新処理により、各データ管理装置３のデータ記憶領域３００には、図２３（ａ）〜（ｅ）に示すような値が格納される。これらの値は、図２３（ｆ）に示すような日時"Ｔ２"における変換テーブルを仮想的に実現したものとみなすことができる。例えば、図２３（ｆ）の一行目のデータは、ドメイン"Ｄ０"の列に識別子"９"が格納され、ドメイン"Ｄ１"の列に識別子"ａ"が格納されているが、これは、日時"Ｔ２"において、ある管理対象が、ドメイン"Ｄ０"では識別子"９"を持ち、ドメイン"Ｄ１"では識別子"ａ"を持つことを示す。
【０１９６】
次に、このＩＤ更新処理におけるゲートウェイ装置２およびデータ管理装置３が行う処理についてさらに詳細に説明する。
【０１９７】
（ＩＤ更新処理におけるゲートウェイ装置の処理）
次に、図２１のＩＤ更新処理における、ゲートウェイ装置２の処理の詳細を説明する。
図２４は、本実施形態に係るＩＤ更新処理におけるゲートウェイ装置２の処理の流れを示すフローチャートである。
【０１９８】
まず、ゲートウェイ装置２の送受信部２４０が、ＩＤ更新要求メッセージ６０（図２２（ａ）参照）をクライアント装置１から受信し、受信したＩＤ更新要求メッセージ６０をＩＤ更新転送部２１５に出力する（ステップＳ３２１）。
【０１９９】
ＩＤ更新転送部２１５は、受信したＩＤ更新要求メッセージ６０の更新対象識別子"０"と更新対象ドメイン"Ｄ０"を結合した値としてインデックスキー"０＠Ｄ０"を生成し、ノード決定部２１２に出力する（ステップＳ３２２）。
【０２００】
ノード決定部２１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部２５０内のノード情報記憶領域２００から取得して、ＩＤ更新転送部２１５に出力する（ステップＳ３２３）。
【０２０１】
ＩＤ更新転送部２１５は、送受信部２４０を介して、ＩＤ更新要求メッセージ６０を、決定したインデックスノードに送信する（ステップＳ３２４）。
【０２０２】
そして、ＩＤ更新転送部２１５は、送受信部２４０を介して、インデックスノードから、ＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を受信する（ステップＳ３２５）。
【０２０３】
続いて、ＩＤ更新転送部２１５は、送受信部２４０を介して、ＩＤ更新応答メッセージ６１を、クライアント装置１に送信して処理を終える（ステップＳ３２６）。
【０２０４】
（ＩＤ更新処理におけるデータ管理装置の処理）
次に、図２１のＩＤ更新処理における、データ管理装置３（ここでは、データ管理装置３Ａ）の処理の詳細に説明する。図２５および図２６は、本実施形態に係るＩＤ更新処理におけるデータ管理装置３（３Ａ）の処理の流れを示すフローチャートである。
【０２０５】
図２５において、まず、データ管理装置３（ここでは、データ管理装置３Ａ）の送受信部３４０が、ゲートウェイ装置２からＩＤ更新要求メッセージ６０（図２２（ａ）参照）を受信し、ＩＤ更新処理部３１６に出力する（ステップＳ３３１）。
【０２０６】
次に、ＩＤ更新処理部３１６は、ＩＤ更新要求メッセージ６０に含まれる、更新対象識別子（ここでは、「ｉ」とする），更新対象ドメイン（ここでは、「ｄ」とする），更新対象日時（ここでは、「ｔ」とする），更新後識別子（ここでは、「ｉ'」とする），更新日時（ここでは、「ｔ'」とする）を取得する。ＩＤ更新処理部３１６は、更新対象識別子ｉと更新対象ドメインｄとを結合した値（ｉ＠ｄ）としてインデックスキーを生成する。ここでは、ＩＤ更新処理部３１６は、インデックスキー"０＠Ｄ０"を生成する。そして、ＩＤ更新処理部３１６は、生成したインデックスキー（ｉ＠ｄ）と、更新対象日時ｔとを、データ管理部３２１に出力する（ステップＳ３３２）。
【０２０７】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、データ記憶領域３００Ａ）に記憶されたインデックスから、条件［key＝ｉ＠ｄ かつ 登録日時≦ｔ＜失効日時］を満たす行を検索する（ステップＳ３３３）。
【０２０８】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ３３４）、条件を満たす行が存在しない場合には（ステップＳ３３４→Ｎｏ）、図２６のステップＳ３４７に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ３３４→Ｙｅｓ）、次のステップＳ３３５へ進む。
【０２０９】
ステップＳ３３５において、データ管理部３２１は、条件を満たす行のvalueの値からルートキー（「ｒ」）を取得し、ＩＤ更新処理部３１６に出力する。ここでは、データ管理部３２１が、図９（ａ）に示すインデックスから、ルートキーとして"Ｒ０"を取得し、ＩＤ更新処理部３１６に出力する。
【０２１０】
次に、ＩＤ更新処理部３１６は、データ管理部３２１を介して、当該行の失効日時を"∞"から更新日時ｔ'に更新する（ステップＳ３３６）。
【０２１１】
続いて、ＩＤ更新処理部３１６は、ルートキーｒと更新対象ドメインｄとを結合した値（ｒ＠ｄ）としてサブルートキーを生成する。ここでは、ＩＤ更新処理部３１６は、サブルートキー"Ｒ０＠Ｄ０"を生成する。そして、ＩＤ更新処理部３１６は、生成したサブルートキー（ｒ＠ｄ）をノード決定部３１２に出力する（ステップＳ３３７）。
【０２１２】
そして、ノード決定部３１２は、コンシステントハッシュ法によりルートノードとなるノードを決定し、決定したルートノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ更新処理部３１６に出力する（ステップＳ３３８）。
【０２１３】
ＩＤ更新処理部３１６は、サブルートキー（ｒ＠ｄ）、更新後識別子ｉ'、更新日時ｔ'を含むルート情報更新要求メッセージ７０（図２２（ｃ）参照）を生成し、送受信部３４０を介して、ルートノードに送信する（ステップＳ３３９）。
【０２１４】
そして、ＩＤ更新処理部３１６は、ルートノードから、送受信部３４０を介して、ルート情報更新応答メッセージ７１（図２２（ｄ）参照）を受信する（ステップＳ３４０）。
【０２１５】
図２６に移り、ＩＤ更新処理部３１６は、更新後識別子ｉ'と更新対象ドメインｄとを結合した値（ｉ'＠ｄ）としてインデックスキーを生成する。ここでは、ＩＤ更新処理部３１６は、インデックスキー"９＠Ｄ０"を生成する。そして、ＩＤ更新処理部３１６は、生成したインデックスキー"９＠Ｄ０"をノード決定部３１２に出力する（ステップＳ３４１）。
【０２１６】
次に、ノード決定部３１２は、コンシステントハッシュ法によりインデックスノードとなるノードを決定し、決定したインデックスノードの接続情報を、記憶部３５０内のノード情報記憶領域２００から取得して、ＩＤ更新処理部３１６に出力する（ステップＳ３４２）。
【０２１７】
そして、ＩＤ更新処理部３１６は、インデックス登録処理部３１８を介して、インデックス登録要求メッセージ３０ｂ（図２２（ｅ）参照）を生成し、インデックスノードへ送信する（ステップＳ３４３）。このインデックス登録要求メッセージ３０ｂには、インデックスキー"９＠Ｄ０"、ルートキー"Ｒ０"、登録日時"Ｔ２"の情報が含まれる。
【０２１８】
続いて、ＩＤ更新処理部３１６は、インデックスノードから、受信部３４０を介して、インデックス登録応答メッセージ３１ｂ（図２２（ｆ）参照）を受信する（ステップＳ３４４）。
【０２１９】
次に、ＩＤ更新処理部３１６は、ＩＤ更新処理に関する全ての処理が成功したが否かを判定し（ステップＳ３４５）、１つでも成功していない処理がある場合には（ステップＳ３４５→Ｎｏ）、ステップＳ３４７に進む。一方、ＩＤ更新処理部３１６は、全ての処理が成功した場合には（ステップＳ３４５→Ｙｅｓ）、次のステップＳ３４６に進む。
【０２２０】
ステップＳ３４６において、ＩＤ更新処理部３１６は、送受信部３４０を介して、ゲートウェイ装置２へＩＤ更新応答メッセージ６１（図２２（ｂ）参照）を送信して、処理を終了する。
【０２２１】
また、図２５のステップＳ３３４において条件を満たす行が存在しない場合（ステップＳ３３４→Ｎｏ）、または、図２６のステップＳ３４５において１つでも成功していない処理がある場合（ステップＳ３４５→Ｎｏ）には、ＩＤ更新処理部３１６は、ゲートウェイ装置２へエラーメッセージを送信して、処理を終了する（ステップＳ３４７）。
【０２２２】
（ルート情報更新処理）
次に、図２１のＩＤ更新処理のステップＳ３０８で行われる、データ管理装置３（ここでは、データ管理装置３Ｂ）のルート情報更新処理を詳細に説明する。図２７は、本実施形態に係るＩＤ更新処理におけるデータ管理装置３（３Ｂ）のルート情報更新処理の流れを示すフローチャートである。
【０２２３】
まず、送受信部３４０が、他のデータ管理装置３からルート情報更新要求メッセージ７０（図２２（ｃ）参照）を受信すると、その受信したルート情報更新要求メッセージ７０をルート情報更新処理部３２０に出力する（ステップＳ３５１）。
【０２２４】
次に、ルート情報更新処理部３２０は、ルート情報更新要求メッセージ７０から、サブルートキー（ｒ＠ｄ）と、更新後識別子（ｉ'）と、更新日時（ｔ'）とを取得し、データ管理部３２１に出力する（ステップＳ３５２）。
【０２２５】
続いて、データ管理部３２１は、データ記憶領域３００（ここでは、データ記憶領域３００Ｂ）に記憶されたルート情報から、条件［key＝ｒ＠ｄ かつ 登録日時≦ｔ'＜失効日時］を満たす行を検索する（ステップＳ３５３）。
【０２２６】
そして、データ管理部３２１は、条件を満たす行が存在するか否かを判定し（ステップＳ３５４）、条件を満たす行が存在しない場合には（ステップＳ３５４→Ｎｏ）、ステップＳ３５８に進む。一方、データ管理部３２１は、条件を満たす行が存在する場合には（ステップＳ３５４→Ｙｅｓ）、次のステップＳ３５５へ進む。
【０２２７】
ステップＳ３５５において、ルート情報更新処理部３２０は、データ管理部３２１を介して、条件を満たす行の失効日時を"∞"から更新日時ｔ'に更新する。
【０２２８】
次に、データ管理部３２１は、データ記憶領域３００のルート情報に、keyとしてサブルートキー（ｒ＠ｄ）、登録日時として更新日時（ｔ'）、失効日時として"∞"、valueとして更新後識別子（ｉ'）となる行と追加する（ステップＳ３５６）。
【０２２９】
そして、ルート情報更新処理部３２０は、ルート情報が更新されたことを示すルート情報更新応答メッセージ７１（図２２（ｄ）参照）を生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ３５７）。
【０２３０】
また、ステップＳ３５４において、条件を満たす行がない場合には（ステップＳ３５４→Ｎｏ）、ルート情報更新処理部３２０は、エラーメッセージを生成し、送受信部３４０を介して、要求元のデータ管理装置３に送信して処理を終える（ステップＳ３５８）。
【０２３１】
このようにすることで、本実施形態に係る分散ＩＤ管理システム５は、クライアント装置１から取得したＩＤ更新要求メッセージ６０（図２２（ａ）参照）に基づき、ある「更新対象ドメイン」における「更新日時」以降の識別子を、それまで登録されていた「更新対象識別子」から新たな識別子である「更新後識別子」に更新することができる。
【０２３２】
≪ＩＤ更新処理後のＩＤ変換処理の具体例≫
次に、本実施形態に係る分散ＩＤ管理システム５において、図２１で示したＩＤ更新処理が行われた後における、ＩＤ変換処理を３例説明する。１例目と２例目は、ＩＤ更新処理後のＩＤ変換処理が正常に行われる例を示し、３例目は、不正なＩＤ変換処理の要求を受けたため、ＩＤ変換処理が失敗する例を示す。これらは、ＩＤ更新処理後においても、正常にＩＤ変換処理が実行できることを説明するための例である。
【０２３３】
＜ＩＤ更新処理後のＩＤ変換処理（１）＞
まず、図２８，図２９を参照して、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理（１）について説明する。
【０２３４】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"９"を、ドメイン（変換先ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理（つまり、ドメイン"Ｄ０"の日時"Ｔ３"における識別子"９"に対応する、ドメイン"Ｄ１"の同日時"Ｔ３"における識別子を検索する処理）、について説明する。ここで、"Ｔ３"は"Ｔ２"よりも未来の日時を示すものとする。
【０２３５】
（ＩＤ変換処理の全体の流れ）
図２８は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理後のＩＤ変換処理（１）の全体の流れを示すシーケンス図である。ここでは、前記した図２１に示すＩＤ更新処理がすでに行われ、各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ）のデータ記憶領域３００には、図２３に示すデータが記憶されているものとして説明する。
【０２３６】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ｂ（４０）をゲートウェイ装置２に送信する（ステップＳ４０１）。
【０２３７】
図２９（ａ）は、ＩＤ変換要求メッセージ４０ｂ（４０）を例示する図である。図２９（ａ）に示すＩＤ変換要求メッセージ４０ｂ（４０）は、変換元であるドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"９"を、ドメイン（変換後ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理を要求するものである。
【０２３８】
図２８に戻り、ＩＤ変換要求メッセージ４０ｂを受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ４０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"９＠Ｄ０"に対応するノードであるデータ管理装置３Ｅが、インデックスノードとして決定される。
【０２３９】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ｂ（４０）を、インデックスノードとして決定したデータ管理装置３Ｅに送信する（ステップＳ４０３）。
【０２４０】
ＩＤ変換要求メッセージ４０ｂ（４０）を受信したデータ管理装置３Ｅは、ルートキーの取得処理を行う（ステップＳ４０４）。ルートキーの取得は、インデックスキー"９＠Ｄ０"をキーとして、データ格納領域３００Ｅ（図２３（ｅ）参照）内を検索し、変換元日時"Ｔ３"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図２３（ｅ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０２４１】
次に、データ管理装置３Ｅは、ルートノードの決定処理を行う（ステップＳ４０５）。ここでは、サブルートキー"Ｒ０＠Ｄ１"に対応するノードとして、データ管理装置３Ｄが、ルートノードとして決定される。
【０２４２】
続いて、データ管理装置３Ｅは、ＩＤ取得要求メッセージ５０ｂ（５０）を、ルートノードとして決定したデータ管理装置３Ｄに送信する（ステップＳ４０６）。
【０２４３】
図２９（ｃ）は、ＩＤ取得要求メッセージ５０ｂ（５０）を例示する図である。図２９（ｃ）に示すように、ＩＤ取得要求メッセージ５０ｂ（５０）は、サブルートキー"Ｒ０＠Ｄ１"に紐付く識別子の内、変換先日時"Ｔ３"で有効なものの取得を要求するものであることを示す。
【０２４４】
図２８に戻り、ＩＤ取得要求メッセージ５０ｂ（５０）を受信したデータ管理装置３Ｄは、ＩＤ（識別子）の取得処理を行う（ステップＳ４０７）。ＩＤ（識別子）の取得は、サブルートキー"Ｒ０＠Ｄ１"をキーとして、データ格納領域３００Ｄ（図２３（ｄ）参照）内を検索し、変換先日時"Ｔ３"が、登録日時と失効日時の間に含まれるような行から行われる。ここでは、図２３（ｄ）に示すルート情報から、識別子（変換先識別子）として"ａ"が取得される。
【０２４５】
次に、データ管理装置３Ｄは、ＩＤ取得応答メッセージ５１ｂ（５１）を、データ管理装置３Ｅに送信する（ステップＳ４０８）。図２９（ｄ）に示すように、ＩＤ取得応答メッセージ５１ｂには、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０２４６】
続いて、データ管理装置３Ｅは、ＩＤ変換応答メッセージ４１ｂ（４１）を、ゲートウェイ装置２に送信する（ステップＳ４０９）。図２９（ｂ）に示すように、ＩＤ変換応答メッセージ４１ｂ（４１）には、ＩＤ変換処理の結果取得された識別子（変換先識別子）"ａ"が含まれる。
【０２４７】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ｂ（４１）をクライアント装置１に送信し、処理を終える（ステップＳ４１０）。
【０２４８】
このようにして、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤ変換要求した際に、ＩＤ更新処理の結果を反映した、正しい変換結果として変換先識別子を得ることができる。
【０２４９】
＜ＩＤ更新処理後のＩＤ変換処理（２）＞
次に、図３０，図３１を参照して、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理（２）について説明する。
【０２５０】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン（変換元ドメイン）"Ｄ１"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"ａ"を、ドメイン（変換先ドメイン）"Ｄ０"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理（つまり、ドメイン"Ｄ１"の日時"Ｔ３"における識別子"ａ"に対応する、ドメイン"Ｄ０"の同日時"Ｔ３"における識別子を検索する処理）、について説明する。ここで、"Ｔ３"は"Ｔ２"よりも未来の日時を示すものとする。
【０２５１】
（ＩＤ変換処理の全体の流れ）
図３０は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理後のＩＤ変換処理の全体の流れ（２）を示すシーケンス図である。ここでは、前記した図２１に示すＩＤ更新処理がすでに行われ、各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ）のデータ記憶領域３００には、図２３に示すデータが記憶されているものとして説明する。
【０２５２】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ｃ（４０）をゲートウェイ装置２に送信する（ステップＳ５０１）。
【０２５３】
図３１（ａ）は、ＩＤ変換要求メッセージ４０ｃ（４０）を例示する図である。図３１（ａ）に示すＩＤ変換要求メッセージ４０ｃ（４０）は、変換元であるドメイン（変換元ドメイン）"Ｄ１"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"ａ"を、ドメイン（変換後ドメイン）"Ｄ０"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理を要求するものである。
【０２５４】
図３０に戻り、ＩＤ変換要求メッセージ４０ｃ（４０）を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ５０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"ａ＠Ｄ１"に対応するノードであるデータ管理装置３Ｃが、インデックスノードとして決定される。
【０２５５】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ｃ（４０）を、インデックスノードとして決定したデータ管理装置３Ｃに送信する（ステップＳ５０３）。
【０２５６】
ＩＤ変換要求メッセージ４０ｃ（４０）を受信したデータ管理装置３Ｃは、ルートキーの取得処理を行う（ステップＳ５０４）。ルートキーの取得は、インデックスキー"ａ＠Ｄ１"をキーとして、データ格納領域３００Ｃ（図２３（ｃ）参照）内を検索し、変換元日時"Ｔ３"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図２３（ｃ）に示すインデックスから、ルートキーとして"Ｒ０"が取得される。
【０２５７】
次に、データ管理装置３Ｃは、ルートノードの決定処理を行う（ステップＳ５０５）。ここでは、サブルートキー"Ｒ０＠Ｄ０"に対応するノードとして、データ管理装置３Ｂが、ルートノードとして決定される。
【０２５８】
続いて、データ管理装置３Ｃは、ＩＤ取得要求メッセージ５０ｃ（５０）を、ルートノードとして決定したデータ管理装置３Ｂに送信する（ステップＳ５０６）。
【０２５９】
図３１（ｃ）は、ＩＤ取得要求メッセージ５０ｃ（５０）を例示する図である。図３１（ｃ）に示すように、ＩＤ取得要求メッセージ５０ｃ（５０）は、サブルートキー"Ｒ０＠Ｄ０"に紐付く識別子の内、変換先日時"Ｔ３"で有効なものの取得を要求するものであることを示す。
【０２６０】
図３０に戻り、ＩＤ取得要求メッセージ５０ｃ（５０）を受信したデータ管理装置３Ｂは、ＩＤ（識別子）の取得処理を行う（ステップＳ５０７）。ＩＤ（識別子）の取得は、サブルートキー"Ｒ０＠Ｄ０"をキーとして、データ格納領域３００Ｂ（図２３（ｂ）参照）内を検索し、変換先日時"Ｔ３"が、登録日時と失効日時の間に含まれるような行から行われる。ここでは、図２３（ｂ）に示すルート情報から、識別子（変換先識別子）として"９"が取得される。
【０２６１】
次に、データ管理装置３Ｂは、ＩＤ取得応答メッセージ５１ｃ（５１）を、データ管理装置３Ｃに送信する（ステップＳ５０８）。図３１（ｄ）に示すように、ＩＤ取得応答メッセージ５１ｃ（５１）には、ＩＤ変換処理の結果取得された識別子（変換先識別子）"９"が含まれる。
【０２６２】
続いて、データ管理装置３Ｃは、ＩＤ変換応答メッセージ４１ｃ（４１）を、ゲートウェイ装置２に送信する（ステップＳ５０９）。図３１（ｂ）に示すように、ＩＤ変換応答メッセージ４１ｃ（４１）には、ＩＤ変換処理の結果取得された識別子（変換先識別子）"９"が含まれる。
【０２６３】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ｃをクライアント装置１に送信し、処理を終える（ステップＳ５１０）。
【０２６４】
このようにして、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤ変換要求した際に、ＩＤ更新処理の結果を反映した、正しい変換結果として変換先識別子を得ることができる。
【０２６５】
＜ＩＤ更新処理後のＩＤ変換処理（失敗例）＞
次に、図３２，図３３を参照して、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求（ＩＤ変換要求）した際に、ゲートウェイ装置２とデータ管理装置３が実行するＩＤ変換処理（失敗例）について説明する。
【０２６６】
ここでは、クライアント装置１が要求するＩＤ変換処理の例として、ドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"０"を、ドメイン（変換先ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）に変換する処理（つまり、ドメイン"Ｄ０"の日時"Ｔ３"における識別子"０"に対応する、ドメイン"Ｄ１"の同日時"Ｔ３"における識別子を検索する処理）、について説明する。ここで、"Ｔ３"は"Ｔ２"よりも未来の日時を示すものとする。
【０２６７】
また、ここでは、前記した図２１に示すＩＤ更新処理がすでに行われ、各データ管理装置３（３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ）のデータ記憶領域３００には、図２３に示すデータが記憶されていることを前提とするが、このＩＤ更新処理が行われた結果、ドメイン"Ｄ０"の日時"Ｔ３"における識別子は"０"ではなく、更新され"９"になっているため、当該ＩＤ変換処理は、失敗する。その場合の処理例を示すものである。
【０２６８】
（ＩＤ変換処理（失敗例）の全体の流れ）
図３２は、本実施形態に係る分散ＩＤ管理システム５が行うＩＤ更新処理後のＩＤ変換処理（失敗例）の全体の流れを示すシーケンス図である。
【０２６９】
まず、クライアント装置１は、ＩＤ変換要求メッセージ４０ｄ（４０）をゲートウェイ装置２に送信する（ステップＳ６０１）。
【０２７０】
図３３（ａ）は、ＩＤ変換要求メッセージ４０ｄ（４０）を例示する図である。図３３（ａ）に示すＩＤ変換要求メッセージ４０ｄは、変換元であるドメイン（変換元ドメイン）"Ｄ０"の日時（変換元日時）"Ｔ３"における識別子（変換元識別子）"０"を、ドメイン（変換後ドメイン）"Ｄ１"の同日時（変換先日時）"Ｔ３"における識別子（変換先識別子）へ変換する処理を要求するものである。
【０２７１】
図３２に戻り、ＩＤ変換要求メッセージ４０ｄ（４０）を受信したゲートウェイ装置２は、インデックスノードの決定処理を行う（ステップＳ６０２）。このインデックスノードの決定処理は、インデックスキーを検索キーとして、ノード決定部２１２がコンシステントハッシュ法により決定する。ここでは、例えば、インデックスキー"０＠Ｄ０"に対応するノードであるデータ管理装置３Ａが、インデックスノードとして決定される。
【０２７２】
続いて、ゲートウェイ装置２は、ＩＤ変換要求メッセージ４０ｄ（４０）を、インデックスノードとして決定したデータ管理装置３Ａに送信する（ステップＳ６０３）。
【０２７３】
ＩＤ変換要求メッセージ４０ｄ（４０）を受信したデータ管理装置３Ａは、ルートキーの取得処理を行う（ステップＳ６０４）。ルートキーの取得は、インデックスキー（"０＠Ｄ０"）をキーとして、データ格納領域３００Ａ（図２３（ａ）参照）内を検索し、変換元日時"Ｔ３"が登録日時と失効日時の間に含まれる行から行われる。ここでは、図２３（ａ）に示すインデックスに基づき、変換元日時Ｔ３が登録日時Ｔ０と失効日時Ｔ２の間に含まれるような行が存在しないため、ルートキーの取得に失敗する。
【０２７４】
次に、データ管理装置３Ａは、ＩＤ変換応答メッセージ４１ｄ（４１）を、ゲートウェイ装置２に送信する（ステップＳ６０５）。図３３（ｂ）に示すように、ＩＤ変換応答メッセージ４１ｄ（４１）には、ＩＤ変換処理の結果が存在しないことを示す"null"が含まれる。なお、当該メッセージには、"null"だけでなく、より詳細なエラー内容を含めるようにしてもよい。
【０２７５】
そして、ゲートウェイ装置２は、ＩＤ変換応答メッセージ４１ｄ（４１）をクライアント装置１に送信し、処理を終える（ステップＳ６０６）。
【０２７６】
このようにして、ＩＤ更新処理が行われた後に、クライアント装置１がゲートウェイ装置２に対して、ＩＤの変換を要求した際に、存在しない識別子を用いた変換処理に対しては、エラーが返されることが示された。
【０２７７】
以上説明したように、本実施形態に係る分散ＩＤ管理方法および分散ＩＤ管理システムによれば、管理対象に紐付く識別子であって、かつ、ドメインや日時ごとに変化し得るような識別子を管理するシステムにおいて、識別子を各データ管理装置３に分散配置し、ドメイン、日時を指定した識別子の変換処理や更新処理が可能となる。また、同一機能を備えたデータ管理装置３を複数配置し、インデックスおよびルート情報を各データ管理装置３に分散することで、管理すべきデータ量を抑えた上で、容易にスケールアウトを可能とすることができる。
【符号の説明】
【０２７８】
１ クライアント装置
２ ゲートウェイ装置
３ データ管理装置
４ 通信ネットワーク
５ 分散ＩＤ管理システム
１０ ＩＤ登録要求メッセージ
１１ ＩＤ登録応答メッセージ
２０ ルート情報登録要求メッセージ
２１ ルート情報登録応答メッセージ
３０ インデックス登録要求メッセージ
３１ インデックス登録応答メッセージ
４０ ＩＤ変換要求メッセージ
４１ ＩＤ変換応答メッセージ
５０ ＩＤ取得要求メッセージ
５１ ＩＤ取得応答メッセージ
６０ ＩＤ更新要求メッセージ
６１ ＩＤ更新応答メッセージ
７０ ルート情報更新要求メッセージ
７１ ルート情報更新応答メッセージ
１００ ゲートウェイ情報記憶領域
１１０，２１０，３１０ 制御部
１１１ ＩＤ登録要求部
１１２ ＩＤ変換要求部
１１３ ＩＤ更新要求部
１３０，２３０，３３０ 入出力部
１４０，２４０，３４０ 送受信部
１５０，２５０，３５０ 記憶部
２００ ノード情報記憶領域
２１１，３１１ ノード管理部
２１２，３１２ ノード決定部
２１３ ＩＤ登録転送部
２１４ ＩＤ変換転送部
２１５ ＩＤ更新転送部
３００ データ記憶領域
３１３ ルートキー生成部
３１４ ＩＤ登録処理部
３１５ ＩＤ変換処理部
３１６ ＩＤ更新処理部
３１７ ＩＤ取得処理部
３１８ インデックス登録処理部
３１９ ルート情報登録処理部
３２０ ルート情報更新処理部
３２１ データ管理部
【特許請求の範囲】
【請求項１】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムの分散ＩＤ管理方法であって、
前記ゲートウェイ装置は、
前記データ管理装置それぞれのアドレスを示す接続情報が記憶される記憶部を備えており、
前記要求メッセージとして、管理対象を識別するための識別子、前記識別子が利用される範囲を示すドメインおよび登録日時を示す登録情報の保存を要求するＩＤ登録要求メッセージを受信し、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合したインデックスキーを生成し、前記登録情報としてのインデックスを保存する第１のデータ管理装置を、当該生成したインデックスキーに基づき、前記複数のデータ管理装置の中から決定し、
前記決定した第１のデータ管理装置へ、前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信し、
前記第１のデータ管理装置は、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成し、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記登録日時を、前記ルートキーに対応付けた情報を前記インデックスとして、自身の記憶部に保存し、
前記ＩＤ登録要求メッセージに含まれる前記ドメインと前記ルートキーとを結合したサブルートキーを生成し、前記登録情報としてのルート情報を保存する第２のデータ管理装置を、当該生成したサブルートキーに基づき、前記複数のデータ管理装置の中から決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記登録日時と、前記識別子とを含むルート情報登録要求メッセージを送信し、
前記第２のデータ管理装置は、
前記ルート情報登録要求メッセージに含まれる前記サブルートキーおよび前記登録日時を、前記識別子に対応付けた情報を前記ルート情報として、自身の記憶部に保存すること
を特徴とする分散ＩＤ管理方法。
【請求項２】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）変換元識別子、変換元ドメイン、変換元日時、および、（２）変換先ドメイン、変換先日時、を含み、変換先となる前記識別子の検索を要求するＩＤ変換要求メッセージを受信し、
前記ＩＤ変換要求メッセージの前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーに基づき、前記インデックスを保存する前記第１のデータ管理装置を決定し、
前記ＩＤ変換要求メッセージを、前記接続情報を参照して、前記第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、
前記ＩＤ変換要求メッセージに含まれる前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記インデックスを参照し、前記ルートキーを取得し、
前記ＩＤ変換要求メッセージに含まれる前記変換先ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、当該生成したサブルートキーに基づき、前記ルート情報を保存する前記第２のデータ管理装置を決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記変換先日時とを含むＩＤ取得要求メッセージを送信し、
前記第２のデータ管理装置は、
前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記ルート情報を参照し、前記変換先となる前記識別子を取得すること
を特徴とする請求項１に記載の分散ＩＤ管理方法。
【請求項３】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信し、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーに基づき、前記インデックスを保存する前記第１のデータ管理装置を決定し、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、前記第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録し、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、当該生成したサブルートキーに基づき、前記ルート情報を保存する前記第２のデータ管理装置を決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信し、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成し、当該生成した新たなインデックスキーに基づき、新たな前記インデックスを保存する第３の前記データ管理装置を決定し、
前記決定した第３のデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含むインデックス登録要求メッセージを送信し、
前記第２のデータ管理装置は、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録し、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に保存し、
前記第３のデータ管理装置は、
前記インデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に保存すること
を特徴とする請求項１に記載の分散ＩＤ管理方法。
【請求項４】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムの分散ＩＤ管理方法であって、
前記複数のデータ管理装置それぞれは、通信可能に接続され、
前記ゲートウェイ装置および前記複数のデータ管理装置は、前記データ管理装置それぞれのアドレスを示す接続情報と、前記データ管理装置それぞれに対応したハッシュ値を示すノードＩＤとが格納されるノード情報が記憶される記憶部をそれぞれ備えており、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）管理対象を識別するための第１（ｉ＝１）の識別子、前記第１の識別子が利用される範囲を示す第１（ｉ＝１）のドメイン、および登録日時を示す第１（ｉ＝１）の登録情報と、（２）前記第１の識別子に示される管理対象と同一の管理対象を示す他の識別子である第２（ｉ＝２）の識別子、前記第２の識別子が利用される範囲を示す第２（ｉ＝２）のドメイン、および登録日時を示す第２（ｉ＝２）の登録情報と、を少なくとも含み、（ｉ）前記第１の識別子に示される管理対象と同一の管理対象を示す識別子である第ｉ（当該ｉは３以上の整数）の識別子、当該第ｉの識別子が利用される範囲を示す第ｉ（当該ｉは３以上の整数）のドメイン、および登録日時を示す第ｉ（当該ｉは３以上の整数）の登録情報と、を含むことができる情報の登録処理を要求するＩＤ登録要求メッセージを受信するステップと、
前記ＩＤ登録要求メッセージの先頭の識別子である前記第１の識別子と前記第１のドメインとを結合したインデックスキーを生成するステップと、
当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、振り分け先となる第１の前記データ管理装置を決定するステップと、
前記決定した第１のデータ管理装置に、前記ノード情報の前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信するステップと、を実行し、
前記第１のデータ管理装置は、
前記ＩＤ登録要求メッセージを受信するステップと、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成するステップと、
前記ＩＤ登録要求メッセージに基づき、第ｉ（ｉ＝１以上の整数）の識別子と第ｉ（ｉ＝１以上の整数）のドメインとを結合した第ｉ（ｉ＝１以上の整数）インデックスキーを生成するステップと、
当該生成した第ｉインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉインデックスキーを含むインデックスである第ｉインデックスの登録先を第（２×ｉ−１）の前記データ管理装置に決定するステップと、
前記第ｉインデックスキー、前記登録日時および前記ルートキーを含むインデックス登録要求メッセージを生成し、前記第（２×ｉ−１）のデータ管理装置に送信するステップと、
前記第ｉのドメインと前記ルートキーとを結合した第ｉサブルートキーを生成するステップと、
当該生成した第ｉサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉサブルートキーを含むルート情報である第ｉルート情報の登録先を第（２×ｉ）の前記データ管理装置に決定するステップと、
前記第ｉサブルートキー、前記登録日時および前記第ｉの識別子を含むルート情報登録要求メッセージを生成し、前記第（２×ｉ）のデータ管理装置に送信するステップと、を実行し、
前記第（２×ｉ−１）のデータ管理装置は、
前記インデックス登録要求メッセージを受信するステップと、
前記インデックス登録要求メッセージに基づき、前記第ｉインデックスキーおよび登録日時を前記ルートキーに対応付けた情報である前記第ｉインデックスを、自身の記憶部に登録するステップと、を実行し、
前記第（２×ｉ）のデータ管理装置は、
前記ルート情報登録要求メッセージを受信するステップと、
前記ルート情報登録要求メッセージに基づき、前記第ｉサブルートキーおよび登録日時を前記第ｉの識別子に対応付けた情報である前記第ｉルート情報を、自身の記憶部に登録するステップと、を実行すること
を特徴とする分散ＩＤ管理方法。
【請求項５】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）変換元となる第１の識別子、変換元となる第１のドメイン、変換元の日時である変換元日時、および、（２）変換先となる第２のドメイン、変換先の日時である変換先日時、を含み、変換先となる第２の識別子の検索を要求するＩＤ変換要求メッセージを受信するステップと、
前記ＩＤ変換要求メッセージの前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成するステップと、
当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定するステップと、
前記ＩＤ変換要求メッセージを、前記ノード情報の前記接続情報を参照して、当該決定したデータ管理装置に送信するステップと、を実行し、
前記インデックスの登録先であるデータ管理装置は、
前記ＩＤ変換要求メッセージを受信するステップと、
前記ＩＤ変換要求メッセージに基づき、前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成し、自身の記憶部に登録された前記インデックスを参照し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記ルートキーを取得するステップと、
前記取得したルートキーと、前記ＩＤ変換要求メッセージに含まれる前記第２のドメインとを結合した前記サブルートキーを生成するステップと、
当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定するステップと、
前記サブルートキーおよび前記ＩＤ変換要求メッセージに含まれる前記変換先日時を含むＩＤ取得要求メッセージを生成し、当該決定したデータ管理装置に送信するステップと、を実行し、
前記ルート情報の登録先であるデータ管理装置は、
前記ＩＤ取得要求メッセージを受信するステップと、
自身の記憶部に登録されたルート情報を参照し、前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記変換先となる第２の識別子を取得するステップと、
前記変換先となる第２の識別子を含むＩＤ取得応答メッセージを生成し、前記インデックスの登録先であるデータ管理装置に送信するステップと、を実行し、
前記インデックスの登録先であるデータ管理装置は、
前記変換先となる第２の識別子を含むＩＤ取得応答メッセージを受信するステップと、
前記変換先となる第２の識別子を含むＩＤ変換応答メッセージを生成し、前記ゲートウェイ装置を介して、前記クライアントに送信するステップと、を実行すること
を特徴とする請求項４に記載の分散ＩＤ管理方法。
【請求項６】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信するステップと、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成するステップと、
当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定するステップと、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、当該決定したデータ管理装置に送信するステップと、を実行し、
前記インデックスの登録先であるデータ管理装置は、
前記ＩＤ更新要求メッセージを受信するステップと、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録するステップと、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成するステップと、
当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定するステップと、
当該決定したデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信するステップと、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成するステップと、
当該生成した新たなインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、新たな前記インデックスの登録先であるデータ管理装置を決定するステップと、
当該決定したデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含む第２のインデックス登録要求メッセージを送信するステップと、を実行し、
前記ルート情報の登録先であるデータ管理装置は、
前記ルート情報更新要求メッセージを受信するステップと、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録するステップと、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に登録するステップと、を実行し、
前記新たなインデックスの登録先であるデータ管理装置は、
前記第２のインデックス登録要求メッセージを受信するステップと、
前記第２のインデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に登録するステップと、を実行すること
を特徴とする請求項４に記載の分散ＩＤ管理方法。
【請求項７】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムであって、
前記ゲートウェイ装置は、
前記データ管理装置それぞれのアドレスを示す接続情報が記憶される記憶部と、
前記要求メッセージとして、管理対象を識別するための識別子、前記識別子が利用される範囲を示すドメインおよび登録日時を示す登録情報の保存を要求するＩＤ登録要求メッセージを受信する送受信部と、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合したインデックスキーを生成し、前記登録情報としてのインデックスを保存する第１のデータ管理装置へ、前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信するＩＤ登録転送部と、
前記第１のデータ管理装置を、前記ＩＤ登録転送部が生成した前記インデックスキーに基づき、前記複数のデータ管理装置の中から決定するノード決定部と、を備え、
前記第１のデータ管理装置は、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成するルートキー生成部と、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記登録日時を、前記ルートキーに対応付けた情報を前記インデックスとして、自身の記憶部に保存し、
前記ＩＤ登録要求メッセージに含まれる前記ドメインと前記ルートキーとを結合したサブルートキーを生成し、前記登録情報としてのルート情報を保存する第２のデータ管理装置へ、前記サブルートキーと、前記登録日時と、前記識別子とを含むルート情報登録要求メッセージを送信するＩＤ登録処理部と、
前記第２のデータ管理装置を、前記ＩＤ登録処理部が生成した前記サブルートキーに基づき、前記複数のデータ管理装置の中から決定するノード決定部と、を備え、
前記第２のデータ管理装置は、
前記ルート情報登録要求メッセージに含まれる前記サブルートキーおよび前記登録日時を、前記識別子に対応付けた情報を前記ルート情報として、自身の記憶部に保存するルート情報登録処理部と、を備えること
を特徴とする分散ＩＤ管理システム。
【請求項８】
前記ゲートウェイ装置は、さらに、ＩＤ変換転送部を備えており、
前記ゲートウェイ装置の前記送受信部が、
前記要求メッセージとして、（１）変換元識別子、変換元ドメイン、変換元日時、および、（２）変換先ドメイン、変換先日時、を含み、変換先となる前記識別子の検索を要求するＩＤ変換要求メッセージを受信し、
前記ＩＤ変換転送部が、
前記ＩＤ変換要求メッセージの前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、前記インデックスを保存する前記第１のデータ管理装置を、当該生成したインデックスキーに基づき、前記ノード決定部を介して決定し、
前記ＩＤ変換要求メッセージを、前記接続情報を参照して、前記決定した第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、さらに、ＩＤ変換処理部を備えており、
前記ＩＤ変換処理部が、
前記ＩＤ変換要求メッセージに含まれる前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記インデックスを参照し、前記ルートキーを取得し、
前記ＩＤ変換要求メッセージに含まれる前記変換先ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、前記ルート情報を保存する前記第２のデータ管理装置を、当該生成したサブルートキーに基づき、前記ノード決定部を介して決定し、
前記サブルートキーと、前記変換先日時とを含むＩＤ取得要求メッセージを、前記決定した第２のデータ管理装置に送信し、
前記第２のデータ管理装置は、さらに、ＩＤ取得処理部を備えており、
前記ＩＤ取得処理部が、
前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記ルート情報を参照し、前記変換先となる識別子を取得すること
を特徴とする請求項７に記載の分散ＩＤ管理システム。
【請求項９】
前記ゲートウェイ装置は、さらに、ＩＤ更新転送部を備えており、
前記ゲートウェイ装置の前記送受信部が、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信し、
前記ＩＤ更新転送部が、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーに基づき、前記インデックスを保存する前記第１のデータ管理装置を決定し、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、前記第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、さらに、ＩＤ更新処理部を備えており、
前記ＩＤ更新処理部が、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録し、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、当該生成したサブルートキーに基づき、前記ルート情報を保存する前記第２のデータ管理装置を決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信し、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成し、当該生成した新たなインデックスキーに基づき、新たな前記インデックスを保存する第３の前記データ管理装置を決定し、
前記決定した第３のデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含むインデックス登録要求メッセージを送信し、
前記第２のデータ管理装置は、さらに、ルート情報更新処理部を備えており、
前記ルート情報更新処理部が、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録し、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に保存し、
前記第３のデータ管理装置は、インデックス登録処理部を備えており、
前記インデックス登録処理部が、
前記インデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に保存すること
を特徴とする請求項７に記載の分散ＩＤ管理システム。
【請求項１０】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムであって、
前記複数のデータ管理装置それぞれは、通信可能に接続され、
前記ゲートウェイ装置および前記複数のデータ管理装置は、前記データ管理装置それぞれのアドレスを示す接続情報と、前記データ管理装置それぞれに対応したハッシュ値を示すノードＩＤとが格納されるノード情報が記憶される記憶部をそれぞれ備えており、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）管理対象を識別するための第１（ｉ＝１）の識別子、前記第１の識別子が利用される範囲を示す第１（ｉ＝１）のドメイン、および登録日時を示す第１（ｉ＝１）の登録情報と、（２）前記第１の識別子に示される管理対象と同一の管理対象を示す他の識別子である第２（ｉ＝２）の識別子、前記第２の識別子が利用される範囲を示す第２（ｉ＝２）のドメイン、および登録日時を示す第２（ｉ＝２）の登録情報と、を少なくとも含み、（ｉ）前記第１の識別子に示される管理対象と同一の管理対象を示す識別子である第ｉ（当該ｉは３以上の整数）の識別子、当該第ｉの識別子が利用される範囲を示す第ｉ（当該ｉは３以上の整数）のドメイン、および登録日時を示す第ｉ（当該ｉは３以上の整数）の登録情報と、を含むことができる情報の登録処理を要求するＩＤ登録要求メッセージを受信する送受信部と、
前記ＩＤ登録要求メッセージの先頭の識別子である前記第１の識別子と前記第１のドメインとを結合したインデックスキーを生成し、前記ゲートウェイ装置のノード決定部が決定した振り分け先となる第１のデータ管理装置に、前記ノード情報の前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信するＩＤ登録転送部と、
前記第１のデータ管理装置を、前記ＩＤ登録転送部が生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記振り分け先となる前記第１の前記データ管理装置を決定する前記ノード決定部と、
前記第１のデータ管理装置は、
前記ＩＤ登録要求メッセージを受信する送受信部と、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成するルートキー生成部と、
前記ＩＤ登録要求メッセージに基づき、第ｉ（ｉ＝１以上の整数）の識別子と第ｉ（ｉ＝１以上の整数）のドメインとを結合した第ｉ（ｉ＝１以上の整数）インデックスキーを生成し、
前記第ｉインデックスキー、前記登録日時および前記ルートキーを含むインデックス登録要求メッセージを生成し、前記第ｉインデックスキーを含むインデックスである第ｉインデックスの登録先である第（２×ｉ−１）のデータ管理装置に送信し、
前記第ｉのドメインと前記ルートキーとを結合した第ｉサブルートキーを生成し、
前記第ｉサブルートキー、前記登録日時および前記第ｉの識別子を含むルート情報登録要求メッセージを生成し、前記第ｉサブルートキーを含むルート情報である第ｉルート情報の登録先である第（２×ｉ）のデータ管理装置に送信するＩＤ登録処理部と、
前記ＩＤ登録処理部が生成した前記第ｉインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉインデックスの登録先を前記第（２×ｉ−１）のデータ管理装置に決定し、
前記ＩＤ登録処理部が生成した前記第ｉサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉルート情報の登録先を前記第（２×ｉ）のデータ管理装置に決定するノード決定部と、を備え、
前記第（２×ｉ−１）のデータ管理装置は、
前記インデックス登録要求メッセージを受信する送受信部と、
前記インデックス登録要求メッセージに基づき、前記第ｉインデックスキーおよび登録日時を前記ルートキーに対応付けた情報である前記第ｉインデックスを、自身の記憶部に登録するインデックス登録処理部と、を備え、
前記第（２×ｉ）のデータ管理装置は、
前記ルート情報登録要求メッセージを受信する送受信部と、
前記ルート情報登録要求メッセージに基づき、前記第ｉサブルートキーおよび登録日時を前記第ｉの識別子に対応付けた情報である前記第ｉルート情報を、自身の記憶部に登録するルート情報登録処理部と、を備えること
を特徴とする分散ＩＤ管理システム。
【請求項１１】
前記ゲートウェイ装置は、さらに、ＩＤ変換転送部を備えており、
前記ゲートウェイ装置の送受信部が、
前記要求メッセージとして、（１）変換元となる第１の識別子、変換元となる第１のドメイン、変換元の日時である変換元日時、および、（２）変換先となる第２のドメイン、変換先の日時である変換先日時、を含み、変換先となる第２の識別子の検索を要求するＩＤ変換要求メッセージを受信し、
前記ＩＤ変換転送部が、
前記ＩＤ変換要求メッセージの前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成し、
前記ノード決定部を介して、当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定し、
前記ＩＤ変換要求メッセージを、前記ノード情報の前記接続情報を参照して、前記決定したインデックスの登録先である前記データ管理装置に送信し、
前記インデックスの登録先であるデータ管理装置は、さらに、ＩＤ変換処理部を備えており、
前記ＩＤ変換処理部が、
受信した前記ＩＤ変換要求メッセージに基づき、前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成し、自身の記憶部に登録された前記インデックスを参照し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記ルートキーを取得し、
前記取得したルートキーと、前記ＩＤ変換要求メッセージに含まれる前記第２のドメインとを結合した前記サブルートキーを生成し、
前記ノード決定部を介して、当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定し、
前記サブルートキーおよび前記ＩＤ変換要求メッセージに含まれる前記変換先日時を含むＩＤ取得要求メッセージを生成し、前記決定したルート情報の登録先である前記データ管理装置に送信し、
前記ルート情報の登録先であるデータ管理装置は、さらに、ＩＤ取得処理部を備えており、
前記ＩＤ取得処理部が、
自身の記憶部に登録されたルート情報を参照し、受信した前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記変換先となる第２の識別子を取得し、
前記変換先となる第２の識別子を含むＩＤ取得応答メッセージを生成し、前記インデックスの登録先であるデータ管理装置に送信し、
前記インデックスの登録先であるデータ管理装置の前記ＩＤ変換処理部は、
受信した前記ＩＤ取得応答メッセージに基づき、前記変換先となる第２の識別子を含むＩＤ変換応答メッセージを生成し、前記ゲートウェイ装置を介して、前記クライアントに送信すること
を特徴とする請求項１０に記載の分散ＩＤ管理システム。
【請求項１２】
前記ゲートウェイ装置は、さらに、ＩＤ更新転送部を備えており、
前記ゲートウェイ装置の送受信部が、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信し、
前記ＩＤ更新転送部が、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、
前記ノード決定部を介して、当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定し、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、当該決定したデータ管理装置に送信し、
前記インデックスの登録先であるデータ管理装置は、さらに、ＩＤ更新処理部を備えており、
前記ＩＤ更新処理部が、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録し、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、
当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定し、
当該決定したデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信し、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成し、
当該生成した新たなインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、新たな前記インデックスの登録先であるデータ管理装置を決定し、
当該決定したデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含む第２のインデックス登録要求メッセージを送信し、
前記ルート情報の登録先であるデータ管理装置は、さらに、ルート情報更新処理部を備えており、
前記ルート情報更新処理部が、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録し、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に登録し、
前記新たなインデックスの登録先であるデータ管理装置は、インデックス登録処理部を備えており、
前記インデックス登録処理部は、
前記第２のインデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に登録すること
を特徴とする請求項１０に記載の分散ＩＤ管理システム。
【請求項１】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムの分散ＩＤ管理方法であって、
前記ゲートウェイ装置は、
前記データ管理装置それぞれのアドレスを示す接続情報が記憶される記憶部を備えており、
前記要求メッセージとして、管理対象を識別するための識別子、前記識別子が利用される範囲を示すドメインおよび登録日時を示す登録情報の保存を要求するＩＤ登録要求メッセージを受信し、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合したインデックスキーを生成し、前記登録情報としてのインデックスを保存する第１のデータ管理装置を、当該生成したインデックスキーに基づき、前記複数のデータ管理装置の中から決定し、
前記決定した第１のデータ管理装置へ、前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信し、
前記第１のデータ管理装置は、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成し、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記登録日時を、前記ルートキーに対応付けた情報を前記インデックスとして、自身の記憶部に保存し、
前記ＩＤ登録要求メッセージに含まれる前記ドメインと前記ルートキーとを結合したサブルートキーを生成し、前記登録情報としてのルート情報を保存する第２のデータ管理装置を、当該生成したサブルートキーに基づき、前記複数のデータ管理装置の中から決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記登録日時と、前記識別子とを含むルート情報登録要求メッセージを送信し、
前記第２のデータ管理装置は、
前記ルート情報登録要求メッセージに含まれる前記サブルートキーおよび前記登録日時を、前記識別子に対応付けた情報を前記ルート情報として、自身の記憶部に保存すること
を特徴とする分散ＩＤ管理方法。
【請求項２】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）変換元識別子、変換元ドメイン、変換元日時、および、（２）変換先ドメイン、変換先日時、を含み、変換先となる前記識別子の検索を要求するＩＤ変換要求メッセージを受信し、
前記ＩＤ変換要求メッセージの前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーに基づき、前記インデックスを保存する前記第１のデータ管理装置を決定し、
前記ＩＤ変換要求メッセージを、前記接続情報を参照して、前記第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、
前記ＩＤ変換要求メッセージに含まれる前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記インデックスを参照し、前記ルートキーを取得し、
前記ＩＤ変換要求メッセージに含まれる前記変換先ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、当該生成したサブルートキーに基づき、前記ルート情報を保存する前記第２のデータ管理装置を決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記変換先日時とを含むＩＤ取得要求メッセージを送信し、
前記第２のデータ管理装置は、
前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記ルート情報を参照し、前記変換先となる前記識別子を取得すること
を特徴とする請求項１に記載の分散ＩＤ管理方法。
【請求項３】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信し、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーに基づき、前記インデックスを保存する前記第１のデータ管理装置を決定し、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、前記第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録し、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、当該生成したサブルートキーに基づき、前記ルート情報を保存する前記第２のデータ管理装置を決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信し、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成し、当該生成した新たなインデックスキーに基づき、新たな前記インデックスを保存する第３の前記データ管理装置を決定し、
前記決定した第３のデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含むインデックス登録要求メッセージを送信し、
前記第２のデータ管理装置は、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録し、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に保存し、
前記第３のデータ管理装置は、
前記インデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に保存すること
を特徴とする請求項１に記載の分散ＩＤ管理方法。
【請求項４】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムの分散ＩＤ管理方法であって、
前記複数のデータ管理装置それぞれは、通信可能に接続され、
前記ゲートウェイ装置および前記複数のデータ管理装置は、前記データ管理装置それぞれのアドレスを示す接続情報と、前記データ管理装置それぞれに対応したハッシュ値を示すノードＩＤとが格納されるノード情報が記憶される記憶部をそれぞれ備えており、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）管理対象を識別するための第１（ｉ＝１）の識別子、前記第１の識別子が利用される範囲を示す第１（ｉ＝１）のドメイン、および登録日時を示す第１（ｉ＝１）の登録情報と、（２）前記第１の識別子に示される管理対象と同一の管理対象を示す他の識別子である第２（ｉ＝２）の識別子、前記第２の識別子が利用される範囲を示す第２（ｉ＝２）のドメイン、および登録日時を示す第２（ｉ＝２）の登録情報と、を少なくとも含み、（ｉ）前記第１の識別子に示される管理対象と同一の管理対象を示す識別子である第ｉ（当該ｉは３以上の整数）の識別子、当該第ｉの識別子が利用される範囲を示す第ｉ（当該ｉは３以上の整数）のドメイン、および登録日時を示す第ｉ（当該ｉは３以上の整数）の登録情報と、を含むことができる情報の登録処理を要求するＩＤ登録要求メッセージを受信するステップと、
前記ＩＤ登録要求メッセージの先頭の識別子である前記第１の識別子と前記第１のドメインとを結合したインデックスキーを生成するステップと、
当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、振り分け先となる第１の前記データ管理装置を決定するステップと、
前記決定した第１のデータ管理装置に、前記ノード情報の前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信するステップと、を実行し、
前記第１のデータ管理装置は、
前記ＩＤ登録要求メッセージを受信するステップと、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成するステップと、
前記ＩＤ登録要求メッセージに基づき、第ｉ（ｉ＝１以上の整数）の識別子と第ｉ（ｉ＝１以上の整数）のドメインとを結合した第ｉ（ｉ＝１以上の整数）インデックスキーを生成するステップと、
当該生成した第ｉインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉインデックスキーを含むインデックスである第ｉインデックスの登録先を第（２×ｉ−１）の前記データ管理装置に決定するステップと、
前記第ｉインデックスキー、前記登録日時および前記ルートキーを含むインデックス登録要求メッセージを生成し、前記第（２×ｉ−１）のデータ管理装置に送信するステップと、
前記第ｉのドメインと前記ルートキーとを結合した第ｉサブルートキーを生成するステップと、
当該生成した第ｉサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉサブルートキーを含むルート情報である第ｉルート情報の登録先を第（２×ｉ）の前記データ管理装置に決定するステップと、
前記第ｉサブルートキー、前記登録日時および前記第ｉの識別子を含むルート情報登録要求メッセージを生成し、前記第（２×ｉ）のデータ管理装置に送信するステップと、を実行し、
前記第（２×ｉ−１）のデータ管理装置は、
前記インデックス登録要求メッセージを受信するステップと、
前記インデックス登録要求メッセージに基づき、前記第ｉインデックスキーおよび登録日時を前記ルートキーに対応付けた情報である前記第ｉインデックスを、自身の記憶部に登録するステップと、を実行し、
前記第（２×ｉ）のデータ管理装置は、
前記ルート情報登録要求メッセージを受信するステップと、
前記ルート情報登録要求メッセージに基づき、前記第ｉサブルートキーおよび登録日時を前記第ｉの識別子に対応付けた情報である前記第ｉルート情報を、自身の記憶部に登録するステップと、を実行すること
を特徴とする分散ＩＤ管理方法。
【請求項５】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）変換元となる第１の識別子、変換元となる第１のドメイン、変換元の日時である変換元日時、および、（２）変換先となる第２のドメイン、変換先の日時である変換先日時、を含み、変換先となる第２の識別子の検索を要求するＩＤ変換要求メッセージを受信するステップと、
前記ＩＤ変換要求メッセージの前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成するステップと、
当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定するステップと、
前記ＩＤ変換要求メッセージを、前記ノード情報の前記接続情報を参照して、当該決定したデータ管理装置に送信するステップと、を実行し、
前記インデックスの登録先であるデータ管理装置は、
前記ＩＤ変換要求メッセージを受信するステップと、
前記ＩＤ変換要求メッセージに基づき、前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成し、自身の記憶部に登録された前記インデックスを参照し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記ルートキーを取得するステップと、
前記取得したルートキーと、前記ＩＤ変換要求メッセージに含まれる前記第２のドメインとを結合した前記サブルートキーを生成するステップと、
当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定するステップと、
前記サブルートキーおよび前記ＩＤ変換要求メッセージに含まれる前記変換先日時を含むＩＤ取得要求メッセージを生成し、当該決定したデータ管理装置に送信するステップと、を実行し、
前記ルート情報の登録先であるデータ管理装置は、
前記ＩＤ取得要求メッセージを受信するステップと、
自身の記憶部に登録されたルート情報を参照し、前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記変換先となる第２の識別子を取得するステップと、
前記変換先となる第２の識別子を含むＩＤ取得応答メッセージを生成し、前記インデックスの登録先であるデータ管理装置に送信するステップと、を実行し、
前記インデックスの登録先であるデータ管理装置は、
前記変換先となる第２の識別子を含むＩＤ取得応答メッセージを受信するステップと、
前記変換先となる第２の識別子を含むＩＤ変換応答メッセージを生成し、前記ゲートウェイ装置を介して、前記クライアントに送信するステップと、を実行すること
を特徴とする請求項４に記載の分散ＩＤ管理方法。
【請求項６】
前記分散ＩＤ管理システムが、前記ＩＤ登録要求メッセージに基づく前記インデックスおよび前記ルート情報の登録を完了した後において、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信するステップと、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成するステップと、
当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定するステップと、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、当該決定したデータ管理装置に送信するステップと、を実行し、
前記インデックスの登録先であるデータ管理装置は、
前記ＩＤ更新要求メッセージを受信するステップと、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録するステップと、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成するステップと、
当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定するステップと、
当該決定したデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信するステップと、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成するステップと、
当該生成した新たなインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、新たな前記インデックスの登録先であるデータ管理装置を決定するステップと、
当該決定したデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含む第２のインデックス登録要求メッセージを送信するステップと、を実行し、
前記ルート情報の登録先であるデータ管理装置は、
前記ルート情報更新要求メッセージを受信するステップと、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録するステップと、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に登録するステップと、を実行し、
前記新たなインデックスの登録先であるデータ管理装置は、
前記第２のインデックス登録要求メッセージを受信するステップと、
前記第２のインデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に登録するステップと、を実行すること
を特徴とする請求項４に記載の分散ＩＤ管理方法。
【請求項７】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムであって、
前記ゲートウェイ装置は、
前記データ管理装置それぞれのアドレスを示す接続情報が記憶される記憶部と、
前記要求メッセージとして、管理対象を識別するための識別子、前記識別子が利用される範囲を示すドメインおよび登録日時を示す登録情報の保存を要求するＩＤ登録要求メッセージを受信する送受信部と、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合したインデックスキーを生成し、前記登録情報としてのインデックスを保存する第１のデータ管理装置へ、前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信するＩＤ登録転送部と、
前記第１のデータ管理装置を、前記ＩＤ登録転送部が生成した前記インデックスキーに基づき、前記複数のデータ管理装置の中から決定するノード決定部と、を備え、
前記第１のデータ管理装置は、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成するルートキー生成部と、
前記ＩＤ登録要求メッセージに含まれる前記識別子と前記ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記登録日時を、前記ルートキーに対応付けた情報を前記インデックスとして、自身の記憶部に保存し、
前記ＩＤ登録要求メッセージに含まれる前記ドメインと前記ルートキーとを結合したサブルートキーを生成し、前記登録情報としてのルート情報を保存する第２のデータ管理装置へ、前記サブルートキーと、前記登録日時と、前記識別子とを含むルート情報登録要求メッセージを送信するＩＤ登録処理部と、
前記第２のデータ管理装置を、前記ＩＤ登録処理部が生成した前記サブルートキーに基づき、前記複数のデータ管理装置の中から決定するノード決定部と、を備え、
前記第２のデータ管理装置は、
前記ルート情報登録要求メッセージに含まれる前記サブルートキーおよび前記登録日時を、前記識別子に対応付けた情報を前記ルート情報として、自身の記憶部に保存するルート情報登録処理部と、を備えること
を特徴とする分散ＩＤ管理システム。
【請求項８】
前記ゲートウェイ装置は、さらに、ＩＤ変換転送部を備えており、
前記ゲートウェイ装置の前記送受信部が、
前記要求メッセージとして、（１）変換元識別子、変換元ドメイン、変換元日時、および、（２）変換先ドメイン、変換先日時、を含み、変換先となる前記識別子の検索を要求するＩＤ変換要求メッセージを受信し、
前記ＩＤ変換転送部が、
前記ＩＤ変換要求メッセージの前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、前記インデックスを保存する前記第１のデータ管理装置を、当該生成したインデックスキーに基づき、前記ノード決定部を介して決定し、
前記ＩＤ変換要求メッセージを、前記接続情報を参照して、前記決定した第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、さらに、ＩＤ変換処理部を備えており、
前記ＩＤ変換処理部が、
前記ＩＤ変換要求メッセージに含まれる前記変換元識別子と前記変換元ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記インデックスを参照し、前記ルートキーを取得し、
前記ＩＤ変換要求メッセージに含まれる前記変換先ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、前記ルート情報を保存する前記第２のデータ管理装置を、当該生成したサブルートキーに基づき、前記ノード決定部を介して決定し、
前記サブルートキーと、前記変換先日時とを含むＩＤ取得要求メッセージを、前記決定した第２のデータ管理装置に送信し、
前記第２のデータ管理装置は、さらに、ＩＤ取得処理部を備えており、
前記ＩＤ取得処理部が、
前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記ルート情報を参照し、前記変換先となる識別子を取得すること
を特徴とする請求項７に記載の分散ＩＤ管理システム。
【請求項９】
前記ゲートウェイ装置は、さらに、ＩＤ更新転送部を備えており、
前記ゲートウェイ装置の前記送受信部が、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信し、
前記ＩＤ更新転送部が、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーに基づき、前記インデックスを保存する前記第１のデータ管理装置を決定し、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、前記第１のデータ管理装置に送信し、
前記第１のデータ管理装置は、さらに、ＩＤ更新処理部を備えており、
前記ＩＤ更新処理部が、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録し、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、当該生成したサブルートキーに基づき、前記ルート情報を保存する前記第２のデータ管理装置を決定し、
前記決定した第２のデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信し、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成し、当該生成した新たなインデックスキーに基づき、新たな前記インデックスを保存する第３の前記データ管理装置を決定し、
前記決定した第３のデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含むインデックス登録要求メッセージを送信し、
前記第２のデータ管理装置は、さらに、ルート情報更新処理部を備えており、
前記ルート情報更新処理部が、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録し、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に保存し、
前記第３のデータ管理装置は、インデックス登録処理部を備えており、
前記インデックス登録処理部が、
前記インデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に保存すること
を特徴とする請求項７に記載の分散ＩＤ管理システム。
【請求項１０】
クライアント装置から要求メッセージを受信し、前記受信した要求メッセージを複数のデータ管理装置のうちのいずれかに振り分けるゲートウェイ装置と、前記振り分けられた前記要求メッセージを受信し、前記要求メッセージに示される処理を実行する前記複数のデータ管理装置とを備える分散ＩＤ管理システムであって、
前記複数のデータ管理装置それぞれは、通信可能に接続され、
前記ゲートウェイ装置および前記複数のデータ管理装置は、前記データ管理装置それぞれのアドレスを示す接続情報と、前記データ管理装置それぞれに対応したハッシュ値を示すノードＩＤとが格納されるノード情報が記憶される記憶部をそれぞれ備えており、
前記ゲートウェイ装置は、
前記要求メッセージとして、（１）管理対象を識別するための第１（ｉ＝１）の識別子、前記第１の識別子が利用される範囲を示す第１（ｉ＝１）のドメイン、および登録日時を示す第１（ｉ＝１）の登録情報と、（２）前記第１の識別子に示される管理対象と同一の管理対象を示す他の識別子である第２（ｉ＝２）の識別子、前記第２の識別子が利用される範囲を示す第２（ｉ＝２）のドメイン、および登録日時を示す第２（ｉ＝２）の登録情報と、を少なくとも含み、（ｉ）前記第１の識別子に示される管理対象と同一の管理対象を示す識別子である第ｉ（当該ｉは３以上の整数）の識別子、当該第ｉの識別子が利用される範囲を示す第ｉ（当該ｉは３以上の整数）のドメイン、および登録日時を示す第ｉ（当該ｉは３以上の整数）の登録情報と、を含むことができる情報の登録処理を要求するＩＤ登録要求メッセージを受信する送受信部と、
前記ＩＤ登録要求メッセージの先頭の識別子である前記第１の識別子と前記第１のドメインとを結合したインデックスキーを生成し、前記ゲートウェイ装置のノード決定部が決定した振り分け先となる第１のデータ管理装置に、前記ノード情報の前記接続情報を参照して、前記ＩＤ登録要求メッセージを送信するＩＤ登録転送部と、
前記第１のデータ管理装置を、前記ＩＤ登録転送部が生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記振り分け先となる前記第１の前記データ管理装置を決定する前記ノード決定部と、
前記第１のデータ管理装置は、
前記ＩＤ登録要求メッセージを受信する送受信部と、
前記管理対象を前記分散ＩＤ管理システムにおいて一意に特定するための識別子であるルートキーを生成するルートキー生成部と、
前記ＩＤ登録要求メッセージに基づき、第ｉ（ｉ＝１以上の整数）の識別子と第ｉ（ｉ＝１以上の整数）のドメインとを結合した第ｉ（ｉ＝１以上の整数）インデックスキーを生成し、
前記第ｉインデックスキー、前記登録日時および前記ルートキーを含むインデックス登録要求メッセージを生成し、前記第ｉインデックスキーを含むインデックスである第ｉインデックスの登録先である第（２×ｉ−１）のデータ管理装置に送信し、
前記第ｉのドメインと前記ルートキーとを結合した第ｉサブルートキーを生成し、
前記第ｉサブルートキー、前記登録日時および前記第ｉの識別子を含むルート情報登録要求メッセージを生成し、前記第ｉサブルートキーを含むルート情報である第ｉルート情報の登録先である第（２×ｉ）のデータ管理装置に送信するＩＤ登録処理部と、
前記ＩＤ登録処理部が生成した前記第ｉインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉインデックスの登録先を前記第（２×ｉ−１）のデータ管理装置に決定し、
前記ＩＤ登録処理部が生成した前記第ｉサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記第ｉルート情報の登録先を前記第（２×ｉ）のデータ管理装置に決定するノード決定部と、を備え、
前記第（２×ｉ−１）のデータ管理装置は、
前記インデックス登録要求メッセージを受信する送受信部と、
前記インデックス登録要求メッセージに基づき、前記第ｉインデックスキーおよび登録日時を前記ルートキーに対応付けた情報である前記第ｉインデックスを、自身の記憶部に登録するインデックス登録処理部と、を備え、
前記第（２×ｉ）のデータ管理装置は、
前記ルート情報登録要求メッセージを受信する送受信部と、
前記ルート情報登録要求メッセージに基づき、前記第ｉサブルートキーおよび登録日時を前記第ｉの識別子に対応付けた情報である前記第ｉルート情報を、自身の記憶部に登録するルート情報登録処理部と、を備えること
を特徴とする分散ＩＤ管理システム。
【請求項１１】
前記ゲートウェイ装置は、さらに、ＩＤ変換転送部を備えており、
前記ゲートウェイ装置の送受信部が、
前記要求メッセージとして、（１）変換元となる第１の識別子、変換元となる第１のドメイン、変換元の日時である変換元日時、および、（２）変換先となる第２のドメイン、変換先の日時である変換先日時、を含み、変換先となる第２の識別子の検索を要求するＩＤ変換要求メッセージを受信し、
前記ＩＤ変換転送部が、
前記ＩＤ変換要求メッセージの前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成し、
前記ノード決定部を介して、当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定し、
前記ＩＤ変換要求メッセージを、前記ノード情報の前記接続情報を参照して、前記決定したインデックスの登録先である前記データ管理装置に送信し、
前記インデックスの登録先であるデータ管理装置は、さらに、ＩＤ変換処理部を備えており、
前記ＩＤ変換処理部が、
受信した前記ＩＤ変換要求メッセージに基づき、前記第１の識別子と前記第１のドメインとを結合した前記インデックスキーを生成し、自身の記憶部に登録された前記インデックスを参照し、当該生成したインデックスキーおよび前記変換元日時をキーとして、前記ルートキーを取得し、
前記取得したルートキーと、前記ＩＤ変換要求メッセージに含まれる前記第２のドメインとを結合した前記サブルートキーを生成し、
前記ノード決定部を介して、当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定し、
前記サブルートキーおよび前記ＩＤ変換要求メッセージに含まれる前記変換先日時を含むＩＤ取得要求メッセージを生成し、前記決定したルート情報の登録先である前記データ管理装置に送信し、
前記ルート情報の登録先であるデータ管理装置は、さらに、ＩＤ取得処理部を備えており、
前記ＩＤ取得処理部が、
自身の記憶部に登録されたルート情報を参照し、受信した前記ＩＤ取得要求メッセージに含まれる前記サブルートキーおよび前記変換先日時をキーとして、前記変換先となる第２の識別子を取得し、
前記変換先となる第２の識別子を含むＩＤ取得応答メッセージを生成し、前記インデックスの登録先であるデータ管理装置に送信し、
前記インデックスの登録先であるデータ管理装置の前記ＩＤ変換処理部は、
受信した前記ＩＤ取得応答メッセージに基づき、前記変換先となる第２の識別子を含むＩＤ変換応答メッセージを生成し、前記ゲートウェイ装置を介して、前記クライアントに送信すること
を特徴とする請求項１０に記載の分散ＩＤ管理システム。
【請求項１２】
前記ゲートウェイ装置は、さらに、ＩＤ更新転送部を備えており、
前記ゲートウェイ装置の送受信部が、
前記要求メッセージとして、（１）更新対象識別子、更新対象ドメイン、更新対象日時、および、（２）更新後識別子、更新日時、を含み、前記更新対象ドメインの前記更新対象日時における前記識別子である前記更新対象識別子を、前記更新日時以降は前記更新後識別子に更新することを要求するＩＤ更新要求メッセージを受信し、
前記ＩＤ更新転送部が、
前記ＩＤ更新要求メッセージの前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、
前記ノード決定部を介して、当該生成したインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記インデックスの登録先である前記データ管理装置を決定し、
前記ＩＤ更新要求メッセージを、前記接続情報を参照して、当該決定したデータ管理装置に送信し、
前記インデックスの登録先であるデータ管理装置は、さらに、ＩＤ更新処理部を備えており、
前記ＩＤ更新処理部が、
前記ＩＤ更新要求メッセージに含まれる前記更新対象識別子と前記更新対象ドメインとを結合した前記インデックスキーを生成し、当該生成したインデックスキーおよび前記更新対象日時をキーとして、自身の記憶部から前記インデックスを抽出して、前記ルートキーを取得し、前記抽出したインデックスの失効日時として前記更新日時を当該インデックスに登録し、
前記ＩＤ更新要求メッセージに含まれる前記更新対象ドメインと前記ルートキーとを結合した前記サブルートキーを生成し、
当該生成したサブルートキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、前記ルート情報の登録先である前記データ管理装置を決定し、
当該決定したデータ管理装置へ、前記サブルートキーと、前記更新日時と、前記更新後識別子とを含むルート情報更新要求メッセージを送信し、
前記ＩＤ更新要求メッセージに含まれる前記更新後識別子と前記更新対象ドメインとを結合した新たな前記インデックスキーを生成し、
当該生成した新たなインデックスキーにハッシュ関数を適用してハッシュ値を算出し、前記ノード情報の前記ノードＩＤを参照して、新たな前記インデックスの登録先であるデータ管理装置を決定し、
当該決定したデータ管理装置へ、前記新たなインデックスキーと、前記更新日時と、前記取得したルートキーとを含む第２のインデックス登録要求メッセージを送信し、
前記ルート情報の登録先であるデータ管理装置は、さらに、ルート情報更新処理部を備えており、
前記ルート情報更新処理部が、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時をキーとして、自身の記憶部から前記ルート情報を抽出し、前記抽出したルート情報の失効日時として前記更新日時を登録し、
前記ルート情報更新要求メッセージに含まれる前記サブルートキーおよび前記更新日時を、前記更新後識別子に対応付けた情報を新たな前記ルート情報として、自身の記憶部に登録し、
前記新たなインデックスの登録先であるデータ管理装置は、インデックス登録処理部を備えており、
前記インデックス登録処理部は、
前記第２のインデックス登録要求メッセージに含まれる前記新たなインデックスキーおよび前記更新日時を、前記ルートキーに対応付けた情報を前記新たなインデックスとして、自身の記憶部に登録すること
を特徴とする請求項１０に記載の分散ＩＤ管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【公開番号】特開２０１３−９７４４１（Ｐ２０１３−９７４４１Ａ）
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１１−２３７３８５（Ｐ２０１１−２３７３８５）
【出願日】平成２３年１０月２８日（２０１１．１０．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願日】平成２３年１０月２８日（２０１１．１０．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
[ Back to top ]