JP2007058610A - データ配信制御システム - Google Patents

Abstract

【課題】従来技術では、動的な環境下のユーザに対し、リアルタイムで、ユーザを効率的に選別して広告を配信する方法については考慮されていない。
【解決手段】
ユーザの所有する端末と、データを送受信する複数の計算機と、前記計算機及び前記端末との間で送受信されるデータの制御を行う制御装置が接続される本システムでは、前記端末は、前記制御装置に第一のデータを送信し、前記制御装置は、前記第一のデータを受信すると、前記第一のデータ及び前記制御装置に事前登録されている属性情報を含む第二のデータに基づき、前記複数の計算機の中から、前記端末に関連する計算機を選択し、前記制御装置は、前記選択した計算機に対して、前記端末の位置情報及び前記ユーザの属性情報を含む第三のデータを送信し、前記計算機は、前記第三のデータを受信すると、前記端末に対して、第四のデータを送信する。
【選択図】 図１

Description

本発明は、携帯端末を有するユーザに対して広告を配信するシステムに関する。

昨今、一般大衆を対象に大量の広告を行うマス・マーケティングに対し、ユーザ個人の嗜好性や行動特性といったユーザの属性情報に基づいて、個々人に対してより適切なマーケティング活動を行うワントゥーワンマーケティングが知られている（非特許文献１参照）。

一方、携帯電話を用いたサービスとして、実世界で商品を販売している店舗がユーザの存在位置に応じて広告を配信する広告配信サービスが知られている（特許文献１参照）。該サービスは、インターネット等を使った広告配信サービスと比較して、実際の商品の近辺に消費者が存在することから、消費者の消費行動を直接的に促す効果がある。

特開２００２−１８３００７号公報 Cliff Allen, Deborah Kania, Beth Yaeckel 著「Internet World Guide to One-To-One Web Marketing」 John Wiley & Sons Inc出版 １９９８年３月

非特許文献１は、ユーザ個人の属性情報に基づいてマーケティング活動を効率的に行うものであるが、インターネットを使用しているユーザ等、静的な環境下のユーザに対して行うものであって、動的な環境下のユーザに対して行うものではない。ここで、動的な環境とは、ユーザ自身が実世界を移動したりすることによる、状況が変化する環境を示すものとする。

一方、特許文献１は、動的な環境下のユーザに対して、ユーザの存在位置に応じて広告を配信するものであるが、ブロードキャスト的に広告を配信するだけであって、効率的な広告配信を行うものではない。

即ち、動的な環境下のユーザに対し、リアルタイムで、ユーザを効率的に選別して広告を配信する方法については考慮されていないため、広告を配信する側にとっては効率が悪く、広告を受信する側にとっても不要な広告を受信させられる煩わしさがある、という課題がある。

そこで、本発明の目的は、動的な環境下のユーザの中からユーザを効率的に選別して、選別したユーザに対して広告を配信するシステムを実現することにある。

前記課題を解決するために、本発明の望ましい態様の一つは、以下の通りである。

ユーザの所有する端末と、データを送受信する複数の計算機と、前記計算機及び前記端末との間で送受信されるデータの制御を行う制御装置が接続される本システムでは、前記端末は、前記制御装置に第一のデータを送信し、前記制御装置は、前記第一のデータを受信すると、前記第一のデータ及び前記制御装置に事前登録されている属性情報を含む第二のデータに基づき、前記複数の計算機の中から、前記端末に関連する計算機を選択し、前記制御装置は、前記選択した計算機に対して、前記端末の位置情報及び前記ユーザの属性情報を含む第三のデータを送信し、前記計算機は、前記第三のデータを受信すると、前記端末に対して、前記ユーザに呼びかけを行うための第四のデータを送信する。

本発明によれば、動的な環境下のユーザの中からユーザを効率的に選別して、選別したユーザに対して広告を配信するシステムを実現することができる。

以下に、本発明の実施の形態を説明する。

図１は、データ配信制御システムの構成図である。本システムは、携帯端末２と店舗端末３の間で送受信されるデータを制御するデータ配信制御装置（以下、制御装置と略す）１、ユーザが所有する携帯端末２、広告を携帯端末２に配信する店舗が所有する店舗端末３、コンテンツを格納するコンテンツサーバ４、ユーザ登録を行う登録サーバ５、及びこれら構成要素を接続するネットワーク６から構成される。

制御装置１は、ＣＰＵ１１、メモリ１２、キーボードやボタン類やディスプレイなどの入出力インタフェース（以下、Ｉ/Ｆと略す）１３、記憶装置１６との間でデータのバッファリング等の各種仲介処理を行うＩ／Ｏ部１４、ネットワーク６を介して携帯端末２等との間のデータの送受信を行う通信部１５、及びプログラムやデータを格納する記憶装置１６から構成される。

ＣＰＵ１１は、記憶装置１６からメモリ１２にプログラムを読み込んで、各種機能を計算機上に実現する。

記憶装置１６は、各種プログラム１０１〜１１６、各種データベース（以下、ＤＢと略す）１１７〜１２０を格納する。各種ＤＢは、ＤＢＭＳ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）により管理されてもよい。

尚、１０１〜１１６を備えた装置をアプリケーションサーバ、各種ＤＢ１１７〜１２０を備えた装置をＤＢサーバのように、各種プログラムを管理する装置とＤＢを管理する装置を別々に構成してもよい。また、記憶装置１６は、一般に磁気ディスクであるが、光ディスク等、他の記憶媒体を用いたものであってもよい。また、コンテンツサーバ４及び登録サーバ５の機能を制御装置１が有する構成としてもよい。更に、複数の店舗端末３の中の１つが、代表して、制御装置１の機能を有する構成としてもよい。

以下、制御装置１が携帯端末２に配信するデータとして、テレビ等の「番組表」を例示して説明するが、配信データの適用例としては番組表のみに限定されず、日時と該日時に配信を希望するコンテンツとからなる組み合わせを表示するものであればいずれも採用できる。また、制御装置１が番組表を作成した時点で、携帯端末２に対して、番組表の情報に含まれる配信希望時刻情報（ユーザがいつコンテンツを配信してほしいかを示す時刻に関する情報）を送信しているものとする。即ち、携帯端末２は、配信希望時刻情報を備えているものとする。

配信データ格納部１０１は、ユーザに指定された番組表を、携帯端末２毎に番組表ＤＢ１１７へ格納するためのプログラムである。

配信処理部１０２は、携帯端末２から、コンテンツの配信要求（以下、配信要求と略す）を受信した場合、番組表に列挙された配信希望コンテンツを、携帯端末２に配信するためのプログラムである。

ユーザＩＤ受信部１０３は、携帯端末２から、配信希望時刻情報に基づく時刻に送信されたユーザＩＤを配信要求として受信するためのプログラムである。ここで、ユーザＩＤとは、ユーザを一意に識別するための情報であるが、携帯端末２を識別するための情報（例えば、携帯電話機の固有ＩＤや電話番号等）であってもよい。この場合、制御装置１でユーザＩＤを割り振ってもよい。本実施例では、ユーザと携帯端末は一対一に対応するものとして説明するが、それに限定されるものではない。また、制御装置１と携帯端末２との間で、時刻と番組表を管理することにより、制御装置−携帯端末間の送受信データ量の低減、携帯端末の負荷軽減、制御装置のメンテナンスの容易化、といった効果である。

配信コンテンツ特定部１０４は、ユーザＩＤに基づき、番組表ＤＢ１１７から該当するユーザに対応付けた番組表を検索し、該番組表の配信希望時刻に設定されているコンテンツを特定するためのプログラムである。この場合、特定されたコンテンツは、配信処理部１０２により、コンテンツＤＢ１１８より抽出され、該当携帯端末２に送信される。

希望時刻受信部１０５は、携帯端末２から、配信希望時刻情報を配信要求として受信するためのプログラムである。

実配信時刻算出部１０６は、実配信時刻を算出するためのプログラムである。実配信時刻については後述する。この場合、配信処理部１１１により、配信要求に基づくコンテンツがコンテンツＤＢ１１８より抽出され、該コンテンツを該実配信時刻において該当携帯端末２に送信される。

位置対応コンテンツ配信部１０７は、携帯端末２から該携帯端末２の現在位置情報を取得し、この現在位置情報に基づいて、コンテンツＤＢ１１８において位置情報に紐付けされているコンテンツを特定して、これを該携帯端末２に配信するためのプログラムである。また、本プログラム１０７により、予め携帯端末２から受信しているユーザの登録住所または一時所在地をユーザＤＢ１１９より抽出し、該登録住所または一時所在地に基づいて、コンテンツＤＢ１１８におけるコンテンツを特定し、これを該携帯端末２に配信することもできる。また、コンテンツに含まれる地図データの示す地域内に所在する各種施設（施設は店舗を含む。本実施例では、以下、店舗と称する）の広告情報を、店舗毎の広告情報が格納された広告ＤＢ１２０より抽出し、該広告情報を地図データ上に表示されるよう携帯端末２に配信することもできる。また、広告情報の取得要求コマンドが対応付けされたアイコンを、地図データにおける該当店舗の所在地上に表示されるよう携帯端末２に配信することもできる。また、所定範囲の所在地にまとまって存在する店舗群について各店舗の広告情報の取得要求コマンドが対応付けされた１つの代表アイコンを、地図データにおける前記所在地上に表示されるよう携帯端末２に配信することもできる。また、広告情報として、店舗端末３より予め受信していた該当店舗内の空席情報または商品・サービスの割引販売情報の少なくともいずれかを含ませて、携帯端末２に配信することもできる。更に、予め携帯端末２から受信していたユーザの属性をユーザＤＢ１１９より抽出し、該属性情報をキーとして、該地図データの示す地域内に所在する各種店舗が特定のユーザを発見するために予めユーザＤＢ１１９に登録してある属性情報を使って、特定の店舗を選択することもできる。

