JP7013807B2 - 情報処理装置、情報処理システムおよび情報処理プログラム - Google Patents

Description

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

従来、ネットワーク上に分散して存在するパーソナルデータ（個人情報）を本人のコントロールのもとに収集して様々なサービス間を流通させ利活用（利用・活用）を図ることができる仕組み、また、そのような機能を提供するクラウド上のサービスや、サービスを提供する装置またはシステムである「パーソナルデータストア（ＰＤＳ：Ｐｅｒｓｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）」が存在する。

関連する先行技術としては、提供するサービス上の他の装置で認証を受けたユーザの役割を適切に決定できるようにする技術がある（たとえば、下記特許文献１を参照。）。また、役割情報を含む認証トークンを用いることで、より効率的にサービスを提供する技術がある（たとえば、下記特許文献２を参照。）。

特開２０１３－１８２４６０号公報 国際公開第２０１５／１２５２９０号

しかしながら、従来技術では、個人ごとにデータ領域を持っている場合で、データの利用者とデータの保有者が異なる場合、データの保有者から利用者に対してアクセス権限を付与しないと、保有者のデータを利用することができない。したがって、データの利用者がアクセス権限を要求し、それに対して保有者が承認することで利用可能な権限が付与されることとなる。このように、アクセス権限の要求に対して、保有者が逐一承認するのは煩雑であるという問題点がある。

一つの側面では、本発明は、個人データの利活用を効率化することを目的とする。

一つの実施態様では、個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御する情報処理装置、情報処理システムおよび情報処理プログラムが提供される。

本発明の一側面によれば、個人データの利活用を効率化することができる。

図１は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。 図２は、実施の形態にかかる情報処理装置のハードウェア構成の一例を示すブロック図である。 図３は、実施の形態にかかる情報処理装置のセル１０１、１５１の機能的構成の一例を示すブロック図である。 図４は、関係性ルール３０４のデータ構成の一例を示す説明図である。 図５は、アカウント関係性マップ３０５のデータ構成の一例を示す説明図である。 図６は、ロール判定マップ３０６のデータ構成の一例を示す説明図である。 図７は、データベース３０７に格納されるデータの一例を示す説明図である。 図８は、アカウントロールマップ３０８のデータ構成の一例を示す説明図である。 図９は、ロール一覧３０９のデータ構成の一例を示す説明図である。 図１０は、セル１０１、１５１の関係性の設定にかかる機能的構成の一例を示すブロック図である。 図１１は、データ書込部３１１の処理の手順の一例を示すフローチャートである。 図１２は、関係性構築部３１２の処理の手順の一例を示すフローチャートである。 図１３は、セル１０１、１５１のロール判定用条件の登録にかかる機能的構成の一例を示すブロック図である。 図１４は、ロール条件登録部３１３の処理の手順の一例を示すフローチャートである。 図１５は、ロール条件の設定画面の一例を示す説明図である。 図１６は、セル１０１、１５１の権限の設定にかかる機能的構成の一例を示すブロック図である。 図１７は、ロール要求部３１４の処理の手順の一例を示すフローチャートである。 図１８は、ロール判定部３１５の処理の手順の一例を示すフローチャートである。 図１９は、関係性取得部３１６の処理の手順の一例を示すフローチャートである。 図２０は、状況取得部３１７の処理の手順の一例を示すフローチャートである。 図２１は、ユーザ承認部３１８の処理の手順の一例を示すフローチャートである。 図２２は、セル１０１、１５１のデータ取得時のアクセス制御にかかる機能的構成の一例を示すブロック図である。 図２３は、アクセス制御部３１９の処理の手順の一例を示すフローチャートである。 図２４Ａは、実施例１（宅配業者への在／不在情報の提供）にかかるユーザ（配達員）に設定されるデータの一例を示す説明図である。 図２４Ｂは、実施例１にかかるユーザ（配達客Ａ）に設定されるデータの一例を示す説明図である。 図２５Ａは、実施例１（宅配業者への在／不在情報の提供）の処理の一例を説明する説明図（その１）である。 図２５Ｂは、実施例１の処理の一例を説明する説明図（その２）である。 図２５Ｃは、実施例１の処理の一例を説明する説明図（その３）である。 図２５Ｄは、実施例１の処理の一例を説明する説明図（その４）である。 図２５Ｅは、実施例１の処理の一例を説明する説明図（その５）である。 図２６Ａは、実施例２（医療情報の提供）にかかるユーザ（医者）に設定されるデータの一例を示す説明図である。 図２６Ｂは、実施例２にかかるユーザ（患者Ａ／急病人）に設定されるデータの一例を示す説明図である。 図２７Ａは、実施例２（医療情報の提供）の処理の一例を説明する説明図（その１）である。 図２７Ｂは、実施例２の処理の一例を説明する説明図（その２）である。 図２８Ａは、実施例３（上司と部下の打合せ予定情報の共有）にかかるユーザ（上司）に設定されるデータの一例を示す説明図である。 図２８Ｂは、実施例３にかかるユーザ（部下Ａ）に設定されるデータの一例を示す説明図である。 図２９Ａは、実施例３（上司と部下の打合せ予定情報の共有）の処理の一例を説明する説明図（その１）である。 図２９Ｂは、実施例３の処理の一例を説明する説明図（その２）である。 図２９Ｃは、実施例３の処理の一例を説明する説明図（その３）である。 図２９Ｄは、実施例３の処理の一例を説明する説明図（その４）である。 図３０Ａは、セルの機能的構成を用いた、実施例３の処理の一例を説明する説明図（その１）である。 図３０Ｂは、セルの機能的構成を用いた、実施例３の処理の一例を説明する説明図（その２）である。 図３０Ｃは、セルの機能的構成を用いた、実施例３の処理の一例を説明する説明図（その３）である。 図３０Ｄは、セルの機能的構成を用いた、実施例３の処理の一例を説明する説明図（その４）である。

以下に図面を参照して、本発明にかかる情報処理装置、情報処理システムおよび情報処理プログラムの実施の形態を詳細に説明する。

（実施の形態）
（システム構成例）
図１は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。

図１において、実施の形態にかかる情報処理システムは、分散型ＰＤＳ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）サーバ１００、１５０を含む複数の分散型ＰＤＳサーバと、ユーザ端末装置１１０、１６０を含む複数のユーザ端末装置から構成される。複数の分散型ＰＤＳサーバと、ユーザ端末装置が、ネットワーク（たとえば、図２に示すネットワーク２０６）によって接続されることにより、システムを構成する。また、各分散型ＰＤＳサーバは、ネットワークを介して、図示を省略する他のシステムと通信をすることができる。複数の分散型ＰＤＳサーバは、具体的には、たとえばＷｅｂ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバなどのサーバであってもよい。

分散型ＰＤＳサーバ１００、１５０が、実施の形態にかかる情報処理装置を構成するようにしてもよい。分散型ＰＤＳサーバ１００、１５０は、各ユーザのＰＤＳ１０１、１５１を備え、提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）として、パーソナルデータ管理機能１０２、１５２と、ソーシャル管理機能１０３、１５３と、を備えている。

パーソナルデータ管理機能１０２、１５２は、ユーザのパーソナルデータを管理するために、セル管理機能（利用者のパーソナルデータを管理する機能）や、ボックス管理機能（利用者のパーソナルデータをアプリケーションや用途毎の領域に管理する機能）を有する。

セル管理機能には、たとえば、セル設定（利用者のパーソナルデータ領域の登録／参照／変更／削除／一覧参照）、アカウント設定（利用者のパーソナルデータ領域に属するアカウントの登録／参照／変更／削除／一覧参照）、認証（利用者の認証）、ロール設定（利用者の役割を登録／参照／変更／削除／一覧参照）、ボックス設定（アプリケーション毎のデータ領域の登録／参照／変更／削除／一覧参照）、アクセス制御（利用者や利用者フォルダへのアクセス権の設定／参照／変更）、イベント受付（利用者に対するイベントを受け付けてログ出力）などがある。

また、ボックス管理機能には、ファイル操作（コレクション設定／ファイル設定／アクセス権設定）やデータベース操作（スキーマ設定／データ操作）などがある。

このように、パーソナルデータ管理機能１０２、１５２は、セルを管理する単位であるユニット、利用者および利用者のデータ（パーソナルデータ）を管理する単位であるセル、利用者のデータ格納領域であるボックスを用いて、利用者の情報およびデータを管理することができる。

ソーシャル管理機能１０３、１５３は、利用者のパーソナルデータに利用者間の関係性を定義づけ、それにより利用者のパーソナルデータの開示制御および秘匿制御を可能とする機能である。具体的には、たとえば、外部セル設定（開示先利用者の登録／参照／変更／削除／一覧参照）、リレーション設定（開示先利用者との関係性を登録／参照／変更／削除／一覧参照）、外部ロール設定（開示先利用者の役割を登録／参照／変更／削除／一覧参照）、メッセージ送受信（利用者のパーソナルデータの開示を許諾するためのコミュニケーション機能）などがある。

このように、ソーシャル管理機能１０３、１５３は、パーソナルデータ（セル）に利用者間の関係性（リレーション）を定義することで、パーソナルデータの開示／秘匿制御が可能となる。それにより、利用者の意思でパーソナルデータの開示が可能なため、利用者間の秘匿性を保つことが可能となる。

これらの機能を用いて、たとば、ユーザ１（主催者）ＰＤＳ１０１において、打合せの予定の登録をおこなう（『Ａｐｐｏｉｎｔｍｅｎｔ打合せ１０：００～』）。そうすると、ユーザ２（参加者）ＰＤＳ１５１において、ユーザ１（主催者）に対して「主催者」という関係性を登録する。

