(57)【特許請求の範囲】
【請求項１】
サービス提供装置がユーザに対しサービスの提供を行うユーザの条件を、前記提供するサービス毎に登録する登録部と、
ユーザに係る情報が、前記登録部が前記提供するサービス毎に登録した前記条件に合致するか否かを判定する条件判定部と、
前記条件判定部が合致の判定をした場合、前記サービス提供装置に対し、前記合致に係る条件を通知すると共に、組み合わせ条件も併せて通知する通知部と、
前記サービス提供装置から前記通知に係る条件に対応するサービスの提供を受けて前記サービスを前記合致に係るユーザに提供するサービス提供部と、
前記条件毎に、前記通知部が前記条件を前記サービス提供装置に通知する際に前記条件に合致するユーザ数の平均値と、前記条件の通知回数の時間平均値とを求め、前記組み合わせ条件を追加した場合の前記合致に係る条件に合致するユーザ数の平均値が所定値以上となり且つ前記組み合わせ条件を追加した場合の前記合致に係る条件毎の通知回数の時間平均値が所定の範囲に収まるように前記組み合わせ条件を求める組み合わせ取得部と、を有することを特徴とする情報処理装置。
【請求項２】
前記組み合わせ取得部は、前記組み合わせ条件を求める際、一の条件の通知回数の時間平均値が、前記条件毎の前記通知回数の時間平均値の最大値に対する所定の割合に満たない場合、他の条件の通知回数の時間平均値が前記所定の割合に満たない不足分を超え且つ最小の値を有する前記他の条件を前記サービス提供装置に通知する際に併せて通知する組み合わせ条件として前記一の条件に加えることを特徴とする、請求項１に記載の情報処理装置。
【請求項３】
前記組み合わせ取得部は、一の条件を、他の条件を通知する際に前記組み合わせ条件として通知する確率を、前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として追加した場合の前記一の条件の通知回数の時間平均値が前記条件毎の前記通知回数の時間平均値の最大値を超えないように決定し、
前記通知部は、前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として通知する際には、前記一の条件を前記組み合わせ条件として通知する確率が前記決定に係る確率となるように、前記一の条件を前記組み合わせ条件として通知するか否かを決定することを特徴とする、請求項１に記載の情報処理装置。
【請求項４】
コンピュータによって実行されるサービス仲介方法であって、
ユーザに係る情報が、提供するサービス毎に登録された夫々の条件に合致するか否かを判定し、
合致と判定された場合、サービス提供装置に対し、前記合致に係る条件を通知すると共に、組み合わせ条件も併せて通知し、
前記サービス提供装置から前記通知に係る条件に対応するサービスの提供を受けて前記サービスを前記合致に係るユーザに提供し、
前記条件毎に、前記条件を前記サービス提供装置に通知する際に前記条件に合致するユーザの人数の平均値と、前記条件の通知回数の時間平均値とを求め、前記組み合わせ条件を追加した場合の前記合致に係る条件に合致するユーザの人数の平均値が所定値以上となり且つ前記組み合わせ条件を追加した場合の前記合致に係る条件毎の通知回数の時間平均値が所定の範囲に収まるように前記組み合わせ条件を求めることを特徴とするサービス仲介方法。
【請求項５】
ユーザに係る情報が、提供するサービス毎に登録された夫々の条件に合致するか否かを判定し、
合致と判定された場合、サービス提供装置に対し、前記合致に係る条件を通知すると共に、組み合わせ条件も併せて通知し、
前記サービス提供装置から前記通知に係る条件に対応するサービスの提供を受けて前記サービスを前記合致に係るユーザに提供し、
前記条件毎に、前記条件を前記サービス提供装置に通知する際に前記条件に合致するユーザの人数の平均値と、前記条件の通知回数の時間平均値とを求め、前記組み合わせ条件を追加した場合の前記合致に係る条件に合致するユーザの人数の平均値が所定値以上となり且つ前記組み合わせ条件を追加した場合の前記合致に係る条件毎の前記通知回数の時間平均値が所定の範囲に収まるように前記組み合わせ条件を求める処理をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、サービス仲介方法及びプログラムに関する。
【背景技術】
【０００２】
信頼できる第三者機関から生成された、ただ一種類のセキュアエージェントが、耐タンパデバイス上に構築されたエージェント実行環境（セキュアエージェント鍵を格納する）で、ユーザやプロバイダの処理を代行する技術が知られている。このセキュアエージェントは、セキュアエージェント間の通信により、非セキュアなエージェントに処理内容や個人情報を知られることなく処理を実行できる。
【０００３】
又、プロバイダから属性開示要求を受け、要求された個人情報の属性を開示する個人情報保護運用装置が知られている。個人情報保護運用装置は、要求された個人情報の属性を開示するとき、個々のユーザＩＤに対してどの程度秘匿性が失われるかについて秘匿性を計算し、秘匿性を確保できる属性の情報のみをプロバイダに開示する。
【０００４】
又、ユビキタスネットワーキング環境において、サービスを利用提供する際のプライバシ保護に関し、プライバシ情報の公開の可否を判断できるプライバシ情報管理サーバが知られている。プライバシ情報管理サーバは、ユーザのプライバシ情報を格納するプライバシ情報データベースと、プライバシ情報データベースの登録ユーザ総数に対するプライバシ情報の種類から特定されるユーザの割合を計算する統計処理手段とを有する。
【０００５】
又、パブリッシュ／サブスクライブ通信を行う通信ノードとメッセージの配信を実行するブローカとの間に代理のパブリッシュ／サブスクライブ通信ノードを配置する技術が知られている。
【０００６】
又、パブリッシャーから送信されたメッセージがトピックという送信先に登録され、トピックに登録されたメッセージはトピックに対して配信を申し込んでいたサブスクライバに配信されるパブリッシュ／サブスクライブメッセージングモデルが知られている。
【０００７】
又、メッセージの出版はトピックと称される論理チャネルに対して行われ、購読側は購読しているトピック向けに出版された全メッセージを受信し、同じトピックを購読している各購読者は全員同じメッセージを受け取るトピックベースシステムが知られている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００１−３３１４４６号公報
【特許文献２】特開２００７−２１９６３５号公報
【特許文献３】特開２００５−２３４８６６号公報
【特許文献４】特開２００９−１１０１６５号公報
【特許文献５】特開２００６−３５０１８３号公報
【特許文献６】特開２００７−２１９６３６号公報
【非特許文献】
【０００９】
【非特許文献１】「Pub/Subメッセージングモデル」（ＵＲＬ：http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d3U0721/EU070356.HTM）（２０１０年１１月１９日現在）
【非特許文献２】「出版-購読型モデル」（ＵＲＬ：http://ja.wikipedia.org/wiki/%E5%87%BA%E7%89%88-%E8%B3%BC%E8%AA%AD%E5%9E%8B%E3%83%A2%E3%83%87%E3%83%AB）（２０１０年１１月１９日現在）
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ユーザに係る情報がサービスを提供する条件に合致した場合にサービス提供装置に対し合致に係る条件を通知し、サービス提供装置から通知に係る条件に対応するサービスの提供を受けてユーザに提供するサービス仲介方法においてユーザに係る情報の匿名性を確保することが課題である。
【課題を解決するための手段】
【００１１】
サービス提供装置がユーザに対しサービスの提供を行うユーザの条件を、提供するサービス毎に登録する登録部と、ユーザに係る情報が、登録部が提供するサービス毎に登録した条件に合致するか否かを判定する条件判定部とを設ける。更に、条件判定部が合致の判定をした場合、サービス提供装置に対し、合致に係る条件を通知すると共に、組み合わせ条件も併せて通知する通知部と、記サービス提供装置から通知に係る条件に対応するサービスの提供を受けてサービスを合致に係るユーザに提供するサービス提供部とを設ける。更に、条件毎に、通知部が条件をサービス提供装置に通知する際に条件に合致するユーザ数の平均値と、条件の通知回数の時間平均値とを求める組み合わせ取得部を有する。組み合わせ取得部は更に、組み合わせ条件を追加した場合の合致に係る条件に合致するユーザ数の平均値が所定値以上となり且つ組み合わせ条件を追加した場合の合致に係る条件毎の通知回数の時間平均値が所定の範囲に収まるように組み合わせ条件を求める。
【発明の効果】
【００１２】
サービス仲介方法によれば、ユーザに係る情報が条件に合致した場合にサービス提供装置に対し合致に係る条件を通知し、通知に係る条件に対応するサービスの提供を受けてユーザに提供するサービス仲介方法においてユーザに係る情報の匿名性を確保することができる。
【図面の簡単な説明】
【００１３】
【図１Ａ】参考例を説明するための図（その１）である。
【図１Ｂ】参考例を説明するための図（その２）である。
【図２】参考例を説明するための図（その３）である。
【図３】参考例を説明するための図（その４）である。
【図４Ａ】参考例を説明するための図（その５）である。
【図４Ｂ】本発明の実施例１を説明するための図（その１）である。
【図５Ａ】本発明の実施例１を説明するための図（その２）である。
【図５Ｂ】本発明の実施例１を説明するための図（その３）である。
【図６】本発明の実施例１を説明するための図（その４）である。
【図７】参考例による情報配信システムのハードウェアブロック図である。
【図８】参考例による情報配信システムの機能ブロック図である。
【図９】本発明の実施例１による情報配信システムのハードウェアブロック図である。
【図１０】本発明の実施例１による情報配信システムの機能ブロック図である。
【図１１】本発明の実施例１による条件通知組み合わせテーブルの一例である。
【図１２】本発明の実施例１による条件通知組み合わせテーブル作成用の平均該当者数及び平均通知回数比較テーブルの一例である。
【図１３】本発明の実施例１による平均該当者数及び平均通知回数比較テーブルを用いて条件通知組み合わせテーブルを決定するための処理の流れの一例を示すフローチャートである（その１）。
【図１４】本発明の実施例１による平均該当者数及び平均通知回数比較テーブルを用いて条件通知組み合わせテーブルを決定するための処理の流れの一例を示すフローチャートである（その２）。
【図１５】本発明の実施例２による条件通知組み合わせテーブルの一例である。
【図１６】本発明の実施例２による条件通知組み合わせテーブル作成用の平均該当者数及び平均通知回数比較テーブルの一例である。
【図１７】本発明の実施例２による平均該当者数及び平均通知回数比較テーブルを用いて条件通知組み合わせテーブルを決定するための処理の流れの一例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下に本発明を実施するための形態につき、図とともに説明する。
【実施例１】
【００１５】
本発明の実施例１について説明する。
【００１６】
説明の便宜上、本発明の実施例１による情報配信システムの前提となる技術について最初に説明する。
【００１７】
ネットワーク及びネットワークを利用したオンラインサービスの発展に伴い、ユーザに係る情報に応じてサービス提供者が提供するサービスの内容をカスタマイズするサービスが増え、その規模も拡大する傾向にある。そのため、ユーザに係る情報が数多くのサービスに利用されることとなり、その結果生じ得る、ユーザに係る情報の漏洩リスク或いはプライバシ侵害のリスク等が想定される。
【００１８】
ユーザに係る情報の漏洩リスク或いはプライバシ侵害のリスクを回避或いは軽減する目的で、いわゆる匿名化処理を行うことが考えられる。匿名化処理とは、例えば、サービスに必要な情報やサービスの質を向上する情報と、サービスの提供を受けるユーザ個人を特定する材料となり得る情報とを区別して利用するようにし、サービスの提供を受けるユーザ個人を特定する材料となり得る情報の利用を必要最小限にする。即ち匿名化処理とは、ユーザ個人を特定する材料となり得る情報であるユーザに係る情報を利用する際、ユーザに係る情報を加工して利用するようにし、ユーザがどのような属性情報を有しているかが第三者に知られる可能性を極力低減する。
【００１９】
このような匿名化処理を効率的に行うため、ユーザに係る情報を管理する仲介業者を利用し、仲介業者による匿名化処理を経た情報のみをサービス提供者に渡し、サービス提供者は渡された情報に対応するサービスをユーザに提供する方法が考えられる。このような方法では、ユーザは仲介業者に自己の属性情報（ユーザに係る情報）を提供すればよいため、サービス提供者に対するユーザに係る情報の漏洩のリスク、プライバシ侵害のリスク等を回避或いは低減することができる。
【００２０】
ここで、サービス提供者が予め仲介業者にサービスを提供する条件を登録しておき、ユーザが条件に合致した際に仲介業者がサービス提供者に通知し、通知を受けてサービス提供者がサービスを提供するという方法につき、以下に説明する。ユーザにサービスを提供するシステムの例として、例えば、ユーザに対するメッセージ（コンテンツ）の配信を行うシステムがある。この用はシステムにおいて、ユーザ（購読者）はトピックと称されるメッセージ配信の条件を予め申し込んでおき、自己が申し込んだトピック向けに出版されたメッセージを受信する。又、サービス提供者が予めコンテンツを仲介業者に登録しておき、仲介業者がコンテンツをユーザに提供するｉコンシェル（登録商標）と称されるサービスも知られている。
【００２１】
図１Ａは上記の如くの、ユーザに係る情報を管理する仲介業者（仲介サーバ）を利用し、仲介業者による匿名化処理を経た情報のみがサービス提供者に渡され、サービス提供者は渡された情報に対応するサービスをユーザに提供するシステムの一例を示す。すなわち図１Ａの構成では、サービス提供者であるサービサ１３００は、予めコンテンツＣＯＮの配信を行う条件（コンテンツ配信条件）を指定し、提供するサービスとしての配信するコンテンツＣＯＮとともに仲介業者（仲介サーバ）１２００に登録する。ユーザ１１００は、図示せぬユーザ端末を使用して自己に係る情報（ユーザに係る情報）を仲介サーバ１２００に送信する。仲介サーバ１２００はユーザ１１００から送信（図中、「ユーザ情報収集」）されるユーザに係る情報（以下単にユーザ情報と称する）をユーザ情報データベース（図中、「ユーザ情報ＤＢ」）ＬＬ（記憶装置）保管する。仲介サーバ１２００はユーザ情報が登録した条件に合致するか否かをマッチング部ＭＡＴにて判定する。受信したユーザ情報が登録した条件と合致した場合、仲介サーバ１２００は対応するコンテンツＣＯＮをユーザ１１００に配信（図中、「コンテンツ提供」）する。
【００２２】
図１Ａの構成によれば、ユーザ１１００のユーザ情報がサービサ１３００に知られることはなく、サービサ１３００が指定した条件に合致するユーザ１１００に対し、仲介サーバ１２００は該当するコンテンツＣＯＮを配信する。したがってユーザ情報のサービサ１３００に対する匿名性が確保される。
【００２３】
しかしながら図１Ａの構成では、サービサ１３００が仲介サーバ１２００に予め登録したコンテンツＣＯＮをユーザ１１００９に配信することができるが、リアルタイムに内容が変化するコンテンツをユーザに提供することができない場合がある。図１Ｂに、リアルタイムに内容が変化するコンテンツをユーザに提供するシステムの構成例を示す。図１Ｂの構成では、サービサ１３００は予めコンテンツを仲介業者（仲介サーバ）１２００に登録することはせず、コンテンツを配信する条件のみを仲介サーバ１２００に登録する。仲介サーバ１２００はユーザ情報を収集してユーザ情報データベースＬＬに保管し、ユーザ情報が登録された条件に合致するかをマッチング部ＭＡＴで判定し、合致すれば、合致の旨をサービサ１３００に通知する。サービサ１３００は通知を受けた時点で該当するコンテンツＣＯＮをリアルタイムに生成して配信する。
【００２４】
ここで図１Ｂの構成の場合、条件に合致するユーザが現れたという事実がリアルタイムにサービサ１３００に伝わるため、ユーザ情報が、希有な状況に係る情報の場合、匿名性の確保が困難になり得る。例えば図２、図３に示すように、コンテンツを配信する条件Ｑが「ユーザが富士山頂に居る」というものであった場合であって、ある日時（例えば冬）に富士山頂に居る人間は、ユーザ１１００ただ一人であった場合を想定する。この場合、「冬に富士山山頂に位置する」という条件は希有な条件となる。このような場合、サービサ１３００は、条件Ｑに合致するユーザがユーザ１１００個人であると知ることができる場合がある。例えば、ブログ（Ｂｌｏｇ）等で、ユーザ１１００が「日時Ｘに仕事で閉山中の富士山頂に登りました。周囲には誰もいませんでした」等の属性情報の一部を公開した場合等である。その場合、ユーザ１１００個人の属性情報である「日時Ｘに「富士山山頂」に居る」という情報がサービサ１３００に知られると、サービサ１３００に対するユーザ情報の匿名性が確保されない（図２，図３中、「匿名性リスク」）。更に、図２，図３に示すように、条件Ｑに「趣味情報」が含まれていた場合、ユーザ１１００の「趣味情報」も併せてサービサ１３００に知られてしまう。更にサービサ１３００は、条件Ｑの合致の通知の記録をとることで、ユーザ１１００のサービス利用状況を知ることもでき、サービス利用状況という属性情報もサービサ１３００に知られてしまう。
【００２５】
このような問題を解決する方法として、例えば以下の方法が考えられる。すなわち、コンテンツ生成のプログラム自体をサービサが仲介サーバに預け、仲介サーバはサービサに条件合致の旨を通知せず、リアルタイムに内容が変化するコンテンツを仲介サーバが生成してユーザに提供する方法である。しかしながら上記方法は、コンテンツ生成負荷を仲介サーバが負う必要がある点、コンテンツ生成のノウハウ、アルゴリズム等がサービサから仲介業者に流出する点等を考慮すると、実現が困難な場合も想定される。
【００２６】
実施例１では、上記問題点を解決する方法として、仲介業者がサービサに通知する条件として、条件に合致するユーザ数がｋ人を超える、すなわち、本人を特定しようとしても候補者をｋ人以下に絞れない状態を確保する。上記候補者をｋ人以下に絞れない状態を「ｋ−匿名性」と称する場合がある。ｋ−匿名性を確保する方法として、いわゆる「情報エントロピー」(information entropy)を用い、該当者数が少ない情報を提供しないように制御する方法と、提供する情報を曖昧にして該当者数を増やす方法とが考えられる。
【００２７】
通知する情報を曖昧にして該当者数を増やす方法として、例えば、条件の範囲を広げる方法がある。条件の範囲を広げる方法としては、例えば位置情報を市単位の情報から県単位の情報に変換する方法等が考えられる。この方法によれば、市単位の条件では該当者がｋ人以下の場合であっても、県単位の条件に変換することにより該当者を増加してｋ人を超えるようにする。
【００２８】
又、通知する情報を曖昧にして該当者数を増やす他の方法として、複数の条件をオア（ｏｒ）論理で組み合わせる（以下単に「組み合わせる」と称する場合がある）方法とが考えられる。複数の条件をオア論理で組み合わせる方法として、例えば「Ａ市に居る」という位置の条件につき、Ａ市に居るユーザがｋ人以下であっても、オア論理を用いて通知する位置の情報を、例えば「Ａ市又は（ｏｒ）Ｂ市」とする。その結果、該当者を増やすことができる。複数の条件をオア論理で組み合わせる方法は、条件の範囲を広げる方法に比し、条件緩和の選択肢が広く、工夫（例えば後述の実施例２）によっては該当者が増えすぎないようにすることができる点で有利と考えられる。
【００２９】
本発明の実施例１は、複数の条件をオア論理条件で組み合わせる方法を採用する。すなわち、情報を配信する条件が希有な条件の場合、すなわち該当するユーザ数が少ない場合に、条件に合致の旨をサービサに通知する際、他の条件を併せて同時に通知する。すなわち、ユーザ情報として条件Ａに合致の旨をサービサに通知する場合、条件Ａに該当（合致）するユーザがｋ人以下である場合には、他の条件Ｂと組み合わせて、「条件Ａ又は条件Ｂに該当」の旨をサービサに通知する。このように条件Ａと他の条件Ｂと組み合わせて同時に通知することによって該当ユーザ数を増加させることができ、実際に条件Ａに該当するユーザを特定することを困難とし得る。その結果、実際に条件Ａに該当するユーザの属性情報である「条件Ａに該当」のサービサに対する匿名性を向上させることができる。
【００３０】
しかしながら、上記「条件Ａに合致の旨をサービサに通知する場合であって条件Ａに該当するユーザがｋ人以下である場合には他の条件Ｂと組み合わせて同時にサービサに通知する」方法の場合、以下の問題点が想定される。即ち、条件Ａ，Ｂを組み合わせる際、組み合わせる条件Ａ，Ｂに通知頻度（通知回数）の偏りがあった場合、条件Ａ，Ｂのうちのいずれが実際に該当する条件であり、他の条件はダミーである点がサービサに知られてしまう可能性がある。この点を図４Ａとともに説明する。尚、「条件Ａに合致の旨をサービサに通知する場合であって条件Ａに該当するユーザがｋ人以下である場合には他の条件Ｂと組み合わせて同時にサービサに通知する」方法における「他の条件Ｂ」のことを、「ダミー条件」或いは「攪乱条件」と称する場合がある。
【００３１】
図４Ａに示すように、条件Ａに該当するユーザ１１００が現れた場合、オア論理を用いて「条件Ａ又は条件Ｂに該当」）（Ａ  ｏｒ  Ｂ）の旨をサービサ１３００に通知する。他方、条件Ｂに該当するユーザ１１００が現れた場合、「条件Ｂに該当」）（Ｂ）の旨をサービサ１３００に通知する。ここで、条件Ａに該当するユーザが現れる頻度が、条件Ｂに該当するユーザが現れる頻度に比して小さい（その結果、通知回数に偏りが生ずる）場合、サービサは、「Ａ  ｏｒ  Ｂ」の通知のうち、「Ｂ」がダミー条件であることを見破る可能性がある。尚、通知回数の偏りとは、例えば「Ａ  ｏｒ  Ｂ」の通知回数が少なく、「Ｂ」の通知回数が多い場合をいう。例えばサービサに対し、「Ａ市又はＢ市」という通知が１件、「Ｂ市」という通知が２０件届いたとすると、サービサは、「ユーザがＢ市に居るときは「Ｂ市」と通知が来る」、「ユーザがＢ市に居るときは「Ａ市又はＢ市」と通知が来る」と予測できてしまう。
【００３２】
本発明の実施例１によれば、仲介業者（仲介サーバ）が、通知する条件の組み合わせを得る際に過大な負荷を負うことなく、適切な条件の組み合わせを得て通知する情報の曖昧化を実現し、ユーザの匿名性を確保することができる。
【００３３】
即ち実施例１によれば、仲介業者（仲介サーバ）がサービサに通知する条件の組み合わせを得る際、図４Ｂに示されるように、条件（条件の組み合わせを含む）を通知する回数の時間平均が偏らないようにする。すなわち図４Ａの参考例では、ユーザ情報として仲介業者１２００がサービサ１３００に通知する情報は、「Ａ ｏｒ  Ｂ」、「Ｂ」、「Ｂ」、「Ｂ」であり、全体を通して「Ｂ」の通知回数が多い。これに対し図４Ｂの実施例１の場合、ユーザ情報として仲介業者２００がサービサ３００に通知する情報は、「Ａ ｏｒ  Ｂ」、「Ｃ ｏｒ  Ｄ」、「Ｂ」、「Ｂ」、「Ａ  ｏｒ  Ｄ」、「Ｂ」であり、全体を通して「Ｂ」の通知回数が比較的少ない。このように実施例１では、通知回数の時間平均の偏りを少なくすることにより、通知する情報の曖昧化を実現し、ユーザの匿名性を確保する。
【００３４】
実施例１によれば、仲介業者がサービサに通知する条件の組み合わせを求める際、条件（条件の組み合わせを含む）を通知する回数が偏らないようにするため、以下の方法を採る。すなわち、仲介サーバ２００は、事前にユーザから送信される条件の統計を取り、各条件につき、通知時の平均該当ユーザ数と、一定時間の平均通知回数とを得る。そして通知時の平均該当ユーザ数がｋ人以下の条件につき、合計した平均該当ユーザ数がｋ人を超えるように、他の条件と組み合わせる。又、組み合わせる際には、組み合わせの結果得られる、各条件（条件の組み合わせを含む）毎の一定時間の平均通知回数の最大値に対する最小値の割合が一定範囲に収まるように、組み合わせを求める。
【００３５】
実施例１によれば、このように通知時の平均該当ユーザ数がｋ人以下の条件につき、合計した通知時の平均該当ユーザ数がｋ人を超えるように他の条件と組み合わせることにより、ｋ−匿名性をする。更に、一定時間の平均通知回数の最大値に対する最小値の割合が一定範囲に収まるように組み合わせを求めることにより、通知回数の偏りを減らすことができる。その結果、条件の組み合わせによる曖昧化を実現すると共に通知回数の偏りを減らすことにより、ダミー条件（攪乱条件）が見破られることを防止する。尚、通知回数の偏りを減らすことを「通知回数の平準化」と称する場合がある。通知回数の平準化は、例えば以下のようにして実現する。すなわち、通知回数の少ない条件（条件の組み合わせを含む）を他の条件（条件の組み合わせを含む）と組み合わせて通知する。その結果、元々通知回数の少ない条件（条件の組み合わせを含む）が、組み合わされた他の条件を通知する場合にも通知され、結果的に元々通知回数の少ない条件の通知回数を増やすことができる。
【００３６】
図５Ａの例の場合、サービサ３００が仲介業者２００に登録した条件がＱ１、Ｑ２、Ｑ３であり、事前統計（事前解析）の結果、通知時の夫々の平均該当ユーザ数がｎ１、ｎ２、ｎ３であり、一定時間の夫々の平均通知回数がｍ１、ｍ２、ｍ３であったとする。ここで条件Ｑ１の平均該当ユーザ数ｎ１がｋ人以下であり、ｋ人を超えるようにするため、条件Ｑ２と組み合わせるものとする。この場合、組み合わせによって得た条件を「Ｑ１＋Ｑ２」と称する（以下同様）。その結果、条件Ｑ１＋Ｑ２の通知時の平均該当ユーザ数はｎ１＋ｎ２となる。又、条件Ｑ２は、Ｑ２該当ユーザが現れた場合に加え、Ｑ１該当ユーザが現れた場合にも通知される。このため、Ｑ２の一定時間の平均通知回数は、Ｑ２の元の一定時間の平均通知回数とＱ１の一定時間の平均通知回数との合計となり、ｍ２＋ｍ１となる。
【００３７】
図５Ｂの構成の場合、コンテンツＣＯＮ（Ｃ１、Ｃ２、...）の配信を行うサービサ３００は、予めコンテンツの配信を行う配信先のユーザ１００の条件Ｑ１、Ｑ２、Ｑ３、...を指定して、仲介サーバ（仲介業者）２００に登録する。ユーザ１００は、ユーザ端末（図示を省略）を使用して自己に係るユーザ情報を仲介サーバ２００に送信する。仲介サーバ２００は、ユーザ１００から送信されたユーザ情報を保管し、サービサ３００が登録した条件Ｑ１、Ｑ２、Ｑ３と合致するか否かを判定する。
【００３８】
例えばユーザ１００から送信されたユーザ情報が、サービサ３００が登録した条件Ｑ１と合致（該当）した場合（図５Ｂ中、「（１）条件Ｑ１通知」）を想定する。この場合、上記組み合わせの結果、条件Ｑ１の該当ユーザが現れたことに応じ、仲介サーバ２００はサービサ３００に対し、「Ｑ１又はＱ２に該当するユーザが現れた」旨の通知（図５Ｂ中、「（２）条件「Ｑ１＋Ｑ２通知」）を行う。「Ｑ１＋Ｑ２通知」を受けたサービサ３００は、「Ｑ１＋Ｑ２通知」に応じ、条件Ｑ１、Ｑ２に夫々対応するコンテンツＣ１、Ｃ２を仲介サーバ２００に配信する。仲介サーバ２００は配信されたコンテンツＣ１、Ｃ２のうち、ユーザ１００のユーザ情報が該当した条件Ｑ１に対応するコンテンツＣ１をユーザ１００に対し配信する（図５Ｂ中、「（３）コンテンツＣ１配信」）。その結果、サービサ３００は、配信したコンテンツを配信する条件としてＱ１、Ｑ２が組み合わされて「Ｑ１＋Ｑ２通知」となり、条件の曖昧化がなされる。このため、仮に条件Ｑ１が希有（希少）であったとしても、サービサ３００が該当するユーザ１００を特定することは困難となり、ユーザ１００の匿名性が確保できる。
【００３９】
次に図６とともに、サービサ３００に通知する条件（以下、単に「通知条件」と称する）の組み合わせを求める方法の例について更に詳細に説明する。上記の如く、事前統計或いは事前解析の結果、通知条件毎の通知時の平均該当ユーザ数（「平均該当者数」とも称する）及び一定時間の平均通知回数を求める。求めた通知時の平均該当者数のうち、通知時の平均該当者数がｋ人以下の通知条件Ｑｉを抽出する。抽出された通知時の平均該当者数がｎｉの条件Ｑｉに対し、通知時の平均該当者数ｎｘが差分ｋ−ｎｉを超える通知条件Ｑｘを抽出し、Ｑｘと組み合わせる。その結果、組み合わせ後の合計に係る通知時の平均該当者数はｋ人を超える。
【００４０】
このようにして全通知条件の各々につき、必要に応じて組み合わせ後の通知時の平均該当者数がｋを超えたら、次に、組み合わせ後の全通知条件の夫々の一定時間の平均通知回数を求め、一定時間の平均通知回数の最大値Ｍｍａｘを得る。そして、一定時間の平均通知回数ｍｉがＭｍａｘにｐ（但し、０≦ｐ≦１）を乗じて得た数以下の一定時間の平均通知回数を有する通知条件Ｑｉを抽出する。次に、抽出された通知条件Ｑｉに対し、一定時間の平均通知回数ｍｙが、Ｍｍａｘにｐを乗じて得た数からｍｘを引いた差分を超えるＱｙを抽出し、抽出された通知条件Ｑｙに、上記Ｑｉを組み合わせる。その結果、通知条件Ｑｉは、通知条件Ｑｉ該当時に加え、通知条件Ｑｙ該当時にも通知される。このため、条件Ｑｉの組み合わせ後の一定時間の平均通知回数は、条件Ｑｉの一定時間の平均通知回数ｍｉにＱｙの一定時間の平均通知回数ｍｙを加えた値となり、Ｍｍａｘにｐを乗じて得た数を超える。
【００４１】
この点を図６とともに説明すると、通知条件Ｑ１の通知時の平均該当者数ｎ１であった場合、通知条件Ｑ２と組み合わせる。その結果、通知条件Ｑ１該当時には「Ｑ１＋Ｑ２」が通知され、「Ｑ１＋Ｑ２」の通知時の平均該当者数はｎ１＋ｎ２であるため、ｎ１＋ｎ２＞ｋなら、ｋ−匿名性が確保される。又、上記組み合わせ後の通知条件Ｑ１の一定時間の平均通知回数ｍ１がＭｍａｘにｐを乗じて得た数以下であった場合、通知回数の平準化のため、通知条件Ｑ１を通知条件Ｑ３に組み合わせる。その結果、その結果、通知条件Ｑ３該当時には「Ｑ３＋Ｑ１」が通知され、通知条件Ｑ１は、通知条件Ｑ１該当時に加え、通知条件Ｑ３該当時にも通知される。したがって条件Ｑ１の一定時間の平均通知回数はｍ１＋ｍ３となり、ｍ１＋ｍ３＞Ｍｍａｘ×ｐなら、通知回数の平準化が実現できる。但し、上記組み合わせによってＭｍａｘが増加する場合があり、Ｍｍａｘが増加する場合には、増加後のＭｍａｘにつき、再度Ｍｍａｘにｐを乗じて得た数以下となる一定時間の平均通知回数を有する通知条件を抽出して再度上記同様の平準化の処理を行る。そして最終的に全通知条件の各々の必要に応じた組み合わせ後の一定時間の平均通知回数がＭｍａｘにｐを乗じて得た数以下とならないようにする。その結果、全通知条件の一定時間の平均通知回数が、最大値Ｍｍａｘにｐを乗じて得た数を超えるようになり、一定時間の平均通知回数の平準化が実現できる。
【００４２】
次に、本発明の実施例１による情報配信システムにつき、より詳細に説明する。
【００４３】
説明の便宜上、最初に参考例の情報配信システムにつき、説明する。
【００４４】
図７は、図１Ａ，１Ｂ，図２，図３、図４Ａとともに述べてきた、参考例の、サービス提供システムとしての情報配信システムのシステム構成例であり、特にユーザ端末、仲介サーバ及びサービサの夫々のハードウェアの構成を示す図である。
【００４５】
図７に示す如く、参考例の情報配信システムは、ユーザ端末１１００，仲介サーバ１２００及びサービサ１３００を有する。ユーザ端末１１００と仲介サーバ１２００との間、及び仲介サーバ１２００とサービサ１３００との間は、夫々ネットワークＮＷ１，ＮＷ２によって相互に通信可能に接続される。
【００４６】
ユーザ端末１１００は、ＣＰＵ（Central Processing Unit）  ＣＰ１，記憶装置ＭＳ１，ＭＬ１，センサＳＥＮ，通信部ＣＯＭ１を有する。ＣＰＵ  ＣＰ１は、例えば記憶装置MＳ1にロードされたプログラム（端末プログラム）を実行することにより、ユーザ端末１１００の動作を制御する。記憶装置ＭＳ１（短期記憶）は、例えばＲＡＭ（Random Access Memory）等であり、データやプログラムを比較的短期間記憶する。記憶装置ＭＬ１（長期記憶）は、例えばROM(Read Only Memory）、ハードディスク装置等であり、データやプログラムを比較的長期間記憶する。センサSENは、例えばGPS(Global Positioning System)を利用してユーザ端末１１００自らの位置を検出する位置検出装置である。通信部ＣＯＭ１は、例えばモデム（MODEM: MOdulator DEModulator）等であり、ユーザ端末１１００がネットワークＮＷ１を利用して仲介サーバ１２００との間で行う通信を実現する。
【００４７】
ユーザ端末１１００では、ＣＰＵ  ＣＰ１が、記憶部ML1に格納された端末プログラムを記憶部MS1にロードして実行することにより、センサＳＥＮを利用してユーザ端末１１００の位置を検出する。そして、検出したユーザ端末１１００の位置の情報をユーザ情報として、通信部ＣＯＭ１を介して仲介サーバ１２００に送信する。
【００４８】
仲介サーバ１２００は、ＣＰＵ  ＣＰ２，記憶装置ＭＳ２，ＭＬ２，通信部ＣＯＭ２−１（通信部１）、ＣＯＭ２−２（通信部２）を有する。ＣＰＵ  ＣＰ２は、例えば記憶装置MＳ２にロードされたサーバプログラムを実行することにより、仲介サーバ１２００の動作を制御する。記憶装置ＭＳ２（短期記憶）は、例えばＲＡＭ等であり、データやプログラムを比較的短期間記憶する。記憶装置ＭＬ２（長期記憶）は、例えばROM、ハードディスク装置等であり、データやプログラムを比較的長期間記憶する。通信部ＣＯＭ２−１は、例えばモデム等であり、仲介サーバ１２００がネットワークＮＷ１を利用してユーザ端末１１００との間で行う通信を実現する。通信部ＣＯＭ２−２も、例えばモデム等であり、仲介サーバ１２００がネットワークＮＷ２を利用してサービサ１３００との間で行う通信を実現する。
【００４９】
仲介サーバ１２００では、ＣＰＵ  ＣＰ２が、記憶部ML２に格納されたサーバプログラムを記憶部MS２にロードして実行することにより、ユーザ端末１１００から送信されるユーザ端末１１００の位置の情報（ユーザ情報）を、通信部ＣＯＭ２−１を介して受信する。仲介サーバ１２００は受信したユーザ情報を記憶部ＭＬ２に格納する。そして予めサービサ１３００によって通知条件テーブルとして記憶部ＭＬ２に登録されている通知条件と受信したユーザ情報とを比較照合する。比較照合の結果、記憶部ＭＬ２に登録されている通知条件と受信したユーザ情報とが合致した場合、仲介サーバ１２００は通信部ＣＯＭ２−２を介し、上記合致の旨をサービサ１３００に通知する。又仲介サーバ１２００は、上記通知に対しサービサ１３００から通信部ＣＯＭ２−２を介して配信されるコンテンツを、通信部ＣＯＭ２−１を介してユーザ端末１１００に配信する。又、仲介サーバ１２００は、サービサ１３００から、サービサ１３００が配信するコンテンツの配信に係る通知条件を受信し、通知条件テーブルの形態で記憶部ＭＬ２に登録する。
【００５０】
サービサ１３００は、ＣＰＵ  ＣＰ３，記憶装置ＭＳ３，ＭＬ３，通信部ＣＯＭ３を有する。ＣＰＵ  ＣＰ３は、例えば記憶装置MＳ３にロードされたサービサプログラムを実行することにより、サービサ１３００の動作を制御する。記憶装置ＭＳ３（短期記憶）は、例えばＲＡＭ等であり、データやプログラムを比較的短期間記憶する。記憶装置ＭＬ３（長期記憶）は、例えばROM、ハードディスク装置等であり、データやプログラムを比較的長期間記憶する。通信部ＣＯＭ３は、例えばモデム等であり、サービサ１３００がネットワークＮＷ２を利用して仲介サーバ１２００との間で行う通信を実現する。
【００５１】
サービサ１３００では、ＣＰＵ  ＣＰ３が、記憶部ML３に格納されたサービサプログラムを記憶部MS３にロードして実行することにより、仲介サーバ１２００から送信される、ユーザ情報が通知条件と合致する旨の通知を、通信部ＣＯＭ３を介して受信する。サービサ１３００は、受信した通知条件に対応するコンテンツを記憶部ＭＬ３から読み出し、通信部ＣＯＭ３を介し、仲介サーバ１２００に配信する。又、サービサ１３００は、自己が配信するコンテンツの配信に係る通知条件を、通信部ＣＯＭ３を介して仲介サーバ１２００に送信し、仲介サーバ２００に登録する。
【００５２】
図８は、図７とともに上述した参考例の情報配信システムのシステム構成例であり、特にユーザ端末、仲介サーバ及びサービサの夫々の機能ブロックを示す図である。
【００５３】
図８に示すように、ユーザ端末１１００は、センサ情報収集部１１１０，ユーザ情報送信部及びコンテンツ受信部１１３０を有する。センサ情報収集部１１１０は、図７に示すＣＰＵ  ＣＰ１，センサＳＥＮ、記憶部ＭＳ１及び端末プログラムによって実現される。センサ情報収集部１１１０は、ＣＰＵ  ＣＰ１が端末プログラムを実行することによって実現する制御の下、センサＳＥＮが収集したユーザ端末１１００の位置の情報（ユーザ情報）を記憶部ＭＳ１に格納する。ユーザ情報送信部１１２０は、ＣＰＵ  ＣＰ１が端末プログラムを実行することによって実現する制御の下、センサ情報収集部１１１０が収集して記憶部ＭＳ１に格納したユーザ情報を、通信部ＣＯＭ−１を介して仲介サーバ１２００に送信する。コンテンツ受信部１１３０は、ＣＰＵ  ＣＰ１が端末プログラムを実行することによって実現する制御の下、通信部ＣＯＭ−１を介し、送信したユーザ情報に応じてサービサ１３００から仲介サーバ１２００を介して配信されたコンテンツを受信する。
【００５４】
仲介サーバ１２００は、ユーザ情報受信部１２５０，ユーザ情報１２６０，通知条件登録受信部１２１０，イベント通知部１２２０，通知条件判定部１２３０，通知条件テーブル１２４０及びコンテンツ仲介部１２７０を有する。ユーザ情報受信部１２５０は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することにより実現する制御の下、ユーザ端末１１００から送信されるユーザ情報を、記憶部ＭＳ２にユーザ情報１２６０として格納する。通知条件登録受信部１２１０は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することにより実現する制御の下、サービサ１３００からコンテンツを配信する通知条件を受信し、受信した通知条件を、通知条件テーブル１２４０に格納する。通知条件判定部１２３０は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することにより実現する制御の下、ユーザ情報受信部１２５０が受信したユーザ情報を、通知条件テーブル１２４０に格納されている、サービサ１３００がコンテンツを配信する通知条件と比較照合する。通知条件判定部１２３０は比較照合の結果、ユーザ情報がコンテンツを配信する通知条件に合致した場合、イベント通知部１２２０に対し、上記合致に係る通知条件と共に通知する。イベント通知部１２２０は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することにより実現する制御の下、通知条件判定部１２３０から通知された合致に係る通知条件をサービサ１３００に通知する。コンテンツ仲介部１２７０は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することにより実現する制御の下、イベント通知部１２２０がサービサ１３００に通知した合致に係る通知条件に応じてサービサ１３００から配信されたコンテンツをユーザ端末１１００に配信する。すなわち、サービサ１３００から提供されたサービスをユーザ端末１１００に提供する。
【００５５】
サービサ１３００は、通知条件登録部１３１０，イベント受信部１３２０，コンテンツ１３３０及びコンテンツ配信部１３４０を有する。通知条件登録部１３１０は、ＣＰＵ  ＣＰ３がサービサプログラムを実行することにより実現する制御の下、提供するサービスとしてのコンテンツを配信する通知条件を予め仲介サーバ１２００に登録する。イベント受信部１３２０は、ＣＰＵ  ＣＰ３がサービサプログラムを実行することにより実現する制御の下、仲介サーバ１２００から通知された合致に係る通知条件を受信し、コンテンツ配信部１３４０に通知する。コンテンツ配信部１３４０は、ＣＰＵ  ＣＰ３がサービサプログラムを実行することにより実現する制御の下、以下の動作を行う。すなわち、イベント受信部１３２０から通知された合致に係る通知条件に対応するコンテンツをコンテンツ１３３０から抽出し、仲介サーバ１２００を介し、ユーザ端末１１００に配信する。
【００５６】
次に図９とともに、本発明の実施例１による、サービス提供システムとしての情報配信システムについて説明する。
【００５７】
図９は、図５Ｂ，図６とともに述べてきた、実施例１の情報配信システムのシステム構成例であり、特にユーザ端末、仲介サーバ及びサービサの夫々のハードウェアの構成を示す図である。
【００５８】
図９に示す如く、実施例１の情報配信システムは、ユーザ端末１００，仲介サーバ２００及びサービサ３００を有する。ユーザ端末１００と仲介サーバ２００との間、及び仲介サーバ２００とサービサ３００との間は、夫々ネットワークＮＷ１，ＮＷ２によって相互に通信可能に接続される。
【００５９】
ユーザ端末１００、仲介サーバ２００及びサービサ３００は、夫々図７とともに上述した参考例の情報配信システムにおけるユーザ端末１１００、仲介サーバ１２００及びサービサ１３００と同様のハードウェアの構成を有する。同様のハードウェアの構成要素には同一の符号を付し、その説明を省略する。
【００６０】
図９に示す実施例１の情報配信システムが図７に示す参考例の情報配信システムと異なる点は以下の通りである。すなわち、仲介サーバ２００の記憶部ＭＬ２には、後述する、ユーザ情報・統計、条件通知組み合わせテーブル及びサーバプログラムが格納される。又仲介サーバ２００の記憶部ＭＳ２には、後述する、平均該当者数及び平均通知回数比較テーブルが格納される。仲介サーバ２００では、サーバプログラムがＣＰＵ  ＣＰ２によって実行されることによって実現される制御の下、平均該当者数及び平均通知回数比較テーブル、ユーザ情報・統計、条件組み合わせテーブルが使用され、図１０とともに後述する機能が実現される。
【００６１】
図１０は、図９とともに上述した実施例１の情報配信システムのシステム構成例であり、特にユーザ端末、仲介サーバ及びサービサの夫々の機能ブロックを示す図である。
【００６２】
図１０に示すように、ユーザ端末１００は、図８とともに上述したユーザ端末１１００と同様の構成を有し、同様の構成要素には同一の符号を付し、その説明を省略する。又、サービサ３００も、図８とともに上述したサービサ１３００と同様の構成を有し、同様の構成要素には同一の符号を付し、その説明を省略する。又、図１０に示すように、仲介サーバ２００は、図８とともに上述したサービサ１３００と部分的に同様の構成を有し、同様の構成要素には同一の符号を付し、その説明を省略する。
【００６３】
仲介サーバ２００のユーザ情報統計作成部２５５は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することによって実現される。ユーザ情報統計作成部２５５は、統計或いは事前解析により、サービサ３００が仲介サーバ２００に登録したコンテンツを配信する通知条件毎に、通知時の平均該当者数及び一定時間の平均通知回数を求める。尚、ユーザ情報統計作成部２５５は、ユーザ情報受信部１２５０がユーザ端末１００から受信したユーザ情報に基づき、上記通知時の平均該当者数及び一定時間の平均通知回数を求め、平均該当者数及び平均通知回数比較テーブル２４５に格納する。
【００６４】
ここで通知時の平均該当者数とは、仲介サーバ２００がサービサ３００に通知条件を通知する際の、サービサ３００が仲介サーバ２００に登録した配信に係る通知条件に該当するユーザ数の平均である。又、一定時間の平均通知回数とは、サービサ３００が仲介サーバ２００に登録した配信に係る通知条件に該当するユーザが現れた回数の一定時間の平均である。ここで配信に係る通知条件とは、例えば特定の場所（上記の例の場合、富士山頂）とすることができる。ユーザ端末１００の位置が上記センサＳＥＮにより常時検出され、検出されたユーザ端末１００の位置の情報がユーザ情報として仲介サーバ２００に送信される。仲介サーバ２００のユーザ情報受信部１２５０がユーザ情報を受信する。仲介サーバ２００の通知条件判定部１２３０はユーザ情報が通知条件（上記例の場合、特定の場所）に合致するか否かを判定する。又、ユーザ情報が通知条件と合致する場合、ユーザ情報統計作成部２５５に通知する。ユーザ情報統計作成部２５５は通知を受け、ユーザ端末１００（を保持するユーザ）が条件に合致したことを認識する。実際にはユーザ端末１００は複数（ユーザ数分）存在する。仲介サーバ２００は複数のユーザ端末１００から夫々のユーザ情報を受信し、受信した夫々のユーザ情報につき、通知条件と合致するか否かを判定する。判定の結果、一又は複数のユーザのユーザ情報が通知条件に合致する場合、通知条件判定部１２３０はユーザ情報統計作成部２５５に一又は複数のユーザのユーザ情報が通知条件に合致する旨を通知する。ユーザ情報統計作成部２５５は通知を受け、一又は複数のユーザのユーザ情報が通知条件に合致することを認識し、認識に基づき、通知時の平均該当者数及び一定時間の平均通知回数を求め、平均該当者及び平均通知回数比較テーブル２４５に格納する。
【００６５】
通知時の平均該当者数を求める際の平均の取り方の例として、例えば、例えば直近の１週間或いは１ヶ月を通して、１時間に何人のユーザのユーザ情報が通知条件に合致するかの統計を取る。そして統計に基づき、例えば直近の１週間或いは１ヶ月を通した１時間単位の平均値として通知時の平均該当者数を求めることができる。尚、上記１週間或いは１ヶ月及び１時間の夫々の数値は、どの程度リアルタイムに通知時の平均該当者数を求めるかに関する設計条件により、任意に決定することができる。又一定時間の平均通知回数を求める際の平均の取り方の例として、例えば直近の１週間或いは１ヶ月を通してユーザ情報が通知条件に合致した回数の累計を取り、累計に基づき、例えば、１時間単位の平均通知回数を求めることができる。尚、上記１週間或いは１ヶ月及び１時間の夫々の数値は、どの程度リアルタイムに一定時間の平均通知回数を求めるかに関する設計条件により、任意に決定することができる。
【００６６】
尚、上記のようにして通知時の平均該当者数及び一定時間の平均通知回数を求める際、平均を取る期間を通知時の平均該当者数及び一定時間の平均通知回数の間で同一にすることが望ましい。同様に、平均値を求める単位時間も、通知時の平均該当者数及び一定時間の平均通知回数の間で同一にすることが望ましい。
【００６７】
ユーザ情報統計作成部２５５は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することによって実現される。ユーザ情報統計作成部２５５は、ユーザ情報受信部１２５０が受信したユーザ情報と通知条件判定部１２３０の判定結果とに基づき、通知時の平均該当者数及び一定時間の平均通知回数を求めるための統計及び累計の情報をユーザ情報・統計２６０に格納する。又ユーザ情報統計作成部２５５は、格納された統計及び累計の情報に基づき、通知条件毎の通知時の平均該当者数及び一定時間の平均通知回数を求める。求められた通知条件毎の通知時の平均該当者数及び一定時間の平均通知回数は上記の如く、平均該当者数及び平均通知回数比較テーブル２４５に格納される。
【００６８】
条件組み合わせ生成部２６５は、ＣＰＵ  ＣＰ２がサーバプログラムを実行することによって実現される。条件組み合わせ生成部２６５は、ユーザ情報・統計２６５に基づき、イベント通知部がサービサ３００に対し「条件に合致」の旨の通知を行う際に、合致に係る条件と組み合わせて同時に通知する他の条件（ダミー条件）と合致に係る条件との組み合わせを求める。尚、図４Ｂ、図５Ａ，５Ｂ、図６とともに上述の如く、イベント通知部がサービサ３００に対し「条件に合致」の旨の通知を行う際に他の条件（ダミー条件）を合致に係る条件と組み合わせて同時に通知するのは、合致に係る条件の平均該当者数がｋ人以下の場合である。条件組み合わせ生成部２６５は、このようにして求めた合致に係る条件と組み合わせて同時に通知する他の条件（ダミー条件）と合致に係る条件との組み合わせを、条件通知組み合わせテーブル２４０に格納する。
【００６９】
又、サービサ３００のコンテンツ配信部１３４０は、仲介サーバ２００から上記の如く合致に係る条件に他の条件が組み合わされて通知されると、合致に係る条件及び他の条件の夫々に対応するコンテンツを仲介サーバ２００に配信する。すなわち、対応するサービスを仲介サーバ２００に提供する。仲介サーバ２００のコンテンツ仲介部１２７０は、サービサ３００から合致に係る条件及び他の条件の夫々に対応するコンテンツを受信すると、合致に係る条件及び他の条件の夫々に対応するコンテンツのうち、合致に係るコンテンツのみをユーザ端末１００に配信する。即ち合致に係るサービスをユーザ端末１００に提供する。
【００７０】
図１１は、図１０とともに上述した条件通知組み合わせテーブル２４０の構成の一例を示す。条件通知組み合わせテーブル２４０の各行（エントリ）はサービサ３００から登録されたコンテンツを配信する通知条件毎に設けられる。通知条件組み合わせテーブル２４０の一列目の「通知条件」の欄には通知条件を示す識別子が格納される。通知条件組み合わせテーブル２４０の二列目の「組み合わせ条件」の欄には、通知条件をサービサ３００に通知する際に組み合わせて同時に通知する他の通知条件（ダミー条件）の識別子が夫々格納される。又、条件通知組み合わせテーブル２４０の三列目の「対応サービサ」の欄には、通知条件を登録したサービサ３００の識別子或いはサービサ３００のアドレス等が格納される。図１１の例の場合、条件通知組み合わせテーブル２４０の三列目の欄には、サービサ３００の識別子「サービサＳ１」及びアドレス「http://s1.co.jp/receiveNotify」(URL:Uniform Resource Locator)が格納される。
【００７１】
図１１の例の場合において、例えば、仲介サーバ２００のユーザ情報受信部１２５０がユーザ端末１００から通知条件Ｑ１に合致するユーザ情報を受信した場合を想定する。この場合、イベント通知部１２２０は、図１１の１行目のエントリの内容、すなわち「通知条件」「Ｑ１」、「組み合わせ条件」「Ｑ２」、及び「対応サービサ」「サービサＳ１...」従ってサービサ３００に対し通知を行う。すなわちイベント通知部１２２０は、「通知条件」「Ｑ１」に「組み合わせ条件」「Ｑ２」を組み合わせて「Ｑ１又はＱ２」という、組み合わせに係る通知条件を「サービサＳ１」の識別子を有するサービサ３００に通知する。
【００７２】
尚、図１１の例の場合、１〜４行目の各エントリの「対応サービサ」として、全て同一の「サービサＳ１...」が格納されている。したがってこの場合、通知条件Ｑ１、Ｑ２、Ｑ３、Ｑ４のそれぞれは同一のサービサ３００によって登録されている。したがってユーザ端末１００から送信されるユーザ情報が通知条件Ｑ１、Ｑ２、Ｑ３、Ｑ４のいずれに合致した場合でも、イベント通知部１２２０は識別子「サービサＳ１」を有する同一のサービサ３００に通知を行う。しかしながらこの例に限られず、複数の異なる通知条件が、夫々複数の異なるサービサ３００によって登録されてもよい。但し、複数の異なる通知条件が夫々複数の異なるサービサ３００によって登録される場合であっても、図１１中、同一エントリ内の一列目の「通知条件」と二列目の「組み合わせ条件」とは、夫々同一のサービサ３００によって登録された通知条件である必要がある。例えば図１１中、通知条件Ｑ１に対応する一行目のエントリの組み合わせ条件Ｑ２は、２行目のエントリの通知条件Ｑ２であるが、この場合、両通知条件Ｑ１、Ｑ２は、同一のサービサ３００によって登録された通知条件である必要がある。
【００７３】
次に図１２，図１３，図１４とともに、図１０に示される仲介サーバ２００の条件通知組み合わせ生成部２６５によって実行される、条件通知組み合わせテーブル２４０の作成方法について説明を行う。
【００７４】
図１２は、図１０に示される平均該当者数及び平均通知回数比較テーブル２４５（以下単に比較テーブル２４５と称する場合がある）の構成の例を示す。尚、図１２の内容は上述した図６の内容と同一である。条件通知組み合わせ生成部２６５は、ユーザ情報・統計２６０に基づいて通知時の平均該当者数及び一定時間の平均通知回数を算出し、平均該当者数及び平均通知回数比較テーブル２４５に格納する。
【００７５】
図１２中、各行（エントリ）は、図１１同様、通知条件毎に設けられる。一列目の「通知条件」の欄には図１１同様、通知条件の識別子が格納される。２列目の「元平均該当者数」の欄には、一列目の欄に格納された通知条件に該当するユーザ数につき、条件通知組み合わせ生成部２６５が算出した通知時の平均該当者数が格納される。３列目の「元平均通知回数」の欄には、一列目の欄に格納された通知条件について条件通知組み合わせ生成部２６５が算出した一定時間の平均通知回数が格納される。尚、３列目の「元平均通知回数」の欄に格納される一定時間の平均通知回数は、受信されたユーザ情報が１列目の通知条件に合致した際にサービサ３００に通知される回数に係るもののみである。したがって３列目の「元平均通知回数」の欄に格納される一定時間の平均通知回数は、１列目の通知条件が、受信されたユーザ情報が他の通知条件に合致した際に組み合わせ条件（ダミー条件）として同時にサービサ３００に通知される回数を含まない。
【００７６】
４列目の「組み合わせ条件」の欄には、図１１の２列目同様、受信されたユーザ情報が１列目の通知条件に合致した場合にイベント通知部１２２０がサービサ３００に対し同時に通知する他の条件（ダミー条件）の識別子が格納される。尚、この場合の「他の通知条件」（ダミー条件）を「組み合わせ条件」とも称する。
【００７７】
図１２中、５列目の「通知時の平均該当者数」の欄には、一列目の通知条件がイベント通知部１２２０によってサービサ３００に通知される際に、同時に通知される３列目の組み合わせ条件も含めた両方の条件についての通知時の平均該当者数が格納される。すなわち、「通知時の平均該当者数」の欄には、一列目の通知条件と４列目の組み合わせ条件との夫々の平均該当者数の和が格納される。例えば１行目のエントリの場合、通知条件Ｑ１の平均該当者数は上記エントリの２行目に格納された元平均該当者数ｎ１である。他方組み合わせ条件Ｑ２の平均該当者数は、通知条件Ｑ２に対応する２行目のエントリの元平均該当者数の欄に格納された元平均該当者数ｎ２である。したがって通知条件Ｑ１に対応する１行目のエントリの「通知時の平均該当者数」の欄には、両者の和である、ｎ１＋ｎ２が格納される。尚、４行目のエントリの場合のように、同時に通知される３列目の組み合わせ条件が存在しない場合（図１２中、「なし」）、「通知時の平均該当者数」の欄には、２列目の「元平均該当者数」と同じ値が格納される。
【００７８】
図１２中、６列目の「一定時間の平均通知回数」の欄には、一列目の通知条件がイベント通知部１２２０によってサービサ３００に通知される回数に係る一定時間の平均通知回数が格納される。すなわち「一定時間の平均通知回数」の欄には、一列目の通知条件と、一列目の通知条件が組み合わせ条件として追加された他のエントリが存在する場合、他のエントリの通知条件の一定時間の平均通知回数を含めた和の値が格納される。例えば１行目のエントリの場合、通知条件Ｑ１の一定時間の平均通知回数は上記エントリの２行目に格納された元平均通知回数ｍ１である。他方一列目の通知条件Ｑ１が組み合わせ条件として追加された他のエントリとして、通知条件Ｑ３に対応する３行目のエントリが存在する。通知条件Ｑ３に対応する３行目のエントリの元平均通知回数はｍ３である。したがって通知条件Ｑ１に対応する１行目のエントリの「一定時間の平均通知回数」の欄には、両者の和、ｍ１＋ｍ３が格納される。すなわち通知条件Ｑ１に対応する１行目のエントリの場合、通知条件Ｑ１は、受信されたユーザ情報が通知条件Ｑ１に合致した際に加え、受信されたユーザ情報が通知条件Ｑ３に合致した際、組み合わせ条件として、合致した条件Ｑ３と同時にサービサ３００に通知される。したがって通知条件Ｑ１の「一定時間の平均通知回数」は、条件Ｑ１の元平均通知回数ｍ１と条件Ｑ３の元平均通知回数ｍ３との和、ｍ１＋ｍ３として得られる。このように、通知条件Ｑ１の「一定時間の平均通知回数」の欄には、条件Ｑ１の元平均通知回数ｍ１と条件Ｑ３の元平均通知回数ｍ３との和、ｍ１＋ｍ３が格納される。尚、４行目のエントリの通知条件Ｑ４の場合のように、特に他の通知条件に対し組み合わせ条件として追加されていない通知条件では、「一定時間の平均通知回数」の欄には、３列目の「元平均通知回数」と同じ値が格納される。
【００７９】
図１３，図１４は、条件通知組み合わせ生成部２６５が比較テーブル２４５を用いて条件組み合わせテーブル２４０を生成する処理の流れを示すフローチャートである。尚、図１３，図１４中、匿名性の指標に係る閾値であって、通知時の平均該当者数の閾値ｋは、２以上の任意の数とされ、例えば１０とされる。又、一定時間の平均通知回数の平準化の割合の閾値ｐは、０〜１の範囲の任意の数とされ、例えば０．８とされる。
【００８０】
図１３中、ステップＳ１で処理を開始すると、ステップＳ２で条件通知組み合わせ生成部２６５は、同一サービサ３００が登録した全ての通知条件の夫々につき、通知時の平均該当者数（以下、「元平均該当者数」と称する）を得る。次に、このようにして得た、同一サービサ３００が登録した全ての通知条件の夫々の平均該当者数の和を算出する。そして算出した和がｋを超えるか否かを判定する。
【００８１】
和がｋを超えない場合（ステップＳ２  ＮＯ），仮に全通知条件を組み合わせたとしてもｋ−匿名性を確保することができないため、通知条件の設定が不適切と判断される。このため、条件通知組み合わせ生成部２６５はステップＳ３にてサービサ３００に対し、「条件設定が不適切なため、より条件を緩和するか、条件を増やす必要がある」旨を通知し、処理を終了する。
【００８２】
他方、算出した和がｋを超える場合（ステップＳ２  ＹＥＳ），同一サービサ３００が登録した通知条件のうち、通知時の平均該当者数がｋを超える通知条件を、以後の処理対象から除去する（ステップＳ５）。平均該当者数がｋを超える通知条件は既にｋ−匿名性を有するため、以後の処理でサービサ３００に同時に通知すべき組み合わせ条件を追加することが不要だからである。次にステップＳ６で、処理対象の通知条件の夫々の元平均該当者数の和を算出し、算出した和がｋを超えるか否か判定する。判定の結果、算出した和がｋを超えない場合（ステップＳ６  ＮＯ），ステップＳ７に移行する。ステップＳ７では、ステップＳ５で除去した元平均該当者数がｋを超える通知条件のうち、最も元平均該当者数が少ない通知条件を１以上の所定個数、処理対象に戻し、ステップＳ８に移行する。又、ステップＳ６の判定の結果、算出した和がｋを超える場合（ステップＳ６  ＹＥＳ）、直接ステップＳ８に移行する。
【００８３】
ステップＳ８では、処理対象の通知条件中、図１２に示す「通知時の平均該当者数」がｋ以下の通知条件が含まれているか否か判定する。「通知時の平均該当者数」がｋ以下の通知条件が含まれていない場合（ステップＳ８  ＮＯ），図１４のステップＳ２１に移行する。図１４に示す、「通知時の平均該当者数」を増加することによって、同一サービサ３００によって登録された全ての通知条件の各々につき、「通知時の平均該当者数」がｋを超えるようにする処理が終了したと判定できるからである。他方、「通知時の平均該当者数」がｋ以下の通知条件が処理対象の通知条件に含まれている場合（ステップＳ８  ＹＥＳ）、ステップＳ９以降の、「通知時の平均該当者数」を増加する処理を行う。
【００８４】
ステップＳ９では、「通知時の平均該当者数」がｋ以下の通知条件のうち、一つの通知条件Ｑｘを選択する（選択の順序は任意でよい）。次にステップＳ１０では、ｋから、Ｑｘの「通知時の平均該当者数」ｎｘを引いた値（差分）を算出し、算出した値ｋ−ｎｘを超える元平均該当者数を有する通知条件を処理対象の通知条件中、組み合わせ条件の候補として抽出する。そして組み合わせ条件の候補として抽出した通知条件中、元平均該当者数ｎｉが最も少ないＱｉを組み合わせ条件として抽出する（ステップＳ１０  ＹＥＳ）。尚、ステップＳ１０では、上記のように、元平均該当者数ｎｉが最も少ないＱｉを抽出することが望ましい。しかしながら、代わりに、元平均該当者数ｎｉがｋ−ｎｘを超えるＱｉをランダムに選択して組み合わせ条件として使用しても良い。尚、上記算出した値ｋ−ｎｘを超える元平均該当者数を有する通知条件が処理対象の通知条件に含まれない場合（ステップＳ１０  ＮＯ），ステップＳ１４に移行する。
【００８５】
ステップＳ１４では、組み合わせ条件の候補として、夫々の元平均該当者数ｎｉ〜ｎｊの和がｋ−ｎｘを超える通知条件Ｑｉ〜Ｑｊの組み合わせを処理対象の通知条件から選択する。そして選択した複数の通知条件Ｑｉ〜Ｑｊの組み合わせのうち、夫々の元平均該当者数ｎｉ〜ｎｊの和が最小となる通知条件Ｑｉ〜Ｑｊの組み合わせを抽出する。尚、ステップＳ１４では、上記のように、夫々の元平均該当者数ｎｉ〜ｎｊの和が最小となる通知条件Ｑｉ〜Ｑｊの組み合わせを抽出することが望ましい。しかしながら、代わりに、夫々の元平均該当者数ｎｉ〜ｎｊの和がｋ−ｎｘを超える通知条件Ｑｉ〜Ｑｊの組み合わせをランダムに選択して組み合わせ条件として使用しても良い。
【００８６】
ステップＳ１０で、差分ｋ−ｎｘを超える元平均該当者数を有する通知条件Ｑｉを組み合わせ条件として抽出できた場合（ステップＳ１０  ＹＥＳ）、ステップＳ１１で、抽出した通知条件Ｑｉを通知条件Ｑｘに対する組み合わせ条件として追加する。そしてステップＳ１２で、通知条件Ｑｘの「通知時の平均該当者数」に、組み合わせ条件として追加した通知条件Ｑｉの元平均該当者数ｎｉを加える。次にステップＳ１３にて、組み合わせ条件として追加した通知条件Ｑｉの「一定時間の平均通知回数」（図１２参照）に、通知条件Ｑｘの元平均通知回数ｍｘを加えた後、ステップＳ８に戻る。
【００８７】
ステップＳ１４の処理後にステップＳ１５にて、ステップＳ１４で抽出した通知条件Ｑｉ〜Ｑｊを通知条件Ｑｘに対する組み合わせ条件として追加する。そしてステップＳ１６で、通知条件Ｑｘの「通知時の平均該当者数」に、組み合わせ条件として追加した通知条件Ｑｉ〜Ｑｊの夫々の元平均該当者数ｎｉ〜ｎｊを加える。次にステップＳ１７にて、組み合わせ条件として追加した通知条件Ｑｉ〜Ｑｊの各々の「一定時間の平均通知回数」（図１２参照）に、通知条件Ｑｘの元平均通知回数ｍｘを加えた後、ステップＳ８に戻る。
【００８８】
ステップＳ８以降の処理は上述の通りである。このようにして、ステップＳ８の判定結果がＮＯとなる迄、ステップＳ８〜Ｓ１３或いはステップＳ８〜Ｓ１７の処理を繰り返す。すなわち、全ての処理対象の通知条件Ｑｘに対し、組み合わせ条件を求め、組み合わせ条件の追加により全ての処理対象の通知条件Ｑｘの「通知時の平均該当者数」がｋを超えるようになる迄、ステップＳ８〜Ｓ１３或いはステップＳ８〜Ｓ１７の処理を繰り返す。全ての処理対象の通知条件Ｑｘの「通知時の平均該当者数」がｋを超えると（ステップＳ８  ＮＯ），図１４の、「一定時間の平均通知回数」の平準化の処理に移行する。
【００８９】
図１４中、ステップＳ２１にて、同一のサービサ３００によって登録された全ての通知条件につき、「一定時間の平均通知回数」ｍｘを得る。次に、このようにして得た「一定時間の平均通知回数」の最大値Ｍｍａｘを抽出する。次にステップＳ２２にて、同一のサービサ３００によって登録された全ての通知条件中、「一定時間の平均通知回数」ｍｘが、Ｍｍａｘにｐを乗じて得た値以下となる通知条件Ｑｘが存在するか否かを判定する。「一定時間の平均通知回数」ｍｘがＭｍａｘにｐを乗じて得た値以下の通知条件Ｑｘが存在しない場合（ステップＳ２２  ＮＯ），処理を終了する。既に、「一定時間の平均通知回数」の平準化の処理が終了したと判断できるからである。他方、「一定時間の平均通知回数」ｍｘが、Ｍｍａｘにｐを乗じて得た値以下となる通知条件Ｑｘが存在する場合（ステップＳ２２  ＹＥＳ），ステップＳ２４に移行する。
【００９０】
ステップＳ２４では、同一のサービサ３００によって登録された全ての通知条件中、「一定時間の平均通知回数」ｍｘがＭｍａｘにｐを乗じて得た値以下の通知条件Ｑｘを抽出する。そして抽出した通知条件Ｑｘのうち、通知条件Ｑｘを１個選択（選択方法は任意でよい）し、ステップＳ２５に移行する。ステップＳ２５では、Ｍｍａｘにｐを乗じて得た値からｍｘを引いた値を算出し、算出した値Ｍｍａｘ×ｐ−ｍｘ（差分）を超える元平均通知回数を有する通知条件を、通知条件Ｑｘを組み合わせ条件として加える相手方の候補として抽出する。そして相手方の候補として抽出した通知条件中、元平均通知回数ｍｉが最も少ないＱｉを、相手方の通知条件として抽出する（ステップＳ２５  ＹＥＳ）。ここで、ステップＳ２５では、元平均通知回数ｍｉが最も少ない通知条件Ｑｉを抽出することが望ましい。これは、後述するステップＳ３３、Ｓ３４で最大値Ｍｍａｘの更新を行う可能性を極力低くするためである。しかしながら、代わりに、元平均通知回数ｍｉがＭｍａｘ×ｐ−ｍｘを超える通知条件Ｑｉをランダムに選択してＱｘを組み合わせ条件として加える相手方の通知条件としてもよい。尚、上記Ｍｍａｘ×ｐ−ｍｘを超える元平均通知回数を有する通知条件が、処理対象の通知条件に含まれない場合（ステップＳ２５  ＮＯ），ステップＳ２９に移行する。
【００９１】
ステップＳ２９では、Ｑｘを組み合わせ条件に加える相手方の候補として、夫々の元平均通知回数ｍｉ〜ｍｊの和が差分Ｍｍａｘ×ｐ−ｍｘを超える通知条件Ｑｉ〜Ｑｊの組み合わせを処理対象の通知条件から選択する。そして選択した複数の通知条件Ｑｉ〜Ｑｊの組み合わせのうち、夫々の元平均通知回数ｍｉ〜ｍｊの和が最小となる通知条件Ｑｉ〜Ｑｊの組み合わせを抽出する。ここで、ステップＳ２９では、夫々の元平均通知回数ｍｉ〜ｍｊの和が最小となる通知条件Ｑｉ〜Ｑｊの組み合わせを抽出することが望ましい。これは、後述するステップＳ３３、Ｓ３４で最大値Ｍｍａｘの更新を行う可能性を極力低くするためである。しかしながら、代わりに、夫々の元平均通知回数ｍｉ〜ｍｊの和がＭｍａｘ×ｐ−ｍｘを超える通知条件Ｑｉ〜Ｑｊの組み合わせをランダムに選択してＱｘを組み合わせ条件として加える相手方の通知条件としてもよい。
【００９２】
ステップＳ２５で、Ｍｍａｘ×ｐ−ｍｘ（差分）を超える元平均通知回数を有する通知条件Ｑｉを、Ｑｘを組み合わせ条件として加える相手方の通知条件として抽出できた場合（ステップＳ２５  ＹＥＳ）、ステップＳ２６で、抽出した通知条件Ｑｉの組み合わせ条件として、通知条件Ｑｘを追加する。そしてステップＳ２７で、相手方の通知条件Ｑｉの「通知時の平均該当者数」に、組み合わせ条件として追加した通知条件Ｑｘの元平均該当者数ｎｉを加える。次にステップＳ２８にて、通知条件Ｑｘの「一定時間の平均通知回数」に、通知条件Ｑｉの元平均通知回数ｍｘを加えた後、ステップＳ３３に移行する。
【００９３】
ステップＳ２９の処理後にステップＳ３０にて、ステップＳ２９で抽出した、相手方の通知条件Ｑｉ〜Ｑｊの各々の組み合わせ条件として、通知条件Ｑｘを追加する。そしてステップＳ３１で、通知条件Ｑｉ〜Ｑｊの各々の「通知時の平均該当者数」に、組み合わせ条件として使用する通知条件Ｑｘの元平均該当者数ｎｘを加える。次にステップＳ３２にて、通知条件Ｑｘの「一定時間の平均通知回数」に、通知条件Ｑｉ〜Ｑｊの夫々の元平均該当者数ｍｉ〜ｍｊを加えた後、ステップＳ３３に移行する。
【００９４】
ステップＳ３３では、ステップＳ２８或いはＳ３２の処理の結果、Ｑｘの「一定時間の平均通知回数」が最大値Ｍｍａｘを超えたか否かを判定する。Ｑｘの「一定時間の平均通知回数」が最大値Ｍｍａｘを超えなかった場合（ステップＳ３３  ＮＯ），ステップＳ２２に移行する。Ｑｘの「一定時間の平均通知回数」が最大値Ｍｍａｘを超えた場合（ステップＳ３３  ＹＥＳ），ステップＳ３４にて、最大値Ｍｍａｘを超えたＱｘの「一定時間の平均通知回数」で最大値Ｍｍａｘを更新した後、ステップＳ２２に移行する。
【００９５】
ステップＳ２２以降の処理は上述の通りである。このようにして、ステップＳ２２の判定結果がＮＯとなる迄、ステップＳ２２〜Ｓ２８〜Ｓ３３（場合によっては更にＳ３４）或いはステップＳ２２〜Ｓ３２〜Ｓ３３（場合によっては更にＳ３４）の処理を繰り返す。すなわち、全ての処理対象の通知条件Ｑｘにつき、「一定時間の平均通知回数」が最大値Ｍｍａｘにｐを乗じて得た値以上になる迄、上記処理を繰り返す。全ての処理対象の通知条件Ｑｘにつき、「一定時間の平均通知回数」が最大値Ｍｍａｘにｐを乗じて得た値以上になると（ステップＳ２２  ＮＯ），処理を終了する（ステップＳ２３）。但し、上記の如く、「通知時の平均該当者数」の増加処理後に増加された「一定時間の平均通知回数」が最大値Ｍｍａｘを超える場合（Ｓ３３  ＹＥＳ）には、ステップＳ３４で最大値Ｍｍａｘを更新する。その結果、ステップＳ２２では、Ｍｍａｘにｐを乗じて得た値以下の「一定時間の平均通知回数」を有する通知条件が新たに生ずる場合がある。その場合、新たに生じた通知条件に対し、ステップＳ２２〜Ｓ２８〜Ｓ３３（場合によっては更にＳ３４）或いはステップＳ２２〜Ｓ３２〜Ｓ３３（場合によっては更にＳ３４）の処理を実行する。
【００９６】
上述した図１３，図１４の処理は、仲介サーバ２００に通知条件を登録するサービサ３００毎に、条件通知組み合わせ生成部２６５が実施する。条件通知組み合わせテーブル２４０及び比較テーブル２４５も、各サービサ３００に対し、個別に設けられる。
【実施例２】
【００９７】
次に本発明の実施例２による情報配信システムについて説明する。本発明の実施例２による情報配信システムは、以下に述べる点を除き、上述した本発明の実施例１による情報配信システムと同様の構成を有し、同様の機能を実現する。以下に実施例１との相違点につき説明を行い、実施例１と同様な構成及び機能につき、重複する説明を省略する。
【００９８】
図１５は、図１０とともに上述した条件通知組み合わせテーブル２４０の構成の一例を示す。条件通知組み合わせテーブル２４０の各行（エントリ）はサービサ３００から登録されたコンテンツを配信する通知条件毎に設けられる。通知条件組み合わせテーブル２４０の一列目の「通知条件」の欄には通知条件を示す識別子、二列目の「組み合わせ条件」の欄には、通知条件をサービサ３００に通知する際に組み合わせて同時に通知する他の通知条件（ダミー条件）の識別子が夫々格納される。実施例２では、上記「組み合わせ条件」の欄には、通知確率を示す情報が付される場合がある。例えば第１行目のエントリの「組み合わせ条件」の欄には、通知条件Ｑ２及び通知条件Ｑ３が格納されているが、通知条件Ｑ３には、通知確率として「５０％」が付されている。この場合、受信したユーザ情報が通知条件Ｑ１に合致した際にサービサ３００に通知すべき条件として、通知条件Ｑ１に加え、通知条件Ｑ２及び５０％の確率で通知条件Ｑ３が含まれる。すなわち受信したユーザ情報が通知条件Ｑ１と合致した際にサービサ３００に通知すべき条件は、Ｑ１＋Ｑ２＋Ｑ３（「Ｑ１又はＱ２又はＱ３」）が５０％、Ｑ１＋Ｑ２（「Ｑ１又はＱ２」）が残りの５０％の確率となる。すなわち２回に一回にはＱ１＋Ｑ２＋Ｑ３（「Ｑ１又はＱ２又はＱ３」）が通知され、他の一回にはＱ１＋Ｑ２（「Ｑ１又はＱ２」）が通知される。
【００９９】
通知条件判定部１２３０は、受信したユーザ情報が通知条件Ｑ１に合致する度に、通知する条件にＱ３を含めるか否かを判定する確率判定を、乱数を使用して行うことができる。或いは他の方法として、現在の通知が何度目の通知かに依存するように、通知する条件にＱ３を含めるか否かを予め決めておいてもよい。この方法では、例えば、通知の一回おき（例えば奇数回）に、通知する条件にＱ３が含まれるように決めておけばよい。
【０１００】
次に図１６，図１７とともに、実施例２の場合に、図１０に示される仲介サーバ２００の条件通知組み合わせ生成部２６５によって実行される、条件通知組み合わせテーブル２４０の作成方法について説明を行う。尚、実施例２の場合、条件通知組み合わせ生成部２６５は先ず、実施例１について図１３とともに上述した処理と同様の処理を行う。そして図１３のステップＳ８の判定結果がＮＯとなると、図１７のステップＳ２１に移行する。
【０１０１】
図１６は、図１０に示される平均該当者数及び平均通知回数比較テーブル２４５（以下単に比較テーブル２４５と称する）の構成の例を示す。図１６中、各行（エントリ）は、図１５同様、通知条件毎に設けられる。一列目の「通知条件」の欄には図１５同様、通知条件の識別子が格納される。２列目の「元平均該当者数」の欄には、一列目の欄に格納された通知条件に該当するユーザ数につき、条件通知組み合わせ生成部２６５が算出した通知時の平均該当者数が格納される。３列目の「元平均通知回数」の欄には、一列目の欄に格納された通知条件について条件通知組み合わせ生成部２６５が算出した一定時間の平均通知回数が格納される。但し３列目の「元平均通知回数」の欄に格納される平均通知回数は、受信されたユーザ情報が１列目の通知条件に合致した際にサービサ３００に通知される回数に係るもののみである。したがって３列目の「元平均通知回数」の欄に格納される平均通知回数は、１列目の通知条件が、受信されたユーザ情報が他の通知条件に合致した際に組み合わせ条件として同時にサービサ３００に通知される回数を含まない。
【０１０２】
４列目の「組み合わせ条件」の欄には、図１５の２列目同様、受信されたユーザ情報が１列目の通知条件に合致した場合にイベント通知部１２２０がサービサ３００に対し同時に通知する他の条件（ダミー条件）の識別子（場合により通知確率が付される）が格納される。
【０１０３】
図１６中、５列目の「通知時の平均該当者数」の欄には、一列目の通知条件がイベント通知部１２２０によってサービサ３００に通知される際に、同時に通知される３列目の組み合わせ条件も含めた両方の条件についての平均該当者数の和が格納される。すなわち、「通知時の平均該当者数」の欄には、一列目の通知条件と４列目の組み合わせ条件との夫々の平均該当者数の和が格納される。例えば１行目のエントリの場合、通知条件Ｑ１の平均該当者数は上記エントリの２行目に格納された元平均該当者数ｎ１である。他方組み合わせ条件Ｑ２の平均該当者数は、通知条件Ｑ２に対応する２行目のエントリの元平均該当者数の欄に格納された元平均該当者数ｎ２である。したがって通知条件Ｑ１に対応する１行目のエントリの「通知時の平均該当者数」の欄には、ｎ１＋ｎ２が格納される。尚、実施例２の場合、「通知時の平均該当者数」の欄に格納する数値として、通知確率が付された組み合わせ条件Ｑ３については、特に考慮しない。しかしながらこの例に限られず、通知確率が付された組み合わせ条件Ｑ３についても、考慮しても良い。
【０１０４】
図１６中、６列目の「一定時間の平均通知回数」の欄には、一列目の通知条件がイベント通知部１２２０によってサービサ３００に通知される回数に係る平均通知回数が格納される。すなわち「一定時間の平均通知回数」の欄には、一列目の通知条件と、一列目の通知条件が組み合わせ条件として格納された他のエントリが存在した場合、他のエントリの通知条件との夫々の平均通知回数（場合により通知確率が乗ぜられる）の和が格納される。例えば１行目のエントリの場合、通知条件Ｑ１の平均該当者数は上記エントリの２行目に格納された元平均通知回数ｍ１である。他方一列目の通知条件Ｑ１が組み合わせ条件として追加された他のエントリとして、通知条件Ｑ３に対応する３行目のエントリ及び通知条件Ｑ２に対応する２行目のエントリが存在する。そして通知条件Ｑ２に対応する２行目のエントリでは、通知条件Ｑ１が７５％の通知確率で組み合わせ条件に追加されている。通知条件Ｑ３に対応する３行目のエントリの元平均通知回数はｍ３であり、通知条件Ｑ２に対応する２行目のエントリの元平均通知回数はｍ２である。したがって通知条件Ｑ１に対応する１行目のエントリの「一定時間の平均通知回数」の欄には、ｍ１＋ｍ３＋ｍ２×０．７５が格納される。
【０１０５】
すなわち通知条件Ｑ１に対応する１行目のエントリの場合、通知条件Ｑ１は、受信されたユーザ情報が通知条件Ｑ１に合致した際に加え、受信されたユーザ情報が通知条件Ｑ３に合致した際に組み合わせ条件として合致した条件Ｑ３と同時にサービサ３００に通知される。更に、通知条件Ｑ１は、受信されたユーザ情報が通知条件Ｑ２に合致した際に組み合わせ条件として、７５％の確率で、合致した条件Ｑ２と同時にサービサ３００に通知される。したがって通知条件Ｑ１の一定時間の平均通知回数は、条件Ｑ１の元平均通知回数ｍ１と条件Ｑ３の元平均通知回数ｍ３と条件Ｑ２の元平均通知回数に通知確率０．７５を乗じて得た数の和であるｍ１＋ｍ３＋ｍ２×０．７５として得られる。よって通知条件Ｑ１の「一定時間の平均通知回数」の欄には、条件Ｑ１の元平均通知回数ｍ１と条件Ｑ３の元平均通知回数ｍ３との和であるｍ１＋ｍ３＋ｍ２×０．７５が格納される。
【０１０６】
図１７は、条件通知組み合わせ生成部２６５が比較テーブル２４５を用いて条件組み合わせテーブル２４０を生成する処理の流れのうち、後半の処理の流れを示すフローチャートである。条件通知組み合わせ生成部２６５が比較テーブル２４５を用いて条件組み合わせテーブル２４０を生成する処理の流れのうち、前半の処理の流れは、図１３とともに上述した実施例１における処理と同様であり、重複する説明を省略する。尚、図１７中、平均通知回数の平準化の割合の閾値ｐは、０〜１の範囲の任意の数とされ、例えば０．８とされる。
【０１０７】
図１７中、ステップＳ２１にて、同一のサービサ３００によって登録された全ての通知条件の各々につき、「一定時間の平均通知回数」を算出し、更に、算出した「一定時間の平均通知回数」の最大値Ｍｍａｘを抽出する。次にステップＳ２２にて、同一のサービサ３００によって登録された全ての通知条件中、算出された「一定時間の平均通知回数」ｍｘが、Ｍｍａｘにｐを乗じて得た値以下となる通知条件Ｑｘが存在するか否かを判定する。算出された「一定時間の平均通知回数」ｍｘがＭｍａｘにｐを乗じて得た値以下となる通知条件Ｑｘが存在しない場合（ステップＳ２２  ＮＯ），処理を終了する。他方、算出された「一定時間の平均通知回数」ｍｘがＭｍａｘにｐを乗じて得た値以下となる通知条件Ｑｘが存在する場合（ステップＳ２２  ＹＥＳ），ステップＳ２４に移行する。
【０１０８】
ステップＳ２４では、同一のサービサ３００によって登録された全ての通知条件中、上記算出された「一定時間の平均通知回数」ｍｘがＭｍａｘにｐを乗じて得た値以下となる通知条件Ｑｘを抽出する。そして抽出した通知条件Ｑｘのうち、通知条件Ｑｘを１個、選択（選択方法は任意でよい）し、ステップＳ２５に移行する。ステップＳ２５では、Ｍｍａｘにｐを乗じて得た値からｍｘを引いた値を算出し、算出した値Ｍｍａｘ×ｐ−ｍｘ（差分）を超える元平均通知回数を有する通知条件の中から、Ｑｘを組み合わせ条件として加える相手方の通知条件Ｑｉをランダムに抽出する（ステップＳ２５  ＹＥＳ）。上記Ｍｍａｘ×ｐ−ｍｘを超える元平均通知回数を有する通知条件が処理対象の通知条件に含まれない場合（ステップＳ２５  ＮＯ），ステップＳ２９に移行する。
【０１０９】
ステップＳ２９では、Ｑｘを組み合わせ条件として加える相手方の通知条件として、夫々の元平均通知回数ｍｉ〜ｍｊの和がＭｍａｘ×ｐ−ｍｘを超える通知条件Ｑｉ〜Ｑｊの組み合わせをランダムに選択する。
【０１１０】
ステップＳ２５でＭｍａｘ×ｐ−ｍｘ（差分）を超える元平均通知回数を有する通知条件Ｑｉが、Ｑｘを組み合わせ条件に加える相手方の通知条件として抽出できた場合（ステップＳ２５  ＹＥＳ）、ステップＳ４６に移行する。ステップＳ４６では、Ｑｉに対しＱｘを組み合わせ条件として加える通知確率ｑを決定する。具体的には、Ｍｍａｘにｐを乗じて得た値からｍｘを引いて得た値をｍｉで除して得た値（Ｍｍａｘ×ｐ−ｍｘ）／ｍｉと、Ｍｍａｘからｍｘを引いて得た値をｍｉで除して得た値（Ｍｍａｘ−ｍｘ）／ｍｉとの間の範囲の値を通知確率ｑとしてランダムに求める。すなわち、（Ｍｍａｘ×ｐ−ｍｘ）／ｍｉ〜（Ｍｍａｘ−ｍｘ）／ｍｉの範囲の値を通知確率ｑとしてランダムに求める。これは、通知条件Ｑｉに、組み合わせ条件Ｑｘを通知確率ｑで追加すると、Ｑｘの「一定時間の平均通知回数」は、ｍｉにｑを乗じて得た値、増加し、ｍｘ＋ｍｉ×ｑとなる。この値ｍｘ＋ｍｉ×ｑが、Ｍｍａｘ×ｐ〜Ｍｍａｘの範囲に収まるように、通知確率ｑを求める。その結果、通知確率は（Ｍｍａｘ×ｐ−ｍｘ）／ｍｉ〜（Ｍｍａｘ−ｍｘ）／ｍｉの範囲とすればよいこととなる。
【０１１１】
次にステップＳ４７で、通知条件Ｑｉの組み合わせ条件として、通知条件Ｑｘを通知確率ｑで加える。次にステップＳ４８で、通知条件Ｑｘの「一定時間の平均通知回数」に、通知条件Ｑｉの元平均通知回数ｍｘに、ｍｉに通知確率ｑを乗じて得た値ｍｉ×ｑを加えた後、ステップＳ２２に戻る。
【０１１２】
ステップＳ２９の処理後にステップＳ５０にて、（Ｍｍａｘ×ｐ−ｍｘ）／（ｍｉ＋...＋ｍｊ）〜（Ｍｍａｘ−ｍｘ）／（ｍｉ＋...＋ｍｊ）の範囲で通知確率ｑをランダムに求める。これは、通知条件Ｑｉ〜Ｑｊの各々に、組み合わせ条件Ｑｘを通知確率ｑで追加すると、Ｑｘの「一定時間の平均通知回数」は、ｍｉ〜ｍｊの和にｑを乗じて得た値、増加し、ｍｘ＋（ｍｉ＋...＋ｍｊ）×ｑとなる。この値ｍｘ＋（ｍｉ＋...＋ｍｊ）×ｑがＭｍａｘ×ｐ〜Ｍｍａｘの範囲に収まるように、通知確率ｑを求める。その結果、通知確率は（Ｍｍａｘ×ｐ−ｍｘ）／（ｍｉ＋...＋ｍｊ）〜（Ｍｍａｘ−ｍｘ）／（ｍｉ＋...＋ｍｊ）の範囲とすればよいこととなる。
【０１１３】
次にステップＳ５１で、ステップＳ２９で抽出した通知条件Ｑｉ〜Ｑｊの各々の組み合わせ条件として、通知条件Ｑｘを通知確率ｑで追加する。そしてステップＳ５２で、通知条件Ｑｘの「一定時間の平均通知回数」として、通知条件Ｑｘの元平均通知回数ｍｘに、通知条件Ｑｉ〜Ｑｊの夫々の元平均該当者数ｍｉ〜ｍｊの和に通知確率ｑを乗じて得た値を加えた後、ステップＳ２２に戻る。
【０１１４】
ステップＳ２２以降の処理は上述の通りである。このようにして、ステップＳ２２の判定結果がＮＯとなる迄、ステップＳ２２、Ｓ２４〜Ｓ４８或いはステップＳ２２、２４〜Ｓ５２の処理を繰り返す。すなわち、全ての処理対象の通知条件Ｑｘにつき、「一定時間の平均通知回数」が最大値Ｍｍａｘにｐを乗じて得た値以上になる迄、上記処理を繰り返す。全ての処理対象の通知条件Ｑｘにつき、「一定時間の平均通知回数」が最大値Ｍｍａｘにｐを乗じて得た値以上になると（ステップＳ２２  ＮＯ），処理を終了する（ステップＳ２３）。
【０１１５】
尚、実施例２の場合、上記の如く、通知確率ｑは、処理対象の通知条件Ｑｘの「一定時間の平均通知回数」がＭｍａｘ×ｐ〜Ｍｍａｘの範囲に収まるように、求められる（ステップＳ４６，Ｓ５０）。その結果実施例１の場合と異なり、処理後のＱｘがＭｍａｘを超えることがない。したがって実施例１に係る図１４のステップＳ３３及びステップＳ３４（最大値Ｍｍａｘの更新）が不要となる。その結果、図１７のフローチャートにおけるループ回数（ステップＳ２２、Ｓ２４〜Ｓ４８或いはステップＳ２２、２４〜Ｓ５２の処理を繰り返す回数）を削減することが可能となる。更に、ループ回数の削減の結果、組み合わせ条件の追加の回数を削減できる。その結果、仲介サーバ２００からサービサ３００に対する通知の回数が減り、仲介サーバ２００からの通知の回数に応じてサービサ３００が配信のために作成するコンテンツの数も減り、コンテンツ作成負荷が減る。
【０１１６】
以上の実施例１，２を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
サービス提供装置がユーザに対しサービスの提供を行うユーザの条件を、前記提供するサービス毎に登録する登録部と、
ユーザに係る情報が、前記登録部が前記提供するサービス毎に登録した前記条件に合致するか否かを判定する条件判定部と、
前記条件判定部が合致の判定をした場合、前記サービス提供装置に対し、前記合致に係る条件を通知すると共に、組み合わせ条件も併せて通知する通知部と、
前記サービス提供装置から前記通知に係る条件に対応するサービスの提供を受けて前記サービスを前記合致に係るユーザに提供するサービス提供部と、
前記条件毎に、前記通知部が前記条件を前記サービス提供装置に通知する際に前記条件に合致するユーザ数の平均値と、前記条件の通知回数の時間平均値とを求め、前記組み合わせ条件を追加した場合の前記合致に係る条件に合致するユーザ数の平均値が所定値以上となり且つ前記組み合わせ条件を追加した場合の前記合致に係る条件毎の通知回数の時間平均値が所定の範囲に収まるように前記組み合わせ条件を求める組み合わせ取得部と、を有することを特徴とする情報処理装置。
（付記２）
前記組み合わせ取得部は、前記組み合わせ条件を求める際、一の条件の通知回数の時間平均値が、前記条件毎の前記通知回数の時間平均値の最大値に対する所定の割合に満たない場合、他の条件の通知回数の時間平均値が前記所定の割合に満たない不足分を超え且つ最小の値を有する前記他の条件を前記サービス提供装置に通知する際に併せて通知する組み合わせ条件として前記一の条件を加えることを特徴とする、付記１に記載の情報処理装置。
（付記３）
前記組み合わせ取得部は、一の条件を、他の条件を通知する際に前記組み合わせ条件として通知する確率を、前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として追加した場合の前記一の条件の通知回数の時間平均値が前記条件毎の前記通知回数の時間平均値の最大値を超えないように決定し、
前記通知部は、前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として通知する際には、前記一の条件を前記組み合わせ条件として通知する確率が前記決定に係る確率となるように、前記一の条件を前記組み合わせ条件として通知するか否かを決定することを特徴とする、付記１に記載の情報処理装置。
（付記４）
コンピュータによって実行されるサービス仲介方法であって、
ユーザに係る情報が、提供するサービス毎に登録された夫々の前記条件に合致するか否かを判定し、
合致と判定された場合、サービス提供装置に対し、前記合致に係る条件を通知すると共に、組み合わせ条件も併せて通知し、
前記サービス提供装置から前記通知に係る条件に対応するサービスの提供を受けて前記サービスを前記合致に係るユーザに提供し、
前記条件毎に、前記条件を前記サービス提供装置に通知する際に前記条件に合致するユーザの人数の平均値と、前記条件の通知回数の時間平均値とを求め、前記組み合わせ条件を追加した場合の前記合致に係る条件に合致するユーザの人数の平均値が所定値以上となり且つ前記組み合わせ条件を追加した場合の前記合致に係る条件毎の通知回数の時間平均値が所定の範囲に収まるように前記組み合わせ条件を求めることを特徴とするサービス仲介方法。
（付記５）
前記組み合わせ条件を求める際、一の条件の通知回数の時間平均値が前記合致に係る条件毎の通知回数の時間平均値の最大値に対する所定の割合に満たない場合、他の条件の通知回数の時間平均値が前記所定の割合に満たない不足分を超え且つ最小の値を有する前記他の条件に対する組み合わせ条件として前記一の条件を追加することを特徴とする、付記４に記載のサービス仲介方法。
（付記６）
前記組み合わせ条件を求める際、一の条件を、他の条件を通知する際に前記組み合わせ条件として通知する確率を、前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として追加した場合の前記一の条件の通知回数の時間平均値が前記条件毎の前記通知回数の時間平均値の最大値を超えないように決定し、
前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として通知する際には、前記一の条件を前記組み合わせ条件として通知する確率が前記決定に係る確率となるように、前記一の条件を前記組み合わせ条件として通知するか否かを決定することを特徴とする、付記４に記載のサービス仲介方法。
（付記７）
ユーザに係る情報が、提供するサービス毎に登録された夫々の前記条件に合致するか否かを判定し、
合致と判定された場合、サービス提供装置に対し、前記合致に係る条件を通知すると共に、組み合わせ条件も併せて通知し、
前記サービス提供装置から前記通知に係る条件に対応するサービスの提供を受けて前記サービスを前記合致に係るユーザに提供し、
前記条件毎に、前記条件を前記サービス提供装置に通知する際に前記条件に合致するユーザの人数の平均値と、前記条件の通知回数の時間平均値とを求め、前記組み合わせ条件を追加した場合の前記合致に係る条件に合致するユーザの人数の平均値が所定値以上となり且つ前記組み合わせ条件を追加した場合の前記合致に係る条件毎の前記通知回数の時間平均値が所定の範囲に収まるように前記組み合わせ条件を求める処理をコンピュータに実行させるプログラム。
（付記８）
前記組み合わせ条件を求める際、一の条件の通知回数の時間平均値が前記条件毎の前記通知回数の時間平均値の最大値に対する所定の割合に満たない場合、他の条件の通知回数の時間平均値が前記所定の割合に満たない不足分を超え且つ最小の値を有する前記他の条件に対し、前記一の条件を前記組み合わせ条件として追加することを特徴とする、付記７に記載のプログラム。
（付記９）
前記組み合わせ条件を求める際、一の条件を、他の条件を通知する際に前記組み合わせ条件として通知する確率を、前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として追加した場合の前記一の条件の通知回数の時間平均値が前記条件毎の前記通知回数の時間平均値の最大値を超えないように決定し、
前記一の条件を、前記他の条件を通知する際に前記組み合わせ条件として通知する際には、前記一の条件を前記組み合わせ条件として通知する確率が前記決定に係る確率となるように、前記一の条件を前記組み合わせ条件として通知するか否かを決定することを特徴とする、付記７に記載のプログラム。
【符号の説明】
【０１１７】
１００  ユーザ、ユーザ端末
２００  仲介業者、仲介サーバ（仲介装置）
２４０  条件通知組み合わせテーブル
２４５  平均該当者及び平均通知回数比較テーブル
２５５  ユーザ情報統計作成部
２６０  ユーザ情報・統計
２６５  条件通知組み合わせ生成部
３００  サービス提供者、サービサ（サービス提供装置）
【図１Ａ】
0005609631.tif 000002
【図１Ｂ】
0005609631.tif 000003
【図２】
0005609631.tif 000004
【図３】
0005609631.tif 000005
【図４Ａ】
0005609631.tif 000006
【図４Ｂ】
0005609631.tif 000007
【図５Ａ】
0005609631.tif 000008
【図５Ｂ】
0005609631.tif 000009
【図６】
0005609631.tif 000010
【図７】
0005609631.tif 000011
【図８】
0005609631.tif 000012
【図９】
0005609631.tif 000013
【図１０】
0005609631.tif 000014
【図１１】
0005609631.tif 000015
【図１２】
0005609631.tif 000016
【図１３】
0005609631.tif 000017
【図１４】
0005609631.tif 000018
【図１５】
0005609631.tif 000019
【図１６】
0005609631.tif 000020
【図１７】
0005609631.tif 000021