特許 7584957 情報処理装置、情報処理方法、及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-08

(45)【発行日】2024-11-18

(54)【発明の名称】情報処理装置、情報処理方法、及び記憶媒体

(51)【国際特許分類】

   G06F 21/62 20130101AFI20241111BHJP

   G06F 16/36 20190101ALI20241111BHJP

【ＦＩ】

G06F21/62

G06F16/36

【請求項の数】 12

(21)【出願番号】P 2020153996

(22)【出願日】2020-09-14

(65)【公開番号】P2022047942

(43)【公開日】2022-03-25

【審査請求日】2023-09-08

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100090273

【弁理士】

【氏名又は名称】國分 孝悦

(72)【発明者】

【氏名】久保山 英生

【審査官】上島 拓也

(56)【参考文献】

【文献】米国特許出願公開第２００８／０２８８５４９（ＵＳ，Ａ１）

【文献】特開２０１９－０２０９８８（ＪＰ，Ａ）

【文献】米国特許出願公開第２００６／００８０５４４（ＵＳ，Ａ１）

【文献】特開２００６－１０６８９６（ＪＰ，Ａ）

【文献】特開２０００－０２９９０１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ １６／３６

(57)【特許請求の範囲】

【請求項1】

データの管理に係る識別情報において大文字と小文字との区別が行われない第一識別情報を含む第一スキーマのデータと、
前記識別情報に対応する前記第一識別情報と、当該識別情報において大文字と小文字との区別が行われる第二識別情報と、を含む第二スキーマのデータと、
を管理する管理手段と、
前記第一スキーマのデータを大文字と小文字の区別を行わずに登録または参照する第一アプリケーションを、前記第一スキーマに対して大文字と小文字との区別を行わず、前記第二スキーマに対して大文字と小文字との区別を行って参照し、当該第二スキーマを登録する第二アプリケーションに切り替える切り替え手段と、
前記切り替え後に前記第一スキーマを前記第二スキーマに更新する更新手段と、
を備える、情報処理装置。

【請求項2】

指定された前記識別情報に対応する前記第一識別情報が一致する１つ以上の前記第一スキーマまたは前記第二スキーマのデータを検索する検索手段
を備える、請求項１に記載の情報処理装置。

【請求項3】

前記検索手段により第一スキーマまたは第二スキーマのデータが１つ以上検索された場合に、前記識別情報が衝突すると判定する第一衝突判定手段と、
前記第一衝突判定手段により前記識別情報が衝突すると判定されなかった場合に、当該識別情報に対応する前記第一識別情報を含む前記第一スキーマのデータを所定の登録先に登録する第一登録手段と、
を備える、請求項２に記載の情報処理装置。

【請求項4】

前記検索手段により前記第一スキーマのデータが検索された場合に、検索された当該データを参照する第一参照手段を備える、請求項２または３に記載の情報処理装置。

【請求項5】

前記検索手段により、前記第一スキーマのデータ、または指定された前記識別情報と前記第二識別情報が一致する前記第二スキーマのデータが検索された場合に、前記識別情報が衝突すると判定する第二衝突判定手段と、
前記第二衝突判定手段により前記識別情報が衝突すると判定されなかった場合に、当該識別情報に対応する前記第一識別情報及び前記第二識別情報を含む前記第二スキーマのデータを所定の登録先に登録する第二登録手段と、
を備える、請求項２～４のいずれか１項に記載の情報処理装置。

【請求項6】

前記検索手段により、前記第一スキーマのデータ、または指定された前記識別情報と前記第二識別情報が一致する前記第二スキーマのデータが検索された場合に、検索された当該データを参照する第二参照手段
を備える、請求項２～５のいずれか１項に記載の情報処理装置。

【請求項7】

前記第一スキーマのデータを前記第二スキーマのデータに更新する更新手段
を備える、請求項１～６のいずれか１項に記載の情報処理装置。

【請求項8】

前記第二識別情報は、前記識別情報をハッシュ値に変換した文字列であり、
前記第一識別情報は、前記識別情報を大文字または小文字に変換したうえでハッシュ値に変換した文字列である、請求項１～７のいずれか１項に記載の情報処理装置。

【請求項9】

指定された前記識別情報に基づき検索される前記第一スキーマのデータまたは前記第二スキーマのデータに含まれる認証情報に基づき認証を行う認証部を備える、請求項１～８のいずれか１項に記載の情報処理装置。

【請求項10】

前記第二スキーマのデータは、前記第一識別情報を主キーとし、前記第二識別情報を副キーとする複合キーを含む、請求項１～９のいずれか１項に記載の情報処理装置。

【請求項11】

情報処理装置により実行される情報処理方法であって、
データの管理に係る識別情報において大文字と小文字との区別が行われない第一識別情報を含む第一スキーマのデータと、
前記識別情報に対応する前記第一識別情報と、当該識別情報において大文字と小文字との区別が行われる第二識別情報と、を含む第二スキーマのデータと、を管理する管理ステップと、
前記第一スキーマのデータを大文字と小文字の区別を行わずに登録または参照する第一アプリケーションを、前記第一スキーマに対して大文字と小文字との区別を行わず、前記第二スキーマに対して大文字と小文字との区別を行って参照し、当該第二スキーマを登録する第二アプリケーションに切り替える切り替えステップと、
前記切り替え後に前記第一スキーマを前記第二スキーマに更新する更新ステップと、
を含む、情報処理方法。

【請求項12】

請求項１１に記載の情報処理方法を実現するプログラムを記憶した記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、情報処理装置、情報処理方法、及び記憶媒体に関する。

【背景技術】

【0002】

各種データの管理に際し、対象となるデータにＩＤ（所謂、識別情報）を割り当て、当該ＩＤを当該データの管理に係るキーとして利用する場合がある。具体的な一例として、Ｗｅｂサービスを提供するシステムの構築に際し、データに対してＩＤを割り当て、当該ＩＤに対して、対象ユーザ、クライアントのパスワード、及び属性情報等の各種情報を関連付けて、これらの情報を管理する場合がある。このように、ＩＤを各種データの管理に利用する際に、ＩＤを構成する英字の大文字と小文字との違い（以降では、「ケース」とも称する）を区別してＩＤの一意性を保証する場合や、ケースを区別せずにＩＤの一意性を保証する場合がある。

