JP6720613B2 - 情報処理システム及び情報処理プログラム - Google Patents

Description

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

特許文献１には、オブジェクトの情報とオブジェクトの処理に関する権限とを同一のデータ構造で管理し、クライアントからの要求を柔軟に制御することを課題とし、情報処理装置は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理し、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定と、権限オブジェクトを用いて実行する処理の要求とをクライアント装置から受け付け、権限情報を認可したオブジェクトである所有者オブジェクトと、権限オブジェクトの親であるオブジェクトとの情報の比較結果に基づいて、クライアント装置からの要求を受理するか否かを判断することが開示されている。

特許文献２には、クライアントから受け付けた要求に係る権限オブジェクトに応じて決定される関数により要求を処理することを課題とし、情報管理装置は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理するオブジェクト情報管理部と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付けるリクエスト受付部と、権限オブジェクトに関連付けられた関数オブジェクトを取得する関数オブジェクト取得部と、関数オブジェクトにより要求を処理するリクエスト処理部を有することが開示されている。

特許文献３には、クライアントから受け付けた要求に係る権限オブジェクトに応じたコンテンツを提供することを課題とし、情報管理装置は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの少なくとも一部にコンテンツを構成する要素の要素名と要素値を関連付けて管理し、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付け、権限オブジェクトに基づいて対象のオブジェクトを設定し、対象のオブジェクトに要求が指定する要素名が関連付けられていない場合には、対象のオブジェクトの親のオブジェクトを新たな対象のオブジェクトに設定する処理を、予め定められた条件が満足されるまで繰り返し実行し、設定された対象のオブジェクトに要求が指定する要素名が関連付けられている場合には、対象のオブジェクトに関連付けられた要素値を要求に対し応答することが開示されている。

特許第５４４７７２２号公報 特開２０１５−１６２０５７号公報 特開２０１５−１６２０５８号公報

前述の特許文献に記載の技術では、オブジェクトの情報を管理する記憶手段は、１箇所の記憶手段にあることを前提としている。
しかし、その１箇所の記憶手段に負荷が集中し、その記憶手段が稼働していない場合は使用することができない。
そこで、本発明は、権限オブジェクトを比較して、要求に対応する処理を行う場合にあって、オブジェクトの情報を、少なくとも１つの情報処理装置内の記憶手段と複数の情報処理装置からアクセス可能な記憶手段の複数箇所で管理するようにした情報処理システム及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、複数の情報処理装置を有し、少なくとも１つの情報処理装置は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、本情報処理装置内の記憶手段で管理する第１の管理手段と、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、本情報処理装置又は他の情報処理装置からアクセス可能な記憶手段で管理する第２の管理手段と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記第１の管理手段又は前記第２の管理手段により管理される対象オブジェクトに対する要求を、本情報処理装置又は他の情報処理装置から受け付ける受付手段と、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記対象オブジェクトの情報に対して、前記要求に対応する処理を行う処理手段を有し、前記処理手段は、前記要求が、オブジェクトの情報の生成、更新、又は廃棄の処理である場合は、前記第１の管理手段を用いて該処理を行い、前記要求が、前記第１の管理手段が管理する記憶手段内の生成、更新、又は廃棄された情報を、前記第２の管理手段が管理する記憶手段に反映させる処理である場合は、前記第２の管理手段を用いて該処理を行い、本情報処理装置内のオブジェクトの変更の処理については権限の判定は不要とし、他の情報処理装置からのオブジェクトの変更の処理については、前記要求に付随して送付されるトークンによって請求される権限を逸脱する処理については失敗とする、ことを特徴とする情報処理システムである。

請求項２の発明は、前記要求がオブジェクトの情報の変更を禁止する要求である場合は、該オブジェクトの子孫のオブジェクトの情報に対しても、変更を禁止する禁止手段をさらに有することを特徴とする請求項１に記載の情報処理システムである。

請求項３の発明は、前記第２の管理手段が管理する記憶手段にオブジェクトの情報の書き込みを始める前に、前記第１の管理手段が管理する記憶手段内の対応するオブジェクトの情報の変更を禁止し、該書き込みが完了したときに、該禁止を解除することを特徴とする請求項２に記載の情報処理システムである。

請求項４の発明は、前記第２の管理手段が管理する記憶手段内のオブジェクトの情報に対して要求を行った利用者を記憶し、該オブジェクトの情報の変更が行われた場合は、該利用者に通知を行う通知手段をさらに有することを特徴とする請求項１から３のいずれか一項に記載の情報処理システムである。

請求項５の発明は、コンピュータを、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、前記コンピュータ内の記憶手段で管理する第１の管理手段と、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、前記コンピュータ又は他の情報処理装置からアクセス可能な記憶手段で管理する第２の管理手段と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記第１の管理手段又は前記第２の管理手段により管理される対象オブジェクトに対する要求を、前記コンピュータ又は他の情報処理装置から受け付ける受付手段と、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記対象オブジェクトの情報に対して、前記要求に対応する処理を行う処理手段として機能させ、前記処理手段は、前記要求が、オブジェクトの情報の生成、更新、又は廃棄の処理である場合は、前記第１の管理手段を用いて該処理を行い、前記要求が、前記第１の管理手段が管理する記憶手段内の生成、更新、又は廃棄された情報を、前記第２の管理手段が管理する記憶手段に反映させる処理である場合は、前記第２の管理手段を用いて該処理を行い、前記コンピュータ内のオブジェクトの変更の処理については権限の判定は不要とし、他の情報処理装置からのオブジェクトの変更の処理については、前記要求に付随して送付されるトークンによって請求される権限を逸脱する処理については失敗とする、情報処理プログラムである。

請求項１の情報処理システムによれば、権限オブジェクトを比較して、要求に対応する処理を行う場合にあって、オブジェクトの情報を、少なくとも１つの情報処理装置内の記憶手段と複数の情報処理装置からアクセス可能な記憶手段の複数箇所で管理することができる。

請求項２の情報処理システムによれば、オブジェクトの子孫のオブジェクトの情報に対しても、変更を禁止することができる。

請求項３の情報処理システムによれば、第２の管理手段が管理する記憶手段にオブジェクトの情報の書き込みがある場合は、その間、第１の管理手段が管理する記憶手段内の対応するオブジェクトの情報の変更を禁止することができる。

請求項４の情報処理システムによれば、第２の管理手段が管理する記憶手段内のオブジェクトの情報に対して要求を行った利用者に対して、そのオブジェクトの情報の変更が行われたことを通知することができる。

請求項５の情報処理プログラムによれば、権限オブジェクトを比較して、要求に対応する処理を行う場合にあって、オブジェクトの情報を、コンピュータ内の記憶手段と複数の情報処理装置からアクセス可能な記憶手段の複数箇所で管理することができる。

本実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を利用したシステム構成例を示す説明図である。 プロトタイプベースのオブジェクトの具体例を示す図である。 オブジェクト管理テーブルの一例を示す図である。 バリュー管理テーブルの一例を示す図である。 配信用アクセストークンの生成処理のシーケンス図である。 配信用オブジェクトのコンテンツ表示処理のシーケンス図である。 配信用オブジェクトの無効化処理のシーケンス図である。 配信用オブジェクトの無効化処理のシーケンス図である。 配信用オブジェクトの凍結処理のシーケンス図である。 配信用オブジェクトに対する任意関数の追加処理のシーケンス図である。 認証が追加された配信用オブジェクトのコンテンツ表示処理のシーケンス図である。 オブジェクトの構成例を示す図である。 オブジェクトの構成例を示す図である。 オブジェクトの構成例を示す図である。 ＫＶＳテーブルのデータ構造例を示す説明図である。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 オブジェクトストアＫＶＳテーブルのデータ構造例を示す説明図である。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態による処理例を示すフローチャートである。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

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

本実施の形態である情報処理装置１００は、図１の例に示すように、データ格納モジュール１１０、リクエスト受付モジュール１２０、権限オブジェクト検証モジュール１３０、オブジェクト管理モジュール１４０、リクエスト処理モジュール１５０、処理結果提供モジュール１６０を有している。情報処理装置１００は、マスターデータ自体ではなく、その子孫オブジェクトを参照させ、子孫オブジェクトが有していないデータ項目についてはマスターデータのデータ項目を提供し、子孫オブジェクトが有しているデータ項目については子孫オブジェクトのデータ項目を提供する事により、一のマスターデータについての提供内容を個別に制御できるものである。
データ格納モジュール１１０は、オブジェクト管理テーブル１１１、バリュー管理テーブル１１２を有しており、権限オブジェクト検証モジュール１３０、オブジェクト管理モジュール１４０と接続されている。
リクエスト受付モジュール１２０は、権限オブジェクト検証モジュール１３０と接続されている。

権限オブジェクト検証モジュール１３０は、データ格納モジュール１１０、リクエスト受付モジュール１２０、リクエスト処理モジュール１５０と接続されている。
オブジェクト管理モジュール１４０は、配信用オブジェクト生成モジュール１４１を有しており、データ格納モジュール１１０、リクエスト処理モジュール１５０と接続されている。
リクエスト処理モジュール１５０は、権限オブジェクト検証モジュール１３０、オブジェクト管理モジュール１４０、処理結果提供モジュール１６０と接続されている。
処理結果提供モジュール１６０は、リクエスト処理モジュール１５０と接続されている。

データ格納モジュール１１０は、プロトタイプベースのオブジェクトの情報を管理する。ここで、プロトタイプベースのオブジェクトには、権限情報が関連付けられたアクセストークンと呼ばれる権限オブジェクトを含む。プロトタイプベースのオブジェクトは変更可能（ミュータブル）なオブジェクトであり、典型的にはランダムに生成されたＩＤで識別される。

図３には、情報処理装置１００により管理されるプロトタイプベースのオブジェクト群（オブジェクト木）の具体例を示した。図３に示される例においては、各ノードはオブジェクトを、ノードをつなぐエッジはプロトタイプ継承による親子関係を表している。

図３に示されるように、「ｒｏｏｔ」オブジェクトＤ１の子オブジェクトとして、「ｃｒｕｄＳｃｏｐｅ」オブジェクトＤ１１、「ｒｅａｄＯｎｌｙＳｃｏｐｅ」オブジェクトＤ１２、「ｃｏｎｔｅｎｔＯｗｎｅｒ」オブジェクトＤ１３が設けられている。さらに、「ｃｏｎｔｅｎｔＯｗｎｅｒ」オブジェクトＤ１３の子オブジェクトとして、「ｃｏｎｔｅｎｔＯｗｎｅｒＴｏｋｅｎ」オブジェクトＤ１３１、「ｍａｓｔｅｒＣｏｎｔｅｎｔ」オブジェクトＤ１３２、「ｍａｓｔｅｒＣｏｎｔｅｎｔＴｏｋｅｎ」オブジェクトＤ１３３が設けられている。そしてさらに、「ｍａｓｔｅｒＣｏｎｔｅｎｔ」オブジェクトＤ１３２の子オブジェクトとして、「ｃｈｉｌｄＣｏｎｔｅｎｔ」オブジェクトＤ１３２１、「ｃｈｉｌｄＣｏｎｔｅｎｔＴｏｋｅｎ」オブジェクトＤ１３２２が設けられている。

図３に示した例において、「ｃｒｕｄＳｃｏｐｅ」オブジェクトＤ１１はＣＲＵＤ（Ｃｒｅａｔｅ，Ｒｅａｄ，Ｕｐｄａｔｅ，Ｄｅｌｅｔｅ）の範囲（すなわち、作成、読み込み、更新、削除）を許可するスコープ、「ｒｅａｄＯｎｌｙＳｃｏｐｅ」オブジェクトＤ１２は読みのみを許可するスコープに相当する。

さらに、「ｃｏｎｔｅｎｔＯｗｎｅｒ」オブジェクトＤ１３は、「ｍａｓｔｅｒＣｏｎｔｅｎｔ」オブジェクトＤ１３２の所有者に相当する。「ｃｏｎｔｅｎｔＯｗｎｅｒＴｏｋｅｎ」オブジェクトＤ１３１は、「ｃｏｎｔｅｎｔＯｗｎｅｒ」オブジェクトＤ１３がＣＲＵＤするためのトークンに相当し、所有者を「ｃｏｎｔｅｎｔＯｗｎｅｒ」、クライアント（権限委譲先）を「ｃｏｎｔｅｎｔＯｗｎｅｒ」、スコープを「ｃｒｕｄＳｃｏｐｅ」とするトークンである。

さらに、「ｍａｓｔｅｒＣｏｎｔｅｎｔ」オブジェクトＤ１３２がマスターデータに相当し、「ｍａｓｔｅｒＣｏｎｔｅｎｔＴｏｋｅｎ」オブジェクトＤ１３３は、マスターデータの子を作成するためのトークンに相当する。なお、「ｍａｓｔｅｒＣｏｎｔｅｎｔＴｏｋｅｎ」オブジェクトＤ１３３は、所有者を「ｍａｓｔｅｒＣｏｎｔｅｎｔ」、クライアント（権限委譲先）を「ｍａｓｔｅｒＣｏｎｔｅｎｔ」、スコープを「ｃｒｕｄＳｃｏｐｅ」とするトークンである。

