JP4217132B2 - コミュニティ位置インデックスサーバ - Google Patents

Description

本発明はコミュニティシステムに関する。

昨今のメーリングリストや掲示板、Ｐ２Ｐソフトウェアによるデジタルコミュニティの普及には著しいものがある。従来、これら口コミ情報は、情報誌などコンテンツベンダが取りまとめを行って流通させることで広く流布させることが可能であった。しかしながらインタネット上のコミュニティ環境の充実に伴って、個人レベルでの情報発信・受信・やりとりがリアルタイムで可能となり、通常の調べものではこれらコミュニティの情報を縦覧するだけでもかなりの情報を集めることが可能となってきている。

一方、モバイル技術の発達により、いつでもどこでもインタネット環境にアクセスすることが可能となってきている。そのような状況の中、モバイル環境におけるコミュニティに関して色々な研究やサービスが行われるようになってきた。位置に関連したコミュニティについては様々な研究がなされている（非特許文献１、非特許文献２）。
時空間限定オブジェクトシステムＳｐａｃｅ Ｔａｇ：プロトタイプシステムの設計と実装、森下健、中尾恵、垂水浩幸、上林弥彦、情報処理学会論文誌、Ｖｏｌ．４１ Ｎｏ．１０、Ｏｃｔ．２０００ 実世界コンテキストに埋め込まれたコミュニティウェア、角康之、間瀬健二、情報処理学会論文誌、Ｖｏｌ．４１ Ｎｏ．１０、Ｏｃｔ．２０００ Ｇ−ＢＯＯＫ（伝言板・掲示板）、http://g-book.com/pc/whats_G-Book/

これらの研究では新規にコミュニティを起こして、その中での情報の授受を行ってユーザの利便を図ることを目的としている。

しかしながら、コミュニティは数の論理で活性化がなされるものであり、情報の存在しないコミュニティは投稿者が枯渇して寂れてしまい、ついには死滅してしまう。上記のサービスは、展示会といったようなバースト的かつテンポラリに情報の錯綜するシチュエーションをターゲットとしているため、利用するユーザの利用意識の高さからこのような問題を回避していると考えられる。しかし、日常での利用におけるコミュニティの活性化といった観点での議論は不足していると考える。

自動車内で利用することを主眼としたコミュニティとして非特許文献３に開示されたようなサービスが行われている。

これは、自動車内だけでなく、ＰＣやＰＤＡ（Personal Digital Assistants）、携帯電話からもアクセス可能とすることでコミュニティの活性化を図っている。しかし、自動車内で利用可能なコミュニティをＰＣやＰＤＡ、携帯電話からもアクセス可能というアプローチであり、既存の膨大なコミュニティとの連携は考慮されていない。

本発明の目的は、モバイル（特に自動車）からのコミュニティアクセスを容易にするコミュニティ位置インデックスサーバを提供することにある。

本発明のコミュニティ位置インデックスサーバは、
既存コミュニティの投稿データから地名情報および話題を示すキーワードをそれぞれ抽出し、該抽出した地名情報について、その出現回数による重み付けと、都道府県名により区分される第１のレイヤ、市町村名により区分される、第１のレイヤの下位である第２のレイヤ、および前記都道府県および市町村の地名以外の他の地名で区分される、第２のレイヤの下位である第３のレイヤからなるレイヤ関係に基づく分類を行い、該重み付けと分類の結果に基づく位置特性関数と前記投稿データの投稿ＩＤを関連付けた位置インデックスを作成し、前記抽出した話題のキーワードについては、その出現回数による重み付けに基づくトピック特性関数と前記投稿データの投稿ＩＤを関連付けたトピックインデックスを作成する話題インデックス生成部と、
前記位置インデックスおよびトピックインデックスの情報を記憶するインデックスＤＢと、
端末との間の通信を行う通信部と、
地名を記憶した地名ＤＢと、
前記通信部で受信した、端末の位置情報から前記地名ＤＢを参照して、該位置情報の地名を取得する地名変換部と、
前記通信部で受信した、端末からのユーザの情報要求であるキーワードと、前記地名変換部にて取得された地名とに基づいて、ユーザが望む情報を前記インデックスＤＢから検索する検索要求部と、
検索結果を端末に合わせた形態に変換するコンテンツ生成部を有し、
前記話題インデックス生成部は、
新規の投稿データを取得すると、該新規の投稿データについて前記位置特性関数を取得し、前記インデックスＤＢに格納されている既存の位置インデックスについて、前記新規の投稿データの位置特性関数との類似度を示す位置相関係数を算出し、該算出した位置相関係数が閾値を超えた位置インデックスに対して、前記新規の投稿データの関連付けを行うとともに、前記新規の投稿データの位置特性関数を追加して、該位置インデックスの位置特性関数を更新する。