選択広告配信部１０８は、広告ＤＢ１２０に格納されている登録審査済みの広告情報リストを、店舗端末３に提示し、広告情報リスト中からの配信希望の広告情報の選択事象を、店舗端末３より受信して、該当広告情報を広告ＤＢ１２０より抽出し、これを携帯端末２に配信するためのプログラムである。また、携帯端末２のディスプレイ（以下、特記しない限り、ディスプレイとは携帯端末２のディスプレイを指す）に表示されるカーソルの一定方向への一定時間の移動指示を、携帯端末２から受信して、地図データ上に複数配置された各アイコンへの選択表示を一定方向へ一定時間連続移動させるプログラムを備えた地図データを、位置対応コンテンツ配信部１０７により携帯端末２に配信することもできる。また、コンテンツＤＢ１１８に格納されたコンテンツは、ディスプレイの一端から他端まで、コンテンツの一端が所定時間内に到達する速度以上でスクロールさせるプログラムと、ディスプレイの他端にコンテンツの一端が到達した後にコンテンツの他端が所定時間以上で、ディスプレイの他端に到達する速度以内でスクロールさせるプログラムとを備えてもよい。

差込広告配信部１０９は、店舗毎の広告情報が格納された広告ＤＢ１２０において、配信希望コンテンツの属性に紐付けされている属性を備える広告情報を検索し、ここで検索した広告情報を、配信希望コンテンツ間への差込広告として配信するためのプログラムである。

ログ保存・管理部１１０は、各携帯端末２のコンテンツや広告情報等の閲覧履歴について、これをユーザＤＢ１１９等に蓄積するためのプログラムである。ここで蓄積される閲覧履歴は、例えば、過去のコンテンツや広告情報の閲覧傾向や、ユーザの属性などに基づいて、制御装置１がコンテンツの利用提案をユーザ側に行ったり、コンテンツの間に差し込む広告情報の選定を行う際に利用することができる。

ログレポート部１１１は、閲覧履歴の情報を適当なフォームにはめ込むなどしてログレポートを生成し、これを該当携帯端末２や広告主たる各種店舗の店舗端末３に送信するためのプログラムである。

一時ユーザＩＤ生成／配信部１１２は、位置対応コンテンツ配信部１０７により、特定のユーザを選択した場合に、該ユーザと所定時間内または所定エリア内で通信を行う為に必要となる一時的なＩＤを生成し、該ＩＤと共に店舗端末３にユーザＤＢ１１９に登録してある属性情報と適合した携帯端末２を発見したことを店舗端末３に通知するためのプログラムである。ここでは、ユーザと店舗に直接メッセージの交換をさせる場合に、店舗側にユーザのアドレス等が開示されないように、ユーザが一時的かつ限定的に利用するアドレスを生成し、該アドレスを、必要とする店舗端末３に配信する。

メッセージチェック部１１３は、ユーザと店舗に直接メッセージの交換をさせる場合に、店舗側からユーザに対して配信されるメッセージの内容に不適切な記載がないか等についてチェックを行うためのプログラムである。

属性キーワードマッチング部１１４は、ユーザが本システムを利用する場合に、ユーザの位置情報と共に送られてきたキーワードまたはユーザＤＢ１１９の属性キーワードのレコードに記録されている属性キーワードと、広告ＤＢ１２０の要求属性キーワードのレコードに記録されたキーワードと一致するか否かをチェックし、一致した場合には、携帯端末２に一致した店舗を通知し、店舗端末３に対しては、ユーザの出現を通知するためのプログラムである。

属性キーワード入力Ｉ/Ｆ提供部１１５は、店舗が誘客する為に必要とするユーザの属性キーワードを入力するためのプログラムである。

自動応答部１１６は、店舗の誘客を自動的に行うためのプログラムである。

番組表ＤＢ１１７は、制御装置１が携帯端末２から受信し、配信希望コンテンツと配信希望時刻との指定に関する情報（以下、配信希望情報と称する）に基づいて、所定期間内に番組表を携帯端末２毎に生成して、これを格納するＤＢである。例えばユーザＩＤをキーとして、番組表ＩＤ、番組表の内容（配信時間帯、配信するコンテンツのＩＤ）といった情報を関連付けたレコードの集合体である（図２（a）参照）。

コンテンツＤＢ１１８は、携帯端末２に配信するコンテンツを格納するＤＢである。例えばコンテンツＩＤをキーとして、コンテンツ種類、対応付けた位置情報、利用料金の区分といった情報を関連付けたレコードの集合体である（図２（b）参照）。尚、コンテンツの種類毎に分けて構成してもよい。

ユーザＤＢ１１９は、ユーザの属性情報を格納するＤＢである。例えばユーザＩＤをキーとして、性別、年齢、コンテンツ等の閲覧履歴、住所（現在位置）、旅行先や出張先といった一時住所、ユーザの嗜好等を示すユーザ個別の属性キーワードなどの情報を関連付けたレコードの集合体である（図２（c）参照）。

広告ＤＢ１２０は、コンテンツの間に差込広告される広告情報や、コンテンツとしての地図データ上に挿入される広告情報等を格納するＤＢである。例えば広告ＩＤをキーとして、広告元の店舗、広告内容（例：図中下線の文節は店舗端末３からの指示で他の文言に選択変更可能）、対応付けた位置情報、対応付けたコンテンツの属性といった情報を関連付けたレコードの集合体である。また、該店舗がどのような属性を有するユーザを誘客したいかを示すキーワードを記録した、要求属性キーワードと当該キーワードとマッチングした場合に自動応答するメッセージの内容を記載したレコードも含んでいる（図２（d）参照）。

以上のような制御装置１の中の構成は、記憶装置１６内のデータが異なる他は、後述する携帯端末２、店舗端末３、コンテンツサーバ４、及び登録サーバ５についても同様である。また、コンテンツサーバ４及び登録サーバ５については、ＣＰＵ等のハードウェアの図示は省略した。以下、各装置について、制御装置１と異なる部分について説明する。

携帯端末２の記憶装置２６には、各種プログラム（２０１〜２０６）が格納される。

配信希望送信部２０１は、配信希望情報を制御装置１に送信するためのプログラムである。

受信処理部２０２は、制御装置１が番組表に従って送信してきた配信希望コンテンツを受信し、ディスプレイに表示するためのプログラムである。

選択移動処理部２０３は、制御装置１より配信されたコンテンツが、各種店舗の広告情報の取得要求コマンドに紐付いたアイコンが該当店舗の所在地上に表示された地図データであった場合、ディスプレイに表示されるカーソルの一定方向への一定時間の移動指示をＩ/Ｆ２３より受け付けて、地図データ上に複数配置された各アイコンへの選択表示を一定方向へ一定時間連続移動させるためのプログラムである。尚、Ｉ/Ｆ２３は、ボタン類やディスプレイなどの入出力インタフェースを指すが、先述のように、ディスプレイについては、「ディスプレイ」と記載し、その他のインタフェースについては、「Ｉ/Ｆ２３」と記載する。

スクロール速度制御部２０４は、制御装置１より配信されたコンテンツをディスプレイの一端から他端までコンテンツの一端が所定時間内に到達する速度以上でスクロールさせ、ディスプレイの他端にコンテンツの一端が到達した後にコンテンツの他端が所定時間以上でディスプレイの他端に到達する速度以内でスクロールさせるためのプログラムである。

位置情報取得部２０５は、ＧＰＳ装置２８などの現在位置情報取得装置から現在位置情報を取得して、これを制御装置１に送信するためのプログラムである。

Ｗｅｂブラウザ２０６は、制御装置１がＷｅｂサーバであって、ｈｔｔｐリクエスト／レスポンスに基づくデータ通信を行うと想定したときの、制御装置１にアクセスするためのプログラムである。これにより、コンテンツ等のディスプレイへの出力を担うことができる。またＷｅｂブラウザ２０６は、店舗端末３からネットワーク６を介して直接に、または制御装置１を経由して、Ｉ/Ｆ２３を介してメッセージを受信し、また店舗端末３に対して、直接的にリアルタイムのメッセージを交換する、リアルタイムメッセージ送受信機能を備えている。また、Ｗｅｂブラウザ２０６は、ユーザが本サービスを利用中であっても、店舗側からのメッセージの到着を受信し、必要に応じてアイコンを点滅させ、該アイコンに連動させて到着したメッセージを表示させる、店舗対応イベントリスナー機能を備えている。更に、Ｗｅｂブラウザ２０６は、制御装置１の、属性キーワード入力Ｉ/Ｆ提供部１１５を介して、該店舗が誘客する為に必要とするユーザの属性キーワードを入力し、該属性キーワードを広告データＤＢ１１９の要求属性キーワードのレコードに記憶させるための、属性キーワード登録用インタフェースの機能を備えている。

