JP5325077B2 - 情報配信装置 - Google Patents

Description

本発明は、サービサ端末からの配信情報をユーザ端末に配信する情報配信装置に関する。

現在、携帯電話等の情報通信端末の高度技術化により、携帯電話等を所有するユーザの位置情報や購入履歴をサーバ装置で把握することが可能となってきている。例えば、サーバ装置は、ＧＰＳ機能に基づいて携帯電話の位置情報を把握できる。また、サーバ装置は、決済機能に基づいて携帯電話を用いて決済した場合の購入履歴を把握できる。

また、移動網のＩＰ化・広帯域化により、サーバ装置側では、上記のようなユーザの位置情報や購入履歴をリアルタイムに収集することも容易である。

したがって、今後においては、サーバ装置側で収集したユーザの位置情報・購入履歴と、サービサ（情報提供者）の配信情報とのマッチングを行い、所定の条件に合致するユーザに対して、サービサの配信情報を配信するようなサービス（情報配信基盤）が発展すると考えられる。

一方、位置情報や購入履歴のような個人情報を用いるサービスにおいては、プライバシ保護の観点から、対象となる個人を特定できないようにする仕組みが考えられている。例えば、配信情報の配信時に、少なくともｋ人以上のユーザが含まれるようにグルーピングし、配信対象となるユーザがｋ人以上存在する状態にした後に、一斉に配信処理を行うことによって、ユーザを特定できないようにする技術（ｋ匿名性）が知られている。

なお、情報配信を行った場合において、配信情報中にＵＲＬが含まれている場合に、携帯電話側で自動的にこのＵＲＬに事前アクセスする仕組みが知られている（例えば、特許文献１参照）。また、特定の個人の通信データを収集され難くするために、通信量が少ない場合にダミー通信を行う仕組みが知られている（例えば、特許文献２参照）。

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

しかしながら、配信時にｋ匿名性を担保した上で配信処理を行ったとしても、配信情報中にＵＲＬが含まれている場合、そのＵＲＬをアクセスしたユーザが少数であれば、ｋ匿名性を担保できない可能性がある。

例えば、サービサである店舗が、神戸市中央区の大学生に向けたセール情報を配信する場合を考える。この場合において、配信対象ユーザのｋ匿名性を担保するために、配信条件を緩和して神戸市全域の大学生にセール情報を配信したとする。このとき、セール情報中のＵＲＬをクリックしたユーザが一人であり、かつ、このユーザが個人ブログ内で「今日、神戸でセール情報を見てＵＲＬをクリックして商品情報を見ました。」といった記事を開示すれば、配信情報のＵＲＬをクリックしたユーザがこの個人ブログのオーナであることが特定されてしまう。特に、店舗がネット店舗であり個人情報を入力する必要がある場合には、住所や年齢等の詳細な個人情報が知られ、個人ブログを匿名で運営しているユーザのプライバシ保護が担保できなくなる。

本発明は、上記のような点に鑑みてなされたものであり、配信する情報中にＵＲＬが含まれている場合であっても、ユーザのｋ匿名性を担保できるようにすることを目的する。

上記の目的を達成するために、以下に開示する情報配信装置は、サービサ端末から配信情報を受け付ける配信情報受付部と、前記配信情報受付部において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出部と、前記アクセス先情報判定抽出部において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス部と、前記配信情報受付部において受け付けた配信情報をユーザ端末に配信する情報配信部とを備える。

本願明細書の開示によれば、情報配信装置において、配信する情報中にＵＲＬが含まれている場合であっても、ユーザのｋ匿名性を担保することが可能となる。

情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。 図１に示した情報配信装置を、ＣＰＵを用いて実現したハードウェア構成の例を示す図である。 サービサ端末２に表示される配信情報入力画面の一例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報登録処理を示すオペレーションチャートの一例を示す図である。 配信情報管理データ２６ｂの一例を示す図である。 ＵＲＬ管理データ２６ｃの一例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、情報配信処理を示すオペレーションチャートの一例を示す図である。 情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報受付処理を示すオペレーションチャートの一例を示す図である。 ＵＲＬ管理データ２６ｃの一例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。 情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。 ＵＲＬ管理データ２６ｃの一例を示す図である。 ＵＲＬを書き換えた後の配信情報の一例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。 情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報受付処理を示すオペレーションチャートの一例を示す図である。 サービサＩＤ毎かつ配信情報ＩＤ毎に、ユーザ端末３からのアクセス数の計数結果を保存したアクセス数管理データの一例を示す図である。 ＵＲＬ管理データ２６ｃの一例を示す図である。 情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。

以下においては、本発明の実施形態について図面を用いて具体的に説明する。

［１．第１の実施形態］
本実施形態にかかる情報配信装置は、携帯電話会社（キャリア）の情報配信基盤として機能する。以下、上記携帯電話会社と情報配信基盤の利用契約を締結したサービサが所有するサービサ端末から、上記携帯電話会社と携帯電話の利用契約を締結したユーザが所有する携帯電話に対して、アクセス先情報（例えば、ＵＲＬ。）を含む配信情報を配信する場合において、ユーザのｋ匿名性を担保する例について説明する。本実施形態において、サービサ端末とは、配信情報をユーザに提供する情報提供者が有する端末をいう。

本実施形態にかかる情報配信装置は、サービサ端末から配信情報を受け付ける配信情報受付部と、前記配信情報受付部において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出部と、前記アクセス先情報判定抽出部において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス部と、前記配信情報受付部において受け付けた配信情報をユーザ端末に配信する情報配信部とを備える。

このように、情報配信装置が配信情報に含まれるＵＲＬを用いてダミーアクセスを行うことにより、配信情報に含まれるＵＲＬにアクセスするユーザが少数であった場合でも、ユーザのｋ匿名性を担保することができる。これにより、ユーザが個人を特定される可能性を低減でき、プライバシ侵害を恐れることなく安心して配信情報のＵＲＬにアクセスできる。このため、結果的にユーザによる配信情報サービスの利用が拡大しやすくなる。

［１−１．システム構成］
図１は、上記情報配信装置、サービサ端末およびユーザ端末を含むシステムの構成例を示す図である。情報配信装置１、サービサ端末２およびユーザ端末３は、ネットワーク（図示せず。）を介して相互に接続可能である。サービサ端末２は、配信情報を提供する者（サービサ）が利用する端末である。例えば、サービサは、サービサ端末２に配信情報を入力すると、サービサ端末２は入力された配信情報を情報配信装置１に送信する。ユーザ端末３は、サービサからの配信情報を取得するユーザが利用する端末である。例えば、情報配信装置１から送信されてきた配信情報がユーザ端末３に表示される。

図１に示す情報配信装置１は、配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４、配信情報管理部１５および、ＵＲＬ管理部１６を備える。