さらに、「ｃｈｉｌｄＣｏｎｔｅｎｔ」オブジェクトＤ１３２１が配信用の子オブジェクトに相当し、「ｃｈｉｌｄＣｏｎｔｅｎｔＴｏｋｅｎ」オブジェクトＤ１３２２が「ｃｈｉｌｄＣｏｎｔｅｎｔ」オブジェクトＤ１３２１を更新するためのトークンに相当する。なお、「ｃｈｉｌｄＣｏｎｔｅｎｔ」オブジェクトＤ１３２１は、所有者を「ｍａｓｔｅｒＣｏｎｔｅｎｔ」、クライアント（権限委譲先）を「ｃｈｉｌｄＣｏｎｔｅｎｔ」、スコープを「ｃｒｕｄＳｃｏｐｅ」とするトークンである。

本実施の形態では、データ格納モジュール１１０には、オブジェクト管理テーブル１１１と、バリュー管理テーブル１１２が含まれ、プロトタイプベースのオブジェクトの情報を、オブジェクト管理テーブル１１１と、バリュー管理テーブル１１２に格納して管理している。

図４には、オブジェクト管理テーブル１１１の一例を、そして図５にはバリュー管理テーブル１１２の一例をそれぞれ示した。

図４に示されるように、オブジェクト管理テーブル１１１には、プロトタイプベースのオブジェクトの識別情報であるオブジェクトＩＤ、オブジェクトの親（プロトタイプ）オブジェクトの識別情報であるプロトタイプＩＤ、オブジェクトが有効化されているか否か（Ｔが有効、Ｆが無効）を示す有効化フラグ、オブジェクトの属性情報が関連付けて記憶される。また、オブジェクトの属性情報には、オブジェクトの型を示すｔｙｐｅ、オブジェクトのデータ内容を格納したデータオブジェクトの識別情報を表すｅｔａｇ、オブジェクトの名称を格納したｎａｍｅ、オブジェクトの生成日時を表すｔｉｍｅを含む。なお、プロトタイプベースのオブジェクトのデータ構成は、図４に示された例に限定されるものではなく、上述した要素以外の要素を含み構成されていても構わない。また、オブジェクトが有効であるか否かはフラグではなく無効化日時を表す属性情報として取り扱ってもよい。その場合は、プロトタイプ継承のため、あるノードを無効化することでそのノードをルートとする部分木の全てのノードを一括して無効化することができる。

また、図５に示されるように、バリュー管理テーブル１１２には、ｅｔａｇにバリューが関連付けられている。例えば、バリューは任意のオクテット配列であり、ｅｔａｇの値はそのオクテット配列のハッシュ値とするようにしてもよい。

例えば、コンテンツに相当するオブジェクトであれば、ｅｔａｇのバリューとして例えば「ＨＥＡＤＥＲ」や「ＢＯＤＹ」のそれぞれの項目について情報が格納される。また例えば、第１オブジェクトを親、第２オブジェクトを第１オブジェクトの子とするコンテンツに関し、第１オブジェクトのｅｔａｇのバリューとして「ＨＥＡＤＥＲ」や「ＢＯＤＹ」に情報が格納され、第２オブジェクトのｅｔａｇのバリューとして「ＨＥＡＤＥＲ」や「ＢＯＤＹ」に情報が格納されていない場合には、第２オブジェクトのコンテンツを参照した場合には、第１オブジェクトの「ＨＥＡＤＥＲ」や「ＢＯＤＹ」に格納された情報が第２オブジェクトのコンテンツとして用いられる。また、第２オブジェクトのコンテンツに「ＨＥＡＤＥＲ」や「ＢＯＤＹ」に格納された情報がある場合には、その格納された情報が第２オブジェクトのコンテンツとして用いられる。

また例えば、アクセストークンであればｅｔａｇのバリューとして、｛“ｏｗｎｅｒ”：ｏｗｎｅｒ（オーナー）のオブジェクトＩＤ、“ｃｌｉｅｎｔ”：ｃｌｉｅｎｔ（クライアント）のオブジェクトＩＤ、“スコープ”：認可された処理の範囲｝の形式の情報を含む。端末装置から受け付ける処理要求にはアクセストークンが添付されるが、ここで、アクセストークンを検証することにより、オーナー、クライアント、スコープの情報が特定される。なお、オーナーが処理のリクエスタ、クライアントが処理の代理リクエスタとして扱われる。

リクエスト受付モジュール１２０は、図２の例を用いて後述する端末装置２５０からリクエストを受け付ける。例えば、リクエスト受付モジュール１２０は、端末装置２５０からデータ格納モジュール１１０で管理されるオブジェクトの処理に関するリクエストを受け付けることとしてよい。なお、リクエスト受付モジュール１２０は、端末装置２５０からリクエストとともにリクエストに係るアクセストークンの情報を受け付けることとしてよい。この際、リクエスト受付モジュール１２０は、例えば端末装置２５０からＨＴＴＰリクエストの形式でリクエストを受け付けることとしてよい。

権限オブジェクト検証モジュール１３０は、リクエスト受付モジュール１２０で受け付けたリクエストに係る権限オブジェクト（アクセストークン）の情報を取得し、取得した権限オブジェクトを検証する。例えば、権限オブジェクト検証モジュール１３０は、アクセストークンの情報を、ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎフィールドから得てもよいし、アクセストークンの情報を含むクッキーが存在すれば、クッキーから得てもよい。

権限オブジェクト検証モジュール１３０は、上記取得したアクセストークン（権限オブジェクト）の情報が正当なものであるか否かを検証する。以下、権限オブジェクト検証モジュール１３０による検証処理の具体例について説明する。

まず、権限オブジェクト検証モジュール１３０は、アクセストークンのＩＤが、データ格納モジュール１１０で管理するオブジェクト管理テーブル１１１に含まれているか否か（第１の条件の適否）を判断し、含まれていない場合には検証失敗と判断する。

次に、権限オブジェクト検証モジュール１３０は、第１の条件が満たされている場合に、アクセストークンのデータ形式（タイプ）が所定の型（すなわち、ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ）であるか否か（第２の条件の適否）を判断し、所定の型でない場合には検証失敗と判断する。すなわち、アクセストークンのｅｔａｇについてバリュー管理テーブル１１２に記憶されるバリューが所定の型（ｏｗｎｅｒ、ｃｌｉｅｎｔ、ｓｃｏｐｅを指定したデータ形式）でない場合には、検証失敗と判断する。

次に、権限オブジェクト検証モジュール１３０は、第２の条件が満たされている場合に、アクセストークンのバリューの値（ｏｗｎｅｒ、ｃｌｉｅｎｔ、ｓｃｏｐｅの値）を取得し、ｏｗｎｅｒ、ｃｌｉｅｎｔ、ｓｃｏｐｅのそれぞれの値がデータ格納モジュール１１０で管理されるデータであるか否か（第３の条件の適否）を判断し、いずれかの値がデータ格納モジュール１１０で管理されるデータでない場合には検証失敗と判断する。

次に、権限オブジェクト検証モジュール１３０は、第３の条件が満足されている場合に、データ格納モジュール１１０からアクセストークンのプロトタイプの情報を取得し、アクセストークンのプロトタイプが、アクセストークンのオーナーと一致しているか、オーナーのプロトタイプチェーン（オーナーの親、さらにその親へとオーナーの祖先を順に接続した経路）に含まれるか否か（第４の条件の適否）を判断し、上記のいずれにも合致しない場合には検証失敗と判断する。また、上記のプロトタイプチェーンは、オブジェクトの親、さらにその親を再帰的にたどる列ともいえる。なお、以上の第１から第４の条件を満足した場合には、権限オブジェクト検証モジュール１３０は、アクセストークンの検証を成功と判断することとしてよい。

権限オブジェクト検証モジュール１３０は、上記の検証の結果と、アクセストークンにより認可されているスコープ（処理の範囲）の情報と、受け付けたリクエストをリクエスト処理モジュール１５０に通知する。

リクエスト処理モジュール１５０は、リクエスト受付モジュール１２０で受け付けたリクエストについて取得したアクセストークン（権限オブジェクト）についての権限オブジェクト検証モジュール１３０から通知された検証結果と、該受け付けたアクセストークンについて認可されたスコープ（処理の範囲）に基づいて、リクエスト受付モジュール１２０で受け付けたリクエストの処理を制御する。例えば、リクエスト処理モジュール１５０は、リクエスト受付モジュール１２０で受け付けたリクエストに係るアクセストークンについての検証結果が検証失敗である場合には、リクエストに係る処理を不受理としてエラーを処理結果提供モジュール１６０に出力することとしてよい。また、リクエスト処理モジュール１５０は、リクエスト受付モジュール１２０で受け付けたリクエストに係るアクセストークンについての検証結果が検証成功である場合には、リクエスト受付モジュール１２０で受け付けたリクエストを、該リクエストに関して受け付けたアクセストークンについて認可されたスコープに基づいて処理し、その処理結果を処理結果提供モジュール１６０に出力する。

例えば、リクエスト処理モジュール１５０は、受け付けたリクエストに基づいて、オブジェクト管理モジュール１４０にオブジェクトの生成、読み出し、更新、削除を依頼し、オブジェクト管理モジュール１４０から処理結果を受け取る。

具体的には、リクエスト処理モジュール１５０は、受け付けたリクエストが、マスターデータについての配信用オブジェクトの生成である場合には、オブジェクト管理モジュール１４０に、マスターデータ（オブジェクト）の子オブジェクト（又は子孫オブジェクト）の生成を要求し、生成された子オブジェクト（又は子孫オブジェクト）のオブジェクトＩＤを処理結果として処理結果提供モジュール１６０を介して端末装置２５０に送信させることとしてよい。

オブジェクト管理モジュール１４０は、データ格納モジュール１１０により管理されるオブジェクトの情報を管理する。例えば、オブジェクト管理モジュール１４０は、リクエスト処理モジュール１５０から受け付ける要求に基づいて、オブジェクト管理テーブル１１１、バリュー管理テーブル１１２に対して情報の追加、読み出し、更新、削除等の処理を実行する。

また、オブジェクト管理モジュール１４０は、配信用オブジェクト生成モジュール１４１を含み、リクエスト処理モジュール１５０から受け付ける配信用オブジェクトの生成要求に基づいて、マスターデータの子（又は子孫）である配信用オブジェクトを生成する。

また、オブジェクト管理モジュール１４０は、リクエスト処理モジュール１５０から受け付ける配信用オブジェクトの読み出し要求に基づいて、配信用オブジェクトの情報を読み出す。ここで、オブジェクト管理モジュール１４０は、配信用オブジェクトの有していないデータ項目については、配信用オブジェクトの親（又は先祖）のオブジェクトのデータ項目の情報を参照し、配信用オブジェクトの情報として返す。

また、オブジェクト管理モジュール１４０は、リクエスト処理モジュール１５０から受け付ける配信用オブジェクトの更新要求に基づいて、配信用オブジェクトの内容を更新する。また、オブジェクト管理モジュール１４０は、リクエスト処理モジュール１５０から受け付ける配信用オブジェクトの削除要求に基づいて、配信用オブジェクトを削除する。

処理結果提供モジュール１６０は、リクエスト処理モジュール１５０による処理結果を、リクエストの要求元である端末装置２５０に対して提供する。例えば、処理結果提供モジュール１６０は、リクエスト受付モジュール１２０により受け付けた処理要求が、配信用オブジェクトの生成である場合には、生成された配信用オブジェクトのオブジェクトＩＤを端末装置２５０に提供することとしてよい。また例えば、処理結果提供モジュール１６０は、リクエスト受付モジュール１２０により受け付けた処理要求が、配信用オブジェクトの読み出しである場合には、読み出された配信用オブジェクトの情報（すなわちコンテンツデータ）を端末装置２５０に提供することとしてよい。また例えば、処理結果提供モジュール１６０は、リクエスト受付モジュール１２０により受け付けた処理要求が、配信用オブジェクトの更新、削除である場合には、配信用オブジェクトの更新、削除の成否情報を端末装置２５０に提供することとしてよい。

［２．システム構成の説明］
図２は、本実施の形態を利用したシステム構成例を示す説明図である。
情報処理装置１００Ａ、第１端末装置２５０Ａ、第２端末装置２５０Ｂ、第３端末装置２５０Ｃ、第４端末装置２５０Ｄ、認証装置２８０は、通信回線２９０を介してそれぞれ接続されている。第３端末装置２５０Ｃは、情報処理装置１００Ｃを有している。第４端末装置２５０Ｄは、情報処理装置１００Ｄを有している。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。また、情報処理装置１００による機能は、クラウドサービスとして実現してもよい。
情報処理装置１００を有していない第１端末装置２５０Ａ、第２端末装置２５０Ｂの例は、リモートでのみ情報処理装置１００Ａを用いる場合を示している。情報処理装置１００を有している第３端末装置２５０Ｃ、第４端末装置２５０Ｄの例は、リモートで情報処理装置１００Ａを用いる場合とローカルの情報処理装置１００Ｃ、情報処理装置１００Ｄを用いる場合を示している。［１］から［４］の説明では、主に、第１端末装置２５０Ａ、第２端末装置２５０Ｂによる情報処理装置１００Ａの利用を示しており、［５］以降の説明では、第３端末装置２５０Ｃ、第４端末装置２５０Ｄによるリモート（情報処理装置１００Ａ）とローカル（情報処理装置１００Ｃ、情報処理装置１００Ｄ）での利用を示している。