このような関係性が登録されると、当該関係性に基づいて、ユーザ１（主催者）に対して、「主催者」には自分の居場所を見せる権限が与えられ、ユーザ２（参加者）ＰＤＳ内のユーザ２（参加者）の現在地に関する情報を、ユーザ２（参加者）の承認を得ることなく、ユーザ１（主催者）ＰＤＳ１０１が取得することができるようになる。ただし、打合せの予定時刻を経過した場合は、状況が変化したため、「主催者」には自分の居場所を見せる権限は廃棄される。このように、関係性と、状況とに基づいて、ＰＤＳに対するアクセス権限を動的に制御することができる。

（情報処理装置のハードウェア構成例）
図２は、実施の形態にかかる情報処理装置のハードウェア構成の一例を示すブロック図である。情報処理装置の一例である分散型ＰＤＳサーバ１００、１５０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、メモリ２０２と、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２０３と、記録媒体Ｉ／Ｆ２０４と、記録媒体２０５と、を有する。また、各構成部は、バス２００によってそれぞれ接続される。

ここで、ＣＰＵ２０１は、分散型ＰＤＳサーバ１００、１５０の全体の制御を司る。メモリ２０２は、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、たとえば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ２０１のワークエリアとして使用される。メモリ２０２に記憶されるプログラムは、ＣＰＵ２０１にロードされることで、コーディングされている処理をＣＰＵ２０１に実行させる。

ネットワークＩ／Ｆ２０３は、通信回線を通じてネットワーク２０６に接続され、ネットワーク２０６を介して他の装置（たとえば、他の分散型ＰＤＳサーバ、ユーザ端末装置、データベース、あるいは、他のシステム）に接続される。そして、ネットワークＩ／Ｆ２０３は、ネットワーク２０６と自装置内部とのインターフェースを司り、他の装置からのデータの入出力を制御する。ネットワークＩ／Ｆ２０３には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。

記録媒体Ｉ／Ｆ２０４は、ＣＰＵ２０１の制御にしたがって記録媒体２０５に対するデータのリード／ライトを制御する。記録媒体２０５は、記録媒体Ｉ／Ｆ２０４の制御で書き込まれたデータを記憶する。記録媒体２０５としては、たとえば、磁気ディスク、光ディスクなどが挙げられる。

なお、分散型ＰＤＳサーバ１００、１５０は、上述した構成部のほかに、たとえば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、キーボード、ポインティングデバイス、ディスプレイなどを有することにしてもよい。

また、ユーザ端末装置１１０、１６０は、たとえば、パーソナルコンピュータ、タブレット端末装置、スマートフォンなどによって実現される。また、ユーザ端末装置１１０、１６０は、図示は省略するが、ＣＰＵ、メモリ、ディスプレイ、入力装置、通信装置などを有する。

（情報処理装置のセルの機能的構成）
図３は、実施の形態にかかる情報処理装置のセル１０１、１５１の機能的構成の一例を示すブロック図である。図３において、情報処理装置の一例である分散型ＰＤＳサーバ１００、１５０の各セル（ＰＤＳ）１０１、１５１は、関係性の設定に関する処理、ロール判定用条件の登録に関する処理、権限の設定に関する処理およびデータ取得時のアクセス制御に関する処理を実行する。

そのような処理を実行するために、各セル１０１、１５１は、関係性ルール３０４、アカウント関係性マップ３０５、ロール判定マップ３０６、データベース３０７、アカウントロールマップ３０８、ロール一覧３０９の各種テーブルあるいはデータを有するとともに、データ書込部３１１、関係性構築部３１２、ロール条件登録部３１３、ロール要求部３１４、ロール判定部３１５、関係性取得部３１６、状況取得部３１７、ユーザ承認部３１８、アクセス制御部３１９の各構成部を有する。各種テーブルあるいはデータの詳細な内容および各構成部の詳細な内容については後述する。

（関係性ルールの内容）
図４は、関係性ルール３０４のデータ構成の一例を示す説明図である。図４において、関係性ルール３０４は、関係性構築部３１２が、関係性を構築する際に用いるテーブルである。すなわち、関係性構築部３１２は、関係性ルール３０４に記憶されたルールに合致するときに関係性を構築（設定）する。

図４に示すように、関係性ルール３０４は、たとえば、「データパス」欄と、「条件」欄と、「対象」欄と、「関係性」欄を有する。各項目欄（カラム）によって形成されるフィールドに情報を記憶することで、関係性ルールがレコードとして登録される。関係性ルール３０４は、具体的には、たとえば、図２に示した記録媒体２０５などによってその機能を実現することができる。

「データパス」欄には、対象となるデータがあるパスに関する情報を記憶する。たとえば、関係性ルール３０４の上段において、対象となるデータがあるパスが『／ｍｅｅｔｉｎｇ』であることを示している。「条件」欄には、関係性を構築（設定）するためのデータのパラメータ条件に関する情報を記憶する。たとえば、関係性ルール３０４の上段において、『ａｐｐｒｏｖｅ』が『ｔｒｕｅ』の場合に関係性を構築することを示している。ここで、パラメータ条件は、図示は省略するが、閾値であってもよい。すなわち、閾値を基準として、関係性の構築の是非を判断するようにしてもよい。

「対象」欄には、対象となるデータのキーに関する情報を記憶する。たとえば、関係性ルール３０４の上段においては、『ｏｒｇａｎｉｚｅｒ』が対象となるデータのキーであることを示し、この場合ｍｅｅｔｉｎｇの主催者のアカウント名が格納されるキーであることを示している。「関係性」欄には、構築する関係性に関する情報を記憶する。たとえば、関係性ルール３０４の上段において、構築する関係性が『Ｏｒｇａｎｉｚｅｒ（主催者）』であることを示している。

このように、関係性ルール３０４において、上段は、データパス：『／ｍｅｅｔｉｎｇ』において、『ａｐｐｒｏｖｅ』が『ｔｒｕｅ』である場合に、キー：『ｏｒｇａｎｉｚｅｒ』に格納されているアカウントに対して『Ｏｒｇａｎｉｚｅｒ』という関係性を構築することを示している。また、下段は、データパス：『／ｌｉｆｅ／ｍｅｄｉｃａｌ／ａｐｐｏｉｎｔｍｅｎｔ』において、『ｄｏｃｔｏｒＡｐｐｒｏｖａｌ』が『ｔｒｕｅ』である場合に、キー：『ｄｏｃｔｏｒ』に格納されているアカウントに対して『Ｄｏｃｔｏｒ（医者）』という関係性を構築することを示している。これにより、関係性構築部３１２が関係性を構築するにあたり、どのような場合に関係性が構築されるか、その関係性の具体的な内容がわかる。

（アカウント関係性マップの内容）
図５は、アカウント関係性マップ３０５のデータ構成の一例を示す説明図である。図５において、アカウント関係性マップ３０５は、関係性構築部３１２によってデータの書込がおこなわれる、アカウントに関連付けされる（いわゆる紐づく）関係性の一覧テーブルである。

図５に示すように、アカウント関係性マップ３０５は、たとえば、「アカウント」欄と、「関係性」欄を有する。各項目欄（カラム）によって形成されるフィールドに情報を記憶することで、アカウント関係性マップがレコードとして登録される。アカウント関係性マップ３０５は、具体的には、たとえば、図２に示した記録媒体２０５などによってその機能を実現することができる。

「アカウント」欄には、ロールを紐付ける対象となるユーザを示すアカウントに関する情報を記憶する。たとえば、アカウント関係性マップ３０５の第１段において、対象となるアカウントが『Ｋａｎｉ』というユーザであることを示している。「関係性」欄には、アカウントに対して紐付ける関係性に関する情報を記憶する。アカウント関係性マップ３０５の第１段において、アカウント：『Ｋａｎｉ』に紐付けされた関係性が『Ｏｒｇａｎｉｚｅｒ』であることを示している。

同様に、アカウント：『Ｍａｔｓｕｚｏｅ』に紐付けされた関係性が『Ｄｏｃｔｏｒ』であり、アカウント：『Ｍａｔｓｕｉ』に紐付けされた関係性が『Ｂｏｓｓ（上司）』であり、アカウント：『Ｙａｍａｔｏ』に紐付けされた関係性が『Ｈｏｍｅ－Ｄｅｌｉｖｅｒｙ（宅配業者）』であることを示している。

このように、アカウント関係性マップ３０５を参照することによって、アカウントがどのような関係性を備えているかがわかる。アカウント関係性マップ３０５は、権限の設定処理をする際に、ロール判定部３１５によって参照される。

（ロール判定マップの内容）
図６は、ロール判定マップ３０６のデータ構成の一例を示す説明図である。図６において、ロール判定マップ３０６は、ルールに合致するときにロールを付与するためのテーブルである。ロール判定マップ３０６へのデータの登録は、ロール条件登録部３１３によっておこなわれる。

図６に示すように、ロール判定マップ３０６は、たとえば、「ロール」欄と、「関係性条件」欄と、「状況条件」欄を有する。各項目欄（カラム）によって形成されるフィールドに情報を記憶することで、ロール判定マップがレコードとして登録される。ロール判定マップ３０６は、具体的には、たとえば、図２に示した記録媒体２０５などによってその機能を実現することができる。

「ロール」欄には、付与の対象となるロールに関する情報を記憶する。ロールとは、たとえば、許可された者（アカウント）がおこなうことができる権限の内容の総称である。たとえば、ロール判定マップ３０６の第１段において、ロールが『ＲｅａｄＡｇｅ（年齢に関する情報を取得する）』であることを示している。なお、ロールの内容の詳細については、後述する図９の「ロール一覧３０９」において、より詳細に説明する。

「関係性条件」欄には、当該ロールを許可する関係性に関する情報を記憶する。たとえば、ロール判定マップ３０６の第１段においては、関係性が『Ｆａｍｉｌｙ（家族）』である場合（すなわち『ｔｒｕｅ』である場合）に、『ＲｅａｄＡｇｅ』の権限を許可することを示している。

