JP2016152024A - 情報収集装置、情報収集プログラムおよび情報収集方法 - Google Patents

Abstract

【課題】プライバシを考慮した情報収集の仕組を実現する。【解決手段】ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置であって、前記データベースに格納された情報の利用要求を端末装置から受け付ける受付部と、前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答する応答部と、前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する格納部と、を備える。【選択図】図６

Description

本発明は、情報収集装置、情報収集プログラムおよび情報収集方法に関する。

ネットワーク上に分散して存在するパーソナルデータ（個人情報）を本人のコントロールのもとに収集して様々なサービス間を流通させ利活用（利用・活用）を図る形態として、パーソナルデータストア（ＰＤＳ：Personal Data Store）と呼ばれるものが知られるようになってきている。個人本人がパーソナルデータを管理するための仕組および個人が自分のパーソナルデータの流通をコントロールする仕組を含めた全体がパーソナルデータストアと呼ばれることもある。また、そのような機能を提供するクラウド上のサービスや、サービスを提供する装置（サーバ群により構成される場合を含む）がパーソナルデータストアと呼ばれることもある。

パーソナルデータには、本人の基本的な属性情報のみならず、興味、所属、友人関係、行動履歴等の様々なものが含まれる。具体的には、ソーシャルサイトの情報、インターネット販売の購買履歴、嗜好情報（ランニングの記録、ハイキングの記録等）、医療の履歴、ネットバンキングの履歴等が含まれる。

図１はパーソナルデータストアの例を示しており、クラウド上のパーソナルデータストア３０は、ユーザから端末装置１を介したコントロールのもと、病院情報を保持するサービスプロバイダ４Ｐ、嗜好情報を保持するサービスプロバイダ４Ｑ、ソーシャル情報を保持するサービスプロバイダ４Ｒから該当するユーザのパーソナルデータを収集する。パーソナルデータストア３０は、端末装置１のユーザによって予め設定されたＩＤやパスワードに基づき、サービスプロバイダ４Ｐ、４Ｑ、４Ｒにユーザに代理してアクセスする。そして、パーソナルデータストア３０は、ユーザから端末装置１を介したコントロールのもと、収集したパーソナルデータを、パーソナルデータストア３０の内部または他のサービス上で利活用する。

図２はパーソナルデータストアの型の例を示す図である。図２（ａ）は集中型の例であり、図１に示したものに対応する。この集中型は、様々なユーザＡ、Ｂ、Ｃ、・・・のパーソナルデータをクラウド上のパーソナルデータストア３０に収集して一元管理を行うものであり、複数（多数）のユーザのデータが集まるため、様々な分析等が容易に行えるという利点がある。図２（ｂ）は分散型の例であり、一人のユーザＡがパーソナルデータの種別等に応じて別々のパーソナルデータストア３０Ｘ、３０Ｙ、３０Ｚにパーソナルデータを暗号化して預けている。他のユーザも異なる任意のパーソナルデータストアに同様にパーソナルデータを暗号化して預ける。この分散型は、他のユーザのデータが一元的に収集されないため、名寄せ等も困難であり、様々な分析等を行うことは難しい。

そこで、以下では集中型を想定して説明を行う。ただし、ユーザのパーソナルデータを収集するという部分については、分散型を除外するものではない。

特開２００８−１１７３６５号公報

上述したパーソナルデータストアの利用に際し、ユーザは、医療や宗教等の機微情報／秘密情報を含むサービスプロバイダの情報をパーソナルデータストアへ提供したくない場合がある。図３はパーソナルデータストアに明かしたくない情報の例を示している。端末装置１のユーザは、サービスプロバイダ４Ｑの嗜好情報やサービスプロバイダ４Ｒのソーシャル情報をパーソナルデータストア３０が収集することについては問題ないと考えるが、サービスプロバイダ４Ｐの病院情報については、プライバシの観点からパーソナルデータストア３０に収集されたくない（明かしたくない）と考える場合が多い。病院情報には、病院名、処方箋、カルテ情報（病名、検査結果等）等が含まれており、例えば、メンタル的な病で通っている病院名、病名（適応障害等）等を他人に知られるのは絶対に避けたいからである。同様に、銀行の預金番号や預金額等についてもパーソナルデータストア３０に明かしたくない場合がある。

本来、パーソナルデータストアは、ユーザ側の視点に立ったサービスであり、パーソナルデータを躊躇なく預けることができるような十分なセキュリティ対策が施されているものである。しかし、ユーザは上述した機微情報／秘密情報について、万が一の情報流出も避けたいと考えるとともに、パーソナルデータストアの運用管理者にさえも知られたくないと考えることが多い。なお、機微情報／秘密情報を含むサービスプロバイダの情報であっても、全てが機微情報／秘密情報というわけではなく、機微情報／秘密情報でない部分についてはパーソナルデータストアを通じた利活用が望まれる。そのため、機微情報／秘密情報を含むサービスプロバイダからの情報収集をパーソナルデータストアに許可しないという単純な対策では、パーソナルデータの十分な利活用が図れなくなる。

かかる要望に応えるため、機微情報／秘密情報を含むサービスプロバイダからの情報収集については、パーソナルデータストアがサービスプロバイダから直接にデータを収集するのではなく、ユーザの端末装置を経由して収集することが考えられる。図４は、サービスプロバイダから端末装置を経由してパーソナルデータストアがパーソナルデータを収集する例を示している。図４において、パーソナルデータストア３０は、サービスプロバイダ４Ｑの嗜好情報やサービスプロバイダ４Ｒのソーシャル情報については直接に収集するが、サービスプロバイダ４Ｐの病院情報については、端末装置１のプロキシを経由して収集している。ユーザは端末装置１のプロキシにより収集されるパーソナルデータをコントロール（機微情報／秘密情報の通過を阻止等）することで、機微情報／秘密情報が意に反してパーソナルデータストア３０に収集されることを防止することができる。

しかしながら、上述した端末装置を経由したデータ収集の仕組を構築するのは、次のような理由から現実的には困難である。

第１に、通常の端末装置ではＷｅｂサーバのような受け口を用意するのが難しく（通常、端末装置ではＷｅｂサーバを立てないため）、パーソナルデータストアが主体となって端末装置に対して情報収集の要求を発し、その要求をトリガとして端末装置がパーソナルデータを収集することはできない。

第２に、多くの端末装置はファイアウォールの背後にいるため、所定のポートを予め開けておく等の対策なしには、パーソナルデータストア側からは端末装置にアクセスすることができない。

第３に、モバイル環境等により端末装置のＩＰアドレス等は変わるため、パーソナルデータストア側から端末装置のアクセス先が特定できず、端末装置にアクセスすることができない。

このように、情報収集の効率性の観点からは、パーソナルデータストアが主体となって情報収集を行うことが望まれるが、実際の端末装置の構成および配置される環境を考慮すると、実現が困難である。

一方、端末装置が主体となって情報収集を行い、収集した情報をパーソナルデータストアに引き渡すことも考えられるが、その場合、端末装置における情報収集を行うタイミングをどのように行うのかという問題が発生し、端末装置のユーザに追加の操作等が発生するおそれがある。また、端末装置における情報収集が遅れればパーソナルデータの鮮度が落ち、利活用に悪影響を及ぼすことも考えられる。

そこで、一側面では、パーソナルデータストア等の情報収集装置が主体となり、端末装置を経由して情報を収集する仕組を基本としつつ、実際の端末装置の構成および配置される環境に適用可能で、端末装置において情報の利用が行われる際に遅滞なく情報収集が行える、プライバシを考慮した情報収集の仕組を実現することを目的とする。

