JP2007158925A - モバイル端末向け推奨番組情報活用型視聴支援システムおよび方法ならびにそのプログラム - Google Patents

Abstract

【課題】より精度の高い推奨番組情報を提供可能なモバイル端末向け推奨番組情報活用型視聴支援システムを提供する。
【解決手段】モバイル端末１１と口コミＡＳＰ３０とがネットワーク５０で接続され、コミュニティ同報クライアント１１０にて、電子番組表から推奨番組を選択し、選択された推奨番組情報と、利用者の友人を登録する友人リスト１２０に登録された宛先を含む推奨番組メッセージを作成して、コミュニティ同報サーバ３１０に送り、コミュニティ同報サーバから推奨番組メッセージに含まれる宛先に推奨番組情報を配信する。
【選択図】図１

Description

本発明は、モバイル端末向け推奨番組情報活用型視聴支援システムに関し、特に、友人からの推奨番組情報を活かすことで、小さいモバイル端末の画面でも録画可能性の高い情報を優先的に表示したり、地上波放送に関して地域の違いを意識せずにモバイル端末から予約や視聴ができるシステムに関する。

図３４は、従来のコンテンツ視聴支援システムの一例を示す（例えば、特許文献１参照）。この従来のコンテンツ視聴支援システムは、サーバと、ユーザ情報管理ＤＢと、投票累計ＤＢと、インターネットを介して接続されるコンテンツ記録再生装置から構成されている。

このような構成を有する従来のシステムはつぎのように動作する。ユーザの視聴履歴や投票結果などを、コンテンツ記録再生装置を使って収集し、収集情報を、インターネットを介してサーバに伝える。サーバは吸い上げた収集結果を、ユーザごとに投票類型ＤＢやユーザ情報管理ＤＢに蓄積する。サーバは、ユーザ情報管理ＤＢや投票類型ＤＢにアクセスし、同じような視聴履歴を有するユーザをグループ化する。すなわち、ユーザの中で視聴した番組で相関係数を計算し、相関係数をもとにクラスタ分析を行うことで、同じ視聴履歴を有するユーザをグループ化する。または、ユーザの性別・年齢・職業等の属性で相関係数を計算し、クラスタ分析する手法も提案されている。

メンバの視聴履歴に現れる特徴をもとに、グループ内のほかのメンバの録画推奨情報を伝える。これにより、ユーザは興味を持つであろう番組情報を得ることができる。すなわち、グループ内での視聴率を計算し、通常のグループ内視聴率よりも急激にグループ内視聴率が高くなった情報をグループ内の他のメンバに伝える。

ところで、近年、地上波を携帯電話等のモバイル端末で視聴するための仕組みが整い始めてきた。例えば、地上アナログテレビチューナを内蔵した携帯電話として「Ｖ６０１Ｎ」などの製品が２００３年１２月に現れている。また、携帯電話向けの地上波デジタル放送が２００５年度中に始まるといわれている。

このようなモバイル端末向け放送視聴においては、自宅のレコーダと連動して、モバイル端末からレコーダに録画予約したり、モバイル端末で視聴中の放送をレコーダにその場で録画操作することも期待される。例えば、Biglobe BroadPassなどの携帯電話向け電子番組表（ＥＰＧ）サービスが存在し、携帯電話から録画予約をすることができるようになっている。
特開２００５−０３３６００号公報

しかしながら、モバイル端末を意識しない従来のコンテンツ視聴支援システムを適用するには以下の問題が存在する。

第１の問題点は、モバイル端末の画面は、通常のテレビ画面よりも小さいため、より精度の高い推奨情報を得る必要があるということである。すなわち、表示できる推奨情報が少ないため、より有意な推奨情報を選別する必要がある。従来の発明では、ユーザのグルーピングを視聴パターンによる相関係数の大きさで求めている。また、グループ内の視聴率変動をもとに推奨情報を作成していた。しかし、この方法では、同じ性別や職業であっても同じ番組嗜好を好むとは限らないことがある。例えば、２０歳代の女性でオフィスに勤める方でも歌番組が好きな人も居れば、ドラマが好きな方もいる。また、同じ視聴パターンを持つグループでも、ながら視聴と興味を持ってみている場合でも同一に捉えられてしまうため、視聴パターンの濃淡が出にくいことが挙げられる。特にモバイルの場合、通勤時間などのながら視聴が増えると想定される。そのような番組も推奨情報として判別されても、グループ内のほかの視聴者への推奨情報として有益ではない。

第２の問題点は、地上波放送視聴に関しては、モバイル端末は移動可能なため、同じ推奨情報でも地域によって視聴可能な番組と、視聴不可な番組がある。また、同じ番組であっても時間がずれている可能性がある。また、モバイル端末で視聴中の放送を自宅のホームサーバに録画しようとしても視聴場所におけるチャネル・時刻での放送内容と、自宅での放送内容は放送局が異なるため、異なる可能性があり、所望の番組を必ずしも録画できない。

そこで本発明は、より精度の高い推奨番組情報を提供可能なモバイル端末向け推奨番組情報活用型視聴支援システムおよび方法ならびにそのプログラムを提供することを目的とする。

さらに、モバイル端末の存在地域や推奨情報の発信地域や自宅の地域によらず地上波放送を視聴・録画する仕組みを提供することを目的とする。

上述の課題を解決するため、本発明の第１のモバイル端末向け推奨番組情報活用型視聴支援システムは、推薦メッセージ作成手段と友人リストとを備え、ある利用者が発した推奨番組情報をその友人から友人へ推奨情報を伝える動作を行う。このような構成を採用し、利用者同士の友人関係を利用することにより、本発明の第１の目的である、より精度の高い推奨情報を提供することができる。

本発明の第２と第３のモバイル端末向け推奨番組情報活用型視聴支援システムは、メッセージ応答手段と友人関係リストとを備え、ある利用者が発した推奨番組情報をその友人から友人へ推奨情報を伝える動作を行う。このような構成を採用し、利用者同士の友人関係を利用することにより、本発明の第１の目的である、より精度の高い推奨情報を提供することができる。

本発明の第１と第２のモバイル端末向け推奨番組情報活用型視聴支援システムは、番組名検索手段と番組表取得クライアントを備え、推奨番組名と同じ番組情報を現在の地域の電子番組表や自宅が位置する地域の電子番組表から検索することで、目的とする番組情報を取得する動作を行う。

このような構成を採用し、地域差があっても同じ番組を検索することにより、本発明の第２の目的である、より精度の高い推奨情報を提供することができる。

本発明の第３のモバイル端末向け推奨番組情報活用型視聴支援システムは、番組対応表を備え、推奨番組と、現在の地域の電子番組表や自宅が位置する地域で同一の番組情報を検索することで、目的とする番組情報を取得する動作を行う。このような構成を採用し、地域差があっても同じ番組を検索することにより、本発明の第２の目的である、より精度の高い推奨情報を提供することができる。

本発明による第１の効果は、より精度の高い推奨番組情報を提供可能なことである。

その理由は、視聴者が明示的に推奨する番組情報を、友人関係を通して、伝播させることによる。視聴者が明示的に推奨情報を発信することにより、ながら視聴と推奨情報を区別でき、より精度の高い推奨番組情報を得ることができる。また、利用者の性別・年齢などの特徴よりも友人関係のほうが同一の視聴嗜好をもつ可能性が高い。例えば、サッカーチームという関係の友人であれば、サッカー番組の視聴する可能性が高い。また、この利用者は、チーム以外にサッカープロチームのファンクラブに入っているとした場合、その推奨番組をファンクラブ仲間に推移的に伝播することもあり得る。その場合、サッカー情報はファンクラブメンバにとっても有益な情報である可能性が高い。

第２の効果は、モバイル端末の存在地域や推奨情報の発信地域や自宅の地域によらず地上波放送を視聴・録画する仕組みを提供することにある。

第１、第２の実施形態において、その理由は、モバイル端末側でモバイル端末の現在の地域、そして、自宅が位置する地域、のそれぞれの地域の電子番組表を得、推奨番組名をもとに番組表を検索することで、地域ごとに対応する番組を検索することができるためである。

