JP6716929B2 - 情報処理装置及び情報処理プログラム - Google Patents

Description

本発明は、情報処理装置及び情報処理プログラムに関する。

特許文献１には、複数の情報サービスにおける情報を収集するためには、複数の情報サービスにアクセスすることが必要であることを課題とし、互いに異なる情報サービスにかかる特定情報を収集、表示するために、特定情報を変換する変換手段を設けておき、当該変換手段で特定情報を変換することによって、異なる情報サービスにおいて用いられている特定情報をも含む情報を一括して収集し、携帯端末に表示するシステムが得られることが開示されている。

特開２０１４−０４４４６５号公報

ＫｅｙＶａｌｕｅＳｔｏｒｅでは、データの呼称とデータが１対１の対応になっており、複数のシステム間で重複なくデータを管理するためには、その呼称として互いに独立の識別情報が必要である。
しかし、そのために、識別情報を管理するため処理が煩雑になっている。
そこで、本発明は、実体を基点にして、複数の呼称とデータの組を管理するようにした情報処理装置及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、トークンと実体の呼称と該実体を示す情報を対応させて記憶する第１の記憶手段と、トークンと実体を示す情報とハッシュ値を対応させて記憶する第２の記憶手段と、ハッシュ値とデータを対応させて記憶する第３の記憶手段と、ユーザーを示すトークンと呼称と該呼称で示される実体に関するデータに対する処理の指示を受け付けた場合は、該トークンと該実体を示す情報に対応する実体を示す情報を、前記第１の記憶手段から抽出する第１の抽出手段と、前記受け付けたトークンと前記第１の抽出手段によって抽出された実体を示す情報に対応するハッシュ値を、前記第２の記憶手段から抽出する第２の抽出手段と、前記第２の抽出手段によって抽出されたハッシュ値に対応するデータを、前記第３の記憶手段から抽出する第３の抽出手段と、前記第３の抽出手段によって抽出されたデータに対して、前記指示にしたがった処理を行う処理手段を有する情報処理装置である。

請求項２の発明は、コンピュータを、トークンと実体の呼称と該実体を示す情報を対応させて記憶する第１の記憶手段と、トークンと実体を示す情報とハッシュ値を対応させて記憶する第２の記憶手段と、ハッシュ値とデータを対応させて記憶する第３の記憶手段と、ユーザーを示すトークンと呼称と該呼称で示される実体に関するデータに対する処理の指示を受け付けた場合は、該トークンと該実体を示す情報に対応する実体を示す情報を、前記第１の記憶手段から抽出する第１の抽出手段と、前記受け付けたトークンと前記第１の抽出手段によって抽出された実体を示す情報に対応するハッシュ値を、前記第２の記憶手段から抽出する第２の抽出手段と、前記第２の抽出手段によって抽出されたハッシュ値に対応するデータを、前記第３の記憶手段から抽出する第３の抽出手段と、前記第３の抽出手段によって抽出されたデータに対して、前記指示にしたがった処理を行う処理手段として機能させるための情報処理プログラムである。

請求項１の情報処理装置によれば、実体を基点にして、複数の呼称とデータの組を管理することができる。

請求項２の情報処理プログラムによれば、実体を基点にして、複数の呼称とデータの組を管理することができる。

第１の実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を利用したシステム構成例を示す説明図である。 リソース管理装置の機能例を示す説明図である。 既存のＫｅｙＶａｌｕｅＳｔｏｒｅの処理例を示す説明図である。 既存のＫｅｙＶａｌｕｅＳｔｏｒｅの処理例を示す説明図である。 既存のＫｅｙＶａｌｕｅＳｔｏｒｅの処理例を示す説明図である。 既存のＫｅｙＶａｌｕｅＳｔｏｒｅの処理例を示す説明図である。 既存のＫｅｙＶａｌｕｅＳｔｏｒｅの処理例を示す説明図である。 呼称管理テーブルのデータ構造例を示す説明図である。 データ属性管理テーブルのデータ構造例を示す説明図である。 データ管理テーブルのデータ構造例を示す説明図である。 第１の実施の形態による処理例を示す説明図である。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示す説明図である。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示す説明図である。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示す説明図である。 第２の実施の形態の構成例についての概念的なモジュール構成図である。 トークン管理テーブルのデータ構造例を示す説明図である。 チケット管理テーブルのデータ構造例を示す説明図である。 呼称管理テーブル、データ属性管理テーブルのデータ構造例を示す説明図である。 第２の実施の形態による処理例を示す説明図である。 第２の実施の形態による処理例を示すフローチャートである。 第２の実施の形態による処理例を示す説明図である。 第２の実施の形態による処理例を示す説明図である。 トークン管理テーブルのデータ構造例を示す説明図である。 ユーザーチケット管理テーブルのデータ構造例を示す説明図である。 第２の実施の形態による処理例を示す説明図である。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

ＫｅｙＶａｌｕｅＳｔｏｒｅ（キーバリューストア）は、データの保存・管理手法の１つで、任意の保存したいデータ（値：ｖａｌｕｅ）に対し、対応する一意の標識（ｋｅｙ）を設定し、これらをペアで保存する方式である。また、そのような機能を提供するシステムやソフトウェアのことを指す場合も含む。
ＫＶＳでは保存したいデータに他のデータと識別するための文字列や数値（キーと呼ばれる）を割り当て、データとセットで記憶装置などに保管する。データの読み出し時には、予め設定したキーを指定すると、対応したデータを取り出すことができる。保存できるデータの種類は、文字列、画像、動画等のように電子データであればよい。

ＫｅｙＶａｌｕｅＳｔｏｒｅとして任意のデータをＨＴＴＰでＣＲＵＤできるシステムに、データを登録しデータ分析、活用に結び付けたい。
様々なシステムのデータを登録するので、それにより他のシステムが登録したデータが上書きされないようにするために、全体を統括するシステムはデータを登録するときにランダムの文字列を生成して、クライアントはそれを使って、そのデータの取得、更新、削除を行うシステムがある。
これにより、複数のシステムが保持しているデータを１か所に集めることが可能になる。
なお、ＣＲＵＤ（クラッド）とは、ほとんど全てのコンピュータソフトウェアが持つ４つの基本機能を示している。具体的には、Ｃｒｅａｔｅ（生成）、Ｒｅａｄ（読み取り）、Ｕｐｄａｔｅ（更新）、Ｄｅｌｅｔｅ（削除）である。ユーザーインタフェースが備えるべき機能（情報の参照／検索／更新）を指す用語としても使われる。図３の例に示すように、リソース管理装置３００は、Ｃｒｅａｔｅ３１０の指示を受けた場合、｛”ｋｅｙ”，”ｖａｌｕｅ”｝を登録し、その｛”ｋｅｙ”，”ｖａｌｕｅ”｝のペアを抽出するためのＩＤ（ランダムの文字列）を返す。そして、リソース管理装置３００は、Ｒｅａｄ３２０の指示を受けた場合、ＩＤ（Ｃｒｅａｔｅ３１０で返されたＩＤ）を指定された場合は、そのＩＤに対応する｛”ｋｅｙ”，”ｖａｌｕｅ”｝のペアを返す。また、リソース管理装置３００は、Ｕｐｄａｔｅ３３０の指示を受けた場合、ＩＤと｛”ｋｅｙ”，”ｖａｌｕｅ２”｝のペアを受け、そのＩＤに対応する｛”ｋｅｙ”，”ｖａｌｕｅ”｝を｛”ｋｅｙ”，”ｖａｌｕｅ２”｝に書き換えることを行う。そして、リソース管理装置３００は、Ｄｅｌｅｔｅ３４０の指示を受けた場合、ＩＤに対応するデータである｛”ｋｅｙ”，”ｖａｌｕｅ”｝（Ｕｐｄａｔｅ３３０の後は、｛”ｋｅｙ”，”ｖａｌｕｅ２”｝）を、リソース管理装置３００内から削除する。