本発明は、既存コミュニティを位置やキーワードによってインデックス付けをすることで、モバイル環境（特に自動車内）からのコミュニティアクセスが容易になる効果がある。

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

図１は本発明の一実施形態のコミュニティ位置インデックスサーバを含むコミュニティインデックスシステムの構成図である。

本実施形態のコミュニティ位置インデックスサーバ（以下、サーバと称す）１は話題インデックス生成部１０とユーザ特徴生成部１１と通信部１２と地名変換部１３と検索要求部１４とコンテンツ生成部１５とユーザ問合せ部１６とインデックスＤＢ１７とユーザＤＢ１８と地名ＤＢ１９を有している。

サーバ１はインタネット上などの既存コミュニティのデータ２を取得すると、そのデータを話題インデックス生成部１０とユーザ特徴生成部１１に渡す。

話題インデックス生成部１０は、投稿データから、投稿日時、地名名詞、固有名詞を抽出する。また、スレッド情報（電子メールでのＩｎ−Ｒｅｐｌｙ−ＴｏやＲｅｆｅｒｅｎｃｅなど）が付加されていれば、それも抽出する。話題インデックス生成部１０は、これら抽出された値を元に、情報の関連づけ＝インデキシングを行う。このインデキシングは、位置インデキシング、トピックインデキシング、スレッドインデキシングに分類される。スレッドインデキシングは電子メールやＷｅｂ掲示板で行われているスレッド管理である。本発明では、位置インデキシングとトピックインデックスを提供することを特徴とすると共に、これらをスレッドインデキシングと併用することで効果のさらなる向上を狙っている。

以下、本発明の特徴である位置インデキシングについて説明する。
位置インデキシングは大きく分けて、Ａ．位置特性関数算出と、Ｂ．位置相関係数算出と、Ｃ．位置特性関数追加の３つのプロセスからなる。
Ａ．位置特性関数算出
新規に取得した投稿情報を処理して位置特性関数を算出することを指す。
Ｂ．位置相関係数算出
インデックスＤＢ１７内の既存位置インデックスと新規投稿情報との位置相関係数を算出し、閾値を越える既存位置インデックスを求める。
Ｃ．位置特性関数追加
閾値を越える既存位置インデックスに新規投稿情報を追加し、位置インデックスの新しい位置特徴関数を算出し、位置特徴関数を更新する。

まず、位置特性関数の算出方法を図２を用いて説明する。
１．投稿データ本文を形態素解析などにかけ、地名を表す名詞を抽出し、その出現回数を合わせて記憶する。
２．例えば、郵便番号の区分に従って、都道府県、市町村、それ以下のレイヤ分けを行い、その地名の出現回数をその重みとする。その際に、上位のレイヤを位置特性関数に必ず追加し、個々で追加した上位レイヤの重みはゼロとする。図２の２においては、愛知県、茨城県行方郡、茨城県、佐賀県西松浦郡、佐賀県、千葉県千葉市、が追加された上位レイヤになる。
３．重みおよびレイヤ関係に応じてソートする。これを「位置特性関数」と定義する。

原則として、各レイヤの同じ値（地名）は連続するように配置する。神奈川県横須賀市が上の方にあって、間に他の県が存在して、下の方に神奈川県横浜市が存在する、という状態にならないようにする。図２を用いて説明する。

まず、最も出現回数の多い「愛知県豊橋市」（４）が選ばれる。次に、これの上位レイヤを順に記載する。愛知県のレイヤ２は上記だけなので、次に記載されるのは愛知県になる。

続いて、次に出現回数の多い「茨城県取手市」（２）と「佐賀県西松浦郡有田町」（２）が比較の俎上に登る。ここでは上位レイヤにさかのぼって出現回数を見てゆく。「茨城県」（０）、「佐賀県西松浦郡」（０）、「佐賀県」（０）であるので、同条件である。そこで、レイヤトポロジーとして近いモノを見る。「茨城県行方郡玉造町」（１）があるので、「茨城県取手市」（２）から始まる茨城県系が愛知県系の次に記載されることになる。続いて佐賀県系が記載され、最後に千葉県系となる。