一つの案では、ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置であって、前記データベースに格納された情報の利用要求を端末装置から受け付ける受付部と、前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答する応答部と、前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する格納部と、を備える。

一態様によれば、情報収集装置が主体となり、端末装置を経由して情報を収集する仕組を基本としつつ、実際の端末装置の構成および配置される環境に適用可能で、端末装置において情報の利用が行われる際に遅滞なく情報収集が行える、プライバシを考慮した情報収集の仕組を実現することができる。

パーソナルデータストアの例を示す図である。 パーソナルデータストアの型の例を示す図である。 パーソナルデータストアに明かしたくない情報の例を示す図である。 端末装置を経由してパーソナルデータストアがデータを収集する例を示す図である。 一実施形態にかかるシステムの構成例を示す図である。 端末装置等のソフトウェア構成例を示す図である。 端末装置側に保持される情報の例を示す図である。 パーソナルデータストア側に保持される情報の例を示す図である。 端末装置等のハードウェア構成例を示す図である。 実施形態の処理例を示すシーケンス図である。 端末装置における処理例を示すフローチャート（その１）である。 端末装置における処理例を示すフローチャート（その２）である。 パーソナルデータストアにおける処理例を示すフローチャートである。 機微／秘密情報の設定の例を示す図である。 パーソナルデータストアにおけるサービス登録の例を示す図である。 収集ＩＤの応答の例を示す図である。 端末装置における収集ＩＤ等の登録の例を示す図である。 パーソナルデータストアにおける収集依頼要否判断の例を示す図である。 収集ＩＤおよびプッシュＵＲＩの応答の例を示す図である。 パーソナルデータストアから端末装置への収集依頼の例を示す図である。 パーソナルデータストアにおけるパーソナルデータの登録の例を示す図である。 端末装置における収集要否判断の例を示す図である。 病院情報の利活用の例を示す図である。 銀行情報の利活用の例を示す図である。

以下、本発明の好適な実施形態につき説明する。なお、病院情報（医療情報）を扱う場合を例として説明するが、その他の情報（例えば、預金情報等）を扱う場合にも適用できることは言うまでもない。

＜構成＞
図５は一実施形態にかかるシステムの構成例を示す図である。図５において、パーソナルコンピュータ、スマートフォン、携帯電話等の端末装置１（１Ａ、１Ｂ、１Ｃ、・・・）は、インターネット等のネットワーク２に接続可能になっている。また、ネットワーク２には、パーソナルデータストア（ＰＤＳ）３と複数のサービスプロバイダ４（４Ｐ、４Ｑ、・・・）が接続されている。

図６は端末装置１等（端末装置１、パーソナルデータストア３、サービスプロバイダ４）のソフトウェア構成例を示す図である。図６において、端末装置１は、メッセージ送受信部１１とアプリ（アプリケーションプログラム）１２とプロキシ部１３とを備えている。プロキシ部１３は、データ制御部１４と収集／加工部１５とＰＤＳ（パーソナルデータストア）側管理部１６とＳＰ（サービスプロバイダ）側管理部１７とを備えている。

メッセージ送受信部１１は、パーソナルデータストア３またはサービスプロバイダ４との間でＨＴＴＰプロトコル等によりメッセージの送受信を行う機能を有している。アプリ１２は、パーソナルデータを扱うアプリケーションプログラムである。プロキシ部１３は、パーソナルデータストア３に代わって端末装置１側で所定のサービスプロバイダ４からパーソナルデータを収集し、収集したパーソナルデータのうちユーザに許可されたパーソナルデータ（ユーザにより事前に設定された不許可情報の除去等を行った後のパーソナルデータ）をパーソナルデータストア３に提供する機能を有している。データ制御部１４は、収集／加工部１５、ＰＤＳ側管理部１６およびＳＰ側管理部１７の間またはメッセージ送受信部１１との間で入出力するデータの制御を行う機能を有している。収集／加工部１５は、パーソナルデータの収集および加工（ユーザにより事前に設定された不許可情報の除去等）を行う機能を有している。ＰＤＳ側管理部１６は、ネットワーク２を介して接続されたパーソナルデータストア３との通信を管理し、サービスプロバイダ４から収集したパーソナルデータをパーソナルデータストア３側の所定の宛先にプッシュ送信する等の機能を有している。ＳＰ側管理部１７は、ネットワーク２を介して接続されたサービスプロバイダ４との通信を管理し、サービスプロバイダ４からパーソナルデータを収集する等の機能を有している。

パーソナルデータストア３は、メッセージ送受信部３１と認証部３２とＰＤＳ（パーソナルデータストア）マネージャ３３と端末側データ収集部３４とＳＰ（サービスプロバイダ）側データ収集部３５とデータベース３６とＰＤＳ（パーソナルデータストア）サービスアプリ３７とを備えている。

メッセージ送受信部３１は、端末装置１またはサービスプロバイダ４との間でＨＴＴＰプロトコル等によりメッセージの送受信を行う機能を有している。認証部３２は、端末装置１からパーソナルデータストア３へのアクセスに際し、ＩＤおよびパスワードまたは生体情報に基づく認証処理を行う機能を有している。ＰＤＳマネージャ３３は、パーソナルデータストア３の基本機能であるデータ収集とデータ提供とを行う機能を有し、端末側データ収集部３４とＳＰ側データ収集部３５を制御する機能を有している。端末側データ収集部３４は、端末装置１を経由してパーソナルデータを収集する機能を有している。ＳＰ側データ収集部３５は、サービスプロバイダ４から直接にパーソナルデータを収集する機能を有している。データベース３６は、収集したパーソナルデータを格納して管理する機能を有している。ＰＤＳサービスアプリ３７は、データベース３６に格納されたパーソナルデータに基づいて様々な解析等を行い、ユーザに対して情報を提供する機能を有している。

サービスプロバイダ４は、メッセージ送受信部４１と認証部４２とサービスアプリ４３とデータベース４４とを備えている。メッセージ送受信部４１は、端末装置１またはパーソナルデータストア３との間でＨＴＴＰプロトコル等によりメッセージの送受信を行う機能を有している。認証部４２は、端末装置１からサービスプロバイダ４へのアクセスに際し、ＩＤおよびパスワード等に基づく認証処理を行う機能を有している。サービスアプリ４３は、サービスプロバイダ４の目的に応じたサービスを提供する機能を有している。データベース４４は、サービスプロバイダ４におけるパーソナルデータ等を格納して管理する機能を有している。

図７は端末装置１側に保持される情報の例を示す図であり、サービス情報テーブルＴ１１とＰＤＳ情報テーブルＴ１２とサービス機微/秘密情報テーブルＴ１３とサービス機微/秘密情報定義テーブルＴ１４と端末収集判断テーブルＴ１５とを示している。

サービス情報テーブルＴ１１は、端末装置１側で利用するサービス（サービスプロバイダ）に関する情報を保持するテーブルであり、「収集ＩＤ」と「サービスＩＤ」と「サービスＵＲＩ」の項目を含んでいる。「収集ＩＤ」は、パーソナルデータストア３から通知されるデータ収集を識別する情報である。「サービスＩＤ」は、端末装置１側でサービスを識別するための情報である。「サービスＵＲＩ」は、サービスにアクセスするためのＵＲＩ（Uniform Resource Locator）である。