【0003】

例えば、特許文献１には、文字列インデックスのインデックスキーの英文字を大文字または小文字に統一したうえで、文字列インデックスの検索を行う技術が開示されている。このような構成により、例えば、検索条件として指定した文字列に大文字と小文字とが混在しているような状況下においても、大文字と小文字との違いの区別なく、検索条件で指定された文字列と同じ綴りの文字列を含む各レコードの検索を行うことが可能となる。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２００２－６３２０２号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

一方で、ケースを区別せずにＩＤの一意性を保証するアプリケーションと、ケースを区別してＩＤの一意性を保証するアプリケーションと、が混在するような状況も想定され得る。また、このような環境下において、共通のシステムによる各種アプリケーションで利用されるＩＤの一括した管理が求められる場合もある。

【0006】

本発明は上記の問題を鑑み、識別情報に含まれる文字の大文字と小文字との区別に係る条件が異なるアプリケーションが混在する状況下においても、当該識別情報の管理をより好適な態様で実現可能とすることを目的とする。

【課題を解決するための手段】

【0007】

本発明に係る情報処理装置は、データの管理に係る識別情報において大文字と小文字との区別が行われない第一識別情報を含む第一スキーマのデータと、前記識別情報に対応する前記第一識別情報と、当該識別情報において大文字と小文字との区別が行われる第二識別情報と、を含む第二スキーマのデータと、を管理する管理手段と、前記第一スキーマのデータを大文字と小文字の区別を行わずに登録または参照する第一アプリケーションを、前記第一スキーマに対して大文字と小文字との区別を行わず、前記第二スキーマに対して大文字と小文字との区別を行って参照し、当該第二スキーマを登録する第二アプリケーションに切り替える切り替え手段と、前記切り替え後に前記第一スキーマを前記第二スキーマに更新する更新手段と、を備える。

【発明の効果】

【0008】

本発明によれば、識別情報に含まれる文字の大文字と小文字との区別に係る条件が異なるアプリケーションが混在する状況下においても、当該識別情報の管理をより好適な態様で実現することが可能となる。

【図面の簡単な説明】

【0009】

【図1】情報処理装置の機能構成の一例を示したブロック図である。

【図2】情報処理装置のハードウェア構成の一例を示した図である。

【図3】ケース区別なしのＩＤの管理に係るデータ構造の一例を示した図である。

【図4】ケース区別ありのＩＤの管理に係るデータ構造の一例を示した図である。

【図5】情報処理装置の処理の一例を示したフローチャートである。

【図6】情報処理装置の処理の他の一例を示したフローチャートである。

【図7】情報処理装置の処理の他の一例を示したフローチャートである。

【図8】情報処理装置の処理の他の一例を示したフローチャートである。

【図9】スキーマの切り替えに係る手順の一例を示した図である。

【発明を実施するための形態】

【0010】

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

【0011】

＜機能構成＞
図１を参照して、本実施形態に係る情報処理装置の機能構成の一例について説明する。
本実施形態に係る情報処理装置１０１は、各種アプリケーションがデータの管理等に利用するＩＤ（識別情報）の管理を行う。図１に示す例では、当該アプリケーションの一例として、第一アプリケーション１０２と、第二アプリケーション１０３とが示されている。
第一アプリケーション１０２は、各種データの管理等に利用するＩＤを構成する英字の大文字と小文字との違い（ケース）を区別せずに当該ＩＤの一意性を保証するアプリケーションを模式的に示している。
これに対して、第二アプリケーション１０３は、各種データの管理等に利用するＩＤを構成する英字の大文字と小文字との違い（ケース）を区別して当該ＩＤの一意性を保証するアプリケーションを模式的に示している。
なお、以降の説明では、ケースを区別してＩＤの一意性を保証する場合を「ケース区別あり」とも称し、ケースを区別せずにＩＤの一意性を保証する場合を「ケース区別なし」とも称する。

【0012】

本実施形態に係る情報処理装置１０１は、管理部１０４と、検索部１０５と、第一登録部１０６と、第二登録部１０７と、第一衝突判定部１０８と、第二衝突判定部１０９と、第一参照部１１０と、第二参照部１１１と、更新部１１２とを含む。

【0013】

管理部１０４は、ＩＤの管理を行う。例えば、管理部１０４は、各種アプリケーションが各種データの管理等に利用するＩＤの管理を行ってもよい。具体的な一例として、第一アプリケーション１０２や第二アプリケーション１０３が利用するＩＤは、後述する第一登録部１０６または第二登録部１０７により、管理部１０４に対する当該ＩＤの登録に係る処理が実行されることで、当該管理部１０４による管理の対象となる。

【0014】

検索部１０５は、ＩＤの検索を行う。例えば、検索部１０５は、管理部１０４が管理する一連のＩＤの中から、指定された条件を満たすＩＤの検索を行ってもよい。具体的な一例として、検索部１０５は、第一アプリケーション１０２や第二アプリケーション１０３からの依頼に応じて、これらのアプリケーションが利用するＩＤを、管理部１０４が管理する一連のＩＤの中から検索してもよい。

【0015】

第一登録部１０６及び第二登録部１０７は、指定されたＩＤを所定の登録先に登録する。例えば、第一登録部１０６及び第二登録部１０７は、指定されたＩＤを、管理部１０４の管理対象として登録してもよい。この際に、第一登録部１０６は、管理部１０４に対して、指定されたＩＤをケース区別なしのＩＤとして登録する。これに対して、第二登録部１０７は、管理部１０４に対して、指定されたＩＤをケース区別ありのＩＤとして登録する。
なお、第一登録部１０６や第二登録部１０７による登録の対象となる上記ＩＤ（例えば、第一アプリケーション１０２や第二アプリケーション１０３が利用するＩＤ）が、データの管理に係る「識別情報」の一例に相当する。また、上記ケース区別なしのＩＤが「第一識別情報」の一例に相当し、上記ケース区別ありのＩＤが「第二識別情報」の一例に相当する。

【0016】