第３の実施形態において、その理由は、口コミＡＳＰ側において、地域ごとの番組対応表をもち、モバイル端末側でモバイル端末の現在の地域、そして、自宅が位置する地域、などの地域ごとに推奨番組に対応する番組情報を取得することができるためである。第３の実施形態は、モバイル端末だけではなく、口コミＡＳＰ側への設備の投資と口コミＡＳＰでの番組対応情報の保守が必要になるが、より正確な番組対応を得ることができる。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

図１を参照すると、本発明の第１の実施形態は、複数台のモバイル端末１１，１２とそれに対応したインターネット予約機能付きレコーダ２１，２２が存在する。インターネット予約機能付きレコーダ２１，２２は、携帯電話から通信により、チャネル、番組開始時刻、時間を伝えることで録画予約や録画操作ができるレコーダとする。また、ネットワーク５０を通して電子番組表（ＥＰＧ）を提供するモバイル端末向けＥＰＧ配信アプリケーション・サービス・プロバイダ（ＡＳＰ）４０と、推奨番組情報を伝播させる口コミＡＳＰ３０で構成される。また、モバイル端末及び口コミＡＳＰ並びにＥＰＧ配信ＡＳＰは、それぞれのメモリに格納された制御プログラムによって、以下に説明する各機能を実現する。

モバイル端末１１は、ユーザに情報を示す画面２３０と、モバイル端末１１の利用者の友人を登録する友人リスト１２０と、モバイル端末１１の認証を行うためのユーザＩＤ（ＵＩＤ）とそのパスワードを記録する利用者情報１３０と、ネットワークを介して口コミＡＳＰ３０やモバイル端末向けＥＰＧ配信ＡＳＰ４０と通信を行うとともに、通信相手と同じ暗号鍵により秘匿通信を行うことが可能なクライアント通信手段１００と、ネットワークを介してインターネット予約機能付きレコーダ２１に番組を予約する機能を提供する番組予約クライアント１９０と、指定された地域コードに応じて定期的にモバイル端末向けＥＰＧ配信ＡＳＰ４０から電子番組表をダウンロードする番組表取得クライアント１４０と、番組表取得クライアント１４０がダウンロードした電子番組表を格納する領域である電子番組表１５０と、ＧＰＳ(Global Positioning System)衛星からの測位情報に基づき携帯電話の現在の位置を緯度・経度で求めることができるＧＰＳ１７０と、緯度・経度と放送における地域コードの対応表である位置・地域コード対応表２２０と、自宅のある地域コードを記録する自宅地域ＩＤ１８０と、与えられた番組名を電子番組表１５０から検索する番組名検索手段１６０と、利用者が指定した推奨番組を推奨番組メッセージとして友人リスト１２０に登録された友人に送信するとともに、口コミＡＳＰ３０から送られた推奨番組メッセージを友人リスト１２０に登録された友人に転送するコミュニティ同報クライアント１１０と、利用者が友人リスト１２０を登録・削除・変更したり、モバイル端末のＵＩＤやパスワードを設定したり、自宅地域ＩＤを設定したり、電子番組表１５０を画面２３０に表示したり、表示された電子番組表を利用者が指定することで、その情報を番組予約クライアント１９０に渡すことで、インターネット予約機能付きレコーダに録画予約したり、推奨リスト２１０を画面２３０に表示したり、利用者が指定した推奨番組情報をコミュニティ同報クライアントに伝えることで、友人への推奨番組情報を伝播させたり、伝播させた推奨番組情報をホップ数に応じた優先度で推奨リスト２１０に追記したり、する番組表制御ＵＩ２００と、番組表制御ＵＩ２００がコミュニティ同報クライアント１１０を通して得た推奨番組情報を格納する推奨リスト２１０と、で構成されている。

本実施形態では、モバイル端末の現在位置特定機能にＧＰＳ衛星からの測位情報を用いたが、モバイル端末にＰＨＳ(Personal Handyphone System)端末を用いて、ＰＨＳによる現在位置特定機能を用いることもできる。

口コミＡＳＰ３０は、ネットワークを介してモバイル端末１１，１２やモバイル端末向けＥＰＧ配信ＡＳＰ４０と通信を行うとともに、通信相手と同じ暗号鍵により秘匿通信を行うことが可能なサーバ通信手段３００と、認証情報とユーザ名とパスワードのペアのリストであるアカウントリスト３４０と、サーバ通信手段３００を行う際、アカウントリスト３４０をもとに認証を行う認証手段３３０と、サーバソケットを開設できないモバイル端末のため、モバイル端末から定期的に送信メッセージをｐｕｌｌ型で取得することにより、擬似的にモバイル端末にサーバ機能を実現するコミュニティ同報サーバ３１０と、コミュニティ同報サーバ３１０がメッセージを一時的に格納する領域であるメッセージバッファ３２０で構成される。

図２は、コミュニティ同報クライアント１１０の詳細構成を示す。認証手段３３０に対して、ユーザＩＤ（ＵＩＤ）１３１とパスワード１３２を送信し、認証を求め、認証が成功したら、クライアント通信手段１００に対して暗号化設定を行う認証クライアント１１１と、口コミＡＳＰ３０から自分宛に送信された推奨番組情報を取り出すための推薦番組メッセージ受信手段Ｃ１１６と、推薦番組メッセージ受信手段Ｃ１１６を定期的に駆動するタイマーＣ１１７と、推薦番組メッセージ受信手段Ｃ１１６が取得した推奨番組メッセージや、利用者が推薦した番組情報を表すメッセージを格納する推奨番組メッセージ記憶手段１１５と、推奨番組メッセージ記憶手段１１５から推薦番組メッセージ受信手段Ｃ１１６が取得した推奨番組メッセージや、利用者が推薦した番組情報を友人リスト１２０に登録された友人に転送する推薦番組メッセージ作成手段１１２と、推薦番組メッセージ作成手段１１２が転送をする際に、転送対象の推奨番組メッセージのホップ数を廃棄する基準を定めるＴＴＬ(Time-to-Live)閾値１１４と、推薦番組メッセージ作成手段１１２が友人リスト１２０中の友人に転送する際、現在の転送中の友人を指し示す友人リストエントリＩＤ１１３で構成される。

図３は、コミュニティ同報サーバ３１０の詳細構成を示す。各行がメッセージバッファ３２０に蓄積された推奨番組メッセージを指し示すメッセージポインタ列と、推奨番組メッセージの登録時刻列と、宛先の３列で構成されたメッセージ一覧表３１５と、モバイル端末１１などからの推奨番組メッセージを受信する推奨番組メッセージ受信手段Ｓ３１１と、モバイル端末１１などからメッセージ取得要求を受信し、推奨番組メッセージを応答するメッセージ応答手段３１２と、メッセージ応答手段３１２がメッセージ一覧表３１５を検索する際、その作業行を指し示すメッセージ一覧表インデックス３１３と、メッセージ応答手段３１２が応答メッセージを構築する際の作業領域であるメッセージ格納領域３１４と、モバイル端末１１などからメッセージ取得要求を受理せず一定時間経過したメッセージバッファ３２０内の推奨番組メッセージを削除するメッセージ削除手段３１６と、メッセージ削除手段３１６を定期的に起動するタイマー３１７と、で構成される。

次に、図４から図１４のフローチャートを参照して本実施形態の全体の動作について詳細に説明する。

まず、図４のフローチャートを参照して本実施形態のうち、利用者が友人に番組を推奨する際の実施形態について説明する。

利用者は、画面２３０に表示されている番組表から番組を選び、「他の人に推薦ボタン」を押す（ステップＳ１０１）。番組表制御ＵＩ２００は、ＧＰＳから得た位置情報をもとに、位置・地域コード対応表２２０を検索し、現位置に対応する地域コードを得る（ステップＳ１０２）。番組表制御ＵＩ２００は、推薦ボタンを押された番組情報（番組名、チャネル、開始時刻と時間）と、地域コードをもとに、推奨番組メッセージを作成し推奨番組メッセージ記憶手段１１５に置くとともに、コミュニティ同報クライアント１１０に伝える（ステップＳ１０３）。コミュニティ同報クライアントは後述する送信処理１を行う（ステップＳ１０５）。送信処理１では、以下のメッセージ例１１で示すメッセージを口コミＡＳＰ３０に送信する。