ＩＣカード２７は、カードの内部にアンテナを持ち、外部の端末が発信する弱い電波を利用してデータを送受信するカードである。該機能は社員証等の特定個人情報の開示、電子チケットや小額電子決済などを可能とする。

ユーザに訴求を行う店舗端末３の記憶装置３６には、各種プログラム（３０１〜３０３）が格納される。

空席情報送信部３０１は、該店舗における空席状況についての情報入力をＩ/Ｆ３３より受け付けて、これを制御装置１に送信するためのプログラムである。これにより、例えば、携帯端末２に提供される該店舗の広告情報に現在の空席状況を付加することができる。

Ｗｅｂブラウザ３０２は、先述の２０６と同様である。これにより、差込広告の対象となる広告情報の選択や、広告情報の登録審査要求等に伴う各種データ出力を担うことができる。また、リアルタイムメッセージ送受信機能や、新たなユーザの発見の際やユーザ側からのメッセージの到着を受信した際のユーザ対応イベントリスナー機能を備える点も同様である。

自動応答部３０３は、店舗の誘客を自動的に行うためのプログラムである。

コンテンツサーバ４は、放送業者、映画会社、出版社などといった各種コンテンツの供給業者が使用する端末であり、該端末の記憶装置には、配信アプリケーション４１が格納される。配信アプリケーション４１は、制御装置１へのコンテンツ配信処理を実行するためのプログラムである。尚、制御装置１が格納している各種コンテンツは、上記供給業者から入手されるため、制御装置１は、コンテンツサーバ４とネットワーク６を介して接続されているものとする。

登録サーバ５は、制御装置１が携帯端末２にコンテンツ配信を行うため、それに先立つ会員登録処理を行うための端末であり、該端末の記憶装置に格納される登録処理アプリケーション５１により、該処理が実行される。

尚、制御装置１、携帯端末２、店舗端末３、コンテンツサーバ４、及び登録サーバ５におけるプログラムの各機能を、ハードウェアとして実現してもよい。また、以上に説明したプログラムは、各装置が常時備えていてもよいし、各装置がネットワーク６等を通じて他の装置から入手して利用してもよい。

また、ネットワーク６は、インターネット、ＬＡＮ、ＡＴＭ回線や専用回線、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、電灯線ネットワーク、無線ネットワーク、公衆回線網、携帯電話網、シリアル・インタフェース通信線、アドホックネットワークなど、様々なネットワークを採用することが出来る。また、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）など仮想専用ネットワーク技術を用いれば、インターネットを採用した際にセキュリティ性を高めた通信を確立できる。尚、シリアル・インタフェースは、単一の信号線を用いて１ビットずつ順次データを送るシリアル伝送で、外部機器と接続するためのインタフェースを指し、通信方式としてはＲＳ−２３２Ｃ、ＲＳ−４２２、ＩｒＤＡ、ＵＳＢ、ＩＥＥＥ１３９４、ファイバ・チャネルなどが想定できる。

以下、データ配信方法の手順について、説明する。尚、ここでは、制御装置１がＷｅｂサーバ機能を備えており、携帯端末２や店舗端末３とはｈｔｔｐリクエスト／レスポンスの処理を経てデータ通信を行っているものとする。従って、この場合、携帯端末２は、制御装置１へＷｅｂブラウザ２０６を実行してアクセスを行う。

図３は、データ配信方法の実施手順例１を示すフロー図である。まず、データ配信方法のメインフローについて述べる。尚、ユーザはユーザ会員登録（図１０参照）を行い、既に制御装置１が提供するサービスの会員になっているものとする。制御装置１は、該登録処理により、ユーザ属性情報（性別、年齢、誕生日、職業、所在地域等）を取得し、ユーザＤＢ１１９に格納し、該属性情報を携帯端末２へ配信するコンテンツや広告情報の選択やユーザ側への推薦処理に際して、コンテンツ等との属性マッチング処理のベースとする。

携帯端末２は、コンテンツの配信に先立ち、番組表の生成を制御装置１に対して行う必要があるため、配信希望情報を、例えば制御装置１が提供する番組表の作成サイト等において入力する（図１１参照）。ここでは、コンテンツのジャンルとして、政治、経済、スポーツ、芸能、社会といった各種ニュースや写真などが提示され（画面１１０１）、または、該時刻にユーザがいる場所等の地図（画面１１０３）が、それぞれ配信時間をプルダウンメニュー等で設定できるようになっている（画面１１０４）。

また、画面１１０４の地図データの提示に関しては、該時刻にユーザがいる場所の地図の他、予め指定した目印（ランドマーク）や前回の地図の選択、該地図の内容を表示する方法の選択、及び該地図の中で検索したい情報の指定（例えば、予めキーワードで指定）などの、付帯的条件を付与することができるようになっている。

以上のような設定を行った後、携帯端末２は、これら配信希望情報を制御装置１に送信する（Ｓ３００）。制御装置１では、これを受信し（Ｓ３０１）、所定期間内に番組表をユーザ毎に生成し、番組表ＤＢ１１７に格納し、実配信時刻を算出し、番組表のデータのうち、実配信時刻については携帯端末２に送信する（Ｓ３０２）。一方、携帯端末２はこの実配信時刻を受信し、メモリ２２等に格納しておく（Ｓ３０３）。

ここで、実配信時刻とは、配信希望時刻情報に基づき算出される、実際にデータ配信を行う時刻を示す。例えば、所定数以上のユーザが１２：００に配信を希望した場合、ネットワークのトラフィックが該時間帯に集中し、通信（配信）が困難となる。そこで、乱数を用いて所定時刻範囲内で（例えば、希望時刻の前後１０分、希望時刻を含む前１０分）トラフィックが分散されるように、または、配信要求を受信した順序に基づき、実配信時刻を算出する。尚、この算出処理は、実配信時刻算出部１０６により実行される。

この際、制御装置１は、ユーザから配信時刻が希望時刻よりずれることを許容する旨の情報、実配信時刻及び配信希望時刻情報等をユーザＤＢ１１９に記憶しておいてもよい。また、実配信時刻はユーザから所定時刻範囲内で優先順位を付した複数の希望時刻を受信しておき、これに基づいて定めてもよい。更に、Ｓ３０２では、実配信時刻を算出するのではなく、配信を要求することとなるＳ３０４を実行する時刻を上記と同様に算出してもよい。このようにして算出された配信時刻を携帯端末２で有することで、制御装置１の処理負荷を低減することができる。

次に、携帯端末２は、配信希望時刻情報に基づく時刻に、配信要求（ユーザＩＤを含む）を制御装置１に送信する（Ｓ３０４）。一方、制御装置１では、配信要求を受信し（Ｓ３０５）、この中のユーザＩＤに基づき、番組表ＤＢ１１７から該ユーザに対応付けられた番組表を検索する（Ｓ３０６）。

次に、制御装置１は、検索された番組表において配信希望時刻に設定されているコンテンツを特定し、これをコンテンツＤＢ１１８より抽出する（Ｓ３０７）。制御装置１は、抽出したコンテンツを該携帯端末２に送信し（Ｓ３０８）、処理を終了する。

一方、携帯端末２は、制御装置１から送信されたコンテンツを受信し、ディスプレイに表示する（Ｓ３０９）。

図１５は、実配信時刻の算出処理（図３のＳ３０２）のフロー図である。図１５の処理は、図３のＳ３０１の処理後に行われるが、携帯端末２が実配信時刻の情報要求を、例えばフィードバックリクエストとして制御装置１側に送信したことを契機として開始されてもよい（Ｓ１５００）。制御装置１では該リクエストを受信し、これに含まれているユーザＩＤ、制御装置１へのアクセスに要するパスワード、ならびに配信希望時刻情報を取得する（Ｓ１５０１）。

制御装置１は、フィードバックリクエストに基づく情報を利用し、番組表ＤＢ１１７において、配信希望時刻情報と同時刻帯の配信を希望している他の配信要求を検索・特定する（Ｓ１５０２）。ここで特定した配信要求は、同時刻帯において重複していることとなる。そこで、これら配信要求の数が所定数以上か否かの判定を行う（Ｓ１５０３）。

重複する配信要求が所定数より多い場合（例えば１０分間に６配信（つまり２分間隔）が所定数であるのに、７配信以上の配信要求が既になされているか、携帯端末２からの配信要求が７配信目になる事態に至った場合）、所定配信間隔を維持できるか否かの判定を行う（Ｓ１５０４）。

