特許 7310616 サーバ装置、データ処理方法、および通信プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-07-10

(45)【発行日】2023-07-19

(54)【発明の名称】サーバ装置、データ処理方法、および通信プログラム

(51)【国際特許分類】

   G06F 21/62 20130101AFI20230711BHJP

   G06F 21/30 20130101ALI20230711BHJP

【ＦＩ】

G06F21/62 345

G06F21/30

【請求項の数】 5

(21)【出願番号】P 2020006598

(22)【出願日】2020-01-20

(65)【公開番号】P2021114141

(43)【公開日】2021-08-05

【審査請求日】2022-09-08

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(72)【発明者】

【氏名】小倉 孝夫

【審査官】平井 誠

(56)【参考文献】

【文献】特開２０１５－１１８６３４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１３／００４７２４９（ＵＳ，Ａ１）

【文献】特開２０１７－０９１２０７（ＪＰ，Ａ）

【文献】小倉 孝夫 他，分散データにおける同意制御方式の提案，２０１９年 暗号と情報セキュリティシンポジウム（ＳＣＩＳ２０１９）予稿集，日本，２０１９年 暗号と情報セキュリティシンポジウム実行，2019年01月15日，1C2-4, pages 1-7

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／００－８８

(57)【特許請求の範囲】

【請求項1】

クライアント装置から送信される、属性情報、データ項目、および品質要求を含むデータリクエストを、リソースサーバを介して受信し、
前記属性情報および前記データ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信し、
前記リソースサーバから前記第１のトークンを受信したときに、前記第１のトークンの検証結果、及び、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信し、
前記リソースサーバから前記第２のトークンを受信したときに、前記第２のトークンの検証結果を前記リソースサーバに送信する
処理をコンピュータに実行させる通信プログラム。

【請求項2】

前記データリクエストを受信したときに、チケットを発行して前記リソースサーバに送信し、
前記クライアント装置から前記チケットを受信したときに、前記第１のトークンおよび前記第２のトークンを前記クライアント装置に送信する
ことを特徴とする請求項１に記載の通信プログラム。

【請求項3】

クライアント装置から送信される、属性情報、データ項目、および品質要求を含むデータリクエストを、リソースサーバを介して受信する受信部と、
前記属性情報および前記データ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信する第１の処理部と、
前記リソースサーバから前記第１のトークンを受信したときに、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信する第２の処理部と、
前記リソースサーバから前記第２のトークンを受信したときに、前記第２のトークンの検証結果を前記リソースサーバに送信する第３の処理部と、
を備えるサーバ装置。

【請求項4】

前記データリクエストを受信したときに、チケットを発行して前記リソースサーバに送信する第４の処理部をさらに備え、
前記第１の処理部は、前記クライアント装置から前記チケットを受信したときに、前記第１のトークンおよび前記第２のトークンを前記クライアント装置に送信する
ことを特徴とする請求項３に記載のサーバ装置。

【請求項5】

リソースサーバに保存されている個人データをクライアント装置に提供するデータ処理方法であって、
前記クライアント装置は、属性情報、データ項目、および品質要求を含むデータリクエストを前記リソースサーバに送信し、
前記リソースサーバは、前記データリクエストを認可サーバに転送し、
前記認可サーバは、前記データリクエストに含まれる属性情報およびデータ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信し、
前記クライアント装置は、前記第１のトークンを前記リソースサーバに送信し、
前記リソースサーバは、前記第１のトークンを前記認可サーバに転送し、
前記認可サーバは、前記リソースサーバから受信する第１のトークンが前記クライアント装置に送信した第１のトークンと一致するときは、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信し、
前記リソースサーバは、前記識別情報により識別されるデータオーナーの個人データの品質を表す品質情報を前記クライアント装置に送信し、
前記クライアント装置は、前記品質情報を受信した後に、前記第２のトークンを前記リソースサーバに送信し、
前記リソースサーバは、前記識別情報により識別されるデータオーナーの個人データを前記クライアント装置に送信する
ことを特徴とするデータ処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ装置、データ処理方法、および通信プログラムに係わる。

【背景技術】

【0002】

近年、個人データの利用を図るために、ＰＤＳ（Personal Data Store）または情報銀行などのサービスが注目されている。ＰＤＳ／情報銀行は、ユーザから預かった個人データを第３者（すなわち、データ利用者）に提供する。ただし、あるユーザの個人データをデータ利用者に提供する際には、そのユーザの同意が必要である。このため、個人データを流通させる際にユーザ（すなわち、個人データのオーナー）の同意を取得する方法が提案されている。例えば、OAuth2.0あるいはUMA2.0が広く知られている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１８－１７３９１７号公報

【文献】特開２０１９－０７０９２１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

個人データは、多くのケースにおいて、品質のばらつきが大きい。このため、データ利用者は、品質の低い個人データを取得することがある。例えば、データの一部が欠落していることがある。また、データが誤った値（或いは、ありえない値）を含むことがある。そして、取得した個人データの品質が低いと、データ利用者は、その個人データを十分に活用できない。

【0005】

本発明の１つの側面に係わる目的は、データ利用者が所望の品質の個人データを取得できるようにすることである。

【課題を解決するための手段】

【0006】

本発明の１つの態様の通信プログラムは、クライアント装置から送信される、属性情報、データ項目、および品質要求を含むデータリクエストを、リソースサーバを介して受信し、前記属性情報および前記データ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信し、前記リソースサーバから前記第１のトークンを受信したときに、前記第１のトークンの検証結果、及び、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信し、前記リソースサーバから前記第２のトークンを受信したときに、前記第２のトークンの検証結果を前記リソースサーバに送信する、処理をコンピュータに実行させる。

【発明の効果】

【0007】

上述の態様によれば、データ利用者は、所望の品質の個人データを取得できる。

【図面の簡単な説明】

【0008】

【図1】本発明の実施形態に係わるデータ処理システムの一例を示す図である。

【図2】データ処理システムの動作の一例を示す図である。

【図3】リソースサーバに保存される個人データの一例を示す図である。

【図4】リソースサーバから個人データを取得するシーケンスの一例を示す図である。

【図5】本発明の実施形態に係わるデータ処理方法のシーケンスの一例を示す図である。

【図6】同意ポータルサーバの構成の一例を示す図である。

【図7】同意ポータルサーバにおいて管理されるテーブルの例を示す図である。

【図8】リソースサーバの構成の一例を示す図である。

【図9】リソースサーバに保存されるデータの構成の一例を示す図である。

【図10】同意ポータルサーバの処理の一例を示すフローチャート（その１）である。

【図11】同意ポータルサーバの処理の一例を示すフローチャート（その２）である。

【図12】同意ポータルサーバの処理の一例を示すフローチャート（その３）である。

【図13】リソースサーバの処理の一例を示すフローチャート（その１）である。

【図14】リソースサーバの処理の一例を示すフローチャート（その２）である。

【図15】第１の実施例におけるデータ処理のシーケンスを示す図である。

【発明を実施するための形態】

【0009】

図１は、本発明の実施形態に係わるデータ処理システムの一例を示す。本発明の実施形態に係わるデータ処理システム１００は、リソースサーバ１、クライアント装置２、および同意ポータルサーバ３を含む。リソースサーバ１、クライアント装置２、および同意ポータルサーバ３は、ネットワーク４に接続されている。ネットワーク４は、特に限定されるものではないが、例えば、インターネットである。