（メッセージ例１１：推奨番組メッセージ）
<!- メッセージ送信 -->
<Transmission>
<from uid=“tanaka”/>
<to uid=“fukuda”/>
<TTL>1</TTL> <!- 0,1,2,…-->
<path uid=“tanaka” time=“2005.03.24.22.01.13”/>
<path uid=“fukuda” time=“2005.03.24.23.02.13”/>
</Transmission>
<Authenticates>
<uid>tanaka</uid>
<passwd>6ad35d</passwd>
</Authenticates>
<Operation code=“send”>
<Programs>
<Program>
<name id=“あるある大辞典” />
<StartTime date=“2004.03.24 Sun 21:00”</>
<Period period=“1:00”/>
<Channel no=“8” />
<region code=“32”/>
</Program>
</Programs>
</Operation>

すなわち、ｆｒｏｍフィールドは、送信者のユーザＩＤ（ｕｉｄ）を表す。Ｔｏフィールドは、送信者のユーザＩＤ（ｕｉｄ）を表す。ＴＴＬはメッセージが何回ユーザの間をホップしたかを示す。例えば、２ならば二人のユーザ間を転送されたことを示す。ｐａｔｈフィールドは送信者や受信者も含めて、何人の間で転送されたかを示す。ＡｕｔｈｅｎｔｉｃａｔｅはユーザのＩＤとパスワードを示す。これにより認証可能かを判断する。このようなＩＰＳｅｃでの認証やＳＳＬでの認証など認証手段は様々な方式が考えられており、それを流用することを想定する。

Ｏｐｅｒａｔｉｏｎフィールドのｃｏｄｅ属性はメッセージの種類を示しており、”ｓｅｎｄ”はモバイル端末１１から口コミＡＳＰ３０を経由して他のモバイル端末に送るメッセージであることを示す。Ｐｒｏｇｒａｍｓフィールドは推奨番組情報が複数格納されている。なお、ｒｅｇｉｏｎフィールドのｃｏｄｅ属性は、放送地域のＩＤ番号である。

送信処理１が成功した場合、推奨番組メッセージ作成手段１１２は、番組表制御ＵＩ２００に推奨メッセージ送信が成功したことを応答する（ステップＳ１０６）。番組表制御ＵＩ２００は、推奨メッセージ送信が成功したことを画面２３０に表示する（ステップＳ１０７）。

送信処理１が失敗した場合、コミュニティ同報クライアント１１０内の推奨番組メッセージ作成手段１１２が、番組表制御ＵＩ２００に認証失敗を返す（ステップＳ１０８）。番組表制御ＵＩ２００は、画面２３０に利用者認証失敗を表示する（ステップＳ１０９）。

次に図５及び図６のフローチャートを参照して本実施形態のうち、モバイル端末１１が口コミＡＳＰ３０に推奨番組メッセージを送る、前述の送信処理１について説明する。コミュニティ同報クライアント１１０内の推奨番組メッセージ作成手段１１２は、認証クライアント１１４に口コミＡＳＰ３０への認証処理を依頼する（ステップＳ１１１）。そして、後述の認証処理を行う（ステップＳ１１２）。

認証が失敗した場合、認証クライアント１１４は、推奨番組メッセージ作成手段１１２を通して、認証失敗を返す（ステップＳ１１４）。

認証が成功した場合、認証クライアント１１４は、推奨番組メッセージ作成手段１１２に認証成功を伝える（ステップＳ１１５）。推奨番組メッセージ作成手段１１２は、推奨番組メッセージ記憶手段１１５から推奨番組メッセージを読み取る（ステップＳ１１６）。推奨番組メッセージ作成手段１１２は、ＴＴＬ閾値１１４を読み取り、メッセージ内のホップ数（Time-to-Live：ＴＴＬ）の値以下であるか比較する（ステップＳ１１７）。もし、ＴＴＬがＴＴＬ閾値１１４より大きければ、友人間を何度もホップしてきたメッセージとして破棄し、後述の送信処理１の終了処理へと進む（ステップＳ１１８）。

もし、ＴＴＬがＴＴＬ閾値１１４以下ならば、推奨番組メッセージ作成手段１１２は、友人リストエントリＩＤ１１３に０を書き込む（ステップＳ１１９）。友人リストエントリＩＤは、友人リスト１２０を検索するときの現在、検索対象のエントリを示す。推奨番組メッセージ作成手段１１２は、友人リストエントリＩＤ１１３が指す友人リスト１２０の行を取得する。もし、該当行が存在しない場合、すなわち、友人リスト１２０のすべての行を検索し終えた場合、後述の送信処理１の終了処理へと進む（ステップＳ１２１）。

もし、該当行が存在すれば、推奨番組メッセージ作成手段１１２は、該当行から宛先列にある友人のＵＩＤを得る。そのＵＩＤが推奨メッセージの中のｐａｔｈフィールドにあるか調べる（ステップＳ１２２）。もし、ＵＩＤがｐａｔｈフィールド上に存在すれば、このメッセージは既にＵＩＤで示される友人には転送済みのため、送信のための処理ステップＳ１２４，Ｓ１２５，Ｓ１２６を省略し、ステップＳ１２７へと進む（ステップＳ１２３）。もし、ＵＩＤがｐａｔｈフィールド上に存在しなければ、このメッセージはまだＵＩＤで示される友人に転送されていないので、送信処理を行う。具体的には、推奨番組メッセージ作成手段１１２は、友人ＵＩＤをメッセージのｔｏエレメントに埋め込み、推奨番組メッセージを口コミＡＳＰ３０に送信する（ステップＳ１２４）。推奨番組メッセージ受信手段Ｓ３１１は、受信したメッセージをメッセージバッファ３２０に追記する。また、メッセージ一覧表に適切な値を登録する（ステップＳ１２５）。推奨番組メッセージ受信手段Ｓ３１１は、処理成功を推奨番組メッセージ作成手段１１２に応答する（ステップＳ１２６）。推奨番組メッセージ作成手段１１２は、友人リストエントリＩＤ１１３に１を足して、書き込む（ステップＳ１２７）。すなわち、ステップＳ１２０から１２７の処理により友人ひとりにメッセージを送信したので、友人リストエントリＩＤ１１３に１を足して、次の友人への送信処理をステップＳ１２０から繰り返す。

さて、送信処理１の終了処理であるが、推奨番組メッセージ作成手段１１２は、推奨メッセージ送信が成功したことを応答し、処理を終了する（ステップＳ１２８）。

次に図７から図１０のフローチャートを参照して本実施形態のうち、モバイル端末１１が定期的に口コミＡＳＰ３０から自分宛のメッセージを取得する際の実施形態について説明する。携帯電話をはじめとする多くのモバイル端末においてはサーバソケットを開設できないため、このように定期的に携帯電話がメッセージをポーリングする形となる。

コミュニティ同報クライアント１１０中のタイマーＣ１１７は、定期的に推奨番組メッセージ受信手段１１６を起動する（ステップＳ１３１）。推奨番組メッセージ受信手段１１６は、認証クライアント１１１に口コミＡＳＰ３０への認証処理を依頼する（ステップＳ１３２）。そして、後述の認証処理を行う（ステップＳ１３３）。

もし、認証に失敗した場合、認証クライアント１１１は、推奨番組メッセージ受信手段１１６を通して、番組表制御ＵＩ２００に認証失敗を伝える（ステップＳ１３５）。番組表制御ＵＩ２００は、画面２３０に利用者認証失敗を表示する（ステップＳ１３６）。

もし、認証に成功した場合、推奨番組メッセージ受信手段１１６は、口コミＡＳＰ３０にメッセージ取得要求を、クライアント通信手段１００を介して、発行する（ステップＳ１３７）。このメッセージの例を以下のメッセージ例１２に示す。Ｏｐｅｒａｔｉｏｎフィールドのｃｏｄｅ属性がｇｅｔであることで、このメッセージがメッセージ取得要求であることを示す。

（メッセージ例１２：メッセージ取得要求メッセージ）
<!- メッセージ取得 -->
<Authenticates>
<uid>fukuda</uid>
<passwd>6ad35d</passwd>
</Authenticates>>
<Operation code=“get”/>
<regionCodes>
<region code=“32”/>
<region code=“15”/>
</regionCodes>
</Operation>

