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

Description

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

オブジェクトを管理するサーバでは、処理の要求元であるクライアントが有する権限に応じてオブジェクトを処理（生成、取得、変更、削除等）することがある。ここで、サーバで管理するオブジェクトには生成、変更、削除等が行われることがあるため、クライアントに対してオブジェクトとは独立に権限を固定的に紐付けておくと、クライアントの権限に応じてオブジェクトを柔軟に処理することが困難となることがある。

特開平０９−２５１４２５号公報

本発明の目的は、オブジェクトの情報とオブジェクトの処理に関する権限とを同一のデータ構造で管理し、クライアントからの要求を柔軟に制御できる情報処理システム及びプログラムを提供することにある。

請求項１に係る発明は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する情報処理システムにおいて、オーナー属性を持つオブジェクトであるアクセストークンのプロトタイプがオーナーに一致する場合に、前記アクセストークンが添付されたメソッド送信を受理する処理部を有する情報処理システムである。

請求項２に係る発明は、前記処理部は、前記アクセストークンのプロトタイプがオーナーの親のオブジェクトを順次接続した経路の中に含まれる場合に、該アクセストークンが添付されたメソッド送信は、前記オーナーにより認可されたものと解釈し、受理する請求項１に記載の情報処理システムである。

請求項３に係る発明は、前記処理部により前記メソッド送信が受理された場合に、前記オーナーに受理されたことを通知する通知部を有する請求項２に記載の情報処理システムである。

請求項４に係る発明は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理するコンピュータに、オーナー属性を持つオブジェクトであるアクセストークンのプロトタイプがオーナーに一致する場合に、前記アクセストークンが添付されたメソッド送信を受理するステップを実行させるためのプログラムである。

本実施形態に係る情報処理装置の機能ブロック図である。 木構造の一例を示す図である。 木構造の一例を示す図である。 木構造の一例を示す図である。 木構造の一例を示す図である。 木構造の一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 データを管理する管理テーブルの一例を示す図である。 木構造の一例を示す図である。

以下、本発明を実施するための実施の形態（以下、実施形態という）を、図面に従って説明する。

［１．情報処理装置に備えられる機能の説明］
図１には、本実施形態に係る情報処理装置１の機能ブロック図を示した。図１に示されるように、情報処理装置１は、木構造データ管理部１１、リクエスト受付部１２、権限情報取得部１３、検証部１４、リクエスト処理部１５、処理データ提供部１６を備える。

情報処理装置１に備えられる上記各部の機能は、ＣＰＵ（Central Processing Unit）等の制御手段、半導体メモリや磁気ディスク装置等の記憶手段、ネットワークインターフェース等の通信手段を備えるコンピュータにおいて、記憶手段に記憶されるプログラムを制御手段が実行することにより実現されることとしてよい。なお、プログラムは、情報記憶媒体に格納された状態で情報処理装置１に供給されることとしてもよいし、インターネット等のデータ通信手段を介して情報処理装置１に供給されることとしてもよい。以下、情報処理装置１に備えられた各部の詳細について説明する。

木構造データ管理部１１は、木構造を構成する２つ以上のオブジェクトを管理する。ここで、オブジェクトは、系に唯一存在するルートオブジェクトを除けば、唯一つの親のオブジェクト（プロトタイプ）を持つ。ルートオブジェクトは自身のプロトタイプを持たない。オブジェクトＡがオブジェクトＢのプロトタイプであるとき、オブジェクトＢはオブジェクトＡのアーティファクトであるともいう。オブジェクト間のプロトタイプ関係はオブジェクト全体の集合に木構造を導入する。木構造を破壊しないならば、プロトタイプを再接続することで木構造を変形することが可能である。木構造データ管理部１１で管理するオブジェクトは値を持つことができる。ＲＥＳＴ（REpresentational State Transferアーキテクチャスタイル）の文脈においては、オブジェクトをリソース、値を表現と呼ぶこともある。値を持つオブジェクトには、アクセストークンと呼ばれる権限情報を表すものがある。オブジェクトには、単にオブジェクト識別子とプロトタイプのみからなる純粋なアイデンティティのみを表すもの、任意のコンテント型の値を持つデータを表現するもの、アクセス資格を証明するクレデンシャルであるアクセストークン、あるいはオブジェクトの所有者であるリソースオーナーやリソースオーナーの認可のもとにオブジェクトへのアクセスを行うアプリケーション（クライアント）のようなエンティティを表すものが含まれることとしてよい。これらのオブジェクト達が１つの木構造の中に含まれる。そして、木構造データ管理部１１は、クライアント装置２から受け付けた命令に従って、管理するオブジェクトの追加、更新、情報の読み出し、削除等を実行する。以下、木構造データ管理部１１で管理されるデータの一例について説明する。

図２〜図６には、木構造データ管理部１１で管理されるオブジェクトを木構造に表した表示例を、図７〜１４には、木構造を構成する各オブジェクトのデータを管理する管理テーブルの一例を示した。ここでは、図２と、図２に対応する管理テーブルのデータ構成例を示した図７を参照しながら、木構造データ管理部１１で管理されるオブジェクトのデータ構成例について説明する。