維持可能な場合、制御装置１は、実配信時刻を変更する処理を行い（Ｓ１５０５）、その後、処理をＳ１５０４に戻し、再度、配信間隔を維持できるか否かを判定する。Ｓ１５０４及びＳ１５０５の処理は、配信間隔を維持できると判定できるまで繰り返される。そして、配信間隔を維持できるようになれば、Ｓ１５０６に移行する。Ｓ１５０３で重複する配信要求が所定数以下の場合も、Ｓ１５０６に移行する。尚、実配信時刻を変更する処理とは、例えば、あるユーザが１４時に配信を希望しており、配信要求が所定数より多い場合、配信時刻を前後にずらす（例えば、１３時３０分〜１４時３０分までの任意の時刻）処理である。

ここで制御装置１は、例えば、各携帯端末２からの配信要求の受付順に応じ、所定配信間隔をあけて各配信要求に応じた実配信時刻を配置する配信スケジュールを決定する。或いは、配信要求毎に乱数を発生させ、この乱数の所定桁等の大小等に応じて、所定配信間隔をあけて各配信要求に応じた実配信時刻を配置する配信スケジュールを決定する。或いは、乱数の所定桁等を時刻の数値と見なすことで、各配信要求の実配信時刻を決定する。いずれにしても制御装置１は、所定配信間隔を保ってコンテンツ配信を行えるよう実配信時刻を決定する手順であれば、いずれを採用してもよい。

制御装置１は、決定した実配信時刻を、該当携帯端末２に送信し（Ｓ１５０７）、処理を終了する。尚、制御装置１は、この実配信時刻を、番組表ＤＢ１１７において配信時刻として設定する。一方、携帯端末２は、実配信時刻を制御装置１より受信して、これをメモリ２２等に格納する（Ｓ１５０８）。

こうして決定された実配信時刻は、携帯端末２より制御装置１に対して配信要求として送信される。その後、制御装置１は、配信処理部１０２により、実配信時刻を含む配信要求に基づき、該当コンテンツをコンテンツＤＢ１１８より抽出し、実配信時刻において該当携帯端末２に送信する。

尚、番組表を視認可能にしたイメージ例としては、新聞や雑誌等に絵掲載されているテレビやラジオなどの番組欄を想定すればよい。１つのカラムには配信時刻が列挙され、その時刻の配信コンテンツの名称等が併記されるという表示スタイルである。また、実際の運用例としては、図７に示すように、ユーザが“出勤”、“出先”、“帰宅”、“就寝前”といった時間帯毎に、配信コンテンツを設定しており、そのコンテンツは画像で最大４枚から１番組が構成されている例がある。この場合、各番組の最後には差込広告がスポット広告として配置されている。また、無料番組の場合は、前記４枚の画像のうち１枚はスポンサー広告の画像とされる。但し、このような運用例は一例であって、コンテンツや広告情報のサイズ、ネットワーク６や制御装置１のスペックや稼働状況といった各種条件に応じて、制御装置１側で任意に変更できる。尚、図示したスポット広告は、設定番組数によらず所定数配信してもよいし、設定番組数に基づいた数としてもよい。また、図７の例は１２：００前後に配信される番組の例を示している。ここでは、左端から右端までが一連の番組として配信され、スクロールとして次回の配信まで繰り返される。

更に、アイコン選択の遷移を以下のような操作で行うことも可能である。尚、下記に示す上（↑）等は図１４の例に従う。

・上（↑）：画面上で１つ上方に表示されているアイコンに遷移。尚、最上方に表示されたアイコンの場合、最下方に表示されたアイコンに遷移。

・下（↓）：画面上で１つ下方に表示されているアイコンに遷移。尚、最下方に表示されたアイコンの場合、最上方に表示されたアイコンに遷移。

次に、携帯端末２がコンテンツの配信を受けてそれをどのように出力するのか、図１２の画面遷移例にそって説明する。携帯端末２は、メインメニューの画面１２０１において、コンテンツの配信開始指示を行ったとする。この時、携帯端末２は制御装置１とデータ通信を行って、自身のユーザＩＤと配信時刻の情報とを制御装置１に送信する（画面１２０２）。制御装置１側では対応するコンテンツを抽出し、携帯端末２に配信する（画面１２０４）。或いは、画面１２０１において、地図データの配信指示がなされていた場合、画面１２０３に示すような地図データがディスプレイに表示されている。この地図データは、コンテンツＤＢ１１８に格納されており、携帯端末２からの、位置情報や所定店舗等の入力に応じて、抽出・表示される。この画面１２０３において、例えば「コンテンツ」の配信開始指示ボタンが押下された場合でも、制御装置１は画面１２０２への遷移を実行する。

また、ディスプレイにコンテンツが表示される際、制御装置１は、“ＰＡＵＳＥ”や“詳細”といった指示ボタンの押下により、コンテンツの詳細情報（画面１２０５）やスクロール等の一時停止処理を実行する。尚、詳細情報の記載内容に連絡先のＵＲＬ、メールアドレスや電話番号等が含まれる場合、制御装置１は、“Ｍａｉｌ ｔｏ”や“Ｗｅｂ ｔｏ”、“Ｐｈｏｎｅ ｔｏ”といったコマンドリンクを表示し処理の実行指示を受付可能とする。

図４は、データ配信方法の実施手順例２を示すフロー図である。コンテンツの配信と共に、地図データや広告情報の配信を、携帯端末２の位置情報等にあわせて効率的かつ確実に実行する処理について説明する。まず、携帯端末２は、ＧＰＳ装置２８等から現在位置情報を取得する。或いは、Ｉ/Ｆ２３より旅行先や出張先等の一時所在地に関するユーザの入力を受け付けて位置情報を取得する。携帯端末２は、こうした位置情報を制御装置１に送信する（Ｓ４００）。尚、図１３に示すように、ＧＰＳ情報などの代わりに、所在地が登録済みの目印（駅、官庁、高層ビルなど）の指定をＩ/Ｆ２３にて受け付けることで、これを現在位置情報として扱うことが可能である。

一方、制御装置１は、携帯端末２より送信されてきた位置情報を受信し（Ｓ４０１）、これが現在位置を示す現在位置情報か一時所在地を示す一時位置情報かを、ユーザＤＢ１１９における登録住所等と比較することで判定し、該判定に応じてコンテンツを特定する（Ｓ４０２）。現在位置情報の場合、コンテンツＤＢ１１８において位置情報に紐付けされているコンテンツを特定する。一時位置情報の場合、ユーザの登録住所または一時所在地をユーザＤＢ１１９より抽出し、抽出した情報に基づいて、コンテンツＤＢ１１８におけるコンテンツの特定をする。

次に、制御装置１は、特定されたコンテンツが、地図データであるか判定し（Ｓ４０３）、地図データでない場合には、特定したコンテンツを、該当携帯端末２に配信し（Ｓ４０９）、処理を終了する。尚、Ｓ４０３はなくともよい。即ち、地図データについてはユーザの指定がなくとも表示させるように制御してもよい。

他方、特定したコンテンツが、地図データである場合には、制御装置１は、地図データの示す地域内に所在する各種店舗の広告情報を、広告ＤＢ１２０より抽出する（Ｓ４０４）。この処理は、コンテンツの“位置情報”の欄のデータにマッチングする位置情報が紐付いた広告情報を、広告ＤＢ１２０で検索することで実行される。

次に、制御装置１は、店舗端末３より予め受信していた情報（空席情報、商品やサービスの割引情報等）を、抽出した広告情報を用いて訴求を行う店舗に対応するものについて、広告情報に付加する（Ｓ４０５）。

次に、制御装置１は、抽出した広告情報に、対応するアイコンがあるか否かを判定する（Ｓ４０６）。このアイコンは広告情報の取得要求コマンドが対応付けされたイメージデータであり、例えば広告ＤＢ１２０において、広告情報毎に対応付けされて格納する状況を想定できる。従って、制御装置１は、広告ＤＢ１２０において広告情報に紐付いたアイコンの有無を検証すれば、Ｓ４０６の処理を実行できる。

Ｓ４０６において、対応アイコンが無い場合、広告情報をそのまま地図データ上に表示する処理を行って（Ｓ４０７）、携帯端末２に配信し（Ｓ４０９）、処理を終了する。

他方、対応アイコンがある場合、広告情報の取得要求コマンドが対応付けされたアイコンを、地図データにおける該当店舗の所在地上に表示する処理を行って（Ｓ４１０）、データを携帯端末２に配信し（Ｓ４０９）、処理を終了する。尚、Ｓ４１０には以下の処理も含まれる。
（１）代表アイコンで代表されている複数のアイコンそれぞれ（少なくともその一部）に対応する情報を、画面の所定位置に表示する。
（２）代表アイコンで代表されている複数のアイコンそれぞれ（少なくともその一部）を、個々に表示する。この際、地図の縮尺を変更するか、アイコン自身の大きさを変更してアイコンの重なりがより少なくするよう表示してもよい。