複数のシステムを横断して、特定の実体（デバイスとも言われる）に対するデータの割り当てにランダムの文字列をＩＤに使うことで、以下のような課題が発生する。
・ＩＤを失わないためのインデックス作成
つまり、各システムが使っているＩＤとランダムの文字列の関係をどこかに持たせなければならない。
・複数のデータソースからの名寄せのためのＩＤのとりまとめ
つまり、複数のシステムを横断して、データを参照するときに個々のシステムが格納したＩＤを束ねて管理しなければならない。
・データを使用するときに、とりまとめたデータからデータのＩＤを抽出する処理
つまり、複数のシステムを横断して、データを参照した結果、他のデータを参照したい場合に関係が保存されていないので、関係を解決できるシステムに問い合わせなければならない。
図４の例に示すように、「（１）作成」として、実体に対して、ランダムの文字列であるＩＤを割り当てる。そして、「（２）作成」として、３つのＩＤをとりまとめて新たなＩＤ（ランダムの文字列）を割り当てる。次に、「（３）束ね情報として作成」として、（２）で作成したＩＤを実体のＩＤと対応付ける必要がある。そして、「（４）配信」として、各データツール（各システム）に各システムにおけるＩＤを配信して、「（５）受信してそれぞれ格納」として、各データツールで実体のＩＤとランダムの文字列であるＩＤの対を格納する必要がある。

このようにデータを作成した場合、本質の「データ」以外で多くの「データを束ねるデータ」を作らなければ運用できなくなってしまう。例えば、図５に示すように、データである「複合機サービス情報」、「フィールド情報」、「機能別カウンター情報」、「ユーザー情報」、「デバイス別集計結果」、「ユーザー別集計結果」、「事業所コード別集計結果」に対して、各システムでインデックスが複数作成されている。例えば、データ集計時の参照パスとして、「複合機サービス情報」等を参照するのに、「表意機種コードセット束」、「機械番号頭３桁束」、「機械番号束」、「デバイス情報束」のインデックスをたどって参照する必要がある。また、データ更新時の参照パスとして、「複合機サービス情報」を参照するのに、データ更新時の参照パスとして、「表意機種コードセット束」、「機械番号３桁束」、「機械番号束」のインデックスをたどって参照する必要がある。そして、「表意機種コードセット」、「表意機種コード」、「機種コード」のように、同じデバイスであってもシステムによって呼び方が異なるために、複数本のパスが存在することになる。

また、図６の例を用いて、データ追加時の更新処理の波及についても処理が膨大になることを説明する。
例えば、図５の例に示した構造に、セット追加対象６００の追加に伴い、インデックスに様々な情報を追加していかなければならない。
つまり、（１）セット追加対象６００を追加した場合、（Ａ２）機械番号束へ参照を追加し、（Ａ３）機械番号３桁束へ参照を追加し、（Ａ４）表意機種コードセット束へ参照を追加する。そして、（Ｂ２）機械番号束へ参照を追加し、（Ｂ３）機械番号３桁束へ参照を追加し、（Ｂ４）それぞれの機種コード束へ参照を追加する必要がある。
さらに、インデックスは参照先のデータがあって初めて、参照元のデータを作ることになるので、一括でデータを作ることが難しい。つまり、セット追加対象６００のデータの格納以外のインデックスに関して多くの処理を要する。

次に、図７の例を用いて、データ追加時の更新処理の波及について説明する。
（１）新サービス情報７１０のエントリを作成（追加）した場合、（２）デバイス情報束の全てを更新し、（３）機械番号束７２０、機械番号３桁束７３０、機種コードセット束７４０の順に作成する必要がある。つまり、このように、情報の種類を１つ追加するだけで、膨大な数の更新が発生する。
しかも、そのサービスを実際に使うかはユーザー次第であるため、無駄なエントリの作成や更新処理が発生していることになる。

既存のＫｅｙＶａｌｕｅＳｔｏｒｅシステムは、データの呼称とデータが１対１で対応してるため、重複なく割り付けるためには全く脈絡のないＩＤが必要になっていた。例えば、図８に示すように、実体８００を指し示すのに、システム８１０では「ＮＣ１００３５８−０００００１」を呼称８１２として用い、システム８３０では「Ａ４Ｃ５７０Ｇ４−０００００１」を呼称８３２として用い、システム８５０では「Ａ４Ｃ５７０ＮＧ−０００００１」を呼称８５２として用いている。
これが、前述したようなＩＤ管理の煩雑さを生み、システムを使いにくくしていた。図８の例では、基盤システム８７０では、１つの実体８００に対して、データ８１４の呼称８１２を用い、データ８３４の呼称８３２を用い、データ８５４の呼称８５２を用いなければならないことになる。
その本質は、実体を基点にして、複数の呼称と複数のデータがあることを考慮できていないためにそうなっており、実体を示す情報（ＩＤ）を利用することで解決が可能となる。

以下、図面に基づき本発明を実現するにあたっての好適な各種の実施の形態の例を説明する。
＜第１の実施の形態＞
図１は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に１対１に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態にしたがって、又はそれまでの状況・状態にしたがって定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、全ての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（１対１対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。

第１の実施の形態である情報処理装置１００は、ＫｅｙＶａｌｕｅＳｔｏｒｅとしての機能を有するものであって、図１の例に示すように、通信モジュール１１０、処理モジュール１２０、呼称記憶モジュール１３０、データ属性記憶モジュール１４０、データ記憶モジュール１５０を有している。
情報処理装置１００は、例えば、利用者識別のためにＯＡｕｔｈ２．０のＢｅａｒｅｒトークンによって認証を行うシステム等としてもよい。そして、ＲＥＳＴのインタフェースを提供し、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のＰＯＳＴ／ＧＥＴ／ＰＵＴ／ＤＥＬＥＴＥがデータの作成／取得／更新／削除に対応したシステムとしてもよい。
情報処理装置１００は、あるユーザー（自分以外のユーザー）が「ある呼称Ａ」で指す実体が、自分の「ある呼称Ｂ」で指すものと同じであることを設定できる機能を付けたシステムである。「ある呼称Ａ」、「ある呼称Ｂ」は、システム毎（あるユーザーが用いているシステム、自分のシステム）に異なっていてもよい。もちろんのことながら、同じ呼称であってもよい。