ＰＤＳ情報テーブルＴ１２は、パーソナルデータストア３に対するデータ送信（プッシュ送信）に関する情報を保持するテーブルであり、「収集ＩＤ」と「プッシュ先」の項目を含んでいる。「収集ＩＤ」は、パーソナルデータストア３から通知されるデータ収集を識別する情報である。「プッシュ先」は、パーソナルデータストア３から通知されるデータ送信の宛先となるＵＲＩである。

サービス機微/秘密情報テーブルＴ１３は、パーソナルデータに含まれる機微情報または秘密情報について、パーソナルデータストア３に対して送信する際の扱いに関する情報を保持するテーブルであり、「サービスＩＤ」と「機微／秘密情報名」と「値」と「ＰＤＳ管理値」の項目を含んでいる。「サービスＩＤ」は、端末装置１側でサービスを識別するための情報である。「機微／秘密情報名」は、機微情報または秘密情報の名前である。「値」は、機微情報または秘密情報の値である。「ＰＤＳ管理値」は、機微情報または秘密情報がパーソナルデータストア３で管理される状態（「null」は管理させない。「hospA」は仮名（実際の名を隠すための仮の名）の例。）である。

サービス機微/秘密情報定義テーブルＴ１４は、パーソナルデータに含まれる機微情報または秘密情報について、どのような加工等を行うかの情報を保持するテーブルであり、「サービス種別」と「サービスＩＤ」と「機微／秘密情報名」と「ＰＤＳ提供フォーマット」の項目を含んでいる。「サービス種別」は、サービスの種別（「Medical」は医療・病院情報を示す）を示す情報である。「サービスＩＤ」は、端末装置１側でサービスを識別するための情報である。「機微／秘密情報名」は、機微情報または秘密情報の名前である。「ＰＤＳ提供フォーマット」は、機微情報または秘密情報に適用する加工等のフォーマットを示す情報である。「None」は加工しないことを示す（サービス機微/秘密情報テーブルＴ１３により提供しないため、加工は不要）。その他には、「Pseudonym ID」では仮名化したＩＤとすることを示し、「Partial Mask」はデータの一部をマスク（例えば、電話番号の場合、「044-xxx-xxxx」のように「x」でマスク。クレジットカードや住所等についても同様。）することを示す。

端末収集判断テーブルＴ１５は、端末装置１において自主的にパーソナルデータの収集を行うタイミングを判断するための情報を保持するテーブルであり、「収集ＩＤ」と「データ最新記録／処方日数」と「収集日」の項目を含んでいる。「収集ＩＤ」は、パーソナルデータストア３から通知されるデータ収集を識別する情報である。「データ最新記録／処方日数」は、最新の収集日および処方箋で示された投薬の日数である。処方日数は、収集間隔を判断するのに用いられる。「収集日」は、予定される次回の収集日であり、「データ最新記録／処方日数」の最新の収集日に処方日数より所定日数少なくした日数を加えた日付である。

図８はパーソナルデータストア３側に保持される情報の例を示す図であり、データ収集管理情報テーブルＴ３１とサービス管理テーブルＴ３２と収集判断テーブルＴ３３とパーソナルデータテーブルＴ３４とを示している。

データ収集管理情報テーブルＴ３１は、パーソナルデータストア３においてパーソナルデータの収集を管理するテーブルであり、「ユーザＩＤ」と「端末ＩＤ」と「サービスＩＤ」と「収集ＩＤ」と「Ｐｒｏｘｙ利用」と「Ｐｕｓｈ ＵＲＩ」の項目を含んでいる。「ユーザＩＤ」は、サービスを利用するユーザを識別する情報である。「端末ＩＤ」は、ユーザが使用する端末装置１を識別する情報である。「サービスＩＤ」は、パーソナルデータストア３側でサービスを識別するための情報であり、ユーザにより登録された仮名が用いられる。「収集ＩＤ」は、ユーザによるサービスの登録時にパーソナルデータストア３側で発行したデータ収集を識別する情報である。「Ｐｒｏｘｙ利用」は、パーソナルデータの収集を端末装置１を経由して行うか否かを示す情報である（「on」は端末装置１を経由して収集。「off」はパーソナルデータストア３が直接に収集。）。「Ｐｕｓｈ ＵＲＩ」は、パーソナルデータの収集を端末装置１を経由して行う場合に、収集したパーソナルデータを端末装置１からプッシュ送信する宛先となるパーソナルデータストア３側のアドレスである。

サービス管理テーブルＴ３２は、ユーザが利用するサービスを管理するテーブルであり、「サービス種別」と「サービス名」と「サービスＩＤ」と「サービスＵＲＩ」の項目を含んでいる。「サービス種別」は、サービスの種別（「Medical」は医療・病院情報を示す）を示す情報である。「サービス名」は、パーソナルデータストア３側で管理するサービスの名前であり、仮名が用いられる。「サービスＩＤ」は、パーソナルデータストア３側でサービスを識別するための情報であり、ユーザにより登録された仮名が用いられる。「サービスＵＲＩ」は、サービスにアクセスするためのアドレスであり、端末装置１を経由してデータを収集する場合はブランクである。

収集判断テーブルＴ３３は、パーソナルデータストア３において、端末装置１からサービス利用要求を受け付けた場合に、収集依頼を応答するタイミングであるか否か、すなわち、パーソナルデータの収集を行うタイミングであるか否かを判断するための情報を保持するテーブルである。収集判断テーブルＴ３３は、「収集ＩＤ」と「利用頻度（１日）」と「データ最新記録／処方日数」の項目を含んでいる。「収集ＩＤ」は、データ収集を識別する情報である。「利用頻度（１日）」は、収集ＩＤに対応するサービスへのユーザの１日あたりの利用頻度を示す情報である。「データ最新記録／処方日数」は、最新の収集日および処方箋で示された投薬の日数である。処方日数は、収集間隔を判断するのに用いられる。

パーソナルデータテーブルＴ３４は、収集したパーソナルデータを保持するテーブルであり、「収集ＩＤ」と「パーソナルデータ」の項目を含んでいる。パーソナルデータテーブルＴ３４は、データベース３６（図６）の実体となる。「収集ＩＤ」は、データ収集を識別する情報である。「パーソナルデータ」は、パーソナルデータの本体データである。

図９は端末装置１等（端末装置１、パーソナルデータストア３、サービスプロバイダ４）のハードウェア構成例を示す図である。なお、パーソナルデータストア３やサービスプロバイダ４は、複数のコンピュータ装置により構成されるのが一般的であるが、便宜上、構成要素としてのコンピュータ装置のハードウェア構成を示している。

図９において、端末装置１等は、システムバス１００１に接続されたＣＰＵ（Central Processing Unit）１００２、ＲＯＭ（Read Only Memory）１００３、ＲＡＭ（Random Access Memory）１００４、ＮＶＲＡＭ（Non-Volatile Random Access Memory）１００５を備えている。また、端末装置１等は、Ｉ／Ｆ（Interface）１００６と、Ｉ／Ｆ１００６に接続された、Ｉ／Ｏ（Input/Output Device）１００７、ＨＤＤ（Hard Disk Drive）１００８、ＮＩＣ（Network Interface Card）１００９と、Ｉ／Ｏ１００７に接続されたモニタ１０１０、キーボード１０１１、マウス１０１２等を備えている。Ｉ／Ｏ１００７にはＣＤ／ＤＶＤ（Compact Disk/Digital Versatile Disk）ドライブ等を接続することもできる。図示のハードウェア上ではＯＳ（Operating System）が動作し、その上で図６に示した各部がコンピュータプログラムに基づいて動作する。

＜動作＞
図１０は上記の実施形態の処理例を示すシーケンス図である。また、図１１および図１２は端末装置１における処理例を示すフローチャートであり、図１３はパーソナルデータストア３における処理例を示すフローチャートである。