情報処理装置１００は、プロトタイプベースのオブジェクトを管理する。ここで、プロトタイプベースのオブジェクトとは、プロトタイプベースのオブジェクトの集合に唯一存在するルートオブジェクトを除けば、唯一つの親のオブジェクト（プロトタイプ）を持つオブジェクトのことである。なお、ルートオブジェクトは自身のプロトタイプを持たない。

また、オブジェクトＡがオブジェクトＢのプロトタイプであるとき、オブジェクトＢはオブジェクトＡのアーティファクトであるともいう。オブジェクト間のプロトタイプ関係により、プロトタイプベースのオブジェクト全体の集合は木構造で表現される。また、オブジェクトにより構成される木構造を破壊しないならば、プロトタイプを再接続することで木構造を変形することが可能である。

さらに、情報処理装置１００で管理するオブジェクトには、属性及び属性値を持たせることができる。ＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）アーキテクチャスタイルにおいては、オブジェクトをリソース、値を表現と呼ぶこともある。オブジェクトには、単にオブジェクト識別子とプロトタイプのみからなる純粋なアイデンティティのみを表すもの、任意のコンテント型の値を持つデータを表すもの、アクセス資格を証明するクレデンシャルであるアクセストークン、あるいはオブジェクトの所有者であるリソースオーナーやリソースオーナーの認可のもとにオブジェクトへのアクセスを行うアプリケーション（クライアント）のようなエンティティを表すものが含まれることとしてよい。そして、これらのオブジェクトが１つの木構造の中に含まれる。なお、上記のアクセストークンは、権限情報が関連付けられるオブジェクトともいえる。

情報処理装置１００は、アクセストークンを提示したリクエストを受け付け、アクセストークンが有効と検証された場合に、アクセストークンに基づき特定された権限の範囲で、上記受け付けたリクエストを処理する。例えば、アクセストークンにより特定される権限の範囲は、オブジェクトを作成（追加）、内容の参照、更新、削除等のいずれかを認可（又は不認可）したものである。また例えば、情報処理装置１００は、端末装置２５０から受け付けたリクエストにしたがって、管理するオブジェクトの追加、更新、情報の読み出し、削除等を実行する。

情報処理装置１００は、第１端末装置２５０Ａからのリクエストに基づいて生成した、配信用のマスターデータであるコンテンツを管理していることとする。そして、情報処理装置１００は、第１端末装置２５０Ａからのリクエストに基づいて、マスターデータであるコンテンツの子であるオブジェクトを生成する。第１端末装置２５０Ａは、マスターデータそのものではなく、マスターデータの子のオブジェクトの情報を第２端末装置２５０Ｂに配信することとする。このマスターデータの子のオブジェクトについては、個別に内容の追加、更新、削除等が可能であり、そうした内容の追加、更新、削除は親であるマスターデータの内容には影響を与えることがない。

［３．処理の一例についての説明］
次に、図６から図１２に示されたシーケンス図に基づいて、情報処理システムで実行される処理の一例について詳細に説明する。

［３．１．配信用オブジェクトの生成処理］
まず、図６に示したシーケンス図に基づいて、第１端末装置２５０Ａと情報処理装置１００とにより実行される配信用アクセストークンの生成処理の一例について説明する。まず、図６のフローにおいては、第１端末装置２５０Ａはマスターデータ（ｍａｓｔｅｒＣｏｔｅｎｔ）の親オブジェクト（ｃｏｎｔｅｎｔＯｗｎｅｒ）について子オブジェクトの生成、取得、更新、削除が可能なスコープが定められたアクセストークンＴ１（ｃｏｎｔｅｎｔＯｗｎｅｒＴｏｋｅｎ）を有することとする。

図６に示されるように、第１端末装置２５０Ａは、アクセストークンＴ１を用いて、マスターデータ（ｍａｓｔｅｒＣｏｔｅｎｔ）の子オブジェクトを作成するためのアクセストークンＴ２（ｍａｓｔｅｒＣｏｎｔｅｎｔＴｏｋｅｎ）の作成を情報処理装置１００に対して指示する（Ｓ３１０１）。

情報処理装置１００は、第１端末装置２５０ＡからアクセストークンＴ２の作成指示を受け付けると（Ｓ１１０１）、アクセストークンＴ１を検証し、検証が成功した場合に、アクセストークンＴ２を作成する（Ｓ１１０２）。そして、情報処理装置１００は、上記作成したアクセストークンＴ２のＩＤ（オブジェクトＩＤ）を第１端末装置２５０Ａに対して送信する（Ｓ１１０３）。

第１端末装置２５０Ａは、情報処理装置１００から送信されるアクセストークンＴ２のＩＤを受信する（Ｓ３１０２）。

次に、第１端末装置２５０Ａは、アクセストークンＴ２を用いて、マスターデータの配信用オブジェクトとして、マスターデータの子オブジェクトの作成を情報処理装置１００に対して指示する（Ｓ３１０３）。

情報処理装置１００は、第１端末装置２５０Ａから配信用オブジェクトの作成指示を受け付けると（Ｓ１１０４）、アクセストークンＴ２を検証し、検証が成功した場合に、配信用オブジェクト、すなわちマスターデータの子オブジェクトを作成する（Ｓ１１０５）。そして、情報処理装置１００は、上記作成した配信用オブジェクトのＩＤ（オブジェクトＩＤ）を第１端末装置２５０Ａに対して送信する（Ｓ１１０６）。

第１端末装置２５０Ａは、情報処理装置１００から送信される配信用オブジェクトのＩＤを受信する（Ｓ３１０４）。そして、第１端末装置２５０Ａは、配信用オブジェクトのＩＤに基づいて生成される、配信用オブジェクトの内容を参照するためのＵＲＩを第２端末装置２５０Ｂに提供する（Ｓ３１０５）。

また、第１端末装置２５０Ａは、第２端末装置２５０Ｂに対して、上記のＵＲＩに加えて、配信用オブジェクトの内容を更新するためのアクセストークンＴ２の情報も提供することとしても構わない。

以上が、配信用オブジェクトの生成に関する処理の一例である。

［３．２．配信用オブジェクトのコンテンツ表示処理］
次に、図７に示したシーケンス図に基づいて、第２端末装置２５０Ｂと情報処理装置１００により実行される、第２端末装置２５０Ｂが配信用オブジェクトのコンテンツを表示する処理の一例について説明する。以下のシーケンス例においては、第２端末装置２５０Ｂは、配信用オブジェクトの参照が可能なスコープが定められたアクセストークンｔを有することとする。

第２端末装置２５０Ｂは、アクセストークンｔを用いて、配信用オブジェクトの内容を参照するためのＵＲＩにアクセスし、配信用オブジェクトの情報の取得を、情報処理装置１００に対して指示する（Ｓ３２０１）。

情報処理装置１００は、第２端末装置２５０Ｂから配信用オブジェクトの情報取得指示を受け付けると（Ｓ１２０１）、アクセストークンｔを検証し、検証が成功した場合に、配信用オブジェクトの情報を取得する（Ｓ１２０２）。例えば、配信用オブジェクトにｔｙｐｅ属性、ｅｔａｇ属性が設定されていない場合には、情報処理装置１００は配信用オブジェクトのｔｙｐｅ属性、ｅｔａｇ属性に、配信用オブジェクトの親であるマスターデータのｔｙｐｅ属性、ｅｔａｇ属性を設定した上で、配信用オブジェクトの情報を取得する。

そして、情報処理装置１００は、上記取得した配信用オブジェクトの情報（コンテンツ）を第２端末装置２５０Ｂに対して送信する（Ｓ１２０３）。

第２端末装置２５０Ｂは、情報処理装置１００から配信用オブジェクトの情報を受信し（Ｓ３２０２）、受信した配信用オブジェクトの情報に基づいて、配信用オブジェクトの情報を表示する（Ｓ３２０３）。

以上が、配信用オブジェクトの表示処理の一例である。

［３．３．配信用オブジェクトの無効化処理（１）］
次に、図８に示されるシーケンス図に基づき、第１端末装置２５０Ａと情報処理装置１００により実行される配信用オブジェクトの無効化処理の一例について説明する。以下のシーケンス例は、マスターデータの所有者（コンテンツオーナー）が配信用オブジェクトに無効化属性を付与することで配信用オブジェクトを無効化する例に相当する。

図８に示されるように、第１端末装置２５０Ａは、アクセストークンＴ２を用いて、配信用オブジェクトの属性を更新するためのアクセストークンＴ３（ｃｈｉｌｄＣｏｎｔｅｎｔＴｏｋｅｎ）の作成指示を情報処理装置１００に対して送信する（Ｓ３３０１）。

情報処理装置１００は、アクセストークンＴ３の作成指示を受け付けると（Ｓ１３０１）、アクセストークンＴ２を検証し、検証が成功した場合に、アクセストークンＴ３を作成する（Ｓ１３０２）。そして、情報処理装置１００は、上記作成したアクセストークンＴ３のＩＤを第１端末装置２５０Ａに対して送信する（Ｓ１３０３）。

第１端末装置２５０Ａは、情報処理装置１００からアクセストークンＴ３のＩＤを受信すると（Ｓ３３０２）、アクセストークンＴ３を用いて、配信用オブジェクトに無効化属性を付与する指示を、情報処理装置１００に対して送信する（Ｓ３３０３）。

情報処理装置１００は、配信用オブジェクトに無効化属性を付与する指示を受け付けると（Ｓ１３０４）、アクセストークンＴ３を検証し、検証が成功した場合に、配信用オブジェクトに無効化属性を付与する（Ｓ１３０５）。例えば、情報処理装置１００は、配信用オブジェクトの有効化フラグの情報をＦに更新することにより上記の無効化処理を行うこととしてよい。

そして、情報処理装置１００は、上記の無効化処理の結果を第１端末装置２５０Ａに対して送信する（Ｓ１３０６）。

第１端末装置２５０Ａは、情報処理装置１００から、上記の無効化処理の結果を受信する（Ｓ３３０４）。以上が、配信用オブジェクトの無効化処理の第１の例である。

なお、上記において、配信用オブジェクトを再有効化する場合には、配信用オブジェクトの無効化属性を削除（すなわち、有効化フラグの情報をＴに更新）すればよい。

［３．４．配信用オブジェクトの無効化処理（２）］
次に、図９に示されるシーケンス図に基づき、第１端末装置２５０Ａと情報処理装置１００により実行される配信用オブジェクトの無効化処理の第２の例について説明する。以下のシーケンス例においては、配信用オブジェクトの無効化を、配信用オブジェクトを削除することにより実行する。

第１端末装置２５０Ａは、アクセストークンＴ２を用いて、配信用オブジェクトの削除指示を情報処理装置１００に対して送信する（Ｓ３４０１）。

情報処理装置１００は、配信用オブジェクトの削除指示を受け付けると（Ｓ１４０１）、アクセストークンＴ２を検証し、検証が成功した場合に、配信用オブジェクトを削除する（Ｓ１４０２）。そして、情報処理装置１００は、上記削除処理の結果を第１端末装置２５０Ａに対して送信する（Ｓ１４０３）。

第１端末装置２５０Ａは、情報処理装置１００から、上記の削除処理の結果を受信する（Ｓ３４０２）。以上が、配信用オブジェクトの無効化処理の第２の例である。

［３．５．配信用オブジェクトの凍結処理］
次に、図１０に示されるシーケンス図に基づき、第１端末装置２５０Ａと情報処理装置１００により実行される配信用オブジェクトの凍結処理について説明する。なお、凍結処理とは、予め定められた時点（例えば業務委託の終了時点）で配信用オブジェクトのマスターデータへの継続的な参照を終了させ、その時点で配信用オブジェクトの情報を固定化させる処理のことをいう。

第１端末装置２５０Ａは、アクセストークンＴ３を用いて、配信用オブジェクトの凍結指示を情報処理装置１００に対して送信する（Ｓ３５０１）。

情報処理装置１００は、配信用オブジェクトの凍結指示を受け付けると（Ｓ１５０１）、アクセストークンＴ３を検証し、検証が成功した場合に、配信用オブジェクトを凍結化する（Ｓ１５０２）。例えば、情報処理装置１００は、配信用オブジェクトのｅｔａｇ属性に、凍結指示を受け付けた時点でのマスターデータのｅｔａｇ属性を設定する。これにより、マスターデータがその後更新されたとしても、配信用オブジェクトのコンテンツは凍結指示を受け付けた時点でのマスターデータの内容に固定化される。なお、配信用オブジェクトのｔｙｐｅ属性については更新しなくともよい。

そして、情報処理装置１００は、上記凍結処理の結果を第１端末装置２５０Ａに対して送信する（Ｓ１５０３）。

第１端末装置２５０Ａは、情報処理装置１００から、上記の凍結処理の結果を受信する（Ｓ３５０２）。以上が、配信用オブジェクトの凍結処理の一例である。

なお、上記において、配信用オブジェクトの凍結を解除する場合には、配信用オブジェクトのｅｔａｇ属性の値を削除すればよい。これにより、配信用オブジェクトの親オブジェクトであるマスターデータへの参照が回復する。

［３．６．配信用オブジェクトに対する任意関数（例えば認証）の追加処理］
次に、図１１に示されるシーケンス図に基づき、第１端末装置２５０Ａと情報処理装置１００により実行される配信用オブジェクトに対する任意関数の追加処理について説明する。なお、以下のシーケンスの例においては、配信用オブジェクトへのアクセス時に認証装置における認証処理を行うための関数を追加することとする。