【0010】

リソースサーバ（データ提供者）１は、個人データを保存する。個人データは、この実施例では、端末５から受信する。クライアント装置（データ利用者）２は、リソースサーバに保存されている個人データを取得する。同意ポータルサーバ３は、リソースサーバ１からクライアント装置２への個人データの提供を仲介する。また、同意ポータルサーバ３は、リソースサーバ１に保存されている個人データを第３者に提供することについて、個人データのオーナーの同意を取得する。以下の記載では、個人データのオーナーを「データオーナー（または、リソースオーナー）」と呼ぶことがある。

【0011】

図２は、データ処理システム１００の動作の一例を示す。この例では、リソースサーバ１は、健康センターに設けられる。クライアント装置２は、ヘルスケアサービスを提供するヘルスケアサービス会社に設けられる。

【0012】

健康センターは、データオーナーの健康データを収集する。すなわち、データオーナーは、自分の健康データを健康センターに提供する。健康データは、個人データの一例であり、この例では、図３に示すように、データオーナーの体重、血圧、歩数、睡眠時間などを含む。具体的には、データオーナーは、健康データとして、毎日、自分の体重、血圧、歩数、睡眠時間などを測定する。そして、データオーナーは、例えば、ユーザ端末５ａを利用して、測定した健康データをリソースサーバ１に送信する。この結果、データオーナーの健康データがリソースサーバ１に蓄積される。なお、図２～図３に示す例では、１人のデータオーナーの個人データがリソースサーバ１に保存されているが、実際には、多数のデータオーナーの個人データがリソースサーバ１に蓄積される。

【0013】

ヘルスケアサービス会社は、多数のデータオーナーの健康データを分析して健康改善のための健康サービス情報を作成する。健康サービス情報は、例えば、健康データを提供したデータオーナーに送られる。また、ヘルスケアサービス会社は、データオーナーの同意に基づいて健康サービス情報を販売することもできる。例えば、ヘルスケアサービス会社は、病院または医師に健康サービス情報を販売する。このように、ヘルスケアサービス会社は、健康センターから健康データを取得し、取得した健康データを利用して健康サービス情報を作成する。

【0014】

同意ポータルサーバ３は、認可サーバ（Authorization Server）の一例であり、この実施例では、個人データの流通を仲介する仲介サービス会社に設けられる。仲介サービス会社は、データオーナーが自分の健康データを健康センターに提供するときに、その健康データを第３者に提供することについて、データオーナーの同意を取得する。このとき、データオーナーは、例えば、ユーザ端末５ａを利用して、属性情報を同意ポータルサーバ３に送信する。属性情報は、データオーナーの氏名、住所、性別、生年月日（または、年齢）などを含む。そして、同意ポータルサーバ３は、各データオーナーの属性情報に関連づけて、健康データが第３者に提供されることについての同意の有無を管理する。

【0015】

図４は、リソースサーバ１から個人データを取得するシーケンスの一例を示す。この例では、リソースサーバ１に多数のデータオーナーの健康データが保存されている。また、クライアント装置２は、リソースサーバ１に保存されている健康データを取得する。

【0016】

データオーナーは、自分の健康データを健康センターに提供する。すなわち、ユーザ端末５ａからリソースサーバ１にデータオーナーの健康データが送信される。そうすると、このデータオーナーの健康データがリソースサーバ１に保存される。ユーザ端末５ａは、例えば、スマートフォン、タブレット、またはパーソナルコンピュータである。

【0017】

データオーナーは、自分の健康データの取り扱いについて、仲介サービス会社と契約する。この実施例では、データオーナーは、ヘルスケアサービス会社が提供するサービスを受けるときに、仲介サービス会社と契約する。ここで、データオーナーは、自分の健康データが第３者（ヘルスケアサービス会社）により利用されることについて同意するものとする。すなわち、仲介サービス会社は、ヘルスケアサービス会社の代わりにデータオーナーの同意を取得する。

【0018】

データオーナーは、仲介サービス会社との契約において、アクセス制御ポリシを設定することができる。例えば、データオーナーは、アクセス制御ポリシとして、健康データの一部（例えば、体重）について第３者への提供を許可しない旨を設定してもよい。

【0019】

なお、データオーナーと仲介サービス会社との間の契約は、ユーザ端末５ａおよび同意ポータルサーバ３を介して行われる。この場合、例えば、同意ポータルサーバ３から提供される入力フォームがユーザ端末５ａのディスプレイに表示される。そして、データオーナーは、この入力フォームを利用して必要な情報を入力する。この結果、データオーナーの属性情報に関連づけて、健康データが第３者に提供されることについての同意を表す情報が、同意ポータルサーバ３に保存される。

【0020】

ヘルスケアサービス会社は、健康センターに蓄積されている健康データを取得したいときには、健康センターに所望するデータを要求する。このとき、クライアント装置２からリソースサーバ１にデータリクエストが送信される。データリクエストは、この実施例では、属性情報およびデータ項目を指定する。属性情報は、データオーナーの属性を指定する。例えば、属性情報は、年代および性別を指定する。データ項目は、ヘルスケアサービス会社が必要とするデータの項目を指定する。データリクエストの一例を示す。
（１）年代：５０～５９歳
（２）性別：男
（３ａ）体重
（３ｂ）血圧
（３ｂ）歩数
データリクエストの内容は、例えば、ＵＲＩを用いて指定される。なお、リソースサーバ１は、ＵＲＩに基づいて、要求されたデータを識別できるものとする。

【0021】

リソースサーバ１は、クライアント装置２から受信したデータリクエストを同意ポータルサーバ３に転送する。そうすると、同意ポータルサーバ３は、リソースサーバ１から受信したデータリクエストを保持すると共に、同意ポータルサーバ３にアクセスするためのチケットを発行する。このチケットは、例えば、ＵＭＡ２．０で使用されるチケットであってもよい。そして、同意ポータルサーバ３は、このチケットをリソースサーバ１に送信する。

【0022】

リソースサーバ１は、同意ポータルサーバ３により発行されたチケットをクライアント装置２に送信する。このとき、リソースサーバ１は、同意ポータルサーバ３にアクセスするためのＵＲＩをクライアント装置２に通知する。

【0023】

クライアント装置２は、リソースサーバ１から受信したチケットを同意ポータルサーバ３に送信する。このとき、クライアント装置２は、リソースサーバ１から通知されたＵＲＩを使用して同意ポータルサーバ３にアクセスする。

【0024】

同意ポータルサーバ３は、クライアント装置２から受信したチケットが正規のチケットであるか否かを判定する。このとき、クライアント装置２から受信したチケットが、同意ポータルサーバ３により発行されたチケットと一致すれば、クライアント装置２から受信したチケットが正規のチケットであると判定される。そして、クライアント装置２から正規のチケットを受信したときは、同意ポータルサーバ３は、トークンを発行する。このトークンは、リソースサーバ１から健康データを取得することを許可する。そして、同意ポータルサーバ３は、このトークンをクライアント装置２に送信する。

【0025】

クライアント装置２は、同意ポータルサーバ３により発行されたトークンをリソースサーバ１に送信する。そうすると、リソースサーバ１は、クライアント装置２から受信したトークンが有効であるか否かを確認するために、そのトークンを同意ポータルサーバ３に送信する。