第一衝突判定部１０８及び第二衝突判定部１０９は、ＩＤの登録に際し、当該ＩＤが衝突するか否かを（換言すると、同様のＩＤが既に登録されているか否か）を判定する。具体的には、第一衝突判定部１０８は、第一登録部１０６がＩＤの登録を行う際に、当該ＩＤが衝突するか否かを判定してもよい。これに対して、第二衝突判定部１０９は、第二登録部１０７がＩＤの登録を行う際に、当該ＩＤが衝突するか否かを判定してもよい。

【0017】

第一参照部１１０及び第二参照部１１１は、所定の登録先に登録されたＩＤの参照や、当該ＩＤを含むデータの参照に係る処理を実行する。例えば、第一参照部１１０及び第二参照部１１１は、管理部１０４の管理対象として登録された一連ＩＤのうち、指定されたＩＤの参照や、当該ＩＤを含むデータの参照を行ってもよい。この際に、第一参照部１１０は、第一登録部１０６により登録されたＩＤを、ケース区別なしで参照してもよい。これに対して、第二参照部１１１は、第二登録部１０７により登録されたＩＤを、ケース区別ありで参照してもよい。

【0018】

更新部１１２は、ケース区別なしのＩＤをケース区別ありのＩＤにスキーマ更新する。なお、更新部１１２によるＩＤの更新に係る処理の詳細については別途後述する。

【0019】

なお、図１に示す機能構成はあくまで一例であり、本実施形態に係る情報処理装置１０１の機能構成を限定するものではない。例えば、上述した情報処理装置１０１の構成要素のうちの少なくとも一部の構成要素が、複数の装置が協働することで実現されてもよい。具体的な一例として、上述した情報処理装置１０１の構成要素のうちの一部が、情報処理装置１０１とは異なる他の装置に設けられていてもよい。また、他の一例として、上述した情報処理装置１０１の構成要素のうちの少なくとも一部の構成要素の処理に係る負荷が複数の装置に分散されてもよい。

【0020】

＜ハードウェア構成＞
図２を参照して、本実施形態に係る情報処理装置のハードウェア構成の一例について説明する。図２に示すように、本実施形態に係る情報処理装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３とを含む。また、情報処理装置１０１は、ネットワークＩ／Ｆ２０４と、補助記憶装置２０５とを含む。ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、ネットワークＩ／Ｆ２０４と、補助記憶装置２０５とは、バス２０６を介して相互に接続されている。

【0021】

ＣＰＵ２０１は、情報処理装置１０１の各種動作を制御する中央演算装置である。例えば、ＣＰＵ２０１は、情報処理装置１０１全体の動作を制御してもよい。ＲＯＭ２０２は、ＣＰＵ２０１で実行可能な制御プログラムやブートプログラムなどを記憶する。ＲＡＭ２０３は、ＣＰＵ２０１の主記憶メモリであり、ワークエリア又は各種プログラムを展開するための一時記憶領域として用いられる。

【0022】

ネットワークＩ／Ｆ２０４は、外部の装置とのネットワーク（例えば、インターネット等）を介した通信に利用される。なお、ネットワークＩ／Ｆ２０４として適用されるデバイスは、通信経路の種別や適用される通信方式に応じて適宜変更されてもよい。

【0023】

補助記憶装置２０５は、各種データや各種プログラムを記憶する。補助記憶装置２０５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）に代表される不揮発性メモリ等のような、各種データを一時的または持続的に記憶可能な記憶デバイスにより実現される。また、他の一例として、補助記憶装置２０５は、フレキシブルディスク（ＦＤ：Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）やコンパクトディスク（ＣＤ：Ｃｏｍｐａｃｔ Ｄｉｓｋ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカード等により実現されてもよい。

【0024】

ＣＰＵ２０１が、ＲＯＭ２０２または補助記憶装置２０５に記憶されたプログラムをＲＡＭ２０３に展開し、このプログラムを実行することで、図１に示す機能構成が実現される。また、上記プログラムが実行されることで、図５～図８に示す処理が実現される。

【0025】

＜データ構造＞
図３及び図４を参照して、管理部１０４によるＩＤの管理に係るデータ構造（以下、「スキーマ」とも称する）の一例について以下に説明する。

【0026】

まず、図３について説明する。図３は、第一登録部１０６が対象となるＩＤをケース区別なしのＩＤとして登録する場合における、当該ＩＤに関する情報の管理に係るスキーマ（以下、「第一スキーマ」とも称する）の一例を示している。

【0027】

図３に示すように、第一スキーマは、主キー（Ｐｒｉｍａｒｙ Ｋｅｙ）３０１と、副キー（Ｓｕｂ Ｋｅｙ）３０２とを含む。管理部１０４は、主キー３０１及び副キー３０２からなる複合キーにより、各データが一意に特定されるように管理する。

【0028】

本実施形態では、第一登録部１０６は、主キー３０１に対して、登録の対象となるＩＤを構成する文字列中の英字を小文字に変換することで、大文字と小文字との区別をなくした当該ＩＤを指定する。具体的な一例として、元のＩＤが“ＡｄｍｉｎＵｓｅｒ００１”の場合には、大文字と小文字との区別をなくした当該ＩＤである“ａｄｍｉｎｕｓｅｒ００１”が主キー３０１に指定されることとなる。

【0029】

副キー３０２には、他のＩＤ（デバイスやアプリケーション等）と区別するためのＩＤの属性に関する情報が指定される。例えば、図３に示す例では、副キー３０２に対して、ユーザのＩＤであることを示す“Ｕｓｅｒ”が指定されている。ただし、本実施形態に係る第一スキーマにおいては、副キー３０２へのＩＤの属性に関する情報の指定は必須ではない。

【0030】

また、第一スキーマは、属性情報３０３として、各種の情報を設定可能であってもよい。例えば、図３に示す例では、対象となるＩＤに関連するパスワード（例えば、当該ＩＤを指定した認証に利用されるパスワード等）、当該ＩＤの登録日等が、属性情報３０３として設定されている。

【0031】

また、第一スキーマは、スキーマバージョン３０４として、対象となるＩＤの管理に適用されるスキーマの種別を示す情報が設定される。例えば、図３に示す例では、スキーマバージョン３０４に対して、対象となるＩＤをケース区別なしのＩＤとして管理するための第一スキーマが適用されていることを示す値である「０」が設定されている。

