JP2005157475A - 情報伝達システム - Google Patents

Abstract

【課題】 送信する情報の種別、内容等に応じて効果的に情報伝達を行うことが可能な情報伝達システムを提供する。
【解決手段】 配信サーバは、コンテンツが更新されると、あらかじめ設定された配信ルールに従って配信ホップ数（ＴＴＬ）を設定してコンテンツに付加し、配信データとして送信する（Ｓ１〜Ｓ４）。配信端末では、受信した配信データを蓄積した後、利用者端末の探索を行い、発見された利用者端末に配信データを送信する（Ｓ５〜Ｓ８）。利用者端末は、受信した配信データ内のコンテンツを表示した後、ＴＴＬを１減少させ、ＴＴＬが０でない場合は、他の利用者端末に配信データを送信し、ＴＴＬが０となった場合は、配信データを削除する（Ｓ９〜Ｓ１６）。
【選択図】 図２

Description

本発明は、携帯可能な端末間における無線通信を利用した情報伝達技術に関する。

近年、コンピュータおよびネットワーク技術の発達により、コンピュータ間で様々な情報がやりとりされるようになってきている。特に、最近では、クライアント端末同士がサーバを介さず、直接データのやりとりを行うＰ２Ｐ（Peer To Peer）技術なども利用されている。

しかしながら、上記Ｐ２Ｐ技術では、端末間で単純に情報をやりとりするのみであり、情報伝達を効果的に行うことができない。そこで、本発明は、送信する情報の種別、内容等に応じて効果的に情報伝達を行うことが可能な情報伝達システムを提供することを課題とする。

上記課題を解決するため、本発明では、情報伝達システムを、配信する内容であるコンテンツと、当該コンテンツを配信する際のルールである配信ルールとに基づいて、前記コンテンツを伝達させる範囲を定義したメタデータを作成し、コンテンツとメタデータを含む配信データを作成する配信データ作成手段と、前記配信データを利用者が用いる端末装置である利用者端末に対して無線通信により配信する配信手段と、前記配信手段から受信した配信データ内の前記コンテンツを自身の表示手段に表示させる機能を有すると共に、前記受信した配信データ内に付加されたメタデータの内容に応じて、当該配信データを他の利用者端末に送信する処理を行う機能を有する利用者端末を有する構成としたことを特徴とする。

本発明によれば、配信する内容であるコンテンツと配信ルールに従って、コンテンツの伝達範囲を決定し、配信データとして利用者端末間で伝達させるようにしたので、送信する情報の種別、内容等に応じて効果的に情報伝達を行うことが可能となるという効果を奏する。

以下、本発明の好適な実施形態について、図面を参照して詳細に説明する。
（第１の実施形態）
まず、本発明第１の実施形態として、情報伝達システムをテーマパークにおけるアトラクション（遊技施設）の混雑状況の伝達に利用する場合について説明する。図１は、第１の実施形態による情報伝達システムのシステム構成図である。図１において、１０は配信サーバ、１１はコンテンツ、１２は配信ルール、２０は配信端末、３０は利用者端末である。

配信サーバ１０は、コンテンツの配信処理を行うサーバコンピュータであり、配信すべきデータであるコンテンツ、コンテンツを配信するための規則である配信ルールを記録している。配信サーバ１０は、コンテンツに対して、あらかじめ定められた配信ルールにしたがって、メタデータを付加して配信データを作成し、配信端末２０に送信する機能を有している。ここで、メタデータとはコンテンツの表示制御、配信データの送信制御等を行うための制御データである。配信端末２０は、配信サーバ１０と有線もしくは無線により接続されるとともに、利用者端末３０と無線通信可能に設定された端末装置であり、配信サーバ１０から受信した配信データを利用者端末３０に送信する機能を有している。利用者端末３０は、配信端末２０から無線通信によりデータ受信可能とされているとともに、利用者端末３０相互間で無線通信によりデータ送受信可能とされている端末装置であり、受信した配信データ内のメタデータの内容に応じた表示処理、送信処理を行う機能を有している。利用者端末３０は、携帯電話機、ＰＤＡ（携帯情報端末）等の機器に専用のソフトウェアを搭載することで実現できる。また、配信端末２０と利用者端末３０間、利用者端末３０相互間における無線通信の方式としては、公知の種々のものを適用することができ、特定の方式に限定されないが、ここではＢｌｕｅｔｏｏｔｈ方式を想定して説明する。