「状況条件」欄には、参照するエンティティのパスと、パスに存在するデータの条件に関する情報を記憶（設定）する。たとえば、ロール判定マップ３０６の第１段においては、状況条件がなにも設定されていない（『［｛｝］』）ので、状況条件は存在せず、いかなる状況においても関係性条件さえ備えていれば、当該ロールを許可することを示している。

また、ロール判定マップ３０６の第２段においては、エンティティのパス：『・・・／Ｌｏｃａｔｉｏｎ』において、『ｄｉｓｔａｎｃｅＴｏＨｏｍｅ：３００、Ｄａｔｅ：“ｕｎｔｉｌ ｔｈｅ ｔａｓｋ ｆｉｎｉｓｈｅｓ（自宅から３００ｍ以内で、配達が完了するまで）”』という条件（コンディション）を満たせば、関係性条件を備えている者（『Ｈｏｍｅ－Ｄｅｌｉｖｅｒｙ（宅配業者）』の関係性が設定されている者）に、該当するロール（『ＲｅａｄＴｒａｎｓｆｅｒＩｎｆｏｒｍａｔｉｏｎ（移動に関する情報を取得すること）』を許可することを示している。

このように、ロール判定マップ３０６を参照することによって、各ロールの関係性条件と状況条件とがわかる。ロール判定マップ３０６は，権限の設定処理をする際に、ロール判定部３１５によって参照される。

（データベースに格納されるデータの内容）
図７は、データベース３０７に格納されるデータの一例を示す説明図である。図７に示すように、データベース３０７には、各ユーザの各種の情報（パーソナルデータ）が格納される。このデータの内容が、状況取得部３１７によって参照（取得）され、その参照結果に基づいて、当該データにアクセス（書き込みあるいは読み出しなど）が許可されるか否かが決定される。

データベース３０７は、具体的には、たとえば、図２に示した記録媒体２０５などによってその機能を実現することができる。

（アカウントロールマップの内容）
図８は、アカウントロールマップ３０８のデータ構成の一例を示す説明図である。図８において、アカウントロールマップ３０８は、アカウントに関連付けされる（いわゆる紐づく）ロールの一覧テーブルである。アカウントロールマップ３０８は、ロール判定部３１５によって、データの書き換えがおこなわれる。

図８に示すように、アカウントロールマップ３０８は、たとえば、「アカウント」欄と、「ロール」欄を有する。各項目欄（カラム）によって形成されるフィールドに情報を記憶することで、アカウントロールマップがレコードとして登録される。アカウントロールマップ３０８は、具体的には、たとえば、図２に示した記録媒体２０５などによってその機能を実現することができる。

「アカウント」欄は、図５に示したアカウント関係性マップ３０５の「アカウント」欄と同じように、ロールを紐付ける対象となるユーザを示すアカウントに関する情報を記憶する。「アカウント」欄の具体的な内容については、図５に示したアカウント関係性マップ３０５と同様なので、その説明は省略する。また、「ロール」欄には、図６に示したロール判定マップ３０６の「ロール」欄と同じように、付与の対象となるロールに関する情報を記憶する。

これによって、アカウントロールマップ３０８を参照することによって、アカウントとそのアカウントに付与されるロールとの関係がわかる。アカウントロールマップ３０８は、データ取得時のアクセス制御の処理をおこなう際に、アクセス制御部３１９によって参照される。

（ロール一覧の内容）
図９は、ロール一覧３０９のデータ構成の一例を示す説明図である。図９において、ロール一覧３０９は、ロールの一覧を示すテーブルである。ロール一覧３０９は、たとえば、「ロール」欄と、「データパス」欄と、「権限レベル」欄を有する。各項目欄（カラム）によって形成されるフィールドに情報を記憶することで、ロール一覧がレコードとして登録される。ロール一覧３０９は、具体的には、たとえば、図２に示した記録媒体２０５などによってその機能を実現することができる。

「ロール」欄には、ロールに関する情報を記憶する。ロールとは、たとえば、許可された者（アカウント）がおこなうことができる権限の内容の総称などであるから、その詳細な内容について、「データパス」欄と、「権限レベル」欄に記憶する。

「データパス」欄には、対象となるデータが存在するパスに関する情報を記憶する。たとえば、ロール一覧３０９の第１段のロール：『ＲｅａｄＡｇｅ』の対象となる「Ａｇｅ」に関する情報は、「データパス」欄の『／ｐｒｏｆｉｌｅ／ａｇｅ』に存在することを示している。

「権限レベル」欄は、対象のデータに対して、どのような権限を与えるか、その内容に関する情報を記憶する。権限レベルが『ｒｅａｄ』であれば、取得する権限が与えられていることを示す。権限レベルは、『ｒｅａｄ』の他に、『ｗｒｉｔｅ（書き込み）』や、『ｅｘｅｃｕｔｅ（プログラムなどの実行）』などがある。権限レベルが『ａｌｌ』であれば、『ｒｅａｄ』、『ｗｒｉｔｅ』、『ｅｘｅｃｕｔｅ』などのすべてを含む権限が与えられていることを示す。

このように、ロール一覧３０９を参照することによって、どのような内容のロールが記憶されているかがわかる。ロール一覧３０９は、データ取得時のアクセス制御の処理をおこなう際に、アクセス制御部３１９によって参照される。

（関係性の設定）
図１０は、セル１０１、１５１の関係性の設定にかかる機能的構成の一例を示すブロック図である。図１０において、関係性の設定に際しては、セル１０１、１５１は、データ書込部３１１と、関係性構築部３１２などを用いる。すなわち、データ書込部３１１に、単純なＰＤＳ（セル１０１、１０５）への書き込みがおこなわれる。そして、データ書込部３１１は、関係性構築部３１２に対して、データの書込情報を伝達する。データ書込部３１１は、具体的には、たとえば、図２に示したネットワークＩ／Ｆ２０３などによってその機能を実現することができる。

関係性構築部３１２は、関係性ルール３０４においてあらかじめ定義されているルールにしたがって、自アカウントと他アカウントとの関係性を設定し、アカウント関係性マップ３０５に登録する。関係性構築部３１２は、具体的には、たとえば、ＣＰＵ２０１、記録媒体Ｉ／Ｆ２０４などによってその機能を実現することができる。

図１１は、データ書込部３１１の処理の手順の一例を示すフローチャートである。図１１のフローチャートにおいて、データ書込部３１１は、データ情報を受信する（ステップＳ１１０１）。データ情報は、たとえば、同じ分散型ＰＤＳサーバ内の他のセル、他の分散型ＰＤＳサーバの他のセル、あるいは、ユーザ端末装置などから受信する。

つぎに、データ書込部３１１は、アクセス制御部３１９にアカウント情報を送信し（ステップＳ１１０２）、アクセス制御部３１９から判定結果を受信する（ステップＳ１１０３）。アクセス制御部３１９では、データ書込部３１１から送信されてきたアカウント情報が、アカウント関係性マップ３０５に対して関係性を書き込む（登録する）ことができる権限があるかを判定し、その判定結果をデータ書込部３１１へ送信する。

データ書込部３１１は、アクセス制御部から受信した判定結果がＯＫ、すなわち書き込むことが許可された場合（ステップＳ１１０４：Ｙｅｓ）は、データに書込をする（ステップＳ１１０５）。具体的には、データ書込部３１１は、関係性構築部３１２に書込情報（データの変更情報）を伝達する。これにより、データ書込部３１１の一連の処理を終了する。一方、判定結果がＯＫでない、すなわち書き込むことが許可されなかった場合（ステップＳ１１０４：Ｎｏ）は、なにもせずに、一連の処理を終了する。

このようにして、ＰＤＳ（セル１０１、１０５）への書き込みについて、データ書込部３１１が、関係性構築部３１２に対して、そのデータの書込情報を伝達することができる。

図１２は、関係性構築部３１２の処理の手順の一例を示すフローチャートである。図１２のフローチャートにおいて、関係性構築部３１２は、データの変更情報を受信する（ステップＳ１２０１）。そして、受信したデータの変更情報（書込情報）が、関係性ルール３０３にあらかじめ登録されている関係性ルールにマッチ（合致）する条件があるか否かを判断する（ステップＳ１２０２）。

ステップＳ１２０２において、マッチする条件がある場合（ステップＳ１２０２：Ｙｅｓ）は、アカウント関係性マップに、変更情報（書込情報）をアカウント関係性マップ３０５に登録し（ステップＳ１２０３）、一連の処理を終了する。一方、マッチする条件がない場合（ステップＳ１２０２：Ｎｏ）は、アカウント関係性マップ３０５への設定はおこなわず（ステップＳ１２０４）。一連の処理を終了する。

このようにして、関係性構築部３１２は、関係性ルール３０４にしたがって、自アカウントと他アカウントとの関係性を構築し、構築された内容を、アカウント関係性マップ３０５に登録することができる。

（ロール判定用条件の登録）
図１３は、セル１０１、１５１のロール判定用条件の登録にかかる機能的構成の一例を示すブロック図である。図１３において、ロール判定用条件の登録に際しては、セル１０１、１５１は、ロール条件登録部３０３などを用いる。すなわち、ロール条件登録部３１３は、たとえば、ユーザ端末装置１１０、１６０などから、ロールを自動設定するための判定条件をあらかじめ設定し、ロール判定マップ３０６に登録しておく。

ロール条件登録部３１３は、具体的には、図２に示したネットワークＩ／Ｆ２０３、記録媒体Ｉ／Ｆ２０４などによってその機能を実現することができる。

図１４は、ロール条件登録部３１３の処理の手順の一例を示すフローチャートである。図１４のフローチャートにおいて、ロール条件登録部３１３は、ロール条件を受信する（ステップＳ１４０１）。ロール条件は、たとえば、ユーザ端末装置１１０、１６０などから受信する。あるいは、同じ分散型ＰＤＳサーバ内の他のセル、他の分散型ＰＤＳサーバの他のセル、あるいは、ユーザ端末装置などからロール条件を受信するようにしてもよい。