サービサがサービサ端末２に配信情報を入力すると、サービサ端末２は配信情報を情報配信装置１に送信する。情報配信装置１の配信情報受付部１１は、サービサ端末２が送信してきた配信情報を受け付け、配信情報管理部に保存する。情報配信装置１のＵＲＬ判定抽出部１２は、配信情報受付部１１が受け付けた配信情報の中にＵＲＬが含まれていると判定すると、当該ＵＲＬを抽出してＵＲＬ管理部１６に保存する。情報配信装置１のダミーアクセス部１３は、ＵＲＬ判定抽出部１２においてＵＲＬ管理部１６に保存されたＵＲＬを用いて所定回数のダミーアクセスを行う。情報配信装置１の情報配信部は、所定回数のダミーアクセスが行われると、配信情報管理部に登録された配信情報を、配信条件に合致するユーザ端末に配信する。ここで、ダミーアクセスとは、ユーザ端末に代わり情報配信装置がサービサの配信情報に含まれるＵＲＬに擬似的にアクセスすることをいう。また、このアクセスのタイミングやアクセス頻度は任意である。

なお、図１の情報配信装置１において示した各機能部は、プログラムによって実現されるＣＰＵの機能を含む概念である。ここで、プログラムとは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。

［１−２．情報配信装置１のハードウェア構成］
図２は、図１に示した情報配信装置１を、ＣＰＵを用いて実現したハードウェア構成の例を示す図である。上記情報配信装置１は、ディスプレイ２１、ＣＰＵ２３、メモリ２４、キーボード／マウス２５、ハードディスク２６、光学式ドライブ２７および通信回路２８を備える。ハードディスク２６には、ＯＳ（オペレーティング・システム、図示せず。）、ブラウザプログラム（図示せず。）、情報配信プログラム２６ａ、配信情報管理データ２６ｂ、ＵＲＬ管理データ２６ｃ等が記録される。なお、メモリ２５に、オペレーティング・システム（ＯＳ）（図示せず。）、情報配信プログラム２６ａ、配信情報管理データ２６ｂ、ＵＲＬ管理データ２６ｃ等の全部または一部を記録する構成としてもよい。

情報配信プログラム２６ａは、光学式ドライブ２７を介して、例えば、ＣＤ−ＲＯＭ等の光学式ディスク２７ａに記録されたプログラムを読み出してインストールされたものである。ＣＰＵ２３は、ＯＳおよび情報配信プログラム２６ａ等に基づいた処理を実行する。

図１に示した情報配信装置１を構成する配信情報管理部１５およびＵＲＬ管理部１６は、ハードディスク２６に記録され、データベースまたはテーブルを構成する配信情報管理データ２６ｂおよびＵＲＬ管理データ２６ｃにそれぞれ該当する。図１に示した情報配信装置１を構成する配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４は、ＣＰＵ２３上において情報配信プログラム２６ａを実行することによって実現される。

［１−３．サービサ端末２およびユーザ端末３のハードウェア構成］
サービサ端末２は、一般的なコンピュータ装置であり、図２に示した情報配信装置１のハードウェア構成と基本的に同様である。ハードディスク２６には、ＯＳ、Ｗｅｂサーバプログラムおよびブラウザプログラムが少なくとも記録される。また、ユーザ端末３は、例えば、ブラウザ機能付きの一般的な携帯電話である。

［１−４．情報配信プログラムの処理内容］
図３〜図７を用いて、上記情報配信装置１における情報配信プログラム２６ａの処理内容を説明する。図３は、サービサ端末２に表示される配信情報入力画面の一例である。配信情報入力画面３０において、サービサは配信情報３１、配信エリア３２および配信対象３３に必要な情報を入力する。例えば、配信情報は「セール情報… 詳しくはこちらhttp://A.example.com/foo/bar」であり、この配信情報はＵＲＬを含んでいる。また、配信条件として、配信エリア３２「明石市大久保町」および、配信対象３３「大学生」が入力される。この場合、配信エリアにおける配信ユーザ（大学生）は、地理的理由からあまり多くないため、ｋ匿名性を担保して配信情報を配信する必要がある。

配信情報入力画面３０の送信ボタン３４が押下されると、サービサ端末２は、入力された配信情報を情報配信装置１に送信する。送信された配信情報は、情報配信装置１の配信情報受付部に一時保存される。例えば、各配信情報は、ＦＩＦＯ方式で配信情報受付部に一時保存される。

図４は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報受付処理を示すオペレーションチャートの一例を示す図である。図４の配信情報受付処理において、ＣＰＵ２３は、ユーザ端末３からの配信情報の送信により、配信情報受付部１１に一時保存されている配信情報が存在していると判断すると（Ｏｐ４１）、配信情報にユニークなＩＤを付与し、この配信情報を配信情報管理データ２６ｂに保存する（Ｏｐ４２）。図５は、配信情報管理データ２６ｂの一例である。図５のレコード５１に示すように、ＩＤ「０００１」の配信情報に対する配信状態は、配信情報を配信できない状態を示す「保留」に初期設定しておく。

ＣＰＵ２３は、配信情報管理データ２６ｂに保存された配信情報にＵＲＬが含まれているかを判断する（Ｏｐ４３）。ＵＲＬが含まれているか否かの判断は、一例として、「http://」をキーワード検索してキーワードが検索できた場合に、配信情報にＵＲＬが含まれていると判断すればよい。ＵＲＬが含まれていないと判断すれば（Ｏｐ４３、Ｎｏ）、ＣＰＵ２３は、Ｏｐ４８まで処理をスキップする。一方、ＵＲＬが含まれていると判断すれば（Ｏｐ４３、Ｙｅｓ）、ＣＰＵ２３は、そのＵＲＬを抽出して、ＵＲＬ管理データ２６ｃに保存する（Ｏｐ４４）。

例えば、図３に示した配信情報３１においては、「http://A.example.com/foo/bar」というＵＲＬが含まれているので、このＵＲＬが抽出され、ＵＲＬと配信情報のＩＤのペアが、ＵＲＬ管理データ２６ｃに保存される。図６は、ＵＲＬ管理データ２６ｃの一例である。図６のレコード６１に示すように、ＩＤ「０００１」の配信情報に対するダミーアクセス回数は「０」を初期設定しておく。

ＣＰＵ２３は、ＵＲＬ管理データ２６ｃに保存されているＵＲＬを周期的にアクセスして、ダミーアクセスを行う（Ｏｐ４５）。なお、本実施形態においてはサービサ端末２が、サービサのＵＲＬ先に対応する簡易的に記載しているが、サービサ端末２以外のサーバ装置にダミーアクセスを行うように構成してもよい。つまり、サービサが配信情報で入力するＵＲＬは、サービサ端末以外のＷｅｂサーバであってもよい。

また、ＣＰＵ２３は、このＵＲＬにアクセスする度にダミーアクセス回数をインクリメントする（Ｏｐ４６）。ＣＰＵ２３は、ダミーアクセス回数が所定回数以上になった場合に、当該ＵＲＬエントリをＵＲＬ管理データ２６ｃから削除する（Ｏｐ４７、Ｙｅｓ）。例えば、ダミーアクセス回数が所定回数である「１０回」以上になった場合に、レコード６１に示すＩＤ「０００１」のＵＲＬエントリをＵＲＬ管理データ２６ｃから削除する。