図７には、図２に示した木構造データのデータを保持したリソース管理テーブルの一例を示した。図７の（Ａ）は、有効化管理テーブル、（Ｂ）はオブジェクト管理テーブル、（Ｃ）はデータ内容管理テーブルを表している。

ここで、図７の（Ａ）に示されるように、有効化管理テーブルには、各オブジェクトのキー（オブジェクトＩＤであり、例えばオブジェクト生成時にシステムがランダムに発生する３２バイト程度の乱数としてよい。本実施形態においては一例として１６進符号化された４バイトの値をキーとして用いることとしている）、バリュー（フラグ値、例えば真偽値としてよい）の各項目を含む１以上のレコードを含む。図２に示した木構造におけるオブジェクト「ｓｐｆ」のオブジェクトキーは「ａ１ｆ４０ｆ９９」であり、オブジェクト「ｓｐｆ＿ｔｏｋｅｎ」のオブジェクトキーは「ｂｆａ６７９５６」であり、いずれも有効化（「０」）されている。なお、オブジェクトを無効化する場合には、有効化管理テーブルにおいて、オブジェクトキーに関連付けられるバリューを「１」に更新すればよい。

次に、図７の（Ｂ）に示されるように、オブジェクト管理テーブルには、オブジェクトキー（オブジェクトＩＤ）、プロトタイプバリュー、アーティファクトバリュー、ステートバリュー、コンテントタイプバリューの各項目を含む１以上のレコードを含む。ここで、オブジェクトキーには、オブジェクトＩＤが格納され、プロトタイプバリューには、オブジェクトの親オブジェクトのオブジェクトＩＤが格納され、アーティファクトバリューには、オブジェクトのアーティファクトのオブジェクトＩＤを格納したデータ内容管理テーブル内のレコードのキー（例えばハッシュ値としてもよい）が格納され、ステートバリューには、オブジェクトのデータ内容を示すデータ内容管理テーブル内のレコードのキー（例えばハッシュ値としてもよい）が格納され、コンテントタイプバリューには、オブジェクトの種類を示すデータ内容管理テーブルのキー（例えばハッシュ値としてもよい）が格納される。

そして、図７の（Ｃ）に示されるように、オブジェクトのデータ内容を格納したデータ内容管理テーブルには、キー（例えば、アーティファクトバリュー、ステートバリュー、コンテントタイプバリューに格納された値）に関連付けて、対応するデータ内容が格納される。例えば、データ内容管理テーブルにおいては、オブジェクトのアーティファクトバリューのキーに関連付けて、当該オブジェクトのアーティファクトのリストの情報が記憶される。また、例えば、データ内容管理テーブルにおいては、アクセストークンのオブジェクトに紐付くステートバリューに格納されたキーには、｛“オーナー”：オーナーのオブジェクトＩＤ、“クライアント”：クライアントのオブジェクトＩＤ、“スコープ”：スコープを表現する文字列｝の情報が関連付けられている。全ての処理要求にはアクセストークンが添付されるが、ここで、オーナーが処理のリクエスタ、クライアントが処理の代理リクエスタとして扱われ、スコープには、生成（Ｃ：ｃｒｅａｔｅ）、更新（Ｕ：ｕｐｄａｔｅ）、削除（Ｄ：ｄｅｌｅｔｅ）、一覧取得（Ｌ：ｌｉｓｔ）等の認可された処理の種類の情報が含まれる。なお、スコープには権限を有する処理の情報を含むこととしてよい。そして、例えば、データ内容管理テーブルにおいては、オブジェクトに紐付くコンテントタイプバリューに格納されたキーには、例えばオブジェクトのデータ型に関する情報が関連付けられてもよい。

リクエスト受付部１２は、クライアント装置２から木構造データ管理部１１で管理されるオブジェクトの処理に関するリクエストを受け付ける。また、リクエスト受付部１２は、リクエストとともに、アクセストークン（権限情報のキー）の情報を取得する。

権限情報取得部１３は、リクエスト受付部１２で受け付けたアクセストークンに基づいて、受け付けたリクエストに係る権限情報（例えばオーナー情報、クライアント情報、スコープ情報）を取得する。例えば、権限情報取得部１３は、リクエスト受付部１２で受け付けたアクセストークンが、有効化管理テーブルで有効とされている場合に、アクセストークンをキーとしてオブジェクト管理テーブルから対応するレコードを検索する。ここで、権限情報取得部１３は、オブジェクト管理テーブルからアクセストークンをキーとするレコードが検索されなかった場合には検索エラーを検証部１４に出力することとしてよい。そして、権限情報取得部１３は、オブジェクト管理テーブルからアクセストークンをキーとするレコードが検索された場合には、検索されたレコードのステートバリューに格納された値をキー（特定キー）として、データ内容管理テーブルから対応するレコードを検索する。ここで、権限情報取得部１３は、データ内容管理テーブルから特定キーに対応するレコードが検索されなかった場合には検索エラーを検証部１４に出力することとしてよい。そして、権限情報取得部１３は、データ内容管理テーブルから特定キーに対応するレコードが検索された場合には、検索されたレコードのバリューに格納されたデータ（オーナー情報、クライアント情報、スコープ情報）を権限情報として取得し、オーナー情報やクライアント情報を検証（オーナーやクライアントが有効なオブジェクトＩＤであるか）し、検証部１４に出力する。