続いて、図１に示したシステムの処理動作について図２のフローチャートを用いて説明する。コンテンツとして混雑情報を用いる場合、コンテンツは定期的に更新される（ステップＳ１）。具体的には、アトラクション付近にいる管理者が混雑状況を入力し、コンテンツ１１として配信サーバ１０内に記録する。例えば、ここでは、コンテンツとして混雑情報が１％刻みで記録されているものとする。コンテンツ１１が更新されると、配信サーバ１０は、コンテンツ１１が配信ルール１２に適合しているかどうかを確認する。ここで、配信ルール１２の一例を図３に示す。図３の例では、混雑状況が１００％である場合は、配信しない旨を示しており、９９％以下の場合は、その数値に応じてホップ数を設定することを示している。更新されたコンテンツが配信ルールに合致すると（ステップＳ２）、すなわち、図３の例では、混雑状況が１００％でない場合であると、配信サーバ１０は、配信ルール１２に従って、配信可能なホップ数である配信ホップ数を設定する（ステップＳ３）。具体的には、配信ホップ数（ＴＴＬ：Time To Live）を設定したメタデータを作成することになる。例えば、混雑状況が５０％であった場合には、「ＴＴＬ＝３」としてメタデータに記録されることになる。次に、配信サーバ１０は、コンテンツにメタデータを付加して配信データとして、配信端末２０に送信する（ステップＳ４）。

配信端末２０では、配信データを受信すると（ステップＳ５）、その配信データを蓄積する（ステップＳ６）。具体的には、配信端末２０内部の記憶手段に配信データを記録することになる。配信データが蓄積されたら、配信端末２０は、通信可能な範囲に利用者端末３０が存在するかどうかの探索を行う。この探索の具体的な手法については、周知であり、また、各無線方式により異なるので詳細は省略する。探索の結果、利用者端末３０を発見することができた場合は（ステップＳ７）、配信データを利用者端末３０に送信する（ステップＳ８）。

利用者端末３０では、配信データを受信すると（ステップＳ９）、配信データ内のコンテンツの表示を行う（ステップＳ１０）。すなわち、ここではあるアトラクションの混雑状況が表示されることになる。続いて、メタデータ内のＴＴＬを１だけ減少させる（ステップＳ１１）。ＴＴＬの減少後、ＴＴＬが０でないかどうかの判断を行い（ステップＳ１２）、ＴＴＬが０でない場合は、受信した配信データからコンテンツを抽出して蓄積する（ステップＳ１３）。コンテンツが蓄積されたら、利用者端末３０は、通信可能な範囲に他の利用者端末３０が存在するかどうかの探索を行う。この結果、他の利用者端末３０を発見することができた場合は（ステップＳ１４）、配信データを発見した利用者端末３０に送信する（ステップＳ１５）。利用者端末３０から配信データを受信した他の利用者端末３０もステップＳ９〜ステップＳ１６の処理を行うことになる。一方、ＴＴＬが０となった場合は、上記ステップＳ１３〜ステップＳ１５の処理を行わずに、受信した配信データを削除する（ステップＳ１６）。すなわち、配信端末２０から送信された配信データは、ＴＴＬが０になるまで、利用者端末３０を伝播して行くことになる。

上記の例では、配信データは、ＴＴＬが０になるまで、利用者端末３０間を伝播していくので、ＴＴＬの初期値に応じて伝播する利用者端末数を制御することができる。上記のようなＴＴＬの設定に代えて、配信端末２０が配信した時刻からの経過時間により設定することも可能である。次に、このような場合について図４のフローチャートを用いて説明する。配信サーバ１０における処理は、大部分が図２に示したフローチャートと同じである。そのため、図２のフローチャートと同一の箇所には同一の符号を付して説明を省略する。違いは、まず、ステップＳ３におけるＴＴＬの設定に代えて、有効時間を設定する点である。配信端末２０における処理も、基本的には図２に示したフローチャートと同じである。違いは、ステップＳ１８において、メタデータに配信時刻情報を設定する点である。利用者端末３０における処理も、基本的には図２に示したフローチャートと同じである。違いは、ステップＳ１９において、現在時刻と配信時刻の差を調べ、ステップＳ２０において、その差が有効時間内であるかどうかを判断する点である。ステップＳ１９において利用する現在時刻は、利用者端末３０内で稼動している時刻を利用する。そして、上述のように、この差が有効時間以下であれば、配信データを利用者端末３０に蓄積し（ステップＳ１３）、有効時間より大きければ、配信データを削除する（ステップＳ１６）。すなわち、配信端末２０から送信された配信データは、有効時間を超えるまで、利用者端末３０を伝播して行くことになる。この場合、配信データは、有効時間を超えるまで、利用者端末３０間を伝播していくので、有効時間の値に応じて伝播する時間を制御することができる。以上のように、第１の実施形態においては、混雑状況に応じて、ホップ数もしくは有効時間を変化させるようにしているため、混雑しているときは、小人数にしか伝達されず、空いている時には、多くの人に伝達されることとなる。