通信モジュール１１０は、処理モジュール１２０と接続されている。通信モジュール１１０は、他の情報処理装置と通信を行う。例えば、情報処理装置１００と通信を行う情報処理装置として、図２の例に示すようなユーザー端末２００、画像処理装置２１０等がある。
通信モジュール１１０は、他の情報処理装置から、「ユーザーを示すトークン」と「呼称」と「その呼称で示される実体に関するデータに対する処理の指示」を受け取る。ここで、「ユーザーを示すトークン」として、例えば、前述のＯＡｕｔｈ２．０のＢｅａｒｅｒトークン等を用いる。指示として、例えば、前述のＣＲＵＤがある。より具体的には、前述のＨＴＴＰのＰＯＳＴ／ＧＥＴ／ＰＵＴ／ＤＥＬＥＴＥ等が該当する。

呼称記憶モジュール１３０は、処理モジュール１２０と接続されている。呼称記憶モジュール１３０は、トークンと実体の呼称とその実体を示す情報を対応させて記憶する。例えば、呼称管理テーブル９００を記憶している。図９は、呼称管理テーブル９００のデータ構造例を示す説明図である。呼称管理テーブル９００は、トークン欄９１０、呼称欄９２０、実体ＩＤ欄９３０を有している。つまり、アクセストークンと呼称の組み合わせにより、実体を示すＩＤを管理する。トークン欄９１０は、トークンを記憶している。呼称欄９２０は、実体の呼称を記憶している。実体ＩＤ欄９３０は、本実施の形態において、実体を一意に識別するための情報（実体ＩＤ：ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）を記憶している。
ここで呼称は、ユーザーが用いているシステムにおける呼称であって、同じ実体に対してそのシステム毎に異なっていてもよい。つまり、同じ実体に対して、例えば、システムＡでは、「ＮＣ１００３５８−０００００１」であり、システムＢでは異なる名前である「Ａ４Ｃ５７０Ｇ４−０００００１」とすることを許すものである。もちろんのことながら、同じ実体に対して異なるシステムであっても同じ呼称であってもよい。

データ属性記憶モジュール１４０は、処理モジュール１２０と接続されている。データ属性記憶モジュール１４０は、トークンと実体を示す情報とハッシュ値を対応させて記憶する。例えば、データ属性管理テーブル１０００を記憶している。図１０は、データ属性管理テーブル１０００のデータ構造例を示す説明図である。データ属性管理テーブル１０００は、トークン欄１０１０、実体ＩＤ欄１０２０、ハッシュ値欄１０３０を有している。つまり、アクセストークンと実体を示すＩＤの組み合わせにより、データのハッシュ値を管理する。トークン欄１０１０は、トークンを記憶している。実体ＩＤ欄１０２０は、実体ＩＤを記憶している。ハッシュ値欄１０３０は、ハッシュ値を記憶している。

データ記憶モジュール１５０は、処理モジュール１２０と接続されている。データ記憶モジュール１５０は、ハッシュ値とデータを対応させて記憶する。例えば、データ管理テーブル１１００を記憶している。図１１は、データ管理テーブル１１００のデータ構造例を示す説明図である。データ管理テーブル１１００は、ハッシュ値欄１１１０、データ欄１１２０を有している。つまり、ハッシュ値をキーにデータを値としたＫｅｙＶａｌｕｅＳｔｏｒｅ型のデータベースである。ハッシュ値欄１１１０は、ハッシュ値を記憶している。データ欄１１２０は、データを記憶している。なお、データ欄１１２０内のデータの形態は、属性名と属性値のペア（組）であるが、この形態以外のデータ形態であってもよい。例えば、マトリックス、ファイル、画像、音声、動画等を含めてもよい。

処理モジュール１２０は、通信モジュール１１０、呼称記憶モジュール１３０、データ属性記憶モジュール１４０、データ記憶モジュール１５０と接続されている。処理モジュール１２０は、通信モジュール１１０が「ユーザーを示すトークン」と「呼称」と「その呼称で示される実体に関するデータに対する処理の指示」を受け付けた場合は、そのトークンとその実体を示す情報に対応する実体を示す情報を、呼称記憶モジュール１３０から抽出する。
そして、処理モジュール１２０は、「通信モジュール１１０が受け付けたトークン」と「抽出した実体を示す情報」に対応する「ハッシュ値」を、データ属性記憶モジュール１４０から抽出する。
次に、処理モジュール１２０は、「抽出したハッシュ値」に対応するデータを、データ記憶モジュール１５０から抽出する。
そして、抽出したデータに対して、通信モジュール１１０によって受け付けられた指示にしたがった処理を行う。

図２は、本実施の形態を利用したシステム構成例を示す説明図である。
情報処理装置１００、ユーザー端末２００Ａ、ユーザー端末２００Ｂ、ユーザー端末２００Ｃ、画像処理装置２１０Ａ、画像処理装置２１０Ｂは、通信回線２９０を介してそれぞれ接続されている。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。また、情報処理装置１００による機能は、クラウドサービスとして実現してもよい。
ユーザー端末２００は、ユーザーが使用する情報処理装置である。例えば、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ、例えば、デスクトップＰＣ、ノートＰＣ等を含む）や、携帯端末（スマートフォン等の携帯電話等）がある。画像処理装置２１０としては、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）等がある。例えば、画像処理装置２１０から処理の履歴（ログ）等が送られてきてもよい。この他に、情報家電、ロボット等であってもよい。

図１２は、第１の実施の形態による処理例を示す説明図である。
情報処理装置１００は、ユーザー端末１２１０から指示等１２１２、ユーザー端末１２２０から指示等１２２２、ユーザー端末１２３０から指示等１２３２を受け取る。指示等１２１２として、例えば、「ＰＯＳＴ／ＮＣ１００３５８−０００００１ Ａｕｔｈｏｒｉｚａｔｉｏｎ：Ｂｅａｒｅｒ ｄ７４３ａｆ８ｂ９７」がある。指示等１２２２として、例えば、「ＰＯＳＴ／Ａ４Ｃ５７０Ｇ４−０００００１ Ａｕｔｈｏｒｉｚａｔｉｏｎ：Ｂｅａｒｅｒ ｃａ０８３ｆ８ｄａｅ」がある。指示等１２３２として、例えば、「ＰＯＳＴ／Ａ４Ｃ５７０ＮＧ−０００００１ Ａｕｔｈｏｒｉｚａｔｉｏｎ：Ｂｅａｒｅｒ ３４７６６ａｆ９ｆ８」がある。つまり、前述の「呼称で示される実体に関するデータに対する処理の指示」と「呼称」と「トークン」を受け取る。
そして、それらの呼称は実体１２００（実体ＩＤ１２０２）を示しており、その実体１２００（実体ＩＤ１２０２）に対応付けられているデータ１２１４、データ１２２４、データ１２３４に対して指示に応じた処理を行う。詳細な処理内容については、図１３〜図１８の例を用いて説明する。

図１３は、第１の実施の形態による処理例を示すフローチャートである。
ステップＳ１３０２では、ユーザー端末からトークンと呼称の組み合わせを受け取る。
ステップＳ１３０４では、呼称管理テーブル９００を用いて、トークンと呼称の組み合わせに対応する実体ＩＤを抽出する。
ステップＳ１３０６では、データ属性管理テーブル１０００を用いて、トークンと実体ＩＤの組み合わせに対応するハッシュ値を抽出する。
ステップＳ１３０８では、データ管理テーブル１１００を用いて、ハッシュ値に対応するデータを抽出する。
ステップＳ１３１０では、ステップＳ１３０８で抽出したデータをユーザー端末に送信する。