第１端末装置２５０Ａは、アクセストークンＴ３を用いて、配信用オブジェクトへの関数の追加指示を情報処理装置１０００に対して送信する（Ｓ３６０１）。

情報処理装置１００は、配信用オブジェクトへの関数の追加指示を受け付けると（Ｓ１６０１）、アクセストークンＴ３を検証し、検証が成功した場合に、配信用オブジェクトに指定された関数を追加する（Ｓ１６０２）。例えば、上記の指定された関数は、認証装置において認証されているか否かを真又は偽で返すものとする。

そして、情報処理装置１００は、上記追加処理の結果を第１端末装置２５０Ａに対して送信する（Ｓ１６０３）。

第１端末装置２５０Ａは、情報処理装置１００から、上記の追加処理の結果を受信する（Ｓ３６０２）。以上が、配信用オブジェクトへの関数の追加処理の一例である。

なお、配信用オブジェクトに追加される関数は、上記の認証処理に限られるものではない。例えば、配信用オブジェクトに対して、配信用オブジェクトが参照された場合に、コンテンツのオーナーに対して、参照があった旨を通知する関数を追加するようにしてもよい。

［３．７．認証が追加された配信用オブジェクトのコンテンツ表示処理］
次に、図１２に示されるシーケンス図に基づき、認証が追加された配信用オブジェクトを第２端末装置２５０Ｂが表示する際に実行される処理の一例について説明する。以下に説明するシーケンスの例は、認証装置２８０による認証が済んでいない場合に相当する。

第２端末装置２５０Ｂは、アクセストークンｔを用いて、配信用オブジェクトの内容を参照するためのＵＲＩにアクセスし、配信用オブジェクトの情報の取得を、情報処理装置１００に対して指示する（Ｓ３７０１）。

情報処理装置１００は、第２端末装置２５０Ｂから配信用オブジェクトの情報取得指示を受け付けると（Ｓ１７０１）、アクセストークンｔを検証し、検証が成功した場合に、追加された認証の関数を実行する（Ｓ１７０２）。そして、情報処理装置１００は、認証先である認証装置２８０をリダイレクト先として第２端末装置２５０Ｂに指示する（Ｓ１７０３）。

第２端末装置２５０Ｂは、情報処理装置１００からリダイレクト先を受信すると（Ｓ３７０２）、リダイレクト先である認証装置２８０にアクセスする（Ｓ３７０３）。

認証装置２８０は、第２端末装置２５０Ｂからのアクセスを受け付けると（Ｓ５７０１）、ログイン画面を第２端末装置２５０Ｂに送信する（Ｓ５７０２）。

第２端末装置２５０Ｂは、認証装置２８０からログイン画面を受信すると（Ｓ３７０４）、受信したログイン画面を表示して、ユーザから認証情報の入力を受け付ける。第２端末装置２５０Ｂは、認証情報の入力を受け付けると、受け付けた認証情報を認証装置２８０に送信する（Ｓ３７０５）。

認証装置２８０は、第２端末装置２５０Ｂから認証情報を受信すると（Ｓ５７０３）、受信した認証情報に基づく認証処理を実行する（Ｓ５７０４）。そして、認証装置２８０は、認証処理の結果（認証の成功／失敗）を第２端末装置２５０Ｂに送信する（Ｓ５７０５）。

第２端末装置２５０Ｂは、認証装置２８０から認証処理の結果を受信し（Ｓ３７０６）、受信した認証処理の結果を情報処理装置１００に送信する（Ｓ３７０７）。

情報処理装置１００は、第２端末装置２５０Ｂから認証処理の結果を受信し（Ｓ１７０４）、受信した認証処理の結果が成功である場合には、配信用オブジェクトの情報（コンテンツ）を取得する（Ｓ１７０５）。

そして、情報処理装置１００は、上記取得した配信用オブジェクトの情報（コンテンツ）を第２端末装置２５０Ｂに対して送信する（Ｓ１７０６）。

第２端末装置２５０Ｂは、情報処理装置１００から配信用オブジェクトの情報を受信し（Ｓ３７０８）、受信した配信用オブジェクトの情報に基づいて、配信用オブジェクトの情報を表示する。

以上が、認証処理が追加された配信用オブジェクトの表示処理の一例である。

なお、第２端末装置２５０Ｂが既に認証装置２８０における認証が済んでいる場合には、第２端末装置２５０Ｂは、Ｓ３７０３〜Ｓ３７０６を省略し、Ｓ３７０２の後にＳ３７０７を実行するようにしてよい。

［４．オブジェクトの他の構成例］
本発明は以上説明した実施の形態に限定されるものではない。例えば、配信用オブジェクトは以下のように構成してもよい。

［４．１．構成例１］
図１３には、配信先ごとに配信用オブジェクトを作成した場合のオブジェクトの構成例を示した。図１３に示すオブジェクトの木構造は、図３に示すオブジェクトの木構造と、第２ユーザへの配信オブジェクトである「ｃｈｉｌｄＣｏｎｔｅｎｔ＿２」オブジェクトＤ１３２３と、「ｃｈｉｌｄＣｏｎｔｅｎｔ＿２」オブジェクトを更新するための「ｃｈｉｌｄＣｏｎｔｅｎｔＴｏｋｅｎ＿２」オブジェクトＤ１３２４が追加されている点で相違し、その他の点で共通している。このように、配信先ごとに配信用オブジェクトを作成することにより、配信先ごとにカスタマイズされた内容での情報提供、制御の実行が可能となる。

［４．２．構成例２］
図１４には、配信先が属するテナント（組織）ごとにマスターデータの子オブジェクトを作成し、配信先をテナントの子オブジェクトとして構成した場合のオブジェクトの構成例を示した。「ｔｅｎａｎｔＡ」Ｄ１３２１及び「ｔｅｎａｎｔＢ」Ｄ１３２２はそれぞれ、「ｍａｓｔｅｒＣｏｎｔｅｎｔ」Ｄ１３２の子オブジェクトである。そして、「ｔｅｎａｎｔＡ」に属する配信先Ａ１とＡ２に対して、それぞれ配信用オブジェクトである「ｃｈｉｌｄＣｏｎｔｅｎｔＡ１」Ｄ１３２１１と「ｃｈｉｌｄＣｏｎｔｅｎｔＡ２」Ｄ１３２１２を作成する。さらに、「ｔｅｎａｎｔＢ」に属する配信先Ｂ１とＢ２に対して、それぞれ配信用オブジェクトである「ｃｈｉｌｄＣｏｎｔｅｎｔＢ１」Ｄ１３２２１と「ｃｈｉｌｄＣｏｎｔｅｎｔＢ２」Ｄ１３２２２を作成する。

なお、配信先Ａ１とＡ２とにおいて共通する内容（ただし配信先Ｂ１とＢ２とは相違する内容）については、「ｔｅｎａｎｔＡ」Ｄ１３２１に記述すればよい。そして、配信先Ａ１とＡ２とにおいて相違する内容については、それぞれ「ｃｈｉｌｄＣｏｎｔｅｎｔＡ１」Ｄ１３２１１と「ｃｈｉｌｄＣｏｎｔｅｎｔＡ２」Ｄ１３２１２に記述すればよい。配信先Ｂ１とＢ２についても同様である。

［４．３．構成例３］
図１５には、配信先が属するテナントがさらに階層構造になっている場合に対応するオブジェクトの構成例を示した。図１５に示されるように、「ｔｅｎａｎｔＡ」Ｄ１３２１の子オブジェクトとして、「ｔｅｎａｎｔＸ」Ｄ１３２１３と、「ｔｅｎａｎｔＡＴｏｋｅｎ」Ｄ１３２１４とが作成される。ここで、「ｔｅｎａｎｔＡＴｏｋｅｎ」Ｄ１３２１４は、オーナーを「ｔｅｎａｎｔＡ」、クライアントを「ｔｅｎａｎｔＸ」、スコープをＣＲＵＤとするアクセストークンとする。これにより、テナントＡは、「ｔｅｎａｎｔＡ」の下にオブジェクトの子孫を作成することが可能となる。

以上は、オブジェクトの構成の例示であり、コンテンツを配信する対象の組織に応じてオブジェクト構成を対応させることが容易であり、こうした場合のコンテンツの内容、制御等も容易である。

なお、以上説明した実施の形態は具体例として示したものであり、本明細書にて開示される発明をこれら具体例の構成やデータ格納例そのものに限定するものではない。当業者はこれら開示された実施の形態に種々の変形、例えば、データ構造、処理の実行順を変更したりしてもよい。本明細書にて開示される発明の技術的範囲は、そのようになされた変形をも含むものと理解すべきである。

［５．分散リソース管理例］
図２の例を用いて前述したように、情報処理装置１００を有している第３端末装置２５０Ｃ、第４端末装置２５０Ｄが、リモートで情報処理装置１００Ａを用いる場合とローカルの情報処理装置１００Ｃ、情報処理装置１００Ｄを用いる場合の例を示す。特に、記憶手段に関しては、リモート側を情報処理装置１００Ａとし、ローカル側をデータ格納モジュール１１０として説明する。
オブジェクト管理モジュール１４０は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、情報処理装置１００で管理する。
そして、オブジェクト管理モジュール１４０は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、複数の端末装置２５０からアクセス可能な情報処理装置１００Ａで管理する。
リクエスト受付モジュール１２０は、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、データ格納モジュール１１０又は情報処理装置１００Ａにより管理される対象オブジェクトに対する要求を受け付ける。
リクエスト処理モジュール１５０は、権限情報を認可したオブジェクトである所有者オブジェクトと、権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、対象オブジェクトの情報に対して、要求に対応する処理を行う。
そして、リクエスト処理モジュール１５０は、要求が、オブジェクトの情報の生成、更新、又は廃棄の処理である場合は、データ格納モジュール１１０を用いてその処理を行い、要求が、データ格納モジュール１１０内の生成、更新、又は廃棄された情報を、情報処理装置１００Ａに反映させる処理である場合は、情報処理装置１００Ａ内のデータ格納モジュール１１０に対してその処理を行う。

また、リクエスト処理モジュール１５０は、要求がオブジェクトの情報の変更を禁止する要求である場合は、そのオブジェクトの子孫のオブジェクトの情報に対しても、変更を禁止するようにしてもよい。
また、リクエスト処理モジュール１５０は、情報処理装置１００Ａにオブジェクトの情報の書き込みを始める前に、データ格納モジュール１１０内の対応するオブジェクトの情報の変更を禁止し、その書き込みが完了したときに、その禁止を解除するようにしてもよい。
また、処理結果提供モジュール１６０は、情報処理装置１００Ａ内のオブジェクトの情報に対して要求を行った利用者を記憶し、そのオブジェクトの情報の変更が行われた場合は、その利用者に通知を行うようにしてもよい。

第１端末装置２５０Ａが情報処理装置１００Ａをリモートで利用する場合は、プロトタイプベースのオブジェクト空間がホストできる実行環境ということを前提としていた。したがって、メモリ空間の制約やプロセスを永続的に稼働できない（プロセスが終了するとヒープが失われる）という制約は問題とならなかった。
しかし、大規模なデータ集約の基盤を実際に構築する場合、次に挙げる三点が問題となる。基本的には、「リモートのＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ）とローカルなＫＶＳを同期する」ということになるが、ファイルの変更履歴を記録・追跡するための分散型バージョン管理システムであるＧｉｔの場合のように、同期する対象が明確（ひとつのリポジトリに含まれる全オブジェクト）ではない。
（１）インターフェイスはサービスへのリクエストレスポンスであり、サービスが稼働していなければ利用できない。また、サービスへの負荷が集中する。リソース管理機能は、処理に必要な範囲のオブジェクトとデータのみで完結し、全オブジェクト及びデータのハンドリングとトークン検証を単一のリモートサービスで実行することは必須ではない。
例えば、多くのクラウド基盤では基本的なＫＶＳ機能はサービスとして提供されており、これらサービスの可用性は利用者の責務ではない。ＫＶＳ機能によるアクセス（つまりｐｕｔ、ｇｅｔ等のＣＲＵＤ）をプロトタイプ継承によるトポロジカルな特権制御と矛盾なく両立できれば、サービス維持・運用の責務を負うこと無く、実質的に従来技術の効用を享受できる。また、スケーラビリティも自動的に増大できる。
（２）オブジェクト及びデータの保持部とＣＲＵＤのインターフェイスをリポジトリという。リポジトリがリモートにあることによるレイテンシーがユースケースによっては無視できない。例えば、５００００台のデバイス情報をオブジェクトとして表現するとき、それらのオブジェクトに新たな属性情報（例えば、ある評価関数によるスコア評価値）を付与又は更新する場合、１オブジェクトあたり２０回のオブジェクト取得・加工・変更等の処理を行う場合、オブジェクトのｐｕｔ／ｇｅｔの回数に換算すると１００００００回のアクセスになる。レイテンシーが１ｍｓｅｃのオーダーでも全体では１０００秒の処理時間となり、バッチ的な処理となってしまう。
（３）スキャン操作等の非ルックアップ処理が行えない。例えば、従来技術でのオブジェクト識別子はケースによってはクレデンシャル情報であるため、一般的にルックアップしか許さないことは論理的に必須である一方、自己の所有オブジェクト（これは利用者自身のものであるため、利用者にとっては知り得ない情報ではない）に対してもこれらの制限が強制されるのは利便性・パフォーマンスの観点で引き合わない。識別子の紛失によるオブジェクトの放棄やオブジェクトのコレクションをオブジェクトとしてネストした場合の参照のオーバーヘッド等はその一例である。