（第２の実施形態）
続いて、本発明第２の実施形態として、情報伝達システムをテーマパークにおける宝探しゲームの実施に利用する場合について説明する。システム構成は、図１と同一であるため、システムの処理動作について図５のフローチャートを用いて説明する。まず、配信サーバ１０が配信ホップ数と表示範囲ホップ数を設定する（ステップＳ２１）。ここで、配信ホップ数とは、第１の実施形態で示したものと同様、配信可能なホップ数であるが、第１の実施形態と異なり、固定で設定される。また、表示範囲ホップ数は、ホップ数によりコンテンツ内のどの部分を表示するかを設定するものである。例えば、コンテンツが複数の画面データで構成される場合は、あるホップ数範囲内では画面Ａを表示し、ある範囲内では画面Ｂを表示するというように設定する。ここでは、この配信ホップ数と表示範囲ホップ数をメタデータとして作成することになる。次に、配信サーバ１０は、コンテンツにメタデータを付加して配信データとして、配信端末２０に送信する（ステップＳ２２）。

配信端末２０での処理は、第１の実施形態と全く同一であるので説明は省略する。利用者端末３０では、配信端末２０から配信データを受信すると（ステップＳ２７）、メタデータ内の表示範囲ホップ数に従って、配信データ内のコンテンツの表示を行う（ステップＳ２２）。具体的には、例えば、ホップ数が、画面Ａに対応している場合は、画面Ａを表示するといった具合に処理を行う。これ以降のステップＳ２９〜ステップＳ３４の処理は、第１の実施形態と全く同一である。したがって、配信端末２０から送信された配信データは、ＴＴＬが０になるまで、利用者端末３０を伝播して行くことになる。この場合に、各利用者端末３０においては、受信した配信データ内のホップ数により、表示が異なることになる。したがって宝さがしゲームを行う場合には、例えば、画面Ａとして、賞品（すなわち宝さがしゲームの目的である宝）の引換えチケットの画面を用意しておき、画面Ｂとして、宝が近くに有ることを示す旨の情報を掲載した画面を用意しておき、画面Ｃとして、宝が遠くに有ることを示す旨の情報を掲載した画面を用意しておく。この場合、利用者は、利用者端末の画面を見ながら、最終的に画面Ａが表示される位置に移動していくことにより、宝を得ることができる。上述のように、本実施形態では、ホップ数で表示を制御しているため、ホップ数が大きければ宝の位置（すなわち配信端末の位置）に近く、ホップ数が小さければ宝の位置から遠いとは限らない。しかし、各利用者端末を所持した各利用者が任意に移動することを考慮すると、ホップ数が大きい場合は、多くの利用者端末３０を経由していないことになるため、配信端末２０から比較的近いことになり、ホップ数が小さい場合は、多くの利用者端末３０を経由していることになるため、配信端末２０から比較的遠いと考えられる。そのため、ホップ数に応じて、近いか遠いかの表示を行っているのである。逆に言えば、表示と実際の距離の関係が正確でないため、よりゲーム性が増すことになる。

上記の例では、宝さがしゲームの実行において、１つのコンテンツで複数の表示を行わせるようにしたが、表示させる内容ごとに別コンテンツとすることも可能である。例えば、上記の画面Ａ、画面Ｂ、画面Ｃをそれぞれ別のコンテンツとして配信するのである。この場合、各コンテンツに対応したメタデータには、それぞれ、配信ホップ数と表示範囲ホップ数が設定される。ここで、配信ホップ数は、上記の例と同じ役割を果たすが、表示範囲ホップ数は上記の例と異なり、表示・非表示だけを制御するものとなる。すなわち、設定された表示範囲ホップ数の範囲内であれば、コンテンツの内容を表示し、表示範囲ホップ数の範囲外であれば表示を行わない。このように、各画面ごとにコンテンツを用意した場合のフローチャートを図６に示す。図６のフローチャートについては、図５と同一の処理を行う箇所については、同一符号を付して説明を省略する。図５と異なる点は、ステップＳ３５とステップＳ３６であり、ステップＳ３０においてＴＴＬが０でないと判断された場合に、表示範囲ホップ数が表示範囲内であるかどうかの判定を行う（ステップＳ３５）。表示範囲内である場合は、そのコンテンツの表示を行い（ステップＳ３６）、表示範囲外である場合は、コンテンツの表示を行わずに、ステップＳ３１に移行する。