図１４は、第１の実施の形態による処理例（図１３の例に示すフローチャートによる具体的処理例）を示す説明図である。呼称管理テーブル９００を用いて、ユーザーの指す実体を特定し、その実体とユーザーの組み合わせによってデータを特定する処理例を説明する。
ユーザー端末１２１０は、そのシステムにおける実体１２００の呼称１４１２とトークンであるユーザーＩＤ１４１４を情報処理装置１００に送信する。なお、図１４の例では、「指示」は省略しているが、例えば、Ｒｅａｄ（読み取り）等であってもよい。
情報処理装置１００は、呼称１４１２とユーザーＩＤ１４１４を受け取り、呼称管理テーブル９００から対象データ１４４０の行を抽出する。対象データ１４４０は、トークン欄９１０内のデータと、呼称欄９２０内のデータの組み合わせである。そして、対象データ１４４０に対応する実体ＩＤ欄９３０内の対象データ１４４５を抽出する。次に、データ属性管理テーブル１０００から、トークンであるユーザーＩＤ１４１４と対象データ１４４５の組み合わせの行（対象データ１４５０）を抽出する。対象データ１４５０は、トークン欄１０１０内のデータと、実体ＩＤ欄１０２０内のデータの組み合わせである。そして、対象データ１４５０に対応するハッシュ値欄１０３０内の対象データ１４５５を抽出する。次に、データ管理テーブル１１００から、対象データ１４５５に対応するハッシュ値欄１１１０内の対象データ１４６０を抽出する。そして、対象データ１４６０に対応する対象データ１４６５を抽出する。対象データ１４６５は、データ欄１１２０内のデータである。そして、その対象データ１４６５に対して、ユーザー端末１２１０から送信されてきた「指示」にしたがった処理を行う。前述のＲｅａｄ（読み取り）の例では、対象データ１４６５をユーザー端末１２１０に返信する。

図１５は、第１の実施の形態による処理例を示すフローチャートである。
ステップＳ１５０２では、ユーザー端末からトークンと呼称の組み合わせ（Ａ）とそれに対応する他のトークンと呼称の組み合わせ（Ｂ）を受け取る。
ステップＳ１５０４では、呼称管理テーブル９００を用いて、他のトークンと呼称の組み合わせ（Ｂ）に対応する実体ＩＤを抽出する。
ステップＳ１５０６では、呼称管理テーブル９００内に、トークンと呼称の組み合わせ（Ａ）と対応させて、ステップＳ１５０４で抽出した実体ＩＤを格納する。
ステップＳ１５０８では、データ追加成功をユーザー端末に送信する。

図１６は、第１の実施の形態による処理例（図１５の例に示すフローチャートによる具体的処理例）を示す説明図である。新たなデータ集合を追加する場合の処理例を示すものである。つまり、呼称と実体ＩＤの対応関係を登録するものである。
具体的には、ユーザー端末１６４０を用いるユーザーは、呼称の対応表を手に入れ、情報処理装置１００における名前登録用のインタフェースを通じて、自身の「会議室のコピー機」（呼称１６４２、実体１２００の呼称）は、ユーザー端末１２１０のユーザーＡにおける「ＮＣ１００３５８−０００００１」と同じであるということを登録する場合の処理である。つまり、１つの実体１２００に対して、ユーザー端末１６４０におけるシステムでは「会議室のコピー機」と命名し、ユーザー端末１２１０におけるシステムでは「ＮＣ１００３５８−０００００１」と命名されており、これが同じ実体であることを示す処理（名寄せ処理）である。図１６の例では、「指示」は省略しているが、Ｃｒｅａｔｅ（生成）である。

ユーザー端末１６４０は、トークンであるユーザーＩＤ１６４４と呼称対応データ１６５０を、情報処理装置１００に送信する。呼称対応データ１６５０は、ユーザーＩＤ１６４４（ユーザーＩＤ：ｂ１２ｆｆｄ６３５）の呼称１６４２（「会議室のコピー機」）は、ユーザーＩＤ１４１４（ｄ７４３ａｆ８ｂ９７）の呼称１４１２（ＮＣ１００３５８−０００００１）と同じ実体であることを示している。
情報処理装置１００は、ユーザーＩＤ１６４４、呼称１６４２、呼称対応データ１６５０を受け取り、呼称対応データ１６５０を用いて呼称管理テーブル９００から対象データ１６６０の行を抽出する。つまり、呼称対応データ１６５０内のトークンと呼称（呼称管理テーブル９００に既に登録されている呼称）の組み合わせである対象データ１６６０の行を抽出する。なお、対象データ１６６０は、トークン欄９１０内のデータと、呼称欄９２０内のデータの組み合わせである。そして、対象データ１６６０に対応する実体ＩＤ欄９３０内の対象データ１６６５を抽出する。
次に、呼称管理テーブル９００に新しい行（対象データ１６７０）を追加し、トークンであるユーザーＩＤ１６４４をトークン欄９１０に挿入し、呼称１６４２を呼称欄９２０に挿入し、対象データ１６６５を実体ＩＤ欄９３０に挿入する。なお、対象データ１６７０は、トークン欄９１０内のデータと、呼称欄９２０内のデータと、実体ＩＤ欄９３０内のデータの組み合わせである。
対象データ１６７０が呼称管理テーブル９００に追加されたことによって、ユーザーＩＤ１６４４のユーザーは、「会議室のコピー機」という呼称によって実体１２００と対応させることができるようになる。

図１７は、第１の実施の形態による処理例を示すフローチャートである。
ステップＳ１７０２では、ユーザー端末からトークンと呼称の組み合わせとデータを受け取る。
ステップＳ１７０４では、呼称管理テーブル９００を用いて、トークンと呼称の組み合わせに対応する実体ＩＤを抽出する。
ステップＳ１７０６では、データ属性管理テーブル１０００を用いて、トークンと実体ＩＤの組み合わせに対応するハッシュ値を抽出する。
ステップＳ１７０８では、データ管理テーブル１１００内に、ハッシュ値に対応させて、データを格納する。
ステップＳ１７１０では、データ追加成功をユーザー端末に送信する。

図１８は、第１の実施の形態による処理例（図１７の例に示すフローチャートによる具体的処理例）を示す説明図である。ＣＲＵＤのインタフェースを通じてデータを登録する例を示す。これによりユーザーを横断して束ねるデータを作成しなくても関連付けてデータを登録できることとなる。
具体的には、ユーザー端末１６４０のユーザーは、呼称１６４２（「会議室のコピー機」）について、登録データ１８５０（「状態：Ａ４用紙補充済」）を情報処理装置１００に登録するものである。図１８の例では、「指示」は省略しているが、Ｕｐｄａｔｅ（更新）である。