検証部１４は、権限情報取得部１３により取得された権限情報と、リクエスト受付部１２で受け付けたアクセストークンの親オブジェクト（プロトタイプオブジェクト）の情報の比較に基づく検証を実行する。例えば、検証部１４は、権限情報取得部１３により検索エラーが通知された場合には、検証エラーをリクエスト処理部１５に出力する。また、検証部１４は、権限情報取得部１３により取得された権限情報に含まれるオーナー情報（オーナーオブジェクト）が、リクエスト受付部１２で受け付けたアクセストークンの親オブジェクト（プロトタイプオブジェクト）に一致するか、オーナーオブジェクトの親オブジェクト、親オブジェクトの更に親オブジェクトを順次接続する経路（プロトタイプチェーン）内に、アクセストークンの親オブジェクト（プロトタイプオブジェクト）が含まれる場合に、検証成功と判断し、それ以外の場合には検証失敗と判断して、検証結果をリクエスト処理部１５に通知する。

ここで、通知キューに関する処理について説明する。まず、リクエスト受付部１２で受け付けたアクセストークンが検証された場合において、リクエスト受付部１２で受け付けたアクセストークンのプロトタイプは通知を格納するキュー（通知キュー）を持つこととなる（通知キューに空のキューがセットされる）。また、リクエスト受付部１２で受け付けたアクセストークンが検証された場合において、アクセストークンが指定するオーナーオブジェクトのプロトタイプチェーンに、アクセストークンのプロトタイプが含まれる場合には、オーナーオブジェクトから通知キューを持つオブジェクトをプロトタイプチェーンに沿って探索し、最初に見つかったオブジェクトが通知先として設定される。

リクエスト処理部１５は、リクエスト受付部１２で受け付けたリクエストと、権限情報取得部１３により取得された権限情報と、検証部１４から通知された検証結果と、に基づいてリクエストに係る処理の実行を制御する。例えば、リクエスト処理部１５は、リクエスト受付部１２で受け付けたリクエストに係る処理が、権限情報取得部１３により取得された権限情報のスコープ情報に含まれており、さらに、検証部１４から通知された検証結果が検証成功であるという条件、さらにターゲットリソース（リクエスト対象のオブジェクト）とアクセストークンの指定するオーナー（オブジェクト）との関係についての条件（例えば、オーナーがターゲットリソースに対する特権を有しているか否か等）を満足する場合に、リクエスト受付部１２で受け付けたリクエストに係る処理を実行し、その実行結果を処理データ提供部１６に出力し、上記の条件を満足しない場合には、リクエストに係る処理を不受理としてエラーを処理データ提供部１６に出力することとしてよい。また、リクエスト処理部１５は、受け付けたリクエストが上記の条件を満足しない場合であっても、処理（例えば更新）を保留し、ターゲットリソースのプロトタイプに処理（例えば更新）の依頼を通知することとしてもよい。ここで、ターゲットリソースのプロトタイプが通知キューを持っていない場合には、ターゲットリソースのプロトタイプチェーンにおける最初に通知キューを有するオブジェクト（通知先オブジェクト）に通知される。ここで、通知先オブジェクトは、通知キューに格納された通知を知った後に、自身のアクセストークンを利用してターゲットリソースへの処理（例えば値のセット）を行なってもよいし、単に通知をキューから削除してもよい。

以下、クライアント装置２からのリクエストが受理される場合に、リクエスト処理部１５が受け付けたリクエストに応じて実行する処理（アーティファクトのリスト取得、アーティファクトの生成、オブジェクトの表現取得、オブジェクトの表現更新、オブジェクトの削除、プロトタイプの取得、プロトタイプの更新等）の例について説明する。以下説明する例においては、クライアント装置２から情報処理装置１に対して送信されるリクエストが、ＨＴＴＰＳのトランスポートでＲＥＳＴのＡＰＩを利用するものであり、ＨＴＴＰリクエストヘッダにアクセストークンが含まれる場合を例として説明する。

リクエスト処理部１５は、受け付けたリクエストが“ＧＥＴ ／”の場合には、権限情報に含まれるオーナーオブジェクトをキーとしてオブジェクト管理テーブルから対応するレコードを検索し、検索されたレコードに含まれるアーティファクトバリューの値に基づいてデータ内容管理テーブルを検索し、検索されたレコードに含まれるバリューの値を処理結果として処理データ提供部１６に出力する。