（第３の実施形態）
続いて、本発明第３の実施形態として、情報伝達システムをドロケーゲームに利用する場合について説明する。図７は、第３の実施形態による情報伝達システムのシステム構成図である。図７に示すように、第３の実施形態においては利用者端末３０だけの構成となる。図７に示した利用者端末３０は、第１、第２の実施形態において説明した機能に加えて、自身の内部にコンテンツおよび配信ルールを有し、他の利用者端末３０に送信する機能を有している。すなわち、第１、第２の実施形態において示した配信サーバ１０の機能も有していることになる。

図７に示したシステムの処理動作について図８のフローチャートを用いて説明する。まず、配信側利用者端末が配信ホップ数と表示範囲ホップ数を設定する（ステップＳ４１）。ここでの配信ホップ数と表示範囲ホップ数は、第２の実施形態で示したものと同一であり、伝播する利用者端末数およびホップ数によりコンテンツ内のどの部分を表示するかを設定するものである。ここでも、この配信ホップ数と表示範囲ホップ数をメタデータとして作成することになる。続いて、配信側利用者端末３０は、通信可能な範囲に他の利用者端末３０が存在するかどうかの探索を行う。この結果、他の利用者端末３０を発見することができた場合は（ステップＳ４２）、配信データを利用者端末３０に送信する（ステップＳ４３）。

受信側利用者端末３０では、第２の実施形態における利用者端末３０と同一の処理動作を行う。すなわち、受信した配信データ内のコンテンツをホップ数に従って表示し、ＴＴＬを１減らして他の利用者端末３０に送信する。ＴＴＬが０になるまで、配信データが利用者端末３０間を伝播することになる。したがってドロケーゲームを行う場合には、例えば、画面Ａとして、相手（刑事から見た泥棒、泥棒から見た刑事）が至近距離にいることを示す旨の情報を掲載した画面を用意しておき、画面Ｂとして、相手が近くにいることを示す旨の情報を掲載した画面を用意しておき、画面Ｃとして、相手が遠くにいることを示す旨の情報を掲載した画面を用意しておく。この場合、刑事役は、利用者端末３０の画面を見ながら、最終的に画面Ａが表示される位置に移動していくことにより、泥棒役を捕まえることができる。一方、泥棒役は、利用者端末３０の画面を見ながら、どの画面も表示されない位置に移動していくことにより刑事役から逃れることができる。

ドロケーゲームを行う場合の利用者端末の基本的な処理は、図８のフローチャートに示したようなものとなるが、１つの利用者端末３０が配信側利用者端末、受信側利用者端末の双方の機能を有することになる。また、各利用者端末には、自分が泥棒側であるか刑事側であるかのグループ情報を保有しておき、メタデータの作成時には、メタデータ内にグループ名も付加する。受信時には、自身に設定されたグループと異なるグループからの配信データのみ受信し、同一のグループからの配信データは破棄する。これにより、刑事側は泥棒側からの配信データのみを受信でき、泥棒側は刑事側からの配信データのみを受信できることとなる。また、グループにより、配信可能ホップ数を異ならせるようにしても良い。例えば、刑事側からの配信データは１０ホップ、泥棒側からの配信データは５ホップ届くように設定すれば、泥棒側はすぐ刑事側に気付くが、刑事側はなかなか泥棒側に気付かないといったハンディが与えられることになる。

以上、本発明の好適な実施形態について説明したが、本発明は上記実施形態に限定されず、種々の変形が可能である。例えば、上記図２、図５、図６、図８のフローチャートでは、配信データの到達範囲をＴＴＬで制御したが、配信時刻から所定の時間が経過した後に配信データを削除するような制御としても良い。この場合、配信端末２０もしくは配信側利用者端末３０が配信データを送信する際に、メタデータに配信時刻情報を付加して送信し、利用者端末３０では、内部の現在時刻情報と比較して所定の時間が経過している配信データを削除するような処理を行う。これにより、基本的にはホップ数で制御するが、新鮮でなくなった情報を削除することができる。