【0026】

同意ポータルサーバ３は、リソースサーバ１から受信したトークンが有効か否かを判定する。このとき、リソースサーバ１から受信したトークンが、同意ポータルサーバ３により発行されたトークンと一致すれば、リソースサーバ１から受信したトークンが有効であると判定される。そして、受信したトークンが有効であるときは、同意ポータルサーバ３は、クライアント装置２から送信されたデータリクエストに基づいて、データオーナーリストを作成する。

【0027】

データオーナーリストは、下記の２つの要件を満足するデータオーナーの識別情報を含む。
（１）クライアント装置２から送信されたデータリクエストに含まれるデータ項目に係わる個人データの提供に同意している。
（２）クライアント装置２から送信されたデータリクエストに含まれる属性情報に対応する。

【0028】

ここで、各データオーナーが個人データの提供について同意するか否かを表す情報は、同意ポータルサーバ３のデータベースに保存されている。また、仲介サービス会社は、健康データの提供に係わる契約を行ったデータオーナーの属性情報を取得している。すなわち、同意ポータルサーバ３は、各データオーナーの属性情報を保持している。よって、同意ポータルサーバ３は、上記２つの要件を満足するデータオーナーを特定できる。たとえば、上述の実施例では、健康データの提供に同意しているデータオーナーの中で、「年齢：５０～５９歳」かつ「性別：男性」に該当するデータオーナーが特定される。そして、同意ポータルサーバ３は、特定したデータオーナーを表す識別情報を含むデータオーナーリストを作成する。

【0029】

同意ポータルサーバ３は、作成したデータオーナーリストをリソースサーバ１に送信する。このとき、同意ポータルサーバ３は、データベースから抽出すべきデータ項目をリソースサーバ１に通知してもよい。なお、データベースから抽出すべきデータ項目は、クライアント装置２から送信されたデータリクエストにおいて指定されている。上述の実施例では、抽出すべきデータ項目として「体重、血圧、歩数」が同意ポータルサーバ３からリソースサーバ１に通知される。

【0030】

リソースサーバ１は、同意ポータルサーバ３から受信するデータオーナーリストおよびデータ項目に従って、リソースサーバ１のデータベースから、ヘルスケアサービス会社が希望する属性のデータオーナーの健康データを抽出する。上述の実施例では、「年齢：５０～５９歳」かつ「性別：男性」に該当するデータオーナーの健康データが抽出され、更にその中から体重データ、血圧データ、歩数データが抽出される。そして、リソースサーバ１は、抽出した健康データをクライアント装置２に送信する。この結果、ヘルスケアサービス会社は、希望する個人データを取得する。

【0031】

このように、図４に示すシーケンスによれば、ヘルスケアサービス会社に代わって仲介サービス会社が一括して各データオーナーの同意を取得する。したがって、ヘルスケアサービス会社は、各データオーナーの同意を取得する作業を行うことなく、多数の健康データを取得できる。なお、図４に示すシーケンスは、ＵＭＡ２．０に基づいている。

【0032】

ところが、個人データは、不完全なことがある。例えば、健康データは、データオーナー自身が測定を行うことで生成される。このため、データオーナーが測定を忘れると、データの一部が欠落することになる。図３に示す例では、２０１９年７月３日の体重データが欠落している。また、データオーナー自身がユーザ端末５ａに測定データを入力する場合には、誤った値が入力されるおそれがある。例えば、体重データとして、正しくは「６４．５ｋｇ」であるにもかかわらず、「６４５ｋｇ」と入力されるケースなどが考えられる。そして、健康データが不完全なときは、ヘルスケアサービス会社は、有効な分析を行うことができない。

【0033】

このように、個人データの取引においては、リソースサーバ１から取得した個人データの品質が低いことがある。そして、品質が低い個人データが提供される状況では、個人データの取引の発展は難しい。そこで、本発明の実施形態に係わるデータ処理方法は、個人データの品質を表す情報を提供する機能を備える。すなわち、本発明の実施形態に係わるデータ処理方法においては、データ利用者は、リソースサーバ１から個人データを取得する前に、その個人データの品質を確認することができる。

【0034】

＜実施形態＞
図５は、本発明の実施形態に係わるデータ処理方法のシーケンスの一例を示す。この実施例においても、図４に示すケースと同様に、リソースサーバ１に多数のデータオーナーの健康データが保存されている。また、データオーナーと仲介サービス会社との間の契約は、図４および図５において実質的に同じであるものとする。

【0035】

クライアント装置２がリソースサーバ１にデータリクエストを送信する工程からクライアント装置２が同意ポータルサーバ３にデータリクエストを送信する工程までの手順（図５では、Ｓ１～Ｓ５）は、図４および図５において実質的に同じである。ただし、本発明の実施形態においてクライアント装置２から送信されるデータリクエストは、図５に示すように、品質要求を含む。品質要求は、クライアント装置２がリソースサーバ１から取得しようとする個人データの品質を表す情報を要求する。

【0036】

品質要求を含むデータリクエストは、例えば、ＵＲＩで表される。この場合、データリクエストを表すＵＲＩは、下記のパス情報を含む。
/operation/quality/pseudonymID_gender_ageRange_(weight_bloodPressure_steps)
「quality」は、個人データの品質を表す情報の作成を要求する。「pseudonymID」は、データオーナーの実名ではなく仮名を要求する。「gender」および「ageRange」は、属性情報の一例であり、「性別」および「年齢（または、年齢の範囲）」を表す。そして、「weight_bloodPressure_steps」は、データ項目の一例であり、「体重」「血圧」「歩数」を表す。

【0037】

また、データリクエストの内容は、下記のようにクリエ（？）で表してもよい。
/operation/quality?pseudonymID_gender_ageRange_(weight_bloodPressure_steps)

【0038】

同意ポータルサーバ３は、Ｓ５においてクライアント装置２から送信されるチケットを受信すると、そのチケットが正規のチケットであるか否かを判定する。そして、クライアント装置２から正規のチケットを受信したときは、同意ポータルサーバ３は、ＱトークンおよびＡトークンを発行する。Ｑトークンは、クライアント装置２から送信されたデータリクエストに含まれる属性情報およびデータ項目に対応する個人データの品質を表す品質情報を要求する。Ａトークンは、図４に示すシーケンスで使用されるトークンと同様に、クライアント装置２から送信されたデータリクエストに含まれる属性情報およびデータ項目に対応する個人データを要求する。そして、同意ポータルサーバ３は、Ｓ６において、ＱトークンおよびＡトークンをクライアント装置２に送信する。

【0039】

クライアント装置２は、Ｓ７において、同意ポータルサーバ３により発行されたＱトークンをリソースサーバ１に送信する。そうすると、リソースサーバ１は、Ｓ８において、クライアント装置２から受信したＱトークンが有効であるか否かを確認するために、そのＱトークンを同意ポータルサーバ３に転送する。

【0040】

同意ポータルサーバ３は、リソースサーバ１から受信したＱトークンが有効か否かを判定する。このとき、リソースサーバ１から受信したＱトークンが、同意ポータルサーバ３により発行されたＱトークンと一致すれば、リソースサーバ１から受信したＱトークンが有効であると判定される。そして、受信したＱトークンが有効であるときは、同意ポータルサーバ３は、クライアント装置２から送信されたデータリクエストに基づいて、データオーナーリストを作成する。