そこで、本実施の形態は、プロトタイプ継承によるトポロジカルな特権制御と矛盾しない形でＫＶＳとしてのリポジトリを分散構成し、状態の同期を効率的に行える機構を導入する。具体的には、オブジェクト取得はリモートから透過的に、副作用のある生成、更新、削除はローカルに、副作用を与えた一連の結果を一括してローカルからリモートに反映する（プッシュ）。また、リモートからローカルに反映する（プル）。
なお、データ集約のユースケースでは、大きなデータセットを持っているサービス（データソース）がローカルにデータ加工した後でマスターのリモートにプッシュすることが効率的である。また、データを利用するクライアントの立場では、プルによって他のオーナーが更新したデータを取り込む必要がある。

情報処理装置１００Ａは、リモートのオブジェクトを保持する。具体的には、ＫＶＳとしてオブジェクトを保持する（識別子はランダムで推定できず偶然一致することもない）。ここでは保持された全てのキーの列挙を行うようなＡＰＩは提供されない。また、情報処理装置１００Ａは、永続的な記憶を持ち、後述の実行手段の起動・終了を超えた寿命を持つ。
そして、情報処理装置１００Ａは、リモートのデータを保持する。具体的には、ＫＶＳとしてデータを保持する。なお、識別子はデータ自身のハッシュ値とすればよい。ここでは保持された全てのキーの列挙を行うようなＡＰＩは提供されない。また、保持手段は永続的な記憶を持ち、後述の実行手段の起動・終了を超えた寿命を持つ。
権限オブジェクト検証モジュール１３０は、リクエスト（要求）に含まれるトークンを検証し、成功すればスコープを取り出す。ここでトークンの検証が成功するためには、トークンは情報処理装置１００Ａに含まれる無効化されていないオブジェクトの識別子であり、トークンのクレームするオーナーのプロトタイプチェーンにトークンの指すオブジェクトのプロトタイプが含まれることが必要である。
データ格納モジュール１１０は、ローカルのオブジェクトを保持する。具体的には、ＫＶＳとしてオブジェクトを保持する。なお、識別子はランダムで推定できず偶然一致することもない。ここでは保持された全てのキーの列挙を行うような、キーのルックアップにとどまらない任意のＡＰＩが利用できても構わない。
またデータ格納モジュール１１０は、ローカルのデータを保持する。具体的には、ＫＶＳとしてデータを保持する。なお、識別子はデータ自身のハッシュ値とすればよい。ここでは保持された全てのキーの列挙を行うような、キーのルックアップにとどまらない任意のＡＰＩが利用できても構わない。
オブジェクト管理モジュール１４０は、変更オブジェクトのリストを保持する。データ格納モジュール１１０の保持する生成、更新、削除したオブジェクト（かつ、情報処理装置１００Ａへ未だ反映していないもの）のリストを保持する。
リクエスト処理モジュール１５０は、リクエストに対応する処理を行う。プロトタイプ継承されたオブジェクトがロードされプログラムが実行される。具体的には、メモリを備えた（ＪａｖａＳｃｒｉｐｔ（登録商標）等の）実行環境である。リクエスト処理モジュール１５０は、情報処理装置１００Ａ、データ格納モジュール１１０のいずれに接続しても構わない。

オブジェクト管理モジュール１４０は、識別子で指定されるオブジェクトが、リクエスト処理モジュール１５０に既にロードされていれば、そのオブジェクトを返す。無ければ、データ格納モジュール１１０からオブジェクトを取得し、リクエスト処理モジュール１５０にロードする。データ格納モジュール１１０にない場合は情報処理装置１００Ａから取得し、リクエスト処理モジュール１５０にロードする一方、データ格納モジュール１１０にも記憶する。以上の処理を指定されたオブジェクトのプロトタイプにも再帰的に行うことで、オブジェクト取得時には、リクエスト処理モジュール１５０に指定オブジェクトのプロトタイプチェーンがロードされ、また、リクエスト処理モジュール１５０の再起動時にも、同一オブジェクトに対しては、プロトタイプチェーンはデータ格納モジュール１１０からロード可能となる。
また、オブジェクト管理モジュール１４０は、オブジェクトの更新を行う。ロードされたオブジェクト（ロード後の変更が許される）をデータ格納モジュール１１０に書き戻し（又は、新規にリクエスト処理モジュール１５０で生起したオブジェクトの場合は追加し）、変更オブジェクトのリストに書き戻した又は追加したオブジェクトを記録する。
オブジェクト管理モジュール１４０は、変更オブジェクトのプッシュを行う。変更オブジェクトのリストが記録したオブジェクトの集合の状態を、データ格納モジュール１１０から情報処理装置１００Ａに一括して反映する。
なお、データ格納モジュール１１０のローカルのオブジェクトの変更については権限の判定は不要であるが、一方、情報処理装置１００Ａのリモートのオブジェクトの変更については、付随して送付されるトークンによってクレームされる権限を逸脱する処理は失敗する。
情報処理装置１００Ａのリモートのオブジェクトの変更は、ＫＶＳの直接操作ではなく、リクエストを受信し、添付のトークンのスコープを実行する。情報処理装置１００Ａ内のリクエスト処理モジュール１５０を介して行ってもよい。この場合も当然、トークンによってクレームされる権限を逸脱する処理は失敗する。

以下にＡＰＩとしての例を示す。
（１）永続化処理（ＫＶＳへのアクセスを行う）
・ｐｕｔ（ｋ， ｖ）， ｇｅｔ（ｋ）， ｄｅｌ（ｋ）
・ｂｉｎｄ（ｂｕｆ）， ｒｅｓｏｌｖｅ（ｅｔａｇ）， ｕｎｂｉｎｄ（ｅｔａｇ）
（２）実行処理（永続化処理はリモートとローカルの２種類がある）
・ｒｓ．ｇｅｎ（ｐｒｏｔｏ）
ｐｒｏｔｏの子オブジェクトｏｂｊを生成し、そのオブジェクトｏｂｊを返す。
なお、永続化はせず、メモリにのみ存在する。
・ｒｓ．ｇｅｔ（ｉｄ）
実行環境に既にオブジェクトがロードされていれば、そのオブジェクトを返す。
ロードされておらず、ローカルからｇｅｔできればその値を実行環境にロードする。ローカルには無くリモートからｇｅｔできれば、その値をローカルにキャッシュし、実行環境にロードする。
また、ロードされたオブジェクトのプロトタイプを再帰的にｒｓ．ｇｅｔする。
・ｒｓ．ｕｐ（ｏｂｊ）
実行環境中のオブジェクトｏｂｊをローカルの永続化層にｐｕｔする。
変更オブジェクトリストにｏｂｊ．ｉｄを追加する。
・ｒｓ．ｄｏｗｎ（ｉｄ）
実行環境中にｉｄのオブジェクトがロードされていれば、永続化層から再取得する。プロトタイプが別のオブジェクトに付け替えられていれば、そのプロトタイプをｒｓ．ｇｅｔする。
・ｒｓ．ｂｉｎｄ（ｂｕｆ）， ｒｓ．ｒｅｓｏｌｖｅ（ｅｔａｇ）
永続化手段のｂｉｎｄ，ｒｅｓｏｌｖｅのラッパー（メモリへのロード・セーブを挟む）を行う。ここでラッパーとは、あるクラスや関数、データ型などが提供する機能やデータを含み、別の形で提供することである。
・ｒｓ．ｐｕｓｈ（）
ローカルの変更オブジェクトリストにあるオブジェクトの変更をリモートに反映する。反映が成功したオブジェクトのＩＤはリストから除去する。
・ｒｓ．ｐｕｌｌ（）
リモートの変更オブジェクトのリスト（さらに、ローカル向けのリスト）にあるオブジェクトの変更をローカルに反映する。反映が成功したオブジェクトのＩＤはリストから除去する。

トランザクション処理について説明する。
・（リモートの）オブジェクトツリーの一部にロック（変更禁止）をかける場合、トランザクション中のノードのルートにロックフラグを付与することで、その子孫達を一斉にロックする。
・トランザクションが完了した時に、ルートノードのロックフラグを解除することで、その子孫達のロックも一斉に解除される。
・具体的には、オブジェクト管理モジュール１４０が、変更オブジェクトをプッシュする場合に、リモートへの書き込みを始める前に、その変更オブジェクトに対応するローカルのオーナーオブジェクトにロックを付与し、リモートへの書き込みが完了したときに、ロックを解除する。また、オブジェクト管理モジュール１４０は、オブジェクトを取得する場合、情報処理装置１００Ａから取得したオブジェクトがロックされている場合は、ロード及びデータ格納モジュール１１０へのキャッシュは行わない。

変更の通知について説明する。
・オブジェクトをＣＲＵＤした自前のＫＶＳを持つピア（つまり、ローカルのオブジェクトとデータを保持するデータ格納モジュール１１０を有する端末装置２５０に対応）をオブジェクトごとに記憶しておき、オブジェクトに変更があった場合にそのピアに通知する。又は、ピアからの要求に応じて変更されたオブジェクトリストを渡せるようにする。
・具体的には、情報処理装置１００Ａ内のリモートのオブジェクトに対してＣＲＵＤ操作を行ったピアを、オブジェクトの購読者属性（ここには購読者リストが記録される）に追加し、情報処理装置１００Ａのリモートのオブジェクトに対してＣＲＵＤ操作（ただし、Ｒ（取得）操作は除く）が行われるときに、対象オブジェクトの購読者リストのピアに対して対象オブジェクトが更新されたことを通知する、又は、対象オブジェクトをピアのＭｕｔａｔｅ属性（ここには変更されたオブジェクトリストが記録される）に追加する。なお、ここで購読者とは、ＣＲＵＤ操作の要求を行った利用者である。

ファイルシステムへのマッピングについて説明する。
・ファイルシステムの階層構造をオブジェクトのプロトタイプ継承関係にマップし、ルートの識別子を｀．ｏｗｎｅｒ｀に保持する。これによって、例えば、Ｇｉｔ管理されたリポジトリと同様に直感的なオブジェクト管理、配布が可能となる。
・｀．ｒｓ｀ディレクトリにメタ情報やＫＶＳをまとめる。例えば、Ｇｉｔにおける｀．ｇｉｔ｀ディレクトリと同様である。

ファイルシステムのＲＥＳＴ ＡＰＩについて説明する。
・ファイルシステムへのマッピングの元に、従来技術のＲＥＳＴ ＡＰＩをローカルで起動する。これによって、ローカルなサービスを起動でき、テストや限定されたコンテンツ配布に利用できる。

トランザクション処理について、より詳細に説明する。
従来技術（本実施の形態を用いない技術）は、リモートの処理装置に多数の端末装置がアクセスし、処理が集中しており、そのため、処理装置がボトルネックになっていた。クラスタ化等も実装又は運用に複雑性を惹起し、結局、処理装置がダウンすればサービス提供できないこととなる。また、セキュリティ要件からＫＶＳはルックアップのみとなっていた。
本実施の形態は、分散リソースの基盤となり、データソースごとに自前の実行環境（第３端末装置２５０Ｃ内の情報処理装置１００Ｃ）とＫＶＳを具備し、生成、更新、廃棄については、リモートの処理装置（情報処理装置１００Ａ）とは無関係に動作する。例えば、リモートのＫＶＳの可用性はクラウドサービス側に担保させればよい。
ローカルのＫＶＳには、その利用者が所有するオブジェクト又は参照取得できた情報だけである。そのため、セキュリティ要件からくる制約が無くなり、任意のＡＰＩが利用可能である。
なお、第３端末装置２５０Ｃとして、大規模なデータソースを扱うものであってもよい。

リモートのＫＶＳは、次のように、ＳＤＫ経由でアクセスする。
ａｗｓ ＝ ｒｅｑｕｉｒｅ（’ａｗｓ−ｓｄｋ’）
なお、ａｗｓ−ｓｄｋはクラウドとして提供されているＷｅｂ ＳｅｒｖｉｃｅのＳＤＫ等が該当する。
ローカルのＫＶＳは、次のように、ＳＤＫ経由でアクセスする。
ｌｅｖｅｌＤＢ ＝ ｒｅｑｕｉｒｅ（’ｌｅｖｅｌＤＢ’）
なお、ｌｅｖｅｌＤＢはリレーショナルデータベース管理システムにおけるライブラリ等が該当する。
ＫＶＳであるので、ａｗｓ．ｐｕｔ（ｋｅｙ， ｖａｌｕｅ）やｌｅｖｅｌＤＢ．ｇｅｔ（ｋｅｙ）のようなＡＰＩを持つ。
これらのＡＰＩが、データ格納モジュール１１０、情報処理装置１００Ａにおけるオブジェクト又はデータ保持機能のＫＶＳインターフェイスである。
また、オブジェクト管理モジュール１４０において、
オブジェクト取得機能である、ｒｓ．ｇｅｔ（ｉｄ）
オブジェクト更新機能である、ｒｓ．ｕｐ（ｏｂｊ）
変更オブジェクトプッシュ機能である、ｒｓ．ｐｕｓｈ（）
等は、ローカル実行環境にロードされるリソース基盤ライブラリの提供するＡＰＩとして実現できる。これらのＡＰＩの動作例を示すフローチャートについては後述する。
本実施の形態は、これらのＡＰＩを利用してＫＶＳを操作する、ローカルの実行環境で動作するプログラムとしてもよい。