［機微／秘密情報の設定］
端末装置１のユーザは、図７に示したサービス機微/秘密情報テーブルＴ１３およびサービス機微/秘密情報定義テーブルＴ１４を作成することで、機微／秘密情報を定義し、サービスプロバイダ４から収集したパーソナルデータのうちどの情報をパーソナルデータストア３に送信することを許可するかを定める。なお、これらのテーブルの作成は後述するサービス登録と並行して行ってもよいし、サービス登録後に内容を変更（再作成）してもよい。ユーザにより機微／秘密情報とその取り扱いを細かく定められることにより、柔軟にパーソナルデータのコントロールを行うことができる。

図１４は機微／秘密情報の設定の例を示す図であり、予めサービス種別毎に用意されたテンプレートから該当する機微／秘密情報名を選択し、ＰＤＳ提供フォーマットに選択肢が設けられている場合にはそれを選択することで、サービス機微/秘密情報定義テーブルＴ１４が作成される。サービスＩＤは対象とするサービスの端末装置１側での識別子が入る。図示の例では、テンプレートからサービス種別「Medical」について機微／秘密情報名「病院名」「病名」についてＰＤＳ提供フォーマット「None」が選択され、サービス機微/秘密情報定義テーブルＴ１４が作成されている。ＰＤＳ提供フォーマット「None」は加工が行われないことを示す。その他のＰＤＳ提供フォーマットとして、仮名化したＩＤとする「Pseudonym ID」、データの一部をマスクする「Partial Mask」等がある。

そして、サービス機微/秘密情報定義テーブルＴ１４の各機微／秘密情報名と、必要に応じて追加された機微／秘密情報名について、サービス機微/秘密情報テーブルＴ１３が作成される。値には該当するサービスにおいて実際に用いられている値が入り、ＰＤＳ管理値はユーザが設定する。「null」はパーソナルデータストア３に提供しないことを示す。サービスＩＤについてのＰＤＳ管理値「hospA」は、端末装置１側でのサービスＩＤ「SP1」がパーソナルデータストア３側では仮名の「hospA」とされることを示す。

［事前フェーズ（登録）］
図１０において、ユーザが端末装置１のアプリ１２からパーソナルデータストア３に対してサービス登録を行おうとする場合、初回のアクセスであるか前回のセッションが無効になっている場合、認証処理を行う（ステップＳ１０１）。

すなわち、図１１において、端末装置１のアプリ１２は、サービス登録の場合（ステップＳ２０１のサービス登録）であって、未認証の場合（ステップＳ２０２のＹｅｓ）は、パーソナルデータストア３に対してＩＤおよびパスワード等の入力を伴う認証要求を行い（ステップＳ２０４）、認証結果を得る（ステップＳ２０５）。また、図１３において、パーソナルデータストア３のＰＤＳマネージャ３３は、端末装置１からメッセージ送受信部３１を介してメッセージを受信した場合（ステップＳ３０１）、メッセージの種類を判断する（ステップＳ３０２）。そして、メッセージの種類が認証要求である場合（ステップＳ３０３）、ＰＤＳマネージャ３３は、認証部３２によりＩＤおよびパスワードを受け付けて認証処理を行い（ステップＳ３０４）、端末装置１に対して認証結果のメッセージ送信する（ステップＳ３０５）。

図１０において、認証が正常に行われた後、端末装置１のアプリ１２は、パーソナルデータストア３に対して仮名のサービスＩＤとプロキシ経由であるか否か等の情報を伴うサービス登録要求を行う（ステップＳ１０２）。この処理は図１１のステップＳ２０６に対応する。

次いで、図１０において、サービス登録要求を受け付けたパーソナルデータストア３のＰＤＳマネージャ３３は、収集ＩＤを発行し、サービス登録を行う（ステップＳ１０３）。すなわち、図１３において、パーソナルデータストア３のＰＤＳマネージャ３３は、端末装置１からメッセージ送受信部３１を介してメッセージを受信した場合（ステップＳ３０１）、メッセージの種類を判断する（ステップＳ３０２）。そして、メッセージの種類がサービス登録要求である場合（ステップＳ３０６）、ＰＤＳマネージャ３３は、収集ＩＤを生成し、ユーザＩＤ、端末ＩＤ、サービスＩＤ（仮名）およびプロキシ利用等と対応付けて登録する（ステップＳ３０７）。プロキシ利用の場合、ＰＤＳマネージャ３３は、併せてプッシュＵＲＩを生成して登録する。なお、ユーザＩＤは認証処理から特定されており、端末ＩＤは端末装置１から取得される。

図１５はパーソナルデータストア３におけるサービス登録の例を示す図である。図１５において、端末装置１から仮名のサービスＩＤ「hospA」が指定され、プロキシ利用が指定された場合、パーソナルデータストア３のＰＤＳマネージャ３３は、収集ＩＤ「col1」およびPushURI「https://pds1.com/mydata/taro/medical」を発行し、データ収集管理情報テーブルＴ３１にユーザＩＤ「ID000abc」、端末ＩＤ「SIM01」、サービスＩＤ「hospA」、Ｐｒｏｘｙ利用「on」とともに登録する。また、ＰＤＳマネージャ３３は、サービス管理テーブルＴ３２にサービス種別「Medical」、サービス名「病院Ａ（仮名）」、サービスＩＤ「hospA」を登録する。ここで、サービス種別はサービス登録要求に際して伴われるものであり、サービス名は仮名である。サービスＵＲＩはパーソナルデータストア３が直接にアクセスするものではないため、ブランクとなっている。

図１０に戻り、パーソナルデータストア３のＰＤＳマネージャ３３は、サービス登録を行った後、メッセージ送受信部３１を介し、収集ＩＤを端末装置１に対して応答する（ステップＳ１０４）。この処理は図１３のステップＳ３０８に対応する。図１６は収集ＩＤの応答の例を示す図であり、ＨＴＴＰヘッダの末行の「Set-cookie:colID=col1;」の記述によって、端末装置１側のクッキー情報を設定することで、収集ＩＤ「col1」を応答している。今回は、クッキーを利用した例であるが、ＨＴＴＰヘッダに独自フォーマットを挿入する場合も考えられる。

次いで、図１０において、端末装置１のアプリ１２は、プロキシ部１３の管理のもと、パーソナルデータストア３から応答された収集ＩＤに端末装置１側でのサービスＩＤとサービスＵＲＩを対応付けて登録する（ステップＳ１０５）。この処理は図１１のステップＳ２０７に対応する。端末装置１側でのサービスＩＤとサービスＵＲＩは仮名である必要はなく、ユーザが識別しやすいものを使用することができる。図１７は端末装置１における収集ＩＤ等の登録の例を示す図であり、パーソナルデータストア３から応答された収集ＩＤ「col1」を、サービス登録要求の対象となった端末装置１側でのサービスＩＤ「SP1」とサービスＵＲＩ「https://hospital1.com/」に対応付けてサービス情報テーブルＴ１１に登録している。

［運用フェーズ（収集）］
図１０において、ユーザが端末装置１のアプリ１２からパーソナルデータストア３のサービス利用を行おうとする場合、前回のセッションが無効になっている場合、認証処理を行う（ステップＳ１１１）。