サーバ通信手段３００は、クライアント通信手段１００が発信した推奨番組メッセージ受信取得メッセージを受信し、メッセージ応答手段３１２に転送する（ステップＳ１３８）。メッセージ応答手段３１２は、メッセージ一覧表インデックス３１３に０を代入（ステップＳ１３９）。メッセージ一覧表３１５の行ごとに送信処理を行うためのインデックスをスタート位置に設定したことになる。メッセージ一覧表３１５をすべて調べつくしたかチェックするために、メッセージ応答手段３１２は、一覧表インデックス３１３の値はメッセージ一覧表３１５の行数をオーバしているか、調べる。もし、オーバしているならば、すなわち、メッセージ一覧表３１５をすべて調べつくしている場合、終了処理であるステップＳ１４８に分岐する。もし、オーバしていない場合、まだ未処理のメッセージ一覧表３１５の行が存在する。メッセージ応答手段３１２は、メッセージ一覧表インデックス３１３の指すメッセージ一覧表３１５のエントリの宛先を得る（ステップＳ１４２）。その際、その宛先がメッセージ取得要求の送信者でなければ、送信のためのメッセージ組み立て処理１４４，１４５，１４６はスキップし、メッセージ応答手段３１２は、メッセージ一覧表インデックス３１３に１足す（ステップＳ１４７）。宛先がメッセージ取得要求の送信者と一致するならば、送信処理を行う。すなわち、メッセージ応答手段３１２は、メッセージ一覧表３１５から見つけたエントリのメッセージポインタが指すメッセージをメッセージバッファ３２０から取得する（ステップＳ１４４）。メッセージ応答手段３１２は、取得したメッセージを、通信手段１４０を通じて、メッセージ格納領域３１４でメッセージを組み立てる（ステップＳ１４５）。メッセージ応答手段３１２は、取得したメッセージをメッセージバッファ３２０およびメッセージ一覧表３１５から削除する（ステップＳ１４６）。

一方、メッセージ取得処理の終了処理を説明する。メッセージ応答手段３１２は、メッセージ格納領域３１４のメッセージを、サーバ通信手段３００を通して、応答メッセージを送信する（ステップＳ１４８）。このメッセージ取得応答メッセージの例を以下のメッセージ例１３に示す。

（メッセージ例１３：メッセージ取得応答）
<Transmission>
<from uid=“fukuta”/>
<to uid=“ohira”/>
<TTL>2</TTL> <!- 0,1,2,…-->
<path uid=“tanaka” time=“2005.03.24.22.01.13”/>
<path uid=“fukuda” time=“2005.03.24.23.02.13”/>
<path uid=“ohira” time=“2005.03.24.23.02.13”/>
</Transmission>
<Authenticates>
<uid>tanaka</uid>
<passwd>kRdka481T</passwd>
</Authenticates>
<!- 応答メッセージペイロード例 -->
<Operation code=“send”>
<Programs>
<Program>
<name id=“あるある大辞典” />
<StartTime date=“2004.03.24 Sun 21:00”</>
<Period period=“2:00”/>
<Channel no=“6” />
<region code=“32”/>
</Program>
<Program>
<name id=“WBS” />
<StartTime date=“2004.03.24 Sun 21:00”</>
<Period period=“2:00”/>
<Channel no=“6” />
<region code=“32”/>
</Program>
</ Programs >
</operation>

推奨番組メッセージ受信手段１１６は、口コミＡＳＰ３０からのメッセージ取得応答を、クライアント通信手段１００を通して受信する（ステップＳ１４９）。

推奨番組メッセージ受信手段１１６は、受信したメッセージを推奨番組メッセージ記憶手段１１５に記録。そして、番組表制御ＵＩ２００に通知する（ステップＳ１５０）。次に後述の地域差修正処理を呼び出す（ステップＳ１５１）。この処理は、番組表制御ＵＩ２００が受け取った推奨番組名をもとに、現在位置している地域コードの番組情報を検索する処理である。地域差修正処理後、番組表制御ＵＩ２００は現在の地域コードでの推薦情報を、ＴＴＬの小さいものの順にソートして推奨リスト２１０に追記する（ステップＳ１５２）。これは、ＴＴＬが小さいメッセージほど、友人間のホップ数が少ないため、より利用者の嗜好に合致するとの仮説のもと、ＴＴＬが小さいメッセージが優先度を高く設定しているためである。番組表制御ＵＩ２００は推薦リスト２１０の内容を画面２３０に表示する（ステップＳ１５３）。推奨番組メッセージ受信手段１１６は、推奨番組メッセージ作成手段１１２に、推奨番組メッセージ記憶手段中１１５中の推奨番組メッセージを送信するように依頼（ステップＳ１５４）。そうして、前述の送信処理１を呼び出す（ステップＳ１５５）。受信し、推奨番組メッセージ記憶手段１１５中のメッセージを、送信処理１により友人に転送することができる。この送信処理が成功した場合、推奨番組メッセージ作成手段１１２は、推奨番組メッセージ受信手段１１６に送信成功を伝える（ステップＳ１５７）。推奨番組メッセージ作成手段１１２は、推奨番組メッセージ受信手段１１６に送信失敗を伝える（ステップＳ１５８）。

次に図１１のフローチャートを参照して本実施形態のうち、番組表制御ＵＩ２００が受け取った推奨番組名をもとに、現在位置している地域コードの番組情報を検索する地域差修正処理を説明する。

番組表制御ＵＩ２００は番組名検索手段１６０に番組検索を依頼（ステップＳ１５１ａ）。番組名検索手段１６０は、番組表取得クライアント１４０が現在位置での地域コードにおいて取得した電子番組表１５０を検索し、同じ番組名の番組を検索。番組表制御ＵＩ２００にチャネルと開始時刻と放送時間を返す（ステップＳ１５１ｂ）。

次に図１２のフローチャートを参照して本実施形態のうち、口コミＡＳＰ３０がモバイル端末１１を認証し、ＩＰＳｅｃなどの安全な通信パスを形成する手順について説明する。

まず、認証クライアント１１１は、設定された利用者識別子（ＵＩＤ）１３１、パスワード１３２をもとに認証メッセージを作成。クライアント通信手段１００に渡す（ステップＳ１６１）。クライアント通信手段１００は、サーバ通信手段３００に認証メッセージを渡す（ステップＳ１６２）。サーバ通信手段３００は認証手段３３０に認証メッセージを渡す（ステップＳ１６３）。認証手段３３０は、認証メッセージを渡し、アカウントリスト３４０からＵＩＤに対応したパスワードを引いて認証する（ステップＳ１６４）。

認証が成功した場合、認証手段３３０は、サーバ通信手段３００に暗号キーを払い出す（ステップＳ１６６）。サーバ通信手段３００は、クライアント通信手段１００に暗号キーを伝えるとともに、今後は暗号化した通信パケットで通信する（ステップＳ１６７）。クライアント通信手段１００は受け取った暗号キーで今後の通信を暗号化する（ステップＳ１６８）。認証クライアント１１１は、認証成功を伝える（ステップＳ１６９）。

認証が失敗した場合、認証手段３３０は、サーバ通信手段３００、クライアント通信手段１００を通して、認証クライアント１１１に認証失敗を伝える（ステップＳ１７０）。認証クライアント１１１は、認証失敗を伝える（ステップＳ１７１）。

次に図１３のフローチャートを参照して本実施形態のうち、メッセージ一覧表３１５及びメッセージバッファ３２０から古いメッセージを削除するタイムアウト処理を説明する。本処理は、宛先が正確でないメッセージのため、メッセージがごみとして残ってしまったり、モバイル端末側が故障などでいつまでたっても処理されない場合、メッセージがごみとして残ってしまうことを防ぐ。

まず、タイマー３１７は、一定周期ごとにメッセージ削除手段３１６を起動する（ステップＳ１８１）。メッセージ削除手段３１６は現在の時刻からある一定時間を引き、削除時刻を求める（ステップＳ１８２）。メッセージ削除手段３１６はメッセージ一覧表３１５の登録時刻が削除時刻より古いメッセージをメッセージバッファ３２０及びメッセージ一覧表３１５から削除する（ステップＳ１８３）。