ＫＶＳのデータ構造について、ＫＶＳテーブル１６００の例を用いて説明する。図１６は、ＫＶＳテーブル１６００のデータ構造例を示す説明図である。ＫＶＳテーブル１６００は、キー欄１６１０、値欄１６２０を有している。キー欄１６１０は、キーを記憶している。値欄１６２０は、そのキーに対応する値を記憶している。
ＰＵＴ処理によって、キーと値を指定してキーに対応する値を更新できる。ＧＥＴ処理によって、キーを指定して対応する値を取得できる。
オブジェクトストア、データストア、変更オブジェクトリストを、ＫＶＳテーブル１６００として構成可能である。
オブジェクトストアは、例えば、ランダム生成された３２バイトのオブジェクト識別子をキーとしてＪａｖａＳｃｒｉｐｔオブジェクトを値とする。
データストアは、例えば、バイト配列を値として、そのバイト配列のＳＨＡ−２５６値（３２バイト）をキーとする。
変更オブジェクトリストは、例えば、変更されたオブジェクトの識別子を記録する。例えば、ここでは値は変更された時刻（又は日時（年、月、日、時、分、秒、秒以下、又はこれらの組み合わせであってもよい））とすればよい。
オブジェクト木については、図３の例で示した通りである。

図１７は、本実施の形態による処理例（オブジェクト生成）を示すフローチャートである。前述の「ｒｓ．ｇｅｎ（ｐｒｏｔｏ）」の処理である。ｐｒｏｔｏの子オブジェクトｏｂｊを生成する。なお、ここで作られたオブジェクトはメモリに存在するだけで、ｒｓ．ｕｐ（ｏｂｊ）するまでは永続化されていない。
ステップＳ１７００では、オブジェクト生成処理を開始する。
ステップＳ１７０２では、ｐｒｏｔｏの子オブジェクトｏｂｊを生成する。
ステップＳ１７０４では、ｉｄを生成する。具体的には、ｐｒｏｔｏ．ｉｄがある場合、ｏｂｊ．ｐｒｏｔｏにｐｒｏｔｏ．ｉｄをセットする。そして、ｏｂｊ．ｉｄにランダムに生成した識別子ｉｄをセットする。

ステップＳ１７０６では、現在時刻をセットする。具体的には、ｏｂｊ．ｃｒｅａｔｅｄＡｔに現在時刻をセットする。
ステップＳ１７０８では、オブジェクト識別子ｉｄのオブジェクトがローカル記憶装置（メモリ）に存在することをマークする。例えば、ｏｂｊｓというキャッシュオブジェクトを用意して、ｏｂｊｓ［ｉｄ］ ＝ ｏｂｊとする。
ステップＳ１７１０では、ｏｂｊを返却する。

図１８は、本実施の形態による処理例（オブジェクト取得）を示すフローチャートである。前述の「ｒｓ．ｇｅｔ（ｉｄ） → ｏｂｊ」の処理である。オブジェクト識別子ｉｄを引数に与えて、対応するｏｂｊを返す。
ステップＳ１８００では、オブジェクト取得処理を開始する。
ステップＳ１８０２では、オブジェクト識別子ｉｄのオブジェクトｏｂｊはロード済みか否かを判断し、ロード済みの場合はステップＳ１８０４へ進み、それ以外の場合はステップＳ１８０６へ進む。
ステップＳ１８０４では、ｏｂｊを返却し、処理を終了する（ステップＳ１８９９）。
ステップＳ１８０６では、オブジェクト識別子ｉｄのレコードはローカルなＫＶＳにあるか否かを判断し、ある場合はステップＳ１８０８へ進み、それ以外の場合はステップＳ１８１４へ進む。
ステップＳ１８０８では、ｏｂｊをローカルなＫＶＳからロードする。

ステップＳ１８１０では、オブジェクト識別子ｏｂｊ．ｐｒｏｔｏのオブジェクトｐｒｏｔｏ＝ｇｅｔ（ｏｂｊ．ｐｒｏｔｏ）をｏｂｊのプロトタイプにセット（再帰呼び出し）する。
ステップＳ１８１２では、ｏｂｊを返却し、処理を終了する（ステップＳ１８９９）。
ステップＳ１８１４では、オブジェクト識別子ｉｄのレコードはリモートのＫＶＳにあるか否かを判断し、ある場合はステップＳ１８１６へ進み、それ以外の場合はステップＳ１８２２へ進む。
ステップＳ１８１６では、ｏｂｊをリモートのＫＶＳからロードし、ローカルのＫＶＳにセーブする。
ステップＳ１８１８では、オブジェクト識別子ｏｂｊ．ｐｒｏｔｏのオブジェクトｐｒｏｔｏ＝ｇｅｔ（ｏｂｊ．ｐｒｏｔｏ）をｏｂｊのプロトタイプにセット（再帰呼び出し）する。
ステップＳ１８２０では、ｏｂｊを返却し、処理を終了する（ステップＳ１８９９）。
ステップＳ１８２２では、オブジェクト識別子ｉｄのオブジェクトは無いのでｕｎｄｅｆｉｎｅｄを返す。

図１９は、本実施の形態による処理例（オブジェクト更新）を示すフローチャートである。前述の「ｒｓ．ｕｐ（ｏｂｊ）」の処理である。ロードされたオブジェクトｏｂｊをＫＶＳにセーブする。
ステップＳ１９００では、オブジェクト更新処理を開始する。
ステップＳ１９０２では、オブジェクトｏｂｊをローカルなＫＶＳにセーブする。
ステップＳ１９０４では、オブジェクト識別子ｏｂｊ．ｉｄを変更オブジェクトリストにセーブする。

図２０は、本実施の形態による処理例（変更オブジェクトのリストのプッシュ）を示すフローチャートである。前述の「ｒｓ．ｐｕｓｈ（）」の処理である。ローカルのＫＶＳにあり、リモートに変更が未だ反映されていないオブジェクト集合をリモートのＫＶＳに反映する。
ステップＳ２０００では、変更オブジェクトリストプッシュ処理を開始する。
ステップＳ２００２では、変更オブジェクトリストｉｄｓとローカルの権限を表すトークンｔｏｋｅｎを取得する。
ステップＳ２００４では、リモートへの処理ストリームを作成する。
ステップＳ２００６では、処理ストリームｓｔｒｅａｍとトークンをリモートのＫＶＳに適用する。
ステップＳ２００８では、処理ストリームが完了したら、変更オブジェクトリストをクリアする。

次にトランザクション処理について説明する。プロトタイプ継承を活用したロックに関する処理である。
変更オブジェクトプッシュ「ｒｓ．ｐｕｓｈ（）」の呼び出し前におおもとのオブジェクト（情報処理装置１００Ａに記憶されているオブジェクト）にロック属性を付与し、呼び出し後にそのロック属性を除去する。
また、オブジェクト取得でロックされているオブジェクトはローカルのＫＶＳにはキャッシュされず、ロードもされないようにする。
ローカルリポジトリを持つのがあるサービスだとすると、そのサービスが変更するのはそのサービスの所有するオブジェクトである。したがって、サービス自体を表すオブジェクトに属性を付与すると、その子孫の全てのオブジェクトはロック属性を持つことになる。図３の例を用いて説明すると、サービス対象となるオブジェクトが「ｒｏｏｔ」オブジェクトＤ１であるとすると、「ｒｏｏｔ」オブジェクトＤ１の子孫である「ｃｒｕｄＳｃｏｐｅ」オブジェクトＤ１１等の全てのオブジェクトにおけるｉｓＬｏｃｋｅｄ属性を全て「ｔｒｕｅ」とする。
これによって、第三のローカル実行環境（そのオブジェクトを編集している端末装置２５０以外の端末装置２５０）がトランザクション中のオブジェクト取得を行い、中途半端な状態（編集中のオブジェクト）をロードしたり、ローカルのＫＶＳにキャッシュすることを防ぐことができる。

図２１は、本実施の形態による処理例を示すフローチャートである。（変更オブジェクトのリストのプッシュ）前述の「ｒｓ．ｐｕｓｈ（）」の処理である。ローカルのＫＶＳにあり、リモートに変更が反映されていないオブジェクト集合をリモートのＫＶＳに反映する。なお、図２１の例に示すフローチャートは、図２０の例に示すフローチャートにステップＳ２１０６の処理とステップＳ２１１０の処理を付加したものである。
ステップＳ２１００では、変更オブジェクトリストプッシュ処理を開始する。
ステップＳ２１０２では、変更オブジェクトリストｉｄｓとローカルの権限を表すトークンｔｏｋｅｎを取得する。
ステップＳ２１０４では、リモートへの処理ストリームを作成する。
ステップＳ２１０６では、［プロトタイプにｉｓＬｏｃｋｅｄ属性を付与］とトークンをリモートのＫＶＳに適用する。
ステップＳ２１０８では、処理ストリームｓｔｒｅａｍとトークンをリモートのＫＶＳに適用する。
ステップＳ２１１０では、［プロトタイプにｉｓＬｏｃｋｅｄ属性を除去］とトークンをリモートのＫＶＳに適用する。
ステップＳ２０１２では、処理ストリームが完了したら、変更オブジェクトリストをクリアする。

図２２は、本実施の形態による処理例（オブジェクト取得）を示すフローチャートである。前述の「ｒｓ．ｇｅｔ（ｉｄ） → ｏｂｊ」の処理である。オブジェクト識別子ｉｄを引数に与えて、対応するｏｂｊを返す。なお、図２２の例に示すフローチャートは、図１８の例に示すフローチャートにステップＳ２２２０の処理とステップＳ２２２２の処理を付加したものである。これらは、ロックされたオブジェクトをリモートから取得してしまうのを防ぐために、前述のｒｓ．ｇｅｔ（ｉｄ）を変更したものである。
ステップＳ２２００では、オブジェクト取得処理を開始する。
ステップＳ２２０２では、オブジェクト識別子ｉｄのオブジェクトｏｂｊはロード済みか否かを判断し、ロード済みの場合はステップＳ２２０４へ進み、それ以外の場合はステップＳ２２０６へ進む。
ステップＳ２２０４では、ｏｂｊを返却し、処理を終了する（ステップＳ２２９９）。
ステップＳ２２０６では、オブジェクト識別子ｉｄのレコードはローカルなＫＶＳにあるか否かを判断し、ある場合はステップＳ２２０８へ進み、それ以外の場合はステップＳ２２１４へ進む。
ステップＳ２２０８では、ｏｂｊをローカルなＫＶＳからロードする。
ステップＳ２２１０では、オブジェクト識別子ｏｂｊ．ｐｒｏｔｏのオブジェクトｐｒｏｔｏ＝ｇｅｔ（ｏｂｊ．ｐｒｏｔｏ）をｏｂｊのプロトタイプにセット（再帰呼び出し）する。
ステップＳ２２１２では、ｏｂｊを返却し、処理を終了する（ステップＳ２２９９）。

ステップＳ２２１４では、オブジェクト識別子ｉｄのレコードはリモートのＫＶＳにあるか否かを判断し、ある場合はステップＳ２２１６へ進み、それ以外の場合はステップＳ２２２６へ進む。
ステップＳ２２１６では、ｏｂｊをリモートのＫＶＳからロードし、ローカルのＫＶＳにセーブする。
ステップＳ２２１８では、オブジェクト識別子ｏｂｊ．ｐｒｏｔｏのオブジェクトｐｒｏｔｏ＝ｇｅｔ（ｏｂｊ．ｐｒｏｔｏ）をｏｂｊのプロトタイプにセット（再帰呼び出し）する。
ステップＳ２２２０では、ｏｂｊがロックされているか否かを判断し、ロックされている場合はステップＳ２２２２へ進み、それ以外の場合はステップＳ２２２４へ進む。
ステップＳ２２２２では、ローカルのＫＶＳへのセーブを破棄して例外をスローする。
ステップＳ２２２４では、ｏｂｊを返却し、処理を終了する（ステップＳ２２９９）。
ステップＳ２２２６では、オブジェクト識別子ｉｄのオブジェクトは無いのでｕｎｄｅｆｉｎｅｄを返す。

次に、変更通知又はプルの処理について説明する。
ローカルなＫＶＳを持つエンティティがリモートのＫＶＳにアクセスし、その後、リモートのＫＶＳが変更されることで、リモートとローカルに不整合がおきる。つまり、リモートである情報処理装置１００Ａ内の情報が変更されているにもかかわらず、ローカルである第３端末装置２５０Ｃ内の情報は変更前の状態となってしまうことが生じる。
本実施の形態によって、リモートでの変更をローカルに伝達することを可能にする。
ローカルなＫＶＳを持つエンティティがリモートのＫＶＳにアクセスするときには、どのような権限（ｏｗｎｅｒ）で誰（ｃｌｉｅｎｔ）がアクセスしているかの情報が必要になる。
ここでは、「ｅ」がローカルＫＶＳの識別子、「ｒ」がリモートＫＶＳにアクセスする権限の識別子とする。
リモートのＫＶＳでは、購読者属性とＭｕｔａｔｅ属性を新しく追加し、リモートのＫＶＳでのＣＲＵＤ操作に伴い、これらの属性を更新する。