【0041】

データオーナーリストを作成する方法は、図４を参照して説明した方法と実質的に同じである。すなわち、健康データの提供に同意しているデータオーナーの中から、クライアント装置２から送信されたデータリクエストに含まれる属性情報に対応するデータオーナーが特定される。そして、同意ポータルサーバ３は、特定したデータオーナーを表す識別情報を含むデータオーナーリストを作成する。データオーナーリストは、Ｓ９において、同意ポータルサーバ３からリソースサーバ１に送信される。

【0042】

リソースサーバ１は、Ｓ１においてクライアント装置２から受信したデータリクエストおよびＳ９において同意ポータルサーバ３から受信したデータオーナーリストに基づいて、リソースサーバ１のデータベースから、ヘルスケアサービス会社が希望する属性に対応するデータオーナーの健康データを抽出する。上述の例では「年齢：５０～５９歳」かつ「性別：男性」に該当するデータオーナーの健康データが抽出され、更にその中から「体重データ、血圧データ、歩数データ」が抽出される。

【0043】

ただし、リソースサーバ１は、Ｓ７においてクライアント装置２からＱトークンを受信している。よって、リソースサーバ１は、上述のようにして抽出した健康データの品質を表す品質情報を作成する。そして、リソースサーバ１は、Ｓ１０において、品質情報をクライアント装置２に送信する。なお、品質情報を作成する方法は、後で詳しく説明する。

【0044】

ヘルスケアサービス会社は、リソースサーバ１から送信される品質情報を取得する。ここで、この品質情報は、ヘルスケアサービス会社が取得しようとする個人データの品質を表す。よって、ヘルスケアサービス会社は、リソースサーバ１が提供する個人データの価値を評価できる。

【0045】

この実施例では、ヘルスケアサービス会社は、Ｑトークンを利用して取得した品質情報を検討した結果、リソースサーバ１が提供する個人データを取得するものとする。この場合、Ｓ１１において、クライアント装置２からリソースサーバ１にＡトークンが送信される。なお、Ａトークンは、上述したように、クライアント装置２から送信されたデータリクエストに含まれる属性情報およびデータ項目に対応する個人データを要求する。

【0046】

クライアント装置２は、Ｓ１２において、クライアント装置２から受信したＡトークンが有効であるか否かを確認するために、そのＡトークンを同意ポータルサーバ３に転送する。同意ポータルサーバ３は、リソースサーバ１から受信したＡトークンが有効か否かを検証する。このとき、リソースサーバ１から受信したＡトークンが、同意ポータルサーバ３が発行したＡトークンと一致すれば、リソースサーバ１から受信したＡトークンが有効であると判定される。そして、同意ポータルサーバ３は、Ｓ１３において、この検証結果をリソースサーバ１に送信する。

【0047】

リソースサーバ１は、同意ポータルサーバ３からＡトークンの検証結果を受信する。この実施例では、Ａトークンが有効であるものとする。そうすると、同意ポータルサーバ３は、データリクエストにより指定された健康データをクライアント装置２に送信する。この結果、ヘルスケアサービス会社は、希望する個人データを取得する。

【0048】

このように、本発明の実施形態に係わるデータ処理方法によれば、ヘルスケアサービス会社に代わって仲介サービス会社が一括して各データオーナーの同意を取得する。したがって、ヘルスケアサービス会社は、各データオーナーの同意を取得する作業を行うことなく、多数の健康データを取得することができる。加えて、ヘルスケアサービス会社は、実際に個人データを取得する前に、その個人データの品質を確認できる。したがって、ヘルスケアサービス会社は、品質のよい価値のある個人データを取得できる。換言すれば、ヘルスケアサービス会社は、品質の悪い個人データを購入しないようにできる。なお、図５に示すシーケンスも、ＵＭＡ２．０に基づいている。

【0049】

次に、品質情報を作成する方法について記載する。品質情報は、この実施例では、ＩＳＯ２５０１２をベースにして作成される。すなわち、個人データについて、最新性、完全性、正確性、一貫性、信憑性に係わる品質情報が作成される。これに加えて、データ量および分散性に係わる品質情報も作成される。

【0050】

（１）データ量
データ量は、統計処理を行うことが可能なデータ量を表す。すなわち、データ量は、母集団におけるサンプル数を表す。例えば、サンプル数が５００の市場調査において、性別／年齢別の分析を行うときは、各属性について３０以上のサンプルが必要と考えられる。

【0051】

（２）分散性
分散性は、データが一様に分布しているか、偏在しているかを表す。例えば、１０代～６０代の各年代に属するサンプル数が互いに同程度であれば、一様に分布していると判定される。

【0052】

（３）最新性
最新性は、データが新しいか否かを表す。例えば、健康データが過去１年以内に測定されていれば、最新性が高いと判定される。

【0053】

（４）正確性
正確性は、データが正しいか否かを表す。また、正確性は、データが指定されたフォーマットで表記されているか否かを表す。例えば、血圧値が「１０００」であれば、あり得ない値なので、正確性が低いと判定される。また、最低血圧および最高血圧の表記において、２つの値の間を「／（スラッシュ）」で区切ることが決まっている場合に、２つの値が「，（カンマ）」で区切られていれば、正確性が低いと判定される。

【0054】

（５）完全性
完全性は、関連するデータが欠落しているか否かを表す。図３に示す例では、２０１９年７月３日の体重データが欠落している。

【0055】

（６）一貫性
一貫性は、論理的な矛盾の有無を表す。例えば、年齢の欄に「２０歳」と記載されているにもかかわらず、生年月日の欄に「２００５年１月１日」と記載されている場合は、一貫性がないと判定される。

【0056】

（７）信憑性
信憑性は、データの収集方法または検証方法などの観点から、そのデータの内容を信頼できるか否かを表す。例えば、データオーナーの身元を表す情報が運転免許証またはパスポートであれば、信憑性が高いと判定される。

【0057】

そして、リソースサーバ１は、Ｑトークンを受信したときは、上記７個の評価項目のうちの１以上の評価項目について、指定された個人データの品質情報を作成する。そして、リソースサーバ１は、作成した品質情報をクライアント装置２に送信する。

【0058】

図６は、同意ポータルサーバ３の構成の一例を示す。同意ポータルサーバ３は、図６に示すように、プロセッサ１０、保存部２０、および通信部３０を備える。ただし、同意ポータルサーバ３は、図６に示していない他の機能またはデバイスを備えてもよい。

【0059】

プロセッサ１０は、不図示の記憶装置に格納されている通信プログラムを実行することにより、同意ポータルサーバ３の機能を提供する。すなわち、プロセッサ１０は、不図示の記憶装置に格納されている通信プログラムを実行することにより、少なくとも、後述する同意管理部１１、リクエスト管理部１２、トークン管理部１３、およびリスト作成部１４の機能を提供する。

【0060】

保存部２０には、同意ポータルサーバ３が使用するデータおよび／または情報が保存される。具体的には、保存部２０には、少なくとも、リソース管理テーブル、データオーナー管理テーブル、およびリクエスト管理テーブルが保存される。

【0061】

リソース管理テーブルには、図７（ａ）に示すように、同意ポータルサーバ３が仲介するリソースが登録される。具体的には、各リソースについて、データ提供者、データ名、およびデータ項目が記録される。リソース管理テーブルは、例えば、データ提供者（図２では、健康センター）と仲介者（図２では、仲介サービス会社）との間の契約に基づいて作成される。