すなわち、図１１において、端末装置１のアプリ１２は、サービス利用の場合（ステップＳ２０１のサービス利用）であって、未認証の場合（ステップＳ２０３のＹｅｓ）は、パーソナルデータストア３に対してＩＤおよびパスワード等の入力を伴う認証要求を行い（ステップＳ２０４）、認証結果を得る（ステップＳ２０５）。また、図１３において、パーソナルデータストア３のＰＤＳマネージャ３３は、端末装置１からメッセージ送受信部３１を介してメッセージを受信した場合（ステップＳ３０１）、メッセージの種類を判断する（ステップＳ３０２）。そして、メッセージの種類が認証要求である場合（ステップＳ３０３）、ＰＤＳマネージャ３３は、認証部３２によりＩＤおよびパスワードを受け付けて認証処理を行い（ステップＳ３０４）、メッセージ送受信部３１を介し、端末装置１に対して認証結果のメッセージ送信する（ステップＳ３０５）。

図１０に戻り、認証が正常に行われた後、端末装置１のアプリ１２は、パーソナルデータストア３に対してサービスＩＤを伴うサービス利用要求を行い（ステップＳ１１２）、サービス利用が開始される。この処理は図１１のステップＳ２０８、Ｓ２０９に対応する。サービス利用が開始されると、サービスの内容に応じ、端末装置１とパーソナルデータストア３の間で対話的に処理が進められ、ユーザからの要求に応じた情報がパーソナルデータストア３から端末装置１に応答される。なお、ここでのサービス利用要求は、指定したサービス（サービスプロバイダ）から収集したパーソナルデータを用いた利活用のサービスをパーソナルデータストア３に対して要求するものである。パーソナルデータストア３自体が利活用のサービスを提供せず、他の事業者の提供するサービスにより利活用を行う場合は、パーソナルデータストア３に対し、サービス（サービスプロバイダ）を指定して、他の事業者の提供するサービスに対してパーソナルデータを提供する要求がサービス利用要求となる。いずれも、データベース３６に格納されたパーソナルデータの利用要求である。

次いで、図１０において、サービス利用要求を受け付けたパーソナルデータストア３のＰＤＳマネージャ３３は、端末側データ収集部３４により、端末装置１に対してパーソナルデータの収集依頼を行うか否か判断し（ステップＳ１１３）、収集依頼を行うと判断した場合には端末装置１に対して収集ＩＤとプッシュＵＲＩを送信する（ステップＳ１１４）。端末装置１では、プロキシ部１３の管理のもと、プッシュＵＲＩがＰＤＳ情報テーブルＴ１２（図７）に設定される。

すなわち、図１３において、パーソナルデータストア３のＰＤＳマネージャ３３は、端末装置１からメッセージを受信した場合（ステップＳ３０１）、メッセージの種類を判断する（ステップＳ３０２）。そして、ＰＤＳマネージャ３３は、メッセージの種類がサービス利用要求である場合（ステップＳ３０９）、サービス利用中とする（ステップＳ３１０）。そして、以下の処理を行う。

先ず、パーソナルデータストア３の端末側データ収集部３４は、サービス利用要求の対象となるサービスが、データ収集管理情報テーブルＴ３１においてＰｒｏｘｙ利用が「on」となっていて、収集判断テーブルＴ３３が設定されているか否か判断する（ステップＳ３１１）。設定されていない場合（ステップＳ３１１のＮｏ）、処理を終了する。設定されている場合（ステップＳ３１１のＹｅｓ）、端末側データ収集部３４は、収集判断テーブルＴ３３の設定情報から収集予測日を判断し（ステップＳ３１２）、現在日が収集予測日に到達しているか否か判断する（ステップＳ３１３）。

図１８は、サービス利用要求の対象となるサービスに対応する収集ＩＤ「col1」についての、データ収集管理情報テーブルＴ３１と収集判断テーブルＴ３３とを示している。図１８において、収集判断テーブルＴ３３では、収集ＩＤ「col1」について、利用頻度「４．１（回／日）」、データ最新記録「２０１４年５月１日」、処方日数「２１日」が設定されている。この場合、利用頻度が高く（１日１回以上）、「２０１４年５月１日」に病院に行って「２１日」分の薬の処方箋が出ているので、２１日後ぐらいに病院に行くことが予測される。従って、現在日が、データ最新記録の「２０１４年５月１日」から２１日後の所定日数前の収集予測日に到達しているか否か判断する。なお、ユーザ本人の情報に基づいてデータ収集のタイミングを判断する場合について説明したが、他ユーザの情報に基づいてデータ収集のタイミングを判断するようにしてもよい。

図１３に戻り、端末側データ収集部３４は、収集予測日に到達していない場合（ステップＳ３１３のＮｏ）、処理を終了する。収集予測日に到達している場合（ステップＳ３１３のＹｅｓ）、端末側データ収集部３４は、端末装置１に対する収集依頼（収集ＩＤ、Ｐｕｓｈ ＵＲＩ）をメッセージに設定し（ステップＳ３１４）、メッセージを応答する（ステップＳ３１５）。図１９は収集ＩＤおよびプッシュＵＲＩの応答の例を示す図であり、ＨＴＴＰヘッダの末行側の「Set-cookie:colID=col1;」「Set-cookie:URI=https://pds1.com/mydata/taro/medical」の記述によって、端末装置１側のクッキー情報を設定することで、収集ＩＤ「col1」とプッシュＵＲＩ「URI=https://pds1.com/mydata/taro/medical」を応答している。また、パラメータに"expires＝値"を付加することで、収集ＩＤ、プッシュＵＲＩの有効期間を設定することもできる。図２０はパーソナルデータストア３から端末装置１への収集依頼の例を示す図であり、端末装置１ではＰＤＳ情報テーブルＴ１２にパーソナルデータストア３から受け取ったプッシュＵＲＩを収集ＩＤ「col1」に対応付けて保持する。

次いで、図１０において、端末装置１のプロキシ部１３は、パーソナルデータストア３から収集依頼を示す応答を受信した場合、データ収集の要否を判断し（ステップＳ１１５）、データ収集すると判断した場合は、該当するサービスプロバイダ４にデータ収集要求を行い（ステップＳ１１６）、パーソナルデータの応答を受ける（ステップＳ１１７）。

すなわち、図１１において、端末装置１のプロキシ部１３は、サービス利用（ステップＳ２０９）の過程でパーソナルデータストア３から応答されるメッセージに収集依頼（プッシュＵＲＩの設定）が含まれるか否かにより収集依頼がされたか否か判断する（ステップＳ２１０）。収集依頼がされていない場合（ステップＳ２１０のＮｏ）、プロキシ部１３は、処理を終了する。収集依頼がされている場合（ステップＳ２１０のＹｅｓ）、プロキシ部１３は、後述する自主的にパーソナルデータの収集を行う処理により既に収集データがあるか否か判断する（ステップＳ２１１）。

収集データがない場合（ステップＳ２１１のＮｏ）、プロキシ部１３は、該当するサービスプロバイダ４に対してユーザに代理して自動的に認証処理を行い（ステップＳ２１２）、サービスプロバイダ４からパーソナルデータを収集する（ステップＳ２１３）。

次いで、図１０において、端末装置１のプロキシ部１３は、サービス機微/秘密情報定義テーブルＴ１４に基づいて収集データの加工等を行い（ステップＳ１１８）、サービス機微/秘密情報テーブルＴ１３に基づいて、既に通知されているパーソナルデータストア３のプッシュＵＲＩを宛先として収集ＩＤと収集データをプッシュ送信する（ステップＳ１１９）。パーソナルデータストア３の端末側データ収集部３４は、プッシュ送信されたデータをデータベース３６（図６）に格納し（ステップＳ１２０）、正常に処理された旨を応答する（ステップＳ１２１）。