情報処理装置１００は、ユーザーＩＤ１６４４、呼称１６４２、登録データ１８５０を受け取り、トークンであるユーザーＩＤ１６４４、呼称１６４２を用いて呼称管理テーブル９００から対象データ１８６０の行を抽出する。なお、対象データ１８６０は、トークン欄９１０内のデータと、呼称欄９２０内のデータの組み合わせである。そして、対象データ１８６０に対応する実体ＩＤ欄９３０内の対象データ１８６５を抽出する。次に、データ属性管理テーブル１０００から、トークンであるユーザーＩＤ１６４４と対象データ１８６５の組み合わせの行（対象データ１８７０）を抽出する。対象データ１８７０は、トークン欄１０１０内のデータと、実体ＩＤ欄１０２０内のデータの組み合わせである。そして、対象データ１８７０に対応するハッシュ値欄１０３０内の対象データ１８７５を抽出する。次に、データ管理テーブル１１００から、対象データ１８７５に対応するハッシュ値欄１１１０内の対象データ１８８０を抽出する。そして、対象データ１８８０に対応するデータ欄１１２０内の対象データ１８８５を特定し、その対象データ１８８５に登録データ１８５０を格納する。

＜第２の実施の形態＞
図１９、第２の実施の形態の構成例についての概念的なモジュール構成図を示している。
情報処理装置１９００は、通信モジュール１１０、処理モジュール１９２０、トークン記憶モジュール１９３０、チケット記憶モジュール１９４０、呼称記憶モジュール１９５０、データ属性記憶モジュール１９６０、データ記憶モジュール１５０を有している。なお、前述の実施の形態と同種の部位には同一符号を付し重複した説明を省略する。
第２の実施の形態は、複数のシステム間を横断して、同じ実体に対応するデータの参照を実現するために、権限を表現するものとしてチケットという概念を、第１の実施の形態に対して導入する。
第１の実施の形態におけるトークン（アクセストークン）をチケットとして扱い、トークンは複数のチケットの集合とする。
チケットは他のユーザーに対して、権限を認可して、与えることを可能とする。
第１の実施の形態の構成に加えて、トークン記憶モジュール１９３０とチケット記憶モジュール１９４０を追加する。なお、呼称記憶モジュール１９５０は第１の実施の形態の呼称記憶モジュール１３０を拡張したものであり、データ属性記憶モジュール１９６０は第１の実施の形態のデータ属性記憶モジュール１４０を拡張したものである。
チケットはチケットの作成者であるオーナー名とオーナーが付けた任意のチケット名と、これまでトークンとして構成していた文字列を代替するチケットＩＤから構成されている。

通信モジュール１１０は、処理モジュール１９２０と接続されている。
トークン記憶モジュール１９３０は、処理モジュール１９２０と接続されている。トークン記憶モジュール１９３０は、「トークン」と「チケットの所有者を示す情報（いわゆるオーナーである）」と「そのチケットの名称」と「そのチケットが示す権限」を対応させて記憶する。例えば、トークン管理テーブル２０００を記憶している。図２０は、トークン管理テーブル２０００のデータ構造例を示す説明図である。トークン管理テーブル２０００は、トークン欄２０１０、チケット欄２０２０、権限欄２０３０を有している。チケット欄２０２０は、オーナー名欄２０２２、チケット名欄２０２４を有している。トークン欄２０１０は、トークンを記憶している。チケット欄２０２０は、チケットを記憶している。オーナー名欄２０２２は、そのチケットのオーナー名を記憶している。チケット名欄２０２４は、そのチケットのチケット名を記憶している。権限欄２０３０は、そのチケットによって許可された権限を記憶している。
なお、トークン記憶モジュール１９３０は、複数のチケット情報のエントリを持ち、そのチケット毎に設定された権限でデータ操作が可能となる。例えば、あるユーザーに認可するチケットではデータのＲＥＡＤしか行えないということが可能となる。

チケット記憶モジュール１９４０は、処理モジュール１９２０と接続されている。チケット記憶モジュール１９４０は、「所有者を示す情報」と「チケットの名称」と「そのチケットを示す情報」を対応させて記憶する。ここで「チケットを示す情報」とは、チケットを特定する情報（以下、チケットＩＤともいう）をいう。例えば、チケット管理テーブル２１００を記憶している。図２１は、チケット管理テーブル２１００のデータ構造例を示す説明図である。チケット管理テーブル２１００は、オーナー名欄２１１０、チケット名欄２１２０、チケットＩＤ欄２１３０を有している。オーナー名欄２１１０は、チケットのオーナー名を記憶している。チケット名欄２１２０は、そのチケットのチケット名を記憶している。チケットＩＤ欄２１３０は、本実施の形態において、チケットを一意に識別するための情報（チケットＩＤ）を記憶している。

呼称記憶モジュール１９５０は、処理モジュール１９２０と接続されている。呼称記憶モジュール１９５０は、「チケットを示す情報」と「実体の呼称」と「その実体を示す情報」を対応させて記憶する。例えば、呼称管理テーブル２２００を記憶している。図２２（ａ）は、呼称管理テーブル２２００のデータ構造例を示す説明図である。呼称管理テーブル２２００は、チケットＩＤ欄２２０２、呼称欄２２０４、実体ＩＤ欄２２０６を有している。チケットＩＤ欄２２０２は、チケットＩＤを記憶している。呼称欄２２０４は、呼称を記憶している。実体ＩＤ欄２２０６は、実体ＩＤを記憶している。つまり、図９の例に示した呼称管理テーブル９００のトークン欄９１０をチケットＩＤ欄２２０２としたものである。

データ属性記憶モジュール１９６０は、処理モジュール１９２０と接続されている。データ属性記憶モジュール１９６０は、「チケットを示す情報」と「実体を示す情報」と「ハッシュ値」を対応させて記憶する。例えば、データ属性管理テーブル２２２０を記憶している。図２２（ｂ）は、データ属性管理テーブル２２２０のデータ構造例を示す説明図である。
データ属性管理テーブル２２２０は、チケットＩＤ欄２２２２、実体ＩＤ欄２２２４、ハッシュ値欄２２２６を有している。チケットＩＤ欄２２２２は、チケットＩＤを記憶している。実体ＩＤ欄２２２４は、実体ＩＤを記憶している。ハッシュ値欄２２２６は、ハッシュ値を記憶している。つまり、図１０の例に示したデータ属性管理テーブル１０００のトークン欄１０１０をチケットＩＤ欄２２２２としたものである。
データ記憶モジュール１５０は、処理モジュール１９２０と接続されている。データ記憶モジュール１５０は、「ハッシュ値」と「データ」を対応させて記憶する。

処理モジュール１９２０は、通信モジュール１１０、トークン記憶モジュール１９３０、チケット記憶モジュール１９４０、呼称記憶モジュール１９５０、データ属性記憶モジュール１９６０、データ記憶モジュール１５０と接続されている。
処理モジュール１９２０は、「ユーザーを示すトークン」と「チケットの所有者を示す情報」と「そのチケットの名称」と「呼称」と「その呼称で示される実体に関するデータに対する処理の指示」を受け付けた場合は、チケットが示す権限を、トークン記憶モジュール１９３０から抽出する。
そして、処理モジュール１９２０は、「通信モジュール１１０が受け付けたチケットの所有者を示す情報」と「そのチケットの名称」に対応するチケットを示す情報を、チケット記憶モジュール１９４０から抽出する。
次に、処理モジュール１９２０は、「抽出したチケットを示す情報」と「通信モジュール１１０が受け付けた呼称」に対応する実体を示す情報を、呼称記憶モジュール１９５０から抽出する。
そして、処理モジュール１９２０は、「抽出したチケットを示す情報」と「抽出した実体を示す情報」に対応するハッシュ値を、データ属性記憶モジュール１９６０から抽出する。
次に、処理モジュール１９２０は、「抽出したハッシュ値」に対応するデータを、データ記憶モジュール１５０から抽出する。
そして、処理モジュール１９２０は、抽出したデータに対して、抽出した権限の範囲内で、通信モジュール１１０によって受け付けられた指示にしたがった処理を行う。

