(57)【要約】【課題】  モバイル環境からのコミュニティアクセスを容易にする。【解決手段】  インデックスＤＢ１７には話題インデックス生成部１０によって生成された位置および話題が格納されている。ユーザＤＢ１８にはユーザ特徴生成部１１によって生成された、投稿ユーザの特徴が格納されている。地名ＤＢ１９には地名が記憶されている。地名変換部１３は端末装置３の位置情報から地名ＤＢ１９を参照して、該位置情報の地名を取得する。検索要求部１４は端末装置３からのユーザの要求と、取得された地名から望む情報をインデックスＤＢ１７とユーザＤＢ１８から検索する。コンテンツ生成部１５は検索結果を端末装置３に合わせた形態に変換する。【選択図】    図１
2005071027.tif 000002
【特許請求の範囲】
【請求項１】
既存コミュニティに対するモバイル環境からのアクセスを容易にするコミュニティ位置インデックスサーバであって、
前記既存コミュニティの投稿データから位置および話題を抽出する話題インデックス生成部と、
抽出された位置および話題を記憶するインデックスＤＢと、
前記既存コミュニティ投稿データから投稿ユーザの特徴を抽出するユーザ特徴生成部と、
前記投稿ユーザの特徴を記憶するユーザＤＢと、
端末との間の通信を行う通信部と、
地名を記憶した地名ＤＢと、
前記通信部で受信した、端末の位置情報から前記地名ＤＢを参照して、該位置情報の地名を取得する地名変換部と、
前記通信部で受信した、端末からのユーザの要求と、前記取得された地名から望む情報を前記インデックスＤＢと前記ユーザＤＢから検索する検索要求部と、
検索結果を端末に合わせた形態に変換するコンテンツ生成部を有するコミュニティ位置インデックスサーバ。
【請求項２】
前記話題インデックス生成部は、既存コミュニティの投稿データから地名情報を抽出し、都道府県／市区町村／それ以下といったレイヤ分け、出現頻度による重み付けによって演算される位置特性関数を算出する、請求項１に記載のコミュニティ位置インデックスサーバ。
【請求項３】
前記話題インデックス生成部は、前記位置特性関数と、前記インデックスＤＢ内の情報の位置特性関数との間で位置相関係数を求めることで、位置に関わる投稿情報間の関連づけを行う、請求項２に記載のコミュニティ位置インデックスサーバ。
【請求項４】
前記話題インデックス生成部は、投稿データからキーワードを抽出し、その出現頻度として前記インデックスＤＢに記憶し、またスレッド情報を前記インデックスＤＢに記憶する、請求項１から３のいずれかに記載のコミュニティ位置インデックスサーバ。
【請求項５】
前記検索要求部は、情報検索の際に、位置情報に合致する位置関連の高い投稿と、カテゴリに合致するキーワードまたはスレッド名を持つ投稿とを検索結果候補として抽出し、さらに、各投稿に対して位置情報およびカテゴリによって絞り込んで検索結果とする、請求項１から４のいずれかに記載のコミュニティ位置インデックスサーバ。
【請求項６】
前記検索要求部は、前記インデックスＤＢ内に合致する情報がない場合には、過去の投稿から位置情報またはカテゴリに造詣の深い投稿者をユーザＤＢから抽出し、その投稿者の過去の投稿から情報を引き出す、請求項１から５のいずれかに記載のコミュニティ位置インデックスサーバ。
【請求項７】
前記コンテンツ生成部は、ユーザの要求に合致する既存投稿が存在しない場合には、造詣の深い投稿者に対して問い合わせを行う、請求項６に記載のコミュニティ位置インデックスサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコミュニティシステムに関する。
【背景技術】
【０００２】
昨今のメーリングリストや掲示板、Ｐ２Ｐソフトウェアによるデジタルコミュニティの普及には著しいものがある。従来、これら口コミ情報は、情報誌などコンテンツベンダが取りまとめを行って流通させることで広く流布させることが可能であった。しかしながらインタネット上のコミュニティ環境の充実に伴って、個人レベルでの情報発信・受信・やりとりがリアルタイムで可能となり、通常の調べものではこれらコミュニティの情報を縦覧するだけでもかなりの情報を集めることが可能となってきている。
【０００３】
一方、モバイル技術の発達により、いつでもどこでもインタネット環境にアクセスすることが可能となってきている。そのような状況の中、モバイル環境におけるコミュニティに関して色々な研究やサービスが行われるようになってきた。位置に関連したコミュニティについては様々な研究がなされている（非特許文献１、非特許文献２）。
【非特許文献１】時空間限定オブジェクトシステムＳｐａｃｅ  Ｔａｇ：プロトタイプシステムの設計と実装、森下健、中尾恵、垂水浩幸、上林弥彦、情報処理学会論文誌、Ｖｏｌ．４１  Ｎｏ．１０、Ｏｃｔ．２０００
【非特許文献２】実世界コンテキストに埋め込まれたコミュニティウェア、角康之、間瀬健二、情報処理学会論文誌、Ｖｏｌ．４１  Ｎｏ．１０、Ｏｃｔ．２０００
【非特許文献３】Ｇ−ＢＯＯＫ（伝言板・掲示板）、http://g-book.com/pc/whats_G-Book/
【発明の開示】
【発明が解決しようとする課題】
【０００４】
これらの研究では新規にコミュニティを起こして、その中での情報の授受を行ってユーザの利便を図ることを目的としている。
【０００５】
しかしながら、コミュニティは数の論理で活性化がなされるものであり、情報の存在しないコミュニティは投稿者が枯渇して寂れてしまい、ついには死滅してしまう。上記のサービスは、展示会といったようなバースト的かつテンポラリに情報の錯綜するシチュエーションをターゲットとしているため、利用するユーザの利用意識の高さからこのような問題を回避していると考えられる。しかし、日常での利用におけるコミュニティの活性化といった観点での議論は不足していると考える。
【０００６】
自動車内で利用することを主眼としたコミュニティとして非特許文献３に開示されたようなサービスが行われている。
【０００７】
これは、自動車内だけでなく、ＰＣやＰＤＡ（Personal Digital Assistants）、携帯電話からもアクセス可能とすることでコミュニティの活性化を図っている。しかし、自動車内で利用可能なコミュニティをＰＣやＰＤＡ、携帯電話からもアクセス可能というアプローチであり、既存の膨大なコミュニティとの連携は考慮されていない。
【０００８】
本発明の目的は、モバイル（特に自動車）からのコミュニティアクセスを容易にするコミュニティ位置インデックスサーバを提供することにある。
【課題を解決するための手段】
【０００９】
本発明のコミュニティ位置インデックスサーバは、
既存コミュニティの投稿データから位置および話題を抽出する話題インデックス生成部と、
抽出された位置および話題を記憶するインデックスＤＢと、
前記既存コミュニティ投稿データから投稿ユーザの特徴を抽出するユーザ特徴生成部と、
前記投稿ユーザの特徴を記憶するユーザＤＢと、
端末との間の通信を行う通信部と、
地名を記憶した地名ＤＢと、
前記通信部で受信した、端末の位置情報から前記地名ＤＢを参照して、該位置情報の地名を取得する地名変換部と、
前記通信部で受信した、端末からのユーザの要求と、前記取得された地名から望む情報を前記インデックスＤＢと前記ユーザＤＢから検索する検索要求部と、
検索結果を端末に合わせた形態に変換するコンテンツ生成部を有する。
【発明の効果】
【００１０】
本発明は、既存コミュニティを位置やキーワードによってインデックス付けをすることで、モバイル環境（特に自動車内）からのコミュニティアクセスが容易になる効果がある。
【発明を実施するための最良の形態】
【００１１】
次に、本発明の実施の形態について図面を参照して説明する。
【００１２】
図１は本発明の一実施形態のコミュニティ位置インデックスサーバを含むコミュニティインデックスシステムの構成図である。
【００１３】
本実施形態のコミュニティ位置インデックスサーバ（以下、サーバと称す）１は話題インデックス生成部１０とユーザ特徴生成部１１と通信部１２と地名変換部１３と検索要求部１４とコンテンツ生成部１５とユーザ問合せ部１６とインデックスＤＢ１７とユーザＤＢ１８と地名ＤＢ１９を有している。
【００１４】
サーバ１はインタネット上などの既存コミュニティのデータ２を取得すると、そのデータを話題インデックス生成部１０とユーザ特徴生成部１１に渡す。
【００１５】
話題インデックス生成部１０は、投稿データから、投稿日時、地名名詞、固有名詞を抽出する。また、スレッド情報（電子メールでのＩｎ−Ｒｅｐｌｙ−ＴｏやＲｅｆｅｒｅｎｃｅなど）が付加されていれば、それも抽出する。話題インデックス生成部１０は、これら抽出された値を元に、情報の関連づけ＝インデキシングを行う。このインデキシングは、位置インデキシング、トピックインデキシング、スレッドインデキシングに分類される。スレッドインデキシングは電子メールやＷｅｂ掲示板で行われているスレッド管理である。本発明では、位置インデキシングとトピックインデックスを提供することを特徴とすると共に、これらをスレッドインデキシングと併用することで効果のさらなる向上を狙っている。
【００１６】
以下、本発明の特徴である位置インデキシングについて説明する。
位置インデキシングは大きく分けて、Ａ．位置特性関数算出と、Ｂ．位置相関係数算出と、Ｃ．位置特性関数追加の３つのプロセスからなる。
Ａ．位置特性関数算出
新規に取得した投稿情報を処理して位置特性関数を算出することを指す。
Ｂ．位置相関係数算出
インデックスＤＢ１７内の既存位置インデックスと新規投稿情報との位置相関係数を算出し、閾値を越える既存位置インデックスを求める。
Ｃ．位置特性関数追加
閾値を越える既存位置インデックスに新規投稿情報を追加し、位置インデックスの新しい位置特徴関数を算出し、位置特徴関数を更新する。
【００１７】
まず、位置特性関数の算出方法を図２を用いて説明する。
１．投稿データ本文を形態素解析などにかけ、地名を表す名詞を抽出し、その出現回数を合わせて記憶する。
２．例えば、郵便番号の区分に従って、都道府県、市町村、それ以下のレイヤ分けを行い、その地名の出現回数をその重みとする。その際に、上位のレイヤを位置特性関数に必ず追加し、個々で追加した上位レイヤの重みはゼロとする。図２の２においては、愛知県、茨城県行方郡、茨城県、佐賀県西松浦郡、佐賀県、千葉県千葉市、が追加された上位レイヤになる。
３．重みおよびレイヤ関係に応じてソートする。これを「位置特性関数」と定義する。
【００１８】
原則として、各レイヤの同じ値（地名）は連続するように配置する。神奈川県横須賀市が上の方にあって、間に他の県が存在して、下の方に神奈川県横浜市が存在する、という状態にならないようにする。図２を用いて説明する。
【００１９】
まず、最も出現回数の多い「愛知県豊橋市」（４）が選ばれる。次に、これの上位レイヤを順に記載する。愛知県のレイヤ２は上記だけなので、次に記載されるのは愛知県になる。
【００２０】
続いて、次に出現回数の多い「茨城県取手市」（２）と「佐賀県西松浦郡有田町」（２）が比較の俎上に登る。ここでは上位レイヤにさかのぼって出現回数を見てゆく。「茨城県」（０）、「佐賀県西松浦郡」（０）、「佐賀県」（０）であるので、同条件である。そこで、レイヤトポロジーとして近いモノを見る。「茨城県行方郡玉造町」（１）があるので、「茨城県取手市」（２）から始まる茨城県系が愛知県系の次に記載されることになる。続いて佐賀県系が記載され、最後に千葉県系となる。
【００２１】
続いて、位置特性関数同士の類似度を示す位置相関係数の算出方法を図３を用いて説明する。
０．インデックスＤＢ１７に格納されている位置インデックスには最後に更新されたタイムスタンプが登録されている。新規追加する投稿情報のタイムスタンプと位置インデックスのタイムスタンプとの差分を求め、これに減算係数をかけた値をそれぞれの地名レイヤの重みから減算する。下位レイヤの地名の重みがゼロを下回った地名は消去される。例えば減算係数＝１／３０であれば、３０日間更新されなかった地名の重みは１減算される。
１．図に示すような２つの位置特性関数の位置相関係数を求める。
【００２２】
図３の２のそれぞれを数列として考えると、｛１，０，０，２，４，０，０，０，０，０，０，２，０，０，１，０，１｝と｛２，０，１，０，０，２，０，２，０，１，０，０，０，０，０，０，０，０｝となる。この２つの相関を求めたものを位置相関係数と呼ぶ（相関の計算自体は公知の方法が使える）。
２．地名をマージした拡張位置特性関数を作成する。基本的には最小公倍数的に地名をマージしたものとなる。このとき、それぞれを基準とした拡張位置特性関数対を作成する。拡張位置特性関数は、位置特性関数間の相関を求めるために便宜的・一時的に作成するものである。したがって、意味的には位置特性関数間の位置相関係数であるが、それは計算上、拡張位置特性関数を使うことで求められる。図は大阪府を含む位置特性関数を基準とした拡張位置特性関数対である。
３．２つの拡張位置特性関数対間の相関係数のうち値の大きいものを「位置相関係数」と定義する。図３の例の場合は０．４７１である。
位置相関係数は−１〜１の値を取り、１に近いほど２つの位置特性関数の類似度が高いことになる。
【００２３】
次に、位置特性関数の追加について説明する。
１．追加される新規投稿情報をマージした位置特性関数を求める。その際に、位置インデックスの各地名の重みに新規投稿情報の地名の重みを加算する。
２．位置インデックスのタイムスタンプを新規投稿情報のタイムスタンプとする。
【００２４】
位置相関係数が一定値以上のデータがインデックスＤＢ１７に無い場合には新規レコードとして当該投稿の位置相関係数などをインデックスＤＢ１７に登録する。
【００２５】
トピックインデックスは、レイヤが存在しないことを除けば、位置インデックスとほぼ同様に算出される。トピックとは、投稿情報中に含まれる固有名詞・一般名詞であり、これの出現頻度から位置インデックスと同様に投稿情報に対してインデックス付与がなされる。
【００２６】
このようにして、インデックスＤＢ１７には、位置インデックスとトピックインデックスとスレッドインデックスが格納される。格納形式例を図４に示す。
【００２７】
また、新規投稿情報はユーザ特徴生成部１１に送られ、投稿ユーザの特徴を抽出しそれをユーザＤＢ１８に保管またはユーザＤＢ１８の特徴を更新する処理が行われる。ユーザ特徴生成部１１の処理は以下の点を除いて話題インデックス生成部１０の動作と同一である。
相違点：
Ａ．減算係数と最終更新からの経過日時を用いた減算結果が０を下回る地名についても、「過去にこの話題に精通した」という履歴の意味からＨｉｓｔｏｒｉｃａｌ  Ｐｏｓｉｔｉｏｎ（履歴位置）として記憶する。このため重みが０を下回らないＬｉｖｅ  Ｐｏｓｉｔｉｏｎ（現在位置）についても重みと同様に出現回数を記憶する。
Ｂ．コミュニティにおいては投稿回数が重要なパラメータとなるため、投稿回数もユーザＤＢ１８内に記憶する。
Ｃ．位置情報とキーワード情報の双方をユーザＤＢ１８に格納する。
ユーザＤＢ１８の構成例を図５に示す。
【００２８】
以上が、コミュニティに投稿がなされた場合、またはコミュニティの過去ログからユーザＤＢ１８およびインデックスＤＢ１７を生成するプロセスである。
【００２９】
次に、自動車内からのアクセスについて説明する。自動車内からの情報検索要求は、ＧＰＳの示す緯度経度情報と、カテゴリ（キーワード）情報の組で端末装置３からサーバ１に送信される。このカテゴリ（キーワード）は、事前にユーザが登録しておく方法や、検索時に簡単なキーワードを音声認識で入力する方法などが考えられる。ユーザが入力したカテゴリ（キーワード）情報は入出力インタフェース３１から演算処理部３３に送られ、そこでＧＰＳユニット３２からのＧＰＳ情報といっしょに通信部３４を介してサーバ１に送信される。
【００３０】
サーバ１では、通信部１２で受信したＧＰＳ情報から地名を抽出する。これは、地名ＤＢ１９と地名変換部１３により行われる。ここでは、併せてレイヤ変換の作業も行われる。レイヤ変換とは、「久里浜」という地名が発見された場合に、これのレイヤを算出すると共に上位レイヤも抽出する作業である。内容は話題インデックス生成部１０での処理と等しい。「久里浜」→「神奈川県：横須賀市：久里浜」と展開する処理である。
【００３１】
続いて、検索要求部１４による検索処理に移る。検索処理は、カテゴリ（キーワード）および位置によって行われる。まず、カテゴリ（キーワード）を用いてインデックスＤＢ１７内のスレッドインデックスを検索し、カテゴリ（キーワード）と合致するスレッドに所属する投稿ＩＤを取得する。さらに、インデックスＤＢ１７内のキーワードインデックスを検索し、カテゴリ（キーワード）と合致する投稿ＩＤを取得する。これら取得した投稿ＩＤが所属する位置インデックスと位置情報（現在地／目的地／任意位置など）の位置相関係数を求め、位置相関係数が高い（一定値以上または上位の）位置インデックスに所属する投稿を候補とする。この候補に所属する投稿が多い場合には、各投稿の位置特性関数と位置情報との位置相関係数を求め、この値が高い投稿に候補を絞り込む。
【００３２】
なお、検索要求部１４は、インデックスＤＢ１７内に合致する情報がない場合には、過去の投稿から位置情報またはカテゴリに造詣の深い投稿者をユーザＤＢ１８から抽出し、その投稿者の過去の投稿から情報を引き出す。
この候補を検索結果として、コンテンツ生成部１５で抽出し、変換して自動車に送信、ユーザ４が閲覧する。コンテンツ生成部１５で行う「変換」は、要約や車載機に合わせた表示様式（プレーンテキスト／ＨＴＭＬ／ＸＭＬなど）に変換する処理である。
【００３３】
一方、スレッドインデックスおよびキーワードインデックスで候補が検索されない場合には、ユーザＤＢ１８を用いた候補抽出処理を行う。位置情報はＬｉｖｅ  Ｐｏｓｉｔｉｏｎとの位置相関係数を求め、この値が高いユーザを候補として抽出する。また、Ｌｉｖｅ  Ｋｅｙｗｏｒｄ（現在興味）に高頻度でカテゴリ（キーワード）が記憶されているユーザを候補として抽出する。このＬｉｖｅ  ＰｏｓｉｔｉｏｎおよびＬｉｖｅ  Ｋｅｙｗｏｒｄで候補が抽出されない場合には、それぞれＨｉｓｔｏｒｉｃａｌ  Ｐｏｓｉｔｉｏｎ，Ｈｉｓｔｏｒｉｃａｌ  Ｋｅｙｗｏｒｄ（履歴興味）に対する検索となる。Ｈｉｓｔｏｒｉｃａｌ  Ｐｏｓｉｔｉｏｎは出現回数を重みと読み替えて位置相関係数の演算を行う。
【００３４】
このようにして抽出された、ユーザが過去に投稿した投稿内容を検索し、その投稿との位置相関係数およびキーワードマッチングを演算する。この値が高い投稿を検索結果としてコンテンツ生成部１５に送る。この値が高い投稿が存在しない場合には、当該ユーザに直接問い合わせる処理に入る。
【００３５】
既存投稿に検索条件を満たす投稿がない場合には、ユーザ４にその旨を通知し、投稿者５への問い合わせに関する実施可否を尋ねる。ユーザが問い合わせを行うことを了承した場合には、問い合わせ内容の作成に入る。
【００３６】
問い合わせ内容は、簡単なキーワードの組み合わせまたは音声録音ファイルを用いて入出力インタフェース３１と演算処理部３３で生成する。もちろん助手席や後席の同乗者がフルキーボードを用いて入力してもよい。
【００３７】
この問い合わせ内容を、ユーザ問合せ部１６から問い合わせ対象の投稿者が現在所属している（最近の投稿履歴より算出）スレッドに投稿する。最近の投稿がない場合には、当該投稿者のメールアドレスに直接送信する（返信は既存コミュニティにするようお願いする）。
【００３８】
当該投稿者が返信をしてくれた場合には、その内容が既存コミュニティに反映するため、それを抽出することで検知・閲覧可能となる。
コンテンツ生成部１５は、ユーザの要求に合致する既存投稿が存在しない場合には、造詣の深い投稿者に対して問い合わせを行う。
【図面の簡単な説明】
【００３９】
【図１】本発明の一実施形態のコミュニティ位置インデックスサーバを含むコミュニティ位置インデックスシステムの構成図である。
【図２】位置特性関数の算出方法を示す図である。
【図３】位置相関係数の算出方法を示す図である。
【図４】インデックスＤＢ１７のデータ格納形式を示す図である。
【図５】ユーザＤＢ１８のデータ格納形式を示す図である。
【符号の説明】
【００４０】
１    コミュニティ位置インデックスサーバ
２    インターネット
３    端末装置
４    ユーザ
５    投稿者
１０    話題インデックス生成部
１１    ユーザ特徴生成部
１２    通信部
１３    地名変換部
１４    検索要求部
１５    コンテンツ生成部
１６    ユーザ問合せ部
１７    インデックスＤＢ
１８    ユーザＤＢ
１９    地名ＤＢ
３１    入出力インタフェース
３２    ＧＰＳユニット
３３    演算処理部
３４    通信部
【図１】
2005071027.tif 000003
【図２】
2005071027.tif 000004
【図３】
2005071027.tif 000005
【図４】
2005071027.tif 000006
【図５】
2005071027.tif 000007