【0032】

次いで、図４について説明する。図４は、第二登録部１０７が対象となるＩＤをケース区別ありのＩＤとして登録する場合における、当該ＩＤに関する情報の管理に係るスキーマ（以下、「第二スキーマ」とも称する）の一例を示している。なお、図４では（ａ）及び（ｂ）としてケースが互いに異なるＩＤに関する情報の一例を示している。具体的には、図４（ａ）は、ＩＤを構成する文字列が“ＡｄｍｉｎＵｓｅｒ００２”の場合の一例を示している。これに対して、図４（ｂ）は、ＩＤを構成する文字列が“ＡＤＭＩＮＵＳＥＲ００２”の場合の一例を示している。

【0033】

図４に示すように、第二スキーマは、主キー（Ｐｒｉｍａｒｙ Ｋｅｙ）４０１と、副キー（Ｓｕｂ Ｋｅｙ）４０２とを含む。主キー４０１及び副キー４０２は、図３を参照して説明した第一スキーマにおける主キー３０１及び副キー３０２に相当する。

【0034】

本実施形態では、第二登録部１０７は、図３に示す例と同様に、主キー４０１に対して、登録の対象となるＩＤを構成する文字列中の英字を小文字に変換することで、大文字と小文字との区別をなくした当該ＩＤを指定する。そのため、図４（ａ）及び図４（ｂ）のそれぞれに示す例では、元のＩＤを構成する文字列中の英字が小文字に変換されることで、主キー４０１に対して同様に“ａｄｍｉｎｕｓｅｒ００２”が設定されている。

【0035】

副キー４０２には、他のＩＤ（デバイスやアプリケーション等）と区別するためのＩＤの属性と、対象となるＩＤをケース区別ありのＩＤとして示した情報とが指定される。具体的な一例として、図４に示す例では、副キー４０２として、プレフィックス“Ｕｓｅｒ－”と、ケース区別ありのＩＤとを組み合わせた情報が指定されている。これにより、大文字と小文字との区別が保持された元のＩＤを含む情報が副キー４０２に設定されることとなる。なお、図４に示す例はあくまで一例であり、副キー４０２に対して、ケース区別ありのＩＤを含む情報が設定されれば、当該情報の形式は特に限定はされない。
これにより、図４（ａ）及び図４（ｂ）それぞれに示す例は、主キー４０１に対して同じ情報が設定されたとしても、副キー４０２に対して異なる情報が設定されることとなり、主キー４０１及び副キー４０２からなる複合キーにより一意性を担保することが可能となる。

【0036】

また、第二スキーマは、図３を参照して説明した第一スキーマと同様に、属性情報３０３として、各種の情報を設定可能であってもよい。

【0037】

また、第二スキーマは、スキーマバージョン４０３として、対象となるＩＤの管理に適用されるスキーマの種別を示す情報が設定される。例えば、図４に示す例では、スキーマバージョン４０３に対して、対象となるＩＤをケース区別ありのＩＤとして管理するための第二スキーマが適用されていることを示す値である「１」が設定されている。

【0038】

管理部１０４は、図３に示すケース区別なしのＩＤに関する情報の管理に係る第一スキーマと、図４（ａ）及び図４（ｂ）に示すケース区別ありのＩＤに関する情報の管理に係る第二スキーマとを、共通のデータベースで管理する。なお、このように、第一スキーマに対応するデータと、第二スキーマに対応するデータとが混在するような状況下においても、主キー及び副キーよりなる複合キーにより、登録されたデータ間におけるＩＤの一意性を担保することが可能となる。

【0039】

検索部１０５は、管理部１０４が管理する一連のデータの中から、主キーとして管理されるケース区別なしのＩＤが一致する１つ以上のデータを検索する。具体的な一例として、図４に示す例の場合には、検索部１０５は、主キーが“ａｄｍｉｎｕｓｅｒ００２”であり、副キーが“Ｕｓｅｒ”で始まる全てのデータを検索してもよい。なお、検索部１０５による検索の対象には、図３に示す第一スキーマに対応するデータと、図４に示す第二スキーマに対応するデータとの双方が含まれ得る。そのため、この場合には、図４（ａ）及び図４（ｂ）に示すデータが検索結果に含まれることとなる。

【0040】

＜処理＞
図５～図８を参照して、本実施形態に係る情報処理装置１０１の処理の一例について、特にＩＤの管理（例えば、登録や参照等）に係る部分に着目して説明する。

【0041】

まず、図５を参照して、第一アプリケーション１０２が利用するＩＤを、管理部１０４にケース区別なしのＩＤとして管理されるように、当該管理部１０４の管理対象として登録する場合の処理の流れの一例について説明する。

【0042】

Ｓ５０１において、第一登録部１０６は、第一アプリケーション１０２から登録の対象となるＩＤの入力を受け付ける。なお、第一アプリケーション１０２は、ケース区別なしのＩＤを利用するアプリケーションである。そのため、第一登録部１０６は、第一アプリケーション１０２から、例えばＩＤを構成する文字列中の英字が小文字化されることでケース情報が失われたケース区別なしのＩＤの入力を受け付けることとなる。
なお、ケース区別なしのＩＤの形式については、ケースの区別なしにＩＤの一意性を担保することが可能であれば上記例には限定されない。例えば、情報処理装置１０１は、ＩＤを構成する文字列中の英字が大文字化されることでケース情報が失われたケース区別なしのＩＤの入力を受け付けてもよい。

【0043】

次いで、Ｓ５０２～Ｓ５０４において、第一登録部１０６が入力を受け付けたＩＤが衝突するか否かの判定が行われる。

【0044】

具体的には、Ｓ５０２において、第一登録部１０６が入力を受け付けたＩＤ（換言すると、登録対象のＩＤ）と一致するＩＤを含むデータの検索が行われる。具体的には、第一衝突判定部１０８は、第一登録部１０６からの依頼に基づき、検索部１０５に対して、登録対象のＩＤと一致するＩＤを含むデータの検索を指示する。検索部１０５は、第一衝突判定部１０８からの指示に応じて、管理部１０４が管理する一連のデータの中から、第一衝突判定部１０８から指定されたＩＤ（登録対象のＩＤ）と一致するＩＤを含むデータを検索する。なお、検索方法については前述したとおりである。また、この場合には、第一スキーマに対応するデータと、第二スキーマに対応するデータとの双方が検索の対象となる。