続いてＣＰＵ２３は、削除されたＵＲＬエントリと同じＩＤを持つ他のＵＲＬエントリが、ＵＲＬ管理データ２６ｃに存在しなければ、同じＩＤで保存されている配信情報管理データ２６ｂのエントリにおける保存状態を「保留」から、配信情報を配信できる状態を示す「配信可」に変更する（Ｏｐ４８）。例えば、図６のＩＤ「０００１」（レコード６１）と同じＩＤを持つ他のＵＲＬエントリが、ＵＲＬ管理データ２６ｃに存在しなければ、同じＩＤで保存されている配信情報管理データ２６ｂのエントリ（レコード５１）における配信状態を「保留」から「配信可」に変更する。

このように、ＵＲＬ管理データ２６ｃにおいて同じＩＤで保存されているエントリが存在しないことを確認してから配信情報管理データ２６ｂの配信状態を変更することにより、一つの配信情報中に複数のＵＲＬが含まれる場合であっても確実に対応することができる。

また、データのガーベージコレクションのため、ＣＰＵ２３は、「配信可」に変更したＩＤにかかるＵＲＬ管理データ２６ｃのレコードを削除する（Ｏｐ４９）。例えば、ＩＤ「０００１」にかかるレコード６１を削除する。

図７は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、情報配信処理を示すオペレーションチャートの一例を示す図である。ＣＰＵ２３は、配信情報管理データ２６ｂを監視している。具体的には、配信情報管理データ２６ｂから配信情報にかかるエントリを取得する（Ｏｐ７１）。例えば、図５の配信情報管理データ２６ｂにおいては、少なくともレコード５１および５２のエントリが取得される。

ＣＰＵ２３は、取得したエントリの配信状態が「配信可」である場合には（Ｏｐ７２、Ｙｅｓ）、そのエントリにかかる配信情報を、配信条件に合致するユーザ端末３に配信する（Ｏｐ７３）。例えば、図５の配信情報管理データ２６ｂにおいては、少なくともレコード５２のエントリの配信情報が、配信条件として設定した、配信エリア３２「神戸市中央区」および、配信対象３３「女性」のユーザ端末３に配信される。配信エリア３２は、ＧＰＳ機能を用いて取得すればよい（図示せず。）。配信対象３３は、ユーザ端末に対応するユーザ情報から取得すればよい（図示せず。）。
なお、ＣＰＵ２３は、取得したエントリの配信状態が「配信可」でない場合には（Ｏｐ７２、Ｎｏ）、Ｏｐ７１に戻って処理を繰り返す。

ＣＰＵ２３は、配信情報の配信後において、データのガーベージコレクションのため、当該エントリを削除する（Ｏｐ７４）。例えば、図５の配信情報管理データ２６ｂにおいては、少なくともレコード５２のエントリが削除される。

以上に説明したとおり、情報配信装置１は、配信情報に含まれるＵＲＬを用いてダミーアクセスを行った後配信情報を配信することにより、配信情報に含まれるＵＲＬにアクセスするユーザが少数であった場合でも、ユーザのｋ匿名性を担保することができる。

この実施形態において、配信情報受付部１１は、一例として、図４のＯｐ４１およびＯｐ４２の処理機能を含む。ＵＲＬ判定抽出部１２は、一例として、図４のＯｐ４３およびＯｐ４４の処理機能を含む。ダミーアクセス部１３は、一例として、図４のＯｐ４５〜Ｏｐ４７の処理機能を含む。情報配信部１４は、一例として、図７のＯｐ７１〜Ｏｐ７３の処理機能を含む。

［２．第２の実施形態］
本実施形態にかかる情報配信装置も、第１の実施形態と同様に、携帯電話会社（キャリア）の情報配信基盤として機能する。本実施形態においては、第１の実施形態のようにユーザ端末に情報配信を行う前にダミーアクセスを行うのではなく、配信情報を予めユーザ端末に配信しておき、ユーザ端末から配信情報中のＵＲＬに対してアクセス要求があったタイミングでダミーアクセスを開始する。なお、本実施形態では、携帯電話網や一部のＣＡＴＶ網のように、ユーザ端末からの通信が必ず通過する「アクセスゲートウェイ」の存在する環境を想定している。

本実施形態にかかる情報配信装置は、ユーザ端末が前記配信情報に含まれるＵＲＬを用いてアクセス要求を行ったか否かを検知するアクセス監視部をさらに備える。また、情報配信部は、配信情報受付部が配信情報を受け付けた場合に前記配信情報を配信する。ダミーアクセス部は、前記アクセス監視部がアクセス要求を検知した場合にダミーアクセスを行う。

このように、アクセス要求を検知した場合に、情報配信装置が配信情報に含まれるＵＲＬに対して所定回数ダミーアクセスを行うことにより、配信情報の配信後において、配信情報に含まれるＵＲＬにアクセスするユーザが少数であった場合でも、ユーザのｋ匿名性を担保することができる。具体的には、ダミーアクセスも、ユーザのアクセスも、アクセスアクセスゲートウェイを通じて行われるため、アクセス先であるサービサからはどのアクセスがユーザのものかを認識できずｋ匿名性が担保されることになる。

［２−１．システム構成］
図８は、上記情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。第１の実施形態と同様に、情報配信装置１、サービサ端末２およびユーザ端末３は、ネットワーク（図示せず。）を介して相互に接続可能である。図８に示す情報配信装置１は、配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４、ＵＲＬ管理部１６、アクセス監視部８１および、アクセスゲートウェイ８２を備える。

サービサがサービサ端末２に配信情報を入力すると、サービサ端末２は配信情報を情報配信装置１に送信する。情報配信装置１の配信情報受付部１１は、サービサ端末２から送信を受けた配信情報を情報配信部１４に転送する。転送を受けて情報配信部１４は、配信情報受付部１１において受け付けた配信情報をユーザ端末３に配信する。情報配信装置１のＵＲＬ判定抽出部１２は、配信情報受付部１１が受け付けた配信情報の中にＵＲＬが含まれていると判定すると、当該ＵＲＬを抽出してＵＲＬ管理部１６に保存する。配信情報を受けたユーザ端末３が、配信情報に含まれるＵＲＬをクリックしてＵＲＬに対するアクセス要求を行うと、アクセスゲートウェイ８２は、ユーザ端末３からアクセス要求があったことをアクセス監視部８１に通知する。アクセス監視部８１は、アクセスゲートウェイ８２から取得したユーザ端末３のアクセス要求に基づいてアクセス先を取得し、配信情報に含まれるＵＲＬに対してアクセス要求が行われているか否かを判断する。アクセス監視部８１は、ユーザ端末３のアクセス先が配信情報に含まれるＵＲＬである場合には、ダミーアクセス部１３に対して当該ＵＲＬへのダミーアクセスを行うことを依頼する。情報配信装置１のダミーアクセス部１３は、ＵＲＬ判定抽出部１２においてＵＲＬ管理部１６に保存されたＵＲＬに基づいて、所定回数のダミーアクセスを行う。なお、ダミーアクセスは、アクセスゲートウェイ８２を通じて行われる。

なお、図８の情報配信装置１において示した各機能部も、第１の実施形態と同様に、プログラムによって実現されるＣＰＵの機能を含む概念である。