続いて、位置特性関数同士の類似度を示す位置相関係数の算出方法を図３を用いて説明する。
０．インデックスＤＢ１７に格納されている位置インデックスには最後に更新されたタイムスタンプが登録されている。新規追加する投稿情報のタイムスタンプと位置インデックスのタイムスタンプとの差分を求め、これに減算係数をかけた値をそれぞれの地名レイヤの重みから減算する。下位レイヤの地名の重みがゼロを下回った地名は消去される。例えば減算係数＝１／３０であれば、３０日間更新されなかった地名の重みは１減算される。
１．図に示すような２つの位置特性関数の位置相関係数を求める。

図３の２のそれぞれを数列として考えると、｛１，０，０，２，４，０，０，０，０，０，０，２，０，０，１，０，１｝と｛２，０，１，０，０，２，０，２，０，１，０，０，０，０，０，０，０，０｝となる。この２つの相関を求めたものを位置相関係数と呼ぶ（相関の計算自体は公知の方法が使える）。
２．地名をマージした拡張位置特性関数を作成する。基本的には最小公倍数的に地名をマージしたものとなる。このとき、それぞれを基準とした拡張位置特性関数対を作成する。拡張位置特性関数は、位置特性関数間の相関を求めるために便宜的・一時的に作成するものである。したがって、意味的には位置特性関数間の位置相関係数であるが、それは計算上、拡張位置特性関数を使うことで求められる。図は大阪府を含む位置特性関数を基準とした拡張位置特性関数対である。
３．２つの拡張位置特性関数対間の相関係数のうち値の大きいものを「位置相関係数」と定義する。図３の例の場合は０．４７１である。
位置相関係数は−１〜１の値を取り、１に近いほど２つの位置特性関数の類似度が高いことになる。

次に、位置特性関数の追加について説明する。
１．追加される新規投稿情報をマージした位置特性関数を求める。その際に、位置インデックスの各地名の重みに新規投稿情報の地名の重みを加算する。
２．位置インデックスのタイムスタンプを新規投稿情報のタイムスタンプとする。

位置相関係数が一定値以上のデータがインデックスＤＢ１７に無い場合には新規レコードとして当該投稿の位置相関係数などをインデックスＤＢ１７に登録する。

トピックインデックスは、レイヤが存在しないことを除けば、位置インデックスとほぼ同様に算出される。トピックとは、投稿情報中に含まれる固有名詞・一般名詞であり、これの出現頻度から位置インデックスと同様に投稿情報に対してインデックス付与がなされる。

このようにして、インデックスＤＢ１７には、位置インデックスとトピックインデックスとスレッドインデックスが格納される。格納形式例を図４に示す。

また、新規投稿情報はユーザ特徴生成部１１に送られ、投稿ユーザの特徴を抽出しそれをユーザＤＢ１８に保管またはユーザＤＢ１８の特徴を更新する処理が行われる。ユーザ特徴生成部１１の処理は以下の点を除いて話題インデックス生成部１０の動作と同一である。
相違点：
Ａ．減算係数と最終更新からの経過日時を用いた減算結果が０を下回る地名についても、「過去にこの話題に精通した」という履歴の意味からＨｉｓｔｏｒｉｃａｌ Ｐｏｓｉｔｉｏｎ（履歴位置）として記憶する。このため重みが０を下回らないＬｉｖｅ Ｐｏｓｉｔｉｏｎ（現在位置）についても重みと同様に出現回数を記憶する。
Ｂ．コミュニティにおいては投稿回数が重要なパラメータとなるため、投稿回数もユーザＤＢ１８内に記憶する。
Ｃ．位置情報とキーワード情報の双方をユーザＤＢ１８に格納する。
ユーザＤＢ１８の構成例を図５に示す。

以上が、コミュニティに投稿がなされた場合、またはコミュニティの過去ログからユーザＤＢ１８およびインデックスＤＢ１７を生成するプロセスである。

次に、自動車内からのアクセスについて説明する。自動車内からの情報検索要求は、ＧＰＳの示す緯度経度情報と、カテゴリ（キーワード）情報の組で端末装置３からサーバ１に送信される。このカテゴリ（キーワード）は、事前にユーザが登録しておく方法や、検索時に簡単なキーワードを音声認識で入力する方法などが考えられる。ユーザが入力したカテゴリ（キーワード）情報は入出力インタフェース３１から演算処理部３３に送られ、そこでＧＰＳユニット３２からのＧＰＳ情報といっしょに通信部３４を介してサーバ１に送信される。