なお、購読者属性とＭｕｔａｔｅ属性は、Ｏｂｊｅｃｔ Ｓｔｏｒｅのオプショナルな属性である。
ローカルなＫＶＳを持つエンティティが操作したオブジェクトには、購読者属性が付与されて操作したエンティティを追加する。
購読者オブジェクト（購読者属性に追加されたエンティティ）には、Ｍｕｔａｔｅ属性を付与し、変更を反映すべきオブジェクトを追加する。
これらを示すＫＶＳとして、例えば、オブジェクトストアＫＶＳテーブル２３００を用いる。図２３は、オブジェクトストアＫＶＳテーブル２３００のデータ構造例を示す説明図である。オブジェクトストアＫＶＳテーブル２３００は、図１６の例に示したＫＶＳテーブル１６００に購読者属性欄２３３０、Ｍｕｔａｔｅ属性欄２３４０を付加したものである。オブジェクトストアＫＶＳテーブル２３００は、キー欄２３１０、値欄２３２０、購読者属性欄２３３０、Ｍｕｔａｔｅ属性欄２３４０を有している。キー欄２３１０は、キーを記憶している。値欄２３２０は、そのキーに対応する値を記憶している。購読者属性欄２３３０は、そのキーに対応する購読者属性を記憶している。購読者属性として、例えば「そのオブジェクトを操作したエンティティのリスト」がある。Ｍｕｔａｔｅ属性欄２３４０は、そのキーに対応するＭｕｔａｔｅ属性を記憶している。Ｍｕｔａｔｅ属性として、例えば「そのエンティティが反映すべき変更されたオブジェクトのリスト」がある。

図２４は、本実施の形態による処理例（リモートの「Ｏｂｊｅｃｔ Ｓｔｏｒｅ」へのＰＵＴ処理）を示すフローチャートである。前述したｐｕｔ処理「ｐｕｔ（ｋ， ｖ）」の処理である。権限ｒでエンティティｅがｐｕｔ（ｋ， ｖ）を実行する。なお、以下でｒ，ｅ，ｋは正確には識別子であるが、説明上、その識別子が指し示すオブジェクトとして扱う。ここで、ｋはＣＲＵＤの対象オブジェクトである。
ステップＳ２４００では、リモートＯｂｊｅｃｔ ＳｔｏｒｅへのＰＵＴ処理を開始する。
ステップＳ２４０２では、権限ｒは対象オブジェクトｋのプロトタイプ（チェーンに含まれる）か否かを判断し、プロトタイプ（チェーンに含まれる）場合はステップＳ２４０４へ進み、それ以外の場合はステップＳ２４０６へ進む。
ステップＳ２４０４では、エンティティｅをオブジェクトｋの購読者リストに追加する。
ステップＳ２４０６では、処理を拒絶し、終了する（ステップＳ２４９９）。

ステップＳ２４０８では、オブジェクトｋの購読者リストに含まれる購読者ｓはあるか否かを判断し、ある場合はステップＳ２４１０へ進み、それ以外の場合はステップＳ２４２０へ進む。
ステップＳ２４１０では、購読者ｓは無効化されているか否かを判断し、無効化されている場合はステップＳ２４１２へ進み、それ以外の場合はステップＳ２４１４へ進む。
ステップＳ２４１２では、オブジェクトｋの購読者リストからｓを除去し、ステップＳ２４０８へ戻る。
ステップＳ２４１４では、購読者ｓがエンティティｅに一致しているか否かを判断し、一致している場合はステップＳ２４１６へ進み、それ以外の場合はステップＳ２４１８へ進む。
ステップＳ２４１６では、購読者ｓの変更オブジェクトリストからｋを除去し、ステップＳ２４０８へ戻る。
ステップＳ２４１８では、購読者ｓの変更オブジェクトリストにｋを追加し、ステップＳ２４０８へ戻る。
ステップＳ２４２０では、ｐｕｔ（ｋ，ｖ）を実行する。

図２５は、本実施の形態による処理例（リモートの「Ｏｂｊｅｃｔ Ｓｔｏｒｅ」へのＧＥＴ処理）を示すフローチャートである。前述のｇｅｔ処理「ｇｅｔ（ｋ， ｖ）」の処理である。権限ｒでエンティティｅがｐｕｔ（ｋ， ｖ）を実行する。なお、以下でｒ，ｅ，ｋは正確には識別子であるが、説明上、その識別子が指し示すオブジェクトとして扱う。ここで、ｋはＣＲＵＤの対象オブジェクトである。
ステップＳ２５００では、リモートＯｂｊｅｃｔ ＳｔｏｒｅへのＧＥＴ処理を開始する。
ステップＳ２５０２では、エンティティｅをオブジェクトｋの購読者リストに追加する。
ステップＳ２５０４では、エンティティｅの変更オブジェクトリストからｋを除去する。
ステップＳ２５０６では、ｇｅｔ（ｋ）を実行する。

図２６は、本実施の形態による処理例（オブジェクト更新処理（永続化層からメモリへのロード処理））を示すフローチャートである。前述の「ｒｓ．ｄｏｗｎ（ｉｄ）」の処理である。ｉｄで指定されたオブジェクトｏｂｊがロードされていれば、ＫＶＳから再ロードする。ロードされていなければ、何もしない。
ステップＳ２６００では、オブジェクト更新処理を開始する。
ステップＳ２６０２では、オブジェクト識別子ｉｄのオブジェクトｏｂｊがロードされているか否かを判断し、ロードされている場合はステップＳ２６０４へ進み、それ以外の場合（オブジェクト識別子ｉｄのオブジェクトｏｂｊがロードされていない場合）はステップＳ２６１０へ進む。

ステップＳ２６０４では、ＫＶＳからｏｂｊを再ロードして、メモリ中のオブジェクトを変更する。
ステップＳ２６０６では、プロトタイプが変更されているか否かを判断し、変更されている場合はステップＳ２６０８へ進み、それ以外の場合は処理を終了する（ステップＳ２６９９）。
ステップＳ２６０８では、プロトタイプをｒｓ．ｇｅｔ（ｏｂｊ．ｉｄ）し、それをｏｂｊのプロトタイプにセットする。
ステップＳ２６１０では、何も行わず、処理を終了する（ステップＳ２６９９）。

図２７は、本実施の形態による処理例（変更オブジェクトのリストのプル処理）を示すフローチャートである。前述した「ｒｓ．ｐｕｌｌ（）」の処理である。ローカルのＫＶＳにキャッシュがあり、リモートでの変更が未だ反映されていないオブジェクト集合をローカルのＫＶＳに反映する。
ステップＳ２７００では、変更オブジェクトリストプル処理を開始する。
ステップＳ２７０２では、変更オブジェクトリストをリモートのＫＶＳから取得する。
ステップＳ２７０４では、リモートへの処理ストリームを作成する。例えば、変更オブジェクトリストに含まれるオブジェクトを取得する。
ステップＳ２７０６では、処理ストリームｓｔｒｅａｍとトークンをリモートのＫＶＳに適用する。
ステップＳ２７０８では、処理ストリームが完了したら、変更オブジェクトリストをクリアする。

次に、本実施の形態によるファイルシステムへのマッピング処理について説明する。具体的には、ローカルリポジトリの生成や管理に関する処理である。
図２８は、本実施の形態による処理例（パスをオブジェクトにアタッチする処理）を示すフローチャートである。「ａｔｔａｃｈＰａｔｈ（ｏｂｊ， ｐａｔｈ）」の処理である。オブジェクトｏｂｊにファイルシステム上のｐａｔｈをアタッチする。
ファイルは、
｛ ｔｙｐｅ： ｛コンテント型｝，
ｅｔａｇ： ｛ハッシュ値｝ ｝
という属性を持つオブジェクトで表現される。ディレクトリは、それがｆｏｏ， ｂａｒ， ｂｕｚを含むとすれば、
｛ ｆｏｏ： ｛ｆｏｏの指すオブジェクトの識別子｝，
ｂａｒ： ｛ｂａｒの指すオブジェクトの識別子｝，
ｂａｒ： ｛ｂａｚの指すオブジェクトの識別子｝ ｝
という属性を持つオブジェクトで表現される。

ステップＳ２８００では、パスをオブジェクトにアタッチする処理を開始する。
ステップＳ２８０２では、ｐａｔｈを判断し、ファイルの場合はステップＳ２８０４へ進み、ディレクトリの場合はステップＳ２８０８へ進む。
ステップＳ２８０４では、ファイルの内容をＤａｔｅ Ｓｔｏｒｅに保存する。
ステップＳ２８０６では、ｏｂｊ．ｔｙｐｅ＝コンテント型、ｏｂｊ．ｅｔａｇ＝ファイルの内容のハッシュ値として、ｏｂｊをＯｂｊｅｃｔ Ｓｔｏｒｅにセーブする。

ステップＳ２８０８では、ディレクトリに含まれるパス名ｓｕｂを属性名とし、パス名ｓｕｂに対応するオブジェクトの識別子をその属性値とする。
ステップＳ２８１０では、ｏｂｊにパス名ｓｕｂに対応する属性が既にあるか否かを判断し、ある場合はステップＳ２８１２へ進み、ない場合はステップＳ２８１４へ進む。
ステップＳ２８１２では、それが指すオブジェクトにｓｕｂを再帰的にアタッチする。
ステップＳ２８１４では、ｓｕｂに対応するオブジェクトはｏｂｊの子として生成し、ディレクトリの階層構造がオブジェクトのプロトタイプ継承ツリーと一致するようにする。

図２９は、本実施の形態による処理例（ローカルリポジトリのｉｎｉｔとｃｏｍｍｉｔ）を示すフローチャートである。ワーキングディレクトリひとつのローカルリポジトリへ初期化したり反映したりする。なお、コマンドツールで「ｒｓ ｃｏｍｍｉｔ」とすると、ワーキングディレクトリに、ｒｓディレクトリが未だ無い場合はｒｓディレクトリを追加し、現状のディレクトリがローカルリポジトリにコミットされる。
ステップＳ２９００では、ローカルリポジトリのｉｎｉｔ＆ｃｏｍｍｉｔ処理を開始する。
ステップＳ２９０２では、ワーキングディレクトリに「．ｒｓ」ディレクトリが無いか否かを判断し、無い場合はステップＳ２９０４へ進み、それ以外の場合はステップＳ２９０６へ進む。
ステップＳ２９０４では、ワーキングディレクトリに「．ｒｓ」ディレクトリを作る。
ステップＳ２９０６では、「．ｒｓ／ｏｗｎｅｒ」が無いか否かを判断し、無い場合はステップＳ２９０８へ進み、それ以外の場合はステップＳ２９１０へ進む。

ステップＳ２９０８では、新たなルートオブジェクトを生成・永続化し、そのＩＤを「．ｒｓ／ｏｗｎｅｒ」に書き込む。
ステップＳ２９１０では、ＩＤが「．ｒｓ／ｏｗｎｅｒ」のオブジェクトをｏｗｎｅｒとする。
ステップＳ２９１２では、ｏｗｎｅｒにワーキングディレクトリをアタッチする。
ステップＳ２９１４では、「．ｒｓ／ｃｌｉｅｎｔ」が無いか否かを判断し、無い場合はステップＳ２９１６へ進み、それ以外の場合はステップＳ２９１８へ進む。
ステップＳ２９１６では、ｏｗｎｅｒの子オブジェクトを生成・永続化し、そのＩＤを、「．ｒｓ／ｃｌｉｅｎｔ」に書き込む。
ステップＳ２９１８では、ＩＤが「．ｒｓ／ｃｌｉｅｎｔ」のオブジェクトをｃｌｉｅｎｔとする。
ステップＳ２９２０では、ｃｌｉｅｎｔにｄｅｒｅｆしたリーフをアタッチする。つまり、ｆｏｏ／ｂａｒ／ｂｕｚという構造のとき、
ｃｌｉｅｎｔ ＝ ｛ ’ｆｏｏ／ｂａｒ／ｂｕｚ’： オブジェクトｂｕｚのＩＤ Ｚ ｝
とする。アタッチでできるオブジェクトはネストしているため、キーを展開してリーフを並べることを行う。

次に、ファイルシステムのＲＥＳＴ ＡＰＩに関して説明する。
具体的には、ローカルリポジトリの公開処理を説明する。
コマンドツールで「ｒｓ ｐｕｂｌｉｓｈ」とすると、ワーキングディレクトリを起点とした「ｈｔｔｐ ｓｅｒｖｅｒ」が起動する。なお、ワーキングディレクトリは既に「ｒｓ ｃｏｍｍｉｔ」済みとする。
このようなローカルＲＥＳＴ ＡＰＩサーバーを起動することで共用の公開サーバーに負荷を掛けず、公開サーバーと同じＡＰＩを利用できる。また、ローカルな環境でデータやスコープを開発・テストし、完了後にｒｓ．ｐｕｓｈ（）することで、共用公開サーバーにデプロイできる。もちろんのことながら、更新もできる。