［２−２．情報配信装置１、サービサ端末２およびユーザ端末３のハードウェア構成］
図８に示した情報配信装置１を、ＣＰＵを用いて実現したハードウェア構成の例を示す図は、第１の実施形態における図２と基本的に同様である。しかし、本実施形態においては、第１の実施形態に示した配信情報管理データ２６ｂは必須ではない。

図８に示した情報配信装置１を構成する配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４および、アクセス監視部８１は、ＣＰＵ２３上において情報配信プログラム２６ａを実行することによって実現される。

アクセスゲートウェイ８２は、ユーザ端末３から受け付けたアクセス要求に従い、ネットワーク（例えば、インターネット。）上のサーバに接続する機能を有するものである。なお、アクセスゲートウェイ８２は、別のハードウェアで構成してもよいし、情報配信装置１１においてソフトウェアによって機能させてもよい。

また、第１の実施形態と同様に、サービサ端末２は一般的なコンピュータ装置であり、ユーザ端末３はブラウザ機能付きの一般的な携帯電話である。

［２−３．情報配信プログラムの処理内容］
図３、図９〜図１１を用いて、上記情報配信装置１における情報配信プログラム２６ａの処理内容を説明する。第１の実施形態と同様に、図３の配信情報入力画面３０において、サービサは配信情報３１、配信エリア３２および配信対象３３に必要な情報を入力する。配信情報入力画面３０の送信ボタン３４が押下されると、サービサ端末２は、入力された配信情報を情報配信装置１に送信する。送信された配信情報は、情報配信装置１の配信情報受付部に一時保存される。

図９は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報受付処理を示すオペレーションチャートの一例を示す図である。図９の配信情報受付処理において、ＣＰＵ２３は、配信情報受付部１１に一時保存されている配信情報が存在していると判断すると（Ｏｐ９１）、配信情報にユニークなＩＤを付与し、この配信情報にＵＲＬが含まれているかを判断する（Ｏｐ９２）。

ＵＲＬが含まれていないと判断すれば（Ｏｐ９２、Ｎｏ）、ＣＰＵ２３は、Ｏｐ９４まで処理をスキップする。一方、ＵＲＬが含まれていると判断すれば（Ｏｐ９２、Ｙｅｓ）、ＣＰＵ２３は、そのＵＲＬを抽出して、ＵＲＬ管理データ２６ｃに保存する（Ｏｐ９３）。図１０は、ＵＲＬ管理データ２６ｃの一例である。図１０のレコード１０１に示すように、ＩＤ「０００１」の配信情報に対する動作フラグは「保留」を初期設定しておく。

続いてＣＰＵ２３は、上記の配信情報を、配信条件に合致するユーザ端末３に配信する（Ｏｐ９４）。

図１１は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。本実施形態においては、配信情報を受けたユーザ端末３から、配信情報に含まれるＵＲＬに対するアクセス要求があると、必ずアクセスゲートウェイ８２に対して通信が行われる。

ＣＰＵ２３は、ユーザ端末３からのアクセス要求があったことを、アクセスゲートウェイ８２を介して検知すると、このアクセス要求に基づいてアクセス先を取得する（Ｏｐ１１１）。ＣＰＵ２３は、取得したアクセス先が、ＵＲＬ管理データ２６ｃに保存されている配信情報に含まれるＵＲＬであるか否かを判断する（Ｏｐ１１２）。

具体的には、一例として、アクセスゲートウェイ８２からは、「アドレス：A.example.com、ポート:80（＝http）」といったTCP/IP情報が取得できる。ＣＰＵ２３は、このTCP/IP情報から http://A.example.com/ にアクセスしているパケットを識別し、パケットの中身であるHTTPプロトコル「GET http://A.example.com/foo/bar」を検査することにより、当該ＵＲＬであるか否かを判断する。

取得したアクセス先がＵＲＬ管理データ２６ｃに保存されている配信情報に含まれるＵＲＬに合致すれば、ＣＰＵ２３は、さらに、このＵＲＬの動作フラグが「保留」であるか否かを判断する。

ＣＰＵ２３は、動作フラグが「保留」であれば（Ｏｐ１１３、Ｙｅｓ）、ダミーアクセスが保留されているので、動作フラグを「開始」に更新した後、ダミーアクセスを行う（Ｏｐ１１４）。一方、ＣＰＵ２３は、動作フラグが「保留」でなく「開始」であれば、ダミーアクセスが開始されているので、Ｏｐ１１１に戻って処理を繰り返す（Ｏｐ１１３、Ｎｏ）。

第１の実施形態と同様に、ＣＰＵ２３は、ＵＲＬ管理データ２６ｃに保存されているＵＲＬを周期的にアクセスして、ダミーアクセスを行う（Ｏｐ１１５）。なお、本実施形態においてはサービサ端末２が、サービサのＵＲＬ先に対応する簡易的に記載しているが、サービサ端末２以外のサーバ装置にダミーアクセスを行うように構成してもよい。

また、ＣＰＵ２３は、このＵＲＬにアクセスする度にダミーアクセス回数をインクリメントする（Ｏｐ１１６）。ＣＰＵ２３は、ダミーアクセス回数が所定回数以上になった場合に（Ｏｐ１１７、Ｙｅｓ）、データのガーベージコレクションのため、当該ＵＲＬエントリをＵＲＬ管理データ２６ｃから削除する（Ｏｐ１１８）。例えば、ダミーアクセス回数が所定回数である「１０回」以上になった場合に、レコード６１に示すＩＤ「０００１」のＵＲＬエントリをＵＲＬ管理データ２６ｃから削除する。

なお、上記Ｏｐ１１１において、ユーザ端末３からのアクセス要求があった場合に、アクセスゲートウェイ８２は、このアクセス自体を一時停止する必要はない。また、ダミーアクセスの状況に応じてユーザ端末３からのアクセス要求を一時停止させてもよい。例えば、ダミーアクセス回数が所定回数以上になるまでアクセス要求を一時停止してもよい。これにより、ユーザ端末３によるアクセスかダミーアクセスであるかを秘匿することができ、匿名性を担保しやすい。

以上に説明したとおり、配信情報の配信後において、情報配信装置１が、アクセス要求を検知した場合に、配信情報に含まれるＵＲＬに対して所定回数ダミーアクセスを行うことにより、配信情報に含まれるＵＲＬにアクセスするユーザが少数であった場合でも、ユーザのｋ匿名性を担保することができる。具体的には、ダミーアクセスも、ユーザのアクセスも、アクセスゲートウェイを通じて行われるため、アクセス先であるサービサからはどのアクセスがユーザのものかを認識できないため、ユーザのｋ匿名性を担保することができる。

この実施形態において、配信情報受付部１１は、一例として、図９のＯｐ９１の処理機能を含む。ＵＲＬ判定抽出部１２は、一例として、図９のＯｐ９２およびＯｐ９３の処理機能を含む。ダミーアクセス部１３は、一例として、図１１のＯｐ１１５〜Ｏｐ１１７の処理機能を含む。情報配信部１４は、一例として、図９のＯｐ９４の処理機能を含む。