【0045】

Ｓ５０３において、第一衝突判定部１０８は、Ｓ５０２における検索部１０５による検索の結果に基づき、第一登録部１０６が入力を受け付けたＩＤ（登録対象のＩＤ）が衝突するか否かを判定する。具体的には、第一衝突判定部１０８は、登録対象のＩＤと一致するＩＤを含むデータが検索部１０５により検索された場合に、登録対象のＩＤが衝突すると判定する。なお、この場合には、ケース区別なしのＩＤに関する情報を表す第一スキーマに対応するデータと、ケース区別ありのＩＤに関する情報を表す第二スキーマに対応するデータとの双方ともに、ケース区別なしに、登録対象のＩＤとの衝突判定が行われることとなる。

【0046】

Ｓ５０４において、第一登録部１０６は、Ｓ５０３における第一衝突判定部１０８によるＩＤが衝突したか否かの判定結果を確認し、当該判定結果に応じて以降の処理を切り替える。
具体的には、第一登録部１０６は、Ｓ５０４においてＩＤが衝突すると判定されたことを確認した場合には、処理をＳ５０５に進める。Ｓ５０５において、第一登録部１０６は、依頼元となる第一アプリケーション１０２に対して、指定されたＩＤ（登録対象のＩＤ）が衝突することを示すエラーを返却し、図５に示す一連の処理を終了する。具体的な一例として、情報処理装置１０１が、Ｒｅｓｔ ＡＰＩを利用して各種アプリケーションに機能を提供している場合には、「ステータスコード４０９ Ｃｏｎｆｌｉｃｔ」のエラーを依頼元のアプリケーションに返却することとなる。
一方で、第一登録部１０６は、Ｓ５０４においてＩＤが衝突しないと判定されたことを確認した場合には、処理をＳ５０６に進める。Ｓ５０６において、第一登録部１０６は、指定されたＩＤを含むデータを、第一スキーマに対応するデータとして管理部１０４に登録する。これにより、当該ＩＤが管理部１０４による管理の対象となる。そして、第一登録部１０６は、依頼元となる第一アプリケーション１０２に対して指定されたＩＤ（登録対象のＩＤ）の登録が正常に完了したことを通知し、図５に示す一連の処理を終了する。

【0047】

次いで、図６を参照して、第二アプリケーション１０３が利用するＩＤを、管理部１０４にケース区別ありのＩＤとして管理されるように、当該管理部１０４の管理対象として登録する場合の処理の流れの一例について説明する。

【0048】

Ｓ６０１において、第二登録部１０７は、第二アプリケーション１０３から登録の対象となるＩＤの入力を受け付ける。なお、第二アプリケーション１０３は、ケース区別ありのＩＤを利用するアプリケーションである。そのため、第二登録部１０７は、第二アプリケーション１０３から、ケース情報が残されたＩＤの入力を受け付けることとなる。
Ｓ６０２において、第二登録部１０７は、第二アプリケーション１０３から入力を受け付けたＩＤから、ケース区別なしのＩＤを生成する。

【0049】

Ｓ６０３において、検索部１０５は、Ｓ６０２において生成されたケース区別なしＩＤと、ケースの区別なしに一致するＩＤを含むデータを検索する。なお、検索方法については前述したとおりである。また、この場合には、第一スキーマに対応するデータと、第二スキーマに対応するデータとの双方が検索の対象となる。

【0050】

Ｓ６０４において、第二衝突判定部１０９は、Ｓ６０３における検索部１０５による検索の結果に基づき、第二登録部１０７が入力を受け付けたＩＤが衝突するか否かを判定する。具体的には、第二衝突判定部１０９は、副キー４０２に含まれるケース区別ありＩＤが登録対象となるＩＤと一致する第二スキーマに対応するデータが検索された、または第一のスキーマに対応するデータが検索された場合に、登録対象のＩＤが衝突すると判定する。
なお、図４に示す例の場合には、第二スキーマに対応するデータにおいて副キー４０２に設定された文字列のうち、“Ｕｓｅｒ－”以降の部分がケース区別ありのＩＤに相当する。また、この場合には、第一スキーマに対応するデータについてはケース区別なしでＩＤの衝突判定が行われ、第二スキーマに対応するデータについてはケース区別ありでＩＤの衝突判定が行われることとなる。

【0051】

Ｓ６０５において、第二登録部１０７は、Ｓ６０４における第二衝突判定部１０９によるＩＤが衝突したか否かの判定結果を確認し、当該判定結果に応じて以降の処理を切り替える。
具体的には、第二登録部１０７は、Ｓ６０５においてＩＤが衝突すると判定されたことを確認した場合には、処理をＳ６０６に進める。Ｓ６０６において、第二登録部１０７は、依頼元となる第二アプリケーション１０３に対して、指定されたＩＤ（登録対象のＩＤ）が衝突することを示すエラーを返却し、図６に示す一連の処理を終了する。
一方で、第二登録部１０７は、Ｓ６０６においてＩＤが衝突しないと判定されたことを確認した場合には、処理をＳ６０７に進める。Ｓ６０７において、第二登録部１０７は、指定されたＩＤを含むデータを、第二スキーマに対応するデータとして管理部１０４に登録する。これにより、当該ＩＤが管理部１０４による管理の対象となる。そして、第二登録部１０７は、依頼元となる第二アプリケーション１０３に対して指定されたＩＤ（登録対象のＩＤ）の登録が正常に完了したことを通知し、図６に示す一連の処理を終了する。

【0052】

次いで、図７を参照して、管理部１０４の管理対象のデータから、第一アプリケーション１０２が利用するＩＤとケース区別なしで一致するＩＤを含むデータを検索して、当該データを参照する場合の処理の流れの一例について説明する。

【0053】

Ｓ７０１において、第一参照部１１０は、第一アプリケーション１０２からデータ参照の対象となるＩＤの入力を受け付ける。なお、第一アプリケーション１０２は、ケース区別なしのＩＤを利用するアプリケーションである。そのため、第一参照部１１０は、第一アプリケーション１０２から、例えばＩＤを構成する文字列中の英字が小文字化されることでケース情報が失われたケース区別なしのＩＤの入力を受け付けることとなる。