すなわち、図１１において、端末装置１のプロキシ部１３は、サービス機微/秘密情報定義テーブルＴ１４（図７）に基づいて予め設定されたフォーマットに従ってデータの加工を行い、サービス機微/秘密情報テーブルＴ１３に基づいてデータの選択を行って登録する（ステップＳ２１４）。次いで、プロキシ部１３は、端末収集判断テーブルＴ１５（図７）を最新情報に基づいて更新し（ステップＳ２１５）、ＰＤＳ情報テーブルＴ１２（図７）に設定された宛先のプッシュＵＲＩにプッシュ送信する（ステップＳ２１６）。自主的に収集を行った収集データがある場合（ステップＳ２１１のＹｅｓ）、新たなデータ収集を行わず、既に収集して保持しているパーソナルデータをプッシュ送信する（ステップＳ２１６）。

次いで、図１３において、パーソナルデータストア３のＰＤＳマネージャ３３は、端末装置１からメッセージを受信した場合（ステップＳ３０１）、メッセージの種類を判断する（ステップＳ３０２）。そして、メッセージの種類がパーソナルデータ登録要求である場合（ステップＳ３１６）、ＰＤＳマネージャ３３は、端末側データ収集部３４によりデータベース３６（図６）にデータ登録を行い（ステップＳ３１７）、収集判断テーブルＴ３３（図８）を最新情報に基づいて更新し（ステップＳ３１８）、端末装置１に対してデータ受信の応答を行う（ステップＳ３１９）。図２１はパーソナルデータストア３におけるパーソナルデータの登録の例を示す図であり、端末装置１からパーソナルデータストア３に対して収集ＩＤ「col1」のパーソナルデータがプッシュ送信され、パーソナルデータストア３は受信したパーソナルデータを収集ＩＤ「col1」と対応付けてパーソナルデータテーブルＴ３４に登録している。

なお、図１３にはパーソナルデータストア３におけるメッセージ受信をトリガとした処理を示したが、端末装置１を経由しないデータ収集（図８のデータ収集管理情報テーブルＴ３１のＰｒｏｘｙ利用が「off」の収集）について、パーソナルデータストア３は定期処理によりサービスプロバイダ４からデータ収集を行う。

［端末装置による先行データ収集］
図１０において、端末装置１のプロキシ部１３は、所定のタイミングでデータ収集の要否を判断し（ステップＳ１３１）、データ収集すると判断した場合は、該当するサービスプロバイダ４にデータ収集要求を行い（ステップＳ１３２）、パーソナルデータの応答を受ける（ステップＳ１３３）。そして、端末装置１のプロキシ部１３は、収集データの加工等を行って内部的に保存する（ステップＳ１３４）。

すなわち、図１２において、端末装置１のプロキシ部１３は、端末装置１の負荷が低い時間帯等における定期処理を開始すると、端末収集判断テーブルＴ１５（図７）に該当する収集ＩＤについての情報が設定されているか否か判断する（ステップＳ２２１）。設定されていない場合（ステップＳ２２１のＮｏ）、処理を終了する。プロキシ部１３は、該当する収集ＩＤについての情報が設定されている場合（ステップＳ２２１のＹｅｓ）、端末収集判断テーブルＴ１５の設定情報から収集日を判断し（ステップＳ２２２）、現在日が収集日に到達しているか否か判断する（ステップＳ２２３）。

図２２は端末装置１における収集要否判断の例を示す図である。図２２において、端末収集判断テーブルＴ１５では、収集ＩＤ「col1」について、データ最新記録「２０１４年５月１日」、処方日数「２１日」、収集日「２０１４年５月１９日」が設定されている。これは、「２０１４年５月１日」に病院に行って「２１日」分の薬の処方箋が出ているので、２１日後ぐらいに病院に行くことが予測され、その数日前の「２０１４年５月１９日」が収集日とされている。従って、現在日が、収集日「２０１４年５月１９日」に到達しなければ収集を行わないとし、到達していれば収集を行うとする。

図１２に戻り、プロキシ部１３は、現在日が収集日に到達していない場合（ステップＳ２２３のＮｏ）、処理を終了する。また、現在日が収集日に到達している場合（ステップＳ２２３のＹｅｓ）、プロキシ部１３は、該当するサービスプロバイダ４に対してユーザに代理して自動的に認証処理を行い（ステップＳ２２４）、サービスプロバイダ４からパーソナルデータを収集する（ステップＳ２２５）。次いで、プロキシ部１３は、サービス機微/秘密情報定義テーブルＴ１４（図７）に基づいて予め設定されたフォーマットに従ってデータの加工を行い、サービス機微/秘密情報テーブルＴ１３に基づいてデータの選択を行って登録する（ステップＳ２２６）。そして、端末収集判断テーブルＴ１５（図７）を最新情報に基づいて更新する（ステップＳ２２７）。

［パーソナルデータの利活用の例］
図２３は病院情報の利活用の例を示す図である。図２３において、ユーザＡは、サービスプロバイダ４Ｐ１のパーソナルデータについては自己の端末装置１Ａを経由した収集とし、サービスプロバイダ４Ｐ２のパーソナルデータについてはパーソナルデータストア３から直接の収集としている。ユーザＢは、サービスプロバイダ４Ｐ３のパーソナルデータについてパーソナルデータストア３から直接の収集としている。