［３．第３の実施形態］
本実施形態にかかる情報配信装置も、第１、２の実施形態と同様に、携帯電話会社（キャリア）の情報配信基盤として機能する。本実施形態においては、第２の実施形態と同様に、ユーザ端末においてが配信情報に含まれるＵＲＬを用いてアクセス要求があった場合にダミーアクセスを開始する。しかし、本実施形態においては、第２の実施形態と異なり、ユーザ端末からの通信を一元的に監視できるアクセスゲートウェイがない環境（例えば、一般的な公衆インターネット環境。）を想定している。

本実施形態にかかる情報配信装置において、ＵＲＬ判定抽出部は、抽出したＵＲＬを、プロキシを経由してアクセスさせるための異なるＵＲＬに変換するとともに、配信情報のＵＲＬを異なるＵＲＬに書き換える。アクセス監視部は、ユーザ端末がプロキシにアクセスしたことに基づいて、アクセス要求を行ったか否かを検知する。

このように、抽出したＵＲＬを、プロキシを経由してアクセスさせるための異なるＵＲＬに変換することにより、アクセスゲートウェイがない環境においても、ユーザ端末のアクセスを監視することができる。つまり、アクセスゲートウェイがない環境においてもユーザ端末からのアクセス要求を検知でき、情報配信装置が配信情報に含まれるＵＲＬに対して所定回数ダミーアクセスを行うことにより、配信情報の配信後において、配信情報に含まれるＵＲＬにアクセスするユーザが少数であった場合でも、ユーザのｋ匿名性を担保することができる。

［３−１．システム構成］
図１２は、上記情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。第１、２の実施形態と同様に、情報配信装置１、サービサ端末２およびユーザ端末３は、ネットワーク（図示せず。）を介して相互に接続可能である。図１２に示す情報配信装置１は、配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４、ＵＲＬ管理部１６、アクセス監視部８１および、プロキシ１２１を備える。

サービサがサービサ端末２に配信情報を入力すると、サービサ端末２は配信情報を情報配信装置１に送信する。情報配信装置１のＵＲＬ判定抽出部１２は、配信情報受付部１１が受け付けた配信情報の中にＵＲＬが含まれていると判定すると、このＵＲＬを抽出し、抽出したＵＲＬをプロキシを経由してアクセスさせるための異なるＵＲＬに変換する。ＵＲＬ判定抽出部１２は、変換前後のＵＲＬをそれぞれ対応づけてＵＲＬ管理部１６に保存するとともに、配信情報のＵＲＬを変換後の異なるＵＲＬに書き換える。情報配信部１４は、ＵＲＬ判定抽出部１２において異なるＵＲＬに書き換えられた配信情報をユーザ端末３に配信する。

配信情報を受けたユーザ端末３が、配信情報に含まれる上記異なるＵＲＬをクリックすると、プロキシ１２１に対してアクセス要求を行うことになる。プロキシ１２１は、ユーザ端末３からアクセス要求があったことをアクセス監視部８１に通知する。アクセス監視部８１は、プロキシ１２１から取得したユーザ端末３のアクセス要求に基づいて、本来のアクセス先を取得し、配信情報に含まれるＵＲＬに対してアクセス要求が行われているか否かを判断する。アクセス監視部８１は、ユーザ端末３のアクセス先が配信情報に含まれるＵＲＬである場合には、ダミーアクセス部１３に対して当該ＵＲＬへのダミーアクセスを行うことを依頼する。情報配信装置１のダミーアクセス部１３は、ＵＲＬ判定抽出部１２においてＵＲＬ管理部１６に保存されたＵＲＬに基づいて、所定回数のダミーアクセスを行う。なお、ダミーアクセスは、プロキシ１２１を通じて行われる。

なお、図８の情報配信装置１において示した各機能部も、第１の実施形態と同様に、プログラムによって実現されるＣＰＵの機能を含む概念である。

［３−２．情報配信装置１、サービサ端末２およびユーザ端末３のハードウェア構成］
図１２に示した情報配信装置１を、ＣＰＵを用いて実現したハードウェア構成の例を示す図は、第１の実施形態における図２と基本的に同様である。しかし、本実施形態においては、第１の実施形態に示した配信情報管理データ２６ｂは必須ではない。

図１２に示した情報配信装置１を構成する配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４および、アクセス監視部８１は、ＣＰＵ２３上において情報配信プログラム２６ａを実行することによって実現される。

プロキシ１２１は、ユーザ端末３から受け付けたアクセス要求に従い、ネットワーク（例えば、インターネット。）上のサーバに接続する機能を有するものである。なお、アクセスゲートウェイ８２は、別のハードウェアで構成してもよいし、情報配信装置１１においてソフトウェアによって機能させてもよい。

また、第１の実施形態と同様に、サービサ端末２は一般的なコンピュータ装置であり、ユーザ端末３はブラウザ機能付きの一般的な携帯電話である。

［３−３．情報配信プログラムの処理内容］
図３、図１３〜１６を用いて、上記情報配信装置１における情報配信プログラム２６ａの処理内容を説明する。第１の実施形態と同様に、図３の配信情報入力画面３０において、サービサは配信情報３１、配信エリア３２および配信対象３３に必要な情報を入力する。配信情報入力画面３０の送信ボタン３４が押下されると、サービサ端末２は、入力された配信情報を情報配信装置１に送信する。送信された配信情報は、情報配信装置１の配信情報受付部に一時保存される。

図１３は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報受付処理を示すオペレーションチャートの一例を示す図である。図９の配信情報受付処理において、ＣＰＵ２３は、配信情報受付部１１に一時保存されている配信情報が存在していると判断すると（Ｏｐ１３１）、配信情報にユニークなＩＤを付与し、この配信情報にＵＲＬが含まれているかを判断する（Ｏｐ１３２）。

ＵＲＬが含まれていないと判断すれば（Ｏｐ１３２、Ｎｏ）、ＣＰＵ２３は、Ｏｐ１３６まで処理をスキップする。一方、ＵＲＬが含まれていると判断すれば（Ｏｐ１３２、Ｙｅｓ）、ＣＰＵ２３は、そのＵＲＬをプロキシ１２１を経由するように変換する（Ｏｐ１３３）。そして、ＣＰＵ２３は、変換前後のＵＲＬをＵＲＬ管理データ２６ｃに保存する（Ｏｐ１３４）。

図１４は、ＵＲＬ管理データ２６ｃの一例である。図１４のレコード１４１に示すように、ＩＤ「０００１」の配信情報について、変換後のＵＲＬ「http://proxy.example.net/A.example.com/foo/bar/」および、変換前のＵＲＬ「http://A.example.com/foo/bar/」を保存するとともに、動作フラグを「保留」に初期設定する。図１４に示すように、ＣＰＵ２３は、サービサ端末２から受け付けた配信情報中に含まれるＵＲＬを、プロキシ１２１にアクセスした後にこのＵＲＬにアクセスすることができる異なるＵＲＬに変換する。