図２３は、第２の実施の形態による処理例を示す説明図である。
通信モジュール１１０は、「トークン」と「チケット（チケットのオーナー名とチケット名によって構成されている）」と「呼称」と「その呼称で示される実体に関するデータに対する処理の指示」を受け取る。
そして、処理モジュール１９２０は、通信モジュール１１０が受け取った「トークン」と「チケット」（対象データ２３１０）から、トークン管理テーブル２０００を用いて、そのトークンとチケットに対応する権限（権限欄２０３０、ここでは「ＲＥＡＤ」）を抽出する。なお、対象データ２３１０は、オーナー名欄２０２２内のデータと、チケット名欄２０２４内のデータの組み合わせである。
次に、「チケット」（対象データ２３２０）から、チケット管理テーブル２１００を用いてチケットＩＤ（対象データ２３３０）を抽出する。なお、対象データ２３２０は、オーナー名欄２１１０内のデータと、チケット名欄２１２０内のデータの組み合わせである。
この後は、第１の実施の形態におけるトークンをチケットＩＤ（対象データ２３４０、対象データ２３５０）として、呼称管理テーブル２２００、データ属性管理テーブル２２２０、データ管理テーブル１１００を用いて、第１の実施の形態による処理と同等の処理を行って、データ管理テーブル１１００のデータ欄１１２０のデータにたどり着き、そのデータに対して「指示」にしたがった処理を行う。ただし、ここでは、権限ＲＥＡＤの範囲での処理を行うことになる。

図２４は、第２の実施の形態による処理例を示すフローチャートである。
ステップＳ２４０２では、ユーザー端末からトークンとチケットと呼称の組み合わせを受け取る。
ステップＳ２４０４では、トークン管理テーブル２０００を用いて、チケットの権限を抽出する。
ステップＳ２４０６では、チケット管理テーブル２１００を用いて、チケットのチケットＩＤを抽出する。
ステップＳ２４０８では、チケットＩＤを用いて、呼称管理テーブル２２００、データ属性管理テーブル２２２０、データ管理テーブル１１００内のデータに対して、権限の範囲での処理を行う。
ステップＳ２４１０では、処理成功をユーザー端末に送信する。

図２５は、第２の実施の形態による処理例（図２４の例に示すフローチャートによる具体的処理例）を示す説明図である。チケットを用いて自分のデータにアクセスする処理例である。第１の実施の形態による処理と同等の処理を、第２の実施の形態でも可能である。
チケット２５０８として、「オーナー名：ｄ８１ｅ５１５ｃｃ０、チケット名：ｄａｔａ」を有しており、チケット２５１８として、「オーナー名：ｄ７４３ａｆ８ｂ９７、チケット名：ｄａｔａ、権限：ＣＲＥＡＴＥ、ＲＥＡＤ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ」を有しており、チケット２５２０として、「オーナー名：ｄ７４３ａｆ８ｂ９７、チケット名：ｄａｔａ、権限：ＲＥＡＤ」を有している。なお、図２５の例では図示していないが、チケット２５０８では、自分のデータであるので「権限：ＣＲＥＡＴＥ、ＲＥＡＤ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ」を有している。
ユーザー端末２５０２のユーザーは、チケット２５０８を有している。ユーザー端末２５１２のユーザーは、チケット２５１８を有している。なお、ユーザー端末２５０２のユーザーは、ユーザー端末２５１２のユーザーからチケット２５２０を受けている。ただし、図２５の例では、このチケット２５２０は用いない。

情報処理装置１９００は、ユーザー端末２５０２から呼称２５０４、ユーザーＩＤ２５０６、チケット２５０８を受け取る。なお、図２５の例では「指示」は省略しているが、例えば、Ｒｅａｄ（読み取り）等であってもよい。
実体データ２５３２として、「オーナー名：ｄ８１ｅ５１５ｃｃ０、チケット名：ｄａｔａ、呼称：ＮＣ１００３５８−０００００１」を有しており、実体データ２５３４として、「オーナー名：ｄ７４３ａｆ８ｂ９７、チケット名：ｄａｔａ、呼称：Ａ４Ｃ５７０Ｇ４−０００００１」を有しており、実体データ２５３６として、「オーナー名：ｄ７４３ａｆ８ｂ９７、チケット名：ｄａｔａ、呼称：ＮＣ１００３５８−０００００１」を有している。
データ２５４２として、「オーナー名：ｄ８１ｅ５１５ｃｃ０、チケット名：ｄａｔａ、実体：６３０ｃｆｆ５４ｂｃ」を有しており、データ２５４４として、「オーナー名：ｄ７４３ａｆ８ｂ９７、チケット名：ｄａｔａ、実体：６３０ｃｆｆ５４ｂｃ」を有しており、データ２５４６として、「オーナー名：３４７６６ａｆ９ｆ８、チケット名：ｄａｔａ、実体：６３０ｃｆｆ５４ｂｃ」を有している。

前述したように、チケット２５０８からトークン管理テーブル２０００を用いて権限を抽出し、チケット２５０８からチケット管理テーブル２１００を用いてチケットＩＤを抽出し、そのチケットＩＤから呼称管理テーブル２２００、データ属性管理テーブル２２２０を用いて実体（実体データ２５３２）にたどり着き、データ管理テーブル１１００のデータ欄１１２０内のデータ（データ２５４２）にたどり着く。そして、権限の範囲（この例では、「権限：ＣＲＥＡＴＥ、ＲＥＡＤ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ」の範囲、いわゆる全権限の範囲）で「指示」にしたがった処理を行う。

図２６は、第２の実施の形態による処理例（図２４の例に示すフローチャートによる具体的処理例）を示す説明図である。チケットを用いてデータを共有する処理例である。
各データ操作に対して、呼称から実体を解決（抽出）する処理と、実体からデータを解決する処理で使用するチケットを切り替えられるようにしている。
具体的には、ＨＴＴＰヘッダーにそれぞれの処理で使用するチケットを指定する拡張ヘッダーを設け、行使するチケットを切り替える。
図２６の例では、他のユーザーのデータにアクセスするものである。
呼称から実体を解決するステップにて自身の使用している呼称を用いて実体を特定し、実体からデータを解決するステップにて、他のユーザーより認可されたチケット２５２０を使用することで、他ユーザーが使用している名前を知らなくても、他のユーザーのデータを取得することが可能になる。
ＨＴＴＰヘッダーとして、例えば、アクセス記述２６１０を記述する。具体的な例として、以下の記載が行われている。
（１）ＧＥＴ／ＮＣ１００３５８−０００００１ ＨＴＴＰ １．１
（２）Ａｕｔｈｏｒｉｚａｔｉｏｎ ： Ｂｅａｒｅｒ ｄ８１ｅ５１５ｃｃ０
（３）Ｘ−ＣａｌｌＡｓ： ｄａｔａ； ｏｗｎｅｒ＝ｄ８１ｅ５１５ｃｃ０
（４）Ｘ−ＰｒｏｃｅｓｓＡｓ： ｄａｔａ； ｏｗｎｅｒ＝ｄ７４３ａｆ８ｂ９７
このアクセス記述２６１０の３行目は、「呼称の解決」を意味し、アクセス記述２６１０の４行目は、「データの解決」を意味する。