そして、ロール条件登録部３１３は、受信したロール条件（「ロール」、とそれに対応する「関係性条件」および「状況条件」）をロール判定マップ３０６に登録する（ステップＳ１４０２）。これにより、ロール条件登録部３１３の一連の処理を終了する。このようにして、ロール条件登録部３１３は、ルールに合致するときにロールを付与するためのテーブルであるロール判定マップ３０６に、ロール条件である「関係性条件」および「状況条件」を登録することができる。

図１５は、ロール条件の設定画面の一例を示す説明図である。図１５に示す設定画面１５００を、たとえば、ユーザ端末装置１１０、１６０に表示する。そして、各入力欄（たとえば、「ルート名」、「対象オブジェクト」、「対象イベント」、「対象条件」、「アクション」、「実行サービス」など）に所定の情報を入力し、登録ボタンを押下することによって、ロール情報をユーザ端末装置１１０、１６０からロール条件登録部３１３へ送信することができる。

設定のための、よく使われそうなテンプレートを提供しておいてもよい。また、設定の履歴はテンプレートとして使い回しをするようにしてもよい。あらかじめテンプレートに書かれたものだけを用意して、ユーザのワンタッチだけで自動設定されるようにしてもよい。

（権限の設定）
図１６は、セル１０１、１５１の権限の設定にかかる機能的構成の一例を示すブロック図である。図１６において、権限の設定に際しては、セル１０１、１５１のデータ要求側は、ロール要求部３１４を用いる。また、セル１０１、１５１のデータ返信側は、ロール判定部３１５、関係性取得部３１６、状況取得部３１７、ユーザ承認部３１８などを用いる。

ロール要求部３１４は、アカウント情報とロール情報とを受信し、ロール判定部３１５に対して、アカウント情報とロール情報とを送信する。ここで、ロール要求部３１４と、ロール判定部３１５とは、別のユーザ（セル／データ領域）を想定している。ロール要求部３１４は、具体的には、たとえば、図２に示したネットワークＩ／Ｆ２０３などによってその機能を実現することができる。

ロール判定部３１５は、ロール要求部３１４から送信されたアカウント情報とロール情報とを受信し、関係性と状況から適切なロールの判定をおこなう。ロール判定部３１５は、具体的には、たとえば、図２に示したＣＰＵ２０１、ネットワークＩ／Ｆ２０３、記録媒体Ｉ／Ｆ２０５などによってその機能を実現することができる。

関係性取得部３１６は、ロール判定部３１５からの要求によって、アカウント関係性マップ３０５から、該当するアカウントの関係性に関する情報を取得し、取得した情報をロール判定部３１５に送信する。関係性取得部３１６は、具体的には、たとえば、図２に示したＣＰＵ２０１、記録媒体Ｉ／Ｆ２０４などによってその機能を実現することができる。

状況取得部３１７は、ロール判定部３１５からの要求によって、データベース３０７から、状況に関する情報を取得し、取得した情報をロール判定部３１５に送信する。状況取得部３１７は、具体的には、たとえば、図２に示したＣＰＵ２０１、記録媒体Ｉ／Ｆ２０４などによってその機能を実現することができる。

ユーザ承認部３１８は、ロール判定部３１５からの要求によって、たとえばユーザ端末装置１１０から、ユーザの承認を求め、当該ユーザの承認の要否（承認する／承認しないなど）を得る。そして、得た承認の要否について、その旨をロール判定部３１５に送信する。ユーザ承認部３１８は、具体的には、たとえば、図２に示したＣＰＵ２０１などによってその機能を実現することができる。

図１７は、ロール要求部３１４の処理の手順の一例を示すフローチャートである。図１７のフローチャートにおいて、ロール要求部３１４は、アカウント情報とロール情報とを受信する（ステップＳ１７０１）。アカウント情報とロール情報は、たとえば、ユーザ端末装置１１０、１６０などから受信する。あるいは、同じ分散型ＰＤＳサーバ内の他のセル、他の分散型ＰＤＳサーバの他のセル、あるいは、ユーザ端末装置などからロール条件を受信するようにしてもよい。

つぎに、ロール要求部３１４は、ロール判定部３１５にアカウント情報とロール情報を送信する（ステップＳ１７０２）。このようにして、ロール要求部３１４では、（主に他者の）データにアクセスするためのロールを要求するために、ロールを与えてよいかを判定する（他者の）ロール判定部３１５を呼び出す。これにより、ロール要求部３１４の一連の処理を終了する。

このようにして、ロール要求部３１４は、他のユーザのセルのロール要求部３１４に対して、ロール判定の要求をすることができる。

図１８は、ロール判定部３１５の処理の手順の一例を示すフローチャートである。図１８のフローチャートにおいて、ロール判定部３１５は、ロール要求部３１４からアカウント情報とロール情報を受信する（ステップＳ１８０１）。つぎに、ロール判定マップ３０６から、対象となるロール情報に対する条件を取得する（ステップＳ１８０２）。そして、対象となるロールの条件が存在するか否かを判断する（ステップＳ１８０３）。ここで、対象となるロールの条件が存在しない場合（ステップＳ１８０３：Ｎｏ）は、ステップＳ１８１３へ移行する。

一方、ステップＳ１８０３において、対象となるロールの条件が存在する場合（ステップＳ１８０３：Ｙｅｓ）は、ロール条件を一時的に保管する（ステップＳ１８０４）。つぎに、ロール判定部３１５は、ロール条件に関係性情報が記載されているか否かを判断する（ステップＳ１８０５）。ここで、ロール条件に関係性情報が記載されていない場合（ステップＳ１８０５：Ｎｏ）は、ステップＳ１８１３へ移行する。

一方、ステップＳ１８０５において、ロール条件に関係性情報が記載されている場合（ステップＳ１８０５：Ｙｅｓ）は、関係性取得部３１６にアカウント情報を送信し（ステップＳ１８０６）、関係性取得部３１６から関係性情報を取得する（ステップＳ１８０７）。

つぎに、ロール判定部３１５は、ロール条件に状況情報を利用するか否かを判断する（ステップＳ１８０８）。ここで、ロール条件に状況情報を利用しない場合（ステップＳ１８０８：Ｎｏ）は、ステップＳ１８１１へ移行する。

一方、ステップＳ１８０８において、ロール条件に状況情報を利用する場合（ステップＳ１８０８：Ｙｅｓ）は、状況取得部３１７にロール条件を送信し（ステップＳ１８０９）、状況取得部３１７から状況情報を取得する（ステップＳ１８１０）。その後、ステップＳ１８１１へ移行し、判定処理を開始する（ステップＳ１８１１）。

そして、要求されている条件に、取得した関係性情報／状況情報が一致するか否かを判断する（ステップＳ１８１２）。ここで、要求されている条件に、取得した関係性情報／状況情報が一致する場合（ステップＳ１８１２：Ｙｅｓ）は、ステップＳ１８１５へ移行する。一方、要求されている条件に、取得した関係性情報／状況情報が一致しない場合（ステップＳ１８１２：Ｎｏ）は、ユーザ承認部３１８にアカウント情報とロール情報を送信する（ステップＳ１８１３）。

そして、確認結果がＯＫであるか否かを判断する（ステップＳ１８１４）。ここで、確認結果がＯＫではない場合（ステップＳ１８１４：Ｎｏ）は、設定が失敗したとして（ステップＳ１８１６）、一連の処理を終了する。一方、ステップＳ１８１４において、確認結果がＯＫである場合（ステップＳ１８１４：Ｙｅｓ）は、アカウントロールマップ３０８を更新し（ステップＳ１８１５）、一連の処理を終了する。

このようにして、ロール判定部３１５は、ロール要求部３１４から要求があったロールに対して当該要求したアカウントがロールに関する権限を有しているかを判定することができる。

図１９は、関係性取得部３１６の処理の手順の一例を示すフローチャートである。図１９のフローチャートにおいて、関係性取得部３１６は、アカウント情報とロール情報を取得する（ステップＳ１９０１）。アカウント情報とロール情報は、ロール判定部３１５から取得する（図１８のステップＳ１８０６を参照）。

そして、アカウント関係性マップ３０５にマッチするアカウント情報があるか否かを判断する（ステップＳ１９０２）。ここで、マッチするアカウント情報がある場合（ステップＳ１９０２：Ｙｅｓ）は、関係性情報をロール判定部３１５に返信し（ステップＳ１９０３）、一連の処理を終了する。このようにして、ロール判定部３１５は、関係性取得部３１６から関係性情報を取得する（図１８のステップＳ１８０７を参照）。

ステップＳ１９０２において、マッチするアカウント情報がない場合（ステップＳ１９０２：Ｎｏ）は、確認結果がＮＧであった旨をロール判定部３１５に返信し（ステップＳ１９０４）、一連の処理を終了する。

このようにして、関係性取得部３１６は、ロール判定部３１５からの要求によって、該当するアカウントの関係性に関する情報を取得し、取得した情報をロール判定部３１５に送信することができる。

図２０は、状況取得部３１７の処理の手順の一例を示すフローチャートである。図２０のフローチャートにおいて、状況取得部３１７は状況情報を受信する（ステップＳ２００１）。状況情報は、ロール判定部３１５から受信する（図１８のステップＳ１８０９を参照）。

つぎに、ロール条件（状況条件）から判定すべきデータパス一覧を取得する（ステップＳ２００２）。そして、データパス上にデータがあるか否かを判断する（ステップＳ２００３）。ここで、データパス上にデータがある場合（ステップＳ２００３：Ｙｅｓ）は、当該データをロール判定部３１５に返信し（ステップＳ２００４）、一連の処理を終了する。このようにして、ロール判定部３１５は、状況取得部３１７からデータを取得する（図１８のステップＳ１８１０）を参照）。