尚、アイコンの他の例として、所定範囲の所在地にまとまって存在する店舗群について各店舗の広告情報の取得要求コマンドが対応付けされた１つの代表アイコンが想定できる。この場合も、制御装置１は、地図データにおける所在地上にこの代表アイコンを表示する処理を行って携帯端末２に配信する。

他方、携帯端末２では、制御装置１から配信されてきた地図データとアイコンや代表アイコンとが一体となったデータを受信し、これをディスプレイに表示する（Ｓ４１０）。この時の画面イメージとしては、例えば図１３の画面１３０６に示すものとなる。

尚、図２（ｃ）のユーザＤＢ１１９における閲覧履歴の情報に、地図データの閲覧履歴を含めてもよい。このような場合、閲覧履歴に含まれる地図データの属性（例：地図データの示す該当地域、地図データが連続的に閲覧されている場合の移動経路など）を制御装置１が認識し、この属性に対応するコンテンツ、地図データ、及び広告情報の少なくともいずれかを、コンテンツＤＢ１１８や広告ＤＢ１２０などから抽出し、これを携帯端末２に配信する処理を実行してもよい。

図５は、データ配信方法の実施手順例３を示すフロー図である。ここで、コンテンツに付加される広告情報の差し替えや修正の処理について説明する。まず、店舗端末３から、自店に関する広告の差し替え又は一部修正の要求が、制御装置１に送信される（Ｓ５００）。制御装置１はこれを受信し（Ｓ５０１）、広告ＤＢ１２０に格納されている登録審査済みの広告情報リストを生成し、これを、店舗端末３に送信する（Ｓ５０２）。

この広告情報リストは、例えば広告の倫理規定等に照らして、広告として衆目に広く伝達しても問題ないとシステム運営者側で判断された広告情報の一覧である。従って、店舗等の広告主は、どのような広告情報でも配信できる訳ではない。一方、リアルタイムで膨大な数の広告情報を迅速に審査するのは困難なため、例えば店舗端末３毎に、予め複数の広告情報を審査して審査に合格したものをリストとして制御装置１が保持しておく。

例えば、図２（ｄ）で示したように、広告ＤＢ１２０の広告内容欄において、下線が引かれた文節については、例えば該当店舗の商品一覧や割引率一覧のプルダウンメニューにリンクさせて、広告情報の文節を構成する商品名や割引率（登録審査に合格している）を店舗端末３側で自由に選択できるものとする。このような処理を制御装置１が実行することで、広告効果の実績や天候等に合わせて店舗側が考える広告戦略をダイレクトに受け付けられることとなる。

店舗端末３は、制御装置１より送信された広告情報リストを受信し（Ｓ５０３）、店舗端末３の使用者等により、該リストから選択されたデータを、制御装置１に送信する（Ｓ５０４）。

制御装置１は、該選択されたデータを店舗端末３より受信し（Ｓ５０５）、該当する広告情報を広告ＤＢ１２０より抽出する（Ｓ５０６）。そして、制御装置１は、ここで抽出した広告情報と属性がマッチングするコンテンツを選択し、両者の配信時刻を確認するなどの配信準備を行う（Ｓ５０７）。配信準備が整った場合、制御装置１は、広告情報を携帯端末２に配信し（Ｓ５０８）、処理を終了する。

他方、携帯端末２は、広告情報を受信し、ディスプレイに表示する（Ｓ５０９）。

図６は、データ配信方法の実施手順例５を示すフロー図である。携帯端末２において表示されるコンテンツの操作性向上に関する技術について説明する。まず、制御装置１から携帯端末２に配信されたコンテンツが、各種店舗の広告情報の取得要求コマンドに紐付いたアイコンが該当店舗の所在地上に表示された地図データであった場合を想定する。この時、携帯端末２では、ディスプレイに表示されたカーソルの一定方向への一定時間の移動指示をＩ/Ｆ２３より受け付ける（Ｓ７００）。

次に、携帯端末２は、地図データ上に複数配置された各アイコン、代表アイコンへの選択表示を一定方向へ一定時間連続移動させる（Ｓ７０１）。移動指示が終了するまでこの処理は繰り返される。移動指示が終了後、処理を終了する。

具体的には、例えば図１４に示すように、携帯端末２のカーソルキー（矢印キーや所定の数字キー）が一定方向（前後左右）に対応しており、これらいずれかのカーソルキーの押下時間（一定時間）にあわせて、ディスプレイにおけるアイコン、代表アイコンの選択が連続的に移行していく。連続的な移行は、例えば“下向き”のカーソルキーが押下されている間、ディスプレイ上部に表示されているアイコンから、（左右位置を問わず）最短距離にあるアイコンに向けて、アイコン選択が遷移していく。また、アイコンが表示されている座標を判別し、所定の位置に近いものから順にアイコン選択を遷移するようにしてもよい。例えば、通常の表示において画面左上から右下に向かって遷移するように遷移してもよい。

尚、地図データ自体が、ディスプレイに表示されたカーソルの一定方向への一定時間の移動指示を携帯端末２より受信して、地図データ上に複数配置された各アイコン、代表アイコンへの選択表示を一定方向へ一定時間連続移動させるプログラムを備えていてもよい。

図８は、コンテンツのスクロール制御のイメージを示す図である。ディスプレイに自動表示されるコンテンツの視認性向上の技術について説明する。コンテンツは、一例として、制御装置１から携帯端末２に配信された後、ディスプレイにおいて一定方向にスクロールして表示される。この時、スクロールの速度が速すぎればユーザとして閲覧しにくいコンテンツとなるし、逆にスクロールの速度が遅すぎると処理の冗長さに耐えられず、コンテンツの閲覧を取りやめることも考えられる。

そこで、携帯端末２は、制御装置１より配信されたコンテンツを、ディスプレイの一端から他端までコンテンツの一端が所定時間内に到達する速度以上でスクロールさせる（画面８００、８０１）。また、ディスプレイの他端にコンテンツの一端が到達した後にコンテンツ他端が所定時間以上でディスプレイの他端に到達する速度以内でスクロールさせる（画面８０２、８０３）。

尚、コンテンツ自体が、ディスプレイの一端から他端まで、自身のコンテンツの一端が所定時間内に到達する速度以上でスクロールするプログラムと、ディスプレイの他端にコンテンツの一端が到達した後にコンテンツ他端が所定時間以上でディスプレイの他端に到達する速度以内でスクロールさせるプログラムとを備えていてもよい。

図９は、データ配信方法の実施手順例５を示すフロー図である。尚、広告情報のうち文字の部分を、以下、テロップと称する。

携帯端末２は、まず、画像とテロップをスクロール表示する処理を、通常スクロール速度のもとで開始する（Ｓ９００〜Ｓ９０２）。そして、画像の左端のＸ座標（画像のドット数に対応）が“０”であるか否か判定する（Ｓ９０２）。該判定で、画像の左端のＸ座標が、ディスプレイの画面上座標における“０”でない場合、処理をＳ９０１に戻す。一方、画像の左端のＸ座標が、ディスプレイの画面上座標における“０”である場合（画像の左端がディスプレイの他端まで到達している場合）、携帯端末２は、画像のスクロール速度を低速にする処理（以下、該処理をスロースクロールと称する）を行う（Ｓ９０３）。

このスロースクロールは、画像の右端のＸ座標が、“０”となるまで継続し（Ｓ９０４）、“０”となれば、スクロールを停止する（Ｓ９０５）。他方、テロップのスクロールは、テロップの右端のＸ座標が“０”となれば、つまり、テロップがスクロールアウトしたら、画像についてもスクロールアウトし（Ｓ９０６）、処理を終了する。こうして画像とテロップのスクロールアウト後、携帯端末２は、次の画像とテロップをスクロールインする。

尚、スクロールの速度の具体例としては、画像の通常スクロール：２０ｄｏｔ／３０ｍｓ（画面が左端にスクロールされるまで）、画像のスロースクロール：１ｄｏｔ／３０ｍｓ（画面が左端にスクロールされた後）、テロップのスクロール速度：３ｄｏｔ／３０ｍｓといったものを想定できる。この場合、携帯端末２は、３０ｍｓ単位に、コンテンツ類の描画処理を実施する。

図１６は、店舗側で誘客したいユーザの属性を登録するための、要求属性キーワードを登録する処理を示すフロー図であり、図１９は、店舗端末３の一つとして携帯電話を用いた場合のディスプレイの表示を図示したものであるが、店舗端末３はＰＣ等でもよい。

まず、店舗端末３は、制御装置１に対して、属性キーワードの登録要求を行う（Ｓ１６００）。制御装置１は、店舗端末３から該要求を受信すると（Ｓ１６０１）、属性キーワード入力Ｉ/Ｆ提供部１１５より、メニュー画面を店舗端末３に送信する（Ｓ１６０２）。店舗端末３は該メニューのトップページを表示し（Ｓ１６０３）、店舗端末３の利用者によりデータが入力されると、入力情報を制御装置１に送信する（Ｓ１６０４）。尚、入力方法として、キーワード入力及び文章（キーワードが混在したメッセージ）入力がある（図１９の画面１９０２参照）。また、キーワード入力が選択された場合については画面１９０４に、文章入力が選択された場合については画面１９０３に示している。制御装置１は、キーワード入力があった場合には、ユーザＤＢ１１９の要求属性キーワード（図２（d）参照）のレコードにキーワードを登録し、文章入力があった場合には、属性キーワード入力Ｉ/Ｆ提供部１１５にて、文章を単語に切り分けて、前記と同様の処理を行う（Ｓ１６０５）。

