(57)【要約】      （修正有）【課題】個人情報に代表される、高い完全性が求められる情報を、複数のセキュリティ管理力に軽重差がある情報分散取得装置で取得するにあたり、情報提供者がシステムに寄せる信頼に可能な限り答える。【解決手段】複数の単位情報が組み合わされた集合情報を取得するにあたり、求められる機密性の程度によって単位情報を複数の類型に分割、分割類型毎に異なる処理系が情報取得処理を行う。この際、評価価値の最も低い情報を取得した処理系が取得処理をし、その後評価価値の高い情報取得処理系が出自を明らかにしつつ残余の情報の取得を促して取得する手順に従い、順次全集合情報の取得を行う。要約値を用いることでシステム全体として完全性を維持する。これにより、コストがかかる高機密性情報取得処理系の小規模化、処理系全体で優れた完全性の維持、効率な資源利用を図る。【選択図】図２
2016081446.tif 000002
【特許請求の範囲】
【請求項１】
情報提供者から提供された第１の提供情報と、第１の提供情報に対して所定の要約値演算処理が加えられた要約値とを受け取るとともに、第１の提供情報より高い価値類型に属する第２の提供情報を取得する情報分散取得装置であって、
該情報分散取得装置を識別させる表示を伴い、第２の提供情報の提供を情報提供者に促す高価値類型情報提供促進手段と、
該高価値類型情報提供促進手段によって情報提供を促された情報を取得・記録する高価値類型情報取得手段と、
第１の提供情報と第１の提供情報に係る要約値とを受領する低価値類型情報受領手段と、
第１の提供情報を要約値演算して、受け取った該要約値と突合演算により第１の提供情報の正当性を評価する正当性評価手段と
を具備することを特徴とする情報分散取得装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の単位情報が組み合わされた集合情報を、分散した複数の情報取得処理系によって取得する、情報分散取得装置に係る。詳しくは、所定の価値評価基準より評価価値が低い情報を一の情報取得処理系で取得した後に、それより評価価値の高い情報を他の情報取得処理系で取得するように分散取得処理をし、かつ情報提供者が提供する情報の重要度に対応して情報取得処理系毎の信頼性を正しく認識できるように構成した情報分散取得装置に関するものである。
【背景技術】
【０００２】
（１．  本発明に至る社会的背景）
（１．１．  本発明に至る社会的状況）
近時、人権尊重の観点から、人格的利益の側面をもつプライバシの扱いが見直されてきている。我が国においてプライバシそのものは、未だ権利というまでの扱いがされてはいないものの、プライバシの一態様となって表われた個人情報は、個人情報保護法、行政機関における個人情報保護法をはじめとして、条例などによっても厳格に保護されるようになってきている。
【０００３】
この背景には、ＯＥＣＤ８原則がある。ＯＥＣＤ８原則は、情報主体の主観と客観との一致の要請に応えることを基調としている。すなわち、個人から提供される個人情報と個人情報取扱者が保有する個人情報とが一致しており、他人に漏洩されず、かつ他の目的には用いられないことは、情報を提供する者の合理的意思である。そして個人情報取扱者にはその合理的意思に合致するような行動が求められている。
【０００４】
（１．２．  本発明で保護しようとするプライバシ）
そもそも個人情報の保護の要請は、プライバシの保護を目的とする。プライバシについては、様々なアプローチでその本質について議論されているが、個人が自己に係る情報の取扱いについて自律的に決定をする自由を基礎とする点については争いがないものと思われる。
この点に着目すると、情報提供者が個人情報を他人に提供するか否かの判断や、その内容の決定にあたっては、情報提供先に寄せている信頼が極めて重要な要素になる。
情報提供者は、商標・商号やサーバのＵＲＬなどを手掛かりとして、情報提供先の信頼性を判断する。このため情報提供者は、商標・商号やＵＲＬが信頼をおける情報提供先のものであることが分かると、安心して情報を提供することができるようになるわけである。
これは言い換えれば、情報提供先たる情報受領者が複数の事業者であり、複数のサーバに跨って受領するような場合には、情報提供者の錯誤を招く虞があることを示唆している。
【０００５】
（２．  本発明に係る背景技術）
上記のような社会的背景のもと、個人情報を記録するデーターベースシステムには極めて重い役割が期待されるのであるが、この点についてはＪＩＳ  Ｑ  ２７００１等で一般的基準が提案されている。
【０００６】
すなわち、ＪＩＳ  Ｑ  ２７００１において情報セキュリティマネジメントシステムは、情報の機密性・完全性・可用性を維持すべき旨を求めている。ここで、機密性 (confidentiality)とは、情報へのアクセスを認められた者だけがその情報にアクセスできる状態を確保することを意味する。また、完全性とは、情報が破壊、改ざん又は消去されていない状態を確保することをいう。
【０００７】
これらの要求を満たすため、システムには高度な管理プログラムを配し、また常に即応可能な担当者を常駐させて監視する必要がある。言い換えれば、保有個人情報を取り扱うシステムはコストが跳ね上がる傾向があると言わざるを得ない。
【０００８】
ところで、複数の事業者によってひとつの情報の集合である個人情報を取得する場合、一の事業者が取得する情報の部分集合が個人に係る情報であっても個人を特定するに至らない場合がある。このとき、その事業者の取得する情報部分集合は個人情報保護法上の「個人情報」にはあたらないため、他の情報を持たないならば高い機密性を有するシステムによる管理をする必要がなくコストの低減を図れる筈である。
【０００９】
このような背景から、先行技術の特許文献１では、複数の異なる情報がひとつのまとまりとなって表される情報を分割し、分割された情報の部分集合をそれぞれ別個のシステムで取得する技術が提案されている。そして、この先行技術においてシステムで取り扱う情報の取得については、高度な秘匿性対応をしたシステムで受け取った後、秘匿性対応レベルが低いシステムに分配記録させるという手法を採っている（同文献段落００８０以降参照）。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許第４７７１５２８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかし、情報提供者が段階的かつ連続的に情報を提供する場面では、情報提供者は最初に操作・表示装置で認めた表示によって、一連の情報取得システムの信頼性を把握し、これを前提に作業を行うのが通常である。従って、上記技術によると、情報提供者が最初にアクセスするのが高度なセキュリティ・レベルのシステムであるから、その程度を信頼して情報を提供するというのが情報提供者にとっての合理的意思というべきものである。
【００１２】
とすれば、もし一部でも秘匿性の低いシステムによって管理されるならばそもそも情報を提供しなかったと推認することもできる。
【００１３】
すなわち、情報提供者は最初にアクセスした情報取得装置のセキュリティを信頼して情報提供をしている。これより低いセキュリティ・レベルしかない情報取得装置が介在するならば、それは情報提供者の合理的意思と異なることになり、情報提供者の信頼を裏切る結果になるわけである。
【課題を解決するための手段】
【００１４】
課題を解決するための手段の説明に先立ち、説明の便宜上、本願明細書における文言を以下のように定義する。なお、図３にこれらの情報に係る文言についての相互の包含関係図を示して説明する。
【００１５】
「単位情報」（３１２−１，−２、・・・）とは、単体で意味をもつ情報である。個人情報でたとえると、氏名、住所、電話番号等、それぞれがこれにあたる。
【００１６】
「情報集合」（３３１）とは、コンピュータによって処理するにあたり複数の異なる単位情報のまとまりであって、個人情報でたとえると、一組の（氏名・住所・電話番号・その他の単位情報）がこれにあたる。
【００１７】
「情報部分集合」（３１３，３２３，・・・）とは、情報集合が包含する部分集合であって、その要素が単位情報単体となる場合があることは勿論、複数の単位情報（３１２−１，−２、・・・）となる場合もある。
【００１８】
「提供情報」とは、情報を提供する者が何らかの手段を用いて提供する情報をいい、単位情報、情報集合、情報部分集合のいずれかを問わない。
【００１９】
「情報価値評価基準」とは、複数の要素によって組み合わされた情報集合につき、これをすくなくとも２つに分割する基準である。この基準は定量的な基準であっても、定性的な基準であってもよい。
【００２０】
次に本発明に係る課題を解決するための手段の内容について図１１を用いて説明する。なお、図を用いるのは理解促進のためであり、実装状態が図１１の図示に限られるわけではない。
本発明は上記課題の低減を図るものであって、その目的とするところは、所定の価値評価基準において評価価値が低い情報を取得した後に、それより評価価値の高い情報を後段の情報取得装置で取得するように分散取得し、情報提供者が提供する情報の重要性に対応して各情報取得装置の信頼性を正しく意識できるようにしたシステムを提供し、システム構成と情報提供者の信頼性に係る認識とを可能な限り一致させ、情報提供者の信頼に錯誤が生じにくくする点にある。この文脈に従うため、本発明に係る手段は以下のように構成している。
【００２１】
すなわち請求項１に記載の発明は、情報集合の取得にあたり、その情報部分集合の取得を担う情報分散取得装置（１１０５）であって、高価値類型情報提供促進手段（１１５１）と、高価値類型情報取得手段（１１５３）と、低価値類型情報受領手段（１１５４）と、正当性評価手段（１１５２）と、を具備する。
【００２２】
ここで、情報分散取得装置は、当該情報分散取得装置の他に情報分散取得装置（１１５７）など、他の情報部分集合を取得乃至記録する装置が存在していることを前提としている。この、他の情報分散取得装置（１１５７）は、情報提供者（１０３）から提供された第１の提供情報を取得するようになっている。ここで、情報価値評価基準において評価価値の低い第１の提供情報は、情報部分集合である。また外部情報取得装置は、当該提供情報並びに予め記憶している情報に対して要約値演算処理を加えることができるようになっている。なお、要約値演算の入力は第１の提供情報と予め記憶している情報のうちの一部若しくは全部を対象とすることができる。また、単位情報の異なる組合せを選択し、複数種類の要約値を得てもよい。
なお、要約値とは、所定の鍵情報を用い、与えられた原情報に演算を加えて得られる疑似的な乱数値のことをいい、同一の鍵と同一の原情報とをもって演算すれば同じ要約値となる性質を持つ。一方、鍵が異なれば、同一の原情報でも、異なる要約値になる性質を持つ。
要約値演算処理とは、原情報から所定の鍵を用いて要約値を求める演算処理のことをいう。
【００２３】
高価値類型情報提供促進手段（１１５１）は、高評価類型情報提供促進情報を生成する。この促進情報は、前記外部情報取得装置によって取得された情報部分集合とは異なる情報部分集合を情報提供者（１０３）に提供を促す内容を持つ情報であって、情報提供者の使用する情報入力装置にその促す旨を表示させる情報である。この際、情報提供促進情報には、当該情報分散取得装置（１１０５）を識別させる表示情報も含む。
すなわち、高価値類型情報提供促進手段は、前記外部情報取得装置（１１５７）によって取得された第１の提供情報とは異なる第２の提供情報の提供を、当該情報分散取得装置（１１０５）を識別させる表示とともに、情報提供者に促す指示を生成するように作用する。
【００２４】
高価値類型情報取得手段（１１５３）は、所定の価値評価基準に従うと第１の提供情報より高い評価類型に属するものであって、情報提供者による提供情報を取得するようになっている。すなわち、第２の提供情報の入力を促された情報提供者が、その促し応じて提供する情報を本情報分散取得装置（１１０５）内に取得するように作用する。
【００２５】
整理していうならば、第１の提供情報と第２の提供情報とは、ともに同一の情報集合に含まれる部分集合であるが、予め決められた価値評価基準によれば、第１の提供情報はこれより低い価値のものであるのに対し、第２の提供情報は基準より高い価値のものである点で異なる。
【００２６】
低価値類型情報受領手段（１１５４）は、前段の情報分散取得装置（１１５７）から、第１の提供情報若しくはその一部（１１５５）を受領するようになっている。また、第１の提供情報若しくはその一部に係る要約値（１１５６）を受領するようになっている。
すなわち、低価値類型情報受領手段（１１５４）は、前段の情報分散取得装置（１１５７）から、協調的に取得する情報集合の情報部分集合を関連付ける情報と正当性評価の為の基礎情報を本情報分散取得装置（１１０５）に取り込むように作用する。
【００２７】
正当性評価手段（１１５２）は、前段の情報分散取得装置（１１５７）から得た第１の提供情報（１１５５）を要約値演算し、その結果を、受け取った要約値（１１５６）と突合演算することにより第１の提供情報（１１５５）の正当性を評価するようになっている。要約値演算した結果と第１の提供情報とが一致しているならば前記要約値の性質から同一の鍵が用いられたことを確認できるように作用する。
すなわち、予め共通の鍵をもつ情報分散取得装置で取得した情報であることを確認できるように作用する。
【発明の効果】
【００２８】
本発明に係る情報分散取得装置によれば、所定の価値評価基準より価値評価が低い情報を取得した後に、高い評価価値情報を取得する情報提供先から情報提供を促され、それに応じて情報提供者は高い価値評価の情報を提供するという手順を採ることになる。このため情報提供者にとって、高い価値評価の情報を提供する段階では、情報提供先を意識せざるを得ず、当初把握していた信頼性より更に高い信頼性をおけるものでなければならないと改めて意識することになる。すなわち、情報提供者にとっては重要性の異なる情報提供毎に、その都度提供先の信頼性を意識することとなり、これらを総合すれば分散して存在する情報取得装置全てにおいて、信頼性の錯誤を起こさせ難い状態で情報取得をすることができる。
またこの際、信頼性の異なる情報取得装置との間では、正当性評価手段の作用によって情報部分集合が一の情報集合に属することが保証される。これらを一体的にみると、低評価価値に属する提供情報を取得する情報取得装置の信頼性に引きずられて全体の信頼性を落とすことなく、分散した各情報取得装置の信頼性の独立性を維持することができるようになる。
以上のようにして、情報提供者が認識する情報部分集合ごとの信頼性（主観的信頼性）と、分散して存在する各情報取得装置の信頼性（客観的信頼性）とを一致させることができる。これはすなわち、情報提供者の信頼を裏切らず、機密性・完全性の優れたセキュアな情報取得を保証することができるようになることを意味する。
【図面の簡単な説明】
【００２９】
【図１】図１は、本発明に係る情報分散取得装置が想定するシステム全体概要図である。
【図２】図２は、本発明に係る情報分散取得装置が想定するシステム全体の動作概要説明図である。
【図３】図３は、本明細書において用いる情報関連概念の相互関係概念図である。
【図４】図４は、本発明に係る第１の実施の形態における動作フロー図である。
【図５】図５は、本発明に係る第２の実施の形態における動作フロー図である。
【図６】図６は、本発明に係る第１の実施の形態で扱われる情報フロー図である。
【図７】図７は、本発明に係る情報分散取得装置が情報提供者に対して入力した情報の確認を求める際に出力する確認促進情報リスト例図である。
【図８】図８は、第１の実施の形態に係るシステム・情報関連説明図である。
【図９】図９は、第１の実施の形態に係る販売者サーバ構成図である。
【図１０】図１０は、第１の実施の形態に係る銀行サーバ構成図である。
【図１１】図１１は、本願発明の請求項１に係る情報分散処理装置の機能構成図である。
【発明を実施するための形態】
【００３０】
本考案を実施するための形態については、以下の目次に沿って説明する。
-------------［目次］-------------
（１．  前提となるシステムについて）  
（１．１．  前提となるシステムの構成概要）
（１．２．  前提となるシステムの動作概要）
（１．３．  本システムにおける評価基準のもつ意義）
（１．４．  システム構成の変形）
（１．５．  前提となるシステムによる技術的効果）
（２．  第１の実施の形態について）
（２．１．  第１の実施の形態における情報価値評価基準について）
（２．２．  第１の実施の形態の構成について）
（２．２．１  システムの構成と取得情報との関係）
（２．２．２  販売者サーバの構成について）
（２．２．３  銀行サーバの構成について）
（２．３．  第１の実施の形態の動作について）
（３．  第２の実施の形態について）
（４．  その他）
（４．１．  情報価値評価基準の例）
（４．２．  セキュリティ維持のためのＳＳＬ通信について）
（４．３．  実施の形態と本願発明との対応について）
（４．４．  他の目的のシステム構築）
（４．５．  振込作業開始処理について）
【００３１】
-------------［本文］-------------
（１．  前提となるシステムについて）
（１．１．  前提となるシステムの構成概要）
本願発明に係る情報分散取得装置はシステムの一部として実装され、そのシステムは情報集合の取得を目的として構成される。そこで、本発明に係る情報分散取得装置を説明するに先立ち、情報分散取得装置の実装を想定するシステムについて、図１に基づいて説明する。図１は、本発明に係る情報分散取得装置の実装が想定されるシステム全体概要図である。
本前提システムでは、前置情報分散取得装置（１０１）、情報分散取得装置（１０５）、後置情報分散取得装置（１０７）が総合して、ネットワーク（１０６）と情報提供者用操作装置（１０４）とを通じて情報集合を操作者（１０３）から取得するものである。そして、本願発明は、情報分散取得装置（１０５）のほか、後置情報分散取得装置（１０７）にも実装が可能である。
【００３２】
情報提供者用操作装置（１０４）は、ネットワーク（１０６）に接続され、操作者（１０３）の操作によって特定した情報取得装置から、所定の情報部分集合の提供を促す提供促進情報を受け、その情報提供を促す表示をするとともに、同操作者（１０３）によって入力された情報部分集合を提供促進情報中に含まれる指定の情報取得装置に対して送信することができるようになっている。
具体的には、例えばブラウザと呼ばれるプログラムが実装された、パーソナル・コンピュータがこれにあたる。
【００３３】
前置情報分散取得装置（１０１）は、情報価値評価基準で最も評価価値が低い情報部分集合を取得する装置であって、ネットワーク（１０６）に接続され、情報提供者用操作装置（１０４）に対して情報部分集合の提供を促すとともに、その情報提供者用操作装置から、提供された情報部分集合を受けることができるようになっている。
【００３４】
情報分散取得装置（１０５）は、本願発明に係る情報分散取得装置が実装された装置である。すなわち、ネットワーク（１０６）に接続され、情報提供者用操作装置（１０４）に対して情報部分集合の提供を促すとともに、その情報提供者用操作装置から、提供された情報部分集合を受けることができるようになっている。この情報分散取得装置（１０５）が取得する情報部分集合は、前置情報分散取得装置（１０１）が取得する情報部分集合より評価価値が高い情報部分集合である。
【００３５】
後置情報分散取得装置（１０７）は、前置情報分散取得装置（１０１）、情報分散取得装置（１０５）と同様に、ネットワーク（１０６）に接続され、情報提供者用操作装置（１０４）に対して情報部分集合の提供を促すとともに、その情報提供者用操作装置から、提供された情報部分集合を受けることができるようになっている。この後置情報分散取得装置（１０７）が取得する情報部分集合は、前記の情報分散取得装置（１０５）が取得する情報部分集合よりさらに評価価値が高い情報部分集合である。
【００３６】
（１．２．  前提となるシステムの動作概要）
次に、本発明に係る情報分散取得装置の実装が想定されるシステム全体の動作の概要について、図２に基づいて説明する。図２は、前記システム全体の動作概要説明図である。
【００３７】
本システムの動作を説明するにあたり、一商品の販売元が販売した商品ごとにキャッシュバックを購入者の銀行口座に行うシナリオを例に用いる。このシナリオでは、前置情報分散取得装置を販売者が管理し、情報分散取得装置並びに後置情報分散取得装置を銀行が管理する。また、情報提供者用操作装置は、通常家庭で用いられているような、ブラウザ・ソフトを搭載したパーソナル・コンピュータであるとする。
【００３８】
情報提供者は、情報提供者用操作装置（１０４）を通して、商品販売者のサーバである前置情報分散取得装置に手続開始を要求する（２０１）。具体的には、商品販売者に対して自分が購入した商品のキャッシュバックの手続きをするＵＲＬを入力するなどして前置情報分散取得装置を特定し、キャッシュバック手続きのための開始頁参照要求を送信することになる。
【００３９】
手続開始要求を受けた前置情報分散取得装置（１０１）は、情報価値評価基準上最も評価価値が低い情報部分集合（図２で「第１情報」と表記する）の入力を促す表示情報を生成し、これを情報提供者用操作装置に返送する（２０２）。ここで、最も評価価値が低い情報部分集合には、購入商品のシリアル番号など、個人を特定するとまでは言えない程度の単位情報が含まれる。
【００４０】
入力促進情報を受けた情報提供者用操作装置（１０４）は、操作者に対し、前置情報分散取得装置が取得すべき情報入力を促す表示をし、操作者の情報提供を待つ。そして、操作者が情報を入力したら、これを前置情報分散取得装置に送り返す（２０３）。
【００４１】
第１情報を前置情報分散取得装置（１０１）が受けると、この情報に基づいて自社の商品に係る手続要求であることを確認する処理をする。そして確認が採れたら、その情報に基づいて処理を続けて良いかどうかの確認を促す情報を送出する（２０４）。
ここで、確認を促す表示情報には、この情報確認の次には機密性の高い情報入力をすること、並びに、その機密性の高い入力を処理するサーバは銀行のサーバなど、別の機密処理が可能な処理装置が担うことを含めておくのが望ましい。更に、確認情報を送信する宛先が情報分散取得装置（１０５）である旨の情報を含めておくのが望ましい。これは、情報提供者が次に入力する情報が機密性を維持すべき重要なものであることを意識させ、並びにその情報提供先について信頼できるものかどうかを判断する契機になるからである。すなわち、情報分散取得装置を識別する識別情報をここで提供することで、情報提供者の情報提供先に対する主観と客観の一致を採るように作用する。なお、識別情報はＵＲＬ自体であっても構わないが、商標などを用いるとユーザーフレンドリなシステムに仕上がる。
【００４２】
確認を促す情報を受けた情報提供者用操作装置（１０４）は、表示・発音など、操作者に確認させるための動作をするとともに、操作者からの確認操作を受け付ける。そして、確認ボタンのクリックなど、確認した旨の操作があったときには、その旨を情報分散取得装置に対して送信する（２０５）。送出する「確認を促す情報」に情報分散取得装置のＵＲＬが含められていれば、情報提供者用操作装置は上記入力情報確認（２０４）の処理でＵＲＬをそこから把握できるので、単純に確認ボタンのクリックなどだけで済むなど、操作者の操作は極めて容易になる。
【００４３】
確認をした旨の情報を情報分散取得装置（１０５）が受けると、これに基づいて情報分散取得装置は、受け取るべき情報部分集合の入力を促す。このために、情報分散取得装置は当該情報部分集合に係る単位情報の入力を促す情報を作成し、これを情報提供者用操作装置に返信する（２０６）。ここで入力を促すべき情報は、情報分散取得装置が受け取るべきものであって、前置情報分散取得装置が受け取る情報部分集合より情報価値評価基準上評価価値が高い情報部分集合（図２で「第２情報」と表記する）に係る。この類型の情報部分集合には、たとえば、その操作者の氏名・生年月日などに加え、その者の銀行口座番号などを含めることができる。
【００４４】
第２情報の入力促進情報を受けた情報提供者用操作装置（１０４）は、操作者に対して情報分散取得装置が取得すべき情報部分集合の入力を促す表示をして、操作者の情報提供を待つ。そして、操作者がこれらの単位情報を入力したら、これを情報分散取得装置に送り返す（２０７）。
【００４５】
第２情報を情報分散取得装置（１０５）が受けると、この情報に基づいて、前置情報分散取得装置と協働してする情報取得の一部であることを確認する処理をする。そして確認が採れたら、その情報に基づいて処理を続けて良いかどうかの確認を促す情報を送出する（２０８）。ここで、確認を促す情報には、この情報確認の次には更に機密性の高い情報入力をすること、並びに、その機密性の高い入力を処理するサーバは更に高度に別の機密処理が可能な処理装置が担うことを含めて情報提供者操作装置に表示できるようにしておくのが望ましい。更に、確認情報を送信する宛先が、情報分散取得装置に加え、後置情報分散取得装置である旨の情報を含めておくのが最適である。
【００４６】
以下、前述した一連の処理と同様に、確認情報を受けた情報提供者操作装置は、確認を促す処理などを経由して、後置情報分散取得装置への送信（２０９）、後置情報分散取得装置での入力促進（２１０）、更に報提供者操作装置における更なる情報入力などを続けることになる。
このように本システムでは、情報の取得装置は並列的に配置するものの、その処理は次第に評価価値が高い情報部分集合を取得していくように、カスケード状に動作することになる。
【００４７】
（１．３．  本システムにおける情報価値評価基準のもつ意義）
情報価値評価を取り入れることで、情報取得システムに対する様々な責務負担・機能負担の分散を容易にし、システム構成の自由度を高めることができるようになる。たとえば上記のように、第１情報として購入商品のシリアル番号など、個人を特定するとまでは言えない程度のものとすれば、前置情報分散取得装置で取得する情報は、個人情報の保護に関する法律における「個人情報」を取得したことにはならず、この前置情報分散取得装置の管理者は個人情報取扱事業者として扱われることなく、事業を運営することが可能となる。
【００４８】
一方、第２情報によって個人情報を把握できるものの、かかる情報を取得する動作は銀行などの機密性処理を得意とする事業者に集中させることができ、システム全体の機密性を担保できる。このように、機密性を維持しつつ、取得情報を適切に分割することができるように機能するわけである。
【００４９】
以上のようにシステムは、複数の情報分散取得装置を並列させ、かつ情報価値評価基準に従ってカスケードに順次動作させることによって、異なる情報価値評価に分類される情報部分集合を順次取得する。そして、特に本発明に係る情報分散取得装置は情報価値評価が低い方から２番目以降の情報部分集合を取得するために実装することができる。
【００５０】
（１．４．  システム構成の変形）
以上の説明では、前置情報分散取得装置がひとつと後置情報分散取得装置がひとつとを用いるシステムを説明したが、前置情報分散取得装置を複数設けるシステムに実装することができる。また、後置情報取得装置を設けないシステムにも実装できる。
【００５１】
（１．５．  前提となるシステムの技術的効果）
このように、本発明に係る情報分散取得装置が実装を想定するシステムは、情報価値評価基準によって分割した取得情報毎に適切な主体による適切な機密性処理の分担を図ることができるようになる。
【００５２】
（２．  第１の実施の形態について）
前記（１．  前提となるシステムについて）では本願発明に係る情報分散取得装置が実装されるシステムと情報取得の動作概要とを説明した。ここでは、本願発明に係る情報分散取得装置そのものの実装を中心に、第１の実施の形態について説明する。特に情報分散取得装置についての、セキュリティ維持も含めた具体的な実施の形態を中心に説明する。
【００５３】
第１の実施の形態は、振込データ作成サービスを実施するシステムに、本発明に係る情報分散処理装置を実装した例である。そして特に振込データを作成する一場面として、一商品の販売元が販売した商品ごとにキャッシュバックを購入者の銀行口座に振り込むというサービスを、販売者と銀行とが協働して実現することを想定している。なお、以下このサービスのことをキャッシュバック・サービスということにする。
【００５４】
（２．１．  第１の実施の形態における情報価値評価基準）
本実施の形態では、装置単体で取り扱う情報部分集合だけで個人情報といえるか否かを情報価値評価基準とする。そして、個人情報とまではいえないものを低い価値評価、個人情報といえるものを高い価値評価とする。より具体的には、価値評価が低い情報部分集合として、商品型番号、商品シリアルＩＤ、キャッシュバック・サービスＩＤなどの商品特定情報が含まれる。また価値評価が高い情報部分集合として、個人の口座名義、口座情報などの個人特定情報が含まれる。
【００５５】
（２．２．  第１の実施の形態の構成について）
第１の実施の形態は、ひとつの前置情報分散取得装置と、本願発明が実装されたひとつの情報分散取得装置とで情報取得を行うように構成されている。
【００５６】
（２．２．１  システムの構成と取得情報との関係）
全体のシステムの構成について、図８を用いて説明する。図８は、第１の実施の形態に係るシステム・情報関連説明図である。
本実施の形態は概ね、情報提供者用操作装置（１０４）と、販売者サーバ（８０１）、また、情報提供者用操作装置（１０４）と銀行サーバ（８０５）とが、ネットワーク（１０６）を介して相互に通信可能となるように構成されている。
【００５７】
ここで、第１の実施の形態と前述の（１．  前提となるシステムについて）との関係は、販売者サーバ（８０１）が前置情報分散取得装置（１０１）に、また、銀行サーバ（８０５）が情報分散取得装置（１０５）にそれぞれ相当する。
販売者サーバ（８０１）は、販売者用データーベースをアクセスでき、ここには情報部分集合としての商品特定情報群（８１３）が記録される。商品特定情報群は商品シリアルＩＤなどが含まれる。また、銀行サーバ（８０５）は銀行用データーベースをアクセスでき、ここには、情報部分集合としての個人特定情報群（８２３）が記録される。商品特定情報群はその口座名義、口座情報などが含まれる。
【００５８】
（２．２．２  販売者サーバの構成について）
販売者サーバ（８０１）の構成について、図９を用いて説明する。図９は第１の実施の形態に係る販売者サーバ構成図である。
【００５９】
リクエスト入力部（９０１）は、ＯＳのネットワークインターフェースやフレームワークを介して間接的に若しくは直接的にネットワーク（１０６）に接続する。そして、ネットワークを介して本装置外部から所定の処理の要求を受けるようになっている。
ここで、フレームワークとは、例えば  Apache Struts2（ジ  アパッチ  ソフトウェア  ファウンデイションの商標）等、ＷＥＢアプリケーションを作成するためのプログラム・スケルトンを意味する。処理の要求は、ＵＲＬの形、たとえば、http://販売者サーバドメイン名/〜?request=〜のように表現されるのが通常である。
【００６０】
リクエスト解析部（９０２）は、リクエスト入力部（９０１）から処理の要求を受け、リクエスト入力部で受けた外部からの要求の内容を解析し、実行すべき動作を選択するようになっている。処理要求にパラメータを含んでいるときには、後述するアクション実行部（９０３）での処理が容易になるように、リクエスト解析部がそのパラメータを分離・抽出することが望ましい。たとえば、Apache Struts2（ジ  アパッチ  ソフトウェア  ファウンデイションの商標）にはこの部分が含まれている。
【００６１】
アクション実行部（９０３）は、リクエスト解析部（９０２）でされた解析結果に基づいて、選択された動作を実行する。たとえば、Apache Struts2をフレームワークに用いる場合には、ActionSupportの継承クラスとして作成されたオブジェクトであったり、当該継承クラスから呼び出され実行するオブジェクトであったりする如き部分がこれにあたる。アクション実行部（９０３）は、本サーバ内に若しくは外部装置として用意されたデーターベース（９０４）に対して、記録の照合・検索ができるようになっている。
【００６２】
販売者用データーベース（９０４）は、予めデータを記録でき、求めに応じて特定の単位情報の一部若しくは全部をキーとする検索ができ、必要に応じて既登録データの削除ができるようになっている。
ここには、個人情報とまでは言えない単位情報で構成される商品特定情報群を記録する。たとえば、販売品のシリアル情報、購買品の最終販売店などが挙げられる。
【００６３】
要約生成部（９０６）は、アクション実行部（９０３）から呼び出され、受け取った情報から、図示しない鍵情報を用い、ひとつの要約値を作成するようになっている。要約値の生成はハッシュ関数と呼ばれる演算をすることで実現できる。
ここで、鍵情報は、予め販売者と銀行との間で取り決められ、双方で保有する。
要約生成部は、独立した要約生成スレッド・タスクなどと通信する実装でも、ひとつの関数をアクション実行部が呼び出すような実装でも構わない。
【００６４】
要約突合部（９０７）は、アクション実行部（９０３）からの指示により、少なくとも２つの要約値を受け取り、これら２つの要約値が一致するかどうかを判定するようになっている。ここで２つの要約値につき、ひとつは要約生成部（９０６）、もうひとつはアクション実行部（９０３）からそれぞれ受け取るように実装するのが簡便である。要約値は鍵が異なれば受け取った情報が同じでも異なる性質があることから、要約突合部による判定をみれば、リクエスト入力部（９０１）で受けたパラメータが、同じ鍵をもつサーバを経由して処理された結果なのかどうかを実用的な程度で保証することができる。
【００６５】
表示情報生成部（９０５）は、アクション実行部による処理をした後、所定の入力を促す促進情報を作成し、これをこのリクエストを送った情報提供者用操作装置に対して送信するようになっている。たとえば、フレームワークにApache Struts2を用いた場合、JSPファイルと、コンテナがこの機能を担うことになる。
【００６６】
（２．２．３  銀行サーバの構成について）
次に銀行サーバ（８０５）について、図１０を用いて説明する。図１０は第１の実施の形態に係る銀行サーバ構成図である。銀行サーバも、販売者サーバと同じようなフレームワーク等を用いて構成することができる。そして、リクエスト入力部（１００１）、リクエスト解析部（１００２）、アクション実行部（１００３）、表示情報生成部（１００５）、要約生成部（１００６）、要約突合部（１００７）については、販売者サーバ（８０１）において実装した、リクエスト入力部（９０１）、リクエスト解析部（９０２）、アクション実行部（９０３）、表示情報生成部（９０５）、要約生成部（９０６）、要約突合部（９０７）と機能は概ね同一なものとすればよいので、その説明は上記に譲る。
【００６７】
銀行用データーベース（１００４）は、販売者用データーベース（９０４）よりも、情報価値評価基準上で評価価値が高い個人特定情報群、すなわち、個人の口座名義、口座情報などが含まれていて、アクション実行部（１００３）から、これらの記録の照合・検索ができるようになっている。
【００６８】
振込処理部（１００８）は、アクション実行部からの指示により、特定された口座に特定の金額の振込処理を行うようになっている。具体的な振込処理部は、銀行サーバが直接管理するかどうかを問わない。直接管理するものであれば、保有する口座データにトランザクションを生じさせるようにすればよい。また、外部のサーバが管理するものであれば他の銀行間ネットワークなどを介して振替処理のための情報を当該サーバに送ることになる。
【００６９】
（２．３．  第１の実施の形態の動作について）
次に本システムの動作について図４と図６とを用いて説明する。図４は、本実施の形態に係る全体システムおける動作に着目して作成した動作フロー図である。また、図６は、本実施の形態に係る全体システムのなかで取り扱われる情報に特に着目して作成した情報フロー図である。
【００７０】
・  手続開始要求（４０１）
操作者は、販売者が行うキャッシュバック・サービスに応募するには、情報提供用操作装置(１０４)に、販売者サーバのキャッシュバック・サービス応募ページのＵＲＬを入力する。ＵＲＬ入力の態様は如何なるものでもよく、キーボードを介して手打ちするのでも、ＱＲコード(登録商標)を読み込ませるのでもよい。情報提供用操作装置(１０４)がこの入力を受けると、販売者サーバに対して、手続開始のリクエストを送信する（４０１）。
【００７１】
・  商品特定情報入力促進（４０２）
手続開始のリクエストが、販売者サーバ（８０１）内のリクエスト入力部（９０１）に到達すると、リクエスト解析部とアクション実行部とは、取得しようとしている項目の入力を促すための情報提供促進情報を表示情報生成部（９０５）に生成させ、これをリクエスト発信元である情報提供者用操作装置に返信する（４０２）。情報提供促進情報は、具体的にはたとえば商品番号とその商品のシリアル番号などの商品を特定できる情報などになる。
【００７２】
・  商品特定情報入力（４０３）
情報提供者用操作装置は、この情報提供促進情報を受け取ると、その内容に従い操作者に対して入力を促す表示を行う。そして、これに呼応して操作者は、応募のための入力を行い、送信の操作をする。この操作を受けて情報提供者用操作装置は、入力された提供情報を販売者サーバに送信する（４０３）。
【００７３】
・  応募起し処理（４０４）
販売者サーバのリクエスト入力部がこれを受け取ると、リクエスト解析部（９０２）により提供された販売商品番号等をアクション実行部（９０３）が把握する。アクション実行部は、これに基づいて応募起し処理を行う（４０４）。具体的には、販売者用データーベース等を用いて、その要求がキャッシュバック・サービスに基づく正当なものかどうかを判断する。そして、このひとつの商品についてのキャッシュバック・サービス応募処理に固有の取引番号を決め、販売者用データーベース（９０４）に記録する。
ここで決められる固有の取引番号は、販売者サーバと銀行サーバとの間で、同一の情報集合を取り扱っている手掛かりとなる。すなわち、情報部分集合間を関連付けるための要（かなめ）として作用させることができる。
【００７４】
・  要約値作成（４０５）
次にアクション実行部（９０３）は、要約生成部（９０６）と協働して、予め決められた鍵情報を用い、提供された情報の要約値を求める（４０５）。すなわち、生成する要約値の原情報には、販売者に固有の企業コード、前記応募固有の取引番号などを選んで要約値を求めればよい。
【００７５】
ここで作成した要約値は、後段の突合処理（４１７）において参照すると一連の流れのなかでの完全性を保証することができるので、取引番号と関連付けて記録しておくとよい。
【００７６】
この処理を情報の視点から図６で説明すると次のようになる。すなわち販売者サーバは、取引番号（６３２）、企業コード（６３３）、鍵情報（６３４）を用いて要約値を作成する（４０５）。また、これに加えてキャッシュバック・サービスで返金する振込金額（６３１）も併せて要約値を作成するとよい。
【００７７】
要約値作成にあたり、要約作成部の実装上の要請で、原情報に桁数制限が必要な場合、これら複数の情報を組合せる際に制限桁数のみを切り出すなどして桁数を揃えた要約値作成をすることも許される。
たとえば、原情報に制限桁数が２０桁の場合であって、取引番号１６桁と企業コード４桁とから要約値を生成するのであれば、これらをそのまま並列に組み合わせた２０桁から要約値作成をすればよい。
ところが、同じく原情報に制限桁数が２０桁であって、取引番号１６桁と企業コード４桁と振込金額１２桁とから要約値を生成するのであれば、これらをそのまま並列させると２０桁を越えてしまう。そのようなときには、取引番号と振込金額との下位８桁を並列させて１６桁の文字列とし、これに企業コード４桁を並列させた合計２０桁の情報を原情報にして要約値を作成するような実装も許されるわけである。このようにすることで、これら３つの情報のセキュリティ上の完全性を保証することが可能となる。
【００７８】
なお、要約値はひとつだけ作成するのでも、適宜これらを組合せて複数を作成するのでも構わない。上述の例でいえば、取引番号・企業コードの２種から得られた要約値と、取引番号・振込金額・企業コードの３種から得られた要約値とを用意しても構わないという趣旨である。
このとき、要約値作成のための鍵情報は、同一のものを用いても、異なるものを用いてもよい。
【００７９】
なお、後段の突合処理（４１７）において参照するためには、この要約値を販売者サーバ若しくは販売者サーバからアクセス可能なデーターベースに記録（６３５）しておけばよい。
【００８０】
・  入力情報の確認促進情報送信（４０６）
次にアクション実行部（９０３）は、情報提供者に入力した情報の確認を依頼するため、表示情報生成部（９０５）を用いて確認を促す確認促進情報を作成する。そして、この確認促進情報は、情報提供者操作装置（１０４）に向けて送出される（４０６）。
【００８１】
ここで確認促進情報の例を、図７を用いて説明する。
図７は、販売者サーバが情報提供者に対して入力した情報の確認を求める際に出力する確認促進情報例であって、ＨＴＭＬによって記述したものである。
【００８２】
確認促進情報には、先に入力された情報を含めて、概ねそのまま表示できるようにすることは勿論、次に提供を求める情報が他のサイトで受け取ることになることを明示するとともに、そのサイトと連携をとるためのパラメータ情報を含むようにすればよい。
具体的には、先に入力された情報（７０３）と、「次の提供情報は他のサイトで受ける」旨を情報提供者操作装置上に表示させるメッセージ（７０４）と、連携をとるためのパラメータを含むＰＯＳＴパラメータ（７０２）とを含めるとよい。このパラメータの中には、企業コード、取引番号、振替金額とともに、先に求めた要約値を含めておくのが望ましい。要約値を含めることによって、後段で処理を行うサーバがデータの真性を把握することができるようになるからである。要約値が複数ある場合には、これらを異なるhidden属性のパラメータに含めておけばよい。
なお、本例における確認促進情報にはＰＯＳＴするサーバの具体的なアドレス指定（７０１）を含むので、情報提供者は確認をクリックひとつで行うことができるようになっている。
また、仮に複数の銀行から選択してキャッシュバック処理をできるようにしたいときには、複数のＰＯＳＴ文を並べ、情報提供者に選択させるようにすればよい。
【００８３】
・  確認・同意（４０７）
前記確認促進情報を受け取った情報提供者用操作装置は、その促進情報に従い、先に入力した情報が情報提供者の意思通りであったかどうかを確認させるとともに、次の情報取得を他のサイトが行うことについて同意することを促す。具体的には、同意・確認ボタンを表示させてこれをクリックすることができるようにすればよい。そして、情報提供者が確認・同意をすると、その旨を表す確認・同意情報が同じく確認促進情報に含まれていたｆｏｒｍ−ａｃｔｉｏｎ先である銀行サーバに送信されることになる（４０７）。
確認促進情報は前述の例に見たとおり、ＰＯＳＴパラメータとして、サイト間でデータ連携を採るための情報の他、要約値が含まれているので、確認・同意をするだけで、販売者サーバに入力された情報と銀行サーバで把握できる情報とが連携できる一方、情報価値評価基準上高いと評価される情報は販売者サーバでは把握しないで済ませることができる。
【００８４】
・  確認情報受領・突合処理（４０８）
商品特定情報や要約値を含んだ前記確認・同意情報は銀行サーバのリクエスト入力部（１００１）が受ける。銀行サーバは、リクエスト入力部が受けた確認・同意情報をリクエスト解析部（１００２）で解析し、正規なリクエストか否かを判別した後、個人特定情報群（８２３）を入力するための入力促進情報をアクション実行部（１００３）・表示情報生成部（１００５）等で生成する。
【００８５】
具体的には、要約生成部（１００６）に、受けた確認・同意情報に含まれる企業コードと取引番号とを、銀行サーバが保有する鍵情報を用いて要約値を作成させる。そして同じく受けた情報に含まれる要約値と要約生成部（１００６）で生成した要約値とが一致しているかどうか、要約突合部（１００７）で判断する。ここで用いた鍵情報は予め販売者サーバにあった鍵情報と同じものを用意してあるから、両要約値が一致していれば突合が成功したと判断できる。これはすなわち、情報提供者用操作装置から得られた情報は販売者サーバが起源であることが保証されたことになるので、途中で成りすましがあったリクエストなのかどうかを判断できることになる。
【００８６】
ここで、突合が成功したら次の入力促進（４０９）に進む。失敗したら無返信とするか、処理に異常がった旨の表示情報を生成して情報提供者用操作装置に送信すれば足りる。
【００８７】
この処理を情報の視点から図６で説明すると次のようになる。
すなわち銀行サーバは、情報提供者用操作装置を介して販売者サーバから受けた振込金額（６３１）・取引番号（６３２）・企業コード（６３３）を基礎として、銀行サーバ内に設けた鍵情報（６３６）を用いて独立に要約値を作成する（４０８−１）。そして、別途販売者サーバから受けた要約値と突合して（４０８−２）、その真正の保証を行えばよい。
なお、後段の処理と連携して完全性を維持するため、受けた要約値を銀行サーバ内で記録しておくことが望ましい（６３７）。記憶の実装はたとえばセッション変数を利用すれば足りる。
【００８８】
・  入力促進（４０９）
突合が成功したら、アクション実行部（１００３）は、表示情報生成部（１００５）を用い、銀行サーバが取得する情報部分集合たる個人特定情報群の入力を促す情報提供促進情報を生成する。具体的には、口座名義、口座情報などの入力を促す情報とであり、たとえばＨＴＭＬで記述すればよい。
生成した情報提供促進情報は、情報提供者用操作装置に返送される。
なお、入力を促す表示には、その情報を取得する主体（この場合は銀行）の商標など、管理者を表すものを表示されるように構成するのが望ましい。その表示は信頼性あるサーバで取り扱う旨を表すことになり、この表示を拠り所として操作者は安心して自己の個人情報を提供することができるようになるからである。
【００８９】
・  個人特定情報入力（４１０）
情報提供者用操作装置は、この情報提供促進情報を受け取ると、その内容に従い操作者に対して入力を促す表示を行う。そして、これに呼応して操作者は、個人を特定する情報を提供する入力を行い、送信の操作をする。この指示を受けて情報提供者用操作装置は銀行サーバに対して、入力された提供情報を送出する（４１０）。
【００９０】
・  入力情報確認（４１２）
銀行サーバのリクエスト入力部（１００１）がこれを受け取ると、アクション実行部（１００３）がリクエスト解析部（１００２）を介して、提供された個人特定情報等を把握する。アクション実行部（１００３）は、これに基づいて提供情報について情報提供者に確認を行わせるための確認促進情報を作成し、情報提供者用操作装置に返信する（４１２）。具体的には、提供された個人特定情報と、確認を知らせるための銀行サーバＵＲＬ等のサーバ特定情報とを含めた確認促進情報を作成することになる。
【００９１】
ここでも確認促進情報に振込金額・取引番号・企業コード、これらの要約値を含めておき、確認処理（４１３）においてパラメータに含めてこれを送り返せるようにしておくことができる。これにより確認情報受領・突合処理（４０８）で行ったのと同様な手法で、その真正の保証を行うことができるようになる。
【００９２】
・  確認（４１３）
前記確認促進情報を受け取った情報提供者用操作装置（１０４）は、その促進情報に従い、先に入力した情報が情報提供者の意思通りであったかどうかを、情報提供者に確認させる。具体的には、確認ボタンを表示させてこれをクリックすることができるようにすればよい。そして、情報提供者が確認をすると、その旨を表す確認情報が同じく確認促進情報に含まれていたｆｏｒｍ−ａｃｔｉｏｎ先である銀行サーバに送信されることになる（４１３）。
【００９３】
確認促進情報にはＰＯＳＴパラメータとして取引番号等の情報を入れ込み、または所謂セッションＩＤという呼ばれる通信を確立するときにサーバ・クライアント間で用いられる唯一のＩＤを含めることができる。更にこのリクエストの内容自体がこのステップであることを示すことができる。これらから、確認情報が一連の流れのなかにあることを銀行サーバが把握することができるようになる。セッションＩＤは、サーブレットと呼ばれる技術を用いるときには概ね標準的に用いられるものであるが、これを用いて通信を管理する場合には、突合処理（４０８）から作業開始報告（４１５）までの間で共通に用いることができるセッション変数が利用できる。そこで、一連の通信のなかで統一的に共通して使用するための情報は、このセッション変数に記録しておくという選択肢がある。また、取引番号を用いて銀行データーベース（１００４）を用いてこれを記録しておいてもよい。
【００９４】
・  振込作業開始（４１４）
銀行サーバは、リクエスト入力部（１００１）で上記確認情報を受けたら、キャッシュバック金額等、キャッシュバック・サービス実行に必要な情報は全て確定したことになる。
そこで、アクション実行部（１００３）が振込処理部（１００８）に振込処理を指示する。振込処理部では、予め決められた手順に従って、取得した個人特定情報を用いた処理を開始する。具体的には、提供された個人特定情報と、販売者サーバが入力情報確認（４０６）処理で確認促進情報に含めた金額・取引番号情報等とを用いて、キャッシュバックのための振込処理を行う。情報提供者から個人特定情報入力（４１０）で提供された個人特定情報には、口座名義・口座番号等の口座を特定するための情報が含まれている。
【００９５】
・  作業開始報告（４１５）
アクション実行部（１００３）は、銀行サーバで必要な振込作業を完了したら、又は振込手続きに時間がかかるのであればその手続開始処理を完了したら、次に作業開始報告を行う。具体的には、表示情報生成部（１００５）を用いて振込作業乃至振込手続開始処理を開始／完了した旨の報告情報を販売者サーバに通知する。
【００９６】
もっとも、ＨＴＭＬを用いている場合、銀行サーバから販売者サーバに直接通知をするよりも、ブラウザを介して通知をする方が、実現が簡単になる。そこで、第１の実施の形態においては、一旦銀行サーバから情報提供者用操作装置に対して確認リクエスト（４１３）に対する応答の中に、販売者サーバに対して処理を完結するための情報を送信する指示情報を含め、この情報に基づいて情報提供者用操作装置が販売者サーバに銀行サーバの作業開始報告をする技法をとっている。
【００９７】
具体的には、作業開始報告のなかに「リダイレクト」とでもいうべき自動転送情報を含めておく。リダイレクトとは、受信した情報を解析・表示するソフトウエア(ブラウザ)が所定の指示を発見したとき、その指示に含まれるＵＲＬにリクエストしてそのレスポンスを表示させる機序をいう。これには、ＨＴＭＬ上で、<meta http-equiv=”refresh”>タグを用いる技法や、ｊａｖａｓｃｒｉｐｔ（登録商標）上でｐｏｓｔ関数を用意してこれによって指定されたＵＲＬを呼び出す技法などがある。
【００９８】
前者の技法は構成が簡単なものの、含めたいパラメータがＵＲＬ列に明示されてしまい、情報提供者用操作装置上での表示体裁が良くないという欠点がある。
これに対して後者の技法は、構成が多少複雑になるものの、含めたいパラメータがＵＲＬ列に明示されず、情報提供者用操作装置上での表示体裁が良くなるという利点がある。また、ｊａｖａｓｃｒｉｐｔ（登録商標）上のプログラムを工夫すると、現在表示されている画面の一部だけを変更するなどの工夫を追加できるという利点もある。
【００９９】
リダイレクトをさせるにあたっては、そのパラメータとして、セキュリティを維持するための情報を含めておくことが望ましい。例えば取引番号と企業コード、更に取引番号と企業コードを原情報とした要約値とを含めておくと、リダイレクトを受けた販売者サーバは予め要約値作成（４０５）過程で作成した要約値と突合検査させることが可能となる。この突合検査により、販売者サーバと銀行サーバとの連携的な処理全体に他人が介在している可能性を著しく減殺させることができ、処理全体に渡る完全性の確保が可能になるわけである。
【０１００】
この処理を情報の視点から図６で説明すると次のようになる。
すなわち銀行サーバは、情報提供者による確認・同意操作（４０７）若しくは確認操作（４１３）によって情報提供者用操作装置を介して販売者サーバから受けた取引番号（６３２）・企業コード（６３３）はセッション変数等によって記録されているので、この記録されている取引番号（６４２）・企業コード（６４３）と、振込作業開始（４１４）によって得られる現実の振込額（６４１）を再利用して再び要約値を作成する（６３９）。この要約値と先に記録した要約値（６３７）とを要約突合（６３８）させる。この突合によって更なる完全性の保証をすることができる。ここで、得られた要約値（６３９）は、リダイレクト情報のパラメータに含まれ、完了処理となる突合処理（４１７）で用いられることになる。
【０１０１】
・  リダイレクト（４１６）
情報提供者用操作装置は、リダイレクト情報を含んだ作業開始報告情報を受けると、このリダイレクト指示に従い、作業開始報告情報に含まれたパラメータとともに、販売者サーバに最終完了報告リクエストを送信することになる。このリクエストには、前記作業開始報告（４１５）で含めた幾つかのパラメータも併せて送信される。このため、情報提供者用操作装置を介する間接的なものであるものの、銀行サーバから販売者サーバに作業開始報告に係る必要な情報が通知されることになる。
【０１０２】
・  突合処理（４１７）
販売者サーバは、情報提供者用操作装置によるリダイレクトで通知された作業開始報告をリクエスト入力部（９０１）で受けると、そのパラメータ等をリクエスト解析部（９０２）で分離し、アクション実行部（９０３）で突合検査のための処理を行う（４１７）。
【０１０３】
ここでの突合処理の手順は、まずパラメータに含まれていた取引情報と企業コードとを予め銀行サーバの管理者等から取得した鍵情報を用いて要約生成部（９０６）で要約値を生成する。そしてここで生成した要約値と、要約値作成（４０５）ステップで作成し記録をしていた要約値とを要約突合部（９０７）にて突合させる。これにより両要約値が一致していれば突合が成功したと判断できる。これはすなわち、銀行サーバから間接的に得られた情報は販売者サーバが起源であることが保証されたことになるので、この一連の処理において途中で成りすましによるリクエストが介入していたかどうかが判断でき、セキュリティ上の完全性保証に大いに貢献する。
【０１０４】
この点を短的に説明するならば、他のサーバの支援を受けて分散的に情報取得等を行ったとしても、販売者サーバで最初に生成した要約値を保持すると共に、その過程で授受がある情報に要約値をするための情報を入れ込んでおき、処理の最終的段階でその要約値と保持した要約値とを突合すれば、分散的に情報取得をした全行程においてセキュリティ上の完全性を保証することができるわけである。
【０１０５】
この処理を情報の視点から図６で説明すると次のようになる。
すなわち銀行サーバは、リダイレクト指示の中パラメータとして、企業コード（６４３）・取引番号（６４２）・振込金額（６４１）を含めていて、これをリダイレクト指示の中に入れ込んでいるために、リダイレクトを受けた販売者サーバもこれらのパラメータを受け付けることになる。そして、受け付けた情報の中に含められた要約値を先に記憶していた要約値（６３５）と突合（４１７）することによって、一連の処理についてセキュリティ上の完全性を保証することができるわけである。
【０１０６】
・  完了確認処理（４１８）
販売者サーバ（８０１）のアクション実行部（９０３）が上記突合処理（４１７）を完了すれば、次に完了確認処理を行う。この処理ステップでは、銀行サーバで振込処理が行われたこと若しくは振込処理を開始したことが確実である旨の作業開始報告（４１５）を通ったことが確実なので、販売者としては、これ以上同じ商品に対してキャッシュバック処理を行う必要がないばかりでなく、重複してキャッシュバック・サービスに応募があったときには、これを排除しなければならない。そこでアクション実行部（９０３）は、商品特定情報群（８１３）を記録するデーターベース若しくは商品特定情報群と連携できるデーターベースに、既に当該商品についてのキャッシュバックは終了した旨のデータを記録する。
【０１０７】
・  完了報告（４１９）
銀行サーバのアクション実行部（９０３）は、完了確認処理が終了したら、表示情報生成部（９０５）を用い、全ステップが終了した旨を表示させるための情報を生成する。そしてこれを情報提供者用操作装置に対して送信する。その結果、情報提供者用操作装置はキャッシュバック・サービスに関する応募について、一連の処理が完了したことを表示して、これを情報提供者に知らせることができるようになる。
【０１０８】
（３．  第２の実施の形態について）
次に第２の実施の形態について説明する。第２の実施の形態は、第１の実施の形態における入力情報確認（４１２）以降の処理を別の処理手順で実装したものである。
第１の実施の形態は、銀行サーバが個人特定情報を取得した後に確認までを行い、現実の振込処理が行えるようになってから完了報告を情報提供者に通知する実装例であった。
これに対し、第２の実施の形態は、銀行サーバが個人特定情報を取得するものの、その内容の確認を販売者サーバが行い、報告が完了してから銀行サーバに最終処理となる振込作業を指示する実装例となっている点で異なる。
本実施の形態の説明には図５を用いる。図５は、第２の実施の形態における情報フロー図である。
【０１０９】
（３．１．  第２の実施の形態の構成について）
第２の実施の形態は、第１の実施の形態の動作に係る変形例であるために、第１の実施の形態と構成は同じであるから、この説明は割愛する。
【０１１０】
（３．２．  第２の実施の形態の動作について）
本実施の形態に係る動作について、第１の実施の形態の説明においてした手続開始要求（４０１）から個人特定情報入力（４１０）までは同じであるから、この説明は割愛する。よって、ここでは入力情報確認処理から説明をする。
【０１１１】
・  入力情報確認（５１２）
銀行サーバのリクエスト入力部（１００１）が情報提供者から個人特定情報を受け取ると、アクション実行部（１００３）がリクエスト解析部（１００２）で抽出した販売商品番号等を把握する。これに基づきアクション実行部（１００３）は、提供情報について情報提供者に確認を行わせるための確認促進情報を作成し、情報提供者用操作装置に返信する（５１２）。ここで、作成する確認促進情報には、確認を知らせる対象となるサーバのＵＲＬを含める。販売者サーバが確認情報の送り先となる点が前記第１の実施の形態と異なる。
なお、入力が間違っていると判断される場合には、再度銀行サーバで入力情報確認（５１２）を行う必要があり、このため再入力する旨の情報を銀行サーバに送信することになる。よって、確認促進情報には、誤入力の場合の再入力リクエスト送信先として銀行サーバのＵＲＬを含めておけばよい。
【０１１２】
・  確認（５１３）
前記確認促進情報を受け取った情報提供者用操作装置は、その促進情報に従い、先に入力した情報が情報提供者の意思通りであったかどうかを確認させる。具体的には、確認ボタンを表示させてこれをクリックすることができるようにする点で第１の実施の形態と同様である。情報提供者が確認をすると、その旨を表す確認情報が同じく確認促進情報に含まれていたｆｏｒｍ−ａｃｔｉｏｎ先である販売者サーバに送信されることになる（５１３）。
【０１１３】
・  完了処理（５１８）
販売者サーバが前記確認（５１３）操作に基づく確認情報を受け取ると、完了処理を行う（５１８）。
完了処理では、再び同じ商品に対してキャッシュバック処理を行うことを禁止するような処理を行う。具体的にはアクション実行部（９０３）は、商品特定情報群（８１３）を記録するデーターベース若しくは商品特定情報群と連携できるデーターベースに、既に当該商品についてのキャッシュバックは終了した旨のデータを記録する。
【０１１４】
・  完了報告（５１９）
販売者サーバは前記完了処理（５１８）を完了すると、次に銀行サーバに振込作業をさせることになる。具体的には、要約値や取引番号等のパラメータを伴ってリダイレクト情報を生成し、これを情報提供者用操作装置に送ることになる。リダイレクトをさせる指示情報については第１の実施の形態で説明をしたとおりである。
【０１１５】
・  リダイレクト（５１６）
情報提供者用操作装置は、リダイレクト情報を含んだ完了報告情報を受けると、このリダイレクト指示に従い、完了報告情報に含まれたパラメータとともに、銀行サーバに最終完了処理を通過した旨を報告するリクエストを送信する。このリクエストには、入力情報確認処理（５１２）で含めた幾つかのパラメータも含まれる。このため、情報提供者用操作装置を介した間接的なものであるものの、販売者サーバから銀行サーバに作業開始に必要な情報が通知されることになる。
【０１１６】
ところで、この実施の形態によれば、販売者サーバでのキャッシュバック・サービス処理の完了をより確実にすることができる一方で、銀行サーバでは個人情報提供を受けた情報の確認をしていないので、何らかの手段で確実に銀行サーバに完了処理を通知しなければならない。このため、このリダイレクト（５１６）処理に代り、情報提供者用操作装置を介することなく、販売者サーバから銀行サーバに直接処理完了通知を送出するような実装することも選択肢のひとつである。このようにすることで販売者サーバと銀行サーバとの間の処理完了を巡る同期処理を確実にすることができる一方、システムを僅かに複雑化することになる。担保する情報の重要度・コスト・信頼性などの要件を総合的に検討して選択すればよい。
その他、情報セキュリティの完全性を維持するための要約値の取り扱いについては、第１の実施の形態に同様である。
【０１１７】
・  振込作業開始（５１４）
銀行サーバは、リダイレクト乃至直接通信によって販売者サーバがキャッシュバック・サービスの処理を完了させた旨の通知を受けると、最終処理として、振込作業を開始する。この段階では、提供された個人特定情報が正しい旨の確認が既にされていることになるので、どのような確認がされたのかを検査することなく振込処理を開始することができる。もっとも、セキュリティ上の完全性保証のための要約値突合はここでも行っておくのが望ましい。
その他の作業開始内容については第１の実施の形態における振込作業開始ステップ（４１４）と同じなので説明を省く。
【０１１８】
・  作業開始報告（５１５）
銀行サーバは、作業開始処理を行った後に、一連の作業が終わった旨を通知するために、完了報告表示情報を情報提供用操作装置に対して送出する。これを受けた情報提供者用操作装置は、その表示として一連のキャッシュバック・サービス応募が終わった旨の表示をすることになる。
【０１１９】
（４．  その他）
（４．１．  情報価値評価基準の例）
第１乃至第２の実施の形態において、情報価値評価基準として個人情報といえるものであるかどうかを例にとったが、個人情報の中でも視点によっては軽重を付けることができる。
たとえば、個人の特定はできるものであっても、直接人格的価値・財産的価値を把握するものかどうかという点を情報価値評価基準とすることも可能である。この場合、総合的にみて個人情報自体が重要であることは否めないが、銀行口座番号・口座残高など財産的価値を表す情報は、これが漏洩すると直接的かつ即時的に大きな被害を出す虞があることから、この基準は情報提供者の不安防止を目的として採用する意義がある。また、過去の経歴などの人格的価値を表す情報は、これが漏洩すると直接的かつ即時的に不測の被害を生む虞があるので、この基準も情報提供者の不安防止を目的として採用する意義がある。
すなわち、情報価値評価基準は、その管理する情報の内容・性質、これに基づく情報管理の程度・態様などによって、総合的に決定するべきものということができる。
【０１２０】
（４．２．  セキュリティ維持のためのＳＳＬ通信について）
本実施例ではセキュリティのためにハッシュコードに代表されるような要約値を用いているが、同じセキュリティ維持のための技術としてＳＳＬ（Secure Socket Layer）を併せて用いるのが望ましい。
本実施の形態において実装した要約値は主としてセキュリティ上の完全性を担保するためである一方、ＳＳＬは主としてセキュリティ上の機密性を担保するためのものであり、その役割を異にする。このため、両者を併用するべきである。
また、本実施の形態において実装する要約関数には、外部からその鍵の解析を困難にするべく、非可逆性の関数を用いるのが望ましい。
【０１２１】
（４．３．  実施の形態と本願発明との対応について）
ここで、各実施の形態について、本願発明との対応を説明する。
【０１２２】
情報提供者用操作装置（１０４）は、キャッシュバック・サービスに応募する最終顧客が操作する操作装置として機能する。
情報分散取得装置（１０５）は、本願発明の情報分散取得装置に相当する。
商品特定情報入力ステップ（４０３）で入力される情報は、本願発明の「第１の提供情報」に相当する。
個人特定情報入力ステップ（４１０）で入力される情報は、本願発明の「第２の提供情報」に相当する。
確認情報受領・突合処理ステップ（４０８）のうち、確認情報受領に係る処理は、本願発明の低価値類型情報受領手段の実現として機能する。
入力促進ステップ（４０９）における処理は、アクション実行部が入力促進ステップを実行することで、本願発明の高価値類型情報提供促進手段の実現として機能する。また、この入力促進処理（４０９）で付加する管理者を表すものの表示は、本願発明の該情報分散取得装置を識別させる表示として機能する。
入力情報確認ステップ（４１２）は、本願発明の高価値類型情報取得手段の実現として機能する。
銀行サーバ内の要約突合部（１００７）は、本願発明の正当性評価手段として機能する。
【０１２３】
（４．４．  他の目的のシステム構築）
なお、本実施の形態においては、特にキャッシュバック・サービスを実行するにあたり好適な実装例を説明してきたが、本願発明はこれに限らず、他の目的で情報分散取得システムを構築する際にも用いることができる。
たとえば従来、企業が複数の振込を銀行に依頼する場合には、企業が振込データをファイル状に整理するなどの準備を行った後にこれらをまとめて銀行に送付するなど、手間が必要であった。
【０１２４】
しかし、本願発明を実装したシステムを利用することで、企業と銀行のシステムを協働させることで、振込データの作成を情報提供者（最終ユーザ）の情報提供操作を契機として逐次生成していくことが可能であり、上記ファイル化などの手間を省くことができる。このように、ファイル化等の手間を省くことを主たる目的としてシステムを構築する際にも本発明は適用することができる。
【０１２５】
なお、ファイル化等の手間を省くことを主たる目的としてシステムを構築する場合には、前記突合処理を逐次行う必要はない。前記の確認情報受領・突合処理（４０８）における突合処理を省き、最終的に作業開始報告（４１５）処理段階での突合処理のみ実装すればよい。
【０１２６】
（４．５．  振込作業開始処理について）
前記実施の形態の説明では、振込作業開始（４１４）処理で現実の振込作業乃至振込手続開始処理を行うこととしている。
この振込手続開始処理には、単に銀行サーバ中にデータ蓄積をするに留める実装も含まれる。
【０１２７】
現実の振込には資金移動が伴うため、その正当性に誤りがあった場合には、出捐者となる販売者は重大な損失を蒙ることになる。このため最終的に振込を行うときには販売者がその内容を確認したいと希望することは想像に難くない。そこで、情報提供者が個人特定情報群を入力した段階では現実の振込はしないで、一定期間銀行サーバ中に振込データを蓄積しておき、販売者がその振込データを確認したところで一括して若しくは個々にその振込の承認をするように構成することもできる。
【０１２８】
もっともこの場合、情報提供者の提供した個人特定情報群は販売者の目に触れることになる。
しかし、販売者が個々の承認をするコンピュータは、銀行サーバとは異なる。また、情報表示はするもののファイルとして保存しないようにしたり、ファイルとして保存しても短期間で削除する社内規則を徹底し、これを遵法経営事項として情報提供者に周知したりすることで、情報提供者の持つ信頼を裏切ることにはならない。
【産業上の利用可能性】
【０１２９】
本発明は、たとえば個人に係る情報を所定の基準によって類型化し、その類型毎に分散して情報を取得する装置に係るものであって、広くコンピュータシステムを構築する産業であって、個人情報を取り扱うシステムに利用できることは勿論である。加えて扱う情報規模が大きく、かつ機密性を比較的が高く保たなければならない情報を扱うシステムを構築する際、特に機密性の高い情報を取得する装置のみを所謂クラウドサービスとして提供することができる。
【符号の説明】
【０１３０】
図面中の符号は先頭の数値が図面番号を表す。
１０３  最終顧客、情報提供者、操作者（場面によって表現を変えるが、自然人として同一人）
１０４  情報提供者用操作装置（最終顧客が操作する装置）
１０５  情報分散取得装置（本願発明の情報分散取得装置に相当する）
４０３  商品特定情報入力ステップ（ここで入力される情報は本願発明の第１の提供情報に相当する）
４１０  個人特定情報入力ステップ（ここで入力される情報は本願発明の第２の提供情報に相当する）
４０９  入力促進ステップ（アクション実行部が入力促進ステップを実行することで、本願発明の高価値類型情報提供促進手段として機能する）
４１２  入力情報確認ステップ（本願発明の高価値類型情報取得手段として機能する）
４０８  確認情報受領・突合処理ステップ（このうち確認情報受領ステップは本願発明の低価値類型情報受領手段として機能する）
１００７  銀行サーバ内の要約突合部（本願発明の正当性評価手段として機能する）
１１０５  情報分散処理装置
１１５１  高価値類型情報提供促進手段
１１５２  正当性評価手段
１１５３  高価値類型情報取得手段
１１５４  低価値類型情報受領手段
【図１】
2016081446.tif 000003
【図２】
2016081446.tif 000004
【図３】
2016081446.tif 000005
【図４】
2016081446.tif 000006
【図５】
2016081446.tif 000007
【図６】
2016081446.tif 000008
【図７】
2016081446.tif 000009
【図８】
2016081446.tif 000010
【図９】
2016081446.tif 000011
【図１０】
2016081446.tif 000012
【図１１】
2016081446.tif 000013