【0062】

データオーナー管理テーブルには、図７（ｂ）に示すように、各データオーナーの属性情報（氏名、住所、性別、生年月日など）、仮名ＩＤ、リソースＩＤ、ポリシ情報、同意情報などが記録される。仮名ＩＤは、データオーナーが特定されることなくそのデータオーナーを表すための識別情報である。この実施例では、「山田ｘｘ」が「２１３４」で表され、「鈴木ｙｙ」が「２１３５」で表されている。なお、仮名ＩＤは、リソースサーバ１および同意ポータルサーバ３において共有されることが好ましい。リソースＩＤは、個々のデータオーナーが提供する個人データを含むリソースを表す。この例では、「山田ｘｘ」の健康データは、健康センターに蓄積されるリソースＲ＿２１３４に含まれている。ポリシ情報は、データオーナーが定義する、データの提供に係わるポリシを表す。たとえば、データオーナーが体重データを提供したくないときは、その旨がポリシ情報として記録される。同意情報は、データオーナーが個人データを第３者の提供することについて同意したか否かを表す。

【0063】

リクエスト管理テーブルには、図７（ｃ）に示すように、クライアント装置２から送信されるデータリクエストが登録される。送信元は、データリクエストの送信元を表す。リクエスト内容は、データ利用者が要求するデータを指定する。なお、リクエスト内容は、ＵＲＩで表されてもよい。また、リクエスト内容は、取得したいデータの品質情報を要求するか否かを表す。さらに、データリクエストに対してトークン（ＱトークンおよびＡトークン）が発行されると、発行されたトークンは、データリクエストに関連づけて保存される。

【0064】

通信部３０は、送信部および受信部を含み、ネットワークに接続するためのインタフェースを提供する。

【0065】

同意管理部１１は、仲介サービス会社とデータオーナーとの間で契約を行うときに、契約に係わる入力フォームをユーザ端末５ａに送信する。そして、同意管理部１１は、入力フォームを利用して入力される情報をデータオーナー管理テーブルに記録する。

【0066】

リクエスト管理部１２は、クライアント装置２から送信されるデータリクエストを処理する。すなわち、リクエスト管理部１２は、クライアント装置２から送信されるデータリクエストを、リソースサーバ１を介して受信すると、そのデータリクエストをリクエスト管理テーブルに登録する。また、リクエスト管理部１２は、受信したデータリクエストに対して、同意ポータルサーバ３にアクセスするためのチケットを発行する。このチケットは、リソースサーバ１に送信される。さらに、リクエスト管理部１２は、データリクエストの送信元からチケットを受信すると、そのチケットが正規のチケットであるか否かを判定する。

【0067】

データリクエストの送信元から受信したチケットが正規のチケットであれば、トークン管理部１３は、そのデータリクエストに対してＱトークンおよびＡトークンを発行する。ＱトークンおよびＡトークンは、それぞれ、例えば、乱数発生器を用いて生成される乱数（または、擬似乱数）である。或いは、ＱトークンおよびＡトークンは、それぞれ、所定の計算式に基づいて生成してもよい。そして、発行したトークンは、データリクエストに関連づけてリクエスト管理テーブルに記録される。また、トークン管理部１３は、リソースサーバ１から受信するトークン（ＱトークンまたはＡトークン）が有効か否かを判定する。このとき、受信したトークンがリクエスト管理テーブルに記録されていれば、そのトークンが有効と判定される。

【0068】

リスト作成部１４は、データオーナーリストを作成する。リスト作成部１４は、たとえば、同意ポータルサーバ３がクライアント装置２からチケットを受信したときに、データオーナーリストを作成する。或いは、リスト作成部１４は、同意ポータルサーバ３がデータリクエストを受信したときにデータオーナーリストを作成してもよいし、同意ポータルサーバ３がＱトークンを受信したときにデータオーナーリストを作成してもよい。

【0069】

データオーナーリストは、データリクエストの内容に基づいて作成される。例えば、図７（ｃ）に示す例では、データリクエスト「RQ_001」の内容に基づいてデータオーナーリストが作成される。この場合、リスト作成部１４は、データリクエストにより指定されたデータ項目（ここでは、体重、血圧、歩数）に係わる個人データの提供に同意しており、且つ、データリクエストにより指定された属性（ここでは、年齢、性別）に対応するデータオーナーを、データオーナー管理テーブルにおいてサーチする。そして、リスト作成部１４は、上述の条件を満足するデータオーナーの識別情報（ここでは、仮名ＩＤ）をデータオーナー管理テーブルから抽出することによりデータオーナーリストを作成する。作成したデータオーナーリストは、リソースサーバ１に送信される。

【0070】

図８は、リソースサーバ１の構成の一例を示す。リソースサーバ１は、図８に示すように、プロセッサ４０、保存部５０、および通信部６０を備える。ただし、リソースサーバ１は、図８に示していない他の機能またはデバイスを備えてもよい。

【0071】

プロセッサ４０は、不図示の記憶装置に格納されている通信プログラムを実行することにより、リソースサーバ１の機能を提供する。即ち、プロセッサ４０は、不図示の記憶装置に格納されている通信プログラムを実行することにより、少なくとも、後述するリソース管理部４１、リクエスト処理部４２、および品質情報作成部４３の機能を提供する。

【0072】

保存部５０には、データオーナーから提供される個人データが保存される。図９に示す例では、「RM_001」で識別されるリソース（即ち、健康データ）がリソースサーバ１の保存部５０に保存されている。なお、保存部５０において、各データオーナーは、仮名ＩＤで識別される。この場合、仮名ＩＤは、リソースサーバ１および同意ポータルサーバ３において共有されることが好ましい。

【0073】

通信部６０は、送信部および受信部を含み、ネットワークに接続するためのインタフェースを提供する。

【0074】

リソース管理部４１は、データオーナーから提供される個人データを保存部５０に保存する。このとき、データオーナーの個人データは、ユーザ端末５ａから送信され、通信部６０により受信される。また、リソース管理部４１は、個人データを提供したデータオーナーに対して仮名ＩＤを割り当てる。また、データオーナーが仲介サービス会社と契約する際には、リソース管理部４１は、必要に応じて、又は、同意ポータルサーバ３からの要求に応じて、データオーナーに割り当てた仮名ＩＤを同意ポータルサーバ３に通知してもよい。

【0075】

リクエスト処理部４２は、クライアント装置２から送信されるデータリクエストを処理する。具体的には、リクエスト処理部４２は、受信したデータリクエストを同意ポータルに転送する。リクエスト処理部４２は、同意ポータルサーバ３から受信するチケットをクライアント装置２に転送する。リクエスト処理部４２は、クライアント装置２から受信するトークンを処理する。なお、リクエスト処理部４２は、クライアント装置２から受信するＡトークンが有効であるときは、同意ポータルサーバ３から受信するデータオーナーリストに載っているデータオーナーの健康データをクライアント装置２に送信する。

【0076】

品質情報作成部４３は、クライアント装置２から受信するＱトークンが有効であるときは、データオーナーリストに載っているデータオーナーの個人データの品質情報を作成する。個人データの品質情報は、この例では、最新性、完全性、正確性、一貫性、信憑性、データ量、および分散性を表す。