ステップＳ２００３において、データパス上にデータがない場合（ステップＳ２００３：Ｎｏ）は、確認結果がＮＧであった旨をロール判定部３１５に返信し（ステップＳ２００５）、一連の処理を終了する。

このようにして、状況取得部３１７は、ロール判定部３１５からの要求によって、データベース３０７から、状況に関する情報を取得し、取得した情報をロール判定部３１５に送信することができる。

図２１は、ユーザ承認部３１８の処理の手順の一例を示すフローチャートである。図２１のフローチャートにおいて、ユーザ承認部３１８は、アカウント情報とロール情報を受信する（ステップＳ２１０１）。アカウント情報とロール情報は、ロール判定部３１５から受信する（図１８のステップＳ１８１３を参照）。

つぎに、ユーザに対して承認画面を表示し承認を得る（ステップＳ２１０２）。そして、確認結果がＯＫであるか否かを判断する（ステップＳ２１０３）。ここで、確認結果がＯＫである場合（ステップＳ２１０３：Ｙｅｓ）は、確認結果がＯＫである旨をロール判定部３１５に返信し（ステップＳ２１０４）、一連の処理を終了する。このようにして、ロール判定部３１５は、ユーザ承認部３１８から確認結果を取得し、その判断をおこなう（図１８のステップＳ１８１４）を参照）。

ステップＳ２１０３において、確認結果がＯＫでない場合（ステップＳ２１０３：Ｎｏ）は、確認結果がＮＧであった旨をロール判定部３１５に返信し（ステップＳ２１０５）、一連の処理を終了する。

このようにして、ユーザ承認部３１８は、ロール判定部３１５からの要求によって、ユーザの承認を求め、当該ユーザの承認の要否に関する情報を取得し、取得した情報をロール判定部３１５に送信することができる。

（データ取得時のアクセス制御）
図２２は、セル１０１、１５１のデータ取得時のアクセス制御にかかる機能的構成の一例を示すブロック図である。図２２において、データ取得時のアクセス制御に際しては、セル１０１、１５１は、アクセス制御部３１９などを用いる。すなわち、アクセス制御部３１９は、たとえば、他のセルや、ユーザ端末装置１１０、１６０などからのアクセス要求に対して、データベース３０７のデータへのアクセスをしてもよいかを判断する。アクセス制御部３１９は、具体的には、図２に示したＣＰＵ２０１、ネットワークＩ／Ｆ２０３、記録媒体Ｉ／Ｆ２０４などによってその機能を実現することができる。

図２３は、アクセス制御部３１９の処理の手順の一例を示すフローチャートである。図２３のフローチャートにおいて、アカウント情報とアクセス情報を受信する（ステップＳ２３０１）。アカウント情報とアクセス情報は、たとえば、同じ分散型ＰＤＳサーバ内の他のセル、他の分散型ＰＤＳサーバの他のセル、あるいは、ユーザ端末装置などから受信する。また、アカウント情報とアクセス情報は、ユーザ端末装置１１０、１６０などから受信するようにしてもよい。

そして、アカウントロールマップ３０８にアカウントに紐づくロール情報が存在するか否かを判断する（ステップＳ２３０２）。ここで、該当するロール情報が存在しない場合（ステップＳ２３０２：Ｎｏ）は、判定結果がＮＧである旨を送信元に返信し（ステップＳ２３０８）、一連の処理を終了する。一方、ステップＳ２３０２において、該当するロール情報が存在する場合（ステップＳ２３０２：Ｙｅｓ）は、当該ロール情報をアカウントロールマップ３０８から取得する（ステップＳ２３０３）。

つぎに、ロール一覧３０９にロール情報詳細が存在するか否かを判断する（ステップＳ２３０４）。ここで、ロール情報詳細が存在しない場合（ステップＳ２３０４：Ｎｏ）は、判定結果がＮＧである旨を送信元に返信し（ステップＳ２３０８）、一連の処理を終了する。一方、ステップＳ２３０４において、ロール情報詳細が存在する場合（ステップＳ２３０４：Ｙｅｓ）は、当該ロール情報詳細をロール一覧３０９から取得する（ステップＳ２３０５）。

そして、アクセス情報がロール情報詳細のＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）設定にマッチするか否かを判断する（ステップＳ２３０６）。ここで、アクセス情報がロール情報詳細のＡＣＬ設定にマッチしない場合（ステップＳ２３０６：Ｎｏ）は、判定結果がＮＧである旨を送信元に返信し（ステップＳ２３０８）、一連の処理を終了する。一方、ステップＳ２３０６において、アクセス情報がロール情報詳細のＡＣＬ設定にマッチする場合（ステップＳ２３０６：Ｙｅｓ）は、判定結果がＯＫである旨を送信元に返信し（ステップＳ２３０７）、一連の処理を終了する。

これにより、判定結果がＯＫである場合は、ＰＤＳの該当するデータへのアクセスが可能となる。

このようにして、アクセス制御部３１９は、他のセルなどからのアクセス要求に対して、データベース３０７のデータへのアクセスをしてもよいかを判断することができる。

以上説明したように、本実施の形態によれば、個人ごとのデータ領域に格納されたユーザの個人データ（具体的にはたとえばＰＤＳなど）にアクセスするにあたり、ユーザの個人データにアクセスするアカウントのユーザとの関係性と、アカウントがユーザの個人データにアクセスする状況とに基づいて、アカウントに対するユーザの個人データへのアクセス権限を制御することができる。

また、本実施の形態によれば、アカウントが関係性に関する条件を満たす場合に、アカウントに対してアクセス権限を認めるようにすることができる。また、アカウントによるアクセスが状況に関する条件を満たす、より具体的には、たとえば、ユーザの個人データに基づいて、アカウントによるアクセスが状況に関する条件を満たす場合に、アカウントに対してアクセス権限を認めるようにすることができる。また、さらに、ユーザの承認があった場合に、アクセス権限を認めるようにすることもできる。

また、本実施の形態によれば、アクセス権限と、アクセス権限に対応する関係性および条件に関する条件とを関連付けして記憶し、記憶された条件に基づいて、アクセス権限を制御することができる。

また、本実施の形態によれば、アカウントのユーザとの関係性を、あらかじめ定められたルールに基づいて構築し、構築されたアカウントのユーザとの関係性に関する情報に基づいて、アカウントが関係性に関する条件を満たすかを判断することができる。

このように構成することによって、本実施の形態は、データの保有者と利用者間の関係性や状況から動的にデータのアクセス権限を設定することができる。これにより、データの保有者が逐一承認することなく、あらかじめ設定しておいた条件（たとえば、関係性に関する条件、状況に関する条件）に合致する場合には、適切な関係性の利用者にのみデータの利用を動的に許可することができる。

なお、データの構成と関係性ルールは、テンプレートが用意されていてもよい。たとえば、打合せに対して主催者と参加者の関係性や、診療に対して患者と医者の関係性は一般的な考え方で、同様の関係性が構築されることは多くあるので、テンプレートとしてあらかじめ定義しておくようにしてもよい。

また、権限に応じて、データを公開する範囲を変えるだけでなく、公開されている情報を限定的な情報にフィルタリングしたり加工するようにしてもよい。たとえば、どこにいるか具体的な所在地（緯度経度など）までわかる情報としてもよく、単に、在宅／外出だけの情報に限定してもよい。

（実施例）
つぎに、具体的な実施例１～３の内容ついて説明する。実施例１は、宅配業者に在／不在情報を提供する処理を例に説明する。また、実施例２は、医療情報を提供する処理を例に説明する。また、実施例３は、上司と部下が打合せ情報を共有する処理を例に説明する。

各実施例では、たとえば、ロール要求部３１４によるロール要求をソーシャル機能の「メッセージ」とし、ロール判定部３１５を「ルールと判定スクリプト」によって実施するようにしてもよい。アプリケーションとしての処理として実行されるものは「実行スクリプト」と呼ぶ。ソーシャル機能の一つであるメッセージは、セル間でのコミュニケーションをおこなう仕組みであり、「ロールを要求」といったメッセージが可能である。

また、ルールは、データの変更やメッセージの送受信時に特定のスクリプトを処理するためのものである。スクリプトは、インタプリタ型の実行可能プログラムであってもよい。ＰＤＳのデータ取得やロールの設定など、ＰＤＳのクライアントとして動作することが可能である。ロール判定のために動作するものを「判定スクリプト」と呼び、それ以外を「実行スクリプト」と呼ぶ。

（実施例１：宅配業者に在／不在情報を提供する処理）
図２４Ａは、実施例１（宅配業者への在／不在情報の提供）にかかるユーザ（配達員）に設定されるデータの一例を示す説明図である。図２４Ａにおいて、ユーザである「配達員」のＰＤＳ２４０１に対しては、たとえば、以下のような関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「配達員」のＰＤＳ２４０１には、配達客Ａに対して『客』という関係性が設定されている。また、「配達員」のＰＤＳ２４０１には、配達客Ａに対して、『宅配情報のＷｒｉｔｅ（書込）権限』を与えるというロールが設定されている。また、「配達員」のＰＤＳ２４０１には、『通知スクリプト』が設定され、『宅配情報が変更されたら通知スクリプトを呼ぶルール』が設定されている。

図２４Ｂは、実施例１にかかるユーザ（配達客Ａ）に設定されるデータの一例を示す説明図である。図２４Ｂにおいて、ユーザである「配達客Ａ」のＰＤＳ２４０２に対しては、図２４Ａに示した「配達員」と同様に、関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「配達客Ａ」のＰＤＳ２４０２には、配達員に対して『宅配業社』という関係性が設定されている。また、「配達客Ａ」のＰＤＳ２４０２には、配達員に対して、『在宅情報のＲｅａｄ（取得）権限』、『帰宅状況のＲｅａｄ権限』を与えるというロールが設定されている。また、「配達客Ａ」のＰＤＳ２４０２には、『在宅確認スクリプト』、『帰宅状況確認スクリプト』、『自動承認スクリプト』が設定され、『定期的に在宅確認や帰宅確認スクリプトを実行するルール』が設定されている。