次に図１４のフローチャートを参照して本実施形態のうち、モバイル端末１１からインターネット予約機能付きレコーダ２１を予約する処理について説明する。

利用者は、番組表制御ＵＩ２００の推薦番組一覧表から番組をモバイル端末１１で視聴する番組を選択し、家での録画処理を選択する（ステップＳ１９１）。番組表制御ＵＩ２００は番組名検索１６０に自宅地域ＩＤにおける番組名検索を依頼する（ステップＳ１９２）。番組表取得クライアント１４０は、自宅地域ＩＤにおける番組名検索をモバイル端末向けＥＰＧ配信ＡＳＰ４０に依頼する（ステップＳ１９３）。ＥＰＧ配信ＡＳＰ４は、自宅地域ＩＤにおける同じ番組名を有する番組のチャネルと開始時刻と放送時間を返す（ステップＳ１９４）。番組名検索手段１６０は、番組表制御ＵＩ２００にチャネルと開始時刻と放送時間を返す（ステップＳ１９５）。

番組表制御ＵＩ２００は、番組予約クライアント１９０に予約を依頼、番組予約クライアント１９０は、インターネット予約付きレコーダ２１に予約を登録する（ステップＳ１９６）。番組予約クライアントは、インターネット予約付きレコーダ２１に予約を登録する（ステップＳ１９７）。

次に、本発明の第２の実施形態について図面を参照して詳細に説明する。図１５、図１６、図１７を参照すると、本発明の第２の実施形態は、第１の実施形態に比して、友人リスト１２０が存在しない代わりに、友人関係リスト３５０が追加されている。友人関係リストは、推奨番組メッセージの宛先となり得るユーザＩＤ（ＵＩＤ）とそのユーザを友達として指定しているユーザのＵＩＤ（友達のＵＩＤ）の組からなる一覧表である。図１６を見ればわかるように、コミュニティ同報クライアント１１０ａから友人リストエントリ１１３がなくなっている。また、第１の実施形態でのメッセージ一覧表３１５はメッセージポインタ、登録時刻、宛先の３組の表であったが、第２の実施形態のメッセージ一覧表３１５ａは、メッセージポインタ、登録時刻、発信者の３組の表になっている。また、推奨番組メッセージ作成手段１１２ａ及びメッセージ応答手段３１２ａの振る舞いが変わる。すなわち、推奨番組メッセージ作成手段１１２ａは友人リスト３５０ごとに推奨番組メッセージを発信していたが、第２の実施形態では推奨番組メッセージは一つだけ、メッセージ応答手段３１２ａに送信される。このときの推奨番組メッセージ例２１を以下に示す。メッセージ例２１は、第１の実施形態の推奨番組メッセージ例であるメッセージ例１１に比してｔｏフィールドが存在しない。これは、本メッセージの最終的なユーザがまだ定まっていないためである。

（メッセージ例２１：推奨番組メッセージ）
<!- メッセージ送信 -->
<Transmission>
<from uid=“fukuta”/>
<!- no “to” element -->
<TTL>1</TTL> <!- 0,1,2,…-->
<path uid=“tanaka” time=“2005.03.24.22.01.13”/>
<path uid=“fukuda” time=“2005.03.24.23.02.13”/>
</Transmission>
<Authenticates>
<uid>tanaka</uid>
<passwd>6ad35d</passwd>
</Authenticates>
<Operation code=“send”>
<Programs>
<Program>
<name id=“あるある大辞典” />
<StartTime date=“2004.03.24 Sun 21:00”</>
<Period period=“2:00”/>
<Channel no=“6” />
<region code=“32”/>
</Program>
</Programs>
</Operation>

次に、本実施形態の効果について説明する。メッセージ応答手段３１２ａは、メッセージ要求メッセージを受信すると、友人関係リスト３５０の中から要求者を友人とみなす利用者のＵＩＤの集合を得て、その集合の中に含まれる利用者が発信者であるメッセージをメッセージ一覧表３１５ａから取得する。

このようにすることで、モバイル端末から大量のメッセージを発行することを防ぐことができる。

次に、図１９から図２５のフローチャートを参照して本実施形態の全体の動作について詳細に説明する。

まず、図１９のフローチャートを参照して本実施形態のうち、利用者が友人に番組を推奨する際の実施形態について説明する。ステップＳ２０１からステップＳ２０３までは、第１の実施形態のステップＳ１０１からステップＳ１０３と同一であるため、説明を省略する。ただし、第１の実施形態でステップＳ１０４として、送信処理１を呼んでいたのが、第２の実施形態では、送信処理２（ステップＳ２０４）を呼び出す点で処理が異なる。送信処理２については、後述する。ステップＳ２０５からステップＳ２０９までは、第１の実施形態のステップＳ１０５からステップＳ１０９と同一であるため、説明を省略する。

そこで、図２０および図２１のフローチャートを参照して本実施形態のうち、モバイル端末が口コミＡＳＰ３０に推奨番組メッセージを送る、前述の送信処理２について説明する。ステップＳ２１１からＳ２１８までは、第１の実施形態のステップＳ１１１からＳ１１８と同一であるため、説明を省略する。

推奨番組メッセージのＴＴＬが十分に小さいとき、第１の実施形態では、友人リスト上の行ごとを宛先として、番組推奨メッセージを送信している（ステップＳ１１９からステップＳ１２４）が、第２の実施形態では、推奨番組メッセージ作成手段１１２は、推奨番組メッセージを口コミＡＳＰ３０に送信している（ステップＳ２１９）。

第１の実施形態では、推奨番組メッセージ受信手段Ｓ３１１は、受信したメッセージをメッセージバッファ３２０に追記し、メッセージ一覧表に適切な値を登録する（ステップＳ１２５）が、第２の実施形態では、推奨番組メッセージ受信手段Ｓ３１１ａは、受信したメッセージをメッセージバッファ３２０に追記する。また、メッセージ一覧表３１５ａに適切な値を登録する（ステップＳ２２０）。このとき、メッセージ一覧表に記載する適切な値とは、第１の実施形態のステップＳ１２５では、メッセージの宛先を示すＵＩＤであったが、第２の実施形態のステップＳ２２０では、メッセージの送信者を示すＵＩＤである。

ステップＳ２２１からＳ２２２までは、第１の実施形態の図１１のステップＳ１２６からＳ１２８と比して、第１の実施形態で、友人リスト１２０の検索処理を進めるため、友人リストエントリＩＤ１１２の値を一つ増加している（ステップＳ１２７）点以外共通であるため、説明を省略する。

次に、図２２から図２５のフローチャートを参照して本実施形態のうち、利用者が推奨番組メッセージを取得するための受信処理の実施形態について説明する。ステップＳ２３１からステップＳ２３８については、第１の実施形態のステップＳ１３１からステップＳ１３８と同一であるため、説明を省略する。ここでのステップは第１の実施形態と同一であるため、ステップＳ２３７で発行される以下のメッセージ例２２のメッセージ取得要求もメッセージ例１１で示される第１の実施形態のメッセージ取得要求と同一である。

（メッセージ例２２：メッセージ取得要求メッセージ）
<!- メッセージ取得 -->
<Authenticates>
<uid>tanaka</uid>
<passwd>6ad35d</passwd>
</Authenticates>>
<Operation code=“get”/>
<regionCodes>
<region code=“32”/>
<region code=“15”/>
</regionCodes>
</Operation>

第２の実施形態では、友人関係リスト３５０に記載された宛先のＵＩＤと、その送信元である友人のＵＩＤの関係に沿って、メッセージを配布するため、メッセージ応答手段３１２ａは、友人関係リスト３５０中の利用者ＩＤに合致するＵＩＤの「宛先」欄から発見し、その「友達のＵＩＤ」欄の友人ＵＩＤリストを得る（ステップＳ２３９）。

第２の実施形態での、ステップＳ２４０からステップＳ２４３までの処理は、第１の実施形態のステップＳ１３９からステップＳ１４２と同一であるため、説明を省略する。