情報処理装置１９００は、呼称２５０４、ユーザーＩＤ２５０６、チケット２５０８、チケット２５２０、指示を受け取る。なお、図２６の例では「指示」は省略しているが、例えば、Ｒｅａｄ（読み取り）等であってもよい。チケット２５０８を用いて実体２５００の実体データ２５３２へたどり着き（呼称から実体を解決）、チケット２５２０を用いて他ユーザーのデータ２５４４にたどり着く（実体からデータを解決する処理）。そして、データ２５４４に対する処理を行う。ただし、チケット２５２０の権限の範囲内（ＲＥＡＤ）での処理を行う。

さらに、情報処理装置１９００は、トークンの危殆化への対応を行うようにしてもよい。
オーナー名としてトークン（アクセストークン）を直接用いると、トークンが他者に漏れた場合にトークンを破棄できなくなってしまうため、トークン記憶モジュール１９３０を、トークン管理テーブル２７００、ユーザーチケット管理テーブル２８００のような構成にしてもよい。これによって、システムの認証操作でトークンとユーザーＩＤの紐付け（関連付け）を設定できるようにする。したがって、トークンを破棄可能にすることができる。
また、これにより、トークン以外はヒューマンリーダブルな文字列でＨＴＴＰリクエストを作成することが可能になり、開発が容易になる。

トークン記憶モジュール１９３０は、トークン管理テーブル２７００、ユーザーチケット管理テーブル２８００を記憶している。
図２７は、トークン管理テーブル２７００のデータ構造例を示す説明図である。トークン管理テーブル２７００は、トークン欄２７１０、ユーザーＩＤ欄２７２０を有している。つまり、トークン管理テーブル２７００は、トークンとユーザーを示す情報を対応させて記憶している。トークン欄２７１０は、トークンを記憶している。ユーザーＩＤ欄２７２０は、本実施の形態において、ユーザーを一意に識別するための情報（ユーザーＩＤ）を記憶している。

図２８は、ユーザーチケット管理テーブル２８００のデータ構造例を示す説明図である。ユーザーチケット管理テーブル２８００は、ユーザーＩＤ欄２８１０、チケット欄２８２０、権限欄２８３０を有している。チケット欄２８２０は、オーナー名欄２８２２、チケット名欄２８２４を有している。つまり、ユーザーチケット管理テーブル２８００は、ユーザーを示す情報とチケットの所有者を示す情報（オーナー）とそのチケットの名称とそのチケットが示す権限を対応させて記憶している。ユーザーＩＤ欄２８１０は、ユーザーＩＤを記憶している。チケット欄２８２０は、チケットを記憶している。オーナー名欄２８２２は、オーナー名を記憶している。チケット名欄２８２４は、チケット名を記憶している。権限欄２８３０は、権限を記憶している。

チケット記憶モジュール１９４０は、トークンとユーザーを示す情報を対応させて記憶するトークン管理テーブル２７００、ユーザーチケット管理テーブル２８００を記憶している。
処理モジュール１９２０は、通信モジュール１１０が「トークン」と「チケットの所有者を示す情報」と「そのチケットの名称」と「呼称」と「その呼称で示される実体に関するデータに対する処理の指示」を受け付けた場合は、そのトークンに対応するユーザーを示す情報を、トークン管理テーブル２７００から抽出する。
そして、処理モジュール１９２０は、抽出したユーザーを示す情報と通信モジュール１１０が受け付けたチケットの所有者を示す情報とそのチケットの名称に対応する権限を、ユーザーチケット管理テーブル２８００から抽出する。
次に、処理モジュール１９２０は、通信モジュール１１０が受け付けたチケットの所有者を示す情報とそのチケットの名称に対応するチケットを示す情報を、チケット記憶モジュール１９４０から抽出する。
そして、処理モジュール１９２０は、抽出したチケットを示す情報と通信モジュール１１０が受け付けた呼称に対応する実体を示す情報を、呼称記憶モジュール１９５０から抽出する。
次に、処理モジュール１９２０は、抽出したチケットを示す情報と抽出した実体を示す情報に対応するハッシュ値を、データ属性記憶モジュール１９６０から抽出する。
そして、処理モジュール１９２０は、抽出したハッシュ値に対応するデータを、データ記憶モジュール１５０から抽出する。
次に、処理モジュール１９２０は、抽出したデータに対して、抽出した権限の範囲内で、通信モジュール１１０が受け付けた指示にしたがった処理を行う。

図２９は、第２の実施の形態による処理例（トークン管理テーブル２７００、ユーザーチケット管理テーブル２８００を用いた処理例）を示す説明図である。
図２９の例では、他のユーザーのデータにアクセスするものである。
ＨＴＴＰヘッダーとして、例えば、アクセス記述２９１０を記述する。具体的な例として、以下の記載が行われている。
（１）ＧＥＴ／ＮＣ１００３５８−０００００１ ＨＴＴＰ １．１
（２）Ａｕｔｈｏｒｉｚａｔｉｏｎ ： Ｂｅａｒｅｒ ｄ８１ｅ５１５ｃｃ０
（３）Ｘ−ＣａｌｌＡｓ： ｄａｔａ； ｏｗｎｅｒ＝ｍａｉｎｔｅｎａｎｃｅ＿ｓｙｓｔｅｍ
（４）Ｘ−ＰｒｏｃｅｓｓＡｓ： ｄａｔａ； ｏｗｎｅｒ＝ｃｏｕｎｔｅｒ＿ｓｙｓｔｅｍ
このアクセス記述２９１０の３行目は、「呼称の解決」を意味し、アクセス記述２９１０の４行目は、「データの解決」を意味する。