リクエスト処理部１５は、受け付けたリクエストが“ＰＯＳＴ ／”の場合には、権限情報に含まれるオーナーオブジェクトを親とする新たなオブジェクトのキー（オブジェクトＩＤ）を生成し（オブジェクトＩＤは例えば乱数により生成することとしてよい）、生成したオブジェクトＩＤと、プロトタイプオブジェクトの情報とを格納したレコードをオブジェクト管理テーブルに追加し、生成したオブジェクトＩＤを処理結果として処理データ提供部１６に出力する。そして、リクエスト処理部１５は、プロトタイプオブジェクトについてのアーティファクトバリューの値を更新するとともに、更新した値をキー、新たに生成されたオブジェクトの情報をリストに含むリスト情報とを含むレコードをデータ内容管理テーブルに追加することとしてよい。

リクエスト処理部１５は、受け付けたリクエストが“ＧＥＴ ／｛ｉｄ｝”の場合には、｛ｉｄ｝をオブジェクトキーとしてオブジェクト管理テーブルから対応するレコードを検索し、検索されたレコードに含まれるステートバリューに格納された値を参照し、参照した値をキーとしてデータ内容管理テーブルを検索し、検索されたレコードに含まれるバリューの値を処理結果として処理データ提供部１６に出力する。

リクエスト処理部１５は、受け付けたリクエストが“ＰＵＴ ／｛ｉｄ｝”の場合には、｛ｉｄ｝により特定されるターゲットオブジェクトに対して、アクセストークンが指定するオーナーが特権を有しているときには（すなわち、ターゲットオブジェクトのプロトタイプチェーンにアクセストークンが指定するオーナーが含まれているときには）、｛ｉｄ｝をオブジェクトキーとしてオブジェクト管理テーブルから対応するレコードを検索し、検索されたレコードに含まれるステートバリューに格納された値を参照し、参照した値をキーとしてデータ内容管理テーブルを検索し、検索されたレコードに含まれるバリューの値を、リクエストとともに受け付けた更新情報に従って更新する。

リクエスト処理部１５は、受け付けたリクエストが“ＤＥＬＥＴＥ ／｛ｉｄ｝”の場合には、｛ｉｄ｝により特定されるターゲットオブジェクトに対して、アクセストークンが指定するオーナーが特権を有しているときには（すなわち、ターゲットオブジェクトのプロトタイプチェーンにアクセストークンが指定するオーナーが含まれているときには）、｛ｉｄ｝をオブジェクトキーとしてオブジェクト管理テーブルから対応するレコードを検索し、検索されたレコードのアーティファクトバリューに値が格納されていない（つまり，ターゲットオブジェクトはアーティファクトを持たない）場合には、有効化管理テーブルにおいてオブジェクトキー｛ｉｄ｝に対応するバリューを無効化の値（１）に更新し、検索されたレコードのアーティファクトバリューに値が格納されている場合には、エラーを処理データ提供部１６に出力することとしてよい。

リクエスト処理部１５は、受け付けたリクエストが“ＧＥＴ ／｛ｉｄ｝／ｐｒｏｔｏｔｙｐｅ”の場合には、｛ｉｄ｝をオブジェクトキーとしてオブジェクト管理テーブルから対応するレコードを検索し、検索されたレコードに含まれるプロトタイプバリューに格納された値を処理結果として処理データ提供部１６に出力する。

リクエスト処理部１５は、受け付けたリクエストが“ＰＵＴ ／｛ｉｄ｝／ｐｒｏｔｏｔｙｐｅ”でリクエストボディは新しいプロトタイプのオブジェクトＩＤの場合には、アクセストークンが指定するオーナー（リクエスタ）がターゲットリソース（｛ｉｄ｝で特定されるオブジェクト）の現在のプロトタイプであり、プロトタイプの変更が木構造を破壊しない場合には、新しいプロトタイプを予約する。そして、リクエスタが新しいプロトタイプとして予約され、プロトタイプの変更が木構造を破壊しない場合には、新しいプロトタイプへの設定を完了し（すなわちプロトタイプの更新を実行し）、上記以外のケースについては、リクエストを拒絶する。例えば、オブジェクトＣの変更前のプロトタイプをＡ、変更後のプロトタイプをＢとすると、「リクエスタ＝A、変更先のプロトタイプ＝B、対象オブジェクト＝Ｃ」とする第１の指示と、「リクエスタ＝B、変更先のプロトタイプ＝B、対象オブジェクト＝Ｃ」とする第２の指示の両方が，それぞれの指示のタイミングで，木構造を破壊しない場合に、リクエスト処理部１５は、オブジェクトＣのプロトタイプをＡからＢに変更する処理を実行することとしてよい。

処理データ提供部１６は、リクエスト処理部１５から通知された処理結果をクライアント装置２に提供する。なお、処理データ提供部１６は、リクエスト処理部１５からエラーが通知された場合にはクライアント装置２にエラーを通知することとしてよい。