続いて、メッセージ応答手段３１２ａは、メッセージ一覧表インデックス３１３の指すメッセージ一覧表３１５ａのエントリの「送信者（ＵＩＤ）」を得る（ステップＳ２４３）。そして、友人リストの中に送信者（ＵＩＤ）が存在するか調べる（ステップＳ２４４）。これにより、メッセージ取得要求を友人とする推奨番組メッセージ送信者が発信した推奨番組メッセージを選択できる。もし、友人リストの中に送信者（ＵＩＤ）が存在すれば、メッセージ応答手段３１２ａは、メッセージ一覧表３１５ａから見つけたエントリのメッセージポインタが指すメッセージをメッセージバッファ３２０から取得する（ステップＳ２４５）。推奨番組メッセージ作成手段１１２は、エントリから宛先である友人のＵＩＤを得る。そのＵＩＤが推奨メッセージの中のｐａｔｈフィールドにあるか調べる（ステップＳ２４６）。もし、ｐａｔｈフィールド上に存在すれば、重複してメッセージを配布することになるので、送信のための処理２４８はスキップする。もし、存在していなければ、メッセージ応答手段３１２ａは、メッセージ格納領域３１４で応答メッセージを組み立てる（ステップＳ２４８）。

次に受信処理の終了処理であるステップＳ２５０について説明する。

第１の実施形態では、メッセージ応答手段３１２は、メッセージ格納領域３１４のメッセージを、サーバ通信手段３００を通して、応答メッセージとして送信する（ステップＳ１４８）。第２の実施形態では、メッセージ応答手段３１２ａは、メッセージ格納領域３１４ａのメッセージのｔｏフィールドを要求メッセージ発信者として追記し、通信手段を通して、応答メッセージを送信する（ステップＳ２５０）。このメッセージ取得応答メッセージの例を以下のメッセージ例２３に示す。これは、（メッセージ例２１）で見たとおり、第２の実施形態では、メッセージバッファ３２０中の推奨番組メッセージにはｔｏフィールドが書き込まれていない。第２の実施形態では受信処理が始まった時点で宛先が決まるため、ステップＳ２５０でｔｏフィールドを追記する。

（メッセージ例２３：メッセージ取得応答）
<Transmission>
<from uid=“fukuta”/>
<to uid=“ohira”/><!-“to” is inserted -->
<TTL>1</TTL> <!- 0,1,2,…-->
<path uid=“tanaka” time=“2005.03.24.22.01.13”/>
<path uid=“fukuda” time=“2005.03.24.23.02.13”/>
</Transmission>
<Authenticates>
<uid>tanaka</uid>
<passwd>6ad35d</passwd>
</Authenticates>
<!- 応答メッセージペイロード例 -->
<Operation code=“send”>
<Programs>
<Program>
<name id=“あるある大辞典” />
<StartTime date=“2004.03.24 Sun 21:00”</>
<Period period=“2:00”/>
<Channel no=“6” />
<region code=“32”/>
</Program>
<Program>
<name id=“WBS” />
<StartTime date=“2004.03.24 Sun 21:00”</>
<Period period=“2:00”/>
<Channel no=“6” />
<region code=“32”/>
</Program>
</ Programs >
</operation>

第２の実施形態での、ステップＳ２５１からステップＳ２５６までの処理は、第１の実施形態のステップＳ１４９からステップＳ１５４と同一であるため、説明を省略する。

次に、本発明の第３の実施形態について図面を参照して詳細に説明する。図２６を参照すると、本発明の第３の実施形態は、第２の実施形態に加えて、近日放送される番組名を縦軸に、地域コードを横軸におく番組対応表３６０と、モバイル端末からのメッセージ取得要求を受理し、推奨番組メッセージを検索し、番組対応表を検索することで、推奨番組情報を地域コードに応じて変換し、応答を返すメッセージ応答手段３１２ｂを第２の実施形態のメッセージ応答手段３１２ａの代わりに使用し、構成される。

次に、本実施形態の効果について説明する。番組対応表３６０は、口コミＡＳＰ３０がビジネスとして責任をもって内容を保守することで、メッセージ応答手段３１２ｂは、メッセージ取得要求を受信すると、番組対応表３６０から正確に対応番組を検索することができる。第１の実施形態や第２の実施形態がモバイル端末１１で番組名で番組表を検索することに比べて、正確に地域コードにあわせた推奨番組情報の変換を行うことができる。

次に、図２８から図３１のフローチャートを参照して本実施形態の全体の動作について詳細に説明する。モバイル端末１１からのメッセージ取得要求の受信し、該当推奨番組メッセージを応答する受信処理の他の処理については、第２の実施形態と同等のため、異なる受信処理の動作について説明する。

ステップＳ３３１からＳ３４８までは、第２の実施形態と同一であるため、説明を省略する。メッセージ応答手段３１２ｂがメッセージ格納領域３１４中の推奨番組情報をモバイル端末が位置する地域コードに合わせて変換する、後述の地域差修正処理２を呼ぶ（ステップＳ３４９）。その後、ステップＳ３５０は、第２の実施形態と同一であるため、説明を省略する。また、受信処理の終了のための手順に相当するステップＳ３５１からステップＳ３６１は、第２の実施形態と同一であるため、説明を省略する。

次に、図３２のフローチャートを参照して地域差修正処理２の動作について詳細に説明する。メッセージ応答手段３１２ｂは、メッセージ格納領域３１４中のメッセージの番組情報と地域コードを取得する（ステップＳ３４９ａ）。メッセージ応答手段３１２ｂは、取得した番組名と地域コードをもとに、番組対応表３６０を検索し、放送時刻・時間・チャネルが一致するエントリを発見する（ステップＳ３４９ｂ）。メッセージ応答手段３１２ｂは、得たエントリの行のうち、と受信要求メッセージ中の地域コードの列のエントリの時刻・時間・チャネルを得る（ステップＳ３４９ｃ）。メッセージ応答手段３１２ｂは、得た時刻・時間・チャネルでメッセージ格納領域３１４中のメッセージを書き直す（ステップＳ３４９ｄ）。

次に、具体的な実施例を用いて本発明の動作を説明する。図３３に示すように、ｔａｎａｋａさんが、モバイル端末向けＥＰＧ配信ＡＳＰ４０からダウンロードした電子番組表（ＥＰＧ）をモバイル端末１１でブラウズし、お勧めボタンを押すと想定する。その際、推奨番組情報は、ｔａｎａｋａさんのお友達であるｆｕｋｕｄａさん、そして、ｆｕｋｕｄａさんの友達であるｏｈｉｒａさん、と伝わると想定する。ただし、ｏｈｉｒａさんの友人であるｓｕｚｕｋｉさんにはホップ数が３となり、ホップ数過多でメッセージが伝わらないとする。

最初に第１の実施形態で考える。ｔａｎａｋａさんは、表示されている番組表から番組を選び、「他の人に推薦ボタン」を押す（図４のステップＳ１０１）。番組表制御ＵＩ２００は、ＧＰＳから得た位置情報をもとに、位置・地域コード対応表２２０を検索し、現位置に対応する地域コード３２を得る（ステップＳ１０２）。

番組表制御ＵＩ２００は、推薦ボタンを押された番組情報（番組名「あるある大辞典」、チャネル８、２００５年３月２４日（日）２１：００と１：００）と、地域コード（３２）をもとに、推奨番組メッセージを作成し推奨番組メッセージ記憶手段１１５に置くとともに、コミュニティ同報クライアント１１０に伝える（ステップＳ１０３）。送信処理１では、（メッセージ例１１）で示すメッセージを口コミＡＳＰ３０に送信する。これに対応する推奨番組メッセージが（メッセージ例１１）である。Ｐａｔｈフィールドは送信者であるｔａｎａｋａさん、受信者であるｆｕｋｕｄａさんが記載されている。コミュニティ同報クライアント１１０内の推奨番組メッセージ作成手段１１２は、認証クライアント１１１に口コミＡＳＰ３０への認証処理を依頼する（図５のステップＳ１１１）。そして、認証処理を行う（ステップＳ１１２）。すなわち、認証クライアント１１１は、設定された利用者識別子（ＵＩＤ）１３１であるｔａｎａｋａ、パスワード１３２である６ａｄ３５ｄをもとに認証メッセージを作成。クライアント通信手段１００に渡す（図１２のステップＳ１６１）。