具体的には、ローカルに、特開２０１５−１６２０５７号公報に記載されたリソース管理基盤のＲＥＳＴ ＡＰＩサービスを起動する。
より具体的には、リソース管理基盤のＲＥＳＴ ＡＰＩサービスは、情報処理システムＡによって実現される。
それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付ける受付手段と、前記権限オブジェクトに関連付けられた関数オブジェクトを取得する取得手段と、前記関数オブジェクトにより前記要求を処理する処理手段と、を含む情報処理システムＡを用いる。
また、情報処理システムＡは、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの情報の比較結果に基づいて、前記要求を受理するか否かを判断する判断手段を含み、前記処理手段は、前記要求を受理すると判断した場合に、前記関数オブジェクトにより前記要求を処理してもよい。
また、前記判断手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとが一致する場合に、前記要求を受理するようにしてもよい。
また、前記判断手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトの親であるオブジェクト、さらに該所有者オブジェクトの親の親であるオブジェクトを順次接続した経路の中に、前記権限オブジェクトの親であるオブジェクトが含まれる場合に、前記要求を受理するようにしてもよい。
また、前記判断手段は、前記権限オブジェクトが前記管理手段により管理されない場合には、前記要求を受理しないようにしてもよい。
また、前記判断手段は、前記権限オブジェクトが、前記権限情報を認可したオブジェクトである所有者オブジェクト、前記権限情報の委譲先を示すオブジェクトであるクライアントオブジェクト、前記権限情報により実行が許可される関数をそれぞれ指定するデータを含まない場合には、前記要求を受理しないようにしてもよい。
また、情報処理システムＡは、関数のソースコードを含むデータオブジェクトを登録する手段と、所与の所有者オブジェクト、所与のクライアントオブジェクト、前記データオブジェクトを指定する情報を含む権限オブジェクトを生成する生成手段と、を含むようにしてもよい。
また、情報処理システムＡは、前記権限オブジェクトに含まれる情報により指定される前記データオブジェクトに含まれる関数のソースコードに基づいて関数オブジェクトが生成できない場合には、前記要求を受理しないようにしてもよい。
また、前記取得手段は、前記権限オブジェクトに含まれる前記処理指定オブジェクトにより指定される前記データオブジェクトに含まれる関数のソースコードに基づいて生成された関数オブジェクトを取得するようにしてもよい。

ここで、アノニマスなアクセス（つまり、ＯＡｕｔｈ ２．０アクセストークンもクッキーも指定しないアクセス）に対して、「．ｒｓ／ｃｌｉｅｎｔ」の値をＩＤとするオブジェクトｃｌｉｅｎｔの子オブジェクトａＵｓｅｒを生成し、以下の内容のアクセストークン
｛ ｏｗｎｅｒ： ｃｌｉｅｎｔ．ｉｄ，
ｃｌｉｅｎｔ： ａＵｓｅｒ．ｉｄ，
ｓｃｏｐｅ： ｒｅａｄＯｎｌｙ．ｉｄ ｝
を発行すればよい。

なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図３０に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ３００１を用い、記憶装置としてＲＡＭ３００２、ＲＯＭ３００３、ＨＤ３００４を用いている。ＨＤ３００４として、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）を用いてもよい。リクエスト受付モジュール１２０、権限オブジェクト検証モジュール１３０、オブジェクト管理モジュール１４０、配信用オブジェクト生成モジュール１４１、リクエスト処理モジュール１５０、処理結果提供モジュール１６０等のプログラムを実行するＣＰＵ３００１と、そのプログラムやデータを記憶するＲＡＭ３００２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ３００３と、データ格納モジュール１１０、オブジェクト管理テーブル１１１、バリュー管理テーブル１１２としての機能を有する補助記憶装置（フラッシュ・メモリ等であってもよい）であるＨＤ３００４と、キーボード、マウス、タッチスクリーン、マイク等に対する利用者の操作に基づいてデータを受け付ける受付装置３００６と、ＣＲＴ、液晶ディスプレイ、スピーカー等の出力装置３００５と、ネットワークインターフェイスカード等の通信ネットワークと接続するための通信回線インターフェイス３００７、そして、それらをつないでデータのやりとりをするためのバス３００８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。

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

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

前述の実施の形態は以下のように把握してもよい。そして、これらと組み合わせてもよい。
［Ａ］ それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、
権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記管理手段により管理される提供対象オブジェクトへの読み出し要求を受け付ける受付手段と、
前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記提供対象オブジェクトの情報を提供する提供手段と、を含み、
前記提供手段は、前記提供対象オブジェクトが有していないデータ項目については、前記提供対象オブジェクトの親やさらにその親を再帰的にたどる列に含まれる祖先オブジェクトのデータ項目の情報を提供する、ことを特徴とする情報処理システム。

［Ｂ］ 前記提供手段は、前記祖先オブジェクトに含まれる項目のうち、前記提供対象オブジェクトに含まれる項目と一致する項目については、前記提供対象オブジェクトに含まれる項目の情報を提供する
［Ａ］に記載の情報処理システム。

［Ｃ］ 前記受付手段が、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記祖先オブジェクトの子オブジェクトの生成の要求を受け付けた場合に、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記祖先オブジェクトの子オブジェクトとして前記提供対象オブジェクトを生成する生成手段、をさらに有する
［Ａ］又は［Ｂ］に記載の情報処理システム。

［Ｄ］ 前記祖先オブジェクトの子となる提供対象オブジェクトを生成する権限を有する第１の権限オブジェクト、又は前記提供対象オブジェクトを更新する権限を有する第２の権限オブジェクトに基づいて、前記提供対象オブジェクトを無効化する手段をさらに含む
［Ａ］から［Ｃ］のいずれか一項に記載の情報処理システム。

［Ｅ］ 前記提供対象オブジェクトの情報の更新を凍結する指示を受け付けた場合には、前記提供対象オブジェクトの情報を、当該凍結する指示を受け付けた時点の情報に固定する
［Ａ］から［Ｄ］のいずれか一項に記載の情報処理システム。

［Ｆ］ 前記凍結する指示を受け付けた後において、当該凍結を解除する指示を受け付けた場合には、前記提供対象オブジェクトの情報を、前記祖先オブジェクトの情報に基づいて更新する
［Ｅ］に記載の情報処理システム。

［Ｇ］ 前記第２の権限オブジェクトに基づいて、前記提供対象オブジェクトに処理を追加する手段をさらに含む
［Ｄ］に記載の情報処理システム。

［Ｈ］ 前記生成手段は、複数の提供先ごとに前記祖先オブジェクトの子である提供対象オブジェクトをそれぞれ生成する
［Ａ］から［Ｇ］のいずれか一項に記載の情報処理システム。

［Ｉ］ 前記提供手段は、提供先に対して前記提供対象オブジェクトの情報と、前記第２の権限オブジェクトを提供する
［Ｄ］に記載の情報処理システム。

［Ｊ］ 前記生成手段は、前記第１の権限オブジェクトの所有者オブジェクトの親であるオブジェクト、さらに該所有者オブジェクトの親の親であるオブジェクトを順次接続した経路の中に、前記第１の権限オブジェクトの親であるオブジェクトが含まれる場合に、前記提供対象オブジェクトを生成する
［Ｃ］に記載の情報処理システム。

［Ｋ］ 前記生成手段は、前記第１の権限オブジェクトが前記管理手段により管理されない場合には、前記提供対象オブジェクトを生成しない
［Ｃ］に記載の情報処理システム。

［Ｌ］ 前記提供手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトが一致する場合に、前記提供対象オブジェクトの情報を提供する、
［Ａ］から［Ｋ］のいずれか一項に記載の情報処理システム。

［Ｍ］ 前記提供手段は、前記権限情報を認可したオブジェクトである所有者オブジェクト、さらに該所有者オブジェクトの親の親であるオブジェクトを順次接続した経路の中に、前記権限オブジェクトの親であるオブジェクトが含まれる場合に、前記提供対象オブジェクトの情報を提供する、
［Ａ］から［Ｌ］のいずれか一項に記載の情報処理システム。

［Ｎ］ それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、
権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記管理手段により管理される提供対象オブジェクトへの読み出し要求を受け付ける受付手段と、
前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記提供対象オブジェクトの情報を提供する提供手段と、してコンピュータを機能させ、
前記提供手段を、前記提供対象オブジェクトが有していないデータ項目については、前記提供対象オブジェクトの親やさらにその親を再帰的にたどる列に含まれる祖先オブジェクトのデータ項目の情報を提供する、ように機能させるためのプログラム。

そして、前述の発明は、以下の効果を有する。
［Ａ］及び［Ｎ］に記載の発明によれば、一のマスターデータについての提供内容を個別に制御できる。

［Ｂ］に記載の発明によれば、子孫オブジェクトのデータ項目内容に応じて提供されるデータの内容を個別に設定できる。

［Ｃ］に記載の発明によれば、マスターデータの子孫オブジェクトを生成できる。

［Ｄ］に記載の発明によれば、提供先に応じたオブジェクトを個別に無効化できる。

［Ｅ］に記載の発明によれば、提供先の個別のオブジェクトが参照する先のオブジェクトの変化によらず、提供先の個別のオブジェクトの内容が変わらないように凍結化できる。

［Ｆ］に記載の発明によれば、提供先の個別のオブジェクトの内容の凍結化を解除できる。

［Ｇ］に記載の発明によれば、提供先の個別のオブジェクトに処理を追加できる。

［Ｈ］に記載の発明によれば、複数の提供先ごとに個別のオブジェクトを設定できる。

［Ｉ］に記載の発明によれば、提供先に対し提供された個別のオブジェクトの更新を認可することができる。

［Ｊ］から［Ｍ］に記載の発明によれば、適正な権限を有する場合に提供先に個別に設定するコンテンツを生成したり、コンテンツの情報を提供したりすることを認可することができる。

１００…情報処理装置
１１０…データ格納モジュール
１１１…オブジェクト管理テーブル
１１２…バリュー管理テーブル
１２０…リクエスト受付モジュール
１３０…権限オブジェクト検証モジュール
１４０…オブジェクト管理モジュール
１４１…配信用オブジェクト生成モジュール
１５０…リクエスト処理モジュール
１６０…処理結果提供モジュール
２５０…端末装置
２８０…認証装置
２９０…通信回線

Claims (5)

1. 複数の情報処理装置を有し、
   少なくとも１つの情報処理装置は、
   それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、本情報処理装置内の記憶手段で管理する第１の管理手段と、
   それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、本情報処理装置又は他の情報処理装置からアクセス可能な記憶手段で管理する第２の管理手段と、
   権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記第１の管理手段又は前記第２の管理手段により管理される対象オブジェクトに対する要求を、本情報処理装置又は他の情報処理装置から受け付ける受付手段と、
   前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記対象オブジェクトの情報に対して、前記要求に対応する処理を行う処理手段
   を有し、
   前記処理手段は、前記要求が、オブジェクトの情報の生成、更新、又は廃棄の処理である場合は、前記第１の管理手段を用いて該処理を行い、
   前記要求が、前記第１の管理手段が管理する記憶手段内の生成、更新、又は廃棄された情報を、前記第２の管理手段が管理する記憶手段に反映させる処理である場合は、前記第２の管理手段を用いて該処理を行い、
   本情報処理装置内のオブジェクトの変更の処理については権限の判定は不要とし、他の情報処理装置からのオブジェクトの変更の処理については、前記要求に付随して送付されるトークンによって請求される権限を逸脱する処理については失敗とする、
   ことを特徴とする情報処理システム。
2. 前記要求がオブジェクトの情報の変更を禁止する要求である場合は、該オブジェクトの子孫のオブジェクトの情報に対しても、変更を禁止する禁止手段
   をさらに有することを特徴とする請求項１に記載の情報処理システム。
3. 前記第２の管理手段が管理する記憶手段にオブジェクトの情報の書き込みを始める前に、前記第１の管理手段が管理する記憶手段内の対応するオブジェクトの情報の変更を禁止し、該書き込みが完了したときに、該禁止を解除する
   ことを特徴とする請求項２に記載の情報処理システム。
4. 前記第２の管理手段が管理する記憶手段内のオブジェクトの情報に対して要求を行った利用者を記憶し、該オブジェクトの情報の変更が行われた場合は、該利用者に通知を行う通知手段
   をさらに有することを特徴とする請求項１から３のいずれか一項に記載の情報処理システム。
5. コンピュータを、
   それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、前記コンピュータ内の記憶手段で管理する第１の管理手段と、
   それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を、前記コンピュータ又は他の情報処理装置からアクセス可能な記憶手段で管理する第２の管理手段と、
   権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む、前記第１の管理手段又は前記第２の管理手段により管理される対象オブジェクトに対する要求を、前記コンピュータ又は他の情報処理装置から受け付ける受付手段と、
   前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの権限の比較結果に基づいて、前記対象オブジェクトの情報に対して、前記要求に対応する処理を行う処理手段
   として機能させ、
   前記処理手段は、前記要求が、オブジェクトの情報の生成、更新、又は廃棄の処理である場合は、前記第１の管理手段を用いて該処理を行い、
   前記要求が、前記第１の管理手段が管理する記憶手段内の生成、更新、又は廃棄された情報を、前記第２の管理手段が管理する記憶手段に反映させる処理である場合は、前記第２の管理手段を用いて該処理を行い、
   前記コンピュータ内のオブジェクトの変更の処理については権限の判定は不要とし、他の情報処理装置からのオブジェクトの変更の処理については、前記要求に付随して送付されるトークンによって請求される権限を逸脱する処理については失敗とする、
   情報処理プログラム。

Images