図２５（図２５Ａ～図２５Ｅ）は、実施例１（宅配業者への在／不在情報の提供）の処理の一例を説明する説明図（その１～その５）である。

図２５Ａは、宅配業者に在／不在情報を提供する際の前提について示している。図２５Ａにおいて、宅配業社の配達員のＰＤＳ２５０１に対して、宅配業社のアプリケーションのインストール時や運送依頼時に配達客Ａの情報を登録する。同時に関係性を設定し、該当する宅配情報のＷｒｉｔｅ権限も付与する（ステップＳ２５１１）。また、処理する実行スクリプトとして、通知スクリプトを配備する（ステップＳ２５１２）。

一方、配達客ＡのＰＤＳ２５０２に対して、宅配業社のアプリケーションのインストール時に宅配業社との関係性はあらかじめ設定しておく（ステップＳ２５１３）。すなわち、アカウントに関係性情報を紐づけしておく。また、設定するロールとして、在宅状況の
Ｒｅａｄ権限と、帰宅状況のＲｅａｄ権限とを自動配備する（ステップＳ２５１４）。また、処理するスクリプトとして、在宅確認スクリプトと、帰宅状況確認スクリプトと、関係性が定義されたアカウントからのメッセージは自動承認する判定スクリプトとを配備する（ステップＳ２５１５）。さらに、起動ルールとして、定期的に在宅確認や、帰宅状況確認をするスクリプトを動かすルールを配備する（ステップＳ２５１６）。

図２５Ｂは、宅配業者に在／不在情報を提供する際の基本動作について示している。図２５Ｂにおいて、宅配業社の配達員のＰＤＳ２５０１は、運送依頼登録で、配達客Ａに承認依頼メッセージを配達客ＡのＰＤＳ２５０２に送信する（ステップＳ２５２１）。また、配達客Ａの宅配情報のＷｒｉｔｅ権限は宅配情報登録時にあらかじめ設定されている（ステップＳ２５２２）。

一方、配達客ＡのＰＤＳ２５０２は、承認依頼メッセージの受信時に、判定スクリプトで配達員の関係性を確認し、配達員に在宅情報のＲｅａｄ権限を付与する（ステップＳ２５２３）。配達客ＡのＰＤＳ２５０２は、具体的な居場所は提供しない（ステップＳ２５２４）。そして、自宅の在・不在情報を、宅配業社の配達員のＰＤＳ２５０１の宅配情報に書き込む（ステップＳ２５２５）。

図２５Ｃは、宅配業者に在／不在情報を提供する処理における、在・不在変化時の通知の処理について示している。図２５Ｃにおいて、宅配業社の配達員のＰＤＳ２５０１は、あらかじめ通知を受け取る端末（配達員のスマートフォン２５３０）を登録しておく（ステップＳ２５３１）。そして、宅配情報が書き込まれると、在・不在変更時に端末に通知するスクリプトを実行する（ステップＳ２５３２）。それにより、在・不在に変化があったら、配達員のスマートフォン２５３０にリアルタイムに通知される（ステップＳ２５３３）。

図２５Ｄは、宅配業者に在／不在情報を提供する処理における、動的な情報の公開の処理について示している。図２５Ｄにおいて、宅配業社の配達員のＰＤＳ２５０１は、配達客Ａ宅に近づいたら、公開範囲を広げてもらうように、配達客ＡのＰＤＳ２５０２に承認依頼をする（ステップＳ２５４１）。そして、配達客Ａ宅の３ｋｍ範囲内に近づいた旨を宅配情報に登録する（ステップＳ２５４２）。

一方、配達客ＡのＰＤＳ２５０２は、判定スクリプトで関係性に加え、配達員が近くに存在している状況を判定し、宅配業社の配達員のＰＤＳ２５０１に帰宅状況のＲｅａｄ権限を付与する（ステップＳ２５４３）。つぎに、自宅から３００ｍ範囲内で、自宅に向かっている＝もうすぐ帰宅する旨を帰宅情報に登録する（ステップＳ２５４４）。そして、その帰宅情報を、宅配業社の配達員のＰＤＳ２５０１の宅配情報に書き込む（ステップＳ２５４５）。

図２５Ｅは、宅配業者に在／不在情報を提供する処理における、情報の削除の処理について示している。図２５Ｅにおいて、宅配業社の配達員のＰＤＳ２５０１は、配達完了時には、配達客ＡのＰＤＳ２５０２にロール削除依頼メッセージを送信する（ステップＳ２５５１）。

一方、配達客ＡのＰＤＳ２５０２は、ロール削除依頼メッセージの受信時における自動承認で、宅配業社の全てのＲｅａｄ権限を削除する（ステップＳ２５５２）。これによって、宅配業社の配達員のＰＤＳ２５０１は、配達客Ａの情報は見られなくなる（ステップＳ２５５３）。

以上説明したように、実施例１では、配達日になると、配達客Ａの在宅状況を確認できるようにする。また、配達時間と、配達客Ａ宅に近いということと、不在（配達客Ａは近く）という条件が重なった場合には、もうすぐ帰宅する旨を確認できるようにする。これにより、宅配業社の配達員は、実際に客先まで配達することなく、その情報から配達すべきかどうかを判断できるようになる。

（実施例２：医療情報を提供する処理）
図２６Ａは、実施例２（医療情報の提供）にかかるユーザ（医者）に設定されるデータの一例を示す説明図である。図２６Ａにおいて、ユーザである「医者」のＰＤＳ２６０１に対しては、たとえば、以下のような関係性およびロールが設定されている。すなわち、「医者」のＰＤＳ２６０１には、患者Ａに対して『患者』という関係性が設定されている。

また、「医者」のＰＤＳ２６０１には、患者Ａに対して、『予約情報のＷｒｉｔｅ権限』を与えるというロールが設定されている。図２６Ａにおいては、「医者」のＰＤＳ２６０１には、スクリプト、ルール一覧は設定されていない。

図２６Ｂは、実施例２にかかるユーザ（患者Ａ／急病人）に設定されるデータの一例を示す説明図である。図２６Ｂにおいて、ユーザである「患者Ａ／急病人」のＰＤＳ２６０２に対しても、実施例１と同様に、関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「患者Ａ／急病人」のＰＤＳ２６０２には医者に対して『担当医』という関係性が設定されている。

また、「患者Ａ／急病人」のＰＤＳ２６０２には、医者に対して、『個人情報のＲｅａｄ権限』を与えるというロールとともに、第三者（緊急時）に対して、『個人情報のＲｅａｄ権限』を与えるというロールが設定されている。また、「患者Ａ／急病人」のＰＤＳ２６０２には、『判定スクリプト』が設定され、『メッセージ受信時に自動承認するルール』が設定されている。

図２７Ａおよび図２７Ｂは、実施例２（医療情報の提供）の処理の一例を説明する説明図である。図２７Ａは、通常時の医療情報の提供の処理について示している。図２７Ａにおいて、患者ＡのＰＤＳ２７０２は、まず、担当医にデータ公開を許容する判定スクリプトを用意する。そして、メッセージ受信時に自動承認する判定スクリプトを発火（実行）するよう設定する。つぎに、患者は、診察を受けるために予約を入れる。もしくは診察を受付で申し込む。

一方、医者のＰＤＳ２７０１は、患者からの診療の予約あるいは診察申し込みを承認する。これによって、患者と医者の関係性（「医者：担当医」）」が自動的に構築される（ステップＳ２７１１）。そして、医者のＰＤＳ２７０１は、診察時間に、診察中に患者の病歴や生活習慣を見るための権限取得要求メッセージを送信する（ステップＳ２７１２）。

これに対して、患者ＡのＰＤＳ２７０２は、権限取得要求メッセージ受信に対応して自動承認する判定スクリプトを発火し、ステップＳ２７１２において構築された関係性（患者と医者）を判断し、医者との関係付けをおこなう（ステップＳ２７１３）。その後、医者のＰＤＳ２７０１に対して個人情報へのＲｅａｄ（取得）権限を付与する（ステップＳ２７１４）。これにより、医者のＰＤＳ２７０１は、個人情報取得権限が自動で設定され、診察に利用するための個人情報にアクセス可能になる。また、診察終了時、医者に対する権限と関係性（患者と医者）を破棄する。

図２７Ｂは、緊急時の医療情報の提供の処理について示している。図２７Ｂにおいて、第三者のＰＤＳ２７０３は、急病人の情報端末装置１５０などから、たとえば、特定のＱＲコード（登録商標）を取得し、関係性を構築する（ステップＳ２７２１）。そして、第三者のＰＤＳ２７０３は、すぐさま情報公開の承認要求メッセージを急病人のＰＤＳ２７０４へ送信する（ステップＳ２７２２）。

これに対して、急病人のＰＤＳ２７０４は、ヘルスケア情報が正常値ではない＝倒れてしまったような大事が起こった場合、関係性は「医者：担当医」に限らない。特定のＱＲコードで得られたデータと一致すれば、自動承認で個人情報のＲｅａｄ権限に関するロールを許可する（ステップＳ２７２３）。そして、緊急事態のメッセージでは、関係性に関わらず、その場にいて救助してくれた人に個人情報へのＲｅａｄ権限を付与する（ステップＳ２７２４）。第三者のＰＤＳ２７０２は、個人情報取得権限を自動で設定され、診察に利用するための個人情報にアクセス可能になる。

このように、突然倒れてしまったような緊急時には、特定のＱＲコードを取得するなどして、個人情報を全公開することができる。

