(57)【要約】【課題】  秘密情報の漏洩を追跡可能な情報保護システム等を提供することができるようにする。【解決手段】  データ提供者がデータ受領者に対して当該データ提供者の所有するデータを提供する際に、当該データおよび前記データ受領者の組み合わせを、当該データ受領者による影響が及ばない状態で自動的に収集して蓄積する蓄積手段（１１２，１１６）と、蓄積されたデータ群により、前記データ受領者が前記データを漏洩したかどうかを判別する判別手段（１１４，１１５）とを備えるようにする。【選択図】  図１
2005235013.tif 000002
【特許請求の範囲】
【請求項１】
データ提供者がデータ受領者に対して当該データ提供者の所有するデータを提供する際に、当該データおよび前記データ受領者の組み合わせを、当該データ受領者による影響が及ばない状態で自動的に収集して蓄積する蓄積工程と、
前記蓄積工程で蓄積されたデータ群により、前記データ受領者が前記データを漏洩したかどうかを判別する判別工程と
を備えることを特徴とする情報保護方法。
【請求項２】
前記データ提供者の所有するデータが当該データ提供者の個人を特定する可能性のある氏名、メールアドレス、電話番号及び住所のうち、少なくともいずれか１つを含む個人情報であることを特徴とする請求項１に記載の情報保護方法。
【請求項３】
前記データ提供者の所有するデータが、コンピュータと接続されたネットワークを介して提供され、前記蓄積工程は、記録対象となる前記データ提供者のデータ群があらかじめ登録されたデータベースの情報をもとに、前記データおよび前記データ受領者の組み合わせを、別のデータベースにより自動的に収集して蓄積することを特徴とする請求項１または２に記載の情報保護方法。
【請求項４】
前記ネットワークがインターネットプロトコルを利用したネットワークであり、前記データ提供者の所有するデータが、前記インターネットプロトコルの上層に位置するＨＴＴＰプロトコルを利用して代理サーバを介して前記データ受領者に送信されることを特徴とする請求項３に記載の情報保護方法。
【請求項５】
前記ＨＴＴＰプロトコルを利用して送信されるデータが前記別のデータベースに自動的に収集されて蓄積される対象となるデータであることを、前記ＨＴＴＰプロトコルのリクエスト・ラインのメソッドの内容、もしくはメッセージ・ボディの内容を解析して判別することを特徴とする請求項４に記載の情報保護方法。
【請求項６】
前記判別を行う機能がＷｅｂブラウザとサイトを中継する代理サーバを介して実現されていることを特徴とする請求項５に記載の情報保護方法。
【請求項７】
データ提供者がデータ受領者に対して当該データ提供者の所有するデータを提供する際に、当該データおよび前記データ受領者の組み合わせを、当該データ受領者による影響が及ばない状態で自動的に収集して蓄積する蓄積手段と、
前記蓄積手段で蓄積されたデータ群により、前記データ受領者が前記データを漏洩したかどうかを判別する判別手段と
を備えることを特徴とする情報保護システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、個人情報の保護を強化するための情報保護方法および情報保護システムに関するものである。
【背景技術】
【０００２】
インターネットが普及するに従い、例えばアンケートや事業者が提供するサービス、展示会の申込など、Ｗｅｂブラウザ等を使用して個人情報を事業者に提供する機会が増加している。一方、個人情報を提供していないはずの事業者、あるいは特定できない送信元から、ｅ−ｍａｉｌアドレスなどの個人情報を使ったいわゆるＳＰＡＭと言われる迷惑勧誘などの悪質な行為が多く発生している。
【０００３】
この悪質な行為の原因は、主に個人情報の漏洩によるものであると思われるが、漏洩が意図的な第３者への不正提供である場合は、その提供について本人に知らされないため漏洩元を突き止めることが難しいという問題があった。
【０００４】
【特許文献１】特開２００２−１８３３６７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このような問題に対し、特許文献１で述べているような名寄せの手法を使うと、不正提供元を特定、あるいはその提供企業の絞り込みにつながる可能性のある情報を得ることができる。この概念を、図７を参照してに説明する。
【０００６】
図７において、７０１は企業Ａのサイト（ＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ−ａ．ｘｘｘとする）、７０２は企業Ｂのサイト（ＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ−ｂ．ｘｘｘとする）、７０３は企業Ｃのサイト（ＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ−ｃ．ｘｘｘとする）であり、それぞれ個人情報を求めるＷｅｂページを所有しており、インターネット７０５に接続されている。
【０００７】
一方、７０７は個人１、７０８は個人２、７０９は個人３であり、それぞれインターネット７０５に直接、またはプロバイダや企業などの専用線７０６経由で間接的に各企業のサイトと接続され、Ｗｅｂブラウザを使って個人情報を提供しているとする。個人１（７０７）は企業Ａおよび企業Ｂに、個人２（７０８）は企業Ｂおよび企業Ｃに、個人３（７０９）は企業Ａおよび企業Ｃに情報を提供していたとする。そして、後日、各個人が情報を提供してないはずのＳＰＡＭ業者から個人１（７０７）と個人２（７０８）にＳＰＡＭメールが届いたとする。各個人がこの被害状況をお互いに、あるいはプロバイダなどに申告し名寄せを行うことで、個人１（７０７）と個人２（７０８）にはＳＰＡＭメールが届き、個人３（７０９）には届いていないという状況が把握できれば、個人情報を不正提供した企業は、企業Ｂである可能性が高いことが推定できる。図７においては、企業や個人は３ずつというきわめて限定した数としているが、実際は多くの企業や個人であっても上記の概念が適用できる。
【０００８】
しかしながら、このような名寄せを個人の自己申告によって行うには手間がかかり、また、各々の個人がどのサイトにどのような個人情報を提供したかを個人レベルで正確に把握し蓄積しておき、何らかの事件が発生してからそれらを提供するということは難しいという課題があった。
【０００９】
本発明は上述の問題点にかんがみてなされたものであり、データ提供者がデータ受領者に対して当該データ提供者の所有するデータを提供する際に、秘密情報の漏洩を追跡可能な情報保護方法および情報保護システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明は上記課題を解決するために、データ提供者がデータ受領者に対して当該データ提供者の所有するデータを提供する際に、当該データおよび前記データ受領者の組み合わせを、当該データ受領者による影響が及ばない状態で自動的に収集して蓄積する蓄積工程と、前記蓄積工程で蓄積されたデータ群により、前記データ受領者が前記データを漏洩したかどうかを判別する判別工程とを備えることを特徴とする情報保護方法等を提供する。
【発明の効果】
【００１１】
本発明によれば、データ提供者がデータ受領者に対して当該データ提供者の所有するデータを提供する際に、秘密情報の漏洩を追跡することができる。
【００１２】
また、個人情報を保護する目的をもって名寄せを行う際の情報を、自動的に蓄積し提供することができる。これにより、たとえば、あるプロバイダの顧客（あるいはある企業における従業員）が様々な企業サイトに対し、Ｗｅｂブラウザからフォームを使ってｅ−ｍａｉｌアドレス等の個人情報を提供する際に、当該プロバイダ（あるいは企業）または信頼できる第３者のＰｒｏｘｙ経由でその個人情報と送信先を自動的にＤＢに記録、蓄積し、将来個人情報漏洩の事件があった際に、その不正提供を行った企業を検知する情報とすることができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施形態を図面を参照しながら説明する。
【００１４】
図１は、本発明の実施形態における情報保護システムを含むシステムの概略構成図である。図１に示したシステムは、図７の従来例に示したシステムに対して、個人情報保護システム１１０を追加したものである。その他の構成は図７に示したものと同様であり、図１の１０１〜１０９の構成は、図７の７０１〜７０９の構成である。
【００１５】
個人情報保護システム１１０は、たとえば各個人が属する企業の管理部門や、プロバイダの運営者など各個人が信頼できる第３者などにより、企業Ａ、Ｂ、Ｃによる閲覧や操作などの影響が及ばない状態で適切に管理されている。
【００１６】
図１においても、企業サイトは図７と同様、１０１は企業Ａのサイト（ＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ−ａ．ｘｘｘとする）、１０２は企業Ｂのサイト（ＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ−ｂ．ｘｘｘとする）、１０３は企業Ｃのサイト（ＵＲＬはｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ−ｃ．ｘｘｘとする）であり、それぞれ個人情報を求めるＷｅｂページを所有しており、インターネット１０５に接続されている。
【００１７】
また、各個人も図７と同様で、１０７は個人１、１０８は個人２、１０９は個人３であり、それぞれインターネット１０５に直接、またはプロバイダや企業などの専用線１０６経由で間接的に各企業のサイトと接続され、Ｗｅｂブラウザを使って個人情報を提供しているとする。但し、各ブラウザは、アクセスに代理サーバ（Ｐｒｏｘｙ）を指定する設定がされており、その指定されたサーバとして個人情報保護システム１１０がＰｒｏｘｙ部１１３を指定している。
【００１８】
個人情報保護システム１１０において、１１１は各個人が提供する際にその記録を必要とする個人情報データベースである。このデータベースに格納されている各レコードの例を図２の表における各行に示す。ここでは、個人ＩＤ０００１で識別される個人１（１０７）はそのｅｍａｉｌアドレスである”ｐｅｒｓｏｎ１＠ｐｒｏｖｉｄｅｒ．ｘｘ”、氏名である“氏名１”、電話番号である“１１１−ｘｘｘ−１１１１”、または必要に応じてその他の個人情報を、記録が必要な個人情報として登録している。個人ＩＤ０００２で識別される個人２（１０８）、個人ＩＤ０００３で識別される個人３（１０９）においても同様な登録がなされている。
【００１９】
個人情報保護システム１１０において、１１２は個人情報とその提供先を関連付けて記録する個人情報／提供先データベースである。１１３はＰｒｏｘｙ部であり、Ｗｅｂブラウザの一般的な代理サーバ機能を提供する。１１４は、送信データ判定部であり、個人がサイトに対して送信するＨＴＴＰリクエストがフォームデータ送信であるかどうかの判定を行う。１１５はフォームデータが個人情報かどうかを解析するフォームデータ部である。１１６は、個人情報／提供先ＤＢ１１２に個人情報と送信先の組み合わせをレコードとして記録する送信個人情報・提供先登録部である。
【００２０】
上述した各構成手段を有する個人情報保護システム１１０は、１台のコンピュータ内において各機能が構成されていても、ネットワークに接続された２台以上のコンピュータがそれぞれ１つ以上の機能を分担する形で構成されていても良い。
【００２１】
以下、本実施形態における情報保護システムの処理を図３のフローチャートに基づいて説明する。
まず、図１における各個人のＷｅｂブラウザ（１０７，１０８，または１０９）から、ＷｅｂサイトへのＨＴＴＰリクエストが発生すると、Ｐｒｏｘｙ部１１３がそのリクエストメッセージを中継のため一旦受信する（ステップＳ３０１）。ここで、この各Ｗｅｂブラウザからの送信は、一般にはＷｅｂサイトからＦＯＲＭタグを含んだＨＴＭＬデータを受信した後その回答として行うケースが多いが、ｅ−ｍａｉｌ等別の手段で入手したローカルのＨＴＭＬデータなどから直接リクエストメッセージをＷｅｂサイトに送信するケースもある。
【００２２】
続いて、送信データ判定部１１４において、Ｐｒｏｘｙ部１１３が中継のため受信したＨＴＴＰリクエストメッセージが、個人がサイトに対して送信するフォームデータであるかどうかの判定を行う（ステップＳ３０２）。
【００２３】
ここで、フォームデータであるかどうかの１つ目の判断基準は、そのＨＴＴＰリクエストがＰＯＳＴメソッドであるかどうかである。図４は、ＨＴＴＰリクエストメッセージのフォーマットのうち、これに関係する部分を抜き出した構造図である。メッセージヘッダの最上位に位置するリクエスト・ラインがＰＯＳＴと記述されていれば、そのメッセージはＰＯＳＴメソッドでありフォームデータを送信していることがわかる（データ自体が空である可能性はある）。
【００２４】
また、フォームデータであるかどうかの２つ目の判断基準は、そのＨＴＴＰリクエストがＧＥＴメソッドであり、かつクエリの送信であるかどうかである。図５は、ＨＴＴＰリクエストメッセージフォーマットのうち、これに関連する部分を抜き出した構造図である。クエリの送信であるかどうかは、リクエスト・ラインで示しているＷｅｂサイトのＵＲＬにクエスチョンマーク“？”が記述され、その後にデータが存在しているかどうか（一般には変数名と送信データがそれぞれ必要に応じてＵＲＬエンコードといわれるアスキー文字へのエンコード処理され、イコール“＝”で結合されて、複数の変数とデータが存在する場合は、それらがアンパサンド記号“＆”で結合されたものをデータとする）で判別できる。
【００２５】
続いて、ステップＳ３０２での判定に基づいて、フォームデータの送信かどうかの判定を行う（ステップＳ３０３）。この判定の結果、フォームデータの送信でないと判定された場合は、Ｐｒｏｘｙ部１１３において、中継のため受信したクライアントからのＨＴＴＰリクエストをそのまま、あるいは一般の代理サーバの機能通りにリクエスト先のＷｅｂサイトに送信する（ステップＳ３０７）。一方、ステップＳ３０３での判定の結果、フォームデータの送信であると判定された場合には、続いて、フォームデータ解析部１１５において、フォームデータが記録を必要とする個人情報かどうかを解析する（ステップＳ３０４）。
【００２６】
このステップＳ３０４の具体的な処理として、ＨＴＴＰリクエストメッセージがＰＯＳＴメソッドである場合には、その送信データ（図４の例では、そのメッセージ・ボディ欄に示されるように、各変数名と送信データがそれぞれ必要に応じてＵＲＬエンコード処理をなされ、イコール“＝”記号で結合され、複数の変数とデータが存在する場合はそれらがアンパサンド“＆”記号で結合されたデータのうち“＝“部直後から”＆“の直前までのデータ、あるいはそれがＵＲＬエンコードされたデータである場合はそれをデコードしたもの）が、図２で示した個人情報データベース内のデータのいずれかに登録されているかどうかで解析する。ここで、ＵＲＬエンコードのデコードはその都度行っても良いが、個人情報データベース（図２）にデータ項目として各個人データ項目をＵＲＬエンコードしたものを記録しておいて、それとそのまま比較しても良い。
【００２７】
また、ステップＳ３０４の具体的な処理として、ＨＴＴＰリクエストがＧＥＴメソッドである場合には、図５の例におけるリクエスト・ライン欄における”？“記号の右部分に、送信データが図２で示した個人情報データベース内のデータのいずれかに登録されているかどうかで解析する。
【００２８】
続いて、フォームデータ送信が記録を必要とする個人データを含むかを判定する（ステップＳ３０５）。この判定の結果、送信するフォームデータが記録を必要とする個人データを含まないと判定された場合は、Ｐｒｏｘｙ部１１３において、中継のため受信したクライアントからのＨＴＴＰリクエストをそのまま、あるいは一般の代理サーバの機能通りリクエスト先のＷｅｂサイトに送信する（ステップＳ３０７）。
【００２９】
一方、ステップＳ３０５の判定の結果、送信するフォームデータが記録を必要とする個人データを含むと判定された場合には、図１における送信個人情報・提供先登録部１１６において、その個人データを個人情報／提供先ＤＢ１１２に登録する（ステップＳ３０６）。例えば、図４のデータを送信したケースでは、個人１のメールアドレスと氏名電話番号がリクエスト／ヘッダフィールドのＨｏｓｔフィールドで示されるｗｗｗ．ｃｏｍｐａｎｙ−ａ．ｘｘｘ（企業ＡのＷｅｂサイト）に提供されたため、図６における点線囲み部６０１で示されるようなデータがレコードとして登録される。また、図５のデータを送信したケースでは、個人１のメールアドレスのみがｗｗｗ．ｃｏｍｐａｎｙ−ｂ．ｘｘｘ（企業ＢのＷｅｂサイト）に提供されたため、図６における点線囲み部６０２で示されるようなデータがレコードとして登録される。
【００３０】
ステップＳ３０６により、レコードが登録された後は、Ｐｒｏｘｙ部１１３において、中継のため受信したクライアントからのＨＴＴＰリクエストをそのまま、あるいは一般の代理サーバの機能通りにリクエスト先のＷｅｂサイトに送信する（ステップＳ３０７）。
以上をもって、図３のフローチャート処理は終了する。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態における情報保護システムを含むシステムの概略構成図である。
【図２】個人情報データベースに記録されるデータの例を示す図である。
【図３】本発明の実施形態における個人情報保護システムの処理のフローチャートである。
【図４】ＰＯＳＴメソッドにおけるＨＴＴＰリクエストメッセージの例を示した図である。
【図５】ＧＥＴメソッドにおけるＨＴＴＰリクエストメッセージの例を示した図である。
【図６】個人情報／提供先データベースに記録されるデータの例を示した図である。
【図７】従来例を示し、各企業サイト、各個人及びネットワークを含むシステムの概略構成図である。
【符号の説明】
【００３２】
１０１〜１０３，７０１〜７０３  企業Ｗｅｂサイト
１０４，７０４  ＳＰＡＭサイト
１０５，７０５  インターネット
１０６，７０６  インターネットまたは専用線
１０７〜１０９，７０７〜７０９  各個人（Ｗｅｂブラウザ）
１１０  個人情報保護システム
１１１  個人情報データベース
１１２  個人情報／提供先データベース
１１３  Ｐｒｏｘｙ部
１１４  送信データ判定部
１１５  フォームデータ解析部
１１６  送信個人情報・提供先登録部
６０１，６０２  個人情報／提供先データベースに記録されるレコード
【図１】
2005235013.tif 000003
【図２】
2005235013.tif 000004
【図３】
2005235013.tif 000005
【図４】
2005235013.tif 000006
【図５】
2005235013.tif 000007
【図６】
2005235013.tif 000008
【図７】
2005235013.tif 000009