また、例えば、配信時刻とＴＴＬの両条件から所定の時間及び所定のホップ数に達した後に配信データを削除するような制御としても良い。この場合ホップ数は０でなくとも、配信時刻からどの程度の時間が経過しているかの条件も加味して、情報を削除することができる。また、ホップ数を増加させ、ある一定値まで増加すると情報を削除することができる。さらに、ホップ数の変化を配信時刻より一定時間経過後は１よりも大きな値にすることで、古い情報ほどホップ数の変化を加速させ、古い情報をより早く消去することも可能である。

本発明に係る情報伝達システムの構成図である。 第１の実施形態の処理概要を示すフローチャートである。 第１の実施形態において用いられる配信ルールの一例を示す図である。 第１の実施形態の変形例の処理概要を示すフローチャートである。 第２の実施形態の処理概要を示すフローチャートである。 第２の実施形態の変形例の処理概要を示すフローチャートである。 本発明第３の実施形態に係る情報伝達システムの構成図である。 第３の実施形態の処理概要を示すフローチャートである。

符号の説明

１０・・・配信サーバ
１１・・・コンテンツ
１２・・・配信ルール
２０・・・配信端末
３０・・・利用者端末

Claims (7)

1. 配信する内容であるコンテンツと、当該コンテンツを配信する際のルールである配信ルールとに基づいて、前記コンテンツを伝達させる範囲を定義したメタデータを作成し、コンテンツとメタデータを含む配信データを作成する配信データ作成手段と、
   前記配信データを利用者が用いる端末装置である利用者端末に対して無線通信により配信する配信手段と、
   前記配信手段から受信した配信データ内の前記コンテンツを自身の表示手段に表示させる機能を有すると共に、前記受信した配信データ内に付加されたメタデータの内容に応じて、当該配信データを他の利用者端末に送信する処理を行う機能を有する利用者端末と、
   を有することを特徴とする情報伝達システム。
2. 前記利用者端末は、さらに受信した配信データ内に付加されたメタデータの内容に応じて、当該配信データを消去する機能を有することを特徴とする請求項１に記載の情報伝達システム。
3. 前記利用者端末は、さらに受信した配信データ内に付加されたメタデータの内容に応じて、当該配信データを非表示にする機能を有することを特徴とする請求項１または請求項２に記載の情報伝達システム。
4. 前記コンテンツは、テーマパーク内の遊技施設の混雑状況を示す情報であり、
   前記配信ルールは、混雑状況と配信可能なホップ数である配信ホップ数を定義したものであり、
   前記利用者端末は、前記メタデータ内のホップ数を一定数変化させると共に、当該メタデータ内のホップ数が一定値になった場合に、受信した配信データを消去するものであることを特徴とする請求項１に記載の情報伝達システム。
5. 前記コンテンツは、複数の画面データを含むものであって、
   前記配信ルールは、ホップ数に応じてどの画面データを表示させるかを定義したものであり、
   前記利用者端末は、前記メタデータ内のホップ数に応じた画面データを表示させる機能を有すると共に、前記メタデータ内のホップ数を一定数変化させ、当該メタデータ内のホップ数が一定値になった場合に受信した配信データを消去する機能を有することを特徴とする請求項１に記載の情報伝達システム。
6. 前記配信データ作成手段は、配信データの管理を行うサーバコンピュータである配信サーバにより実現され、
   前記配信手段は、配信処理を行う端末装置である配信端末であることを特徴とする請求項４または請求項５に記載の情報伝達システム。
7. 前記コンテンツは、複数の画面データを含むものであって、
   前記配信ルールは、ホップ数に応じてどの画面データを表示させるかを定義すると共に、グループ別の配信ホップ数を定義したものであり、
   前記利用者端末は、前記メタデータ内のホップ数に応じた画面データを表示させる機能を有すると共に、前記メタデータ内のホップ数を一定数変化させ、当該メタデータ内のホップ数が一定値になった場合に受信した配信データを消去する機能を有し、さらに
   前記配信データ作成手段および前記配信手段を有することを特徴とする請求項１に記載の情報伝達システム。
   
   

Images