サーバ１では、通信部１２で受信したＧＰＳ情報から地名を抽出する。これは、地名ＤＢ１９と地名変換部１３により行われる。ここでは、併せてレイヤ変換の作業も行われる。レイヤ変換とは、「久里浜」という地名が発見された場合に、これのレイヤを算出すると共に上位レイヤも抽出する作業である。内容は話題インデックス生成部１０での処理と等しい。「久里浜」→「神奈川県：横須賀市：久里浜」と展開する処理である。

続いて、検索要求部１４による検索処理に移る。検索処理は、カテゴリ（キーワード）および位置によって行われる。まず、カテゴリ（キーワード）を用いてインデックスＤＢ１７内のスレッドインデックスを検索し、カテゴリ（キーワード）と合致するスレッドに所属する投稿ＩＤを取得する。さらに、インデックスＤＢ１７内のキーワードインデックスを検索し、カテゴリ（キーワード）と合致する投稿ＩＤを取得する。これら取得した投稿ＩＤが所属する位置インデックスと位置情報（現在地／目的地／任意位置など）の位置相関係数を求め、位置相関係数が高い（一定値以上または上位の）位置インデックスに所属する投稿を候補とする。この候補に所属する投稿が多い場合には、各投稿の位置特性関数と位置情報との位置相関係数を求め、この値が高い投稿に候補を絞り込む。

なお、検索要求部１４は、インデックスＤＢ１７内に合致する情報がない場合には、過去の投稿から位置情報またはカテゴリに造詣の深い投稿者をユーザＤＢ１８から抽出し、その投稿者の過去の投稿から情報を引き出す。
この候補を検索結果として、コンテンツ生成部１５で抽出し、変換して自動車に送信、ユーザ４が閲覧する。コンテンツ生成部１５で行う「変換」は、要約や車載機に合わせた表示様式（プレーンテキスト／ＨＴＭＬ／ＸＭＬなど）に変換する処理である。

一方、スレッドインデックスおよびキーワードインデックスで候補が検索されない場合には、ユーザＤＢ１８を用いた候補抽出処理を行う。位置情報はＬｉｖｅ Ｐｏｓｉｔｉｏｎとの位置相関係数を求め、この値が高いユーザを候補として抽出する。また、Ｌｉｖｅ Ｋｅｙｗｏｒｄ（現在興味）に高頻度でカテゴリ（キーワード）が記憶されているユーザを候補として抽出する。このＬｉｖｅ ＰｏｓｉｔｉｏｎおよびＬｉｖｅ Ｋｅｙｗｏｒｄで候補が抽出されない場合には、それぞれＨｉｓｔｏｒｉｃａｌ Ｐｏｓｉｔｉｏｎ，Ｈｉｓｔｏｒｉｃａｌ Ｋｅｙｗｏｒｄ（履歴興味）に対する検索となる。Ｈｉｓｔｏｒｉｃａｌ Ｐｏｓｉｔｉｏｎは出現回数を重みと読み替えて位置相関係数の演算を行う。

このようにして抽出された、ユーザが過去に投稿した投稿内容を検索し、その投稿との位置相関係数およびキーワードマッチングを演算する。この値が高い投稿を検索結果としてコンテンツ生成部１５に送る。この値が高い投稿が存在しない場合には、当該ユーザに直接問い合わせる処理に入る。

既存投稿に検索条件を満たす投稿がない場合には、ユーザ４にその旨を通知し、投稿者５への問い合わせに関する実施可否を尋ねる。ユーザが問い合わせを行うことを了承した場合には、問い合わせ内容の作成に入る。

問い合わせ内容は、簡単なキーワードの組み合わせまたは音声録音ファイルを用いて入出力インタフェース３１と演算処理部３３で生成する。もちろん助手席や後席の同乗者がフルキーボードを用いて入力してもよい。

この問い合わせ内容を、ユーザ問合せ部１６から問い合わせ対象の投稿者が現在所属している（最近の投稿履歴より算出）スレッドに投稿する。最近の投稿がない場合には、当該投稿者のメールアドレスに直接送信する（返信は既存コミュニティにするようお願いする）。

当該投稿者が返信をしてくれた場合には、その内容が既存コミュニティに反映するため、それを抽出することで検知・閲覧可能となる。
コンテンツ生成部１５は、ユーザの要求に合致する既存投稿が存在しない場合には、造詣の深い投稿者に対して問い合わせを行う。

本発明の一実施形態のコミュニティ位置インデックスサーバを含むコミュニティ位置インデックスシステムの構成図である。 位置特性関数の算出方法を示す図である。 位置相関係数の算出方法を示す図である。 インデックスＤＢ１７のデータ格納形式を示す図である。 ユーザＤＢ１８のデータ格納形式を示す図である。