また、木構造データ管理部１１で管理されるオブジェクト毎に、そのオブジェクトに対して実行が保留されたリクエストを保持するキューを用意し、オブジェクトのオーナーには、オブジェクトに用意されたキューに保持されたアイテムの閲覧や削除が可能とするようにしてよい。ここで、キューに保持されるアイテムは、ＨＴＴＰリクエストのヘッダおよびボディのハッシュ値とし、ボディの内容自体はハッシュ値から参照できるように保存しておくこととしてよい。そして、オブジェクトのオーナーは、リクエストの内容が妥当であれば、そのリクエストを自分自身のアクセストークンを利用したリプレイにより実行することとしてよい。ただし、当初のＨＴＴＰリクエストヘッダをそのまま全て保存した場合には、本来秘匿すべきアクセストークンがオブジェクトのオーナーに知られてしまう（つまり、オーナーは元のリクエストを行ったエンティティになりすませる）ので、リクエストヘッダ中のアクセストークンはオブジェクト識別子ではなく、そのオブジェクト識別子に割り当てられたハッシュ値（すなわち、オブジェクト識別子（アクセストークン）に対してデータ内容管理テーブルで管理されるハッシュ値）に置換することで、アクセストークンの漏洩を防ぐこととしてよい。このようにすれば、ハッシュ値からトークンの内容（JSONオブジェクトとしての｛“オーナー”：オーナーのオブジェクトＩＤ、“クライアント”：クライアントのオブジェクトＩＤ、“スコープ”：スコープを表現する文字列｝は特定できるが、アクセストークン自体がオーナーに露見することはない。

［２．処理の具体例についての説明］
以下、本実施形態に係る情報処理装置１において実行されるオブジェクトの追加、更新処理の具体例について図２〜図１４を参照しながら説明する。

まず、図２には、初期状態のオブジェクトのなす木構造を示した。図２に示されるように、初期状態のオブジェクトの木構造には、ルートオブジェクトである「ｓｐｆ」に対して、ルート用のアクセストークンである「ｓｐｆ＿ｔｏｋｅｎ」がアーティファクトとして設けられている。また、図２に示される木構造のデータは、図７に示す管理テーブル（有効化テーブル、オブジェクト管理テーブル、データ内容管理テーブル）に対応している。

次に、図３に示されるように、オブジェクトのなす木構造において、オブジェクト「ｓｐｆ」のアーティファクトとして「ｕｓｅｒｓ」オブジェクトを追加する場合の処理について説明する。この場合には、まず、クライアント装置２は、情報処理装置１に対してアクセストークン「ｓｐｆ＿ｔｏｋｅｎ」を用いて、“ＰＯＳＴ ／”のリクエストを投げる。これにより、情報処理装置１は、図８に示されるように、新たなオブジェクトキーを生成し、生成したオブジェクトキーについてのレコードを有効化管理テーブル（Ａ）とオブジェクト管理テーブル（Ｂ）に追加するとともに、オブジェクト管理テーブル（Ｂ）とデータ内容管理テーブル（Ｃ）に関して、アーティファクトを追加するプロトタイプオブジェクト（ここでは「ｓｐｆ」オブジェクト）に関するアーティファクトバリューの値を更新、追加する。なお、図８においては、図７から変更があるデータについて下線を付している。情報処理装置１は、追加したオブジェクトのキー（ｅ３５６ｂｆ４６）をクライアント装置２に通知する。

クライアント装置２は、アクセストークン「ｓｐｆ＿ｔｏｋｅｎ」を用いて、情報処理装置１から通知されたオブジェクトキー（ｅ３５６ｂｆ４６）についての情報を更新するリクエスト（ＰＵＴ ／ｅ３５６ｂｆ４６）、更新内容｛“ｎａｍｅ”：“ｕｓｅｒｓ”｝を情報処理装置１に対して投げる。これにより、図９に示されるように、オブジェクト管理テーブル（Ｂ）及びデータ内容管理テーブル（Ｃ）において、オブジェクトキー（ｅ３５６ｂｆ４６）についてのデータ内容が登録される。なお、図９においては、図８から変更があるデータについて下線を付している。

次に、図４に示されるように、オブジェクト「ｕｓｅｒｓ」の一時的なアクセストークンとして「ｔｅｍｐ＿ｕｓｅｒｓ＿ｔｏｋｅｎ」を追加する。クライアント装置２は、「ｓｐｆ＿ｔｏｋｅｎ」を用いて、“ＰＯＳＴ ／”のリクエストを投げることで、オブジェクトを新規追加することとしてよい。図１０には、「ｔｅｍｐ＿ｕｓｅｒｓ＿ｔｏｋｅｎ」のオブジェクト（ｄｅ７５ｅ９６９）を追加した管理テーブルを示した。なお、図１０においては、図９から変更があるデータについて下線を付している。