ＣＰＵ２３は、配信情報に含まれるＵＲＬを変換後のＵＲＬに書き換える（Ｏｐ１３５）。図１５は、ＵＲＬを書き換えた後の配信情報の一例である。図１５に示す配信情報においては、図３の配信情報３１に含まれるＵＲＬ「http://A.example.com/foo/bar/」は、変換後のＵＲＬ「http://proxy.example.net/A.example.com/foo/bar/」に書き換えられている。

続いてＣＰＵ２３は、上記の配信情報を、配信条件に合致するユーザ端末３に配信する（Ｏｐ１３６）。

図１６は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。本実施形態においては、配信情報を受けたユーザ端末３から、配信情報に含まれるＵＲＬに対するアクセス要求があると、必ずプロキシ１２１に対して通信が行われる。

ＣＰＵ２３は、ユーザ端末３からのアクセス要求があったことを、プロキシ１２１を介して検知すると、このアクセス要求に基づいてアクセス先を取得する（Ｏｐ１６１）。ＣＰＵ２３は、取得したアクセス先が、ＵＲＬ管理データ２６ｃに保存されている配信情報に含まれるＵＲＬであるか否かを判断する（Ｏｐ１６２）。

具体的には、一例として、プロキシ１２１からは、「アドレス：proxy.example.net、ポート:80（＝http）」といったTCP/IP情報が取得できる。ＣＰＵ２３は、このTCP/IP情報から http://proxy.example.net/ にアクセスしているパケットを識別し、パケットの中身であるHTTPプロトコル「GET http://proxy.example.net/A.example.com/foo/bar」を検査することにより、当該ＵＲＬであるか否かを判断する。

取得したアクセス先がＵＲＬ管理データ２６ｃに保存されている変換後ＵＲＬに合致すれば、ＣＰＵ２３は、さらに、このＵＲＬの動作フラグが「保留」であるか否かを判断する。

ＣＰＵ２３は、動作フラグが「保留」であれば（Ｏｐ１６３、Ｙｅｓ）、ダミーアクセスが保留されているので、動作フラグを「開始」に更新した後、ダミーアクセスを行う（Ｏｐ１６４）。一方、ＣＰＵ２３は、動作フラグが「保留」でなく「開始」であれば、ダミーアクセスが開始されているので、Ｏｐ１６１に戻って処理を繰り返す（Ｏｐ１６３、Ｎｏ）。

第１の実施形態と同様に、ＣＰＵ２３は、ＵＲＬ管理データ２６ｃに保存されているＵＲＬを周期的にアクセスして、ダミーアクセスを行う（Ｏｐ１６５）。なお、本実施形態においてはサービサ端末２が、サービサのＵＲＬ先に対応する簡易的に記載しているが、サービサ端末２以外のサーバ装置にダミーアクセスを行うように構成してもよい。

また、ＣＰＵ２３は、このＵＲＬにアクセスする度にダミーアクセス回数をインクリメントする（Ｏｐ１６６）。ＣＰＵ２３は、ダミーアクセス回数が所定回数以上になった場合に（Ｏｐ１６７、Ｙｅｓ）、データのガーベージコレクションのため、当該ＵＲＬエントリをＵＲＬ管理データ２６ｃから削除する（Ｏｐ１６８）。例えば、ダミーアクセス回数が所定回数である「１０回」以上になった場合に、レコード１４１に示すＩＤ「０００１」のＵＲＬエントリをＵＲＬ管理データ２６ｃから削除する。

なお、上記Ｏｐ１１１において、ユーザ端末３からのアクセス要求があった場合に、プロキシ１２１は、このアクセス自体を一時停止する必要はない。また、プロキシ１２１は、ダミーアクセスの状況に応じてユーザ端末３からのアクセス要求を一時停止させてもよい。例えば、ダミーアクセス回数が所定回数以上になるまでアクセス要求を一時停止してもよい。これにより、ユーザ端末３によるアクセスかダミーアクセスであるかを秘匿することができ、匿名性を担保しやすい。

以上に説明したとおり、情報配信装置１が、抽出したＵＲＬを、プロキシを経由してアクセスさせるための異なるＵＲＬに変換することにより、アクセスゲートウェイがない環境においても、ユーザ端末のアクセスを監視することができる。

よって、情報配信装置１が、アクセス要求を検知した場合に、配信情報に含まれるＵＲＬに対して所定回数ダミーアクセスを行うことにより、配信情報に含まれるＵＲＬにアクセスするユーザが少数であった場合でも、ユーザのｋ匿名性を担保することができる。具体的には、ダミーアクセスも、ユーザのアクセスも、プロキシを通じて行われるため、アクセス先であるサービサからはどのアクセスがユーザのものかを認識できないため、ユーザのｋ匿名性を担保することができる。

この実施形態において、配信情報受付部１１は、一例として、図１３のＯｐ１３１の処理機能を含む。ＵＲＬ判定抽出部１２は、一例として、図１３のＯｐ１３２の処理機能を含む。ダミーアクセス部１３は、一例として、図１６のＯｐ１６５〜Ｏｐ１６７の処理機能を含む。情報配信部１４は、一例として、図１３のＯｐ１３６の処理機能を含む。

［４．第４の実施形態］
本実施形態にかかる情報配信装置も、第１の実施形態と同様に、携帯電話会社（キャリア）の情報配信基盤として機能する。本実施形態においては、第２、３の実施形態をベースにして、サービサが配信した配信情報に含まれるＵＲＬへのユーザのアクセス数実績を元にして、ダミーアクセス数を可変とする。なぜなら、ダミーアクセスは、ユーザのアクセス数が少ないときに、ユーザの匿名性を担保するために仕方なく行うアクセスであり、サービサにとっては本来不要なアクセスだからである。そこで、ユーザのアクセス数がある程度望めるサービサである場合には、ダミーアクセスを可変とする枠組みを提供する。

本実施形態にかかる情報配信装置は、少なくともサービサＩＤ毎に、配信情報に含まれるＵＲＬに対するユーザ端末のアクセス数を計数して保存するアクセス数計数部をさらに備える。ダミーアクセス部は、アクセス数計数部に保存されているアクセス数に基づいて、ダミーアクセスの回数を低減させる。

このように、情報配信装置が配信情報に含まれるＵＲＬに対して行うダミーアクセスの回数を、サービサのアクセス頻度によって可変とすることにより、ｋ匿名性が担保できる可能性の高いサービサに対してはダミーアクセスを減らして処理負荷を抑えることができる。

［４−１．システム構成］
図１７は、上記情報配信装置、サービサ端末およびユーザ端末から構成されるシステムの構成例を示す図である。第１の実施形態と同様に、情報配信装置１、サービサ端末２およびユーザ端末３は、ネットワーク（図示せず。）を介して相互に接続可能である。図１７に示す情報配信装置１は、配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４、ＵＲＬ管理部１６、アクセス監視部８１、アクセス計数部１７１および、アクセスゲートウェイ８２を備える。