尚、文章を単語に切り分ける処理、及び単語による検索技術としては、全文検索システムＮａｍａｚｕが著名なソフトウェアとして知られている（ｈｔｔｐ：／／ｗｗｗ．ｎａｍａｚｕ．ｏｒｇ／ｉｎｄｅｘ．ｈｔｍｌ．ｅｎ）。

ここで、実世界における効率的な誘客方法である「呼びかけを契機とするインタラクティブなリアルタイムメッセージ交換」について説明する。
（１）「呼びかけを契機とするインタラクティブなリアルタイムメッセージ交換」とは、店舗の店員とその店舗の近辺に存在する自然人たる潜在顧客（ユーザ）との間で生じるコミュニケーションの一態様であり、「呼びかけ」の内容は、例えば、自店舗が保有する商品のアピールや、その商品が安価であることを知らしめるものである。
（２）「呼びかけ」は、店舗の店員がユーザの属性に応じて選択的に行う。例えば、化粧品の購買は女性に対して行い、玩具であれば子供に対して行う。
（３）「呼びかけ」は、限定的な場所で一時的に実施され、該ユーザの物品の購入によって、または、ユーザが該店舗付近から離脱することによって完了し、完了後は店員とユーザは完全な他人の関係に復帰する。従って、該ユーザの個人情報が開示されることはない。
（４）「呼びかけ」に対して、ユーザもまた、選択的に応答する。ユーザは、「呼びかけ」に含まれる広告の内容を瞬時に理解し、応答するか否かを判断する。該内容が、ユーザにとって興味を引くものであれば、先述のように、限定的な場所で一時的に実施されるコミュニケーションに対して協力的な態度をとる。例えば、該内容に関する質問等が行われ、店舗の店員から、該商品等の具体的な情報を引き出す、または該商品の価格に関する交渉などが実施される。

一般的にインターネット等を使ったクライアントーサーバ型の仮想店舗においては、ユーザが、店舗側のＵＲＬ等をＷｅｂブラウザに入力するか、あるいはリンクされた情報を経由されて、店舗側サーバにアクセスすることによって、店舗へ訪問することはできるが、その逆は成り立たない。

もっとも、予め取得した大量のメールアドレスを使って、一斉に店舗側サーバへのアクセスを促す方法（例えば、スパムメール）があるが、これは、店舗側にとっては比較的簡単に広告を行うというメリットがある反面、ユーザ側にとっては、不要な広告を受信させられ、読まされ、削除しなければならないという煩わしさがあり、ユーザからその店舗への積極的な反感を買い、高効率の誘客効果という観点からも望ましいものではない。

また、スパムメール方式は、店舗側のタイミングで送信され、ユーザ側のタイミングで読まれるものであるので、限定的な場所で一時的に実施されるような「呼びかけ」型の誘客を行うことはできない。

更に、「呼びかけ」は、現行のインターネットでは、店舗側がユーザの選択を行うことはできない。仮にそれが可能であったとしても、ユーザが該「呼びかけ」に対して応答を行うか否かの選択を行うことができない。

尚、現行のインターネットの仮想店舗では、匿名性を保持したまま、該仮想店舗に訪問することは可能であるが、店舗側とユーザが実際にコミュニケーションを行う場合には、匿名性を維持したままで行うことは困難である。なぜなら、インターネットでは、ユーザ情報を特定するメールアドレス等のＩＤを開示することで、コミュニケーションが成立するからである。

一旦ＩＤを開示してしまったら、「呼びかけを契機とするインタラクティブなリアルタイムメッセージ交換」が完了した後においても、このＩＤは使用され、店舗側とユーザが完全な他人の関係に復帰することを妨げる可能性がある。

例えば、インターネットの仮想店舗に関して、電子メール等で商品情報等の問い合わせをする場合、問い合わせに対する返事を貰うためには、電子メールアドレス等の自分のＩＤを開示しなければならない。ところが一旦、そのようなＩＤが開示されてしまうと、このＩＤが第三者に渡って、商品情報等の問い合わせ以外の目的（例えば、不要な広告メール送信）に使用されることがある。このような問題に対して、両者の匿名の状態を保ったまま、メールの送受信を可能にする電子メールサーバシステムを提供する方法（特開２００４−３４２１２７号公報）が開示されている。該発明では、送信時の送信元アドレスを秘匿指定する手段を備え、電子メールサーバでは、送信元アドレスが秘匿指定されたメールを判定して、送信元アドレスを匿名アドレスに変換し、さらにその匿名アドレスで返信されてきた応答メールに関しては、該匿名アドレスを、秘匿指定された送信元アドレスに復元する。しかし、ユーザを特定させることなくメッセージ交換を行わせることは可能であるが、秘匿アドレス自体が使用を繰り返されることによって、個人を特定する機能が発揮されてしまう可能性がある。

匿名メールは、個人情報を完全に隠蔽した状態で情報の送達を行うために用いられるが、その匿名ＩＤが連続して使用されることにより、匿名メールの使用者の属性が推認される可能性がある。例え、その本人の氏名や年齢が不明だったとしても、その嗜好が推定されれば、その匿名メールの本人にスパムメールが送信される可能性は否定できない。

一方、店舗側の立場に立てば、それぞれのユーザに個別の広告メール等を配布したいサービス提供者や店舗にとって、匿名性の有無に関わらず個人を特定できないことには、効率的な広告メールが送信できない。

しかし、本実施例では、個人情報を開示することなく、店舗側が、実世界を歩行する動的な環境下のユーザと、コミュニケーションを行うこともできる。

図１７は、携帯端末２と店舗端末３の間で「呼びかけ」を契機としてユーザと店舗が直接メッセージ交換を行う処理を行うフロー図である。

図２０及び図２１は、携帯端末２を用いた場合のディスプレイの表示を、図２２は、携帯端末２を店舗端末３として使用した場合のディスプレイの表示を図示したものである。

携帯端末２が、図２０の画面２００１〜２００３に示すように、携帯端末の位置情報とユーザの属性キーワード（ユーザの属性キーワードはなくてもよい）を制御装置１に送信すると（Ｓ１７００）、制御装置１がそれらの情報を受信（Ｓ１７０１）し、該キーワードを、ユーザＤＢ１１９から抽出（Ｓ１７０２）し、地図データ及びその周辺地域内（図２１（ａ））に所在する店舗の一つを抽出し、属性キーワードマッチング部１１４により、広告ＤＢ１２０から該店舗に紐づけられた要求属性キーワードと比較（Ｓ１７０３）し、キーワードが一致した場合には、一時ユーザＩＤ生成／配信部１１２にてユーザの仮名アドレスを生成し、ユーザの位置情報及び抽出した属性キーワードとともに当該店舗に送信（Ｓ１７０４）し、店舗端末３はそれらの情報を受信する（Ｓ１７０５）。それらの処理を全ての店舗端末３に対して行う（Ｓ１７０６）。キーワードが一致しない場合は、Ｓ１７０４、Ｓ１７０５を経ることなく、Ｓ１７０６に移行する。その後、制御装置１は、該店舗端末３が該ユーザ宛に作成し送信するメッセージを待ち受ける体制に入る。尚、「その周辺」とは、上、下、左、右、左斜上、右斜上、左斜下、右斜下の８方向を示すものとして説明するが、８方向に限定されるものではない。

また、該店舗端末３が該ユーザ宛に作成し送信する（Ｓ１７０６）代わりに、該店舗からの要求に応じて、図２（ｄ）記載の広告ＤＢ１２０に記録されている自動応答メッセージを送信してもよい。例えば、ユーザの属性キーワードが「激辛」の場合は、「ただ今、カレーフェア実施中」という応答メッセージを返信する。このように自動応答メッセージを予め登録しておくことによって、店舗側が店舗端末から個々のユーザに対して応答メッセージを作成する手間を省くことが可能となる。また、Ｓ１７０５、Ｓ１７０６の処理を、店舗端末３の自動応答部３０３で実施してもよい。

更に、店舗側は、該自動応答と手動応答を並行して行ってもよい。例えば、後述するキーワードが完全に一致した場合、マッチングの評価関数の値が高いユーザには、手動応答を行いつつ、それ以外のユーザは自動応答を行うことで、誘客の可能性の高い顧客を優先しつつ、複数の顧客への呼びかけを同時かつ迅速に実施することが可能となる。