情報処理装置１９００は、呼称２５０４、対象データ２９１２、チケット２９０２、チケット２９０４、指示を受け取る。なお、図２９の例では「指示」は省略しているが、例えば、Ｒｅａｄ（読み取り）等であってもよい。
チケット２９０２として、「オーナー名：ｍａｉｎｔｅｎａｎｃｅ＿ｓｙｓｔｅｍ、チケット名：ｄａｔａ」を有しており、チケット２９０４として、「オーナー名：ｃｏｕｎｔｅｒ＿ｓｙｓｔｅｍ、チケット名：ｄａｔａ、権限：ＲＥＡＤ」を有している。
対象データ２９１２は、「ｄ８１ｅ５１５ｃｃ０」である。対象データ２９１２からトークン管理テーブル２７００を用いて、対象データ２９２０（特に、ユーザーＩＤ欄２７２０のユーザーＩＤ）を抽出する。対象データ２９２０は、トークン欄２７１０内のデータと、ユーザーＩＤ欄２７２０内のデータの組み合わせである。
そして、対象データ２９２０内のユーザーＩＤとチケット２９０２とチケット２９０４から、ユーザーチケット管理テーブル２８００を用いて、対象データ２９３０、対象データ２９３５を抽出する。対象データ２９３０は、ユーザーＩＤ欄２８１０内のデータと、オーナー名欄２８２２内のデータと、チケット名欄２８２４内のデータの組み合わせである。対象データ２９３５は、ユーザーＩＤ欄２８１０内のデータと、オーナー名欄２８２２内のデータと、チケット名欄２８２４内のデータの組み合わせである。
次に、対象データ２９３０内のオーナー名とチケット名から、チケット管理テーブル２１００を用いて、対象データ２９４０を抽出する。そして、対象データ２９３５内のオーナー名とチケット名から、チケット管理テーブル２１００を用いて、対象データ２９４５を抽出する。対象データ２９４０は、オーナー名欄２１１０内のデータと、チケット名欄２１２０内のデータの組み合わせである。対象データ２９４５は、オーナー名欄２１１０内のデータと、チケット名欄２１２０内のデータの組み合わせである。
この後は、前述したように、呼称管理テーブル２２００、データ属性管理テーブル２２２０、データ管理テーブル１１００を用いて、実体に関するデータにたどり着き、そのデータ群に対して、抽出した権限（チケット２９０２ではＣＲＥＡＴＥ、ＲＥＡＤ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、チケット２９０４ではＲＥＡＤ）の範囲内で、通信モジュール１１０が受け付けた指示にしたがった処理を行う。

図３０を参照して、本実施の形態の情報処理装置のハードウェア構成例について説明する。図３０に示す構成は、例えばパーソナルコンピュータ（ＰＣ）等によって構成されるものであり、スキャナ等のデータ読み取り部３０１７と、プリンタ等のデータ出力部３０１８を備えたハードウェア構成例を示している。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３００１は、前述の実施の形態において説明した各種のモジュール、すなわち、通信モジュール１１０、処理モジュール１２０、処理モジュール１９２０等の各モジュールの実行シーケンスを記述したコンピュータ・プログラムにしたがった処理を実行する制御部である。

ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３００２は、ＣＰＵ３００１が使用するプログラムや演算パラメータ等を格納する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３００３は、ＣＰＵ３００１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を格納する。これらはＣＰＵバス等から構成されるホストバス３００４により相互に接続されている。

ホストバス３００４は、ブリッジ３００５を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス３００６に接続されている。

キーボード３００８、マウス等のポインティングデバイス３００９は、操作者により操作されるデバイスである。ディスプレイ３０１０は、液晶表示装置又はＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）等があり、各種情報をテキストやイメージ情報として表示する。また、ポインティングデバイス３００９とディスプレイ３０１０の両方の機能を備えているタッチスクリーン等であってもよい。

ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）３０１１は、ハードディスク（フラッシュメモリ等であってもよい）を内蔵し、ハードディスクを駆動し、ＣＰＵ３００１によって実行するプログラムや情報を記録又は再生させる。ハードディスクは、呼称記憶モジュール１３０、データ属性記憶モジュール１４０、データ記憶モジュール１５０、トークン記憶モジュール１９３０、チケット記憶モジュール１９４０、呼称記憶モジュール１９５０、データ属性記憶モジュール１９６０等としての機能を実現させる。さらに、その他の各種データ、各種コンピュータ・プログラム等が格納される。

ドライブ３０１２は、装着されている磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体３０１３に記録されているデータ又はプログラムを読み出して、そのデータ又はプログラムを、インタフェース３００７、外部バス３００６、ブリッジ３００５、及びホストバス３００４を介して接続されているＲＡＭ３００３に供給する。なお、リムーバブル記録媒体３０１３も、データ記録領域として利用可能である。

接続ポート３０１４は、外部接続機器３０１５を接続するポートであり、ＵＳＢ、ＩＥＥＥ１３９４等の接続部を持つ。接続ポート３０１４は、インタフェース３００７、及び外部バス３００６、ブリッジ３００５、ホストバス３００４等を介してＣＰＵ３００１等に接続されている。通信部３０１６は、通信回線に接続され、外部とのデータ通信処理を実行する。データ読み取り部３０１７は、例えばスキャナであり、ドキュメントの読み取り処理を実行する。データ出力部３０１８は、例えばプリンタであり、ドキュメントデータの出力処理を実行する。

なお、図３０に示す情報処理装置のハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図３０に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続している形態でもよく、さらに図３０に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機などに組み込まれていてもよい。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読み出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読み出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読み出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラムの全体又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分又は全部であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。

１００…情報処理装置
１１０…通信モジュール
１２０…処理モジュール
１３０…呼称記憶モジュール
１４０…データ属性記憶モジュール
１５０…データ記憶モジュール
２００…ユーザー端末
２１０…画像処理装置
２９０…通信回線
１９００…情報処理装置
１９２０…処理モジュール
１９３０…トークン記憶モジュール
１９４０…チケット記憶モジュール
１９５０…呼称記憶モジュール
１９６０…データ属性記憶モジュール

Claims (2)

1. トークンと実体の呼称と該実体を示す情報を対応させて記憶する第１の記憶手段と、
   トークンと実体を示す情報とハッシュ値を対応させて記憶する第２の記憶手段と、
   ハッシュ値とデータを対応させて記憶する第３の記憶手段と、
   ユーザーを示すトークンと呼称と該呼称で示される実体に関するデータに対する処理の指示を受け付けた場合は、該トークンと該実体を示す情報に対応する実体を示す情報を、前記第１の記憶手段から抽出する第１の抽出手段と、
   前記受け付けたトークンと前記第１の抽出手段によって抽出された実体を示す情報に対応するハッシュ値を、前記第２の記憶手段から抽出する第２の抽出手段と、
   前記第２の抽出手段によって抽出されたハッシュ値に対応するデータを、前記第３の記憶手段から抽出する第３の抽出手段と、
   前記第３の抽出手段によって抽出されたデータに対して、前記指示にしたがった処理を行う処理手段
   を有する情報処理装置。
2. コンピュータを、
   トークンと実体の呼称と該実体を示す情報を対応させて記憶する第１の記憶手段と、
   トークンと実体を示す情報とハッシュ値を対応させて記憶する第２の記憶手段と、
   ハッシュ値とデータを対応させて記憶する第３の記憶手段と、
   ユーザーを示すトークンと呼称と該呼称で示される実体に関するデータに対する処理の指示を受け付けた場合は、該トークンと該実体を示す情報に対応する実体を示す情報を、前記第１の記憶手段から抽出する第１の抽出手段と、
   前記受け付けたトークンと前記第１の抽出手段によって抽出された実体を示す情報に対応するハッシュ値を、前記第２の記憶手段から抽出する第２の抽出手段と、
   前記第２の抽出手段によって抽出されたハッシュ値に対応するデータを、前記第３の記憶手段から抽出する第３の抽出手段と、
   前記第３の抽出手段によって抽出されたデータに対して、前記指示にしたがった処理を行う処理手段
   として機能させるための情報処理プログラム。

Images