【0054】

Ｓ７０２において、検索部１０５は、第一参照部１１０からの指示に応じて、管理部１０４が管理する一連のデータの中から、当該第一参照部１１０が入力を受け付けたＩＤ（換言すると、参照対象のＩＤ）と一致するＩＤを含むデータの検索を行う。なお、検索方法については前述したとおりである。また、この場合には、第一スキーマに対応するデータと、第二スキーマに対応するデータとの双方が検索の対象となる。

【0055】

Ｓ７０３において、第一参照部１１０は、Ｓ７０２における検索部１０５により検索の結果に第一スキーマに対応するデータが含まれる場合に、当該データを、第一アプリケーション１０２から入力を受け付けたＩＤと一致するＩＤを含むデータと判定する。
Ｓ７０４において、第一参照部１１０は、Ｓ７０３における検索部１０５による、参照対象のＩＤと一致するＩＤを含むデータの検索結果に基づく判定の結果に応じて以降の処理を切り替える。
具体的には、第一参照部１１０は、Ｓ７０４において参照対象のＩＤと一致するＩＤを含むと判定されたデータが検索された場合には、処理をＳ７０５に進める。Ｓ７０５において、第一参照部１１０は、参照対象のＩＤと一致するＩＤを含むと判定されたデータ（換言すると、検索部１０５により検索されたデータ）を、依頼元となる第一アプリケーション１０２に返却し、図７に示す一連の処理を終了する。
一方で、第一参照部１１０は、Ｓ７０４において参照対象のＩＤと一致するＩＤを含むと判定されたデータが検索されなかった場合には、処理をＳ７０７に進める。Ｓ７０７において、第一参照部１１０は、依頼元となる第一アプリケーション１０２に対して、参照対象のＩＤと一致するＩＤを含むデータが存在しないことを示すエラーを返却し、図７に示す一連の処理を終了する。具体的な一例として、情報処理装置１０１が、Ｒｅｓｔ ＡＰＩを利用して各種アプリケーションに機能を提供している場合には、「ステータスコード４０４ Ｎｏｔ Ｆｏｕｎｄ」のエラーを依頼元のアプリケーションに返却することとなる。

【0056】

次いで、図８を参照して、管理部１０４の管理対象のデータから、第二アプリケーション１０３が利用するＩＤとケース区別ありで一致するＩＤを含むデータを検索して、当該データを参照する場合の処理の流れの一例について説明する。

【0057】

Ｓ８０１において、第二参照部１１１は、第二アプリケーション１０３からデータ参照の対象となるＩＤの入力を受け付ける。なお、第二アプリケーション１０３は、ケース区別ありのＩＤを利用するアプリケーションである。そのため、第二参照部１１１は、第二アプリケーション１０３から、ケース情報が残されたＩＤの入力を受け付けることとなる。
Ｓ８０２において、第二参照部１１１は、第二アプリケーション１０３から入力を受け付けたＩＤから、ケース区別なしのＩＤを生成する。

【0058】

Ｓ８０３において、検索部１０５は、Ｓ８０２において生成されたケース区別なしＩＤと、ケースの区別なしに一致するＩＤを含むデータを検索する。なお、検索方法については前述したとおりである。また、この場合には、第一スキーマに対応するデータと、第二スキーマに対応するデータとの双方が検索の対象となる。

【0059】

Ｓ８０４において、第二参照部１１１は、Ｓ８０３における検索部１０５により検索の結果に第一スキーマに対応するデータが含まれる場合に、当該データを、第二アプリケーション１０３から入力を受け付けたＩＤと一致するＩＤを含むデータと判定する。また、第二参照部１１１は、検索の結果に、ケース区別ありＩＤが一致する第二スキーマのデータ、または第一スキーマのデータが含まれた場合も同様の判定を行う。

【0060】

Ｓ８０５において、第二参照部１１１は、Ｓ８０４における検索部１０５による参照対象のＩＤと一致するＩＤを含むデータの検索結果に基づく判定の結果に応じて以降の処理を切り替える。具体的には、第二参照部１１１は、副キー４０２に含まれるケース区別ありＩＤが参照対象となるＩＤと一致する第二スキーマに対応するデータと、第一のスキーマに対応するデータと、のいずれかが検索されたか否かを判定することとなる。

【0061】

第二参照部１１１は、Ｓ８０５において参照対象のＩＤと一致するＩＤを含むと判定されたデータが検索された場合には、処理をＳ８０６に進める。Ｓ８０６において、第二参照部１１１は、参照対象のＩＤと一致するＩＤを含むと判定されたデータ（換言すると、検索部１０５により検索されたデータ）を、依頼元となる第二アプリケーション１０３に返却し、図８に示す一連の処理を終了する。
一方で、第二参照部１１１は、Ｓ８０５において参照対象のＩＤと一致するＩＤを含むと判定されたデータが検索されなかった場合には、処理をＳ８０７に進める。Ｓ８０７において、第二参照部１１１は、依頼元となる第二アプリケーション１０３に対して、参照対象のＩＤと一致するＩＤを含むデータが存在しないことを示すエラーを返却し、図８に示す一連の処理を終了する。

【0062】

＜作用効果＞
以上のような構成により、本実施形態に係る情報処理装置１０１に依れば、以下に列挙する機能を実現することが可能となる。
１．ケースを区別せずに利用されているＩＤの衝突判定を、ケース区別なしで登録されたＩＤとケース区別ありで登録されたＩＤとの双方を対象として、ケースの区別なしの条件下で行う。
２．ケースの区別なしに利用されているＩＤと登録済みのＩＤとの一致に係る判定に際し、ケース区別なしで登録されたＩＤを判定の対象とし、ケース区別ありで登録されたＩＤを判定の対象としない。
３．ケースを区別して利用されているＩＤの衝突判定を、ケース区別なしで登録されたＩＤを対象とする場合にはケース区別なしの条件下で行い、ケース区別ありで登録されたＩＤを対象とする場合にはケース区別ありの条件下で行う。
４．ケースを区別して利用されているＩＤと登録済みのＩＤとの一致に係る判定に際し、ケース区別なしで登録されたＩＤを対象とする場合にはケース区別なしで判定し、ケース区別ありで登録されたＩＤを対象とする場合にはケース区別ありで判定する。