（実施例３：上司と部下の打合せ予定情報の共有）
図２８Ａは、実施例３（上司と部下の打合せ予定情報の共有）にかかるユーザ（上司）に設定されるデータの一例を示す説明図である。図２８Ａにおいて、ユーザである「上司」のＰＤＳ２８０１に対しては、たとえば、以下のような関係性、ロール、スクリプト、ルール一覧が設定されている。すなわち、「上司」のＰＤＳ２８０１には、部下Ａに対して『同僚・部下』という関係性が設定されている。また、「上司」のＰＤＳ２８０１には、部下Ａに対して、『予定のＲｅａｄ権限』を与えるというロールが設定されている。

また、「上司」のＰＤＳ２８０１には、『予定書き込みスクリプト』、『判定スクリプト』、『１０分前通知スクリプト』が設定されている。また、『予定を追加したらメンバ（部下）の予定を書き込む（ルール）』、『予定を変更したら通知する（ルール）』、『関係性が定義されたアカウントからのメッセージ受信時には自動承認する（ルール）』、『開始１０分前を通知する（ルール）』というルールが設定されている。

図２８Ｂは、実施例３にかかるユーザ（部下Ａ）に設定されるデータの一例を示す説明図である。図２８Ｂにおいて、ユーザである「部下Ａ」のＰＤＳ２８０２には、上司に対して『同僚・主催者』という関係性が設定されている。また、「部下Ａ」のＰＤＳ２８０２には、上司に対して、『予定のＲｅａｄ／Ｗｒｉｔｅ権限』、『居場所のＲｅａｄ権限』、『資料のＲｅａｄ権限』を与えるというロールが設定されている。また、「部下Ａ」のＰＤＳ２８０２には、『通知スクリプト』、『判定スクリプト』が設定され、『資料を更新したら上司の予定情報を更新するルール』が設定されている。

図２９（図２９Ａ～図２９Ｄ）は、実施例３（上司と部下の打合せ予定情報の共有）の処理の一例を説明する説明図である。図２９Ａにおいて、上司のＰＤＳ２９０１と部下ＡのＰＤＳ２９０２は、あらかじめ「同僚社員」という関係性を持っている。上司のＰＤＳ２９０１は、会議メンバ登録で、部下Ａに承認依頼メッセージを送信する（ステップＳ２９１１）。より具体的には、上司のＰＤＳ２９０１は、自身の打合せ予定の書き込み時に、打合せ予定のメンバに予定情報を読み書きする権限要求メッセージの送信と、同打合せ情報の書き込みをおこなうルールとスクリプトを登録する。

一方、部下ＡのＰＤＳ２９０２は、同僚社員に打合せ予定情報のＲｅａｄ権限を与えるための、判定スクリプトを用意する。そして、メッセージ受信時に自動承認する判定スクリプトを発火するルールを登録する。また、上司を主催者として関係付けをおこなう（ステップＳ２９１２）。

つぎに、上司のＰＤＳ２９０１は、部下Ａをメンバに含んで予定を書き込むことによって、ルールにしたがって、部下Ａに対して権限要求メッセージを送信する。部下Ａは、この権限要求メッセージを自動承認し、上司に打合せ予定情報のＲｅａｄ権限を付与する（ステップＳ２９１３）。上司のＰＤＳ２９０１は、続けて、部下Ａの予定情報に打合せ予定情報を書き込む（ステップＳ２９１４）。さらに、通知用のスクリプトを用意すれば、部下Ａのスマートフォン２９１０へ通知することも可能となる。

このように、メンバを指定して打合せを設定すると、メンバに打合せが通知され、打合せを同期するスクリプトが動作する。これにより、上司と部下Ａの予定情報が共有されることになる。部下ＢのＰＤＳ２９０３に対しても、部下ＡのＰＤＳ２９０２と同様に設定することができる。

図２９Ｂにおいて、部下ＡのＰＤＳ２９０２は、打合せの変化を通知してもらうためのルールの登録依頼を上司のＰＤＳ２９０１に対しておこなう（ステップＳ２９２１）。これに対して、上司のＰＤＳ２９０１は、メッセージ受信時に判定スクリプトで自動承認しルール登録する（ステップＳ２９２２）。そして、打合せの予定変更時には部下ＡのＰＤＳ２９０２に通知する（ステップＳ２９２３）。

このように、打合せの変化を通知してもらうためのルールを上司側に設定依頼する。これにより、状況の動的変化に対しても、確実に情報共有をすることができる。部下ＢのＰＤＳ２９０３に対しても、部下ＡのＰＤＳ２９０２と同様に設定することができる。

図２９Ｃにおいて、上司のＰＤＳ２９０１は、打合せ資料置き場の変化を通知してもらうためにルールを登録するように、部下ＡのＰＤＳ２９０２に対して依頼する（ステップＳ２９３１）。これに対して、部下ＡのＰＤＳ２９０２は、メッセージ受信時に自動承認でルールを登録する（ステップＳ２９３２）。これよって、上司のＰＤＳ２９０１は、部下Ａの資料の完成具合を把握できるようになる（ステップＳ２９３３）。

このように、上司側からメンバの打合せ用資料置き場などの変化を通知してもらうためにメンバ側にルールの設定を依頼することもできる。部下ＢのＰＤＳ２９０３に対しても、部下ＡのＰＤＳ２９０２と同様に設定することができる。

図２９Ｄにおいて、上司のＰＤＳ２９０１は、打合せ１０分前をメンバ（部下ＡのＰＤＳ２９０２を含む）に通知する（ステップＳ２９４１）。これに対して、部下ＡのＰＤＳ２９４２は、打合せ１０分前の通知を受けて居場所情報を上司に公開する（ステップＳ２９４２）。

これにより、打合せ１０分前をメンバに通知することで、打合せ１０分前からは、メンバの居場所がより詳細に提供されるようにすることができる。部下ＢのＰＤＳ２９０３に対しても、部下ＡのＰＤＳ２９０２と同様に設定することができる。

図３０（図３０Ａ～図３０Ｄ）は、セルの機能的構成を用いた、実施例３の処理の一例を説明する説明図である。図３０Ａは、予定の書込までの流れを示している。図３０Ａにおいて、セルＡ３０００は、ユーザＡ（主催者）のセルＰＤＳであり、セルＢ３０５０は、ユーザＢ（参加者）のセルＰＤＳである。また、ユーザＡ（主催者）とユーザＢ（参加者）とは『同僚社員』という関係性が構築されている。

（１）ユーザＡ（主催者）は、セルＡ３０００のデータ書込部３３１１に、打合せの予定を書き込む。データ書込部３３１１に書き込まれた打合せの予定は、予定（のデータベース）３２０１に記憶されるとともに、ロール要求部３３１４に送信される。

（２）ロール要求部３３１４は、セルＢ３０５０のロール判定部３３５５に対して、ユーザＡ（主催者）のアカウント情報とロール情報を送信し、予定の取得および書込権限（予定Ｒ／Ｗ権限）を要求する。ロール判定部３３５５は、関係性取得部３３５６に対して、関係性の取得要求を送信する。関係性取得部３３５６は、関係性の取得要求を受信すると、関係性（のデータベース（アカウント関係性マップ））３２５２に、マッチするアカウント情報があるかを判断する。

（３）アカウント関係性マップ（関係性）３２５２において、マッチするアカウント情報がある、すなわち、ユーザＡ（主催者）のアカウントが「同僚社員」の関係性を持つことがわかったので、関係性取得部３３５６は、その旨をロール判定部３３５５に返信する。

（４）ロール判定部３３５５は、同僚社員は予定Ｒ／Ｗ権限を付与可能であることを確認し、ユーザＡに権限を付与する。具体的には、ロール（のデータベース（アカウントロールマップ）３２５３にアカウント（ユーザＡ）とロール（予定Ｒ／Ｗ権限）とを紐付けするように更新する。

（５）セルＡ３０００のデータ書込部３３１１は、書き込まれた打合せの予定と同じ予定をユーザＢに書き込もうとすると、セルＢ３０５０のアクセス制御部３３５９が、そのアクセス（書込）を許可するか否かを判断する。アクセス制御部３３５９は、ロール（のデータベース（アカウントロールマップおよびロール一覧））３２５３にアクセスして、確認する。

（６）アクセス制御部３３５９は、ロール３２５３に確認した結果、ユーザＡが予定Ｒ／Ｗ権限を持つことが判明するので、書込を許可し、ユーザＡから書き込まれた打合せの予定をセルＢ３０５０の予定（のデータベース）３２５１に記憶する。

図３０Ｂは、関係性の更新について示している。図３０Ｂにおいても、図３０Ａと同様に、セルＡ３０００は、ユーザＡ（主催者）のセルＰＤＳであり、セルＢ３０５０は、ユーザＢ（参加者）のセルＰＤＳである。また、ユーザＡ（主催者）は、ユーザＢ（参加者）との間において『主催者』という関係性が構築されている。

（１）ユーザＢ（参加者）は、打合せ参加を承認する旨の情報を、自らのセルであるセルＢ３０５０のデータ書込部３３６１に書き込む。データ書込部３３６１に書き込まれた打合せ参加を承認する旨の情報は、予定（のデータベース）３２５１に記憶されるとともに、関係性構築部３３５２に送信される。

（２）関係性構築部３３５２は、関係性として、ユーザＡ（主催者）を『主催者』として設定し、関係性（のデータベース）３２５２に記憶する。このようにして、セルＢ３０５０における関係性（のデータベース）３２５２を更新することができる。

図３０Ｃは、打合せ資料の共有について示している。図３０Ｃにおいても、図３０Ａ、図３０Ｂと同様に、セルＡ３０００は、ユーザＡ（主催者）のセルＰＤＳであり、セルＢ３０５０は、ユーザＢ（参加者）のセルＰＤＳである。また、ユーザＡ（主催者）は、ユーザＢ（参加者）との間において『主催者』という関係性が構築されている。