ここで、クライアント装置２は、アクセストークン「ｓｐｆ＿ｔｏｋｅｎ」を用いて、情報処理装置１から通知されたオブジェクトキー（ｄｅ７５ｅ９６９）についての情報を更新するリクエスト（ＰＵＴ ／ｄｅ７５ｅ９６９）、更新内容｛“ｏｗｎｅｒ”：“／ｅ３５ｂｆ４６”，“ｃｌｉｅｎｔ”：“／ｅ３５ｂｆ４６”，“ｓｃｏｐｅ“：”ｃｒｅａｔｅ ｕｐｄａｔｅ ｄｅｌｅｔｅ ｌｉｓｔ”｝を情報処理装置１に対して投げる。これにより、図１１に示されるように、オブジェクト管理テーブル（Ｂ）及びデータ内容管理テーブル（Ｃ）において、オブジェクトキー（ｄｅ７５ｅ９６９）について、オブジェクト「ｕｓｅｒｓ」をオーナーとする権限情報が設定される。なお、図１１においては、図１０から変更があるデータについて下線を付している。

次に、図５に示されるように、クライアント装置２は、アクセストークン「ｔｅｍｐ＿ｕｓｅｒｓ＿ｔｏｋｅｎ」を用いてオブジェクト「ｕｓｅｒｓ」の子として「ｕｓｅｒｓ＿ｔｏｋｅｎ」を追加する。すなわち、クライアント装置２は、「ｔｅｍｐ＿ｕｓｅｒｓ＿ｔｏｋｅｎ」を用いて、“ＰＯＳＴ ／”のリクエストを投げることで、オブジェクトを新規追加することとしてよい。図１２には、「ｕｓｅｒｓ＿ｔｏｋｅｎ」のオブジェクト（１ｆｆ６４ｄｆ４）を追加した管理テーブルを示した。なお、図１２においては、図１１から変更があるデータについて下線を付している。

ここで、クライアント装置２は、アクセストークン「ｔｅｍｐ＿ｕｓｅｒｓ＿ｔｏｋｅｎ」を用いて、情報処理装置１から通知されたオブジェクトキー（１ｆｆ６４ｄｆ４）についての情報を更新するリクエスト（ＰＵＴ ／１ｆｆ６４ｄｆ４）、更新内容｛“ｏｗｎｅｒ”：“／ｅ３５ｂｆ４６”，“ｃｌｉｅｎｔ”：“／ｅ３５ｂｆ４６”，“ｓｃｏｐｅ“：”ｃｒｅａｔｅ ｕｐｄａｔｅ ｄｅｌｅｔｅ ｌｉｓｔ”｝を情報処理装置１に対して投げる。これにより、図１３に示されるように、オブジェクト管理テーブル（Ｂ）及びデータ内容管理テーブル（Ｃ）において、オブジェクトキー（１ｆｆ６４ｄｆ４）について、オブジェクト「ｕｓｅｒｓ」をオーナーとする権限情報が設定される。なお、図１３においては、図１２から変更があるデータについて下線を付している。

次に、図６に示されるように、クライアント装置２は、アクセストークン「ｕｓｅｒｓ＿ｔｏｋｅｎ」を用いて、オブジェクト「ｕｓｅｒｓ」に対してアーティファクト「Ａｌｉｃｅ」を追加する。すなわち、クライアント装置２は、「ｕｓｅｒｓ＿ｔｏｋｅｎ」を用いて、“ＰＯＳＴ ／”のリクエストを投げることで、オブジェクトを新規追加することとしてよい。図１４には、「Ａｌｉｃｅ」のオブジェクト（８７ａｄ５５７ｆ）を追加した管理テーブルを示した。なお、図１４においては、図１３から変更があるデータについて下線を付している。

このように、アクセストークンの追加、オブジェクトの追加、更新を実行することにより、権限情報と、リソースとを同一の木構造内に設けることが可能となるとともに、リソースごとに詳細な権限情報を設定することが可能となる。

次に、図１５に示されたオブジェクトの木構造を参照しながら、アクセストークンの指定するオーナーと、プロトタイプ（親オブジェクト）が異なる場合に実行される通知処理の一例について説明する。なお、アクセストークンの指定するオーナーと、アクセストークン自体のプロトタイプ（親オブジェクト）が異なるタイプのアクセストークンを特異トークンと称する。

図１５に示されるように、オブジェクトＡに対するアーティファクトであるオブジェクトＢはアクセストークンであり、そのオーナー及びクライアントはオブジェクトＡ、スコープはｓ＝”ｃｒｅａｔｅ ｕｐｄａｔｅ ｄｅｌｅｔｅ ｌｉｓｔ”である。

次に、トークンＢを利用してオブジェクトＣを生成したとする。このとき、トークンＢが利用された時に、トークンＢのプロトタイプであるオブジェクトＡは通知を格納するキューを有することとなる。

次に、トークンＢを利用してトークンＤを生成したとする。ここで、トークンＤは、オブジェクトＡをプロトタイプとし、そのオーナー及びクライアントはオブジェクトＣ、スコープはｓであるとする。