【0077】

次に、図１０～図１２に示すフローチャートを参照して同意ポータルサーバ３の処理を説明する。なお、同意ポータルサーバ３は、ユーザ端末５、リソースサーバ１、またはクライアント装置２からメッセージを受信したときに、そのメッセージに応じた処理を実行する。

【0078】

図１０（ａ）に示すフローチャートの処理は、同意ポータルサーバ３がユーザ端末５ａから契約に係わるメッセージを受信したときに実行される。なお、この処理は、主に、同意管理部１１により実行される。

【0079】

Ｓ２１において、同意ポータルサーバ３は、契約情報を入力するための入力フォームをユーザ端末５ａに送信する。そして、同意ポータルサーバ３は、その入力フォームを利用して入力される情報を保存部２０に保存する。なお、データオーナーの属性情報は、データオーナー管理テーブルに記録される。

【0080】

Ｓ２２において、同意ポータルサーバ３は、同意処理を実行する。例えば、個人データを第３者の提供することについて同意するか否かをデータオーナーに問い合わせる。この問合せに対する応答がユーザ端末５ａから送信されると、同意ポータルサーバ３は、その応答内容をデータオーナー管理テーブルに記録する。

【0081】

Ｓ２３において、同意ポータルサーバ３は、データオーナーのポリシをデータオーナー管理テーブルに記録する。なお、データオーナーは、必要に応じて、ユーザ端末５ａを利用して、個人データの提供に係わるポリシを同意ポータルサーバ３に送信する。

【0082】

図１０（ｂ）に示すフローチャートの処理は、同意ポータルサーバ３がクライアント装置２から送信されるデータリクエストを、リソースサーバ１を介して受信したときに実行される。データリクエストは、図５に示す例では、Ｓ１においてクライアント装置２から送信され、Ｓ２においてリソースサーバ１により同意ポータルサーバ３に転送される。また、この処理は、主に、リクエスト管理部１２により実行される。

【0083】

Ｓ３１において、同意ポータルサーバ３は、受信したデータリクエストが品質要求を含むか否かを判定する。そして、データリクエストが品質要求を含むときは、Ｓ３２において、同意ポータルサーバ３は、リクエストの内容および品質要求を保持する。一方、データリクエストが品質要求を含まないときは、Ｓ３３において、同意ポータルサーバ３は、リクエストの内容を保持する。Ｓ３４において、同意ポータルサーバ３は、同意ポータルサーバ３にアクセスするためのチケットを発行する。Ｓ３５において、同意ポータルサーバ３は、発行したチケットをリソースサーバ１に送信する。

【0084】

図１１に示すフローチャートの処理は、同意ポータルサーバ３がクライアント装置２から送信されるチケットを受信したときに実行される。チケットは、図５に示す例では、Ｓ５においてクライアント装置２から送信される。また、この処理は、主に、リクエスト管理部１２、トークン管理部１３、およびリスト作成部１４により実行される。

【0085】

Ｓ４１～Ｓ４２において、同意ポータルサーバ３は、クライアント装置２から受信したチケットを検証する。例えば、クライアント装置２から受信したチケットが、Ｓ３４において発行したチケットと一致すれば、受信したチケットが正規のチケットであると判定される。そして、受信したチケットが正規のチケットであるときは、同意ポータルサーバ３の処理はＳ４３に進む。

【0086】

Ｓ４３において、同意ポータルサーバ３は、データオーナーリストを作成する。具体的には、同意ポータルサーバ３は、リクエスト管理テーブルに登録されているデータリクエストが指定する属性に対応し、且つ、そのデータリクエストが指定する個人データを提供し、且つ、その個人データを第３者に提供することに同意しているデータオーナーの仮名ＩＤを、データオーナー管理テーブルから抽出する。図７（ｂ）に示す例では、データオーナー管理テーブルから「２１３４」「２１３５」．．．が抽出される。これにより、データオーナーリストが作成される。

【0087】

Ｓ４４において、同意ポータルサーバ３は、受信したデータリクエストが品質要求を含むか否かを判定する。そして、データリクエストが品質要求を含むときは、Ｓ４５において、同意ポータルサーバ３は、ＱトークンおよびＡトークンを発行する。ＱトークンおよびＡトークンは、それぞれ、例えば、乱数発生器を用いて生成される乱数（または、擬似乱数）である。或いは、ＱトークンおよびＡトークンは、それぞれ、所定の計算式に基づいて生成してもよい。そして、同意ポータルサーバ３は、生成したＱトークンおよびＡトークンを、クライアント装置２から送信されたデータリクエストに関連付けてリクエスト管理テーブルに記録する。

【0088】

データリクエストが品質要求を含まないときは、Ｓ４６において、同意ポータルサーバ３は、１個のトークンを発行する。Ｓ４６において発行されるトークンは、図４に示すシーケンスで使用されるトークンに相当する。

【0089】

Ｓ４７において、同意ポータルサーバ３は、Ｓ４５またはＳ４６で発行したトークンをクライアント装置２に送信する。

【0090】

図１２（ａ）に示すフローチャートの処理は、同意ポータルサーバ３がリソースサーバ１から送信されるＱトークンを受信したときに実行される。Ｑトークンは、図５に示す例では、Ｓ７においてクライアント装置２から送信され、Ｓ８においてリソースサーバ１により同意ポータルサーバ３に転送される。また、この処理は、主に、トークン管理部１３により実行される。

【0091】

Ｓ５１～Ｓ５２において、同意ポータルサーバ３は、リソースサーバ１から受信したＱトークンを検証する。たとえば、リソースサーバ１から受信したＱトークンがリクエスト管理テーブルに登録されていれば、受信したＱトークンが有効であると判定される。そして、Ｑトークンが有効であるときは、同意ポータルサーバ３は、Ｓ５３において、検証ＯＫメッセージおよびデータオーナーリストをリソースサーバ１に送信する。一方、Ｑトークンが有効でないときは、同意ポータルサーバ３は、Ｓ５４において、エラーメッセージをリソースサーバ１に送信する。

【0092】

図１２（ｂ）に示すフローチャートの処理は、同意ポータルサーバ３がリソースサーバ１から送信されるＡトークンを受信したときに実行される。Ａトークンは、図５に示す例では、Ｓ１１においてクライアント装置２から送信され、Ｓ１２においてリソースサーバ１により同意ポータルサーバ３に転送される。また、この処理は、主に、トークン管理部１３により実行される。

【0093】

Ｓ６１～Ｓ６２において、同意ポータルサーバ３は、リソースサーバ１から受信したＡトークンを検証する。たとえば、リソースサーバ１から受信したＡトークンがリクエスト管理テーブルに登録されていれば、受信したＡトークンが有効であると判定される。そして、Ａトークンが有効であるときは、同意ポータルサーバ３は、Ｓ６３において、検証ＯＫメッセージをリソースサーバ１に送信する。一方、Ａトークンが有効でないときは、同意ポータルサーバ３は、Ｓ６４において、エラーメッセージをリソースサーバ１に送信する。

【0094】

次に、図１３～図１４に示すフローチャートを参照してリソースサーバ１の処理を説明する。なお、リソースサーバ１は、クライアント装置２または同意ポータルサーバ３からメッセージを受信したときに、そのメッセージに応じた処理を実行する。

【0095】