【0063】

＜変形例＞
続いて、本実施形態に係る情報処理装置１０１の変形例について以下に説明する。

【0064】

（変形例１）
本実施形態に係る情報処理装置の変形例１について以下に説明する。
上述した実施形態では、第二アプリケーション１０３からの依頼に基づき登録されたＩＤについては、第一アプリケーション１０２からの参照が制限される。また、第一アプリケーション１０２からの依頼に基づき登録されたＩＤについては、第二アプリケーションからの参照の対象となるが、ケース区別なしの条件下での参照となる。
一方で、アプリケーションのアップデートに伴い、当該アプリケーションにおけるＩＤの管理方法が、ケース区別なしの管理方法からケース区別ありの管理方法に変更されるような状況も想定され得る。
このような状況を鑑み、本変形例では、ＩＤの管理を、ケース区別なしの管理から、ケース区別ありの管理に切り替える方法の一例について以下に説明する。

【0065】

本変形例では、第一アプリケーション１０２をアップデート等により第二アプリケーション１０３に切り替えるため、第二アプリケーション１０３からの依頼に基づき登録されたＩＤを、第一アプリケーション１０２が参照するような状況は想定されないものとする。一方で、第一アプリケーション１０２からの依頼に基づき登録されたＩＤは、ケース区別なしでの管理（第一スキーマに基づく管理）が継続される。そのため、ケース区別ありでの参照や、ケース違いのＩＤの登録を可能とするために、対象となるＩＤの管理を、第一スキーマに基づく管理から第二スキーマに基づく管理に変更する必要が生じる場合がある。

【0066】

そこで、図９を参照して、第一アプリケーション１０２からの依頼に基づき登録された第一スキーマに基づき管理されるケース区別なしのＩＤを、第二スキーマに基づき管理されるケース区別ありのＩＤに切り替える手順の一例について以下に説明する。

【0067】

Ｓ９０１は、第一アプリケーション１０２に相当する各種アプリケーションが管理対象となっており、こられのアプリケーションが第二アプリケーション１０３にアップデートされる前の状態を模式的に示している。すなわち、Ｓ９０１においては、情報処理装置１０１は、管理対象となる上記各種アプリケーションが利用するＩＤを、図３を参照して説明した第一スキーマに基づき管理することとなる。そのため、当該ＩＤの登録及び参照には、第一スキーマにおける主キー３０１及び副キー３０２が利用されることとなる。

【0068】

Ｓ９０２～Ｓ９０５は、アプリケーションのアップデートと、当該アップデートに伴う当該アプリケーションが利用するＩＤの管理の切り替えに係る手順に相当する。
具体的には、Ｓ９０２において、まず対象となるアプリケーションが利用するＩＤの管理の主体を、本実施形態に係る情報処理装置１０１に切り替えるための各種手続きが実行される。具体的な一例として、ＤＮＳ等によりＵＲＬに対するルーディングを、元のＩＤ管理の主体となる情報処理装置から、本実施形態に係る情報処理装置１０１に切り替えるための各種手続きが実行されてもよい。このような手続きが実行されることで、対象となるアプリケーション（第一アプリケーション１０２）自体の修正を伴わずに、ＩＤ管理の主体を、元の情報処理装置から本実施形態に係る情報処理装置１０１に切り替えることが可能となる。
なお、Ｓ９０２の段階では、対象となるアプリケーションは、これまでと同様にケース区別なしにＩＤの登録及び参照を行い、ＩＤ管理の主体となる情報処理装置も第一スキーマに基づきＩＤの管理を行うこととなるが、第二スキーマを処理するための準備が整う。

【0069】

Ｓ９０３において、対象となるアプリケーションが、アップデート等により、第一アプリケーション１０２から同様の機能を実現するための第二アプリケーション１０３に切り替えられる。なお、機能ごとに第一アプリケーション１０２が複数存在する場合も想定され得る。このような場合には、例えば、複数のアプリケーションそれぞれの切り替えが順次行われる。
なお、Ｓ９０３の段階のうち、特にアプリケーションの切り替えが順次行われている状況下では、ＩＤの登録及び参照を行うアプリケーションとして、第一アプリケーション１０２と第二アプリケーション１０３とが混在し得る。このような場合においても、情報処理装置１０１がＩＤ管理の主体となるため、ＩＤの登録や参照の依頼元となるアプリケーションが、第一アプリケーション１０２及び第二アプリケーション１０３のいずれかに応じて、処理が選択的に切り替えられる。
具体的には、第一アプリケーション１０２が依頼元の場合には、ＩＤの登録及び参照がケースの区別なしに行われることとなる。これに対して、第二アプリケーション１０３が依頼元の場合には、ＩＤの登録及び参照がケースの区別ありで行われることとなる。ただし、第二アプリケーション１０３からの依頼に基づき、第一アプリケーション１０２が登録したＩＤを対象として参照や衝突判定が行われる場合には、ケースの区別なしにこれらの処理が実行されることとなる。

【0070】

Ｓ９０４は、Ｓ９０３の処理の進行に伴い、対象となる一連のアプリケーションそれぞれについての、第一アプリケーション１０２から第二アプリケーション１０３への切り替えが完了した段階を示している。すなわち、Ｓ０９４においては、第一アプリケーション１０２からの依頼に基づくＩＤの参照や登録は想定されないこととなる。一方で、第一アプリケーション１０２からの依頼に基づき登録されたＩＤについては残留している。そのため、第二アプリケーション１０３からの依頼に基づき、第一アプリケーション１０２が登録したＩＤを対象として参照や衝突判定が行われる場合には、依然としてケースの区別なしにこれらの処理が実行されることとなる。

【0071】