サービサがサービサ端末２に配信情報を入力すると、サービサ端末２は配信情報を情報配信装置１に送信する。情報配信装置１の配信情報受付部１１は、サービサ端末２から送信を受けた配信情報を情報配信部１４に転送する。転送を受けて情報配信部１４は、配信情報受付部１１において受け付けた配信情報をユーザ端末３に配信する。情報配信装置１のＵＲＬ判定抽出部１２は、配信情報受付部１１が受け付けた配信情報の中にＵＲＬが含まれていると判定すると、当該ＵＲＬを抽出してＵＲＬ管理部１６に保存する。配信情報を受けたユーザ端末３が、配信情報に含まれるＵＲＬをクリックしてＵＲＬに対するアクセス要求を行うと、アクセスゲートウェイ８２は、ユーザ端末３からアクセス要求があったことをアクセス監視部８１に通知する。アクセス監視部８１は、アクセスゲートウェイ８２から取得したユーザ端末３のアクセス要求に基づいてアクセス先を取得し、配信情報に含まれるＵＲＬに対してアクセス要求が行われているか否かを判断する。アクセス監視部８１は、ユーザ端末３のアクセス先が配信情報に含まれるＵＲＬである場合には、アクセス数計数部１７１にその通知を行うとともに、ダミーアクセス部１３に対して当該ＵＲＬへのダミーアクセスを行うことを依頼する。ここで、本実施形態のアクセス数計数部１７１は、サービサ毎にアクセス数をカウントする。ダミーアクセス部１３は、ＵＲＬ判定抽出部１２においてＵＲＬ管理部１６に保存されたＵＲＬに基づいて、所定回数のダミーアクセスを行う。なお、ダミーアクセスは、アクセスゲートウェイ８２を通じて行われる。

なお、図１７の情報配信装置１において示した各機能部も、第１の実施形態と同様に、プログラムによって実現されるＣＰＵの機能を含む概念である。

［４−２．情報配信装置１、サービサ端末２およびユーザ端末３のハードウェア構成］
図１７に示した情報配信装置１を、ＣＰＵを用いて実現したハードウェア構成の例を示す図は、第１の実施形態における図２と基本的に同様である。しかし、本実施形態においては、第１の実施形態に示した配信情報管理データ２６ｂは必須ではない。なお、図１７に示した情報配信装置１を構成するアクセス数管理部１７２は、図２のメモリ２４またはハードディスク２６において、アクセス数管理データとして記録される。

図１７に示した情報配信装置１を構成する配信情報受付部１１、ＵＲＬ判定抽出部１２、ダミーアクセス部１３、情報配信部１４、アクセス監視部８１および、アクセス計数部１７１は、ＣＰＵ２３上において情報配信プログラム２６ａを実行することによって実現される。アクセスゲートウェイ８２は、ユーザ端末３から受け付けたアクセス要求に従い、ネットワーク（例えば、インターネット。）上のサーバに接続する機能を有するものである。なお、アクセスゲートウェイ８２は、別のハードウェアで構成してもよいし、情報配信装置１１においてソフトウェアによって機能させてもよい。

また、第１の実施形態と同様に、サービサ端末２は一般的なコンピュータ装置であり、ユーザ端末３はブラウザ機能付きの一般的な携帯電話である。

［４−３．情報配信プログラムの処理内容］
図３、図１８〜図２１を用いて、上記情報配信装置１における情報配信プログラム２６ａの処理内容を説明する。第１の実施形態と同様に、図３の配信情報入力画面３０において、サービサは配信情報３１、配信エリア３２および配信対象３３に必要な情報を入力する。配信情報入力画面３０の送信ボタン３４が押下されると、サービサ端末２は、入力された配信情報を情報配信装置１に送信する。送信された配信情報は、情報配信装置１の配信情報受付部に一時保存される。

図１８は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、配信情報受付処理を示すオペレーションチャートの一例を示す図である。Ｏｐ１８１、Ｏｐ１８２は、第２の実施形態の図９において示した処理（Ｏｐ９１、Ｏｐ９２）と同様である。

図１９は、サービサＩＤ毎かつ配信情報ＩＤ毎に、ユーザ端末３からのアクセス数の計数結果を保存したアクセス数管理データの一例である。

ＣＰＵ２３は、配信情報を送信してきたサービサ端末２にかかるサービサＩＤ毎に、ダミーアクセスを行う所定回数を決定する（Ｏｐ１８３）。例えば、図１９においてサービサＩＤ「ＡＡＡＡ」の最低アクセス数はレコード１９１の「４」回であるので、デフォルトのダミーアクセス数である「１０」から最低アクセス数「４」を減算し、所定回数を「６」回と決定する。これは、サービサＩＤ「ＡＡＡＡ」の配信情報に含まれるＵＲＬへのアクセスが最低「４」回は見込まれることに基づいて、ダミーアクセス数を削減するものである。これにより、無駄なダミーアクセスを事前に防止して、処理負荷を抑えることができる。

なお、上記においては、最低アクセス数を用いて所定回数を決定したが、サービサＩＤ毎の平均アクセス数等のように他の統計値に基づく数値を用いてもよい。また、決定した所定回数が匿名性を担保するに足る回数になるとは限らないため、ダミーアクセスの開始から一定時間内に、ユーザのアクセス回数が想定した回数に満たない場合には、追加でダミーアクセスをするようにすることが望ましい。

Ｏｐ１８４、Ｏｐ１８５は、第２の実施形態の図９において示した処理（Ｏｐ９３、Ｏｐ９４）と基本的に同様である。図２０は、ＵＲＬ管理データ２６ｃの一例である。本実施形態においては、ＵＲＬ管理データ２６ｃに、サービサＩＤおよび所定回数を保存する点が、第２の実施形態と異なる。

図２１は、情報配信装置１のＣＰＵ２３で実行される情報配信プログラム２６ａに基づく、ダミーアクセス処理を示すオペレーションチャートの一例を示す図である。本実施形態のダミーアクセス処理は、第２の実施形態の図１１において示した処理と基本的に同様である。

ＣＰＵ２３は、Ｏｐ２１３において、ユーザ端末３からのアクセス要求があった場合に、サービサＩＤ毎かつ配信情報ＩＤ毎にアクセス数を計数する点が異なる。この計数処理によって、図１９において示したサービサＩＤ毎のアクセス数の履歴が作成されることになる。

また、本実施形態においては、図２１のＯｐ２１８において、使用する「所定回数」は、図２０に示した配信情報毎に保存した「所定回数」である。

以上に説明したとおり、情報配信装置が配信情報に含まれるＵＲＬに対して行うダミーアクセスの回数を、サービサのアクセス頻度によって可変とすることにより、ｋ匿名性が担保できる可能性の高いサービサに対してはダミーアクセスを減らして処理負荷を抑えることができる。

この実施形態において、配信情報受付部１１は、一例として、図１８のＯｐ１８１の処理機能を含む。ＵＲＬ判定抽出部１２は、一例として、図１８のＯｐ１８２の処理機能を含む。ダミーアクセス部１３は、一例として、図２１のＯｐ２１６〜Ｏｐ２１８の処理機能を含む。情報配信部１４は、一例として、図１８のＯｐ１８４の処理機能を含む。

