以下に図面を参照して、本発明にかかる情報処理装置、情報処理システムおよび情報処理プログラムの実施の形態を詳細に説明する。
(実施の形態)
(システム構成例)
図1は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。
図1において、実施の形態にかかる情報処理システムは、分散型PDS(Personal Data Store)サーバ100、150を含む複数の分散型PDSサーバと、ユーザ端末装置110、160を含む複数のユーザ端末装置から構成される。複数の分散型PDSサーバと、ユーザ端末装置が、ネットワーク(たとえば、図2に示すネットワーク206)によって接続されることにより、システムを構成する。また、各分散型PDSサーバは、ネットワークを介して、図示を省略する他のシステムと通信をすることができる。複数の分散型PDSサーバは、具体的には、たとえばWeb(World Wide Web)サーバなどのサーバであってもよい。
分散型PDSサーバ100、150が、実施の形態にかかる情報処理装置を構成するようにしてもよい。分散型PDSサーバ100、150は、各ユーザのPDS101、151を備え、提供するAPI(Application Programming Interface)として、パーソナルデータ管理機能102、152と、ソーシャル管理機能103、153と、を備えている。
パーソナルデータ管理機能102、152は、ユーザのパーソナルデータを管理するために、セル管理機能(利用者のパーソナルデータを管理する機能)や、ボックス管理機能(利用者のパーソナルデータをアプリケーションや用途毎の領域に管理する機能)を有する。
セル管理機能には、たとえば、セル設定(利用者のパーソナルデータ領域の登録/参照/変更/削除/一覧参照)、アカウント設定(利用者のパーソナルデータ領域に属するアカウントの登録/参照/変更/削除/一覧参照)、認証(利用者の認証)、ロール設定(利用者の役割を登録/参照/変更/削除/一覧参照)、ボックス設定(アプリケーション毎のデータ領域の登録/参照/変更/削除/一覧参照)、アクセス制御(利用者や利用者フォルダへのアクセス権の設定/参照/変更)、イベント受付(利用者に対するイベントを受け付けてログ出力)などがある。
また、ボックス管理機能には、ファイル操作(コレクション設定/ファイル設定/アクセス権設定)やデータベース操作(スキーマ設定/データ操作)などがある。
このように、パーソナルデータ管理機能102、152は、セルを管理する単位であるユニット、利用者および利用者のデータ(パーソナルデータ)を管理する単位であるセル、利用者のデータ格納領域であるボックスを用いて、利用者の情報およびデータを管理することができる。
ソーシャル管理機能103、153は、利用者のパーソナルデータに利用者間の関係性を定義づけ、それにより利用者のパーソナルデータの開示制御および秘匿制御を可能とする機能である。具体的には、たとえば、外部セル設定(開示先利用者の登録/参照/変更/削除/一覧参照)、リレーション設定(開示先利用者との関係性を登録/参照/変更/削除/一覧参照)、外部ロール設定(開示先利用者の役割を登録/参照/変更/削除/一覧参照)、メッセージ送受信(利用者のパーソナルデータの開示を許諾するためのコミュニケーション機能)などがある。
このように、ソーシャル管理機能103、153は、パーソナルデータ(セル)に利用者間の関係性(リレーション)を定義することで、パーソナルデータの開示/秘匿制御が可能となる。それにより、利用者の意思でパーソナルデータの開示が可能なため、利用者間の秘匿性を保つことが可能となる。
これらの機能を用いて、たとば、ユーザ1(主催者)PDS101において、打合せの予定の登録をおこなう(『Appointment打合せ10:00~』)。そうすると、ユーザ2(参加者)PDS151において、ユーザ1(主催者)に対して「主催者」という関係性を登録する。
このような関係性が登録されると、当該関係性に基づいて、ユーザ1(主催者)に対して、「主催者」には自分の居場所を見せる権限が与えられ、ユーザ2(参加者)PDS内のユーザ2(参加者)の現在地に関する情報を、ユーザ2(参加者)の承認を得ることなく、ユーザ1(主催者)PDS101が取得することができるようになる。ただし、打合せの予定時刻を経過した場合は、状況が変化したため、「主催者」には自分の居場所を見せる権限は廃棄される。このように、関係性と、状況とに基づいて、PDSに対するアクセス権限を動的に制御することができる。
(情報処理装置のハードウェア構成例)
図2は、実施の形態にかかる情報処理装置のハードウェア構成の一例を示すブロック図である。情報処理装置の一例である分散型PDSサーバ100、150は、CPU(Central Processing Unit)201と、メモリ202と、ネットワークI/F(Interface)203と、記録媒体I/F204と、記録媒体205と、を有する。また、各構成部は、バス200によってそれぞれ接続される。
ここで、CPU201は、分散型PDSサーバ100、150の全体の制御を司る。メモリ202は、たとえば、ROM(Read Only Memory)、RAM(Random Access Memory)およびフラッシュROMなどを有する。具体的には、たとえば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU201のワークエリアとして使用される。メモリ202に記憶されるプログラムは、CPU201にロードされることで、コーディングされている処理をCPU201に実行させる。
ネットワークI/F203は、通信回線を通じてネットワーク206に接続され、ネットワーク206を介して他の装置(たとえば、他の分散型PDSサーバ、ユーザ端末装置、データベース、あるいは、他のシステム)に接続される。そして、ネットワークI/F203は、ネットワーク206と自装置内部とのインターフェースを司り、他の装置からのデータの入出力を制御する。ネットワークI/F203には、たとえば、モデムやLANアダプタなどを採用することができる。
記録媒体I/F204は、CPU201の制御にしたがって記録媒体205に対するデータのリード/ライトを制御する。記録媒体205は、記録媒体I/F204の制御で書き込まれたデータを記憶する。記録媒体205としては、たとえば、磁気ディスク、光ディスクなどが挙げられる。
なお、分散型PDSサーバ100、150は、上述した構成部のほかに、たとえば、SSD(Solid State Drive)、キーボード、ポインティングデバイス、ディスプレイなどを有することにしてもよい。
また、ユーザ端末装置110、160は、たとえば、パーソナルコンピュータ、タブレット端末装置、スマートフォンなどによって実現される。また、ユーザ端末装置110、160は、図示は省略するが、CPU、メモリ、ディスプレイ、入力装置、通信装置などを有する。
(情報処理装置のセルの機能的構成)
図3は、実施の形態にかかる情報処理装置のセル101、151の機能的構成の一例を示すブロック図である。図3において、情報処理装置の一例である分散型PDSサーバ100、150の各セル(PDS)101、151は、関係性の設定に関する処理、ロール判定用条件の登録に関する処理、権限の設定に関する処理およびデータ取得時のアクセス制御に関する処理を実行する。
そのような処理を実行するために、各セル101、151は、関係性ルール304、アカウント関係性マップ305、ロール判定マップ306、データベース307、アカウントロールマップ308、ロール一覧309の各種テーブルあるいはデータを有するとともに、データ書込部311、関係性構築部312、ロール条件登録部313、ロール要求部314、ロール判定部315、関係性取得部316、状況取得部317、ユーザ承認部318、アクセス制御部319の各構成部を有する。各種テーブルあるいはデータの詳細な内容および各構成部の詳細な内容については後述する。
(関係性ルールの内容)
図4は、関係性ルール304のデータ構成の一例を示す説明図である。図4において、関係性ルール304は、関係性構築部312が、関係性を構築する際に用いるテーブルである。すなわち、関係性構築部312は、関係性ルール304に記憶されたルールに合致するときに関係性を構築(設定)する。
図4に示すように、関係性ルール304は、たとえば、「データパス」欄と、「条件」欄と、「対象」欄と、「関係性」欄を有する。各項目欄(カラム)によって形成されるフィールドに情報を記憶することで、関係性ルールがレコードとして登録される。関係性ルール304は、具体的には、たとえば、図2に示した記録媒体205などによってその機能を実現することができる。
「データパス」欄には、対象となるデータがあるパスに関する情報を記憶する。たとえば、関係性ルール304の上段において、対象となるデータがあるパスが『/meeting』であることを示している。「条件」欄には、関係性を構築(設定)するためのデータのパラメータ条件に関する情報を記憶する。たとえば、関係性ルール304の上段において、『approve』が『true』の場合に関係性を構築することを示している。ここで、パラメータ条件は、図示は省略するが、閾値であってもよい。すなわち、閾値を基準として、関係性の構築の是非を判断するようにしてもよい。
「対象」欄には、対象となるデータのキーに関する情報を記憶する。たとえば、関係性ルール304の上段においては、『organizer』が対象となるデータのキーであることを示し、この場合meetingの主催者のアカウント名が格納されるキーであることを示している。「関係性」欄には、構築する関係性に関する情報を記憶する。たとえば、関係性ルール304の上段において、構築する関係性が『Organizer(主催者)』であることを示している。
このように、関係性ルール304において、上段は、データパス:『/meeting』において、『approve』が『true』である場合に、キー:『organizer』に格納されているアカウントに対して『Organizer』という関係性を構築することを示している。また、下段は、データパス:『/life/medical/appointment』において、『doctorApproval』が『true』である場合に、キー:『doctor』に格納されているアカウントに対して『Doctor(医者)』という関係性を構築することを示している。これにより、関係性構築部312が関係性を構築するにあたり、どのような場合に関係性が構築されるか、その関係性の具体的な内容がわかる。
(アカウント関係性マップの内容)
図5は、アカウント関係性マップ305のデータ構成の一例を示す説明図である。図5において、アカウント関係性マップ305は、関係性構築部312によってデータの書込がおこなわれる、アカウントに関連付けされる(いわゆる紐づく)関係性の一覧テーブルである。
図5に示すように、アカウント関係性マップ305は、たとえば、「アカウント」欄と、「関係性」欄を有する。各項目欄(カラム)によって形成されるフィールドに情報を記憶することで、アカウント関係性マップがレコードとして登録される。アカウント関係性マップ305は、具体的には、たとえば、図2に示した記録媒体205などによってその機能を実現することができる。
「アカウント」欄には、ロールを紐付ける対象となるユーザを示すアカウントに関する情報を記憶する。たとえば、アカウント関係性マップ305の第1段において、対象となるアカウントが『Kani』というユーザであることを示している。「関係性」欄には、アカウントに対して紐付ける関係性に関する情報を記憶する。アカウント関係性マップ305の第1段において、アカウント:『Kani』に紐付けされた関係性が『Organizer』であることを示している。
同様に、アカウント:『Matsuzoe』に紐付けされた関係性が『Doctor』であり、アカウント:『Matsui』に紐付けされた関係性が『Boss(上司)』であり、アカウント:『Yamato』に紐付けされた関係性が『Home-Delivery(宅配業者)』であることを示している。
このように、アカウント関係性マップ305を参照することによって、アカウントがどのような関係性を備えているかがわかる。アカウント関係性マップ305は、権限の設定処理をする際に、ロール判定部315によって参照される。
(ロール判定マップの内容)
図6は、ロール判定マップ306のデータ構成の一例を示す説明図である。図6において、ロール判定マップ306は、ルールに合致するときにロールを付与するためのテーブルである。ロール判定マップ306へのデータの登録は、ロール条件登録部313によっておこなわれる。
図6に示すように、ロール判定マップ306は、たとえば、「ロール」欄と、「関係性条件」欄と、「状況条件」欄を有する。各項目欄(カラム)によって形成されるフィールドに情報を記憶することで、ロール判定マップがレコードとして登録される。ロール判定マップ306は、具体的には、たとえば、図2に示した記録媒体205などによってその機能を実現することができる。
「ロール」欄には、付与の対象となるロールに関する情報を記憶する。ロールとは、たとえば、許可された者(アカウント)がおこなうことができる権限の内容の総称である。たとえば、ロール判定マップ306の第1段において、ロールが『ReadAge(年齢に関する情報を取得する)』であることを示している。なお、ロールの内容の詳細については、後述する図9の「ロール一覧309」において、より詳細に説明する。
「関係性条件」欄には、当該ロールを許可する関係性に関する情報を記憶する。たとえば、ロール判定マップ306の第1段においては、関係性が『Family(家族)』である場合(すなわち『true』である場合)に、『ReadAge』の権限を許可することを示している。
「状況条件」欄には、参照するエンティティのパスと、パスに存在するデータの条件に関する情報を記憶(設定)する。たとえば、ロール判定マップ306の第1段においては、状況条件がなにも設定されていない(『[{}]』)ので、状況条件は存在せず、いかなる状況においても関係性条件さえ備えていれば、当該ロールを許可することを示している。
また、ロール判定マップ306の第2段においては、エンティティのパス:『・・・/Location』において、『distanceToHome:300、Date:“until the task finishes(自宅から300m以内で、配達が完了するまで)”』という条件(コンディション)を満たせば、関係性条件を備えている者(『Home-Delivery(宅配業者)』の関係性が設定されている者)に、該当するロール(『ReadTransferInformation(移動に関する情報を取得すること)』を許可することを示している。
このように、ロール判定マップ306を参照することによって、各ロールの関係性条件と状況条件とがわかる。ロール判定マップ306は,権限の設定処理をする際に、ロール判定部315によって参照される。
(データベースに格納されるデータの内容)
図7は、データベース307に格納されるデータの一例を示す説明図である。図7に示すように、データベース307には、各ユーザの各種の情報(パーソナルデータ)が格納される。このデータの内容が、状況取得部317によって参照(取得)され、その参照結果に基づいて、当該データにアクセス(書き込みあるいは読み出しなど)が許可されるか否かが決定される。
データベース307は、具体的には、たとえば、図2に示した記録媒体205などによってその機能を実現することができる。
(アカウントロールマップの内容)
図8は、アカウントロールマップ308のデータ構成の一例を示す説明図である。図8において、アカウントロールマップ308は、アカウントに関連付けされる(いわゆる紐づく)ロールの一覧テーブルである。アカウントロールマップ308は、ロール判定部315によって、データの書き換えがおこなわれる。
図8に示すように、アカウントロールマップ308は、たとえば、「アカウント」欄と、「ロール」欄を有する。各項目欄(カラム)によって形成されるフィールドに情報を記憶することで、アカウントロールマップがレコードとして登録される。アカウントロールマップ308は、具体的には、たとえば、図2に示した記録媒体205などによってその機能を実現することができる。
「アカウント」欄は、図5に示したアカウント関係性マップ305の「アカウント」欄と同じように、ロールを紐付ける対象となるユーザを示すアカウントに関する情報を記憶する。「アカウント」欄の具体的な内容については、図5に示したアカウント関係性マップ305と同様なので、その説明は省略する。また、「ロール」欄には、図6に示したロール判定マップ306の「ロール」欄と同じように、付与の対象となるロールに関する情報を記憶する。
これによって、アカウントロールマップ308を参照することによって、アカウントとそのアカウントに付与されるロールとの関係がわかる。アカウントロールマップ308は、データ取得時のアクセス制御の処理をおこなう際に、アクセス制御部319によって参照される。
(ロール一覧の内容)
図9は、ロール一覧309のデータ構成の一例を示す説明図である。図9において、ロール一覧309は、ロールの一覧を示すテーブルである。ロール一覧309は、たとえば、「ロール」欄と、「データパス」欄と、「権限レベル」欄を有する。各項目欄(カラム)によって形成されるフィールドに情報を記憶することで、ロール一覧がレコードとして登録される。ロール一覧309は、具体的には、たとえば、図2に示した記録媒体205などによってその機能を実現することができる。
「ロール」欄には、ロールに関する情報を記憶する。ロールとは、たとえば、許可された者(アカウント)がおこなうことができる権限の内容の総称などであるから、その詳細な内容について、「データパス」欄と、「権限レベル」欄に記憶する。
「データパス」欄には、対象となるデータが存在するパスに関する情報を記憶する。たとえば、ロール一覧309の第1段のロール:『ReadAge』の対象となる「Age」に関する情報は、「データパス」欄の『/profile/age』に存在することを示している。
「権限レベル」欄は、対象のデータに対して、どのような権限を与えるか、その内容に関する情報を記憶する。権限レベルが『read』であれば、取得する権限が与えられていることを示す。権限レベルは、『read』の他に、『write(書き込み)』や、『execute(プログラムなどの実行)』などがある。権限レベルが『all』であれば、『read』、『write』、『execute』などのすべてを含む権限が与えられていることを示す。
このように、ロール一覧309を参照することによって、どのような内容のロールが記憶されているかがわかる。ロール一覧309は、データ取得時のアクセス制御の処理をおこなう際に、アクセス制御部319によって参照される。
(関係性の設定)
図10は、セル101、151の関係性の設定にかかる機能的構成の一例を示すブロック図である。図10において、関係性の設定に際しては、セル101、151は、データ書込部311と、関係性構築部312などを用いる。すなわち、データ書込部311に、単純なPDS(セル101、105)への書き込みがおこなわれる。そして、データ書込部311は、関係性構築部312に対して、データの書込情報を伝達する。データ書込部311は、具体的には、たとえば、図2に示したネットワークI/F203などによってその機能を実現することができる。
関係性構築部312は、関係性ルール304においてあらかじめ定義されているルールにしたがって、自アカウントと他アカウントとの関係性を設定し、アカウント関係性マップ305に登録する。関係性構築部312は、具体的には、たとえば、CPU201、記録媒体I/F204などによってその機能を実現することができる。
図11は、データ書込部311の処理の手順の一例を示すフローチャートである。図11のフローチャートにおいて、データ書込部311は、データ情報を受信する(ステップS1101)。データ情報は、たとえば、同じ分散型PDSサーバ内の他のセル、他の分散型PDSサーバの他のセル、あるいは、ユーザ端末装置などから受信する。
つぎに、データ書込部311は、アクセス制御部319にアカウント情報を送信し(ステップS1102)、アクセス制御部319から判定結果を受信する(ステップS1103)。アクセス制御部319では、データ書込部311から送信されてきたアカウント情報が、アカウント関係性マップ305に対して関係性を書き込む(登録する)ことができる権限があるかを判定し、その判定結果をデータ書込部311へ送信する。
データ書込部311は、アクセス制御部から受信した判定結果がOK、すなわち書き込むことが許可された場合(ステップS1104:Yes)は、データに書込をする(ステップS1105)。具体的には、データ書込部311は、関係性構築部312に書込情報(データの変更情報)を伝達する。これにより、データ書込部311の一連の処理を終了する。一方、判定結果がOKでない、すなわち書き込むことが許可されなかった場合(ステップS1104:No)は、なにもせずに、一連の処理を終了する。
このようにして、PDS(セル101、105)への書き込みについて、データ書込部311が、関係性構築部312に対して、そのデータの書込情報を伝達することができる。
図12は、関係性構築部312の処理の手順の一例を示すフローチャートである。図12のフローチャートにおいて、関係性構築部312は、データの変更情報を受信する(ステップS1201)。そして、受信したデータの変更情報(書込情報)が、関係性ルール303にあらかじめ登録されている関係性ルールにマッチ(合致)する条件があるか否かを判断する(ステップS1202)。
ステップS1202において、マッチする条件がある場合(ステップS1202:Yes)は、アカウント関係性マップに、変更情報(書込情報)をアカウント関係性マップ305に登録し(ステップS1203)、一連の処理を終了する。一方、マッチする条件がない場合(ステップS1202:No)は、アカウント関係性マップ305への設定はおこなわず(ステップS1204)。一連の処理を終了する。
このようにして、関係性構築部312は、関係性ルール304にしたがって、自アカウントと他アカウントとの関係性を構築し、構築された内容を、アカウント関係性マップ305に登録することができる。
(ロール判定用条件の登録)
図13は、セル101、151のロール判定用条件の登録にかかる機能的構成の一例を示すブロック図である。図13において、ロール判定用条件の登録に際しては、セル101、151は、ロール条件登録部303などを用いる。すなわち、ロール条件登録部313は、たとえば、ユーザ端末装置110、160などから、ロールを自動設定するための判定条件をあらかじめ設定し、ロール判定マップ306に登録しておく。
ロール条件登録部313は、具体的には、図2に示したネットワークI/F203、記録媒体I/F204などによってその機能を実現することができる。
図14は、ロール条件登録部313の処理の手順の一例を示すフローチャートである。図14のフローチャートにおいて、ロール条件登録部313は、ロール条件を受信する(ステップS1401)。ロール条件は、たとえば、ユーザ端末装置110、160などから受信する。あるいは、同じ分散型PDSサーバ内の他のセル、他の分散型PDSサーバの他のセル、あるいは、ユーザ端末装置などからロール条件を受信するようにしてもよい。
そして、ロール条件登録部313は、受信したロール条件(「ロール」、とそれに対応する「関係性条件」および「状況条件」)をロール判定マップ306に登録する(ステップS1402)。これにより、ロール条件登録部313の一連の処理を終了する。このようにして、ロール条件登録部313は、ルールに合致するときにロールを付与するためのテーブルであるロール判定マップ306に、ロール条件である「関係性条件」および「状況条件」を登録することができる。
図15は、ロール条件の設定画面の一例を示す説明図である。図15に示す設定画面1500を、たとえば、ユーザ端末装置110、160に表示する。そして、各入力欄(たとえば、「ルート名」、「対象オブジェクト」、「対象イベント」、「対象条件」、「アクション」、「実行サービス」など)に所定の情報を入力し、登録ボタンを押下することによって、ロール情報をユーザ端末装置110、160からロール条件登録部313へ送信することができる。
設定のための、よく使われそうなテンプレートを提供しておいてもよい。また、設定の履歴はテンプレートとして使い回しをするようにしてもよい。あらかじめテンプレートに書かれたものだけを用意して、ユーザのワンタッチだけで自動設定されるようにしてもよい。
(権限の設定)
図16は、セル101、151の権限の設定にかかる機能的構成の一例を示すブロック図である。図16において、権限の設定に際しては、セル101、151のデータ要求側は、ロール要求部314を用いる。また、セル101、151のデータ返信側は、ロール判定部315、関係性取得部316、状況取得部317、ユーザ承認部318などを用いる。
ロール要求部314は、アカウント情報とロール情報とを受信し、ロール判定部315に対して、アカウント情報とロール情報とを送信する。ここで、ロール要求部314と、ロール判定部315とは、別のユーザ(セル/データ領域)を想定している。ロール要求部314は、具体的には、たとえば、図2に示したネットワークI/F203などによってその機能を実現することができる。
ロール判定部315は、ロール要求部314から送信されたアカウント情報とロール情報とを受信し、関係性と状況から適切なロールの判定をおこなう。ロール判定部315は、具体的には、たとえば、図2に示したCPU201、ネットワークI/F203、記録媒体I/F205などによってその機能を実現することができる。
関係性取得部316は、ロール判定部315からの要求によって、アカウント関係性マップ305から、該当するアカウントの関係性に関する情報を取得し、取得した情報をロール判定部315に送信する。関係性取得部316は、具体的には、たとえば、図2に示したCPU201、記録媒体I/F204などによってその機能を実現することができる。
状況取得部317は、ロール判定部315からの要求によって、データベース307から、状況に関する情報を取得し、取得した情報をロール判定部315に送信する。状況取得部317は、具体的には、たとえば、図2に示したCPU201、記録媒体I/F204などによってその機能を実現することができる。
ユーザ承認部318は、ロール判定部315からの要求によって、たとえばユーザ端末装置110から、ユーザの承認を求め、当該ユーザの承認の要否(承認する/承認しないなど)を得る。そして、得た承認の要否について、その旨をロール判定部315に送信する。ユーザ承認部318は、具体的には、たとえば、図2に示したCPU201などによってその機能を実現することができる。
図17は、ロール要求部314の処理の手順の一例を示すフローチャートである。図17のフローチャートにおいて、ロール要求部314は、アカウント情報とロール情報とを受信する(ステップS1701)。アカウント情報とロール情報は、たとえば、ユーザ端末装置110、160などから受信する。あるいは、同じ分散型PDSサーバ内の他のセル、他の分散型PDSサーバの他のセル、あるいは、ユーザ端末装置などからロール条件を受信するようにしてもよい。
つぎに、ロール要求部314は、ロール判定部315にアカウント情報とロール情報を送信する(ステップS1702)。このようにして、ロール要求部314では、(主に他者の)データにアクセスするためのロールを要求するために、ロールを与えてよいかを判定する(他者の)ロール判定部315を呼び出す。これにより、ロール要求部314の一連の処理を終了する。
このようにして、ロール要求部314は、他のユーザのセルのロール要求部314に対して、ロール判定の要求をすることができる。
図18は、ロール判定部315の処理の手順の一例を示すフローチャートである。図18のフローチャートにおいて、ロール判定部315は、ロール要求部314からアカウント情報とロール情報を受信する(ステップS1801)。つぎに、ロール判定マップ306から、対象となるロール情報に対する条件を取得する(ステップS1802)。そして、対象となるロールの条件が存在するか否かを判断する(ステップS1803)。ここで、対象となるロールの条件が存在しない場合(ステップS1803:No)は、ステップS1813へ移行する。
一方、ステップS1803において、対象となるロールの条件が存在する場合(ステップS1803:Yes)は、ロール条件を一時的に保管する(ステップS1804)。つぎに、ロール判定部315は、ロール条件に関係性情報が記載されているか否かを判断する(ステップS1805)。ここで、ロール条件に関係性情報が記載されていない場合(ステップS1805:No)は、ステップS1813へ移行する。
一方、ステップS1805において、ロール条件に関係性情報が記載されている場合(ステップS1805:Yes)は、関係性取得部316にアカウント情報を送信し(ステップS1806)、関係性取得部316から関係性情報を取得する(ステップS1807)。
つぎに、ロール判定部315は、ロール条件に状況情報を利用するか否かを判断する(ステップS1808)。ここで、ロール条件に状況情報を利用しない場合(ステップS1808:No)は、ステップS1811へ移行する。
一方、ステップS1808において、ロール条件に状況情報を利用する場合(ステップS1808:Yes)は、状況取得部317にロール条件を送信し(ステップS1809)、状況取得部317から状況情報を取得する(ステップS1810)。その後、ステップS1811へ移行し、判定処理を開始する(ステップS1811)。
そして、要求されている条件に、取得した関係性情報/状況情報が一致するか否かを判断する(ステップS1812)。ここで、要求されている条件に、取得した関係性情報/状況情報が一致する場合(ステップS1812:Yes)は、ステップS1815へ移行する。一方、要求されている条件に、取得した関係性情報/状況情報が一致しない場合(ステップS1812:No)は、ユーザ承認部318にアカウント情報とロール情報を送信する(ステップS1813)。
そして、確認結果がOKであるか否かを判断する(ステップS1814)。ここで、確認結果がOKではない場合(ステップS1814:No)は、設定が失敗したとして(ステップS1816)、一連の処理を終了する。一方、ステップS1814において、確認結果がOKである場合(ステップS1814:Yes)は、アカウントロールマップ308を更新し(ステップS1815)、一連の処理を終了する。
このようにして、ロール判定部315は、ロール要求部314から要求があったロールに対して当該要求したアカウントがロールに関する権限を有しているかを判定することができる。
図19は、関係性取得部316の処理の手順の一例を示すフローチャートである。図19のフローチャートにおいて、関係性取得部316は、アカウント情報とロール情報を取得する(ステップS1901)。アカウント情報とロール情報は、ロール判定部315から取得する(図18のステップS1806を参照)。
そして、アカウント関係性マップ305にマッチするアカウント情報があるか否かを判断する(ステップS1902)。ここで、マッチするアカウント情報がある場合(ステップS1902:Yes)は、関係性情報をロール判定部315に返信し(ステップS1903)、一連の処理を終了する。このようにして、ロール判定部315は、関係性取得部316から関係性情報を取得する(図18のステップS1807を参照)。
ステップS1902において、マッチするアカウント情報がない場合(ステップS1902:No)は、確認結果がNGであった旨をロール判定部315に返信し(ステップS1904)、一連の処理を終了する。
このようにして、関係性取得部316は、ロール判定部315からの要求によって、該当するアカウントの関係性に関する情報を取得し、取得した情報をロール判定部315に送信することができる。
図20は、状況取得部317の処理の手順の一例を示すフローチャートである。図20のフローチャートにおいて、状況取得部317は状況情報を受信する(ステップS2001)。状況情報は、ロール判定部315から受信する(図18のステップS1809を参照)。
つぎに、ロール条件(状況条件)から判定すべきデータパス一覧を取得する(ステップS2002)。そして、データパス上にデータがあるか否かを判断する(ステップS2003)。ここで、データパス上にデータがある場合(ステップS2003:Yes)は、当該データをロール判定部315に返信し(ステップS2004)、一連の処理を終了する。このようにして、ロール判定部315は、状況取得部317からデータを取得する(図18のステップS1810)を参照)。
ステップS2003において、データパス上にデータがない場合(ステップS2003:No)は、確認結果がNGであった旨をロール判定部315に返信し(ステップS2005)、一連の処理を終了する。
このようにして、状況取得部317は、ロール判定部315からの要求によって、データベース307から、状況に関する情報を取得し、取得した情報をロール判定部315に送信することができる。
図21は、ユーザ承認部318の処理の手順の一例を示すフローチャートである。図21のフローチャートにおいて、ユーザ承認部318は、アカウント情報とロール情報を受信する(ステップS2101)。アカウント情報とロール情報は、ロール判定部315から受信する(図18のステップS1813を参照)。
つぎに、ユーザに対して承認画面を表示し承認を得る(ステップS2102)。そして、確認結果がOKであるか否かを判断する(ステップS2103)。ここで、確認結果がOKである場合(ステップS2103:Yes)は、確認結果がOKである旨をロール判定部315に返信し(ステップS2104)、一連の処理を終了する。このようにして、ロール判定部315は、ユーザ承認部318から確認結果を取得し、その判断をおこなう(図18のステップS1814)を参照)。
ステップS2103において、確認結果がOKでない場合(ステップS2103:No)は、確認結果がNGであった旨をロール判定部315に返信し(ステップS2105)、一連の処理を終了する。
このようにして、ユーザ承認部318は、ロール判定部315からの要求によって、ユーザの承認を求め、当該ユーザの承認の要否に関する情報を取得し、取得した情報をロール判定部315に送信することができる。
(データ取得時のアクセス制御)
図22は、セル101、151のデータ取得時のアクセス制御にかかる機能的構成の一例を示すブロック図である。図22において、データ取得時のアクセス制御に際しては、セル101、151は、アクセス制御部319などを用いる。すなわち、アクセス制御部319は、たとえば、他のセルや、ユーザ端末装置110、160などからのアクセス要求に対して、データベース307のデータへのアクセスをしてもよいかを判断する。アクセス制御部319は、具体的には、図2に示したCPU201、ネットワークI/F203、記録媒体I/F204などによってその機能を実現することができる。
図23は、アクセス制御部319の処理の手順の一例を示すフローチャートである。図23のフローチャートにおいて、アカウント情報とアクセス情報を受信する(ステップS2301)。アカウント情報とアクセス情報は、たとえば、同じ分散型PDSサーバ内の他のセル、他の分散型PDSサーバの他のセル、あるいは、ユーザ端末装置などから受信する。また、アカウント情報とアクセス情報は、ユーザ端末装置110、160などから受信するようにしてもよい。
そして、アカウントロールマップ308にアカウントに紐づくロール情報が存在するか否かを判断する(ステップS2302)。ここで、該当するロール情報が存在しない場合(ステップS2302:No)は、判定結果がNGである旨を送信元に返信し(ステップS2308)、一連の処理を終了する。一方、ステップS2302において、該当するロール情報が存在する場合(ステップS2302:Yes)は、当該ロール情報をアカウントロールマップ308から取得する(ステップS2303)。
つぎに、ロール一覧309にロール情報詳細が存在するか否かを判断する(ステップS2304)。ここで、ロール情報詳細が存在しない場合(ステップS2304:No)は、判定結果がNGである旨を送信元に返信し(ステップS2308)、一連の処理を終了する。一方、ステップS2304において、ロール情報詳細が存在する場合(ステップS2304:Yes)は、当該ロール情報詳細をロール一覧309から取得する(ステップS2305)。
そして、アクセス情報がロール情報詳細のACL(Access Control List)設定にマッチするか否かを判断する(ステップS2306)。ここで、アクセス情報がロール情報詳細のACL設定にマッチしない場合(ステップS2306:No)は、判定結果がNGである旨を送信元に返信し(ステップS2308)、一連の処理を終了する。一方、ステップS2306において、アクセス情報がロール情報詳細のACL設定にマッチする場合(ステップS2306:Yes)は、判定結果がOKである旨を送信元に返信し(ステップS2307)、一連の処理を終了する。
これにより、判定結果がOKである場合は、PDSの該当するデータへのアクセスが可能となる。
このようにして、アクセス制御部319は、他のセルなどからのアクセス要求に対して、データベース307のデータへのアクセスをしてもよいかを判断することができる。
以上説明したように、本実施の形態によれば、個人ごとのデータ領域に格納されたユーザの個人データ(具体的にはたとえばPDSなど)にアクセスするにあたり、ユーザの個人データにアクセスするアカウントのユーザとの関係性と、アカウントがユーザの個人データにアクセスする状況とに基づいて、アカウントに対するユーザの個人データへのアクセス権限を制御することができる。
また、本実施の形態によれば、アカウントが関係性に関する条件を満たす場合に、アカウントに対してアクセス権限を認めるようにすることができる。また、アカウントによるアクセスが状況に関する条件を満たす、より具体的には、たとえば、ユーザの個人データに基づいて、アカウントによるアクセスが状況に関する条件を満たす場合に、アカウントに対してアクセス権限を認めるようにすることができる。また、さらに、ユーザの承認があった場合に、アクセス権限を認めるようにすることもできる。
また、本実施の形態によれば、アクセス権限と、アクセス権限に対応する関係性および条件に関する条件とを関連付けして記憶し、記憶された条件に基づいて、アクセス権限を制御することができる。
また、本実施の形態によれば、アカウントのユーザとの関係性を、あらかじめ定められたルールに基づいて構築し、構築されたアカウントのユーザとの関係性に関する情報に基づいて、アカウントが関係性に関する条件を満たすかを判断することができる。
このように構成することによって、本実施の形態は、データの保有者と利用者間の関係性や状況から動的にデータのアクセス権限を設定することができる。これにより、データの保有者が逐一承認することなく、あらかじめ設定しておいた条件(たとえば、関係性に関する条件、状況に関する条件)に合致する場合には、適切な関係性の利用者にのみデータの利用を動的に許可することができる。
なお、データの構成と関係性ルールは、テンプレートが用意されていてもよい。たとえば、打合せに対して主催者と参加者の関係性や、診療に対して患者と医者の関係性は一般的な考え方で、同様の関係性が構築されることは多くあるので、テンプレートとしてあらかじめ定義しておくようにしてもよい。
また、権限に応じて、データを公開する範囲を変えるだけでなく、公開されている情報を限定的な情報にフィルタリングしたり加工するようにしてもよい。たとえば、どこにいるか具体的な所在地(緯度経度など)までわかる情報としてもよく、単に、在宅/外出だけの情報に限定してもよい。
(実施例)
つぎに、具体的な実施例1~3の内容ついて説明する。実施例1は、宅配業者に在/不在情報を提供する処理を例に説明する。また、実施例2は、医療情報を提供する処理を例に説明する。また、実施例3は、上司と部下が打合せ情報を共有する処理を例に説明する。
各実施例では、たとえば、ロール要求部314によるロール要求をソーシャル機能の「メッセージ」とし、ロール判定部315を「ルールと判定スクリプト」によって実施するようにしてもよい。アプリケーションとしての処理として実行されるものは「実行スクリプト」と呼ぶ。ソーシャル機能の一つであるメッセージは、セル間でのコミュニケーションをおこなう仕組みであり、「ロールを要求」といったメッセージが可能である。
また、ルールは、データの変更やメッセージの送受信時に特定のスクリプトを処理するためのものである。スクリプトは、インタプリタ型の実行可能プログラムであってもよい。PDSのデータ取得やロールの設定など、PDSのクライアントとして動作することが可能である。ロール判定のために動作するものを「判定スクリプト」と呼び、それ以外を「実行スクリプト」と呼ぶ。
(実施例1:宅配業者に在/不在情報を提供する処理)
図24Aは、実施例1(宅配業者への在/不在情報の提供)にかかるユーザ(配達員)に設定されるデータの一例を示す説明図である。図24Aにおいて、ユーザである「配達員」のPDS2401に対しては、たとえば、以下のような関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「配達員」のPDS2401には、配達客Aに対して『客』という関係性が設定されている。また、「配達員」のPDS2401には、配達客Aに対して、『宅配情報のWrite(書込)権限』を与えるというロールが設定されている。また、「配達員」のPDS2401には、『通知スクリプト』が設定され、『宅配情報が変更されたら通知スクリプトを呼ぶルール』が設定されている。
図24Bは、実施例1にかかるユーザ(配達客A)に設定されるデータの一例を示す説明図である。図24Bにおいて、ユーザである「配達客A」のPDS2402に対しては、図24Aに示した「配達員」と同様に、関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「配達客A」のPDS2402には、配達員に対して『宅配業社』という関係性が設定されている。また、「配達客A」のPDS2402には、配達員に対して、『在宅情報のRead(取得)権限』、『帰宅状況のRead権限』を与えるというロールが設定されている。また、「配達客A」のPDS2402には、『在宅確認スクリプト』、『帰宅状況確認スクリプト』、『自動承認スクリプト』が設定され、『定期的に在宅確認や帰宅確認スクリプトを実行するルール』が設定されている。
図25(図25A~図25E)は、実施例1(宅配業者への在/不在情報の提供)の処理の一例を説明する説明図(その1~その5)である。
図25Aは、宅配業者に在/不在情報を提供する際の前提について示している。図25Aにおいて、宅配業社の配達員のPDS2501に対して、宅配業社のアプリケーションのインストール時や運送依頼時に配達客Aの情報を登録する。同時に関係性を設定し、該当する宅配情報のWrite権限も付与する(ステップS2511)。また、処理する実行スクリプトとして、通知スクリプトを配備する(ステップS2512)。
一方、配達客AのPDS2502に対して、宅配業社のアプリケーションのインストール時に宅配業社との関係性はあらかじめ設定しておく(ステップS2513)。すなわち、アカウントに関係性情報を紐づけしておく。また、設定するロールとして、在宅状況の
Read権限と、帰宅状況のRead権限とを自動配備する(ステップS2514)。また、処理するスクリプトとして、在宅確認スクリプトと、帰宅状況確認スクリプトと、関係性が定義されたアカウントからのメッセージは自動承認する判定スクリプトとを配備する(ステップS2515)。さらに、起動ルールとして、定期的に在宅確認や、帰宅状況確認をするスクリプトを動かすルールを配備する(ステップS2516)。
図25Bは、宅配業者に在/不在情報を提供する際の基本動作について示している。図25Bにおいて、宅配業社の配達員のPDS2501は、運送依頼登録で、配達客Aに承認依頼メッセージを配達客AのPDS2502に送信する(ステップS2521)。また、配達客Aの宅配情報のWrite権限は宅配情報登録時にあらかじめ設定されている(ステップS2522)。
一方、配達客AのPDS2502は、承認依頼メッセージの受信時に、判定スクリプトで配達員の関係性を確認し、配達員に在宅情報のRead権限を付与する(ステップS2523)。配達客AのPDS2502は、具体的な居場所は提供しない(ステップS2524)。そして、自宅の在・不在情報を、宅配業社の配達員のPDS2501の宅配情報に書き込む(ステップS2525)。
図25Cは、宅配業者に在/不在情報を提供する処理における、在・不在変化時の通知の処理について示している。図25Cにおいて、宅配業社の配達員のPDS2501は、あらかじめ通知を受け取る端末(配達員のスマートフォン2530)を登録しておく(ステップS2531)。そして、宅配情報が書き込まれると、在・不在変更時に端末に通知するスクリプトを実行する(ステップS2532)。それにより、在・不在に変化があったら、配達員のスマートフォン2530にリアルタイムに通知される(ステップS2533)。
図25Dは、宅配業者に在/不在情報を提供する処理における、動的な情報の公開の処理について示している。図25Dにおいて、宅配業社の配達員のPDS2501は、配達客A宅に近づいたら、公開範囲を広げてもらうように、配達客AのPDS2502に承認依頼をする(ステップS2541)。そして、配達客A宅の3km範囲内に近づいた旨を宅配情報に登録する(ステップS2542)。
一方、配達客AのPDS2502は、判定スクリプトで関係性に加え、配達員が近くに存在している状況を判定し、宅配業社の配達員のPDS2501に帰宅状況のRead権限を付与する(ステップS2543)。つぎに、自宅から300m範囲内で、自宅に向かっている=もうすぐ帰宅する旨を帰宅情報に登録する(ステップS2544)。そして、その帰宅情報を、宅配業社の配達員のPDS2501の宅配情報に書き込む(ステップS2545)。
図25Eは、宅配業者に在/不在情報を提供する処理における、情報の削除の処理について示している。図25Eにおいて、宅配業社の配達員のPDS2501は、配達完了時には、配達客AのPDS2502にロール削除依頼メッセージを送信する(ステップS2551)。
一方、配達客AのPDS2502は、ロール削除依頼メッセージの受信時における自動承認で、宅配業社の全てのRead権限を削除する(ステップS2552)。これによって、宅配業社の配達員のPDS2501は、配達客Aの情報は見られなくなる(ステップS2553)。
以上説明したように、実施例1では、配達日になると、配達客Aの在宅状況を確認できるようにする。また、配達時間と、配達客A宅に近いということと、不在(配達客Aは近く)という条件が重なった場合には、もうすぐ帰宅する旨を確認できるようにする。これにより、宅配業社の配達員は、実際に客先まで配達することなく、その情報から配達すべきかどうかを判断できるようになる。
(実施例2:医療情報を提供する処理)
図26Aは、実施例2(医療情報の提供)にかかるユーザ(医者)に設定されるデータの一例を示す説明図である。図26Aにおいて、ユーザである「医者」のPDS2601に対しては、たとえば、以下のような関係性およびロールが設定されている。すなわち、「医者」のPDS2601には、患者Aに対して『患者』という関係性が設定されている。
また、「医者」のPDS2601には、患者Aに対して、『予約情報のWrite権限』を与えるというロールが設定されている。図26Aにおいては、「医者」のPDS2601には、スクリプト、ルール一覧は設定されていない。
図26Bは、実施例2にかかるユーザ(患者A/急病人)に設定されるデータの一例を示す説明図である。図26Bにおいて、ユーザである「患者A/急病人」のPDS2602に対しても、実施例1と同様に、関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「患者A/急病人」のPDS2602には医者に対して『担当医』という関係性が設定されている。
また、「患者A/急病人」のPDS2602には、医者に対して、『個人情報のRead権限』を与えるというロールとともに、第三者(緊急時)に対して、『個人情報のRead権限』を与えるというロールが設定されている。また、「患者A/急病人」のPDS2602には、『判定スクリプト』が設定され、『メッセージ受信時に自動承認するルール』が設定されている。
図27Aおよび図27Bは、実施例2(医療情報の提供)の処理の一例を説明する説明図である。図27Aは、通常時の医療情報の提供の処理について示している。図27Aにおいて、患者AのPDS2702は、まず、担当医にデータ公開を許容する判定スクリプトを用意する。そして、メッセージ受信時に自動承認する判定スクリプトを発火(実行)するよう設定する。つぎに、患者は、診察を受けるために予約を入れる。もしくは診察を受付で申し込む。
一方、医者のPDS2701は、患者からの診療の予約あるいは診察申し込みを承認する。これによって、患者と医者の関係性(「医者:担当医」)」が自動的に構築される(ステップS2711)。そして、医者のPDS2701は、診察時間に、診察中に患者の病歴や生活習慣を見るための権限取得要求メッセージを送信する(ステップS2712)。
これに対して、患者AのPDS2702は、権限取得要求メッセージ受信に対応して自動承認する判定スクリプトを発火し、ステップS2712において構築された関係性(患者と医者)を判断し、医者との関係付けをおこなう(ステップS2713)。その後、医者のPDS2701に対して個人情報へのRead(取得)権限を付与する(ステップS2714)。これにより、医者のPDS2701は、個人情報取得権限が自動で設定され、診察に利用するための個人情報にアクセス可能になる。また、診察終了時、医者に対する権限と関係性(患者と医者)を破棄する。
図27Bは、緊急時の医療情報の提供の処理について示している。図27Bにおいて、第三者のPDS2703は、急病人の情報端末装置150などから、たとえば、特定のQRコード(登録商標)を取得し、関係性を構築する(ステップS2721)。そして、第三者のPDS2703は、すぐさま情報公開の承認要求メッセージを急病人のPDS2704へ送信する(ステップS2722)。
これに対して、急病人のPDS2704は、ヘルスケア情報が正常値ではない=倒れてしまったような大事が起こった場合、関係性は「医者:担当医」に限らない。特定のQRコードで得られたデータと一致すれば、自動承認で個人情報のRead権限に関するロールを許可する(ステップS2723)。そして、緊急事態のメッセージでは、関係性に関わらず、その場にいて救助してくれた人に個人情報へのRead権限を付与する(ステップS2724)。第三者のPDS2702は、個人情報取得権限を自動で設定され、診察に利用するための個人情報にアクセス可能になる。
このように、突然倒れてしまったような緊急時には、特定のQRコードを取得するなどして、個人情報を全公開することができる。
(実施例3:上司と部下の打合せ予定情報の共有)
図28Aは、実施例3(上司と部下の打合せ予定情報の共有)にかかるユーザ(上司)に設定されるデータの一例を示す説明図である。図28Aにおいて、ユーザである「上司」のPDS2801に対しては、たとえば、以下のような関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「上司」のPDS2801には、部下Aに対して『同僚・部下』という関係性が設定されている。また、「上司」のPDS2801には、部下Aに対して、『予定のRead権限』を与えるというロールが設定されている。
また、「上司」のPDS2801には、『予定書き込みスクリプト』、『判定スクリプト』、『10分前通知スクリプト』が設定されている。また、『予定を追加したらメンバ(部下)の予定を書き込む(ルール)』、『予定を変更したら通知する(ルール)』、『関係性が定義されたアカウントからのメッセージ受信時には自動承認する(ルール)』、『開始10分前を通知する(ルール)』というルールが設定されている。
図28Bは、実施例3にかかるユーザ(部下A)に設定されるデータの一例を示す説明図である。図28Bにおいて、ユーザである「部下A」のPDS2802には、上司に対して『同僚・主催者』という関係性が設定されている。また、「部下A」のPDS2802には、上司に対して、『予定のRead/Write権限』、『居場所のRead権限』、『資料のRead権限』を与えるというロールが設定されている。また、「部下A」のPDS2802には、『通知スクリプト』、『判定スクリプト』が設定され、『資料を更新したら上司の予定情報を更新するルール』が設定されている。
図29(図29A~図29D)は、実施例3(上司と部下の打合せ予定情報の共有)の処理の一例を説明する説明図である。図29Aにおいて、上司のPDS2901と部下AのPDS2902は、あらかじめ「同僚社員」という関係性を持っている。上司のPDS2901は、会議メンバ登録で、部下Aに承認依頼メッセージを送信する(ステップS2911)。より具体的には、上司のPDS2901は、自身の打合せ予定の書き込み時に、打合せ予定のメンバに予定情報を読み書きする権限要求メッセージの送信と、同打合せ情報の書き込みをおこなうルールとスクリプトを登録する。
一方、部下AのPDS2902は、同僚社員に打合せ予定情報のRead権限を与えるための、判定スクリプトを用意する。そして、メッセージ受信時に自動承認する判定スクリプトを発火するルールを登録する。また、上司を主催者として関係付けをおこなう(ステップS2912)。
つぎに、上司のPDS2901は、部下Aをメンバに含んで予定を書き込むことによって、ルールにしたがって、部下Aに対して権限要求メッセージを送信する。部下Aは、この権限要求メッセージを自動承認し、上司に打合せ予定情報のRead権限を付与する(ステップS2913)。上司のPDS2901は、続けて、部下Aの予定情報に打合せ予定情報を書き込む(ステップS2914)。さらに、通知用のスクリプトを用意すれば、部下Aのスマートフォン2910へ通知することも可能となる。
このように、メンバを指定して打合せを設定すると、メンバに打合せが通知され、打合せを同期するスクリプトが動作する。これにより、上司と部下Aの予定情報が共有されることになる。部下BのPDS2903に対しても、部下AのPDS2902と同様に設定することができる。
図29Bにおいて、部下AのPDS2902は、打合せの変化を通知してもらうためのルールの登録依頼を上司のPDS2901に対しておこなう(ステップS2921)。これに対して、上司のPDS2901は、メッセージ受信時に判定スクリプトで自動承認しルール登録する(ステップS2922)。そして、打合せの予定変更時には部下AのPDS2902に通知する(ステップS2923)。
このように、打合せの変化を通知してもらうためのルールを上司側に設定依頼する。これにより、状況の動的変化に対しても、確実に情報共有をすることができる。部下BのPDS2903に対しても、部下AのPDS2902と同様に設定することができる。
図29Cにおいて、上司のPDS2901は、打合せ資料置き場の変化を通知してもらうためにルールを登録するように、部下AのPDS2902に対して依頼する(ステップS2931)。これに対して、部下AのPDS2902は、メッセージ受信時に自動承認でルールを登録する(ステップS2932)。これよって、上司のPDS2901は、部下Aの資料の完成具合を把握できるようになる(ステップS2933)。
このように、上司側からメンバの打合せ用資料置き場などの変化を通知してもらうためにメンバ側にルールの設定を依頼することもできる。部下BのPDS2903に対しても、部下AのPDS2902と同様に設定することができる。
図29Dにおいて、上司のPDS2901は、打合せ10分前をメンバ(部下AのPDS2902を含む)に通知する(ステップS2941)。これに対して、部下AのPDS2942は、打合せ10分前の通知を受けて居場所情報を上司に公開する(ステップS2942)。
これにより、打合せ10分前をメンバに通知することで、打合せ10分前からは、メンバの居場所がより詳細に提供されるようにすることができる。部下BのPDS2903に対しても、部下AのPDS2902と同様に設定することができる。
図30(図30A~図30D)は、セルの機能的構成を用いた、実施例3の処理の一例を説明する説明図である。図30Aは、予定の書込までの流れを示している。図30Aにおいて、セルA3000は、ユーザA(主催者)のセルPDSであり、セルB3050は、ユーザB(参加者)のセルPDSである。また、ユーザA(主催者)とユーザB(参加者)とは『同僚社員』という関係性が構築されている。
(1)ユーザA(主催者)は、セルA3000のデータ書込部3311に、打合せの予定を書き込む。データ書込部3311に書き込まれた打合せの予定は、予定(のデータベース)3201に記憶されるとともに、ロール要求部3314に送信される。
(2)ロール要求部3314は、セルB3050のロール判定部3355に対して、ユーザA(主催者)のアカウント情報とロール情報を送信し、予定の取得および書込権限(予定R/W権限)を要求する。ロール判定部3355は、関係性取得部3356に対して、関係性の取得要求を送信する。関係性取得部3356は、関係性の取得要求を受信すると、関係性(のデータベース(アカウント関係性マップ))3252に、マッチするアカウント情報があるかを判断する。
(3)アカウント関係性マップ(関係性)3252において、マッチするアカウント情報がある、すなわち、ユーザA(主催者)のアカウントが「同僚社員」の関係性を持つことがわかったので、関係性取得部3356は、その旨をロール判定部3355に返信する。
(4)ロール判定部3355は、同僚社員は予定R/W権限を付与可能であることを確認し、ユーザAに権限を付与する。具体的には、ロール(のデータベース(アカウントロールマップ)3253にアカウント(ユーザA)とロール(予定R/W権限)とを紐付けするように更新する。
(5)セルA3000のデータ書込部3311は、書き込まれた打合せの予定と同じ予定をユーザBに書き込もうとすると、セルB3050のアクセス制御部3359が、そのアクセス(書込)を許可するか否かを判断する。アクセス制御部3359は、ロール(のデータベース(アカウントロールマップおよびロール一覧))3253にアクセスして、確認する。
(6)アクセス制御部3359は、ロール3253に確認した結果、ユーザAが予定R/W権限を持つことが判明するので、書込を許可し、ユーザAから書き込まれた打合せの予定をセルB3050の予定(のデータベース)3251に記憶する。
図30Bは、関係性の更新について示している。図30Bにおいても、図30Aと同様に、セルA3000は、ユーザA(主催者)のセルPDSであり、セルB3050は、ユーザB(参加者)のセルPDSである。また、ユーザA(主催者)は、ユーザB(参加者)との間において『主催者』という関係性が構築されている。
(1)ユーザB(参加者)は、打合せ参加を承認する旨の情報を、自らのセルであるセルB3050のデータ書込部3361に書き込む。データ書込部3361に書き込まれた打合せ参加を承認する旨の情報は、予定(のデータベース)3251に記憶されるとともに、関係性構築部3352に送信される。
(2)関係性構築部3352は、関係性として、ユーザA(主催者)を『主催者』として設定し、関係性(のデータベース)3252に記憶する。このようにして、セルB3050における関係性(のデータベース)3252を更新することができる。
図30Cは、打合せ資料の共有について示している。図30Cにおいても、図30A、図30Bと同様に、セルA3000は、ユーザA(主催者)のセルPDSであり、セルB3050は、ユーザB(参加者)のセルPDSである。また、ユーザA(主催者)は、ユーザB(参加者)との間において『主催者』という関係性が構築されている。
(1)ユーザA(主催者)からの指示により、セルA3000のロール要求部3314は打合せ資料のREAD権限を、セルB3050のロール判定部3355に対して要求する。
(2)ロール要求部3314は、セルB3050のロール判定部3355に対して、ユーザA(主催者)のアカウント情報とロール情報を送信し、打合せ資料のREAD権限を要求する。ロール判定部3355は、関係性取得部3356に対して、関係性の取得要求を送信する。関係性取得部3356は、関係性の取得要求を受信すると、関係性(のデータベース(アカウント関係性マップ))3252に、マッチするアカウント情報があるかを判断し、ユーザA(主催者)が『主催者』の関係性を有する旨をロール判定部3355に返信する。ロール判定部3355は、その返信を受けて、ユーザA(主催者)に打合せ資料のREAD権限を与え、ロール(のデータベース(アカウントロールマップ)3253にアカウント(ユーザA)とロール(打合せ資料のREAD権限)とを紐付けするように更新する。
(3)つぎに、ユーザA(主催者)が、ユーザB(参加者)の打合せ資料の取得(読込)を、セルA3000のデータ読込部3321に要求すると、データ読込部3321は、セルB3050のアクセス制御部3359に対して、打合せ資料の取得を要求する。アクセス制御部3359は、ロール3253を参照して、ユーザA(主催者)が、打合せ資料のREAD権限を有していることを確認し、データベース3254に記憶されている打合せ資料を取得(読込)し、セルA3000のデータ読込部3321へ送信する。これによって、ユーザA(主催者)は、打合せ資料を取得することができ、打合せ資料の共有が実現する。
このように、打合せ資料を共有するように構成することによって、データを公開する側の情報(状況)が変化して、データや権限を変えることができる。主催者は、参加者全員の準備ができ次第、打合せの日程を決定するために、参加者の資料が公開されたら日付決定処理をするように条件を設定しておくことができる。また、参加者は、資料の作成完了時に主催者に資料を公開することができる。
また、主催者のもとに、参加者全員からの資料公開がなされれば、日付決定処理がおこなわれるようにすることができる。また、ある一定期間待っても資料が公開されない場合は、公開されていない参加者に通知をおこなったり、参加者打合せの開催の延期をおこなうことができる。
図30Dは、10分前の居場所の共有について示している。図30Dにおいても、図30A~図30Cと同様に、セルA3000は、ユーザA(主催者)のセルPDSであり、セルB3050は、ユーザB(参加者)のセルPDSである。また、ユーザA(主催者)は、ユーザB(参加者)との間において『主催者』という関係性が構築されている。
(1)ロール要求部3314は、セルB3050のロール判定部3355に対して、ユーザA(主催者)のアカウント情報とロール情報を送信し、10分前に居場所の取得する権限を要求する。
(2)ロール判定部3355は、関係性取得部3356に対して、関係性の取得要求を送信する。関係性取得部3356は、関係性の取得要求を受信すると、関係性(のデータベース(アカウント関係性マップ))3252に、マッチするアカウント情報があるかを判断し、ユーザA(主催者)が『主催者』の関係性を有する旨をロール判定部3355に返信する。ロール要求部3355は、その返信を受けて、ユーザA(主催者)に10分前に居場所の取得する権限を与え、ロール(のデータベース(アカウントロールマップ)3253にアカウント(ユーザA)とロール(10分前に居場所の取得する権限)とを紐付けするように更新する。
(3)つぎに、ユーザA(主催者)が、ユーザB(参加者)の居場所の取得(読込)を、セルA3000のデータ読込部3321に要求すると、データ読込部3321は、セルB3050のアクセス制御部3359に対して、居場所の取得を要求する。アクセス制御部3359は、ロール3253を参照して、ユーザA(主催者)が、10分前に居場所の取得する権限を有していることを確認し、データベース3254に記憶されている居場所に関する情報を取得(読込)し、セルA3000のデータ読込部3321へ送信する。これによって、ユーザA(主催者)は、ユーザB(参加者)の居場所を取得することができ、10分前の居場所の共有が実現する。
このように、打合せ10分前の居場所を共有するように構成することによって、たとえば、部下は、打合せ予定の参加を承認すると依頼主を主催者として関係性を構築するルールとスクリプトを設定することができる。部下が、上司からの予定の参加を承認する。それにともなって、そのルールにより依頼主を主催者として関係性を設定することができる。
また、上司が、打合せ10分前に、居場所情報の権限取得要求メッセージを送信すると、部下は、メッセージ受信に対応して自動承認スクリプトを発火し、関係性(主催者)を判断したのち、権限を自動承認することができる。これにより、上司は、居場所情報取得権限を自動で設定され、部下の居場所情報にアクセス可能になる。また、打合せ終了時には、上司に対する権限と関係性(打合せ主催者)を破棄することができる。
なお、本実施の形態で説明した情報処理方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。表示制御プログラムは、ハードディスク、フレキシブルディスク、CD(Compact Disc)-ROM、MO(Magneto-Optical Disk)、DVD(Digital Versatile Disk)、USB(Universal Serial Bus)メモリなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、表示制御プログラムは、インターネットなどのネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
(付記1)個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、
前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御する、
制御部を有することを特徴とする情報処理装置。
(付記2)前記制御部は、前記アカウントが前記関係性に関する条件を満たす場合に、前記アカウントに対して前記アクセス権限を認めることを特徴とする付記1に記載の情報処理装置。
(付記3)前記制御部は、前記アカウントによるアクセスが前記状況に関する条件を満たす場合に、前記アカウントに対して前記アクセス権限を認めることを特徴とする付記1または2に記載の情報処理装置。
(付記4)前記制御部は、前記ユーザの個人データに基づいて、前記アカウントによるアクセスが前記状況に関する条件を満たすかを判断することを特徴とする付記3に記載の情報処理装置。
(付記5)前記制御部は、前記ユーザの承認があった場合に、前記アクセス権限を認めることを特徴とする付記2~4のいずれか一つに記載の情報処理装置。
(付記6)前記制御部は、前記アクセス権限と、前記アクセス権限に対応する前記関係性および前記条件に関する条件とを関連付けして記憶し、
記憶された前記条件に基づいて、前記アクセス権限を制御することを特徴とする付記1~5のいずれか一つに記載の情報処理装置。
(付記7)前記制御部は、前記アカウントの前記ユーザとの関係性を、あらかじめ定められたルールに基づいて構築し、
構築された前記アカウントの前記ユーザとの関係性に関する情報に基づいて、前記アカウントが前記関係性に関する条件を満たすかを判断することを特徴とする付記2に記載の情報処理装置。
(付記8)第1のサーバから、第2のサーバの個人ごとのデータ領域に格納されたユーザの個人データに、ネットワークを介してアクセスするにあたり、
前記第2のサーバは、前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御することを特徴とする情報処理システム。
(付記9)前記第2のサーバは、前記アクセス権限と、前記アクセス権限に対応する前記関係性および前記条件に関する条件とを関連付けして記憶し、
記憶された前記条件に基づいて、前記アクセス権限を制御することを特徴とする付記8に記載の情報処理システム。
(付記10)個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、
前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。