クライアント通信手段１００は、サーバ通信手段３００に認証メッセージを渡す（ステップＳ１６２）。サーバ通信手段３００は認証手段３３０に認証メッセージを渡す（ステップＳ１６３）。認証手段３３０は、認証メッセージを渡し、アカウントリスト３４０からＵＩＤｔａｎａｋａに対応したパスワード６ａｄ３５ｄを引く（ステップＳ１６４）。メッセージ中のアカウントｔａｎａｋａとパスワード６ａｄ３５ｄが、アカウントリスト３４０のアカウントｔａｎａｋａとパスワード６ａｄ３５ｄと一致したので、認証は成功する。

推奨番組メッセージ作成手段１１２は、推奨番組メッセージ記憶手段１１５から推奨番組メッセージを読み取る（図５のステップＳ１１６）。推奨番組メッセージのＴＴＬは当初１に設定されているので、ＴＴＬ閾値１１４が２以下であるので、メッセージは破棄されない。しかし、図６で示すようにｏｈｉｒａさんからｓｕｚｕｋｉさんに伝播するときはＴＴＬフィールドが３になっているため、メッセージは破棄される。推奨番組メッセージ作成手段１１２は、友人リストエントリＩＤ１１３が指す友人リスト１２０の行を取得する。先頭の行がｆｕｋｕｄａさんのため、ｆｕｋｕｄａさんへの送信を行う。この後、順次ｙａｍａｄａ，ｋａｗａｓａｋｉさんに送信される。当初、推奨番組メッセージ記憶手段１１５中の番組推奨メッセージは、ｆｕｋｕｄａさんに関するｐａｔｈフィールドは存在しないため、メッセージは破棄されない。推奨番組メッセージ作成手段１１２は、番組推奨メッセージにｔｏフィールドとしてｆｕｋｕｄａを埋め込み、推奨番組メッセージを口コミＡＳＰ３０に送信する（図６のステップＳ１２４）。推奨番組メッセージ受信手段Ｓ３１１は、受信したメッセージをメッセージバッファ３２０に追記する。また、メッセージ一覧表に宛先ＵＩＤｆｕｋｕｄａで登録する（ステップＳ１２５）。

口コミＡＳＰ３０内のメッセージバッファに配置された推奨番組情報は、ｆｕｋｕｄａさんのモバイル端末１２が定期的に口コミＡＳＰ３０にポーリングすることで、取得される。すなわち、モバイル端末１２内のコミュニティ同報クライアント１１０中のタイマーＣ１１７は、定期的に推奨番組メッセージ受信手段１１６を起動する（図７のステップＳ１３１）。推奨番組メッセージ受信手段１１６は、アカウントｆｕｋｕｄａ、パスワードｋＲｄｋａ４８１Ｔで認証クライアント１１１に口コミＡＳＰ３０への認証処理を依頼する（ステップＳ１３２）。そして、認証処理を行う（ステップＳ１３３）。認証に成功した場合、推奨番組メッセージ受信手段１１６は、（メッセージ例１２）に示す口コミＡＳＰ３０にメッセージ取得要求を、クライアント通信手段１００を介して、発行する（ステップＳ１３７）。メッセージ応答手段３１２は、メッセージ一覧から宛先ＵＩＤがｆｕｋｕｄａである推奨番組メッセージを検索する。発見した推奨番組メッセージは、メッセージバッファ３２０およびメッセージ一覧表３１５から削除し、メッセージ格納領域３１４でメッセージを組み立てる（図８のステップＳ１４５）。

すべてのメッセージ一覧表を検索し終えると、メッセージ応答手段３１２は、メッセージ格納領域３１４のメッセージを、サーバ通信手段３００を通して、応答メッセージを送信する（図９のステップＳ１４８）。このメッセージ取得応答メッセージの例を（メッセージ例１３）に示す。推奨番組メッセージ受信手段１１６は、口コミＡＳＰ３０からのメッセージ取得応答を、クライアント通信手段１００を通して受信する（ステップＳ１４９）。推奨番組メッセージ受信手段１１６は、受信したメッセージを推奨番組メッセージ記憶手段１１５に記録。そして、番組表制御ＵＩ２００に通知する（ステップＳ１５０）。次に後述の地域差修正処理を呼び出す（ステップＳ１５１）。すなわち、ＧＰＳの現在の地域コード３２と推奨番組の地域コード３２を比べて、異なる場合は携帯電話ＧＰＳの現在位置の番組表から“あるある大辞典”という番組名を発見し、その値で推奨番組メッセージを書き換える。このようにｆｕｋｕｄａさんに転送されたメッセージは、ｆｕｋｕｄａさんにおいて再び送信処理が行われて、ｆｕｋｕｄａさんの友人リストからｏｈｉｒａさんが発見され、ｏｈｉｒａさんに転送される。

次にメッセージ一覧表３１５及びメッセージバッファ３２０から古いメッセージを削除するタイムアウト処理を説明する。図３のメッセージ一覧表の＃１行のエントリの登録時刻は、２００５年１月２日である。Ｎａｋａｔａさんのモバイル端末が故障などの理由でとりにこれないことを想定している。このとき、タイマー３１７は、一定周期、例えば１日ごとにメッセージ削除手段３１６を起動する（図１３のステップＳ１８１）。メッセージ削除手段３１６は現在の時刻からある一定時間例えば２日、を引き、削除時刻を求める（ステップＳ１８２）。＃１行目の登録時刻は２ヶ月以上前のため、このメッセージは、メッセージバッファ３２０及びメッセージ一覧表３１５から削除する（ステップＳ１８３）。

次に図１４のフローチャートを参照して本実施形態のうち、モバイル端末１１からインターネット予約機能付きレコーダ２１を予約する処理について説明する。ｆｕｋｕｄａさんは、番組表制御ＵＩ２００の推薦番組一覧表から番組をモバイル端末１２で視聴する番組「あるある大辞典」を選択し、家での録画処理を選択する（ステップＳ１９１）。番組表取得クライアント１４０は、自宅地域コード３３における番組名検索をモバイル端末向けＥＰＧ配信ＡＳＰ４０に依頼（ステップＳ１９３）し、自宅のある多摩地区ではたまたま東京地区と同じく２００５年３月２３日（日）２１：００から２時間８チャネルで放送されることがわかる（ステップＳ１９４）。この情報をもとに、番組表制御ＵＩ２００は、番組予約クライアント１９０に予約を依頼、番組予約クライアント１９０は、インターネット予約付きレコーダ２１に予約を登録する（ステップＳ１９６）。

次に第２の実施形態においての特徴は、モバイル端末側では、友人リスト１２０の検索を行わず、口コミＡＳＰ３０側の友人リストで転送されることである。例えば、ｔａｎａｋａさんからｆｕｋｕｄａさんにメッセージが送信される場合、（メッセージ例２１）で示す推奨番組メッセージのようにｔａｎａｋａさんは、宛先（ｔｏフィールド）にｆｕｋｕｄａを指定せず口コミＡＳＰ３０に送信する（図２１のステップＳ２１９）。

送信された推奨録画メッセージは、メッセージバッファ３２０に記録され、その場所は、メッセージ一覧表３１５ａの＃０行のように、発信者ＵＩＤであるｔａｎａｋａが登録される（図２１のステップＳ２２０）。

ｆｕｋｕｄａから（メッセージ例２２）のメッセージ取得要求を送信する（ステップＳ２２１）と、図１７の友人関係リスト３５０からｆｕｋｕｄａさんに送信する利用者のＵＩＤであるｔａｎａｋａ，ｋａｗａｓａｋｉを得る。そこで、メッセージ一覧表３１５ａから送信者がｔａｎａｋａもしくはｋａｗａｓａｋｉのメッセージを検索する。その結果、メッセージ一覧表３１５ａの＃０行目のメッセージポインタが指す推奨番組メッセージをコピーし、さらに他の検索されたメッセージともに（メッセージ例２２）で示す応答メッセージとして応答する。

次に第３の実施形態による特徴は、地域差修正処理をモバイル端末側で行わず、口コミＡＳＰ３０で行うことである。すなわち、メッセージ応答手段３１２ｂはｆｕｋｕｄａさんの推奨番組として東京（地域コード＝３２）での「あるある大辞典」という番組がｏｈｉｒａさんの居る札幌（地域コード０５）では、１０：３０から４チャネルであることを変換して（図３２のステップＳ３４９ａ〜Ｓ３４９ｄ）伝える。