そして、Ｓ９０５において、更新部１１２は、第一スキーマのデータを第二スキーマのデータに更新する。なお、第一スキーマのデータは、ケース区別ありの元のＩＤに関する情報を保持していない場合がある。このような場合には、更新部１１２は、他のサービスやデータベース等から元のＩＤに関する情報（例えば、当該ＩＤ自体）を取得し、当該元のＩＤに関する情報を利用して第一スキーマのデータを第二スキーマのデータに更新すればよい。もちろん、更新部１１２が元のＩＤに関する情報を取得することが可能であれば、その方法については特に限定はされない。
また、第一スキーマのデータを第二スキーマのデータに更新する際に、対応するアプリケーション（第二アプリケーション１０３）からデータの参照が行われる場合がある。そのため、例えば、更新部１１２は、更新後のデータである第二スキーマのデータを生成した後に、更新前のデータである第一スキーマのデータを削除することで、対象となるデータの更新を行ってもよい。このような制御が適用されることで、対象となるＩＤに対応するデータが存在しない期間が発生しないため、アプリケーションがデータを参照した際に、当該アプリケーションが利用するＩＤに対応するデータが存在しない事態の発生を防止することが可能となる。

【0072】

上記に説明したようにスキーマの更新が行われることで、第一アプリケーション１０２からの依頼に基づきケース区別なしでＩＤが管理される第一スキーマのデータが、ケース区別ありでＩＤが管理される第二スキーマのデータに更新される。そのため、対象となるアプリケーションが、アップデート等により第一アプリケーション１０２から第二アプリケーション１０３に更新された場合においても、当該アプリケーションがケース区別ありでＩＤの登録及び参照を行うことが可能となる。
以上のように、ＩＤ管理の主体となる情報処理装置とＩＤを利用するアプリケーションとを更新することで、ユーザによるアプリケーションの利用を停止することなく、ＩＤ管理をケース区別なしの管理からケース区別ありの管理に切り替えることが可能となる。

【0073】

（変形例２）
次いで、本実施形態に係る情報処理装置の変形例２について以下に説明する。
上述した実施形態では、主キー３０１及び４０１としてケース区別なしのＩＤ（例えば、元のＩＤを小文字化した文字列）を管理し、副キー４０２としてケース区別ありのＩＤ（例えば、元のＩＤを含む文字列）を管理する場合の一例について説明した。

【0074】

一方で、第二スキーマのデータがケース区別なしのＩＤとケース区別ありのＩＤとの双方をキーとして含み、第一スキーマ及び第二スキーマそれぞれのデータに一意性を持たせつつ、ケース区別なしのＩＤを利用して検索が可能であれば、その方法は限定されない。

【0075】

また、主キー及び副キーとして設定される情報は、ケース区別ありのＩＤ自体やケース区別なしのＩＤ自体に限らず、これらを所定のアルゴリズムに基づき他の形式に変換したものであってもよい。具体的な一例として、ケース区別ありのＩＤとケース区別なしのＩＤとのそれぞれをハッシュ値に変換した文字列が、主キー及び副キーとして設定されてもよい。
ただし、ＩＤをハッシュ値に変換する処理をアプリケーション側で行う場合には、情報処理装置１０１が、ケース区別ありのＩＤが変換されたハッシュ値から、ケース区別なしのＩＤが変換されたハッシュ値を生成することは困難である。そのため、このような場合には、情報処理装置１０１は、依頼元のアプリケーション（第二アプリケーション１０３）から、ケース区別ありのＩＤが変換されたハッシュ値と、ケース区別なしのＩＤが変換されたハッシュ値との双方の入力を受け付けるとよい。

【0076】

（変形例３）
次いで、本実施形態に係る情報処理装置の変形例３について以下に説明する。
上述した実施形態では、第一参照部１１０及び第二参照部１１１それぞれが第一スキーマ及び第二スキーマそれぞれに対応するデータを対象としてＩＤの一致判定を行い、当該判定の結果に応じて依頼元のアプリケーションにデータを返却していた。一方で、本実施形態に係る技術は、上記に例示したデータの参照に限らず、他の機能の実現にも応用することが可能である。

【0077】

例えば、本実施形態に係る情報処理装置を利用して所謂認証サービスを実現することも可能である。この場合には、本実施形態に係る情報処理装置１０１は、第一アプリケーション１０２や第二アプリケーション１０３等のアプリケーションから、ＩＤに加えてパスワード等の認証情報の入力を受け付けてもよい。また、この場合には、情報処理装置１０１は、例えば、依頼元のアプリケーションからＩＤに加えて入力を受け付けた認証情報を、第一参照部１１０や第二参照部１１１により参照されたデータに含まれる認証情報と照合する認証部を含んでもよい。

【0078】

上記認証部は、例えば、入力を受け付けた認証情報と、データに含まれる認証情報とが一致した場合には、認証が成功したものと判定して認証トークンを発行し、当該認証トークンを依頼元のアプリケーションに返却してもよい。また、上記認証部は、例えば、入力を受け付けた認証情報と、データに含まれる認証情報とが一致しなかった場合には、認証が失敗したものと判定して、認証に係るエラーを依頼元のアプリケーションに返却してもよい。

【0079】

このように、本実施形態に係る技術は、データの参照に限らず、認証機能等の他の機能の実現にも応用することが可能であり、この際に、ケース区別なしのＩＤの管理と、ケース区別ありのＩＤの管理とをより好適な態様で両立することが可能となる。

【0080】

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記録媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
この場合には、記憶媒体から読み出されたプログラム自体が前述した実施形態の機能を実現することとなり、そのプログラムを記憶した記憶媒体が本発明を構成し得る。
プログラムを供給するための記憶媒体としては、例えば、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ等を用いることが可能である。
また、コンピュータが読み出したプログラムを実行することにより、実施形態として前述した機能が実現される例のみには限定されない。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）等が実際の処理の一部または全部を実行することで、その処理によって実施形態として前述した機能が実現されてもよい。
また、記憶媒体から読み出されたプログラムが、コンピュータに接続された機能拡張ユニットのメモリに書きこまれた後、その機能拡張ユニットのＣＰＵが実際の処理の一部または全部を実行することで、実施形態として前述した機能が実現されてもよい。

【符号の説明】

【0081】

１０１ 情報処理装置
１０２ 第一アプリケーション
１０３ 第二アプリケーション
１０４ 管理部
１０５ 検索部
１０８ 第一衝突判定部
１０９ 第二衝突判定部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】