図１３（ａ）に示すフローチャートの処理は、リソースサーバ１がクライアント装置２からデータリクエストを受信したときに実行される。データリクエストは、図５に示す例では、Ｓ１においてクライアント装置２から送信される。また、この処理は、主に、リクエスト処理部４２により実行される。

【0096】

Ｓ７１において、リソースサーバ１は、受信したデータリクエストが品質要求を含むか否かを判定する。そして、データリクエストが品質要求を含むときは、Ｓ７２において、リソースサーバ１３は、リクエストの内容および品質要求を保持する。一方、データリクエストが品質要求を含まないときは、Ｓ７３において、リソースサーバ１は、リクエストの内容を保持する。Ｓ７４において、リソースサーバ１は、クライアント装置２から受信したデータリクエストを同意ポータルサーバ３に転送する。

【0097】

図１３（ｂ）に示すフローチャートの処理は、リソースサーバ１が同意ポータルサーバ３からチケットを受信したときに実行される。チケットは、図１０（ｂ）に示す処理において、データリクエストに対して同意ポータルサーバ３により発行される。図５に示す例では、Ｓ３において同意ポータルサーバ３から送信される。また、この処理は、主に、リクエスト処理部４２により実行される。

【0098】

Ｓ８１において、リソースサーバ１は、受信したチケットを、データリクエストの送信元に転送する。すなわち、リソースサーバ１は、受信したチケットをクライアント装置２に転送する。このとき、リソースサーバ１は、同意ポータルサーバ３にアクセスするためのＵＲＩをクライアント装置２に通知する。

【0099】

図１３（ｃ）に示すフローチャートの処理は、リソースサーバ１がクライアント装置２からＱトークンを受信したときに実行される。Ｑトークンは、図１１に示す処理において、データリクエストに対して同意ポータルサーバ３により発行される。図５に示す例では、Ｓ６において同意ポータルサーバ３から送信され、Ｓ７においてクライアント装置２によりリソースサーバ１に転送される。また、この処理は、主に、リクエスト処理部４２により実行される。

【0100】

Ｓ９１において、リソースサーバ１は、受信したＱトークンを同意ポータルサーバ３に転送する。このとき、リソースサーバ１は、Ｑトークンが有効であるか否かの検証を同意ポータルサーバ３に依頼してもよい。

【0101】

図１４（ａ）に示すフローチャートの処理は、リソースサーバ１が同意ポータルサーバ３からＱトークンの検証結果を受信したときに実行される。Ｑトークンは、図１２（ａ）に示す処理において、同意ポータルサーバ３により検証される。図５に示す例では、検証結果は、Ｓ９において同意ポータルサーバ３からリソースサーバ１に送信される。また、この処理は、主に、品質情報作成部４３により実行される。

【0102】

Ｓ１０１において、リソースサーバ１は、Ｑトークンの検証結果を確認する。また、Ｓ１０２において、リソースサーバ１は、Ｑトークンの検証結果にデータオーナーリストが添付されているか否かを判定する。そして、Ｑトークンが有効であり、且つ、データオーナーリストが添付されているときは、リソースサーバ１の処理はＳ１０３に進む。

【0103】

Ｓ１０３において、リソースサーバ１は、データオーナーリストに載っているデータオーナーの個人データを保存部５０から抽出する。Ｓ１０４において、リソースサーバ１は、Ｓ１０３で抽出した個人データの品質情報を作成する。品質情報は、例えば、ＩＳＯ２５０１２に従って作成される。ただし、この実施例では、ＩＳＯ２５０１２をベースとして評価項目が追加されている。なお、個人データの品質情報を作成する方法については、後で実施例を記載する。

【0104】

Ｓ１０５において、リソースサーバ１は、品質情報をクライアント装置２に送信する。なお、Ｑトークンが有効でない場合、或いは、データオーナーリストが添付されていない場合は、Ｓ１０６において、エラーメッセージが出力される。

【0105】

図１４（ｂ）に示すフローチャートの処理は、リソースサーバ１がクライアント装置２からＡトークンを受信したときに実行される。Ａトークンは、図１１に示す処理において、データリクエストに対して同意ポータルサーバ３により発行される。図５に示す例では、Ｓ６において同意ポータルサーバ３から送信され、Ｓ１１においてクライアント装置２によりリソースサーバ１に転送される。また、この処理は、主に、リクエスト処理部４２により実行される。

【0106】

Ｓ１１１において、リソースサーバ１は、受信したＡトークンを同意ポータルサーバ３に転送する。このとき、リソースサーバ１は、Ａトークンが有効であるか否かの検証を同意ポータルサーバ３に依頼する。

【0107】

図１４（ｃ）に示すフローチャートの処理は、リソースサーバ１が同意ポータルサーバ３からＡトークンの検証結果を受信したときに実行される。Ａトークンは、図１２（ｂ）に示す処理において、同意ポータルサーバ３により検証される。図５に示す例では、検証結果は、Ｓ１３において同意ポータルサーバ３からリソースサーバ１に送信される。また、この処理は、主に、リクエスト処理部４２により実行される。

【0108】

Ｓ１２１において、リソースサーバ１は、Ａトークンの検証結果を確認する。Ａトークンが有効であるときは、Ｓ１２２において、リソースサーバ１は、Ｓ１０３で抽出した個人データをクライアント装置２に送信する。一方、Ａトークンが有効でない場合は、Ｓ１２３において、エラーメッセージが出力される。

【0109】

＜第１の実施例＞
第１の実施例では、サンプル数（健康データの提供に同意し、且つ、データリクエストが指定する属性に対応するデータオーナーの数）は、４５３である。抽出されたデータオーナーの年代ごとの分布は、１０代のデータオーナーが３２人、２０代のデータオーナーが２０人．．．である、その標準偏差は９．８である。健康データの測定期間は、２０１９年１月１６日から２０２０年１月１５日である。データのロス率は０．９パーセントである。各データオーナーの健康データのうち、最小サンプル数は２９０日であり、最大サンプル数は３６５日であり、連続欠損期間は５日である。

【0110】

「データ量」は、サンプル数により表される。「分散性」は、抽出されたデータオーナーの年代ごとの分布（ここでは、偏差値）により表される。「最新性」は、健康データの測定期間により表される。「完全性」は、データのロス率、最小／最大サンプル数、連続欠損期間により表される。なお、第１の実施例では、正確性、一貫性、信憑性に係わる品質情報は、作成されてない。

【0111】

図１５は、第１の実施例におけるデータ処理のシーケンスを示す。このシーケンスは、クライアント装置２からデータリクエストが送信され、そのデータリクエストに対応するＱトークンおよびＡトークンが同意ポータルサーバ３からクライアント装置２に与えられえた後の手順を示している。

【0112】

同意ポータルサーバ３は、クライアント装置２から送信されるＱトークンを、リソースサーバ１を介して受信すると、データオーナーリストをリソースサーバ１に送信する。そうすると、リソースサーバ１は、品質情報を作成してクライアント装置２に送信する。したがって、ヘルスケアサービス会社は、実際の健康データを取得する前に、その健康データの品質を知ることができる。そして、ヘルスケアサービス会社は、その健康データの品質に満足したときには、リソースサーバ１にＡトークンを送信することにより、リソースサーバ１に対して健康データの送信を依頼する。そして、リソースサーバ１は、この依頼に応じて健康データをクライアント装置２に送信する。