ユーザＡについて、サービスプロバイダ４Ｐ１から収集したパーソナルデータ「処方箋情報(セロトニン）、電子カルテ情報（適応障害）」については、病名の「適応障害」について機密／機微情報であるとして端末装置１Ａでブロックされ、パーソナルデータストア３には収集されない。機微／秘密情報に該当しない部分（薬名を含む）についてはパーソナルデータストア３に収集される。ユーザＡについて、サービスプロバイダ４Ｐ２のパーソナルデータ「処方箋情報(ステロイド）、電子カルテ情報（慢性気管支炎）」についてはそのままパーソナルデータストア３に収集される。ユーザＢについて、サービスプロバイダ４Ｐ３のパーソナルデータ「処方箋情報(アレグラ）、電子カルテ情報（慢性気管支炎、回復）」についてはそのままパーソナルデータストア３に収集される。

このような状況において、ユーザＡは、病院Ｐ１から処方された「セロトニン」と病院Ｐ２から処方された「ステロイド」の薬の飲み合わせチェックをパーソナルデータストア３または他のサイトにおける情報処理により判断してもらうことができる。本来は病院側で薬の飲み合わせチェックをしてくれるものではあるが、病名「適応障害」を意識して情報を共有できずに実施されない場合がある。しかし、本実施形態では機微／秘密情報を明確に区別できることで、機微／秘密情報に該当しない情報（この例では薬名）に基づいて利活用を図ることができる。なお、パーソナルデータストア３における薬の飲み合わせチェック等の情報処理は、図１１のステップＳ２０９および図１３のステップＳ３１０において行われる。

また、ユーザＡは、ユーザＢの名前を伏せた上で、病院Ｐ３での病名「慢性気管支炎」、薬「アレグラ」、「回復」の情報に基づき、自分の病名「慢性気管支炎」について症状の回復に役立つ情報（病院名、薬、生活等）を得ることができる。

図２４は銀行情報の利活用の例を示す図である。図２４において、ユーザＡは、サービスプロバイダ４Ｓ１、４Ｓ２のパーソナルデータについて自己の端末装置１Ａを経由した収集としている。ユーザＢは、サービスプロバイダ４Ｓ３のパーソナルデータについて自己の端末装置１Ｂを経由した収集としている。ユーザＡ、Ｂとも、サービスプロバイダ４Ｓ１〜４Ｓ３から収集したパーソナルデータ「口座番号、預金額」については機微／秘密情報であるとして端末装置１Ａ、１Ｂでブロックされ、パーソナルデータストア３には収集されない。機微／秘密情報に該当しない部分（収入、支出を含む）についてはパーソナルデータストア３に収集される。

このような状況において、ユーザＡは、銀行Ｓ１、Ｓ２の収入および支出に基づき、毎月の収入および支出の分析をパーソナルデータストア３または他のサイトにおける情報処理により実施してもらうことができる。また、ユーザＡは、ユーザＢの名前を伏せた上で、ユーザＢその他のユーザの収入および支出と比較した分析を実施してもらうことができる。なお、パーソナルデータストア３における収入および支出の分析等の情報処理は、図１１のステップＳ２０９および図１３のステップＳ３１０において行われる。

＜総括＞
以上説明したように、本実施形態によれば、端末装置を経由した情報の収集については、端末装置がサービス利用要求という形で常に処理のトリガを与えるため、端末装置にＷｅｂサーバ機能が設けられていなくても、端末装置がファイアウォールの背後にいても、モバイル環境により端末装置のＩＰアドレスが変更されても、パーソナルデータストアが情報の収集を行うことができる。それにより、パーソナルデータストアが主体となり、端末装置を経由して情報を収集する仕組を基本としつつ、実際の端末装置の構成および配置される環境に適用可能で、端末装置において情報の利用が行われる際に遅滞なく情報収集が行える、プライバシを考慮した情報収集の仕組を実現することができる。

ユーザの機微／秘密情報に関しては、ネットワークに接続せず、直接、端末装置で情報を見ることができる。

端末装置において機微／秘密情報を定義し、加工方法やパーソナルデータストアに管理させるか否か等を細かく設定できるため、柔軟なコントロールが可能である。

パーソナルデータストアは、端末装置からのサービス利用要求の都度に端末装置にデータ収集を依頼するのではなく、端末装置からのパーソナルデータストアの利用頻度と直近のデータ取得日（データ最新記録）を考慮し、データ収集が必要となるタイミングを管理して収集依頼を行うため、重複した無駄なデータ収集を削減することができる。

端末装置は、パーソナルデータストアから収集依頼を受けなくても、自主的にデータ収集が必要となるタイミングを管理してデータ収集（収集依頼とは非同期のデータ収集）を行う。そのため、パーソナルデータストアから収集依頼を受けた場合には、サービスプロバイダにアクセスすることなく即座にパーソナルデータをプッシュ送信でき、メッセージ処理の削減を図ることができる。端末装置はパーソナルデータストアとのメッセージやり取り、および、複数のサービスプロバイダからのデータ取得のために、端末処理の削減が重要となる。サービスプロバイダからのデータ取得には、代理ログイン処理からデータ取得処理まで複数のメッセージ処理が必要となり、１回の取得処理でも端末装置に負荷がかかる。そのため、これらのメッセージ処理の削減が必要となるが、収集依頼とは非同期のデータ収集により、端末装置の負荷が低い時にデータ収集を行うことができるため、サービスプロバイダから効率よくデータ収集を行うことができる。

以上、好適な実施の形態により説明した。ここでは特定の具体例を示して説明したが、特許請求の範囲に定義された広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により限定されるものと解釈してはならない。

パーソナルデータストア３は、情報収集装置の一例である。サービスプロバイダ４は、情報装置の一例である。データベース３６は、データベースの一例である。ＰＤＳマネージャ３３は、受付部の一例である。端末側データ収集部３４は、応答部の一例である。端末側データ収集部３４は、格納部の一例である。ＰＤＳマネージャ３３は、登録部の一例である。端末側データ収集部３４は、管理部の一例である。

以上の説明に関し、更に以下の項を開示する。
（付記１） ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置であって、
前記データベースに格納された情報の利用要求を端末装置から受け付ける受付部と、
前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答する応答部と、
前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する格納部と、
を備えたことを特徴とする情報収集装置。
（付記２） 付記１に記載の情報収集装置において、
前記端末装置から、前記情報装置の情報を識別する仮の名の識別情報と前記端末装置を経由した収集であるか否かを示す経由情報とを受け付け、情報の収集を識別する収集識別情報を発行し、ユーザ識別情報および端末識別情報と対応付けて前記識別情報と前記経由情報と前記収集識別情報とを登録し、前記収集識別情報を前記端末装置に返送する登録部、
を備え、
前記応答部は、前記利用要求に含まれる前記識別情報に対応付けられた前記経由情報が前記端末装置を経由した収集であると登録されている場合に、前記収集識別情報と収集した情報の宛先とを応答する、
ことを特徴とする情報収集装置。
（付記３） 付記１または２のいずれか一項に記載の情報収集装置において、
収集の対象となる情報毎に収集の頻度と最新の収集日と収集間隔とから次回の収集タイミングを管理する管理部、
を備え、
前記応答部は、前記利用要求を受け付けた現在日が前記収集タイミングに到達している場合に、前記収集依頼を応答する、
ことを特徴とする情報収集装置。
（付記４） 付記１乃至３のいずれか一項に記載の情報収集装置において、
前記格納部は、前記端末装置において収集の対象となる情報毎に最新の収集日と収集間隔とから次回の収集タイミングが管理され、該収集タイミングで予め情報の収集が行われている場合、前記端末装置から即座に送信された情報を前記データベースに格納する、
ことを特徴とする情報収集装置。
（付記５） 付記１乃至４のいずれか一項に記載の情報収集装置において、
前記応答部は、前記端末装置に応答する情報へのクッキー情報の設定により、前記収集依頼を応答する、
ことを特徴とする情報収集装置。
（付記６） 付記１乃至５のいずれか一項に記載の情報収集装置において、
前記端末装置における前記所定の不許可情報の除去は、機微情報または秘密情報について加工の態様および送信の有無の定義情報に基づいて行われる、
ことを特徴とする情報収集装置。
（付記７） ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置のプログラムであって、
前記データベースに格納された情報の利用要求を端末装置から受け付け、
前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答し、
前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する、
処理をコンピュータに実行させる情報収集プログラム。
（付記８） 付記７に記載の情報収集プログラムにおいて、
前記端末装置から、前記情報装置の情報を識別する仮の名の識別情報と前記端末装置を経由した収集であるか否かを示す経由情報とを受け付け、情報の収集を識別する収集識別情報を発行し、ユーザ識別情報および端末識別情報と対応付けて前記識別情報と前記経由情報と前記収集識別情報とを登録し、前記収集識別情報を前記端末装置に返送する、
処理をコンピュータに実行させ、
前記応答する処理は、前記利用要求に含まれる前記識別情報に対応付けられた前記経由情報が前記端末装置を経由した収集であると登録されている場合に、前記収集識別情報と収集した情報の宛先とを応答する、
情報収集プログラム。
（付記９） 付記７または８のいずれか一項に記載の情報収集プログラムにおいて、
収集の対象となる情報毎に収集の頻度と最新の収集日と収集間隔とから次回の収集タイミングを管理する、
処理をコンピュータに実行させ、
前記応答する処理は、前記利用要求を受け付けた現在日が前記収集タイミングに到達している場合に、前記収集依頼を応答する、
情報収集プログラム。
（付記１０） 付記７乃至９のいずれか一項に記載の情報収集プログラムにおいて、
前記格納する処理は、前記端末装置において収集の対象となる情報毎に最新の収集日と収集間隔とから次回の収集タイミングが管理され、該収集タイミングで予め情報の収集が行われている場合、前記端末装置から即座に送信された情報を前記データベースに格納する、
情報収集プログラム。
（付記１１） 付記７乃至１０のいずれか一項に記載の情報収集プログラムにおいて、
前記応答する処理は、前記端末装置に応答する情報へのクッキー情報の設定により、前記収集依頼を応答する、
情報収集プログラム。
（付記１２） 付記７乃至１１のいずれか一項に記載の情報収集プログラムにおいて、
前記端末装置における前記所定の不許可情報の除去は、機微情報または秘密情報について加工の態様および送信の有無の定義情報に基づいて行われる、
情報収集プログラム。
（付記１３） ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置が、
前記データベースに格納された情報の利用要求を端末装置から受け付け、
前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答し、
前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する、
情報収集方法。
（付記１４） 付記１３に記載の情報収集方法において、
情報収集装置が、前記端末装置から、前記情報装置の情報を識別する仮の名の識別情報と前記端末装置を経由した収集であるか否かを示す経由情報とを受け付け、情報の収集を識別する収集識別情報を発行し、ユーザ識別情報および端末識別情報と対応付けて前記識別情報と前記経由情報と前記収集識別情報とを登録し、前記収集識別情報を前記端末装置に返送し、
前記応答する処理は、前記利用要求に含まれる前記識別情報に対応付けられた前記経由情報が前記端末装置を経由した収集であると登録されている場合に、前記収集識別情報と収集した情報の宛先とを応答する、
情報収集方法。
（付記１５） 付記１３または１４のいずれか一項に記載の情報収集方法において、
情報収集装置が、収集の対象となる情報毎に収集の頻度と最新の収集日と収集間隔とから次回の収集タイミングを管理し、
前記応答する処理は、前記利用要求を受け付けた現在日が前記収集タイミングに到達している場合に、前記収集依頼を応答する、
情報収集方法。
（付記１６） 付記１３乃至１５のいずれか一項に記載の情報収集方法において、
前記格納する処理は、前記端末装置において収集の対象となる情報毎に最新の収集日と収集間隔とから次回の収集タイミングが管理され、該収集タイミングで予め情報の収集が行われている場合、前記端末装置から即座に送信された情報を前記データベースに格納する、
情報収集方法。
（付記１７） 付記１３乃至１６のいずれか一項に記載の情報収集方法において、
前記応答する処理は、前記端末装置に応答する情報へのクッキー情報の設定により、前記収集依頼を応答する、
情報収集方法。
（付記１８） 付記１３乃至１７のいずれか一項に記載の情報収集方法において、
前記端末装置における前記所定の不許可情報の除去は、機微情報または秘密情報について加工の態様および送信の有無の定義情報に基づいて行われる、
情報収集方法。
（付記１９） ネットワーク上の情報装置から情報を収集し該情報をデータベースに格納する情報収集装置に対し、前記データベースに格納された情報の利用要求を送信する要求送信部と、
前記利用要求の対象となる情報について、前記情報収集装置において前記情報装置から端末装置を経由した収集が必要であると判断された場合に、前記端末装置が前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を受信する応答受信部と、
前記利用要求の対象となる情報を前記情報装置から収集し、所定の不許可情報を除去した情報を前記宛先に送信する送信部と、
を備えたことを特徴とする端末装置。
（付記２０） ネットワーク上の情報装置から情報を収集し該情報をデータベースに格納する情報収集装置に対し、前記データベースに格納された情報の利用要求を送信し、
前記利用要求の対象となる情報について、前記情報収集装置において前記情報装置から前記端末装置を経由した収集が必要であると判断された場合に、前記端末装置が前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を受信し、
前記利用要求の対象となる情報を前記情報装置から収集し、所定の不許可情報を除去した情報を前記宛先に送信する、
処理をコンピュータに実行させる情報収集プログラム。

１、１Ａ〜１Ｃ 端末装置
１１ メッセージ送受信部
１２ アプリ
１３ プロキシ部
１４ データ制御部
１５ 収集／加工部
１６ ＰＤＳ側管理部
１７ ＳＰ側管理部
２ ネットワーク
３１ メッセージ送受信部
３２ 認証部
３３ ＰＤＳマネージャ
３４ 端末側データ収集部
３５ ＳＰ側データ収集部
３６ データベース
３７ ＰＤＳサービスアプリ
４、４Ｐ〜４Ｒ サービスプロバイダ
４１ メッセージ送受信部
４２ 認証部
４３ サービスアプリ
４４ データベース

Claims (8)

1. ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置であって、
   前記データベースに格納された情報の利用要求を端末装置から受け付ける受付部と、
   前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答する応答部と、
   前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する格納部と、
   を備えたことを特徴とする情報収集装置。
2. 請求項１に記載の情報収集装置において、
   前記端末装置から、前記情報装置の情報を識別する仮の名の識別情報と前記端末装置を経由した収集であるか否かを示す経由情報とを受け付け、情報の収集を識別する収集識別情報を発行し、ユーザ識別情報および端末識別情報と対応付けて前記識別情報と前記経由情報と前記収集識別情報とを登録し、前記収集識別情報を前記端末装置に返送する登録部、
   を備え、
   前記応答部は、前記利用要求に含まれる前記識別情報に対応付けられた前記経由情報が前記端末装置を経由した収集であると登録されている場合に、前記収集識別情報と収集した情報の宛先とを応答する、
   ことを特徴とする情報収集装置。
3. 請求項１または２のいずれか一項に記載の情報収集装置において、
   収集の対象となる情報毎に収集の頻度と最新の収集日と収集間隔とから次回の収集タイミングを管理する管理部、
   を備え、
   前記応答部は、前記利用要求を受け付けた現在日が前記収集タイミングに到達している場合に、前記収集依頼を応答する、
   ことを特徴とする情報収集装置。
4. 請求項１乃至３のいずれか一項に記載の情報収集装置において、
   前記格納部は、前記端末装置において収集の対象となる情報毎に最新の収集日と収集間隔とから次回の収集タイミングが管理され、該収集タイミングで予め情報の収集が行われている場合、前記端末装置から即座に送信された情報を前記データベースに格納する、
   ことを特徴とする情報収集装置。
5. 請求項１乃至４のいずれか一項に記載の情報収集装置において、
   前記応答部は、前記端末装置に応答する情報へのクッキー情報の設定により、前記収集依頼を応答する、
   ことを特徴とする情報収集装置。
6. 請求項１乃至５のいずれか一項に記載の情報収集装置において、
   前記端末装置における前記所定の不許可情報の除去は、機微情報または秘密情報について加工の態様および送信の有無の定義情報に基づいて行われる、
   ことを特徴とする情報収集装置。
7. ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置のプログラムであって、
   前記データベースに格納された情報の利用要求を端末装置から受け付け、
   前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答し、
   前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する、
   処理をコンピュータに実行させる情報収集プログラム。
8. ネットワーク上の情報装置から情報を収集し、該情報をデータベースに格納する情報収集装置が、
   前記データベースに格納された情報の利用要求を端末装置から受け付け、
   前記利用要求の対象となる情報について前記情報装置から前記端末装置を経由した収集が必要であるか判断し、必要である場合に、前記端末装置に対し、前記利用要求の対象となる情報を前記情報装置から収集して、収集した情報を所定の宛先に送信する旨の収集依頼を応答し、
   前記端末装置において前記情報装置から収集され、所定の不許可情報が除去され、前記宛先に送信された情報を前記データベースに格納する、
   情報収集方法。

Images