（１）ユーザＡ（主催者）からの指示により、セルＡ３０００のロール要求部３３１４は打合せ資料のＲＥＡＤ権限を、セルＢ３０５０のロール判定部３３５５に対して要求する。

（２）ロール要求部３３１４は、セルＢ３０５０のロール判定部３３５５に対して、ユーザＡ（主催者）のアカウント情報とロール情報を送信し、打合せ資料のＲＥＡＤ権限を要求する。ロール判定部３３５５は、関係性取得部３３５６に対して、関係性の取得要求を送信する。関係性取得部３３５６は、関係性の取得要求を受信すると、関係性（のデータベース（アカウント関係性マップ））３２５２に、マッチするアカウント情報があるかを判断し、ユーザＡ（主催者）が『主催者』の関係性を有する旨をロール判定部３３５５に返信する。ロール判定部３３５５は、その返信を受けて、ユーザＡ（主催者）に打合せ資料のＲＥＡＤ権限を与え、ロール（のデータベース（アカウントロールマップ）３２５３にアカウント（ユーザＡ）とロール（打合せ資料のＲＥＡＤ権限）とを紐付けするように更新する。

（３）つぎに、ユーザＡ（主催者）が、ユーザＢ（参加者）の打合せ資料の取得（読込）を、セルＡ３０００のデータ読込部３３２１に要求すると、データ読込部３３２１は、セルＢ３０５０のアクセス制御部３３５９に対して、打合せ資料の取得を要求する。アクセス制御部３３５９は、ロール３２５３を参照して、ユーザＡ（主催者）が、打合せ資料のＲＥＡＤ権限を有していることを確認し、データベース３２５４に記憶されている打合せ資料を取得（読込）し、セルＡ３０００のデータ読込部３３２１へ送信する。これによって、ユーザＡ（主催者）は、打合せ資料を取得することができ、打合せ資料の共有が実現する。

このように、打合せ資料を共有するように構成することによって、データを公開する側の情報（状況）が変化して、データや権限を変えることができる。主催者は、参加者全員の準備ができ次第、打合せの日程を決定するために、参加者の資料が公開されたら日付決定処理をするように条件を設定しておくことができる。また、参加者は、資料の作成完了時に主催者に資料を公開することができる。

また、主催者のもとに、参加者全員からの資料公開がなされれば、日付決定処理がおこなわれるようにすることができる。また、ある一定期間待っても資料が公開されない場合は、公開されていない参加者に通知をおこなったり、参加者打合せの開催の延期をおこなうことができる。

図３０Ｄは、１０分前の居場所の共有について示している。図３０Ｄにおいても、図３０Ａ～図３０Ｃと同様に、セルＡ３０００は、ユーザＡ（主催者）のセルＰＤＳであり、セルＢ３０５０は、ユーザＢ（参加者）のセルＰＤＳである。また、ユーザＡ（主催者）は、ユーザＢ（参加者）との間において『主催者』という関係性が構築されている。

（１）ロール要求部３３１４は、セルＢ３０５０のロール判定部３３５５に対して、ユーザＡ（主催者）のアカウント情報とロール情報を送信し、１０分前に居場所の取得する権限を要求する。
（２）ロール判定部３３５５は、関係性取得部３３５６に対して、関係性の取得要求を送信する。関係性取得部３３５６は、関係性の取得要求を受信すると、関係性（のデータベース（アカウント関係性マップ））３２５２に、マッチするアカウント情報があるかを判断し、ユーザＡ（主催者）が『主催者』の関係性を有する旨をロール判定部３３５５に返信する。ロール要求部３３５５は、その返信を受けて、ユーザＡ（主催者）に１０分前に居場所の取得する権限を与え、ロール（のデータベース（アカウントロールマップ）３２５３にアカウント（ユーザＡ）とロール（１０分前に居場所の取得する権限）とを紐付けするように更新する。

（３）つぎに、ユーザＡ（主催者）が、ユーザＢ（参加者）の居場所の取得（読込）を、セルＡ３０００のデータ読込部３３２１に要求すると、データ読込部３３２１は、セルＢ３０５０のアクセス制御部３３５９に対して、居場所の取得を要求する。アクセス制御部３３５９は、ロール３２５３を参照して、ユーザＡ（主催者）が、１０分前に居場所の取得する権限を有していることを確認し、データベース３２５４に記憶されている居場所に関する情報を取得（読込）し、セルＡ３０００のデータ読込部３３２１へ送信する。これによって、ユーザＡ（主催者）は、ユーザＢ（参加者）の居場所を取得することができ、１０分前の居場所の共有が実現する。

このように、打合せ１０分前の居場所を共有するように構成することによって、たとえば、部下は、打合せ予定の参加を承認すると依頼主を主催者として関係性を構築するルールとスクリプトを設定することができる。部下が、上司からの予定の参加を承認する。それにともなって、そのルールにより依頼主を主催者として関係性を設定することができる。

また、上司が、打合せ１０分前に、居場所情報の権限取得要求メッセージを送信すると、部下は、メッセージ受信に対応して自動承認スクリプトを発火し、関係性（主催者）を判断したのち、権限を自動承認することができる。これにより、上司は、居場所情報取得権限を自動で設定され、部下の居場所情報にアクセス可能になる。また、打合せ終了時には、上司に対する権限と関係性（打合せ主催者）を破棄することができる。

なお、本実施の形態で説明した情報処理方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。表示制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ Ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、表示制御プログラムは、インターネットなどのネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、
前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御する、
制御部を有することを特徴とする情報処理装置。

（付記２）前記制御部は、前記アカウントが前記関係性に関する条件を満たす場合に、前記アカウントに対して前記アクセス権限を認めることを特徴とする付記１に記載の情報処理装置。

（付記３）前記制御部は、前記アカウントによるアクセスが前記状況に関する条件を満たす場合に、前記アカウントに対して前記アクセス権限を認めることを特徴とする付記１または２に記載の情報処理装置。

（付記４）前記制御部は、前記ユーザの個人データに基づいて、前記アカウントによるアクセスが前記状況に関する条件を満たすかを判断することを特徴とする付記３に記載の情報処理装置。

（付記５）前記制御部は、前記ユーザの承認があった場合に、前記アクセス権限を認めることを特徴とする付記２～４のいずれか一つに記載の情報処理装置。

（付記６）前記制御部は、前記アクセス権限と、前記アクセス権限に対応する前記関係性および前記条件に関する条件とを関連付けして記憶し、
記憶された前記条件に基づいて、前記アクセス権限を制御することを特徴とする付記１～５のいずれか一つに記載の情報処理装置。

（付記７）前記制御部は、前記アカウントの前記ユーザとの関係性を、あらかじめ定められたルールに基づいて構築し、
構築された前記アカウントの前記ユーザとの関係性に関する情報に基づいて、前記アカウントが前記関係性に関する条件を満たすかを判断することを特徴とする付記２に記載の情報処理装置。

（付記８）第１のサーバから、第２のサーバの個人ごとのデータ領域に格納されたユーザの個人データに、ネットワークを介してアクセスするにあたり、
前記第２のサーバは、前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御することを特徴とする情報処理システム。

（付記９）前記第２のサーバは、前記アクセス権限と、前記アクセス権限に対応する前記関係性および前記条件に関する条件とを関連付けして記憶し、
記憶された前記条件に基づいて、前記アクセス権限を制御することを特徴とする付記８に記載の情報処理システム。

（付記１０）個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、
前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントに対する前記ユーザの個人データへのアクセス権限を制御する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。

１００、１５０ 分散型ＰＤＳサーバ（情報処理装置）
１０１、１５１ セル（ＰＤＳ）
１０２、１５２ パーソナルデータ管理機能
１０３、１５３ ソーシャル管理機能
１１０、１６０ ユーザ端末装置
３０４ 関係性ルール
３０５ アカウント関係性マップ
３０６ ロール判定マップ
３０７ データベース
３０８ アカウントロールマップ
３０９ ロール一覧
３１１ データ書込部
３１２ 関係性構築部
３１３ ロール条件登録部
３１４ ロール要求部
３１５ ロール判定部
３１６ 関係性取得部
３１７ 状況取得部
３１８ ユーザ承認部
３１９ アクセス制御部

Claims (5)

1. 個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、
   前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントが前記関係性に関する条件および前記アカウントによるアクセスが前記状況に関する条件を満たす場合に、前記ユーザが前記アカウントに対して与えた前記アカウントがおこなうことができるロールに基づく、前記アカウントに対する前記ユーザの個人データへのアクセス権限を認める、
   制御部を有することを特徴とする情報処理装置。
2. 前記制御部は、前記ユーザの個人データに基づいて、前記アカウントによるアクセスが前記状況に関する条件を満たすかを判断することを特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、前記ユーザの承認があった場合に、前記アクセス権限を認めることを特徴とする請求項１または２に記載の情報処理装置。
4. 第１のサーバから、第２のサーバの個人ごとのデータ領域に格納されたユーザの個人データに、ネットワークを介してアクセスするにあたり、
   前記第２のサーバは、前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントが前記関係性に関する条件および前記アカウントによるアクセスが前記状況に関する条件を満たす場合に、前記ユーザが前記アカウントに対して与えた前記アカウントがおこなうことができるロールに基づく、前記アカウントに対する前記ユーザの個人データへのアクセス権限を認めることを特徴とする情報処理システム。
5. 個人ごとのデータ領域に格納されたユーザの個人データにアクセスするにあたり、
   前記ユーザの個人データにアクセスするアカウントの前記ユーザとの関係性と、前記アカウントが前記ユーザの個人データにアクセスする状況とに基づいて、前記アカウントが前記関係性に関する条件および前記アカウントによるアクセスが前記状況に関する条件を満たす場合に、前記ユーザが前記アカウントに対して与えた前記アカウントがおこなうことができるロールに基づく、前記アカウントに対する前記ユーザの個人データへのアクセス権限を認める、
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。
   
   
   

Images