尚、該キーワードマッチングに関しては、キーワードの同否によるマッチング手法から、概念検索、類似検索、曖昧検索などについて、（１）Ｉｎｇｗｅｒｓｅｎ，Ｐｅｔｅｒ：Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ Ｉｎｔｅｒａｃｔｉｏｎ， Ｌｏｎｄｏｎ， Ｔａｙｌｏｒ Ｇｒａｈａｍ Ｐｕｂｌｉｓｈｉｎｇ（１９９３）、（２）Ｓａｌｔｏｎ， Ｇｅｒａｌｄ： Ａｕｔｏｍａｔｉｃ Ｔｅｘｔ Ｐｒｏｃｅｓｓｉｎｇ， Ｍａｓｓａｃｈｕｓｅｔｔｓ， Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ ｐｕｂｌｉｓｈｉｎｇ ｃｏｍｐａｎｙ（１９８８）、（３）Ｌｕｈｎ， Ｈ．Ｐ．： Ａ Ｓｔａｔｉｓｔｉｃａｌ Ａｐｐｒｏａｃｈ ｔｏ Ｍｅｃｈａｎｉｚｅｄ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｓｅａｒｃｈｉｎｇ ｏｆ Ｌｉｔｅｒａｒｙ Ｉｎｆｏｒｍａｔｉｏｎ， ＩＢＭ Ｊｏｕｒｎａｌ ｏｆ Ｒｅｓｅａｒｃｈ ａｎｄ Ｄｅｖｅｌｏｐｍｅｎｔ， Ｖｏｌ．１， Ｎｏ．４，ｐｐ．３０９−３１７（１９５７））等に記載がある。

図２０の画面２００４は、キーワードによって店舗が選択されて表示されていることを示しており、画面２００５においては、「ａｄｄ “デート”」と入力されることによって、キーワードがさらに追加されて、再検索される。

図２２（ａ）の画面２２０２は、店舗端末３が制御装置１から、Ｓ１７０５の情報を受信した時の表示を示すものであり、店舗端末３側においても、店舗の位置を中心とした地図データ及びその周辺地域内で発見された誘客効果が高いユーザ位置を表示することができる。画面２２０２の矢印アイコンとその中に記載された数字は、店舗の位置を中心とした地図上に一人のユーザがおり、店舗端末３の画面上に表示されていない右斜上、左、または下にそれぞれ一人のユーザが発見されていることを示している。店舗端末３の利用者は、店舗端末３のＩ/Ｆ３３を使って該矢印アイコンにジャンプして、該アイコン上で所定のキーを押下することによって、図２２（ｂ）の画面２２０３に示すように周辺の地図にジャンプすることができる。尚、これらの地図データは、ユーザの指定した地図の縮尺に応じて自由に変更されるようにしてもよい。また、ユーザアイコンの近くに、該ユーザが発見された属性キーワードを仮名ＩＤと共に表示させてもよい。更に、ユーザの位置を表示する方式と併せて、またはその代わりに、対話型のインタフェース（画面２２０２）を用いて、店舗周辺でサービスを利用中のユーザの人数や、該ユーザが発見された属性キーワードを仮名ＩＤと共に表示させてもよい。

更に、キーワードのマッチングの度合いに応じて、ユーザアイコン、店舗アイコンの表示方法を変えてもよい。例えば、キーワードが完全に一致した場合には赤色や点滅等の表示によってアイコンを強調し、概念検索、類似検索、及び曖昧検索等でマッチングした場合には、そのマッチングの評価関数の値に応じて色や表示方法を変えてもよい。

店舗端末３は、Ｓ１７０５で受信したデータに基づいて、ユーザに対するメッセージを作成し、制御装置１に送信する（Ｓ１７０７）。

制御装置１は、店舗端末３からメッセージを受信すると、広告情報の取得要求コマンドが紐付いたアイコン、代表アイコンを地図データの該店舗所在地に表示し、携帯端末２に送信（Ｓ１７０８）し、携帯端末２は該配信情報を受信し表示する（Ｓ１７０９）。尚、店舗端末３からメッセージが再度届いた場合には、制御装置１は該メッセージを携帯端末２に再送信し、携帯端末２は、その配信情報を受信し、再表示する。

図２２の画面２２０１には、店舗端末３がユーザに送信するメッセージ「こんにちは、％Ｅ１００％さん。１０分前にクロワッサンが焼きあがりました。」が表示されている。制御装置１が予め店舗端末３に送信した”Ｅ１００“なるＩＤを、店舗端末３が利用することによってメッセージを作成することができる。このＩＤは、制御装置１の一時ユーザＩＤ生成／配信部１１２で生成され、一定時間後、またはユーザが存在する地域からの離脱によって廃棄されるものである。

図２１の画面２１０１は、店舗端末３からのメッセージが表示されている様子を示している。ユーザは選択されたアイコンの一つを選ぶことによって、そのメッセージを読むことができる。ここに、メッセージ「こんにちは、江端さん。１０分前にクロワッサンが焼きあがりました。」が表示されている。制御装置１のメッセージチェック部１１３は、“Ｅ１００”なるＩＤを実際のユーザ名「江端」に変換する。

尚、図１７では、一つの店舗端末３のメッセージが携帯端末２に転送されているように記載しているが、制御装置１は、複数の店舗端末３からのユーザ宛てのメッセージを一連の処理が終わるまで受信し続け、携帯端末２に転送を続ける。

ユーザは、このメッセージに対して応答することができる。携帯端末２は、店舗端末３とリアルタイムでメッセージを送受信することができ、制御装置１はこのメッセージの転送を司る（Ｓ１７１０乃至Ｓ１７１２）。ここで制御装置１は、店舗端末３から携帯端末２に対して、不適切なメッセージが送信されることがないように、または、ユーザの携帯端末２から店舗に対して、ユーザの個人情報が開示されることがないように、メッセージチェック部１１３にて、メッセージ内容のチェックを行う。

ここで、不適切なメッセージとは、公序良俗に反するもの、ユーザに対して著しく礼を欠いたものなどが含まれる。このようなメッセージは、メッセージチェック部１１３において、予め登録された単語等を用いて、日本語全文検索システム等でリアルタイムにチェックすることで、該メッセージの配信を停止し、問題があった旨のメッセージを付与して、店舗端末３に返送するなどの処理が考えられる。また、必要に応じてシステムの管理人が直接メッセージを読む等の処理を行ってもよい。

一方、携帯端末２から店舗端末３に対するメッセージとしては、個人の電話番号が記載されたメッセージ等がこれに相当するが、ユーザがそのようなチェックを必要としないという意思表示を、ユーザ会員登録時に行った場合は、このような処理を行わなくてもよい。

尚、交換中のメッセージから、属性キーワード入力Ｉ/Ｆ提供部１１５にて、該メッセージの文章を単語に切り分け、ユーザＤＢ１１９にキーワードを登録する（Ｓ１７１３）。このような処理を行うことによって、新たなユーザの属性を取得することが可能となる。

ユーザは、自ら店舗の表示アイコンをアクティブにすることによって、店舗側のメッセージを読み、店舗とメッセージの交換を行うことができるが、店舗がユーザに「呼びかけ」を行っていることを明示するために、図２１の画面２１０１に示すような仕組みを取り入れる。即ち、店舗側からメッセージが届いている場合には、該店舗のアイコンを点滅させ、該店舗のアイコンが携帯端末２のディスプレイに表示されていない場合には、地図データ及びその周辺への移動を行うための矢印アイコンを点滅させることによって、ユーザに「呼びかけ」を行っている店舗を知らせ、該矢印アイコンを操作することによって即座に移動できるようにする。

また、これとは逆に店舗端末３が携帯端末２よりメッセージを受けた場合においては、図２２（ａ）の画面２２０２に示すように、ユーザのアイコンを点滅させ、または、矢印アイコンを点滅させることによって、ユーザアイコンに即座に移動して、店舗に応答しているユーザに即座に返信できるようにする。

携帯端末２と店舗端末３のメッセージのやりとりを行うインタフェースの一態様としては、図２１（ｂ）の画面２１０３、図２２（ｂ）の画面２２０３に表示された、地図上のアイコンと連動したテキストベースのメッセージインタフェースを用いる方法があるが、本インタフェースに限定する理由はない。店舗アイコンの近くに、該店舗が発見された属性キーワードを店舗ＩＤと共に表示させてもよい。上記のユーザの位置を表示する方式と併せて、またはその代わりに、画面２１０２に示すような対話型のインタフェースを用いて、ユーザ周辺でサービスを利用中の店舗数や、当該店舗が発見された属性キーワードを店舗ＩＤと共に表示させてもよい。

ユーザが携帯端末２から本サービスを終了する操作を行うと、携帯端末２は終了する旨のメッセージを制御装置１に送信し（Ｓ１７１４）、制御装置１は、該携帯端末２のユーザに関するＤＢへのアクセス、メッセージ待ち受け処理等を終了するとともに、該メッセージを店舗端末３に転送する（Ｓ１７１５）。店舗端末３は、該メッセージを受信すると（Ｓ１７１６）、店舗端末３の画面から該携帯端末２のユーザのユーザアイコンが消滅する。

図１８は、制御装置１において「呼びかけ」を受けたユーザが実際に利用した店舗を推定するフロー図である。