次に、トークンＤを利用してトークンＥを生成したとする。ここで、トークンＤが検証された時に、トークンＤが特異トークンであることが検知され、トークンＤのオーナーであるオブジェクトＣに対して通知される。ここで、オブジェクトＣから通知キューを有するオブジェクトをプロトタイプチェーンに沿って探索し、その最初に探索されたオブジェクト（オブジェクトＡ）を通知先とする。

次に、トークンＥを利用してオブジェクトＦを生成したとする。このとき、トークンＥが検証されて、トークンＥのプロトタイプであるオブジェクトＣは通知を格納するキューを有することとなる。

また、トークンＤを利用してオブジェクトＧが生成されたとする。このとき、トークンＤが特異トークンであることが検知され、トークンＤのオーナーであるオブジェクトＣに対して通知が発行され、オブジェクトＣのキューに通知が格納される。

また、オブジェクトＣを親とするトークンＫがあり、トークンＫのオーナーがＣ、クライアント（オーナの権限の委譲先を示す）がＪで、スコープがｓである場合に、オブジェクトＪはオブジェクトＣの代理で例えばオブジェクトＣのアーティファクトであるオブジェクトＧを生成することができる。

本発明は、例えば以下の形態を有することができる。

（１）本実施形態に係る情報処理装置１において、オーナー属性を持つオブジェクト（アクセストークンと呼称）のプロトタイプがオーナーに一致する場合（正規アクセストークンと呼称）、そのアクセストークンが添付されたメソッド送信は、オーナーにより認可されたものと解釈され、受理されることとしてよい。
（２）（１）において、アクセストークン自体のプロトタイプがオーナーのプロトタイプチェーンに含まれる場合（特異アクセストークンと呼称）、そのアクセストークンが添付されたメソッド送信は、オーナーにより認可されたものと解釈され、受理されることとしてよい。
（３）（２）において、特異アクセストークンの添付によってメソッド送信が受理された場合、オーナーに受理されたことを通知することとしてよい。
（４）（２）において、特異アクセストークンの添付によってメソッド送信が受理された場合、アクセストークン自体のプロトタイプに受理されたことを通知することとしてよい。
（５）（１）乃至（４）において、オブジェクト生成のためのメソッド（クローニング）を持ち、生成されたオブジェクトはオーナーのクローン（つまり、オーナーをプロトタイプとする）であることとしてよい。
（６）（１）乃至（５）において、アクセストークンはクライアント属性を持ち、アクセストークンが添付されたメソッド送信は、指定されたクライアントへ委譲されたものと解釈されることとしてよい。
（７）（１）乃至（６）において、アクセストークンはスコープ属性を持ち、アクセストークンが添付されたメソッド送信は、指定されたスコープの範囲で委譲されたものと解釈されることとしてよい。
（８）（１）乃至（７）において、クローン一覧取得のためのメソッド（クローンリスティング）を持ち、オーナーのクローンのコレクションを返却することとしてよい。
（９）（１）乃至（８）において、対象オブジェクトの表現取得のためのメソッドを持つこととしてよい。
（１０）（１）乃至（９）において、対象オブジェクトの表現更新のためのメソッドを持ち、対象オブジェクトのプロトタイプに認可された場合に限り、表現更新が実行できることとしてよい。
（１１）（１）乃至（１０）において、対象オブジェクトの削除のためのメソッドを持ち、対象オブジェクトのプロトタイプに認可された場合に限り、削除が実行できることとしてよい。
（１２）（１）乃至（１１）において、メソッドの実行は、アクセストークンが指定するスコープに含まれる場合に限り、実行されることとしてよい。
（１３）（１）乃至（１２）において、対象オブジェクトのプロトタイプチェーンに含まれるオブジェクトに認可された場合、メソッドの実行が可能となることとしてよい。
（１４）（１）乃至（１３）において、対象オブジェクトのプロトタイプチェーンに含まれるオブジェクトに認可されてメソッドの実行を行った場合、対象オブジェクトのプロトタイプにメソッドが実行されたことを通知することとしてよい。
（１５）（１）乃至（１４）において、対象オブジェクトのプロトタイプチェーンに含まれるオブジェクトに認可されてメソッドの実行を行った場合、メソッド送信オーナーにメソッドが実行されたことを通知することとしてよい。
（１６）（１）乃至（１５）において、オブジェクト識別子はシステムによってランダムに生成されることとしてよい。
（１７）（１）乃至（１６）において、表現は、表現のハッシュ値として定まる識別子を持ち、オブジェクトと表現のバインディングはこの識別子を介して行われることとしてよい。
（１８）（１）乃至（１７）において、オブジェクト表現取得およびオブジェクト表現更新等の表現の送受信が発生するメソッド実行では、応答に表現識別子が付加されることとしてよい。
（１９）（１）乃至（１８）において、オブジェクト表現取得およびオブジェクト表現更新等の表現の送受信が発生するメソッド実行では、メソッド送信に表現識別子が付加され、付加された表現識別子に応じてメソッド実行が条件的に行われることとしてよい。
（２０）（１）乃至（１９）において、権限が満たされない対象オブジェクトへのメソッド送信の内容は保存され、対象オブジェクトのプロトタイプは送信内容を参照できることとしてよい。
（２１）（１）乃至（２０）において、メソッド送信に添加されたトークンは置換されることとしてよい。
（２２）（１）乃至（２１）において、対象オブジェクトのプロトタイプに事象が通知されることとしてよい。
（２３）（１）乃至（２２）において、通知はキューあるいはスタックに保存されることとしてよい。
（２４）（１）乃至（２３）において、オブジェクトへのメソッド送信の内容や付帯状況は記録され、オーナーは参照することができることとしてよい。
（２５）（１）乃至（２４）において、メソッド送信のトランスポートがＨＴＴＰ ｏｖｅｒ ＴＬＳ （ｈｔｔｐｓ）であることとしてよい。
（２６）（１）乃至（２５）において、アクセストークンがＨＴＴＰリクエストメッセージにおけるＡｕｔｈｏｒｉｚａｔｉｏｎフィールドを利用して添付されることとしてよい。
（２７）（１）乃至（２６）において、クローニングがファクトリーリソースへのＰＯＳＴで表現されることとしてよい。
（２８）（１）乃至（２７）において、クローンリスティングがファクトリーリソースへのＧＥＴで表現されることとしてよい。
（２９）（１）乃至（２８）において、オブジェクト表現取得がエンティティリソースへのＧＥＴで表現されることとしてよい。
（３０）（１）乃至（２９）において、オブジェクト表現更新がエンティティリソースへのＰＵＴで表現されることとしてよい。
（３１）（１）乃至（３０）において、メソッド送信のトランスポートがＷｅｂＳｏｃｋｅｔ ｏｖｅｒ ＴＬＳ （ｗｓｓ）であることとしてよい。