符号の説明

１ コミュニティ位置インデックスサーバ
２ インターネット
３ 端末装置
４ ユーザ
５ 投稿者
１０ 話題インデックス生成部
１１ ユーザ特徴生成部
１２ 通信部
１３ 地名変換部
１４ 検索要求部
１５ コンテンツ生成部
１６ ユーザ問合せ部
１７ インデックスＤＢ
１８ ユーザＤＢ
１９ 地名ＤＢ
３１ 入出力インタフェース
３２ ＧＰＳユニット
３３ 演算処理部
３４ 通信部

Claims (3)

1. 既存コミュニティに対するモバイル環境からのアクセスを容易にするコミュニティ位置インデックスサーバであって、
   前記既存コミュニティの投稿データから地名情報および話題を示すキーワードをそれぞれ抽出し、該抽出した地名情報について、その出現回数による重み付けと、都道府県名により区分される第１のレイヤ、市町村名により区分される、第１のレイヤの下位である第２のレイヤ、および前記都道府県および市町村の地名以外の他の地名で区分される、第２のレイヤの下位である第３のレイヤからなるレイヤ関係に基づく分類を行い、該重み付けと分類の結果に基づく位置特性関数と前記投稿データの投稿ＩＤを関連付けた位置インデックスを作成し、前記抽出した話題のキーワードについては、その出現回数による重み付けに基づくトピック特性関数と前記投稿データの投稿ＩＤを関連付けたトピックインデックスを作成する話題インデックス生成部と、
   前記位置インデックスおよびトピックインデックスの情報を記憶するインデックスＤＢと、
   端末との間の通信を行う通信部と、
   地名を記憶した地名ＤＢと、
   前記通信部で受信した、端末の位置情報から前記地名ＤＢを参照して、該位置情報の地名を取得する地名変換部と、
   前記通信部で受信した、端末からのユーザの情報要求であるキーワードと、前記地名変換部にて取得された地名とに基づいて、ユーザが望む情報を前記インデックスＤＢから検索する検索要求部と、
   検索結果を端末に合わせた形態に変換するコンテンツ生成部を有し、
   前記話題インデックス生成部は、新規の投稿データを取得すると、該新規の投稿データについて前記位置特性関数を取得し、前記インデックスＤＢに格納されている既存の位置インデックスについて、前記新規の投稿データの位置特性関数との類似度を示す位置相関係数を算出し、該算出した位置相関係数が閾値を超えた位置インデックスに対して、前記新規の投稿データの関連付けを行うとともに、前記新規の投稿データの位置特性関数を追加して、該位置インデックスの位置特性関数を更新する、コミュニティ位置インデックスサーバ。
2. 前記話題インデックス生成部は、前記投稿データにスレッド情報が付加されている場合に、該スレッド情報のスレッド名を前記投稿データの投稿ＩＤと関連付けたスレッドインデックスを作成し、該スレッドインデックスを前記インデックスＤＢに記憶し、
   前記検索要求部は、前記ユーザの情報要求であるキーワードを用いて前記インデックスＤＢを検索し、該キーワードと合致するスレッドインデックスに属する投稿ＩＤおよび該キーワードと合致するトピックインデックスに属する投稿ＩＤをそれぞれ取得し、これら取得した投稿ＩＤが所属する位置インデックスの位置特性関数と前記地名変換部にて取得された地名の位置相関係数を求め、位置相関係数が一定値以上の位置インデックスに所属する投稿データを検索候補とする、請求項１に記載のコミュニティ位置インデックスサーバ。
3. ユーザＤＢと、
   前記既存コミュニティの投稿データから前記地名情報および話題を示すキーワードを抽出し、抽出した地名情報とその出現回数による重み付けの情報を含む位置情報と、抽出した話題のキーワードとその出現回数による重み付けの情報を含むキーワード情報とを、前記投稿ユーザのＩＤと関連付けて前記ユーザＤＢに記憶するユーザ特徴生成部をさらに有し、
   前記検索候補となる投稿データを前記インデックスＤＢから取得できない場合は、前記検索要求部は、前記ユーザＤＢを参照して、前記位置情報と前記地名変換部にて取得された地名の位置相関係数と、前記ユーザの情報要求であるキーワードと前記キーワード情報のマッチングとに基づいて、ユーザが望む情報を投稿したユーザＩＤを特定する、請求項２に記載のコミュニティ位置インデックスサーバ。

Images