本発明によれば、携帯電話などのモバイル端末と口コミＡＳＰといったＡＳＰの連携によるビジネスの展開に使用できる。

本発明の第１の実施形態の構成を示すブロック図である。 第１の実施形態の構成の詳細を示すブロック図である。 第１の実施形態の構成の詳細を示すブロック図である。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第１の実施形態の動作を示すフローチャートである。 第２の実施形態の構成を示すブロック図である。 第２の実施形態の構成の詳細を示すブロック図である。 第２の実施形態の構成の詳細を示すブロック図である。 第１〜３の実施形態で、共通に利用される推奨リストである。 第２の実施形態の動作を示すフローチャートである。 第２の実施形態の動作を示すフローチャートである。 第２の実施形態の動作を示すフローチャートである。 第２の実施形態の動作を示すフローチャートである。 第２の実施形態の動作を示すフローチャートである。 第２の実施形態の動作を示すフローチャートである。 第２の実施形態の動作を示すフローチャートである。 第３の実施形態の構成を示すブロック図である。 第３の実施形態の構成の詳細を示すブロック図である。 第３の実施形態の動作を示すフローチャートである。 第３の実施形態の動作を示すフローチャートである。 第３の実施形態の動作を示すフローチャートである。 第３の実施形態の動作を示すフローチャートである。 第３の実施形態の動作を示すフローチャートである。 本発明の実施例を示す図である。 従来のシステムを示す図である。

符号の説明

１１，１２ モバイル端末
２１，２２ インターネット予約付きレコーダ
３０ 口コミＡＳＰ
４０ モバイル端末向けＥＰＧ配信ＡＳＰ
５０ ネットワーク

Claims (9)

1. モバイル端末と口コミ・アプリケーション・サービス・プロバイダ（ＡＳＰ）とがネットワーク接続されたシステムであって、
   前記モバイル端末は、利用者の友人を登録する友人リストとコミュニティ同報クライアントを備え、
   前記口コミＡＳＰは、コミュニティ同報サーバを備え、
   前記コミュニティ同報クライアントは、
   前記コミュニティ同報サーバから送信された推奨番組メッセージを受信する推薦番組メッセージ受信手段と、
   この推薦番組メッセージ受信手段が受信した推奨番組メッセージ又は利用者が電子番組表から選択した推奨番組情報を含むメッセージを格納する推奨番組メッセージ記憶手段と、
   この推奨番組メッセージ記憶手段に格納した推奨番組メッセージを友人リストに登録された友人ＩＤを指定して前記コミュニティ同報サーバに転送する推薦メッセージ作成手段とを有し、
   前記コミュニティ同報サーバは、
   前記コミュニティ同報クライアントから推奨番組メッセージを受信する推奨番組メッセージ受信手段と、
   前記友人ＩＤに対応するモバイル端末からメッセージ取得要求を受信し、推奨番組メッセージを応答するメッセージ応答手段とを有することを特徴とする推奨番組情報活用型視聴支援システム。
2. モバイル端末と口コミＡＳＰとがネットワーク接続されたシステムであって、
   前記モバイル端末は、コミュニティ同報クライアントを備え、
   前記口コミＡＳＰは、推奨番組メッセージの宛先となり得るユーザＩＤとそのユーザを友達として指定する友達ユーザＩＤの組からなる友人関係リストとコミュニティ同報サーバを備え、
   前記コミュニティ同報クライアントは、
   前記コミュニティ同報サーバから送信された推奨番組メッセージを受信する推薦番組メッセージ受信手段と、
   この推薦番組メッセージ受信手段が受信した推奨番組メッセージ又は利用者が電子番組表から選択した推奨番組情報を含むメッセージを格納する推奨番組メッセージ記憶手段と、
   この推奨番組メッセージ記憶手段に格納した推奨番組メッセージに発信者ＩＤを付して前記コミュニティ同報サーバに転送する推薦メッセージ作成手段とを有し、
   前記コミュニティ同報サーバは、
   前記コミュニティ同報クライアントから推奨番組メッセージを受信する推奨番組メッセージ受信手段と、
   前記友人関係リストを検索して発信者ＩＤに対応するユーザＩＤのモバイル端末からメッセージ取得要求を受信し、推奨番組メッセージを応答するメッセージ応答手段とを有することを特徴とする推奨番組情報活用型視聴支援システム。
3. 前記モバイル端末は、現在の位置を与える現在位置特定手段と、
   現在の位置と放送における地域コードを対応させた位置・地域コード対応表とをさらに備え、
   現在の位置を示す地域コードに応じて推奨番組メッセージを作成することを特徴とする請求項１又は２に記載の推奨番組情報活用型視聴支援システム。
4. ネットワークを介して電子番組表を提供するＥＰＧ配信アプリケーション・サービス・プロバイダ（ＡＳＰ）と、
   前記モバイル端末にて、指定された地域コードに応じて前記ＥＰＧ配信ＡＳＰから電子番組表をダウンロードする番組表取得クライアントとをさらに備えることを特徴とする請求項１又は２に記載の推奨番組情報活用型視聴支援システム。
5. 近日放送される番組名と地域コードを対応させた番組対応表をさらに備え、
   前記コミュニティ同報サーバが、前記モバイル端末からのメッセージ取得要求を受信し、前記番組対応表を検索して、前記推奨番組メッセージに含まれる推奨番組情報を地域コードに応じて変換し、応答を返すことを特徴とする請求項２に記載の推奨番組情報活用型視聴支援システム。
6. コミュニティ同報クライアントとコミュニティ同報サーバとがネットワーク接続されたシステムにおける推奨番組情報活用型視聴支援方法であって、
   前記コミュニティ同報クライアントにて、電子番組表から推奨番組を選択し、
   選択された推奨番組情報と、利用者の友人を登録する友人リストに登録された宛先を含む推奨番組メッセージを作成して、前記コミュニティ同報サーバに送り、
   前記コミュニティ同報サーバから前記推奨番組メッセージに含まれる宛先に推奨番組情報を配信することを特徴とする推奨番組情報活用型視聴支援方法。
7. コミュニティ同報クライアントとコミュニティ同報サーバとがネットワーク接続されたシステムにおける推奨番組情報活用型視聴支援方法であって、
   前記コミュニティ同報クライアントにて、電子番組表から推奨番組を選択し、
   選択された推奨番組情報と発信者ＩＤを含む推奨番組メッセージを作成して、前記コミュニティ同報サーバに送り、
   前記コミュニティ同報サーバにて、推奨番組メッセージの宛先となり得るユーザＩＤとそのユーザを友達として指定する友達ユーザＩＤの組からなる友人関係リストを検索して推奨番組メッセージに含まれる発信者ＩＤに対応する宛先に推奨番組情報を配信することを特徴とする推奨番組情報活用型視聴支援方法。
8. コミュニティ同報クライアントとコミュニティ同報サーバとがネットワーク接続されたシステムを構築するための推奨番組情報活用型視聴支援プログラムであって、
   前記モバイル端末に、電子番組表から推奨番組を選択する機能と、
   選択された推奨番組情報と、利用者の友人を登録する友人リストに登録された宛先を含む推奨番組メッセージを作成して、前記コミュニティ同報サーバに送る機能を実現させ、
   前記コミュニティ同報サーバに、前記推奨番組メッセージに含まれる宛先に推奨番組情報を配信する機能を実現させることを特徴とする推奨番組情報活用型視聴支援プログラム。
9. コミュニティ同報クライアントとコミュニティ同報サーバとがネットワーク接続されたシステムを構築するための推奨番組情報活用型視聴支援プログラムであって、
   前記モバイル端末に、電子番組表から推奨番組を選択する機能と、
   選択された推奨番組情報と発信者ＩＤを含む推奨番組メッセージを作成して、前記コミュニティ同報サーバに送る機能を実現させ、
   前記コミュニティ同報サーバに、推奨番組メッセージの宛先となり得るユーザＩＤとそのユーザを友達として指定する友達ユーザＩＤの組からなる友人関係リストを検索して推奨番組メッセージに含まれる発信者ＩＤに対応する宛先に推奨番組情報を配信する機能を実現させることを特徴とする推奨番組情報活用型視聴支援プログラム。

Images