また、本実施形態において、クライアント装置２から受け付けた要求に対して、要求とともに受け付けたアクセストークンにより権限がない場合であっても、プロトタイプの情報についてはクライアント装置２に提供することとしても構わない。

１ 情報処理装置、２ クライアント装置、１１ 木構造データ管理部、１２ リクエスト受付部、１３ 権限情報取得部、１４ 検証部、１５ リクエスト処理部、１６ 処理データ提供部。

Claims (3)

1. それぞれ親又は子の少なくも一方が定められたオブジェクトの情報を管理する情報処理システムにおいて、
   アクセス資格を証明するオブジェクトであり、オーナー属性を持つオブジェクトであるアクセストークンの指定を、オブジェクトの処理に関するリクエストとともに受け付ける受付手段と、
   前記アクセストークンの親のオブジェクトが、前記オーナー属性により示されるオブジェクトと一致するか、又は前記オーナー属性により示されるオブジェクトの親のオブジェクトを順次接続した経路の中に含まれるか否かを判断する第１判断手段と、
   前記アクセストークンの親のオブジェクトが、前記オーナー属性により示されるオブジェクトと一致するか、又は前記オーナー属性により示されるオブジェクトの親のオブジェクトを順次接続した経路の中に含まれる場合には、前記リクエストを受理すると判断し、前記アクセストークンの親のオブジェクトが、前記オーナー属性により示されるオブジェクトと一致せず、且つ前記経路の中に含まれない場合には、前記リクエストを受理しないと判断する第２判断手段を有する情報処理システム。
2. 前記アクセストークンの親のオブジェクトが前記オーナー属性により示されるオブジェクトと一致する場合には、前記アクセストークンの親のオブジェクトに受理されたことを通知し、前記アクセストークンの親のオブジェクトが前記オーナー属性により示されるオブジェクトの親のオブジェクトを順次接続した経路の中に含まれる場合には、当該経路の中に含まれる前記アクセストークンの親のオブジェクトに受理されたことを通知する通知手段を有する
   請求項１に記載の情報処理システム。
3. それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理するコンピュータに、
   アクセス資格を証明するオブジェクトであり、オーナー属性を持つオブジェクトであるアクセストークンの指定を、オブジェクトの処理に関するリクエストとともに受け付けるステップ、
   前記アクセストークンの親のオブジェクトが、前記オーナー属性により示されるオブジェクトと一致するか、又は前記オーナー属性により示されるオブジェクトの親のオブジェクトを順次接続した経路の中に含まれるか否かを判断するステップ、及び、
   前記アクセストークンの親のオブジェクトが、前記オーナー属性により示されるオブジェクトと一致するか、又は前記オーナー属性により示されるオブジェクトの親のオブジェクトを順次接続した経路の中に含まれる場合には、前記リクエストを受理すると判断し、前記アクセストークンの親のオブジェクトが、前記オーナー属性により示されるオブジェクトと一致せず、且つ前記経路の中に含まれない場合には、前記リクエストを受理しないと判断するステップを実行させるプログラム。
   

Images