携帯端末２は、図１７のサービスの開始と同時に自己の場所を一定時間間隔で、メモリ２２に記録を開始する（Ｓ１８００）。例えば、ＧＰＳ装置２８を使って一分単位の緯度・軽度情報を記録してもよい。所定の時間の経過後、例えば図１７のサービスの開始から１時間程度が経過した時点で、時系列に記録した位置情報を制御装置１に転送する（Ｓ１８０１）。または、次に図１７のサービスを開始した時点で転送してもよい。

該時系列の位置情報を受け取った制御装置１は、その時系列方向の位置情報を解析して、携帯端末２のユーザが本サービスを利用することによって、滞留した（立ち寄った）と考えられる一つ以上の店舗を推定する（Ｓ１８０２）。例えば、ある一定時間以上、同一の緯度・経度より移動がなく、かつ、その移動のなかった緯度・経度に、ある店舗が存在した場合には、ユーザが該店舗を利用した蓋然性が高いと推定してもよい。

次に制御装置１は、該店舗に対して、該ユーザが訪問した蓋然性が高いことを、使用した仮名ＩＤと共に通知し（Ｓ１８０３）、店舗端末３はこれを受信（Ｓ１８０４）し、制御装置１は該ユーザに対して、該店舗のアンケート用のＷｅｂサイトのＵＲＬを送信する（Ｓ１８０５）。ここで、店舗端末３は、予め制御装置１に複数のアンケート用のＷｅｂサイトのページを登録しておき、制御装置１またはその管理人によって該ページの審査を受けているものとする。尚、該ページは制御装置１でなく、店舗端末３側で所有してもよい。

制御装置１は、該アンケートを閲覧可能状態にして、該ユーザにアンケートの回答するように要求する旨のメッセージ送信し（Ｓ１８０６）、携帯端末２は、該メッセージを受信して、任意でＷｅｂブラウザからアンケートの回答する（Ｓ１８０７）。尚、該アンケートは、ユーザの意思によって行われ、ユーザは該メッセージを無視できる。

制御装置１は、携帯端末２よりアンケートの回答があった場合には、該店舗が指定したクーポンを送信し（Ｓ１８０８）、携帯端末２はこれを受信する（Ｓ１８０９）。更に、制御装置１は、これまで店舗とユーザが使用してきた仮名ＩＤを抹消する（Ｓ１８１０）。

その後、制御装置１は、アンケート結果を店舗端末３に転送し（Ｓ１８１１）、店舗端末３はこれを受信する（Ｓ１８１２）。尚、該アンケート結果は、ユーザのアンケートを取得したタイミングで転送してもよいし、一定期間後に纏めて転送してもよい。

図２３は、Ｓ１８０６からＳ１８０９までの携帯端末２における動作の一態様である。店舗からユーザに対してアンケートを行う画面が表示された（画面２３０１、２３０２）後、アンケート画面が表示され、ユーザはＩ/Ｆ２３から、このアンケートに回答する（画面２３０３）。回答が終わったら、ユーザはクーポンのダウンロードを行うことができるようになる（画面２３０４）。

尚、上記の事例は、「呼びかけ」を受けたユーザが実際に利用した店舗を推定するのに位置情報を使った方法であるが、実際にはこのような方法を用いず、来店したユーザの携帯端末２に具備されたＩＣカード２７を用いて、来店を直接制御装置１に通知する方法を採用してもよい。

図２４（ａ）は、ユーザが携帯端末２で、または店舗管理人が店舗端末３で、地図をスクロールさせるイメージを示す図である。ここで携帯端末２のユーザが、右上の矢印アイコンを選択すると、矢印アイコンの向いている方向にある地図がスクロールインして表示されることになる。この移動方法に関しては、図８または図９にて説明した方法に準ずるものとする。この操作の前後のイメージとしては、図２１または図２２に示した通りである。尚、地図を移動させた場合に、自分の現在位置（店舗にあっては店舗の位置）を見失わないように、自分の位置が表示される地図データの位置を表示するようにする。例えば図２１（ｂ）においては、左下の矢印アイコンの輪郭が太い線で表示されており、図２２（ｂ）においては、上向きの矢印アイコンの輪郭が太い線で表示されており、ユーザまたは店舗管理人に即座に自分の現在地を確認できるようにする。

図２４（ｂ）は、ユーザが携帯端末２から、ユーザの位置から地図データを高さ方向に表示した図である。ユーザは、図２３（ａ）に示すインタフェースから、「高さ、上」という入力を行うことで、ユーザの現在位置から、ディスプレイにおける、上方向のビューを俯瞰した地図が表示される。図中の星印のアイコンは、ビルの中に収納されている店舗の位置を示すものであり、該アイコンは上記において説明したアイコンと同じ役割を果たすものである。尚、図２３（ｂ）は、店舗端末３の画面上で実施してもよい。

本実施例は、店舗側が、動的な環境下の携帯電話等を有するユーザの中から、ユーザを効率的に選別して、店舗と該選別したユーザとの間で、店舗やユーザの現在位置と対応した一時的かつ限定的なコミュニケーションを、個人情報を開示することなく確立することで高効率かつ高信頼な広告配信を行うとともに、ユーザの嗜好に関する情報を回収することをも実現するものである。

以上、本発明の実施形態について説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

データ配信制御システムの構成図。 （ａ）番組表ＤＢ、（ｂ）コンテンツＤＢ、（ｃ）ユーザＤＢ、（ｄ）広告ＤＢ、の各データ構造例を示す図。 データ配信方法の実施手順例１のフロー図。 データ配信方法の実施手順例２のフロー図。 データ配信方法の実施手順例３のフロー図。 データ配信方法の実施手順例４のフロー図。 番組表の構成イメージを示す図。 コンテンツのスクロール制御のイメージを示す図。 データ配信方法の実施手順例５のフロー図。 画面遷移例１を示す図。 画面遷移例２を示す図。 画面遷移例３を示す図。 画面遷移例４を示す図。 画面遷移例５を示す図。 実配信時刻の算定処理のフロー図。 要求属性キーワードを登録する処理のフロー図。 ユーザと店舗が直接メッセージ交換を行う処理のフロー図。 ユーザが実際に利用した店舗を推定する処理のフロー図。 要求属性キーワードを登録する画面遷移例を示す図。 店舗が選択されて表示されていることを示す画面遷移例を示す図。 携帯端末のディスプレイの様子を示す図。 店舗端末のディスプレイの様子を示す図。 携帯端末におけるアンケート実施の様子を示す図。 携帯端末または店舗端末における地図データの表示を示す図。

符号の説明

１…データ配信制御装置、２…携帯端末、３…店舗端末、４…コンテンツサーバ、５…登録サーバ、６…ネットワーク、１１…ＣＰＵ、１２…メモリ、１３…Ｉ/Ｆ、１４…Ｉ／Ｏ部、１５…通信部、１６…記憶装置

Claims (11)

1. ユーザの所有する端末と、データを送受信する複数の計算機と、前記計算機及び前記端末との間で送受信されるデータの制御を行う制御装置が接続されるシステムにおいて、
   前記端末は、前記制御装置に第一のデータを送信し、
   前記制御装置は、前記第一のデータを受信すると、前記第一のデータ及び前記制御装置に事前登録されている属性情報を含む第二のデータに基づき、前記複数の計算機の中から、前記端末に関連する計算機を選択し、
   前記制御装置は、前記選択した計算機に対して、前記端末の位置情報及び前記ユーザの属性情報を含む第三のデータを送信し、
   前記計算機は、前記第三のデータを受信すると、前記端末に対して、前記ユーザに呼びかけを行うための第四のデータを送信する、データ配信制御システム。
2. 前記第三のデータは、更に、前記端末を一意に示すユーザＩＤを含む、請求項１記載のデータ配信制御システム。
3. 前記ユーザＩＤは、前記制御装置が前記第一のデータを受信した際に生成される、請求項１記載のデータ配信制御システム。
4. 前記ユーザＩＤは、前記計算機が前記第四のデータを送信した後に廃棄する、請求項１記載のデータ配信制御システム。
5. 前記制御装置は、前記端末から、前記端末を一意に示すユーザＩＤを受信し、前記ユーザＩＤを、前記端末が特定できないデータに変換した後、前記特定できないデータを前記第三のデータに含める、請求項１記載のデータ配信制御システム。
6. 前記端末は、前記複数の計算機からデータを受信する、請求項１記載のデータ配信制御システム。
7. 前記端末は、前記第四のデータを受信した際、前記端末上の画面のアイコンを目立たせて表示する、請求項１記載のデータ配信制御システム。
8. 前記制御装置は、複数の端末からデータを受信する、請求項１記載のデータ配信制御システム。
9. 前記端末または前記計算機において、自己の位置を含まない位置情報の表示を行う際に、自己の位置を含む位置情報への復帰手段を提供する、請求項１記載のデータ配信制御システム。
10. 前記端末または前記計算機において、地図の表示を変更する際に、地図データをスライド移動させる、請求項１記載のデータ配信制御システム。
11. 前記端末または前記計算機において、地図の表示を変更する際に、地図データを高さ方向に表示する、請求項１記載のデータ配信制御システム。
    

Images