【0113】

＜第２の実施例＞
第２の実施例では、第１の実施例に加えて「正確性」に係わる品質情報が作成される。正確性については、この実施例では、データ値の正しさ、及び、データフォーマットの正しさを表す。

【0114】

例えば、体重データ、血圧データ、歩数データについて、それぞれ取り得るデータ範囲として「５～１８０ｇｋ」「４０～１８０ｍＨｇ」「１～９９９９９歩」が設定される。この場合、体重データ、血圧データ、歩数データそれぞれについて、測定値が設定されたデータ範囲内に入っている否かが判定される。そして、設定されたデータ範囲から外れている測定値の個数がカウントされる。すなわち、「正確性（データ値の正しさ）」は、外れ値の個数で表される。

【0115】

また、最低血圧および最高血圧を表記するフォーマットとして、２つの値の間を「／（スラッシュ）」で区切ることが決まっているものとする。この場合、例えば「80,120」のように、最低血圧および最高血圧が他の形式で表記されているときは、フォーマットエラーと判定される。あるいは、最低血圧および最高血圧を表記するフォーマットとして、最低血圧をスラッシュの左側に記載し、最高血圧をスラッシュの右側に記載することが決まっているものとする。この場合、例えば「120/80」のように、スラッシュの左側に記載されている値が、スラッシュの左側に記載されている値がより大きいときは、フォーマットエラーと判定される。すなわち、「正確性（データフォーマットの正しさ）」は、フォーマットエラーの個数で表される。

【0116】

＜バリエーション＞
図５～図１４に示す実施形態では、２つのトークン（即ち、ＱトークンおよびＡトークン）を使用することにより、データ利用者は、データを取得する前にそのデータの品質を知ることができるが、本発明はこの方法に限定されるものではない。例えば、同意ポータルサーバ３は、１つのデータリクエストに対して１つのトークンを発行する。また、リソースサーバ１は、データを提供するためのエンドポイント（例えば、/token/data）とは別に、品質情報を提供するためのエンドポイント（例えば、/token/quality_info）を用意する。この場合、例えば、上記２つのエンドポイントは、リソースサーバ１から同意ポータルサーバ３に通知され、その後、図５に示すＳ６の代わりに、同意ポータルサーバ３からクライアント装置２に上記２つのエンドポイントが通知される。そして、クライアント装置２は、図５に示すＳ７の代わりに、トークンを用いて品質情報を提供するためのエンドポイントにアクセスすることで品質情報を取得する。また、クライアント装置２は、図５に示すＳ１１の代わりに、同じトークンを用いてデータを提供するためのエンドポイントにアクセスすることでデータを取得する。

【0117】

クライアント装置２は、データリクエストを送信する際に、上述した７つの項目（データ量、分散性、最新性、正確性、完全性、一貫性、信憑性）のうちの所望の１以上の項目を指定してもよい。この場合、リソースサーバ１は、指定された項目のみに係わる品質情報をクライアント装置２に送信する。

【0118】

上述の実施例を含む実施形態に関し、さらに下記の付記を開示する。
（付記１）
クライアント装置から送信される、属性情報、データ項目、および品質要求を含むデータリクエストを、リソースサーバを介して受信し、
前記属性情報および前記データ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信し、
前記リソースサーバから前記第１のトークンを受信したときに、前記第１のトークンの検証結果、及び、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信し、
前記リソースサーバから前記第２のトークンを受信したときに、前記第２のトークンの検証結果を前記リソースサーバに送信する
処理をコンピュータに実行させる通信プログラム。
（付記２）
前記データリクエストを受信したときに、チケットを発行して前記リソースサーバに送信し、
前記クライアントサーバから前記チケットを受信したときに、前記第１のトークンおよび前記第２のトークンを前記クライアント装置に送信する
ことを特徴とする付記１に記載の通信プログラム。
（付記３）
クライアント装置から送信される、属性情報、データ項目、および品質要求を含むデータリクエストを、リソースサーバを介して受信する受信部と、
前記属性情報および前記データ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信する第１の処理部と、
前記リソースサーバから前記第１のトークンを受信したときに、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信する第２の処理部と、
前記リソースサーバから前記第２のトークンを受信したときに、前記第２のトークンの検証結果を前記リソースサーバに送信する第３の処理部と、
を備えるサーバ装置。
（付記４）
前記データリクエストを受信したときに、チケットを発行して前記リソースサーバに送信する第４の処理部をさらに備え、
前記第１の処理部は、前記クライアントサーバから前記チケットを受信したときに、前記第１のトークンおよび前記第２のトークンを前記クライアント装置に送信する
ことを特徴とする付記３に記載のサーバ装置。
（付記５）
リソースサーバに保存されている個人データをクライアント装置に提供するデータ処理方法であって、
前記クライアント装置は、属性情報、データ項目、および品質要求を含むデータリクエストを前記リソースサーバに送信し、
前記リソースサーバは、前記データリクエストを認可サーバに転送し、
前記認可サーバは、前記データリクエストに含まれる属性情報およびデータ項目に対応する個人データの品質を表す品質情報を要求する第１のトークンおよび前記個人データを要求する第２のトークンを前記クライアント装置に送信し、
前記クライアント装置は、前記第１のトークンを前記リソースサーバに送信し、
前記リソースサーバは、前記第１のトークンを前記認可サーバに転送し、
前記認可サーバは、前記リソースサーバから受信する第１のトークンが前記クライアント装置に送信した第１のトークンと一致するときは、前記データ項目に係わる個人データの提供に同意しており、且つ、前記属性情報に対応するデータオーナーの識別情報を前記リソースサーバに送信し、
前記リソースサーバは、前記識別情報により識別されるデータオーナーの個人データの品質を表す品質情報を前記クライアント装置に送信し、
前記クライアント装置は、前記品質情報を受信した後に、前記第２のトークンを前記リソースサーバに送信し、
前記リソースサーバは、前記識別情報により識別されるデータオーナーの個人データを前記クライアント装置に送信する
ことを特徴とするデータ処理方法。
（付記６）
前記リソースサーバは、前記識別情報により識別されるデータオーナーの個人データについて、データ量、分散性、最新性、正確性、完全性、一貫性、および信憑性のうちの少なくとも１つを表す品質情報を作成して前記クライアント装置に送信する
ことを特徴とする付記５に記載のデータ処理方法。
(付記７)
前記品質情報は、前記識別情報により識別されるデータオーナーの個人データのロス率を表す
ことを特徴とする付記５に記載のデータ処理方法。
(付記８)
前記品質情報は、前記識別情報により識別されるデータオーナーの個人データ内の外れ値の個数を表す
ことを特徴とする付記５に記載のデータ処理方法。
(付記９)
前記品質情報は、前記識別情報により識別されるデータオーナーの個人データ内のフォーマットエラーの個数を表す
ことを特徴とする付記５に記載のデータ処理方法。

【符号の説明】

【0119】

１ リソースサーバ
２ クライアント装置
３ 同意ポータルサーバ（認可サーバ）
１０ プロセッサ
１１ 同意管理部
１２ リクエスト管理部
１３ トークン管理部
１４ リスト作成部
２０ 保存部
３０ 通信部
４０ プロセッサ
４１ リソース管理部
４２ リクエスト処理部
４３ 品質情報作成部
５０ 保存部
６０ 通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】