［５．その他の実施形態］
［５−１．実施形態の組み合わせ］
上記第１〜第４の実施形態において説明した構成の一部または全部を、２以上組み合わせた構成としてもよい。特に、第１の実施形態と第２の実施形態を組み合わせる場合、または、第１の実施形態と第３の実施形態を組み合わせる場合においては、第１の実施形態で説明した配信情報の配信前のダミーアクセス（第１ダミーアクセス）の回数と、第２の実施形態または第３の実施形態で説明したアクセス要求時のダミーアクセス（第２ダミーアクセス）の回数との割合を変動できるように構成してもよい。

具体的には、第１ダミーアクセスを所定回数の３０％行い、第２ダミーアクセスを所定回数の７０％を行うようにしてもよい。これにより、匿名性をより効果的に高めることができる。

［５−２．ダミーアクセスの方法］
ダミーアクセスの対象となるＵＲＬに、下位階層のＵＲＬや、別サイトのＵＲＬが含まれている場合には、ランダムにそのＵＲＬをたどるようにアクセスするように構成してもよい。これにより、人間が手動でアクセスしたかのように振る舞うことができ、匿名性を高めることができる。

また、第２の実施形態または第３の実施形態においてが、ユーザ端末３からのアクセス要求があった場合にダミーアクセスを行うように構成したが、ユーザ端末３にダミーアクセスを行うか否かを確認してからダミーアクセスを開始するように構成してもよい。これにより、ユーザ端末３のユーザ自身が匿名性を要する場合にのみダミーアクセスを行わせることができる。

さらに、乱数に基づく時間間隔でダミーアクセスを行うようにしてもよい。これにより、手動でアクセスしたかのように振る舞うことができる。さらに、定期的（毎日、毎時）にダミーアクセスを行うようにしてもよい。これにより、日付や時刻単位での匿名化を行うことができる。

［５−３．各機能ブロックの実現方法］
上記実施形態においては、図１、８、１２または１７に示す各機能ブロックを、ソフトウェアを実行するＣＰＵの処理によって実現している。しかし、その一部もしくは全てを、ロジック回路等のハードウェアによって実現してもよい。なお、プログラムの一部の処理をさらに、オペレーティング・システム（ＯＳ）にさせるようにしてもよい。

１１ 配信情報受付部
１２ ＵＲＬ判定抽出部
１３ ダミーアクセス部
１４ 情報配信部
１５ 配信情報管理部
１６ ＵＲＬ管理部
８１ アクセス監視部
８２ アクセスゲートウェイ
１２１ プロキシ
１７１ アクセス数計数部
１７２ アクセス数管理部

Claims (8)

1. サービサ端末から配信情報を受け付ける配信情報受付部と、
   前記配信情報受付部において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出部と、
   前記アクセス先情報判定抽出部において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス部と、
   前記配信情報受付部において受け付けた配信情報をユーザ端末に配信する情報配信部とを備え、
   前記情報配信部は、前記ダミーアクセス部において配信情報に含まれるアクセス先情報を用いてダミーアクセスが行われた後に前記配信情報を配信する、情報配信装置。
2. サービサ端末から配信情報を受け付ける配信情報受付部と、
   前記配信情報受付部において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出部と、
   前記アクセス先情報判定抽出部において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス部と、
   前記配信情報受付部において受け付けた配信情報をユーザ端末に配信する情報配信部と、
   配信情報に含まれるアクセス先情報に対するユーザ端末のアクセス数を計数して保存するアクセス数計数部とを備え、
   前記ダミーアクセス部は、前記アクセス数計数部に保存されているアクセス数に基づいて、前記ダミーアクセスの回数を低減させる、情報配信装置。
3. 前記ユーザ端末が前記配信情報に含まれるアクセス先情報を用いてアクセス要求を行ったか否かを検知するアクセス監視部をさらに備え、
   前記情報配信部は、前記配信情報受付部が配信情報を受け付けた場合に前記配信情報を配信し、
   前記ダミーアクセス部は、前記アクセス監視部がアクセス要求を検知した場合に前記ダミーアクセスを行う、請求項１又は２に記載の情報配信装置。
4. 前記アクセス先情報判定抽出部は、抽出した前記アクセス先情報を、プロキシを経由してアクセスさせるための異なるアクセス先情報に変換するとともに、前記配信情報のアクセス先情報を前記異なるアクセス先情報に書き換えるものであり、
   前記アクセス監視部は、ユーザ端末がプロキシにアクセスしたことに基づいて、前記アクセス要求を行ったか否かを検知する、請求項３に記載の情報配信装置。
5. 情報配信装置を、コンピュータを用いて実現するための情報配信プログラムであって、
   サービサ端末から配信情報を受け付ける配信情報受付処理と、
   前記配信情報受付処理において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出処理と、
   前記アクセス先情報判定抽出処理において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス処理と、
   前記配信情報受付処理において受け付けた配信情報をユーザ端末に配信する情報配信処理とをコンピュータに実行させ、
   前記配信情報を配信する前記情報配信処理は、前記ダミーアクセス処理において配信情報に含まれるアクセス先情報を用いてダミーアクセスが行われた後にコンピュータに実行させる、情報配信プログラム。
6. 情報配信装置を、コンピュータを用いて実現するための情報配信プログラムであって、
   サービサ端末から配信情報を受け付ける配信情報受付処理と、
   前記配信情報受付処理において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出処理と、
   前記アクセス先情報判定抽出処理において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス処理と、
   前記配信情報受付処理において受け付けた配信情報をユーザ端末に配信する情報配信処理と、
   配信情報に含まれるアクセス先情報に対するユーザ端末のアクセス数を計数して保存するアクセス数計数処理とをコンピュータに実行させ、
   前記ダミーアクセス処理は、前記アクセス数計数処理で保存されたアクセス数に基づいて、前記ダミーアクセスの回数を低減させる処理を含む、情報配信プログラム。
7. サービサ端末から配信情報を受け付ける配信情報受付工程と、
   前記配信情報受付工程において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出工程と、
   前記アクセス先情報判定抽出工程において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス工程と、
   前記配信情報受付工程において受け付けた配信情報をユーザ端末に配信する情報配信工程とを含み、
   前記配信情報を配信する前記情報配信工程は、前記ダミーアクセス工程において配信情報に含まれるアクセス先情報を用いてダミーアクセスが行われた後に実行される、情報配信方法。
8. サービサ端末から配信情報を受け付ける配信情報受付工程と、
   前記配信情報受付工程において受け付けた配信情報にアクセス先情報が含まれていると判定した場合に、当該アクセス先情報を抽出するアクセス先情報判定抽出工程と、
   前記アクセス先情報判定抽出工程において抽出されたアクセス先情報を用いてダミーアクセスを行うダミーアクセス工程と、
   前記配信情報受付工程において受け付けた配信情報をユーザ端末に配信する情報配信工程と、
   配信情報に含まれるアクセス先情報に対するユーザ端末のアクセス数を計数して保存するアクセス数計数工程とを含み、
   前記ダミーアクセス工程は、前記アクセス数計数工程で保存されたアクセス数に基づいて、前記ダミーアクセスの回数を低減させる工程を含む、情報配信方法。

Images