情報検索システム及び情報検索装置
【課題】携帯電話のような小さい表示画面に関連語の分類画面を表示する場合でも、ユーザにとっての使い勝手を向上する。
【解決手段】地名関連語リストから地名と関連語の組に基づき検索した文書に記載されたＵＲＬから、地名と関連語の組が含まれているネットワーク上の文書を取得する。そして、該取得文書に含まれる関連語を中心とする前後の単語を取り出してネットワーク上の文書のファイル名と共にＷＡＭファイル作成する。同一の地名に係る複数のＷＡＭファイルに基づき、ネットワーク上の文書群と関連語の有無の関係が書かれた関連語出現テーブルを作成すると共に、本ベストスコアテーブルを生成する。そして、該本ベストスコアテーブルを基に、クライアントへ送信される本クラスタを作成する。そして、携帯電話の位置情報をＧＰＳ衛星経由で受信した検索サーバは、位置情報を知名に変換して、その地名に該当する本クラスタを送信する。
【解決手段】地名関連語リストから地名と関連語の組に基づき検索した文書に記載されたＵＲＬから、地名と関連語の組が含まれているネットワーク上の文書を取得する。そして、該取得文書に含まれる関連語を中心とする前後の単語を取り出してネットワーク上の文書のファイル名と共にＷＡＭファイル作成する。同一の地名に係る複数のＷＡＭファイルに基づき、ネットワーク上の文書群と関連語の有無の関係が書かれた関連語出現テーブルを作成すると共に、本ベストスコアテーブルを生成する。そして、該本ベストスコアテーブルを基に、クライアントへ送信される本クラスタを作成する。そして、携帯電話の位置情報をＧＰＳ衛星経由で受信した検索サーバは、位置情報を知名に変換して、その地名に該当する本クラスタを送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報検索システム及び情報検索装置にかかり、特に、検索エンジンによって文書データを検索する情報検索システム及び情報検索装置に関する。
【背景技術】
【０００２】
近年、携帯電話の普及により、携帯電話からインターネット上の検索エンジンを用いて、さまざまな検索が行われている。しかし、流行している物や現象、人名、企業、商品、サービス、テレビ番組、地名、駅名等を検索クエリとして情報を検索することは決して易しくはない。これは、ユーザが検索対象についてあまり詳しく知らないために、適切な関連語で検索結果を絞り込むことが困難であるからである。
また、検索クエリで検索される膨大な検索結果を全て閲覧するのではなく、興味のあるウェブページ群だけ概観したいという要求もある。
【０００３】
パソコンを用いた検索では、検索対象となる文章集合の中には類似した文章が含まれることが多いため、予め文書集合を類似度に応じて分類しておき、検索時にはこれらのグループと検索クエリとの類似度を計算するクラスタ型の検索が知られている。
また、ある検索クエリで検索される検索結果ウェブページ群は、多数の類似したウェブページが含まれるので、適切な分類を行うことにより、検索結果を容易に絞り込むことができると共に、検索結果を概観することも容易になる。
なお、非特許文献１にクラスタ型の検索に関する先行技術文献を記す。
【０００４】
【非特許文献１】徳永健伸、「情報検索と言語処理」、東京大学出版会、（１９９９）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記非特許文献１に記載の技術では、ウェブページ内のテキストデータ全文を利用して関連語を分類している。このようなテキストデータ全文の中には、ユーザの検索ニーズに合致しない雑多な情報が多数含まれている。そのため、ユーザにとって意味が分からない関連語を含むクラスタや、検索対象を絞り込む上で役に立たないクラスタが生成されてしまうという問題が発生する。すなわち、分類された関連語が、ユーザにとって分かりにくく、利便性の低いものとなるという不都合がある。特に、一般名詞とは異なる特徴を持つ固有名詞、例えば地名、駅名及び人名等の関連語の分類を行う際には、上述した問題点が顕著に現れることが、本発明者の過去の研究より明らかとなっている。
【０００６】
携帯電話のウェブブラウザでクラスタ型検索を実行すると問題はもっと複雑になる。つまり、携帯電話の表示画面は、パソコンの表示画面に比べて小さいため、一行に表示できる文字列の数が限られている。そのため、やみくもに関連語の分類を行い、分類された関連語全てを携帯電話の画面に表示しようとすると、見た目が悪いだけでなく、ユーザにとって非常に分かりづらい画面表示となってしまうという問題がある。
【０００７】
本発明は斯かる点に鑑みてなされたものであり、固有名詞の関連語を適切に分類することにより、携帯電話のような小さい表示画面に関連語の分類画面を表示する場合でも、ユーザにとって使い勝手が良い情報検索システム及び情報検索装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る情報検索システムは、クライアントと、クライアントに情報を提供する情報検索サーバと、情報検索サーバの要求にしたがって所定の情報を出力する検索エンジンとよりなる情報検索システムであって、クライアントは、現在位置情報を取得するＧＰＳ受信部と、所定の情報を表示する表示部と、表示部を制御する表示制御部と、ＧＰＳ受信部から得られる位置情報を送信すると共に、所定の情報を受信して表示制御部に渡す入出力制御部とを備え、検索エンジンは、所定の単語が入力されると単語の関連語を出力するものであり、情報検索サーバは、情報検索エンジンから所定の情報を受信して加工するバッチ処理部と、バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、不揮発性データ記憶部に蓄積された加工された情報をクライアントに送信するリアルタイム処理部とを備え、不揮発性データ記憶部は、ＧＰＳ受信部から入出力制御部を通じて得られる現在位置情報に対応する地名が格納されているＧＰＳ地名マスタと、情報検索エンジンから得られる、地名とその関連語群が格納される地名関連語リストと、地名と関連語群から作成される地名と各々の関連語の組よりなる複数の検索クエリをそれぞれ情報検索エンジンにて検索した結果が記録される検索結果ファイル群が格納される検索結果ファイルディレクトリと、検索結果ファイル群に記載されているＵＲＬから得られる、地名と関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、検索結果ファイル毎に作成され、ネットワーク上の文書群に含まれる関連語を中心とする前後の単語がネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、ＷＡＭファイル中に出現する関連語の関係が記されている関連語出現テーブルと、ＷＡＭファイル中に出現する関連語の類似度が記されている本ベストスコアテーブルと、本ベストスコアテーブルから生成され、クライアントへ送信される本クラスタが格納される本クラスタディレクトリとを備え、バッチ処理部は、ＧＰＳ地名マスタに含まれている地名を検索エンジンに与えて地名関連語リストを取得し、地名関連語リストから地名と関連語の組を検索エンジンに与えて検索結果の文書を検索結果ファイルディレクトリに格納すると共に、検索結果の文書に記載されているＵＲＬから得られる、地名と関連語の組が含まれているネットワーク上の文書をキャッシュファイルディレクトリに格納するデータ取得処理部と、ネットワーク上の文書に含まれる関連語を中心とする前後の単語を取り出してネットワーク上の文書のファイル名と共にＷＡＭファイルに書き出し、ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、同一の地名に係る複数のＷＡＭファイルに基づいて、ネットワーク上の文書群と関連語の有無の関係を関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、関連語出現テーブルを基に全ての各関連語同士の類似度を算出した後、類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、第一関連語、第二関連語及び第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、本ベストスコアテーブルを基に、クライアントへ送信される本クラスタを作成して本クラスタディレクトリに格納する本クラスタ生成処理部とを備え、リアルタイム処理部は、クライアントから得られる現在位置情報を受けて対応する地名をＧＰＳ地名マスタから取得して、本クラスタディレクトリから地名に対応する本クラスタを取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部とを備えることを特徴とする。
【０００９】
地名や人名等の固有名詞は、事物或は人物そのものを特定する名称であるので、本質的に特有の意味を持たない。しかし、一方で、その土地や人物には、固有に由来する様々な事象がある。つまり、固有名詞は、その人物や事物自体を指し示す観点においては一義的であるものの、その人物や事物に由来する事象において多義的である。
人は固有名詞からそれに由来する様々な事象を連想する。その事象は個々の目的や趣味趣向等によって極めて多彩である。このため、検索システムは固有名詞を検索クエリとして与えられた時に、固有名詞から連想される複数の側面を端的に示すキーワードを用いて、そのような複数の側面を分類する必要がある。
あるキーワードとキーワードとの間の関係は、一つの文書の中に同時に現れるだけでなく、それぞれの出現する場所が極めて近い場合が多い。
発明者はこの点に注目し、関連語同士の出現頻度を算出する対象を、文書中の関連語の前後数ワードに絞った。
更に、関連語同士の類似度を算出し、その上澄みとも言える２レコードだけ取り出し、クラスタリング処理を行った。
【００１０】
上記構成によれば、携帯電話の表示画面の大きさにかかわらず、適切に各関連語が分類された本クラスタを作成することができる。
【発明の効果】
【００１１】
本発明により、携帯電話のような小さい表示画面に関連語の分類画面を表示する場合でも、ユーザにとって使い勝手が良い情報検索システム及び情報検索装置を提供することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態の例を、図１〜図５１を参照して説明する。
【００１３】
〔全体構成〕
図１（ａ）は、本発明の一実施形態例である情報検索システムの概略図である。
また、図１（ｂ）は、本実施形態例に用いられる携帯電話１０２の機能を示すブロック図である。本実施形態例は、この図１（ｂ）に示す携帯電話１０２を保有するユーザに対して効果的に情報（コンテンツ）を提供する情報検索システムである。
この情報検索システム１０１は、携帯電話１０２、モバイル情報検索サーバ１０３、検索エンジン１０４及び地図サーバ１０５より構成されており、図１(a)に示すように、これらの各要素がインターネット１０６上で相互に接続されている。
【００１４】
携帯電話１０２は、ＧＰＳ（Global Positioning System）衛星１０７からユーザの現在位置情報を取得し、インターネット１０６を介してその現在位置情報をモバイル情報検索サーバ１０３に送信する。また、ユーザの操作によって、後述するようなさまざまな指示をモバイル情報検索サーバ１０３に送信する。
【００１５】
モバイル情報検索サーバ１０３は、携帯電話１０２から送信されたユーザの指示に基づいて、検索エンジン１０４及び地図サーバ１０５よりさまざまな情報を取得する。検索エンジン１０４及び地図サーバ１０５からの情報の取得は、インターネット１０６を介して行われる。モバイル情報検索サーバ１０３は、検索エンジン１０４及び地図サーバ１０５から送信された情報に所定の処理を加え、ユーザの携帯電話１０２に対する操作に応じたｈｔｍｌ（Hyper Text Markup Language）文書を周知のＨＴＴＰ（Hyper Text Transfer Protocol）にて携帯電話１０２へ送信する。
モバイル情報検索サーバ１０３は、情報検索装置ともいえる。
【００１６】
検索エンジン１０４は、インターネット１０６に存在する情報（ウェブページ、ウェブサイト、画像ファイル、住所など）を検索する機能を提供するｗｅｂサーバである。
地図サーバ１０５は、入力された位置情報に基づいて、所定の範囲の地図画像をユーザに提供する周知のｗｅｂサーバである。
【００１７】
〔携帯電話〕
図１（ｂ）は、携帯電話の機能的な構成を示すブロック図である。なお、図（ｂ）は本実施形態に用いられる機能ブロック図のみを示している。したがって、通話等の、本実施形態と関係のない機能の記載は省略している。
ＧＰＳ受信部１０８は、ＧＰＳ衛星１０７から受信した電波を受信し、携帯電話１０２のユーザの現在位置情報（緯度・経度等）を取得し、その現在位置情報を入出力制御部１０９へ出力する。
【００１８】
ＧＰＳ受信部１０８から現在位置情報の入力があると、入出力制御部１０９は、インターネット１０６を介して、モバイル情報検索サーバ１０３へ現在位置情報を送信する。また、モバイル情報検索サーバ１０３から携帯電話１０２へｈｔｍｌ文書が送信された場合、入出力制御部１０９は、そのｈｔｍｌ文書を受信し、表示制御部１１０を通じて表示部１１１へ送る。そして、表示部１１１において、モバイル検索サーバ１０３から送られたｈｔｍｌ文書が表示される。
【００１９】
入力部１１２は、操作キー等である。ユーザは、この操作キーを操作することにより、表示部１１１で表示されたｈｔｍｌ文書の各リンクを選択したり、ｈｔｍｌ文書の所定の領域に文字列を入力したりする。このようなユーザの入力部１１２に対する操作は、入出力制御部１０９を介して、インターネット１０６上のモバイル情報検索サーバ１０３、検索エンジン１０４及び地図サーバ１０５へ送信される。
【００２０】
〔モバイル情報検索サーバ〕
図２は、モバイル情報検索サーバの機能的な構成を示すブロック図である。
モバイル情報検索サーバ１０３は、大まかには、バッチ処理部２０２、リアルタイム処理部２０３及び不揮発性データ記憶部２０４よりなる。
【００２１】
バッチ処理部２０２は、例えばシェルスクリプト等により、モバイル情報検索サーバ１０３で行われる処理の一部をサーバのリソースがあまり忙しくない時間帯（例えば、夜間等）に稼動する。ここで処理の一部とは、携帯電話１０２からのユーザの指示を受けなくても行える処理、つまりモバイル情報検索サーバ１０３のみで行える処理のことを指している。具体的には、所定の情報を検索エンジン１０４及び地図サーバ１０５より取得し、これらの情報を携帯電話１０２のユーザに提供するためのｈｔｍｌ文書を作成するための形式に変換する処理、及び不揮発性データ記憶部２０４に記憶する処理のことである。なお、バッチ処理部２０２の内部構成及びバッチ処理部２０２で行われるより詳細な処理については図４〜図３３にて後述する。
【００２２】
リアルタイム処理部２０３は、ユーザによる携帯電話１０２の操作に応じた処理をリアルタイムで行う部分である。ここで、リアルタイム処理とは、予めバッチ処理部２０２で生成され、不揮発性データ記憶部２０４に記憶された所定の情報に基づいて、携帯電話１０２に適合するｈｔｍｌ文書に変換する処理、及び携帯電話１０２へｈｔｍｌ文書を送信する処理のことである。なお、リアルタイム処理部２０３の内部構成及びリアルタイム処理部２０３で行われるより詳細な処理については図３４〜図４６にて後述する。
【００２３】
[バッチ処理部］
図３は、バッチ処理部２０２及び不揮発性データ記憶部２０４の一部の機能的な構成を示すブロック図である。
バッチ処理部２０２は、非対話型ウェブクライアント３０２と、データ取得処理部３０３と、本クラスタ作成部３１９とからなる。
データ取得処理部３０３は、非対話型ウェブクライアント３０２を介して所定の情報を取得する。
【００２４】
本クラスタ作成部３１９は、データ取得処理部３０３が取得した情報を呼び出し、その情報に基づいて、後述する本クラスタを作成する。なお、本クラスタ作成部３１９は、ＷＡＭ（Word-Article Matrix）ファイル生成処理部３０４と、関連語出現テーブル生成処理部３０５と、ベストスコアテーブル生成処理部３０６と、本クラスタ生成処理部３０７とからなる。
【００２５】
これらバッチ処理部２０２の各ブロックで生成された情報は、不揮発性データ記憶部２０４の所定の領域に適宜記憶される。この不揮発性データ記憶部２０４には、ＧＰＳ地名マスタ３０８、地名関連語リスト３０９、検索結果ファイルディレクトリ３１０、キャッシュファイルディレクトリ３１１、検索キー・ファイル名対応テーブル３１２、ＷＡＭファイルディレクトリ３１３、関連語出現テーブル３１４、仮ベストスコアテーブル３１５（一時ファイル）、本ベストスコアテーブル３１６、仮クラスタ３１７（一時ファイル）及び本クラスタディレクトリ３１８を記憶する領域が存在する。
不揮発性データ記憶部を構成する上記各要素間の関係とそれぞれの動作については、後述する。
【００２６】
以下、バッチ処理部２０２の各ブロックの機能について、図４〜図８を参照して説明する。
【００２７】
[データ取得処理部]
図４は、データ取得処理部３０３を中心とするブロック図である。
データ取得処理部３０３は、非対話型ウェブクライアント３０２及びインターネット１０６を介して検索エンジン１０４と相互に情報のやり取りを行う。データ取得処理部３０３は、予め不揮発性データ記憶部２０４に記憶してあるＧＰＳ地名マスタ３０８にアクセスし、全ての地名の文字列を取得する。この地名の文字列と地図上の経度緯度との関係は後述する図１３（ａ）に示されている。
そして、各地名の文字列を順次非対話型ウェブクライアント３０２を介して、検索エンジン１０４に送信する。ここで、検索エンジン１０４から返信される情報を基にして、データ取得処理部３０３は、各地名とその地名に関する複数の単語（以下、「関連語」という）が対応付けられた、後述する地名関連語リスト３０９を生成し、不揮発性データ記憶部２０４に記憶する。
【００２８】
また、データ取得処理部３０３は、不揮発性データ記憶部２０４に地名関連語リスト３０９を生成後、その地名関連語リスト３０９にアクセスし、各関連語毎に「（地名）＋（カンマ）＋（関連語１）＋（関連語２）＋…＋（関連語１００）」の文字列を取得する。そして、「（地名）＋（スペース）＋（関連語１）」、「（地名）＋（スペース）＋（関連語２）」、…、「(地名)＋(スペース)＋(関連語１００)」という各文字列（以下、「地名関連語文字列」という）に変換するコマンドを順次実行し、複数の地名関連語文字列を取得する。ただし、地名は複数存在するので、データ取得処理部３０３が生成する地名関連語文字列は、（全地名の数）×（各地名に対する関連語の数）通りとなる。
【００２９】
そして、各地名関連語文字列を非対話型ウェブクライアント３０２を介して、検索エンジン１０４に順次送信する。また、データ取得処理部３０３は、検索エンジン１０４から返信される検索結果を示す、検索結果ｈｔｍｌファイル及びウェブページのキャッシュファイルにそれぞれ所定の名称を付与し、検索結果ｈｔｍｌファイルディレクトリ及びキャッシュファイルディレクトリ３１１にそれぞれ記憶する。なお、検索結果ｈｔｍｌファイル及びウェブページのキャッシュファイルについての詳細は、図１０及び図１１に基づいて後述する。
【００３０】
また、データ取得処理部３０３は、地名関連語リスト、検索結果ｈｔｍｌファイルディレクトリに記憶された検索結果ｈｔｍｌファイル名及びキャッシュファイルディレクトリ３１１に記憶されたキャッシュファイル名をそれぞれ対応付けた、検索キー・ファイル名対応テーブル３１２を生成する。この検索キー・ファイル名対応テーブル３１２は、不揮発性データ記憶部２０４に記憶されるものであるが、その具体的な内容は、後述する図１３（ｂ）に示されるようなものである。
ここで、キャッシュファイルに住所文字列が含まれている場合は、データ取得処理部３０３が、非対話型ウェブクライアント３０２を介してその住所文字列を検索エンジン１０４に送信し、その住所に対応する位置情報（緯度・経度）を取得する。そして、これらの住所文字列及び位置情報を検索キー・ファイル名対応テーブル３１２の所定のフィールドにキャッシュファイル名と対応付けて追記する。
【００３１】
[ＷＡＭファイル生成処理部]
図５は、ＷＡＭファイル生成処理部３０４を中心とするブロック図である。
ＷＡＭファイル生成処理部３０４は、データ取得処理部３０３で生成され、キャッシュファイルディレクトリ３１１に記憶されたキャッシュファイル及び検索キー・ファイル名生成テーブル３１２を参照して、各関連語毎にＷＡＭファイル５０２を生成する。そして、生成された各ＷＡＭファイル５０２に所定の名称をそれぞれ付与し、ＷＡＭファイルディレクトリ３１３に記憶する。一つの関連語につき一つのＷＡＭファイル５０２が生成されるので、関連語の数だけＷＡＭファイル５０２が生成されることになる。
【００３２】
ここで、ＷＡＭファイル５０２とは、所定の関連語と、その関連語に対応するキャッシュファイル名と、キャッシュファイル内に含まれる関連語の前後にある名詞（以下、「周辺語」という）と、そのキャッシュファイルに含まれる、関連語及び周辺語の出現頻度とが対応付けられて書き込まれたファイルである。なお、ＷＡＭファイル５０２についての詳細な説明及びＷＡＭファイル５０２の具体的な生成方法については、図１４及び図１５に基づいて後述する。
【００３３】
また、ＷＡＭファイル生成処理部３０４は、データ取得処理部３０３で生成された検索キー・ファイル名対応テーブル３１２に、関連語のフィールドの各関連語に対応するようにＷＡＭファイル名を追記し、検索キー・ファイル名対応テーブル３１２を更新する。
【００３４】
[関連語出現テーブル生成処理］
図６は、関連語出現テーブル生成処理部３０５を中心とするブロック図である。
関連語出現テーブル生成処理部３０５は、ＷＡＭファイル生成処理部３０４で生成され、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２から関連語出現テーブル３１４を生成する処理を行う。この関連語出現テーブル生成処理部３０５の処理により、一つの地名に対応する複数の関連語毎の、全てのＷＡＭファイル５０２から一つの関連語出現テーブル３１４が生成される。
【００３５】
ここで、関連語出現テーブル３１４とは、一つの地名に対する複数の関連語が、各キャッシュファイル内に含まれるか否かの判定が書き込まれたテーブルである。この関連語出現テーブル３１４は、ＧＰＳ地名マスタ３０８に含まれる地名の数だけ生成されることになる。なお、関連語出現テーブル３１４についての詳細な説明及び関連語出現テーブル３１４の具体的な生成方法については、図１６及び図１７に基づいて後述する。
【００３６】
[ベストスコアテーブル生成処理部］
図７は、ベストスコアテーブル生成処理部３０６を中心とするブロック図である。
ベストスコアテーブル生成処理部３０６は、ＷＡＭファイル生成処理部３０４で生成され、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２、及び関連語出現テーブル生成処理部３０５で生成された関連語出現テーブル３１４に基づいて、仮ベストスコアテーブル３１５（一時ファイル）を不揮発性データ記憶部２０４に生成する。そして、仮ベストスコアテーブル３１５に対し所定の処理及び計算等行い、仮スコアテーブルを順次更新し、本ベストスコアテーブル３１６を生成し、不揮発性データ記憶部２０４に記憶する。本ベストスコアテーブル３１６は、ＧＰＳ地名マスタ３０８に含まれる地名の数だけ生成される。ここで、ベストスコアテーブルとは、所定の地名の関連語から、所定の関連語との類似度が最も高くなる他の関連語２語を選び、これら二つの関連語とその類似度を、各関連語毎に書き込んだテーブルのことである。なお、ベストスコアテーブルについての詳細な説明及びベストスコアテーブルの具体的な生成方法については、図１８〜図２１に基づいて詳細に説明する。
【００３７】
[本クラスタ生成処理部]
図８は、本クラスタ生成処理部３０７を中心として機能させた場合の機能ブロック図である。
本クラスタ生成処理部３０７は、ベストスコアテーブル生成処理部３０６で生成されたベストスコアテーブルから、仮クラスタ３１７（一時ファイル）を不揮発性データ記憶部２０４に生成する。そして、仮クラスタ３１７に対し、所定の処理及び計算を行い、仮クラスタ３１７を順次更新し、本クラスタ８０２を生成し、本クラスタディレクトリ３１８に記憶する。この本クラスタ８０２は、ベストスコアテーブルの数、すなわちＧＰＳ地名マスタ３０８に含まれる地名の数だけ生成される。
【００３８】
ここで、本クラスタ８０２とは、所定の地名の関連語全てをグループ分けし、そのグループに含まれる関連語について、類似度の合計の高い順に並べたテーブルである。なお、全ての関連語と記載したが、不必要な関連語に関連する項目は本クラスタ８０２には含まれていない。本クラスタ８０２についての詳細な説明及び本クラスタ８０２の具体的な生成方法については、図２２〜図３２に基づいて行われる。
【００３９】
[バッチ処理の動作説明]
次に、本実施形態の情報検索システム１０１におけるモバイル情報検索サーバ１０３のバッチ処理の流れを説明する。
図９は、モバイル情報検索サーバ１０３を中心とするバッチ処理の動作の流れを示すシーケンス図である。
まず、モバイル情報検索サーバ１０３（クライアント）は、予めＧＰＳ地名テーブルに記憶してある地名の文字列を検索エンジン１０４側へ送信する（ステップＳ９０１）。
【００４０】
検索エンジン１０４は、地名の文字列を受けて、その地名の関連語１００語をモバイル情報検索サーバ１０３に返信する（ステップＳ９０２）。
【００４１】
図１０（ａ）は、地名とその関連語の例を示す図である。
まず、関連語の詳細について図１０（ａ）を参照して説明する。
例えば不特定多数の人が、検索エンジン１０４による検索を行う際、「新宿」プラス「単語Ｘ」を検索クエリとして入力したとする。このとき「単語Ｘ」が「新宿」の関連語となる。本実施例では、このような「単語Ｘ」の中で、「新宿」という単語と最も多い頻度で組み合わせられた「単語Ｘ」のうち上位１００語を関連語とする。なお、検索クエリとは、ユーザが検索エンジンにからウェブページを訪問する際に検索エンジンから入力したキーワードのことである。
【００４２】
図１０（ａ）では、「ルミネ（登録商標）」が１番多い頻度で「新宿」と組み合わされた関連語１である。「イタリアン」及び「レストラン」は、２番目及び３番目多い頻度で「新宿」と組み合わされた関連語２及び関連語３である。ただし、「新宿」は地名の一例であるので、「新宿」以外の地名の関連語も存在する。
【００４３】
再び、図９の説明に戻る。
モバイル情報検索サーバ１０３は、関連語１００語を受信すると、前述の地名関連語文字列１００通りを検索エンジン１０４側に送信する（ステップＳ９０３）。
【００４４】
検索エンジン１０４は、１００通りの地名関連語文字列を受けて、各地名関連語文字列を検索クエリとして検索を実行する。そして、１００通りの地名関連語文字列毎の検索結果のｈｔｍｌファイルである図１０（ｂ）に示す検索結果ｈｔｍｌファイル１００３をモバイル情報検索サーバ１０３（クライアント）側へ送信する（ステップＳ９０４）。
【００４５】
モバイル情報検索サーバ１０３は、検索結果ｈｔｍｌファイル１００３を受信すると、各検索結果ｈｔｍｌファイル１００３毎にリンクが付与されている１０００件のキャッシュページのリンク先ＵＲＬ１００４を検索エンジン１０４に送信する（Ｓ９０５）。ここでは、クライアントが受信した検索結果ｈｔｍｌファイル１００３は１００通りなので、クライアントから検索エンジン１０４に送信されるキャッシュページのリンク先ＵＲＬ１００４は１００×１０００件となる。
【００４６】
検索エンジン１０４は、キャッシュページのリンク先ＵＲＬ１００４を受信すると、そのＵＲＬにアクセスして、図１１に示すキャッシュファイル１１０２を取得する。そして、検索エンジン１０４は、１つの検索結果ｈｔｍｌファイル１００３に付き、キャッシュファイル１１０２が取得できたものの中から１００件のキャッシュファイル１１０２をクライアント側へ送信する（Ｓ９０６）。ここでは、検索結果ｈｔｍｌファイル１００３は、１００通りなので、検索エンジン１０４からモバイル情報検索サーバ１０３側に送信されるキャッシュファイル１１０２は１００×１００件となる。
【００４７】
そして、モバイル情報検索サーバ１０３側のＧＰＳ地名マスタ３０８に書き込まれている地名文字列の数だけステップＳ９０１〜ステップＳ９０６の処理を繰り返す（ステップＳ９０７）。
【００４８】
ステップＳ９０７の処理が完了すると、モバイル情報検索サーバ１０３は、地名及び検索エンジン１０４から取得した、関連語、検索結果ｈｔｍｌファイル１００３及びキャッシュファイル１１０２に対し所定の内部処理を行い前述の本クラスタ８０２を生成する。
【００４９】
[バッチ処理メインフロー]
図１２は、本実施形態の情報検索システム１０１において、バッチ処理部２０２の動作を示すフローチャートである。
データ取得処理部３０３（図３を参照）は、ＧＰＳ地名マスタ３０８に含まれる地名の検索を開始する（ステップＳ１２０１）。
【００５０】
図１３（ａ）は、ＧＰＳ地名マスタ３０８を示す図である。ＧＰＳ地名マスタ３０８の詳細について図１３（ａ）を参照して説明する。前述したように、ＧＰＳ地名マスタ３０８は、予め不揮発性データ記憶部２０４に蓄積されている。このＧＰＳ地名マスタ３０８の「地名」フィールドには、例えば「新宿」等各地の地名文字列が書き込まれている。また、「緯度範囲」フィールドには、同一のレコードにある地名の緯度範囲が書き込まれている。例えば「新宿」の緯度範囲は、「（×，○）」となる。また、「経度範囲」フィールドには、同一のレコードにある地名の経度範囲が書き込まれている。例えば「新宿」の経度範囲は、「（△，■）」となる。
【００５１】
再び、図１２の説明に戻る。
これ以降はループ処理である。最初に、カウンタを構成する変数ｉを１に初期化する（ステップＳ１２０２）。データ取得処理部３０３は、非対話型ウェブクライアント３０２を介して、ＧＰＳ地名マスタ３０８のｉ番目のレコードの「地名」をインターネット１０６上の検索エンジン１０４に送信する。そして、送信した「地名」の関連語１００語の文字列（図１０（ａ）を参照）を検索エンジン１０４から取得する（ステップＳ１２０３）。そして、地名及びその１００語の関連語がフィールドセパレータで区切られた地名関連語リスト３０９を不揮発性データ記憶部２０４に記憶する。
【００５２】
次に、データ取得処理部３０３は、地名関連語リスト３０９に書き込まれた関連語１００語の文字列を「（地名）＋（スペース）＋（関連語１）」、「（地名）＋（スペース）＋（関連語２）」、…、「（地名）＋（スペース）＋（関連語１００）」に変換するコマンドを実行し、地名関連語文字列を１００件取得する。そして、非対話型ウェブクライアント３０２を介して、１００件の地名関連語文字列をインターネット１０６上の検索エンジン１０４に順次送信し、各地名関連語文字列を含むウェブページの検索結果ｈｔｍｌファイル１００３（図１０（ｂ）を参照）１００件を検索エンジン１０４から取得する（ステップＳ１２０４）。その後、各検索結果ｈｔｍｌファイル１００３毎に検索結果ｈｔｍｌファイル名を付与し、検索結果ディレクトリに記憶する。
【００５３】
次に、データ取得処理部３０３は、検索結果ディレクトリに記憶された各検索結果ｈｔｍｌファイル１００３毎に記載された１０００件のキャッシュページのリンク先ＵＲＬに、アクセスする。このアクセスは、非対話型ウェブクライアント３０２及び検索エンジン１０４を介して行われる。そして、各検索結果ｈｔｍｌファイル１００３につき１００件のキャッシュファイル１１０２（図１１を参照）を、キャッシュファイル１１０２を取得できるキャッシュページ１００件から取得する（ステップＳ１２０５）。そして、各キャッシュファイル１１０２毎にキャッシュファイル名を付与し、キャッシュファイルディレクトリ３１１に記憶する。
【００５４】
ここで、データ取得処理部３０３は、キャッシュファイル１１０２内に住所文字列が含まれているか否かを判定する。住所文字列が含まれているならば、この住所文字列を非対話型ウェブクライアント３０２を介して、インターネット１０６上の検索エンジン１０４へ送信する。そして、住所に応じた位置情報（緯度、経度）を検索エンジン１０４から受信する。
【００５５】
そして、データ取得処理部３０３は、各地名と、各検索結果ｈｔｍｌファイル名と、各キャッシュファイル名と、各住所と、各位置情報（緯度、経度）とが対応付けられた検索キー・ファイル名対応テーブル３１２（図１３（ｂ）を参照）を生成し、不揮発性データ記憶部２０４に記憶する。ただし、住所文字列を含まないキャッシュファイル１１０２と同一レコードにある住所フィールド及び位置情報（緯度、経度）フィールドについては、空のままにしておく。また、検索キー・ファイル名対応テーブル３１２のＷＡＭファイル名のフィールドについては、後述する。
【００５６】
次に、ＷＡＭファイル生成処理部３０４は、キャッシュファイルディレクトリ３１１に記憶されたキャッシュファイル１１０２及び検索キー・ファイル名対応テーブル３１２に書き込まれている情報に基づいて各関連語毎にＷＡＭファイル５０２を生成する（ステップＳ１２０６）。そして、各ＷＡＭファイル５０２に名称を付与し、ＷＡＭファイルディレクトリ３１３に記憶する。それと同時に、関連語とＷＡＭファイル５０２が対応するように、各ＷＡＭファイル５０２の名称を検索キー・ファイル名対応テーブル３１２のＷＡＭファイル名のフィールドに書き込み、検索キー・ファイル名対応テーブル３１２を更新する。このステップＳ１２０６のＷＡＭファイル生成処理の詳細は、図１４に基づいて後述する。
【００５７】
次に、関連語出現テーブル生成処理部３０５は、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２に基づいて、関連語出現テーブル３１４を生成し（ステップＳ１２０７）、不揮発性データ記憶部２０４に記憶する。なお、このステップＳ１２０７の関連語出現テーブル生成処理については、図１６に後述する。
【００５８】
次に、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２及び関連語出現テーブル生成処理部３０５で生成された関連語出現テーブル３１４に書き込まれている情報に基づいて、ベストスコアテーブルが生成され（ステップＳ１２０８）、不揮発性データ記憶部２０４に記憶する。
ステップＳ１２０８のベストスコアテーブル生成処理については、図１８に後述する。
【００５９】
次に、ベストスコアテーブル生成処理部３０６で生成され、ベストスコアテーブルに書き込まれている情報に基づいて、本クラスタ８０２を生成する（ステップＳ１２０９）。そして、ステップＳ１２０９で生成された本クラスタ８０２が、本クラスタディレクトリ３１８に記憶される。このステップＳ１２０９の本クラスタ生成処理の詳細については、図２２に後述する。
【００６０】
以上の処理完了後、カウンタを構成する変数ｉをインクリメントする（ステップＳ１２１０）。
そして、変数ｉがＧＰＳ地名マスタ３０８の最大レコード数を超えたか否かを確認し（ステップＳ１２１１）、超えていなければ再び繰り返す（ステップＳ１２１１のＮ）。超えていれば（ステップＳ１２１１のＹ）、処理を終了する（ステップＳ１２１２）。
【００６１】
[ＷＡＭファイル生成処理フロー]
図１４は、図１２のステップＳ１２０６のＷＡＭファイル生成処理の詳細な処理の流れを示すフローチャートである。
【００６２】
図１２のステップＳ１２０６で、ＷＡＭファイル生成処理部３０４がＷＡＭファイル生成処理を開始すると（ステップＳ１４０１）、まず、現在対象としている地名で検索キー・ファイル名対応テーブル３１２（図１３（ｂ）を参照）を絞り込む（ステップＳ１４０２）。
【００６３】
以降はループ処理である。最初に、カウンタを構成する変数ｊを１に初期化する（ステップＳ１４０３）。次に、検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの検索結果ＨＴＭＬファイル名を一時変数fnameに代入する（ステップＳ１４０４）。そして、この一時変数fnameからＷＡＭファイル名を生成する（ステップＳ１４０５）。
【００６４】
続いて、ＷＡＭファイ生成処理部３０４（図３参照）は、地名で絞り込まれた検索キー・ファイル名対応テーブル３１２のｊ番目のレコードのキャッシュ名でキャッシュファイルディレクトリ３１１を検索する。そして、検索したキャッシュファイル１１０２をプレーンテキストに変換する（ステップＳ１４０６）。
【００６５】
次に、ＷＡＭファイル生成処理部３０４が、プレーンテキストに対し形態素解析を行い、プレーンテキストの形態素から名詞のみを抽出する。そして、抽出した名詞の形態素のテキスト（以下、「形態素テキスト」という）を生成する（ステップＳ１４０７）。
ここで、プレーンテキストに対して行われる形態素解析とは、対象言語の文法の知識（文法のルールの集まり）や辞書（品詞等の情報付きの単語リスト）を情報源として用い、自然言語で書かれた文書を形態素（言語で意味を持つ最小単位）の列に分割し、それぞれの品詞を判別する作業のことである。
【００６６】
次に、ＷＡＭファイル生成処理部３０４は、形態素テキストを検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの関連語で検索し、関連語及びその周辺語を抽出する。そして、ステップＳ１４０４の処理にて生成された名称のＷＡＭファイル５０２へ出力する（ステップＳ１４０８）。
このステップＳ１４０８の処理の際には、検索キー・ファイル名対応テーブル３１２のｊ番目のレコードのキャッシュファイル名と、形態素テキストにおける関連語と各周辺語の出現頻度とが、同時にステップＳ１４０４にて生成された名称のＷＡＭファイル５０２へ出力される。なお、本実施形態例では、周辺語の定義を、形態素テキスト内で関連語に一致する形態素の前後に２語ずつある、合計４語の形態素としている。
【００６７】
以上の処理完了後、カウンタを構成する変数ｊをインクリメントする（ステップＳ１４０９）。
そして、検索キー・ファイル名対応テーブル３１２に、インクリメントしたｊ番目のレコードが存在するか否かを確認する（ステップＳ１４１０）。そして、インクリメントしたｊ番目のレコードが存在する場合は（ステップＳ１４１０のＮ）、続いて、fnameと、検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの検索結果ｈｔｍｌファイル名が一致するか否かを確認する（ステップＳ１４１１）。
そして、両者が一致すると判定された場合は（ステップＳ１４１１のＹ）、ステップＳ１４０６の処理に戻り、再びステップＳ１４０６以降の処理を繰り返す。検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの検索結果ｈｔｍｌファイル名がfnameと一致しない場合は（ステップＳ１４１１のＮ）、ステップＳ１４０３の処理に戻り、それ以降の処理を再び繰り返す。
【００６８】
一方、ステップＳ１４１０において、検索キー・ファイル名対応テーブル３１２のｉ番目のレコードが存在しないと判定された場合は（ステップＳ１４１０のＹ）、処理を終了する（ステップＳ１４１２）。
【００６９】
図１５は、ＷＡＭファイル生成処理によって生成されるＷＡＭファイル５０２の例を示す図である。
ＷＡＭファイル５０２は、検索結果ｈｔｍｌファイル名が「shinjyuku_001」、すなわちＷＡＭファイル名が「shinjyuku_001.wam」（図１４のステップＳ１４０４の処理を参照）で、関連語が「新宿二丁目」（図１３（ｂ）を参照）のＷＡＭファイルである。ＷＡＭファイル５０２を例に、ＷＡＭファイルの構造について説明する。
【００７０】
ＷＡＭファイル５０２の括弧部分１５０２は、図１４のステップＳ１４０５の処理〜ステップＳ１４０７の処理（一回目）で生成される箇所に相当する。この括弧部分１５０２に注目すると、一行目には、図１３(ｂ)に示す検索キー・ファイル名対応テーブル３１２の１番目のレコードのキャッシュファイル名である「shinjyuku_001_001」が書かれている。また、２行目以降には、関連語である「新宿二丁目」と、その周辺語である「東京」、「都」、「写真」、「街」、「開催」、「バー」及び「こんど」と、が記載されている。関連語及び各周辺語の左には、キャッシュファイル１１０２「shinjyuku_001_001」の形態素テキストに出現する関連語及び各周辺語の出現頻度が書かれている。なお、ＷＡＭファイル５０２において、キャッシュファイル名「shinjyuku_001_002」、「shinjyuku_001_003」、…、「shinjyuku_001_100」に相当する箇所は、ステップＳ１４０５〜ステップＳ１４０７の処理（二回目、三回目、…、百回目）にて書き込まれる。なお、上述したように、ＷＡＭファイル５０２は、一つの地名につき、その関連語の数だけ生成される。
【００７１】
[関連語出現テーブル生成処理フロー]
図１６は、図１２のステップＳ１２０７の関連語出現テーブル生成処理の詳細な処理の流れを示すフローチャートである。
【００７２】
図１２のステップＳ１２０７で説明したように、関連語出現テーブル生成処理部３０５が関連語出現テーブル３１４生成処理を開始すると（ステップＳ１６０１）、まず、現在対象としている地名に対応する全てのＷＡＭファイル５０２（図１３（ｂ）を参照）から図１７（ａ）に示す全フィールドが“０”の関連語出現テーブル３１４を作成する（ステップＳ１６０２）。
ここで、図１７（ａ）に示す関連語出現テーブル３１４の関連語のレコードの「term（1）」、「term（2）」、「term（3）」、…、「term（100）」は、ステップＳ１６０２の処理で対象とした各ＷＡＭファイル５０２に対応する関連語に相当する。また、関連語出現テーブル３１４のキャッシュファイル名のフィールドの「shinjyuku_001_001」、「shinjyuku_001_002」、…、「shinjyuku_100_100」は、ステップＳ１６０２の処理で対象とした全てのＷＡＭファイル５０２に書かれているキャッシュファイル名に相当する。
【００７３】
再び、図１６の説明に戻る。
これ以降はループ処理である。最初に、カウンタを構成する変数ｋ，ｌ，ｍを１に初期化する（ステップＳ１６０３、ステップＳ１６０４及びステップＳ１６０５）。そして、ｌ番目のＷＡＭファイル５０２（図１５を参照）のｍ行目がキャッシュファイル名であるか否かを確認する（ステップＳ１６０６）。キャッシュ名であるならば（Ｓ１６０６のＹ）、そのキャッシュ名に対応する関連語出現テーブル３１４のレコードに移動する（ステップＳ１６０７）。
【００７４】
キャッシュ名でないならば（ステップＳ１６０６のＮ）、ｌ番目のＷＡＭファイル５０２のｍ行目の単語が関連語出現テーブル３１４のｋ番目のフィールドに対応する関連語と一致するか否かを確認する（ステップＳ１６０８）。両者が一致すると判定された場合は（ステップＳ１６０８のＹ）、ステップＳ１６０７の処理で移動した、関連語出現テーブル３１４のレコードのｋ番目のフィールドに“１”を書き込む（ステップＳ１６０９）。
【００７５】
以上の処理完了後、カウンタを構成する変数ｍをインクリメントする（ステップＳ１６１０）。
続いて、ｌ番目のＷＡＭファイル５０２において、インクリメントしたｍ行目が存在するか否かを確認する（ステップＳ１６１１）。ｌ番目のＷＡＭファイル５０２のｍ行目が、まだ存在すると判定された場合は（ステップＳ１６１１のＮ）、ステップＳ１６０６の処理に戻り、それ以降の処理を繰り返す。ステップＳ１６１１の処理でｌ番目のＷＡＭファイル５０２のｍ行目が存在しないと判定された場合は（ステップＳ１６１１のＹ）、カウンタを構成する変数ｌをインクリメントする（ステップＳ１６１２）。
【００７６】
以上の処理完了後、続いて、インクリメントされたｌ番目のＷＡＭファイル５０２が存在するか否かを確認する（ステップＳ１６１３）。ｌ番目のＷＡＭファイル５０２が、まだ存在すると判定された場合は（ステップＳ１６１３のＮ）、ステップＳ１６０５の処理に戻り、それ以降の処理を繰り返す。ｌ番目のＷＡＭファイル５０２が存在しないと判定されると（ステップＳ１６１３のＹ）、カウンタを構成する変数ｋをインクリメントする（ステップＳ１６１４）。
【００７７】
次に、関連語出現テーブル３１４のｋ番目のフィールドが存在するか否かを確認する（ステップＳ１６１５）。そして、インクリメントされたｋ番目のフィールドが関連語出現テーブル３１４に存在すると判定された場合は（ステップＳ１６１５のＮ）、ステップＳ１６０４の処理に戻り、以降の処理を繰り返す。関連語出現テーブル３１４にｋ番目のフィールドが存在しないと判定された場合は（ステップＳ１６１５のＹ）、関連語出現テーブル３１４の全フィールドが“０”のレコードを削除し（ステップＳ１６１６）、処理を終了する（ステップＳ１６１７）。
【００７８】
図１７は、関連語出現テーブルの例を示す図である。
図１７（ａ）は、初期状態の関連語出現テーブルである。この関連語出現テーブルは、図１６のステップＳ１６０２の処理で生成されるものであり、その全フィールドには“０”が書き込まれている。
【００７９】
図１７（ｂ）は、不要レコード削除前の関連語出現テーブルを示す図である。この関連語出現テーブルは、図１６のステップＳ１６１５において、インクリメントされたｋ番目のレコードがないとき（ステップＳ１６１５のＹ）に生成されるテーブルであり、テーブルの各フィールドには、“０”或いは“１”が書き込まれている。
また、図１７（ｂ）に示す関連語出現テーブルには、キャッシュファイル名の形態素テキストに関連語が含まれる場合は“１”が、含まれない場合は“０”が書き込まれている。例えば、キャッシュファイル名「shinjyuku_001_001」の形態素テキストには、関連語「tem1(1)」が含まれていない。そのため、関連語出現テーブル３１４の「shinjyuku_001_001」のレコードの「temp(1)」のフィールドには、“０”が書き込まれている。また、キャッシュファイル名「shinjyuku_100_001」の形態素テキストには、関連語「tem1(3)」が含まれている。そのため、関連語出現テーブル３１４の「shinjyuku_100_001」のレコードの「temp(3)」のフィールドには、“１”が書き込まれている。
【００８０】
図１７（ｃ）は、不要レコード削除後の関連語出現テーブルを示す図である。
この関連語出現テーブル３１４は、図１６に示すステップＳ１６１６の処理により、図１７（ｂ）に示す関連語出現テーブル３１４から全フィールドが“０”のレコードが削除されたものである。例えば、図１７（ｂ）に示す関連語出現テーブル３１４の「shinjyuku_001_001」のレコードに注目すると、「term(1)」〜「term(100)」までのすべてのフィールドが“０”となっている。このような、レコードがステップＳ１６１６の処理にて削除されることにより、図１７（ｃ）の関連語出現テーブル３１４が生成される。
【００８１】
[ベストスコアテーブル生成処理フロー]
図１８及び図１９は、図１２のステップＳ１２０８のベストスコアテーブル生成処理の詳細な処理の流れを示すフローチャートである。
【００８２】
図１２のステップＳ１２０８で、ベストスコアテーブル生成処理部３０６がベストスコアテーブル生成処理を開始すると（ステップＳ１８０１）、それ以降はループ処理となる。
最初に、カウンタを構成する変数ｎ，ｐを１に初期化する（ステップＳ１８０２及びステップＳ１８０３）。次に、ｎとｐとが等しいか否かを確認する（ステップＳ１８０４）。ｎとｐが等しくない場合には（ステップＳ１８０４のＹ）、不揮発性データ記憶部２０４に記憶された関連語出現テーブル３１４（図１７（ｃ）を参照）のｎ番目のフィールドに対応する関連語を配列変数term_xに、ｐ番目のフィールドの関連語を配列変数term_yに追記する（ステップＳ１８０５）。
【００８３】
次に、関連語出現テーブル３１４のｎ番目のterm(n)とｐ番目のterm(ｐ)のいずれかに“１”が立っているレコード数を、配列変数ornumに追記する（ステップＳ１８０６、図２０参照）。そして、関連語出現テーブル３１４のｎ番目のterm(n)とｐ番目のterm(ｐ)の両方に“１”が立っているレコード数を、配列変数andnumに追記する（ステップＳ１８０７、図２０参照）。
【００８４】
そして、ステップＳ１８０７の処理の最後に、図２０に示すandnumとornumへ追記された各値に基づいて、term_xとterm_yに最後に追記された関連語間の類似度を計算し、この類似度を、配列変数scoreに追記する（ステップＳ１８０８）。ここで、類似度とは、相異なる２つの単語間にある関連性の強さを数値で表したものである。別の言い方をすると、これらの２つの単語の共起関係を数値で示したものである。なお、類似度の計算式を以下に示す。
【００８５】
〔数１〕
score=(andnum/ornum)*log(andnum)
【００８６】
以上の処理完了後、カウンタを構成する変数ｐをインクリメントする（ステップＳ１８０９）。
そして、関連語出現テーブル３１４のｐ番目のフィールドが存在するか否かを確認する（ステップＳ１８１０）。ｐ番目のフィールドが存在する場合は（ステップＳ１８１０のＮ）、ステップＳ１８０４の処理に戻り、それ以降の処理を繰り返す。ｐ番目のフィールドが存在しないと判定された場合は（ステップＳ１８１０のＹ）、続いて、カウンタを構成する変数ｎをインクリメントする（Ｓ１８１１）。
【００８７】
次に、関連語出現テーブル３１４のｎ番目のフィールドが存在するか否かを確認する（ステップＳ１８１２）。ｎ番目のフィールドが存在する場合は（ステップＳ１８１２のＮ）、ステップＳ１８０３の処理に戻り、以降の処理を繰り返す。
【００８８】
以上の処理完了後、ステップＳ１８１２で、関連語出現テーブル３１４のｎ番目のフィールドが存在しないと判定された場合は（ステップＳ１８１２のＹ）、図１９の処理に移行する（○囲みＡ）。そして、上述したscore、andnum、ornum、term_x及びterm_yの各配列から、図２０（ａ）に示すソート前仮ベストスコアテーブル２００２を生成する（ステップＳ１９０１）。
【００８９】
そして、図２０（ａ）に示したソート前仮ベストスコアテーブル２００２のterm_xが一致するレコードの中で、score（類似度）の大きさが上位２に含まれるレコードのみ残して他のレコードは削除し、図２０（ｂ）に示すソート済仮ベストスコアテーブル２００３を生成する（ステップＳ１９０２）。このソート済仮ベストスコアテーブル２００３が、図３で示した仮ベストスコアテーブル３１５に相当する。以下、このソート済仮ベストスコアテーブル２００３を、仮ベストスコアテーブル３１５と呼ぶ。
【００９０】
これ以降はループ処理である。最初、カウンタを構成する変数ｑを初期化する（ステップＳ１９０３）。ここで、仮ベストスコアテーブル３１５のｑ番目と（ｑ＋１）番目の２レコード２１０２（図２１（ａ）を参照）より、ソート前本ベストスコアテーブル３１６の（ｑ＋１）／２番目の１レコード２１０３（図２１（ｂ）を参照）を生成する（ステップＳ１９０４）。すなわち、２レコードを１レコードに変換する処理を行う。具体的には、仮ベストスコアテーブル３１５のｑ番目のレコードのscore及びterm_yを、score_1及びterm_1にそれぞれ書き込み、（ｑ＋１）番目のレコードのscore及びterm_yはscore_2及びterm_2にそれぞれ書き込む。
【００９１】
また、仮ベストスコアテーブル３１５のｑ番目及び（ｑ＋１）番目のレコードのterm_xは等しいので、term_xをtermに書き込む。なお、ソート前本ベストスコアテーブル３１６のtotalのレコードに書き込まれる値については、後述する。
【００９２】
ステップＳ１９０４の処理完了後、ソート前本ベストスコアテーブル３１６の（ｑ＋１）／２番目のレコードのscore_1とscore_2の和を当該レコードのtotalに書き込む。
【００９３】
以上の処理完了後、カウンタを構成する変数ｑを２インクリメントする（ステップＳ１９０６）。そして、仮ベストスコアテーブル３１５のｑ番目のレコードが存在するか否かを確認する（ステップＳ１９０７）。
【００９４】
仮ベストスコアテーブル３１５にインクリメントされたｑ番目のレコードが存在する場合は（ステップＳ１９０７のＮ）、ステップ１９０４の処理に戻り、それ以降の処理を繰り返す。一方、仮ベストスコアテーブル３１５にｑ番目のレコードが存在しないと判定された場合は（ステップＳ１９０７のＹ）、図２１（ｃ）に示すように、ソート前本ベストスコアテーブル３１６の各レコードのtotalの値の大きい順に、当該各レコードを並び替える（ステップＳ１９０８）。そして、処理を終了する（ステップＳ１９０９）。なお、このステップＳ１９０８の処理によってソートされたソート前本ベストスコアテーブル３１６が、図３に示した本ベストスコアテーブル３１６に相当するものである。
【００９５】
[本クラスタ生成処理フロー]
図２２は、図１２のステップＳ１２０６の処理である、本クラスタ生成処理の詳細な処理の流れを示すフローチャートである。
【００９６】
まず、本クラスタ生成処理部３０７が本クラスタ８０２生成処理を開始する（ステップＳ２２０１）。これ以降はループ処理である。
最初に、カウンタを構成する変数ｒを１に初期化する（ステップＳ２２０２）。そして、不揮発性データ記憶部２０４に記憶された本ベストスコアテーブル３１６（図２１（ｃ）を参照）のｒ番目のレコードから仮クラスタ３１７のcid=ｒ,tid=1のレコード（図２３（ａ）を参照）を生成する（ステップＳ２２０３）。具体的には、本ベストスコアテーブル３１６のｒ番目のレコードの「total」、「term」、「score_1」、「term_1」、「score_2」及び「term_2」を仮クラスタ３１７のcid=ｒ,tid=1のレコードの「total」、「term」、「score_1」、「term_1」、「score_2」及び「term_2」にそれぞれ書き込む。
【００９７】
次に、ステップＳ２２０３の処理完了後、本ベストスコアテーブル３１６から仮クラスタ３１７のcid=ｒ,tid=2のレコード（図２３（ｂ）を参照）を生成する（ステップＳ２２０４）。具体的には、まず本ベストスコアテーブル３１６のｒ番目のレコードの「term_1」を仮クラスタ３１７のcid=ｒ,tid=2のレコードの「term」に書き込む。そして、その「term」で本ベストスコアテーブル３１６のtermフィールドを検索し、該当するレコードの「total」、「score_1」、「term_1」、「score_2」及び「term_2」を仮クラスタ３１７のcid=ｒ,tid=2のレコードの「total」、「score_1」、「term_1」、「score_2」にそれぞれ書き込む。
【００９８】
ステップＳ２２０４の処理完了後、本ベストスコアテーブル３１６から仮クラスタ３１７のcid=ｒ,tid=3のレコードを生成する（ステップＳ２２０５）。具体的には、まず本ベストスコアテーブル３１６のｒ番目のレコードの「term_2」を仮クラスタ３１７のcid=ｒ,tid=3のレコードの「term」に書き込む。そして、その「term」で本ベストスコアテーブル３１６のtermフィールドを検索し、該当するレコードの「total」、「score_1」、「term_1」、「score_2」及び「term_2」を仮クラスタ３１７のcid=ｒ,tid=3のレコードの「total」、「score_1」、「term_1」、「score_2」にそれぞれ書き込む。
【００９９】
そして、ステップＳ２２０５の処理完了後、仮クラスタ３１７のcid=ｒ,tid=1,2,3のレコードの各「term」の文字列長を当該レコードの「len」にそれぞれ書き込む（ステップＳ２２０６）。なお、以上の処理１回により生成される仮クラスタ３１７を図２３（ｃ）に示す。
【０１００】
ここで、図２３の仮クラスタ３１７の「cid」及び「tid」のフィールドについて説明する。
「cid」とは、クラスタ番号であり、「term」、つまり関連語を所定のクラスタに分類するための番号のことである。このクラスタとは、類似した特性を持つ複数の関連語の集合のことを言う。つまり、同一のクラスタ番号が付されている各関連語は、類似した特性を有している。また、クラスタ番号が小さいほど、分類された関連語と地名の関連性（共起関係）が強いということを意味する。また、「tid」とは、ターム番号であり、同一クラスタ番号の各レコード内での「term」の順位付けを行うための番号である。すなわち、仮クラスタとは、「cid」、「tid」の優先順位で各レコードが並んでいるテーブルである。
【０１０１】
なお、仮クラスタ３１７の「cnt」、「valid」、「alt」及び「stop」の各フィールドについての詳細は、図２６，図２８，図３０及び図３１にて後述する。
【０１０２】
再び、図２２の説明に戻り、本クラスタ生成処理について説明する。
以上の処理完了後、カウンタを構成する変数ｒをインクリメントする（ステップＳ２２０７）。続いて、このインクリメントされたｒ番目のレコードが本ベストスコアテーブル３１６に存在するか否かを確認する（ステップＳ２２０８）。そして、ｒ番目のレコードが存在する場合は（ステップ２２０８のＮ）、ステップＳ２２０３の処理に戻る。そして、本ベストスコアテーブル３１６のレコードの数に応じた回数の処理を繰り返し、図２４に示す仮クラスタ３１７を生成する。
【０１０３】
インクリメントされたｒ番目のレコードが本ベストスコアテーブル３１６に存在しない場合、つまり、仮クラスタ３１７の生成が完了した場合は（ステップＳ２２０８のＹ）、仮クラスタ３１７の「cnt」のフィールドに所定の値を書き込むｃｎｔ付与処理を行う（ステップＳ２２０９）。
【０１０４】
[ｃｎｔ付与処理フロー]
図２５は、図２２のステップＳ２２０９のｃｎｔ付与処理の詳細な処理の流れを示すフローチャートである。
【０１０５】
本クラスタ生成処理部３０７がｃｎｔ付与処理を開始すると（ステップＳ２５０１）、図２５に示すループ処理が行われる。
最初に、カウンタを構成する変数ｓ１に初期化し、更に仮クラスタ３１７の全レコードの「ｃｎｔ」を０に初期化する（ステップＳ２５０２）。次に、カウンタを構成する変数ｔを１に初期化する（ステップＳ２５０３）。次に、図２４に示す仮クラスタ３１７のcid=s,tid=tのレコードの「term_1」が、cid=s,tid=1,2,3の各レコードの「term」にあるか否かを確認する（ステップＳ２５０４）。「term_1」がある場合には（ステップＳ２５０４のＹ）、仮クラスタ３１７のcid=s,tid=tのレコードの「cnt」に１を加算して書き込む（ステップＳ２５０５）。
【０１０６】
そして、仮クラスタ３１７のcid=s,tid=tのレコードの「term_2」が、cid=d,tid=1,2,3の各レコードの「term」にあるか否かを確認する（ステップＳ２５０６）。「term_2」がある場合には（ステップＳ２５０４のＹ）、仮クラスタ３１７のcid=s,tid=tのレコードの「cnt」に１を加算して書き込む（ステップＳ２５０７）。
【０１０７】
以上の処理完了後、カウンタを構成する変数ｔをインクリメントする。そして、変数ｔが３より大きいか否かを確認する（ステップＳ２５０９）。インクリメントされた変数ｔが３以下であれば（ステップＳ２５０９のＮ）、ステップＳ２５０４の処理に戻り、処理を繰り返す。変数ｔが３より大きい場合には（ステップＳ２５０９のＹ）、続いて、カウンタを構成する変数ｓをインクリメントする。
【０１０８】
そして、本ベストスコアテーブル３１６にインクリメントされたｓ番目のレコードが存在するか否かを確認する（ステップＳ２５１１）。ｓ番目のレコードが存在する場合は（ステップＳ２５１１のＮ）、ステップＳ２５０３の処理に戻り、処理を繰り返す。ｓ番目のレコードが存在しないならば（ステップＳ２５１１のＹ）、処理を終了する（ステップＳ２５１２）。
【０１０９】
図２６は、ｃｎｔ付与処理によりｃｎｔ値が書き込まれた状態の仮クラスタ３１７の例を示す図である。このｃｎｔ値について図２６を参照して説明する。仮クラスタ３１７の「cnt」のフィールドには、ｃｎｔ値として０，１又は２のいずれかの値が書き込まれている。
【０１１０】
仮クラスタ３１７のcid=1,tid=1のレコードに注目する。このレコードの「南口（term_1）」及び「西口（term_2）」の両方が、仮クラスタ３１７のcid=1,tid=1,2,3のいずれかのレコードの「term」に含まれている。このような場合、ｃｎｔ値は２となる。
【０１１１】
また、仮クラスタ３１７のcid=2,tid=2のレコードに注目する。このレコードの「西口（term_1）」及び「東口（term_2）」の片方、すなわち「西口（term_1）」しか仮クラスタ３１７のcid=2,tid=1,2,3の各レコードの「term」に含まれていない。このような場合、ｃｎｔ値は１となる。
【０１１２】
また、仮クラスタ３１７のcid=6,tid=3のレコードに注目する。このレコードの「野村ビル（term_1）」及び「住友ビル（term_2）」のいずれも、仮クラスタ３１７のcid=6,tid=1,2,3の各レコードの「term」に含まれていない。このような場合、ｃｎｔ値は０となる。
【０１１３】
すなわち、ｃｎｔ値とは、所定の関連語（term）が、同一クラスタ番号に属する他の２つの関連語（term）との関連性を示す値である。ｃｎｔ値“２”は関連性がすごくあるということを、ｃｎｔ値“１”は関連性があるということを、ｃｎｔ値“０”は関連がないということを、それぞれ示している。
【０１１４】
再び、図２２に戻り、本クラスタ生成処理について説明する。
以上、図２２のステップＳ２２０９のｃｎｔ付与処理について図２５、図２６に基づいて説明したが、このｃｎｔ付与処理が完了すると、図２６に示す仮クラスタ３１７の「valid」のフィールドに所定の値を書き込むｖａｌｉｄ付与処理が行われる（ステップＳ２２１０）。次に、このｖａｌｉｄ付与処理について、その詳細を説明する。
【０１１５】
[ｖａｌｉｄ付与処理フロー]
図２７は、図２２のステップＳ２２１０のｖａｌｉｄ付与処理の詳細な処理の流れを示すフローチャートである。
以下、図２６に示すｃｎｔが付与された仮クラスタ３１７の「valid」のフィールドを更新する際の本クラスタ生成部３０７の動作について説明する。なお、以下ではｃｎｔが付与された仮クラスタ３１７のことを、説明の便宜上、単に仮クラスタ３１７と記載する。
【０１１６】
本クラスタ生成処理部３０７がｖａｌｉｄ付与処理を開始すると（ステップＳ２７０１）、まず、仮クラスタ３１７の全レコードの「valid」を０に初期化する（ステップＳ２７０２）。
これ以降はループ処理となる。最初に、カウンタを構成する変数ａを１に初期化する（ステップＳ２７０３）。
【０１１７】
そして、仮クラスタ３１７のａ番目のレコードの「valid」が“０”であるか否かを確認する（ステップＳ２７０４）。ａ番目のレコードの「valid」が“０”である場合は（ステップＳ２７０４のＹ）、仮クラスタ３１７のａ番目のレコードの「term」を一時変数tmpstrに代入する（ステップＳ２７０５）。
【０１１８】
次に、term=tmpstr及びvalid=0で仮クラスタ３１７を絞り込む（ステップＳ２７０６）。そして、絞り込んだ仮クラスタ３１７の各レコードの「cid」の小さい順に、当該各レコードを並び替える（ステップＳ２７０７）。そして、この並び替えた各レコードの最上位レコードの「valid」に１を書き込み、その他のレコードの「valid」に−１を書き込む（ステップＳ２７０８）。
【０１１９】
以上の処理完了後、カウンタを構成する変数ａをインクリメントする（ステップＳ２７０９）。一方、ステップＳ２７０４の判断で、仮クラスタ３１７のａ番目のレコードの「valid」が０でないと判定された場合は（ステップＳ２７０４）、ステップＳ２７０５〜ステップＳ２７０８の処理をすることなく、ステップＳ２７０９の処理へ移行する。
【０１２０】
次に、インクリメントされたａ番目のレコードが仮クラスタ３１７の中に存在するか否かを確認する（ステップＳ２７１０）。ａ番目のレコードが存在する場合には（ステップＳ２７１０のＮ）、ステップＳ２７０３の処理へ戻り、処理を繰り返す。ａ番目のレコードが存在しないときは（ステップＳ２７１０のＹ）、処理を終了する。
【０１２１】
図２８は、図２７で説明したｖａｌｉｄ付与処理によりｖａｌｉｄ値が書き込まれた状態の仮クラスタ３１７の例を示す図である。ｃｎｔ値について図２８を参照して説明する。仮クラスタ３１７の「valid」のフィールドには、ｖａｌｉｄ値として−１又は１いずれかの値が書き込まれている。
【０１２２】
仮クラスタ３１７のcid=1,tid=3のレコードに注目する。このレコードの「西口（term）」は、当該レコードより上位にあるレコードに含まれていない。このような場合、ｖａｌｉｄ値は“１”となる。
【０１２３】
また、仮クラスタ３１７のcid=2,tid=1のレコードに注目する。このレコードの「西口（term）」は、当該レコードより上位にあるcid=1,tid=3のレコードの「西口（term）」と一致する。このような場合、ｖａｌｉｄ値は“−１”となる。
【０１２４】
ここで、ｖａｌｉｄ値とは、仮クラスタ３１７において、対象としているレコードの「term」が、当該レコードより上位にあるレコードの「term」と重複しているか否かを判断するための設定値である。つまり、重複がない場合は、“１”が記入され、重複が有る場合は“−１”が記入される。
【０１２５】
再び、図２２の本クラスタ生成処理の説明に戻る。
以上、図２２のステップＳ２２１０のｖａｌｉｄ付与処理について図２７、図２８に基づいて説明したが、このｖａｌｉｄ付与処理が完了すると、図２８に示す仮クラスタ３１７の「alt」のフィールドに所定の値を書き込むａｌｔ付与処理に移行する（ステップＳ２２１１）。
【０１２６】
[ａｌｔ付与処理フロー]
図２９は、図２２のステップＳ２２１１のａｌｔ付与処理の詳細な処理の流れを示すフローチャートである。
以下、図２８に示すｖａｌｉｄが付与された仮クラスタ３１７の「alt」のフィールドを更新する際の本クラスタ生成処理部３０７（図３を参照）の動作について説明する。なお、以下ではｖａｌｉｄが付与された仮クラスタ３１７のことを、説明の便宜上、単に仮クラスタ３１７と呼ぶことにする。
【０１２７】
まず、図３の本クラスタ生成処理部３０７がａｌｔ付与処理を開始する（ステップＳ２９０１）。そして、仮クラスタ３１７をvalid=1で絞り込む（ステップＳ２９０２）。
【０１２８】
最初に、カウンタを構成する変数ｂを２に初期化し（ステップＳ２９０３）、図２９に示したループ処理に移行する。そして、絞り込んだ仮クラスタ３１７の「cid」がｂと一致するレコードを全て検索し、それらのレコードを一時ファイルに書き出す（ステップＳ２９０４）。
【０１２９】
ここで、一時ファイルに書き出されたレコードの数を確認する（ステップＳ２９０５）。一時ファイルに書き出されたレコードが複数ある場合には（ステップＳ２９０５のＮ）、続いて、絞り込んだ仮クラスタ３１７の「cid」がｂの全レコードの「len」の合計が１６以下であるか否かを確認する（ステップＳ２９０６）。そして、「len」の合計が１６以下である場合は（ステップＳ２９０６のＹ）、カウンタを構成する変数ｃを１に初期化する（ステップＳ２９０７）。また、ステップＳ２９０５で、一時ファイルに書き出されたレコードの数が一つだけであると判定された場合も（ステップＳ２９０５のＹ）、ステップＳ２９０７の処理に移行する。
【０１３０】
次に、一時ファイルの「cid」がｂ、レコード番号がｃのレコードの「term_1」及び「term_2」で、絞り込んだ仮クラスタ３１７の当該レコードより上位にあるレコードの「term」を検索する（ステップＳ２９０８）。そして、検索がヒットしたか否かを確認する（ステップＳ２９０９）。なお、レコード番号とは、一時ファイルの各レコードに降順に割り当てられた番号のことである。
【０１３１】
また、ステップＳ２９０９で、仮クラスタ３１７の当該レコードより上位にあるレコードの「term」検索がヒットした場合は（ステップＳ２９０９のＹ）、ヒットしたレコードの「cid」を、絞り込んだ仮クラスタ３１７の所定のレコードの「alt」に書き込む（ステップ２９１０）。この検索でヒットしたレコードの「cid」がない場合は（ステップＳ２９０９のＮ）、絞り込んだ仮クラスタ３１７の所定のレコードの「alt」に“−１”を書き込む（ステップＳ２９１１）。ここで、所定のレコードとは、一時ファイルの「cid」がｂ、レコード番号がｃのレコードの「cid」及び「tid」と一致する、仮クラスタ３１７のレコードのことである。
【０１３２】
以上の処理完了後、カウンタを構成するレコード番号の変数ｃをインクリメントする（ステップＳ１９１２）。そして、一時ファイルの「cid」がｂで、レコード番号がインクリメントされたｃのレコードが存在するか否かを確認する（ステップＳ２９１３）。該当するレコードが存在する場合には（ステップＳ１９１３のＮ）、ステップＳ２９０８の処理に戻り、以降の処理を繰り返す。該当するレコードが存在しない場合は（ステップＳ１９１３のＹ）、カウンタを構成する、一時ファイルの「cid」である変数ｂをインクリメントする（ステップＳ２９１４）。また、ステップＳ２９０６で、絞り込んだ仮クラスタ３１７の「cid」である変数ｂの全レコードの「len」の合計が“１６”を超えるときも（ステップＳ２９０６のＮ）、ステップＳ２９１４の処理へ移行し、変数ｂをインクリメントする。
【０１３３】
次に、絞り込んだ仮クラスタ３１７の「cid」の中にインクリメントされた変数ｂのレコードが存在するか否かを確認する（ステップＳ１９１５）。そして、インクリメントされた変数ｂのレコードが存在する場合には（ステップＳ２９１５のＮ）、ステップＳ２９０４の処理へ戻る。インクリメントされた変数ｂのレコードが存在しない場合は（ステップＳ２９１５のＹ）、処理を終了する（ステップＳ２９１６）。
【０１３４】
なお、仮クラスタ３１７の「alt」のフィールドに“０”以外の値が設定される条件（以下、「ａｌｔ値設定条件」という）を以下にまとめる。具体的には、以下に示す条件（１）かつ（２）または条件（１）かつ（３）の場合に、仮クラスタ３１７の「alt」のフィールドに“０”以外の値が設定される。
（１）仮クラスタ３１７の「valid」が“１”である。
（２）ステップＳ２９０４の処理で書き出された一時ファイルの各レコードの「len」の合計が“１６”以下である。
（３）ステップＳ２９０４の処理で書き出された一時ファイルのレコードが一つである。
【０１３５】
図３０は、図２９で説明したａｌｔ付与処理によりａｌｔ値が書き込まれた状態の仮クラスタ３１７の例を示す図であるである。この図３０を参照して、ａｌｔ値について説明する。仮クラスタ３１７の「alt」のフィールドには、ｃｎｔ値として−１，０又はクラスタ番号（cid）のいずれかの値が書き込まれている。
【０１３６】
例えば、仮クラスタ３１７のcid=2,tid=3のレコードに注目する。このレコードは、前述のａｌｔ値設定条件を満たしていないレコードである。そのため当該レコードの「alt」には、０が書き込まれている。
【０１３７】
また、仮クラスタ３１７のcid=9,tid=1のレコードに注目する。このレコードは、前述のａｌｔ値設定条件を満たしているレコードである。さらに、当該レコードの「ビジネスホテル（term_1）」及び「ヒルトン（商標登録）（term_2）」の両方とも、これらのレコードより上位にある全てのレコードの各「term」と一致しない場合は、ａｌｔ値は“−１”となる。ここで、当該レコードより上位にあるレコードとは、仮クラスタ３１７テーブルの中で、cidが１〜８の各レコードのことである。
【０１３８】
また、仮クラスタ３１７のcid=61,tid=1のレコードに注目する。このレコードのクラスタ番号は“６１”でありcid=61且つvalid=1の全てのレコードの「len」の合計は１０であるから、前述のａｌｔ値設定条件を満たしているレコードである。さらに、このレコードより上位にあり、同一のｃｉｄ値を有するレコード（cid=17,tid=1,2）の各「term」が、当該レコードの「映画館（term_1）」及び「映画（term_2）」の両方と一致する。このような場合、ａｌｔ値は、一致した上位のレコードの「cid」である“１７”となる。
【０１３９】
以上、図２２のステップＳ２２１１のａｌｔ付与処理について図２９、図３０に基づいて説明した。再び、図２２の本クラスタ生成処理の説明に戻る。
ステップＳ２２１１のａｌｔ付与処理が完了すると、図３０に示す仮クラスタ３１７の全レコードを検索して、ストップワードのフラグを立てる（ステップＳ２２１２）。具体的には、仮クラスタ３１７の各レコードの「term」が予め設計者の設定したストップワードに一致する場合、当該レコードの「stop」に１を書き込む。なお、ストップワードのフラグが立てられた仮クラスタ３１７の例を図３１に示す。
【０１４０】
そして、図３１に示す仮クラスタ３１７の不要なレコードを削除する（ステップＳ２２１３）。このステップＳ２２１３で削除される不要なレコードの条件は以下の通りである。
（１）「valid」のフィールドが−１のレコード
（２）「stop」のフィールドが１のレコード
（３）「cnt」のフィールドが０のレコード
【０１４１】
ここで、不要なレコードを削除した仮クラスタ３１７の「alt」が“１”以上の値が設定されているレコードを検索し、そのレコードの「cid」と「alt」を入れ替える。そして、不要なレコードを削除した仮クラスタ３１７の中で、各レコードの「cid」の小さい順に、当該各レコードを並び替え（ステップＳ２２１４）、処理を終了する（ステップＳ２２１５）。
【０１４２】
ステップＳ２２１４の処理によって並び替えられた仮クラスタ３１７は、図３で説明した本クラスタ８０２に該当する。本クラスタ８０２の例を図３２及び図３３に示す。
以上で、図２２に基づいたモバイル情報検索サーバ１０３のバッチ処理部２０２の説明を終了する。
【０１４３】
[リアルタイム処理部］
次に、図２のリアルタイム処理部２０３について説明する。
図３４は、リアルタイム処理部２０３及びデータ記憶部の一部の機能的な構成を示すブロック図である。
リアルタイム処理部２０３は、概略的にはＨＴＴＰを用いて、図１に示す携帯電話１０２にｈｔｍｌ文書を送信する、ｗｅｂサーバの機能を有している。この機能は、携帯電話１０２のｗｅｂブラウザプログラム１１３からの要求に応じて行われるものである。
【０１４４】
リアルタイム処理部２０３は、一般的なネットワークＯＳが稼働するコンピュータである。ネットワークＯＳは、一例として、ＦｒｅｅＢＳＤ等のＢＳＤ系、或いはＬｉｎｕｘ（登録商標）等のＰＯＳＩＸ（Portable Operating System Interface for UNIX）（ＵＮＩＸは登録商標）系ＯＳ等が挙げられる。
【０１４５】
以下、図３４に示す機能ブロック図に基づいて、リアルタイム処理部２０３の構成について説明する。
リアルタイム処理部２０３は、上述したように、ｗｅｂサーバ機能を持つｗｅｂサーバプログラム３４０２を備えている。このｗｅｂサーバプログラム３４０２は、携帯電話１０２から来る要求（コマンド）を受信し、これに応じて、ＨＴＴＰにてｈｔｍｌ文書をクライアントへ送信する機能を提供する。端的に言えば、ｗｅｂサーバソフトウェアであり、一例としてはＡｐａｃｈｅ（http://www.apache.org/）等が、これに該当する。
【０１４６】
また、ｗｅｂサーバプログラム３４０２は、携帯電話１０２の要求に応じ、ｃｇｉ（Common Gateway Interface）の実行も行う。ｃｇｉの実体は、標準出力にテキストを出力するプログラムである。このｃｇｉが生成するテキストが、ｗｅｂサーバプログラムによってＨＴＴＰにて携帯電話１０２へ送信される。図３４では、第１のｃｇｉ３４０３の他、第２のｃｇｉ３４０７〜第４のｃｇｉ３４０９まで用意されている。
【０１４７】
これらのｃｇｉを構成する要素としては、どのようなプログラミング言語であってもよい。ｐｅｒｌ（http://www.perl.org/）やＰＨＰ（http://php.net/）、ｐｙｔｈｏｎ（http://www.python.org/ja/）、ｒｕｂｙ（http://www.ruby-lang.org/ja/）等のインタプリタ言語のみならず、Ｃ言語やＪａｖａ（登録商標）等のコンパイルを要する言語であってもよい。簡単な内容であれば、シェルスクリプトであってもよい。
【０１４８】
各々のｃｇｉは、主にｗｅｂブラウザに表示する画面を作るためのｈｔｍｌ文書を作成する。つまり、ｈｔｍｌ文書はｗｅｂブラウザを通じてＧＵＩを作成する手段である。
なお、図３４では、上述のように、携帯電話の表示部に表示させる画面ごとに４つのｃｇｉが個別に設けられているが、単一のｃｇｉで構成することも可能である。ただし、その場合は、単一のｃｇｉの中に複数の表示画面を作成する機能が含まれることとなる。
【０１４９】
第一のｃｇｉ３４０３は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行される。
第一のｃｇｉ３４０３は、携帯電話１０２から得られたパラメータであるユーザの現在位置情報で不揮発性データ記憶部２０４に記憶されているＧＰＳ地名マスタ３０８を検索する。そして、ＧＰＳ地名マスタ３０８から現在位置情報に応じた地名を取得する。また、第一のｃｇｉ３４０３は、取得した地名をキーとして、本クラスタディレクトリ３１８を検索し、入力した地名と対応する本クラスタ８０２を取得する。
【０１５０】
そして、この取得した本クラスタ８０２を表示用本クラスタ３４０４に変換し、不揮発性データ記憶部に表示用一時ファイル３４０４として記憶する。なお、表示用本クラスタ３４０４とは、本クラスタ８０２から所定のレコードを削除したものである。この表示用本クラスタ３４０４の詳細については図３８及び図３９にて後述する。
【０１５１】
また、本クラスタ８０２から表示用本クラスタ３４０４に変換する際には、第一のｃｇｉ３４０３は、携帯電話１０２の表示部の大きさ、フォントの大きさ及びフォントの種類を考慮した表示用本クラスタ３４０４を生成するようにする。この表示用本クラスタ３４０４の生成は、予め不揮発性データ記憶部２０４に記憶された携帯端末マスタ３４０５及びリアルタイム処理部２０３に存在しているプロポーショナルフォントファイル３４０６を参照しながら第一のｃｇｉ３４０３によって行われる。
【０１５２】
携帯端末マスタ３４０５には、様々な携帯電話の画面（表示部）の大きさを示す情報が記憶されている。また、プロポーショナルフォントファイル３４０６には、携帯電話１０２がプロポーショナルフォントでの画面表示を要求してきた際に、そのフォント幅に対応した表示用本クラスタ３４０４を生成するための情報が記憶されている。
【０１５３】
第一のｃｇｉ３４０３は、この表示用本クラスタ３４０４（表示用一時ファイル）に基づいて、携帯電話１０２の表示部に、分類の選択画面を表示するｈｔｍｌ文書を作成する。なお、分類の選択画面とは、表示用本クラスタ３４０４を、その「cid」毎に分類して「term」が表示された画面のことである。ただし、分類の選択画面の詳細については、図３６にて後述する。第一のｃｇｉは、本クラスタ送信部ともいえる。
【０１５４】
第二のｃｇｉ３４０７は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行されるｃｇｉである。
第二のｃｇｉ３４０７は、分類の選択画面を表示している携帯電話から、得られたパラメータである地名及び関連語で検索キー・ファイル名対応テーブル３１２（図１３（ｂ）を参照）を検索する。そして、検索キー・ファイル名対応テーブル３１２から、地名及び関連語に対応する検索結果ｈｔｍｌファイル名を取得する。
【０１５５】
第二のｃｇｉ３４０７は、この検索結果ｈｔｍｌファイル名で検索結果ｈｔｍｌファイルディレクトリ３１０を検索し、検索結果ｈｔｍｌファイルを取得する。そして、第二のｃｇｉ３４０７は、取得した検索結果ｈｔｍｌファイルを携帯電話用のｈｔｍｌファイルに変換し、携帯電話１０２の表示部に検索結果画面を表示するためのｈｔｍｌ文書を作成する。
なお、検索結果画面とは、地名及び関連語を検索クエリとして、検索エンジン１０４（図１参照）で検索を行った際の画面のことであり、その詳細については図３７（ａ）にて後述する。ただし、ここでの地名及び関連語は、分類の選択画面を表示している携帯電話１０２から得られるパラメータのことである。
【０１５６】
第三のｃｇｉ３４０８は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行される。このプログラムによって実行される第三のｃｇｉ３４０８による処理が後述するリアルタイム処理（３）を行うブロック（図３５のステップＳ３５０８、図４２）である。
第三のｃｇｉ３４０８は、検索結果画面を表示している携帯電話１０２から、得られたパラメータであるキャッシュファイル名で検索キー・ファイル名対応テーブル３１２を検索する。そして、検索キー・ファイル名対応テーブル３１２から、キャッシュファイル名を取得する。第三のｃｇｉ３４０８は、このファイル名でキャッシュファイルディレクトリ３１１を検索して、キャッシュファイルを取得する。
【０１５７】
キャッシュファイルのプレーンテキストに住所文字列が含まれていない場合、第三のｃｇｉ３４０８は、取得したキャッシュファイルを携帯電話ｈｔｍｌに変換する。第三のｃｇｉ３４０８によって変換された携帯電話ｈｔｍｌは、携帯電話１０２の表示部１１１にキャッシュファイルのプレーンテキストを表示するｈｔｍｌ文書である。
【０１５８】
一方、キャッシュファイルのプレーンテキストに住所文字列が含まれている場合、第三のｃｇｉ３４０８は、検索キー・ファイル名対応テーブル３１２の緯度・経度のフィールドから位置情報を取得して、地図サーバ１０５へのＡタグを生成する。そして、第三のｃｇｉ３４０８は、Ａタグ及びキャッシュファイルを基にして、携帯電話１０２の表示部１１１に地図付きキャッシュ画面を表示するｈｔｍｌ文書を作成する。なお、地図付きキャッシュ画面とは、キャッシュファイルのプレーンテキストと共にプレーンテキストに記載された位置情報を中心とする地図を含む画面のことである。ただし、地図付きキャッシュ画面の詳細については、図３７にて後述する。
【０１５９】
第四のｃｇｉ３４０９は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行される。このプログラムによる第四のｃｇｉ３４０９の処理が後述する連想語検索処理を行うブロック（図４３のステップＳ４３０３，図４５）である。
第四のｃｇｉ３４０９は、分類の選択画面３６０２を表示している携帯電話１０２から得られるパラメータの中で、クラスタ番号で第一のｃｇｉにて生成された表示用本クラスタ３４０４クラスタ番号(cid)に属する関連語（term）を全て取得する。そして、この取得した各関連語でＷＡＭファイルディレクトリ３１３を検索する。
この検索により、ＷＡＭファイルディレクトリ３１３から各関連語のＷＡＭファイル全てを取得し、これらＷＡＭファイルから連想語テーブル３４１０を生成する。連想語テーブル３４１０とは、携帯電話１０２から得られた各関連語の連想語が書かれたテーブルのことである。なお、連想語とは、各関連語から連想される単語のことである。この連想語テーブルについては、図４６にて後述する。
【０１６０】
第四のｃｇｉ３４０９は、連想語テーブル３４１０に基づいて、携帯電話１０２の表示部１１１に連想語画面を表示するｈｔｍｌ文書を作成する。なお、連想語画面とは、連想語テーブル３４１０に書かれている各連想語を羅列した画面のことである。ただし、連想語画面の詳細については、図４４にて後述する。
【０１６１】
[リアルタイム処理部の動作]
次に、リアルタイム処理の流れを説明する。
図３５は、携帯電話１０２（クライアント）、モバイル情報検索サーバ１０３及び地図サーバ１０５の間で行われる動作を示すシーケンス図である。
まず、ユーザは、携帯電話１０２の所定のアプリケーションを起動する。すると、携帯電話１０２は、ＧＰＳ受信部１０８において、ＧＰＳ衛星１０７より携帯電話１０２の現在位置情報（以下、「ＧＰＳ位置データ」という）を取得し、入出力制御部１０９を通じてモバイル情報検索サーバ１０３に送信する（ステップＳ３５０１）。ここで、ＧＰＳ位置データとは、携帯電話１０２の現在位置の緯度及び経度のことである。以下では、携帯電話１０２の現在位置が新宿の場合を例として、リアルタイム処理の流れを説明する。また、ステップＳ３５０１の処理の際に、携帯電話１０２は、入出力制御部１０９を通じて、携帯電話１０２のユーザエージェント文字列もモバイル情報検索サーバ１０３に送信するようにしている。
【０１６２】
モバイル情報検索サーバ１０３は、ＧＰＳ位置データすなわち新宿の緯度及び経度を受信する。そして、現在位置情報及びユーザエージェント文字列に基づいて、図３８にて後述するリアルタイム処理（１）を実行し（ステップＳ３５０２）、携帯電話１０２の表示部１１１に図３６に示す分類の選択画面３６０２を表示するｈｔｍｌ文書を作成して、クライアント側へ送信する（ステップＳ３５０３）。
【０１６３】
次に、携帯電話１０２は、後述するリアルタイム処理（１）で作成されたｈｔｍｌ文書を入出力制御部１０９により取得・解釈する。そして、このｈｔｍｌ文書は表示制御部１１０を通じて表示部１１１に入力される。これにより、携帯電話１０２の表示部１１１に分類の選択画面３６０２が表示される。図３６に示されるように、分類の選択画面３６０２には、現在位置の地名「新宿」に対する関連語がクラスタ番号毎に、すなわちクラスタ毎に分類されて表示されている。ユーザは、携帯電話１０２の入力部１１２を操作して、分類の選択画面３６０２から、例えば「レストラン」という関連語を選択する。すると、携帯電話１０２は、「（現在位置の地名）＋（スペース）＋（関連語）」である「（新宿）＋（スペース）＋（レストラン）」の文字列をモバイル情報検索サーバ１０３側に送信する（ステップＳ３５０４）。
【０１６４】
モバイル情報検索サーバ１０３は、「（新宿）＋（スペース）＋（レストラン）」という文字列を受信する。そして、この文字列に基づいて、図４１にて後述するリアルタイム処理（２）を実行し（ステップＳ３５０５）、携帯電話１０２の表示部１１１に図３７（ａ）に示す検索結果画面３７０２を表示するｈｔｍｌ文書を作成して、クライアント側へ送信する（ステップＳ３５０６）。
【０１６５】
携帯電話１０２は、後述するリアルタイム処理（２）で作成されたｈｔｍｌ文書を入出力制御部１０９により取得・解釈する。そして、このｈｔｍｌ文書は表示制御部１１０を通じて表示部１１１に入力され、携帯電話１０２の表示部１１１に検索結果画面３７０２が表示される。このとき、検索結果画面３７０２には、「（新宿）＋（スペース）＋（レストラン）」を検索クエリにしてウェブページを検索した検索結果が表示されている。ユーザは、携帯電話１０２の入力部１１２を操作して、検索結果画面３７０２の「■（黒四角）」ボタン３７０３或いは「□（白四角）」ボタン３７０４を選択すると、所定のキャッシュファイル名がモバイル情報検索サーバ１０３側へ送信される（ステップＳ３５０７）。なお、「■（黒四角）」ボタン３７０３は、モバイル情報検索サーバ１０３側へ送信されるキャッシュファイル名のキャッシュファイル内に住所が含まれているリンクボタンであり、「□（白四角）」ボタン３７０４はキャッシュファイル内に住所が含まれていないリンクボタンである。
【０１６６】
モバイル情報検索サーバ１０３は、例えば「■（黒四角）」ボタン３７０３に対応するキャッシュファイル名を受信したとする。すると、このキャッシュファイル名に基づいて、図４２にて後述するリアルタイム処理（３）を行う。そして、携帯電話１０２の表示部１１１に地図キャッシュ画面を表示するｈｔｍｌ文書を作成し（ステップＳ３５０８）、クライアント側へ送信する（ステップＳ３５０９）。
【０１６７】
携帯電話１０２は、リアルタイム処理（３）で作成されたｈｔｍｌ文書を入出力制御部１０９により取得・解釈する。そして、地図サーバ１０５に地図画像要求を送信する（ステップＳ３５１０）。すなわち、このリアルタイム処理（３）で生成されたｈｔｍｌ文書には、地図画像３７０６の所在を示す地図サーバ１０５のＵＲＬが記載されており、携帯電話１０２の入出力制御部１０９は、携帯電話１０２に当該ＵＲＬの地図画像３７０６を送信するように地図サーバ１０５に要求する。この要求を受けて、地図サーバ１０５は、地図画像３７０６を携帯電話１０２（クライアント）側へ送信する（ステップＳ３５１１）。
【０１６８】
携帯電話１０２は、地図サーバ１０５から地図画像３７０６を受信して、表示部１１１に、図３７（ｂ）に示されるような地図付きキャッシュ画面３７０５を表示する。なお、地図付きキャッシュ画面３７０５の「☆（星印）」記号３７０７の位置は、キャッシュファイル内に含まれる住所に一致している。具体的には、地図付きキャッシュ画面３７０５に表示された、東京都新宿区歌舞伎町○−△□−□という住所に当たる。
【０１６９】
[リアルタイム処理（１）フロー]
図３８は、図３５のＳ３５０２のリアルタイム処理（１）の詳細な処理の流れを示すフローチャートである。
【０１７０】
図３５のステップＳ３５０２で説明したように、第一のｃｇｉが処理を開始すると（ステップＳ３８０１）、第一のｃｇｉ３４０３は携帯電話１０２から受信したＧＰＳ位置データで、ＧＰＳ地名マスタ３０８（図３を参照）を検索する（ステップＳ３８０２）。そして、ＧＰＳ地名マスタ３０８から検索がヒットした地名を取得する。
【０１７１】
次に、地名を検索クエリとして本クラスタディレクトリ３１８を検索し（ステップＳ３８０４）、地名に応じた本クラスタ８０２（図８、図３２及び図３３を参照）を取得する。そして、第一のｃｇｉ３４０３は、ＧＰＳ位置データと共に携帯電話１０２が取得したユーザエージェント文字列を基にして、携帯端末マスタ３４０５を検索する。そして、携帯端末マスタ３４０５の検索によって、携帯電話１０２の機種名を取得する。
なお、携帯端末マスタ３４０５の中には、携帯電話１０２の機種名及びその画面に関する諸情報が記録されている。例えば、等幅フォントであれば、画面の幅はバイト数で決定できる。また、プロポーショナルフォントを使っている場合は、画面に収められる文字数がその文字列によって変化する。そこで、携帯端末マスタ３４０５で画面に関する諸情報を取得して、本クラスタ８０２をその携帯端末に最適な表示用本クラスタ３４０４に変換するのである（ステップＳ３８０５）。
【０１７２】
次に、このようにして変換した表示用本クラスタ３４０４を携帯電話ｈｔｍｌ文書に変換する（ステップＳ３８０６）。最後に、第一のｃｇｉ３４０３は、変換したｈｔｍｌ文書をクライアントに送信して（ステップＳ３８０７）、一連の処理を終了する（ステップＳ３８０８）。なお、等幅フォントを使用する場合は、画面のバイト数で本クラスタ８０２から表示用本クラスタ３４０４に変換する文字数が一意的に“１”に決められる。ただし、プロポーショナルフォントを使う場合は、本クラスタ８０２で表示しようとする関連語の文字列を、プロプロポーショナルフォントファイル３４０６を使って参照し、それら文字列を表示するのに必要な画面のピクセル数を得る。画面のピクセル数と携帯電話１０２の画面の横幅とを比較して最適な文字数を決定する。
【０１７３】
図３９は、表示用の本クラスタの一例を示す。
この例は、図３２及び図３３に示す本クラスタ８０２を携帯端末毎に最適な表示用形態に変換したものである。ここで、図３２及び図３３に示す本クラスタ８０２の各レコードと、図３９に示す表示用本クラスタ３４０４の各レコードとを比較する。すると、表示用本クラスタ３４０４は、本クラスタ８０２から所定のレコードを削除したものであることが確認できる。つまり、携帯電話上で最適化できる表示に変換した結果、表示用本クラスタ３４０４は、本クラスタ８０２のcid=3,8,12,17,33,48,62のレコードのみを残して削除したものとなっている。なお、本クラスタ８０２から削除するレコードの条件は、同一の「cid」のレコードの各「term」の文字列数すなわち「len」合計が２０以上３０以下のレコードである。ただし、「term」が複数ある場合は、各「term」の間にはスペースが入るので、「term」の数だけスペースの文字列数が追加される。
【０１７４】
また、本クラスタ８０２から表示用本クラスタ３４０４に変換する際、cid=17の各レコードに注目すると、図３２に示されるcid=17，tid=4のレコードのみ削除されている。このレコードを含めてしまうと合計文字列数が３１となり、レコードを削除する条件を満たしてしまうためである。図３２のcid=3,tid=3のレコードも同様の理由で削除される。
【０１７５】
図４０は、表示用本クラスタ３４０４のｈｔｍｌ文書の一例を示した図である。
表示用本クラスタｈｔｍｌ文書４００２は、携帯電話１０２の表示部１１１に図３６に示す分類の表示画面を表示させるｈｔｍｌ文書である。
以下、表示用本クラスタｈｔｍｌ文書４００２に記載されている単語の並びについて説明する。
【０１７６】
図３９に示す表示用本クラスタ３４０４の各パラメータの中で、表示用本クラスタｈｔｍｌ文書４００２を生成するのに必要なパラメータは、「cid」、「tid」及び「term」である。
ここで、表示用本クラスタｈｔｍｌ文書４００２の一行目に注目する。
この行には、表示用本クラスタ３４０４の「cid」が最も小さいレコードの「term」である「カプセルホテル」及び「新宿区役所」が、「tid」の小さい順に左から並んでいる。また、一番左の「カプセルホテル」のさらに左脇には、表示用本クラスタ３４０４の中で最も「cid」が小さい、つまり「新宿」という地名に最も関連しているクラスタであることを示す「（０１）」が付与されている。なお、表示用本クラスタｈｔｍｌ文書４００２の一行目以降も一行目と同様の特徴を持っている。
【０１７７】
以上のような特徴を持った表示用本クラスタｈｔｍｌ文書４００２を携帯電話１０２に送信することにより、携帯電話１０２は、その表示部１１１に図３６に示す分類の選択画面３６０２を表示する。
【０１７８】
[リアルタイム処理（２）フロー]
図４１は、図３５のＳ３５０５のリアルタイム処理（２）の詳細な処理の流れを示すフローチャートである。
【０１７９】
図３５のステップＳ３５０５で説明したように、携帯電話１０２から地名＋関連語というパラメータが送られると（ステップＳ４１０１）、第二のｃｇｉ３４０７は、この携帯電話１０２から受信した地名＋関連語を検索クエリとして、検索キー・ファイル名対応テーブル３１２を検索する。そして、その結果、検索結果ｈｔｍｌファイル名を取得する（ステップS４１０２）。
【０１８０】
この検索結果ｈｔｍｌファイル名の検索結果ｈｔｍｌファイルは、検索エンジン１０４から取得した検索結果のｈｔｍｌファイルである。このｈｔｍｌファイルに書かれているＡタグを選択すると検索エンジン１０４にアクセスしてしまうので、そこはモバイル情報検索サーバ１０３宛のアクセスを示すＡタグに書き換えなければならない。
そこで、第二のｃｇｉ３４０７は、この検索結果ｈｔｍｌファイルに記されている検索エンジン１０４宛のＡタグを、モバイル情報検索サーバ１０３宛のＡタグに変換する処理を行う（ステップＳ４１０３）。そして、変換されたｈｔｍｌファイルを携帯電話（クライアント）１０２に送信して（ステップＳ４１０４）、処理を終了する（ステップＳ４１０５）。
【０１８１】
[リアルタイム処理（３）フロー]
図４２は、図３５のＳ３５０８のリアルタイム処理（３）の詳細な処理の流れを示すフローチャートである。
【０１８２】
図３５のステップＳ３５０８で説明したように、ユーザが携帯電話１０２で検索結果ｈｔｍｌファイルのＡタグの一つを選択すると、そこに埋め込まれているキャッシュファイル名がモバイル情報検索サーバ１０３に送信される（ステップＳ４２０１）。
【０１８３】
第三のｃｇｉ３４０８は、キャッシュファイル名を検索キーとして、検索キー・ファイル名対応テーブル３１２を検索する。そして、検索にヒットしたレコードの住所フィールドをみる（ステップＳ４２０２）。そこで、この住所フィールドが何らかの文字列が含まれるかどうか、すなわち住所が含まれているかどうか確認する（ステップＳ４２０３）。もし住所フィールドに住所が含まれているのであれば、そのレコードの緯度・経度フィールドを読んで、地図サーバ１０５へのイメージタグを生成する（ステップＳ４２０４）。そして、キャッシュファイルを地図サーバ１０５へのイメージタグを含む携帯用ｈｔｍｌファイルに変換する（ステップＳ４２０５）。
そして、このようにして生成した携帯用ｈｔｍｌファイルをクライアントである携帯電話１０２へ送信して（ステップＳ４２０６）、処理を終了する（ステップＳ４２０７）。
【０１８４】
もし、ステップＳ４２０３の処理において、住所フィールドが空である場合、すなわち住所を含んでいなかったならば、住所がないので先に説明したステップＳ４２０４のような変換は一切行わず、単にキャッシュファイルを携帯用ｈｔｍｌファイルに変換する（ステップＳ４２０８）。それをクライアントに送信し（ステップＳ４２０６）、処理を終了する（ステップＳ４２０７）。
【０１８５】
[連想語検索処理フロー]
図４３は、携帯電話１０２とモバイル情報検索サーバ１０３との間で行われる連想語検索処理の流れを示すシーケンス図である。
ここでは、図３５におけるリアルタイム処理（１）から、ユーザがクラスタを選択した場合の動作の流れを示している。
【０１８６】
図３６において関連語をクリックした動作は、図３５で説明した動作であったが、この図４３に示される動作は、図３６の関連語の前にある「ｗ」の記号をクリックした時の動作である。
【０１８７】
リアルタイム処理（１）までの処理は、図３５で説明した処理と同じである。
携帯電話１０２を保有するユーザは、表示用本クラスタ３４０４ｈｔｍｌ、すなわち分類の選択画面３６０２を表示した中で、「ｗ」の記号３６０３を選択する。これは、クラスタの選択に相当する。すると、「ｗ」の記号３６０３の中に埋め込まれているクラスタ番号が、第四のｃｇｉ３４０９に向けて送信される。そして、第四のｃｇｉ３４０９は、連想語検索を行って連想語表示画面を携帯電話１０２の表示部１１１に表示するｈｔｍｌ文書（以下、「連想語検索結果ｈｔｍｌ文書」という）を携帯電話１０２（クライアント）に送信する。以降、この連想語結果検索ｈｔｍｌ文書に従って、ユーザは連想語のさらに絞り込みを行ったり、連想語の連想語を検索したりする等の操作を継続することとなる。
【０１８８】
図４４は、連想語検索処理の結果として、携帯電話１０２の表示部１１１に表示される連想検索結果を示す一例である。
図４４（ａ）は、新宿のレストラン及びイタリアンという単語について連想語検索処理を行った結果を示す図である。
ここで、図４４（ａ）に示す関連語の連想語検索結果画面４４０２上のフレンチの横にあるｗ記号４４０３をクリックすると、図４４（ｂ）に示す連想語の連想語検索結果画面４４０４が表示されることとなる。ここでは、新宿のフレンチ、レストラン及びイタリアンの連想語検索結果画面４４０４が表示されている。すなわち、レストラン及びイタリアンという単語に、さらにフレンチという連想語が追加されて検索されたものとなる。このようにして、連想語の連想語、更に、連想語の連想語の連想語、…、という風に、芋づる式に、連想語検索処理を行うことができる。
【０１８９】
ここから、このような連想語検索処理の動作について、図４５に基づいて詳細に説明する。
図４５は、図４３のＳ４３０３の連想語検索処理の詳細な処理の流れを示すフローチャートである。
【０１９０】
図４３のステップＳ４３０３で説明したように、携帯電話１０２からクラスタ番号を受信すると（ステップＳ４５０１）、第四のｃｇｉ３４０９は表示用本クラスタ３４０４から得られた同一クラスタに属する関連語のＷＡＭファイルを全て取得する（ステップＳ４５０２）。
【０１９１】
そして、第四のｃｇｉ３４０９は、取得した処理対象のＷＡＭファイルをソートする。そうすると、キャッシュファイル名は上の方に、単語（関連語及び周辺語）はその単語の出現頻度と共に、キャッシュファイル名の下に並ぶこととなる。そこで、単語の部分のみを抜き出して、出現する単語の出現頻度を加算する。そして、単語を連想語テーブル３４１０の「aterm」のフィールドに、当該単語の出現頻度を加算した結果を連想語テーブル３４１０の「wcnt」のフィールドに順次書き込む（ステップＳ４５０３）。
【０１９２】
次に、処理対象となるＷＡＭファイルから、関連語テーブルの「aterm」フィールドの各単語が出現するキャッシュファイルの数を、連想語テーブル３４１０の「pcnt」フィールドに順次書き込む（ステップＳ４５０４）。
【０１９３】
続いて、第四のｃｇｉ３４０９は、連想語テーブル３４１０の各レコード毎に、「wcnt」及び「pcnt」からＴＦＩＤＦ値を計算し、その計算結果を当該各レコードの「tfidf」のフィールドに順次書き込む（ステップＳ４５０５）。ＴＦＩＤＦ値とは、文章中の特徴的な単語（重要とみなされる単語）を抽出するためのアルゴリズムであり、主に情報検索や文章要約などの分野で利用される。なお、ＴＦＩＤＦ値の計算式を以下に示す。計算式において、“１００００”は検索エンジン１０４からモバイル検索サーバ１０３が取得したキャッシュファイルの総数に対応している。また、対数の項に加算される“１”は、ｐｃｎｔの値が小さいときに、ＴＦＩＤＦ値が“０”となることを回避するための調整値である。
【０１９４】
〔数２〕
tfidf=wcnt*(1+log(10000/pcnt))
【０１９５】
第四のｃｇｉ３４０９は、さらにＴＦＩＤＦ値の大きい順に連想語テーブル３４１０の並び替えを行う。そして、連想語テーブル３４１０の「aterm」が連想語またはストップワードと一致するレコードを削除する（ステップ４５０７）。その結果として、第四のｃｇｉ３４０９は、連想語テーブル３４１０からｈｔｍｌ文書を作成し、それを送信して（ステップＳ４５０８）、処理を終了する（ステップＳ４５０９）。
【０１９６】
図４６は、連想語テーブル３４１０の中身の一例を示す図である。
図４６（ａ）は、図４５のステップＳ４５０５の処理の時点の連想語テーブル３４１０の中身である。
図４６（ｂ）は、図４５のステップ４５０７の処理を経た連想語テーブル３４１０の中身である。
図４６（ａ）の連想語テーブル３４１０に対して、ＴＦＩＤＦ値の大きい順に連想語テーブル３４１０の各レコードをソートした後に、「aterm」がストップワード（東京）及び関連語（レストラン、イタリアン）と一致するレコードを削除する。すると、連想語のみが抽出された図４６（ｂ）の連想語テーブル３４１０が生成される。なお、以上の処理により生成された連想語テーブル３４１０をｈｔｍｌ文書に変換して、携帯電話１０２の表示部１１１に表示させたものが、図４４（ｂ）に示す連想語検索結果画面である。
【０１９７】
本実施形態には、以下のような応用例が考えられる。
（１）例えば、検索エンジン１０４には、検索対象の言葉のカテゴリの深さを開示する機能がある。そこで、このカテゴリの深さというものを検索結果に反映させることで、より最適な検索結果の表示を実現することができる。
【０１９８】
図４７は、深さ付与処理の流れを示すフローチャートである。
深さ付与処理とは、検索対象の関連語（term）の深さを表示用本クラスタ３４０４に与える処理である。
図３８には図示していないが、この深さ付与処理は、図３８のステップＳ３８０５の処理とステップＳ３８０６の処理の間に挿入される処理である。この処理は、オプションで必要に応じて行われる。
【０１９９】
ここで、処理を開始すると（ステップＳ４７０１）、表示用本クラスタ３４０４の先頭レコードに注目する（ステップＳ４７０２）。そして、変数ｄに現在注目しているレコードの「cid」を代入する（ステップＳ４７０３）。
【０２００】
次に、表示用本クラスタ３４０４の現在のレコードの「term」を、図示しない深さテーブルで検索して、「term」の深さを得る（ステップＳ４７０４）。なお、深さテーブルとは、表示用本クラスタ３４０４の「term」とその深さが対応付けられて書き込まれているテーブルのことである。ただし、この深さの情報は、予め検索エンジン１０４から取得して、深さテーブルに書き込んでおく。
【０２０１】
以上のようにして得た「深さ」の情報を、表示用本クラスタ３４０４の現在のレコードの「new_tid」に書き込む（ステップＳ４７０５）。
以上の処理が完了すると、表示用本クラスタ３４０４のレコードをインクリメントし、現在のレコードの次にあるレコードに注目する（ステップＳ４７０６）。
【０２０２】
次に、表示用本クラスタ３４０４にまだレコードが存在するか否かを確認する（ステップＳ４７０７）。レコードがまだ存在する場合には（ステップＳ４７０７のＹ）、現在注目しているレコードの「cid」が変数ｄと等しいか否かを確認する（ステップＳ４７０８）。注目レコードの「cid」が変数ｄと等しい場合は（ステップＳ４７０８のＮ）、ステップＳ４７０４の処理に戻り、再びステップＳ４７０４以降の処理を繰り返す。注目レコードの「cid」が変数ｄと等しくない場合には（ステップＳ４７０８のＹ）、表示用本クラスタ３４０４のcid=dの各レコードの「new_tid」の最小値を、当該各レコードの「new_cid」に書き込む（ステップＳ４７０９）。
【０２０３】
ステップＳ４７０７の処理にて、表示用本クラスタ３４０４のレコードが存在しない場合には（ステップＳ４７０７のＮ）、「new_cid」、「cid」、「new_tid」の順にソートのキーの優先順位を設定して、表示用本クラスタ３４０４の各レコードを並び替え（ステップＳ４７１０）、処理を終了する（ステップＳ４７１１）。
【０２０４】
図４８は、図４７で説明した深さ付与処理において用いる表示用本クラスタ４８０２である。
図３９の表示用本クラスタ３４０４と違う点は、「new_cid」及び「new_tid」というフィールドが新たに付与されている点である。これらのフィールドが深さ付与処理において有効に機能することとなる。
図４９は、深さで分類した表示用本クラスタの中身を示す図である。すなわち、図４９の表示用本クラスタ４９０２は、図４８の表示用本クラスタ４９０２をステップＳ４７１０で処理することによって、並び替えたものである。具体的には、「new_cid」が第一優先、「cid」が第二優先「new_tid」が第三優先となった並び替え結果となる。
【０２０５】
図５０は、携帯電話１０２の表示画面に関連する図である。
図５０（ａ）は、深さ付与処理がなされた表示用本クラスタｈｔｍｌ文書の一例である。
深さで分類した表示用本クラスタｈｔｍｌ文書５００２は、携帯電話１０２の表示部１１１に図５０（ｂ）に示す分類の選択画面５００３を表示させるｈｔｍｌ文書である。なお、分類の選択画面５００３は、図３６に示す分類の選択画面３６０２と同じ特徴を持っているので、説明は省略する。
【０２０６】
以下、本クラスタｈｔｍｌ文書に記載されている単語の並びについて説明する。
図４９に示す本クラスタの各パラメータの中で、深さで分類した表示用本クラスタｈｔｍｌ文書５００２を生成するのに必要なパラメータは、「cid」、「new_cid」及び「new_tid」である。
ここで、深さで分類した表示用本クラスタｈｔｍｌ文書５００２の一行目に注目する。
この行には、図４９に示す表示用本クラスタ４８０２の「cid」と「new_cid」の合計が最も小さいレコードの「term」である「レストラン」及び「イタリアン」が、「new_tid」の小さい順に左から並んでいる。また、図５０（ａ）に示すように、一番左の「レストラン」のさらに左脇には、表示用本クラスタ４８０２の中で最も「cid」と「new_cid」の合計が小さい、つまり「新宿」という地名に最も関連しているクラスタであることを示す「（０１）」が付与されている。なお、深さで分類した表示用本クラスタｈｔｍｌ文書５００２の一行目以降も一行目と同様の特徴を持っている。
【０２０７】
以上のような、深さ付与処理を行うことによって、表示内容が表示される関連語（term）がより最適化されて分類される。
【０２０８】
（２）上述の実施形態においては、携帯電話１０２の現在位置の地名を検索クエリとして、自動的にモバイル情報検索サーバ１０３に送信した。その代替えとして、検索エンジン１０４のリアルタイム処理部２０２に、図５１に示すアプリケーション起動時表示画面５１０２を携帯電話１０２に表示するｈｔｍｌ文書を作成するｃｇｉを設けておけば、入力部１１２からユーザの所望する文字列、例えば地名以外の固有名詞等を入力することにより、その文字列を検索クエリとしてモバイル情報検索サーバ１０３に送信できるようにしてもよい。なお、携帯電話１０２から地名以外の固有名詞を検索クエリとしてリアルタイムサーバに送信する場合は、ＧＰＳ地名マスタの代わりに、固有名詞等が書かれたマスタを不揮発性記憶装置に用意しておく必要がある。
【０２０９】
（３）上述の実施形態においては、携帯電話１０２の現在位置の地名を検索クエリとして、自動的にモバイル情報検索サーバ１０３に送信したが、その代替えとして、携帯電話１０２の現在位置付近の駅名或いは地名等を選択的にモバイル情報検索サーバ１０３に送信できるようにしてもよい。
【０２１０】
（４）上述の実施形態においては、モバイル情報検索サーバ１０３と検索エンジン１０４はインターネット１０６を介して接続されているが、その代替として、モバイル情報検索サーバ１０３及び検索エンジン１０４を一体化したサーバを用いることもできる。
【０２１１】
（５）上述の実施形態において、モバイル情報検索サーバ１０３は、検索エンジン１０４から所定の地名の関連語を取得したが、当該地名に関連するような単語を取得できるのであればいかなるものから取得してもかまわない。例えば、関連語を取得できる場所としては、その地名に関連する情報が記載されているホームページ等があげられる。
【０２１２】
（６）上記の実施形態においては、ＷＡＭファイル生成処理部３０４は、検索対象として日本語を想定し、形態素解析を行ったが、日本語以外の言語に対しては、接辞処理（ｓｔｅｍｍｉｎｇ）を行うことで、語形変化の多様性を正規化することができる。ここで、接辞処理とは、予め用意された規則にしたがって接尾辞や接頭辞を削除し、語基（ｓｔｅｍ）のみを残す処理のことである。
【０２１３】
また、検索エンジン１０４には、単語を別の単語に翻訳する機能がある。関連語の分類表示は単語の羅列であり、文法構造を含まないため、係り受け構造の解析などの複雑な翻訳処理を必要としない。上記の実施形態においては、携帯電話１０２の表示言語として日本語を想定しているが、関連語を日本語以外の別の言語の翻訳することにより、言語横断検索を行ってもよい。関連語の翻訳処理は、携帯電話１０２の表示の直前に行われる処理である。すなわち図４７に示す深さ付与処理のステップＳ４７１０の処理とステップＳ４７１１の処理の間で行われる処理である。この処理は、必要に応じてオプションスイッチとして提供することが望ましい。
【０２１４】
（７）上記の実施形態においては、〔数１〕により、単語間の関連性の強さを計算している。これは、発明者の行ったデータ実験において、〔数１〕が他の計算式よりも、良い精度で共起関係を抽出できることが確認されたためである。〔数１〕の代替として、共起関係を抽出するための計算式として情報検索の分野でよく知られている、相互情報量、カイ二乗値、シンプソン係数などの計算式を用いても良い。なお、これらの計算式によっても、ある程度の精度で、関連語の共起関係を抽出することができることが発明者によって確認されている。
【０２１５】
（８）また、ＷＡＭファイルに対し、全文検索を実行してもよい。このためには、予めインデックス作成プログラムを用いて、ＷＡＭファイル内に含まれるキャッシュファイル名、検索結果ｈｔｍｌファイル名及びＷＡＭファイル内の単語の出現頻度等を高速に検索することができる、インデックスファイルを作成しておく。そして、全文検索実行時には、全文検索エンジンがインデックスファイルにアクセスして、高速な検索を実現する。これにより、図１６に示すステップＳ１６１１、ステップＳ１６１３及びステップＳ１６１５のループ処理をする必要がなくなり、処理の高速化を実現できる。
【０２１６】
また、ＷＡＭファイルに対して全文検索エンジンによる全文検索を用いることにより、第二のｃｇｉ３４０７の処理を一部代替することができる。具体的には、図４１のステップＳ４１０２を、「地名＋関連語で全てのＷＡＭファイルを対象に全文検索を実行する」、とする。そして、ステップＳ４１０３は、「検索にヒットしたＷＡＭファイル名からキャッシュファイル名へのＡタグを生成する」、とする。
【０２１７】
また、図４１のステップＳ４１０２は、上記ＷＡＭファイルに対する全文検索エンジンによる全文検索に代えて、キャッシュファイルに対する全文検索エンジンによる全文検索を用いた処理とすることができる。この場合は、検索結果にノイズがやや増えるものの、詳細な検索を行いたい場合に向いている。
【０２１８】
なお、このような全文検索エンジンを用いることで、地名＋関連語に限らず、連想語を含む任意の単語を用いた検索も実現できる。
【０２１９】
（９）また、第二のｃｇｉ３４０７は、図１３の検索キー・ファイル名対応テーブル３１２から取得した検索結果ｈｔｍｌファイル１００３を、検索クエリのＴＦＩＤＦ値の大きいものの順で順序付けしてから、携帯電話１０２に検索結果画面を表示するためのｈｔｍｌ文書を作成してもよい。
【０２２０】
また、検索結果ｈｔｍｌファイル１００３は、図１３の検索キー・ファイル名対応テーブル３１２から取得した（緯度、経度）とユーザの現在位置の（緯度、経度）のユークリッド距離の小さいものの順で順序付けしても良い。
【０２２１】
検索結果ｈｔｍｌファイル１００３の順序付けは、必要に応じてオプションスイッチとして提供することが望ましい。また、順序付けは、ユーザからの要求に応じて選択的に行うようにしてもよい。
【０２２２】
（１０）上記の実施形態においては、ＧＰＳ受信部１０８から得られる位置情報に対応する地名を取得しているが、携帯電話１０２の保有する音声認識の機能により地名等の固有名詞を取得してもよい。
また、ユーザが受信したメールからコピーアンドペーストの機能により切り出した固有名詞を取得してもよい。これらの処理は、図３８のステップＳ３８０２及びステップＳ３８０３の処理、すなわち地名（固有名詞）を取得する手段の代替となる。なお、これらの処理は、必要に応じてオプションスイッチとして提供することが望ましい。
【０２２３】
以上説明したように、本実施形態では、検索エンジンが提供する、地名に対して強い結びつきを示す関連語を出力するサービスを有効活用している。「地名＋関連語＜１＞」、「地名＋関連語＜２＞」、…、で検索して、そこから得られる各ウェブサイトのキャッシュファイルに対し、各関連語の前後の数単語だけに情報を絞り込んでいる。この情報を基に、各キャッシュファイルにおける各関連語同士の出現頻度を計算して、各関連語の分類を行う。情報が絞り込まれているから、情報の純度が高い、逆に言えば、ノイズが少ない。こうして、分類分けされた各関連語の群をユーザに提示することで、情報をその地名に由来するクラスタ毎に整理して提供できる。
それにより、ユーザは目的地に立って、携帯電話に所定の操作を行うだけで、地名入力せずとも、その土地に由来する情報が整理された状態で提供される。したがって、ユーザの利便性が向上するという利点がある。
【０２２４】
また、本実施形態では、本クラスタを作成する際に、仮クラスタの各レコードにストップワードのフラグを設定する。つまり、ストップワードを含むレコードを最後に削除する。このため、ユーザにとって不要な情報を除外できるので、関連語を各カテゴリに分類する際の分類精度を向上させることができる。
【０２２５】
また、本実施形態は、携帯画面の表示可能文字数に合わせて、適切な文字列長で各クラスタに分類した関連語を表示できるように、本クラスタを表示用本クラスタに変換する。これにより、関連語の意味的な類似性を保ちつつ、携帯電話の小さな画面を有効活用した、分類表示が実現できる。
【０２２６】
また、本実施形態は、携帯画面に限らず、表示可能文字数が制限されている入出力機器一般、任意文字列の入力が制限されるタッチパネルモニタ付情報端末、高齢者、障害者、幼児など入出力の自由度が制限されたユーザ向けの端末においても、適応可能である。その際、本実施形態の特色である、ユーザの直感に合致する、適切なキーワード（検索クエリ）をクラスタリングして提供できるので、ユーザにとって易しい操作性を提供できると共に、検索出力結果もユーザが希望する内容に合致し易い。
【０２２７】
以上、本発明の実施形態の例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含むことはいうまでもない。
【図面の簡単な説明】
【０２２８】
【図１】本発明の一実施の形態による、情報検索システムの全体概略図及び携帯電話の機能ブロック図である。
【図２】モバイル情報検索サーバの機能ブロック図である。
【図３】バッチ処理部及び不揮発性データ記憶部の機能ブロック図である。
【図４】データ取得処理部を中心とする機能ブロック図である。
【図５】ＷＡＭファイル生成処理部を中心とする機能ブロック図である。
【図６】関連語出現テーブル生成処理部を中心とする機能ブロック図である。
【図７】ベストスコアテーブル生成処理部を中心とする機能ブロック図である。
【図８】本クラスタ生成処理部を中心とする機能ブロック図である。
【図９】モバイル情報検索サーバと検索エンジンとの間で行われる動作を示すシーケンス図である。
【図１０】検索エンジンから送信される関連語及び検索結果ｈｔｍｌファイルを示す図である。
【図１１】検索エンジンから送信されるキャッシュファイルを示す図である。
【図１２】モバイル情報検索サーバを構成するバッチ処理部の動作の流れを示すフローチャートである。
【図１３】ＧＰＳ地名マスタ及び検索キー・ファイル名対応テーブルを示す図である。
【図１４】バッチ処理部を構成するＷＡＭファイル生成処理部の動作の流れを示すフローチャートである。
【図１５】ＷＡＭファイル示す図である。
【図１６】バッチ処理部を構成する関連語出現テーブル生成処理部の動作の流れを示すフローチャートである。
【図１７】関連語出現テーブルを示す図である。
【図１８】バッチ処理部を構成するベストスコアテーブル生成処理部の動作の流れを示すフローチャートである。
【図１９】バッチ処理部を構成するベストスコアテーブル生成処理部の動作の流れを示すフローチャートの続きである。
【図２０】仮ベストスコアテーブルの更新を示す図である。
【図２１】本ベストスコアテーブルを示す図である。
【図２２】バッチ処理部を構成する本クラスタ生成処理部の動作の流れを示すフローチャートである。
【図２３】仮クラスタの生成手順を示す図である。
【図２４】仮クラスタを示す図である。
【図２５】本クラスタ生成処理部のｃｎｔ付与処理の詳細な処理の流れを示すフローチャートである。
【図２６】ｃｎｔが付与された仮クラスタを示す図である。
【図２７】本クラスタ生成処理部のｖａｌｉｄ付与処理の詳細な処理の流れを示すフローチャートである。
【図２８】ｖａｌｉｄが付与された仮クラスタを示す図である。
【図２９】本クラスタ生成処理部のａｌｔ付与処理の詳細な処理の流れを示すフローチャートである。
【図３０】ａｌｔが付与された仮クラスタを示す図である。
【図３１】ストップワードが付与された仮クラスタを示す図である。
【図３２】本クラスタを示す図である。
【図３３】本クラスタを示す図の続きである。
【図３４】リアルタイム処理部及び不揮発性データ記憶部の機能ブロック図を示す図である。
【図３５】携帯電話とモバイル情報検索サーバと地図サーバとの間で行われる動作の流れを示すシーケンス図である。
【図３６】携帯電話の画面に表示される分類の表示画面を示す図である。
【図３７】携帯電話の画面に表示される検索結果画面及び地図付きキャッシュ画面を示す図である。
【図３８】リアルタイム処理部を構成する第一のｃｇｉで行われる動作の流れを示すフローチャートである。
【図３９】表示用本クラスタを示す図である。
【図４０】表示用本クラスタｈｔｍｌ文書を示す図である。
【図４１】リアルタイム処理部を構成する第二のｃｇｉで行われる動作の流れを示すフローチャートである。
【図４２】リアルタイム処理部を構成する第三のｃｇｉで行われる動作の流れを示すフローチャートである。
【図４３】携帯電話とモバイル情報検索サーバとの間で行われる連想語検索に関する動作の流れを示すシーケンス図である。
【図４４】携帯電話に表示される連想語検索結果画面を示す図である。
【図４５】リアルタイム処理部を構成する第四のｃｇｉで行われる動作の流れを示すフローチャートである。
【図４６】連想語テーブルを示す図である。
【図４７】リアルタイム処理部を構成する第一のｃｇｉで行われる深さ付与処理の流れを示すフローチャートである。
【図４８】深さを付与した表示用本クラスタを示す図である。
【図４９】深さで分類した表示用本クラスタを示す図である。
【図５０】深さで分類した分類の選択画面を示す図である。
【図５１】携帯電話に表示されるアプリケーション起動時の表示画面を示す図である。
【符号の説明】
【０２２９】
１０１…情報検索システム、１０２…携帯電話、１０３…モバイル情報検索サーバ、１０４…検索エンジン、１０５…地図サーバ、１０６…インターネット、１０７…ＧＰＳ衛星、１０８…ＧＰＳ受信部、１０９…入出力制御部、１１０…表示制御部、１１１…表示部、１１２…入力部、１１３…ｗｅｂブラウザプログラム、２０２…バッチ理部、２０３…リアルタイム処理部、２０４…不揮発性データ記憶部、３０２…非対話型ウェブクライアント、３０３…データ取得処理部、３０４…ＷＡＭファイル生成処理部、３０５…関連語出現テーブル生成処理部、３０６…ベストスコアテーブル生成処理部、３０７…本クラスタ生成処理部、３０８…ＧＰＳ地名マスタ、３０９…地名関連語リスト、３１０…検索結果ファイルディレクトリ、３１１…キャッシュファイルディレクトリ、３１２…検索キー・ファイル名対応テーブル、３１３…ＷＡＭファイルディレクトリ、３１４…関連語出現テーブル、３１５…仮ベストスコアテーブル、３１６…本ベストスコアテーブル、３１７…仮クラスタ、３１８…本クラスタディレクトリ、３１９…本クラスタ作成部、５０２…ＷＡＭファイル、８０２…本クラスタ、１００３…検索結果ｈｔｍｌファイル、１００４…リンク先ＵＲＬ、１１０２…キャッシュファイル、１５０２…括弧、２００２…ソート前仮ベストスコアテーブル、２００３…ソート済仮ベストスコアテーブル（仮ベストスコアテーブル）、２１０２…２レコード、２１０３…１レコード、３４０２…ｗｅｂサーバプログラム、３４０３…第一のｃｉ、３４０４…表示用本クラスタ、３４０５…携帯端末マスタ、３４０６…プロポーショナルフォントファイル、３４０７…第二のｃｇｉ、３４０８…第三のｃｇｉ、３４０９…第四のｃｇｉ、３４１０…連想語テーブル、３６０２…分類の選択画面、記号…３６０３、３７０２…検索結果画面、３７０３…ボタン、３７０４…ボタン、３７０５…地図付きキャッシュ画面、３７０６…地図画像、３７０７…記号、４００２…表示用本クラスタｈｔｍｌ文書、４４０２…関連語の連想語検索結果画面、４４０３…記号、４４０４…連想語の連想語検索結果画面、４８０２…表示用本クラスタ、５００２点深さで分類した表意洋本クラスタｈｔｍｌ文書、５００３…深さで分類した分類の選択画面、５１０２…アプリケーション起動時表示画面
【技術分野】
【０００１】
本発明は、情報検索システム及び情報検索装置にかかり、特に、検索エンジンによって文書データを検索する情報検索システム及び情報検索装置に関する。
【背景技術】
【０００２】
近年、携帯電話の普及により、携帯電話からインターネット上の検索エンジンを用いて、さまざまな検索が行われている。しかし、流行している物や現象、人名、企業、商品、サービス、テレビ番組、地名、駅名等を検索クエリとして情報を検索することは決して易しくはない。これは、ユーザが検索対象についてあまり詳しく知らないために、適切な関連語で検索結果を絞り込むことが困難であるからである。
また、検索クエリで検索される膨大な検索結果を全て閲覧するのではなく、興味のあるウェブページ群だけ概観したいという要求もある。
【０００３】
パソコンを用いた検索では、検索対象となる文章集合の中には類似した文章が含まれることが多いため、予め文書集合を類似度に応じて分類しておき、検索時にはこれらのグループと検索クエリとの類似度を計算するクラスタ型の検索が知られている。
また、ある検索クエリで検索される検索結果ウェブページ群は、多数の類似したウェブページが含まれるので、適切な分類を行うことにより、検索結果を容易に絞り込むことができると共に、検索結果を概観することも容易になる。
なお、非特許文献１にクラスタ型の検索に関する先行技術文献を記す。
【０００４】
【非特許文献１】徳永健伸、「情報検索と言語処理」、東京大学出版会、（１９９９）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記非特許文献１に記載の技術では、ウェブページ内のテキストデータ全文を利用して関連語を分類している。このようなテキストデータ全文の中には、ユーザの検索ニーズに合致しない雑多な情報が多数含まれている。そのため、ユーザにとって意味が分からない関連語を含むクラスタや、検索対象を絞り込む上で役に立たないクラスタが生成されてしまうという問題が発生する。すなわち、分類された関連語が、ユーザにとって分かりにくく、利便性の低いものとなるという不都合がある。特に、一般名詞とは異なる特徴を持つ固有名詞、例えば地名、駅名及び人名等の関連語の分類を行う際には、上述した問題点が顕著に現れることが、本発明者の過去の研究より明らかとなっている。
【０００６】
携帯電話のウェブブラウザでクラスタ型検索を実行すると問題はもっと複雑になる。つまり、携帯電話の表示画面は、パソコンの表示画面に比べて小さいため、一行に表示できる文字列の数が限られている。そのため、やみくもに関連語の分類を行い、分類された関連語全てを携帯電話の画面に表示しようとすると、見た目が悪いだけでなく、ユーザにとって非常に分かりづらい画面表示となってしまうという問題がある。
【０００７】
本発明は斯かる点に鑑みてなされたものであり、固有名詞の関連語を適切に分類することにより、携帯電話のような小さい表示画面に関連語の分類画面を表示する場合でも、ユーザにとって使い勝手が良い情報検索システム及び情報検索装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る情報検索システムは、クライアントと、クライアントに情報を提供する情報検索サーバと、情報検索サーバの要求にしたがって所定の情報を出力する検索エンジンとよりなる情報検索システムであって、クライアントは、現在位置情報を取得するＧＰＳ受信部と、所定の情報を表示する表示部と、表示部を制御する表示制御部と、ＧＰＳ受信部から得られる位置情報を送信すると共に、所定の情報を受信して表示制御部に渡す入出力制御部とを備え、検索エンジンは、所定の単語が入力されると単語の関連語を出力するものであり、情報検索サーバは、情報検索エンジンから所定の情報を受信して加工するバッチ処理部と、バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、不揮発性データ記憶部に蓄積された加工された情報をクライアントに送信するリアルタイム処理部とを備え、不揮発性データ記憶部は、ＧＰＳ受信部から入出力制御部を通じて得られる現在位置情報に対応する地名が格納されているＧＰＳ地名マスタと、情報検索エンジンから得られる、地名とその関連語群が格納される地名関連語リストと、地名と関連語群から作成される地名と各々の関連語の組よりなる複数の検索クエリをそれぞれ情報検索エンジンにて検索した結果が記録される検索結果ファイル群が格納される検索結果ファイルディレクトリと、検索結果ファイル群に記載されているＵＲＬから得られる、地名と関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、検索結果ファイル毎に作成され、ネットワーク上の文書群に含まれる関連語を中心とする前後の単語がネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、ＷＡＭファイル中に出現する関連語の関係が記されている関連語出現テーブルと、ＷＡＭファイル中に出現する関連語の類似度が記されている本ベストスコアテーブルと、本ベストスコアテーブルから生成され、クライアントへ送信される本クラスタが格納される本クラスタディレクトリとを備え、バッチ処理部は、ＧＰＳ地名マスタに含まれている地名を検索エンジンに与えて地名関連語リストを取得し、地名関連語リストから地名と関連語の組を検索エンジンに与えて検索結果の文書を検索結果ファイルディレクトリに格納すると共に、検索結果の文書に記載されているＵＲＬから得られる、地名と関連語の組が含まれているネットワーク上の文書をキャッシュファイルディレクトリに格納するデータ取得処理部と、ネットワーク上の文書に含まれる関連語を中心とする前後の単語を取り出してネットワーク上の文書のファイル名と共にＷＡＭファイルに書き出し、ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、同一の地名に係る複数のＷＡＭファイルに基づいて、ネットワーク上の文書群と関連語の有無の関係を関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、関連語出現テーブルを基に全ての各関連語同士の類似度を算出した後、類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、第一関連語、第二関連語及び第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、本ベストスコアテーブルを基に、クライアントへ送信される本クラスタを作成して本クラスタディレクトリに格納する本クラスタ生成処理部とを備え、リアルタイム処理部は、クライアントから得られる現在位置情報を受けて対応する地名をＧＰＳ地名マスタから取得して、本クラスタディレクトリから地名に対応する本クラスタを取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部とを備えることを特徴とする。
【０００９】
地名や人名等の固有名詞は、事物或は人物そのものを特定する名称であるので、本質的に特有の意味を持たない。しかし、一方で、その土地や人物には、固有に由来する様々な事象がある。つまり、固有名詞は、その人物や事物自体を指し示す観点においては一義的であるものの、その人物や事物に由来する事象において多義的である。
人は固有名詞からそれに由来する様々な事象を連想する。その事象は個々の目的や趣味趣向等によって極めて多彩である。このため、検索システムは固有名詞を検索クエリとして与えられた時に、固有名詞から連想される複数の側面を端的に示すキーワードを用いて、そのような複数の側面を分類する必要がある。
あるキーワードとキーワードとの間の関係は、一つの文書の中に同時に現れるだけでなく、それぞれの出現する場所が極めて近い場合が多い。
発明者はこの点に注目し、関連語同士の出現頻度を算出する対象を、文書中の関連語の前後数ワードに絞った。
更に、関連語同士の類似度を算出し、その上澄みとも言える２レコードだけ取り出し、クラスタリング処理を行った。
【００１０】
上記構成によれば、携帯電話の表示画面の大きさにかかわらず、適切に各関連語が分類された本クラスタを作成することができる。
【発明の効果】
【００１１】
本発明により、携帯電話のような小さい表示画面に関連語の分類画面を表示する場合でも、ユーザにとって使い勝手が良い情報検索システム及び情報検索装置を提供することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態の例を、図１〜図５１を参照して説明する。
【００１３】
〔全体構成〕
図１（ａ）は、本発明の一実施形態例である情報検索システムの概略図である。
また、図１（ｂ）は、本実施形態例に用いられる携帯電話１０２の機能を示すブロック図である。本実施形態例は、この図１（ｂ）に示す携帯電話１０２を保有するユーザに対して効果的に情報（コンテンツ）を提供する情報検索システムである。
この情報検索システム１０１は、携帯電話１０２、モバイル情報検索サーバ１０３、検索エンジン１０４及び地図サーバ１０５より構成されており、図１(a)に示すように、これらの各要素がインターネット１０６上で相互に接続されている。
【００１４】
携帯電話１０２は、ＧＰＳ（Global Positioning System）衛星１０７からユーザの現在位置情報を取得し、インターネット１０６を介してその現在位置情報をモバイル情報検索サーバ１０３に送信する。また、ユーザの操作によって、後述するようなさまざまな指示をモバイル情報検索サーバ１０３に送信する。
【００１５】
モバイル情報検索サーバ１０３は、携帯電話１０２から送信されたユーザの指示に基づいて、検索エンジン１０４及び地図サーバ１０５よりさまざまな情報を取得する。検索エンジン１０４及び地図サーバ１０５からの情報の取得は、インターネット１０６を介して行われる。モバイル情報検索サーバ１０３は、検索エンジン１０４及び地図サーバ１０５から送信された情報に所定の処理を加え、ユーザの携帯電話１０２に対する操作に応じたｈｔｍｌ（Hyper Text Markup Language）文書を周知のＨＴＴＰ（Hyper Text Transfer Protocol）にて携帯電話１０２へ送信する。
モバイル情報検索サーバ１０３は、情報検索装置ともいえる。
【００１６】
検索エンジン１０４は、インターネット１０６に存在する情報（ウェブページ、ウェブサイト、画像ファイル、住所など）を検索する機能を提供するｗｅｂサーバである。
地図サーバ１０５は、入力された位置情報に基づいて、所定の範囲の地図画像をユーザに提供する周知のｗｅｂサーバである。
【００１７】
〔携帯電話〕
図１（ｂ）は、携帯電話の機能的な構成を示すブロック図である。なお、図（ｂ）は本実施形態に用いられる機能ブロック図のみを示している。したがって、通話等の、本実施形態と関係のない機能の記載は省略している。
ＧＰＳ受信部１０８は、ＧＰＳ衛星１０７から受信した電波を受信し、携帯電話１０２のユーザの現在位置情報（緯度・経度等）を取得し、その現在位置情報を入出力制御部１０９へ出力する。
【００１８】
ＧＰＳ受信部１０８から現在位置情報の入力があると、入出力制御部１０９は、インターネット１０６を介して、モバイル情報検索サーバ１０３へ現在位置情報を送信する。また、モバイル情報検索サーバ１０３から携帯電話１０２へｈｔｍｌ文書が送信された場合、入出力制御部１０９は、そのｈｔｍｌ文書を受信し、表示制御部１１０を通じて表示部１１１へ送る。そして、表示部１１１において、モバイル検索サーバ１０３から送られたｈｔｍｌ文書が表示される。
【００１９】
入力部１１２は、操作キー等である。ユーザは、この操作キーを操作することにより、表示部１１１で表示されたｈｔｍｌ文書の各リンクを選択したり、ｈｔｍｌ文書の所定の領域に文字列を入力したりする。このようなユーザの入力部１１２に対する操作は、入出力制御部１０９を介して、インターネット１０６上のモバイル情報検索サーバ１０３、検索エンジン１０４及び地図サーバ１０５へ送信される。
【００２０】
〔モバイル情報検索サーバ〕
図２は、モバイル情報検索サーバの機能的な構成を示すブロック図である。
モバイル情報検索サーバ１０３は、大まかには、バッチ処理部２０２、リアルタイム処理部２０３及び不揮発性データ記憶部２０４よりなる。
【００２１】
バッチ処理部２０２は、例えばシェルスクリプト等により、モバイル情報検索サーバ１０３で行われる処理の一部をサーバのリソースがあまり忙しくない時間帯（例えば、夜間等）に稼動する。ここで処理の一部とは、携帯電話１０２からのユーザの指示を受けなくても行える処理、つまりモバイル情報検索サーバ１０３のみで行える処理のことを指している。具体的には、所定の情報を検索エンジン１０４及び地図サーバ１０５より取得し、これらの情報を携帯電話１０２のユーザに提供するためのｈｔｍｌ文書を作成するための形式に変換する処理、及び不揮発性データ記憶部２０４に記憶する処理のことである。なお、バッチ処理部２０２の内部構成及びバッチ処理部２０２で行われるより詳細な処理については図４〜図３３にて後述する。
【００２２】
リアルタイム処理部２０３は、ユーザによる携帯電話１０２の操作に応じた処理をリアルタイムで行う部分である。ここで、リアルタイム処理とは、予めバッチ処理部２０２で生成され、不揮発性データ記憶部２０４に記憶された所定の情報に基づいて、携帯電話１０２に適合するｈｔｍｌ文書に変換する処理、及び携帯電話１０２へｈｔｍｌ文書を送信する処理のことである。なお、リアルタイム処理部２０３の内部構成及びリアルタイム処理部２０３で行われるより詳細な処理については図３４〜図４６にて後述する。
【００２３】
[バッチ処理部］
図３は、バッチ処理部２０２及び不揮発性データ記憶部２０４の一部の機能的な構成を示すブロック図である。
バッチ処理部２０２は、非対話型ウェブクライアント３０２と、データ取得処理部３０３と、本クラスタ作成部３１９とからなる。
データ取得処理部３０３は、非対話型ウェブクライアント３０２を介して所定の情報を取得する。
【００２４】
本クラスタ作成部３１９は、データ取得処理部３０３が取得した情報を呼び出し、その情報に基づいて、後述する本クラスタを作成する。なお、本クラスタ作成部３１９は、ＷＡＭ（Word-Article Matrix）ファイル生成処理部３０４と、関連語出現テーブル生成処理部３０５と、ベストスコアテーブル生成処理部３０６と、本クラスタ生成処理部３０７とからなる。
【００２５】
これらバッチ処理部２０２の各ブロックで生成された情報は、不揮発性データ記憶部２０４の所定の領域に適宜記憶される。この不揮発性データ記憶部２０４には、ＧＰＳ地名マスタ３０８、地名関連語リスト３０９、検索結果ファイルディレクトリ３１０、キャッシュファイルディレクトリ３１１、検索キー・ファイル名対応テーブル３１２、ＷＡＭファイルディレクトリ３１３、関連語出現テーブル３１４、仮ベストスコアテーブル３１５（一時ファイル）、本ベストスコアテーブル３１６、仮クラスタ３１７（一時ファイル）及び本クラスタディレクトリ３１８を記憶する領域が存在する。
不揮発性データ記憶部を構成する上記各要素間の関係とそれぞれの動作については、後述する。
【００２６】
以下、バッチ処理部２０２の各ブロックの機能について、図４〜図８を参照して説明する。
【００２７】
[データ取得処理部]
図４は、データ取得処理部３０３を中心とするブロック図である。
データ取得処理部３０３は、非対話型ウェブクライアント３０２及びインターネット１０６を介して検索エンジン１０４と相互に情報のやり取りを行う。データ取得処理部３０３は、予め不揮発性データ記憶部２０４に記憶してあるＧＰＳ地名マスタ３０８にアクセスし、全ての地名の文字列を取得する。この地名の文字列と地図上の経度緯度との関係は後述する図１３（ａ）に示されている。
そして、各地名の文字列を順次非対話型ウェブクライアント３０２を介して、検索エンジン１０４に送信する。ここで、検索エンジン１０４から返信される情報を基にして、データ取得処理部３０３は、各地名とその地名に関する複数の単語（以下、「関連語」という）が対応付けられた、後述する地名関連語リスト３０９を生成し、不揮発性データ記憶部２０４に記憶する。
【００２８】
また、データ取得処理部３０３は、不揮発性データ記憶部２０４に地名関連語リスト３０９を生成後、その地名関連語リスト３０９にアクセスし、各関連語毎に「（地名）＋（カンマ）＋（関連語１）＋（関連語２）＋…＋（関連語１００）」の文字列を取得する。そして、「（地名）＋（スペース）＋（関連語１）」、「（地名）＋（スペース）＋（関連語２）」、…、「(地名)＋(スペース)＋(関連語１００)」という各文字列（以下、「地名関連語文字列」という）に変換するコマンドを順次実行し、複数の地名関連語文字列を取得する。ただし、地名は複数存在するので、データ取得処理部３０３が生成する地名関連語文字列は、（全地名の数）×（各地名に対する関連語の数）通りとなる。
【００２９】
そして、各地名関連語文字列を非対話型ウェブクライアント３０２を介して、検索エンジン１０４に順次送信する。また、データ取得処理部３０３は、検索エンジン１０４から返信される検索結果を示す、検索結果ｈｔｍｌファイル及びウェブページのキャッシュファイルにそれぞれ所定の名称を付与し、検索結果ｈｔｍｌファイルディレクトリ及びキャッシュファイルディレクトリ３１１にそれぞれ記憶する。なお、検索結果ｈｔｍｌファイル及びウェブページのキャッシュファイルについての詳細は、図１０及び図１１に基づいて後述する。
【００３０】
また、データ取得処理部３０３は、地名関連語リスト、検索結果ｈｔｍｌファイルディレクトリに記憶された検索結果ｈｔｍｌファイル名及びキャッシュファイルディレクトリ３１１に記憶されたキャッシュファイル名をそれぞれ対応付けた、検索キー・ファイル名対応テーブル３１２を生成する。この検索キー・ファイル名対応テーブル３１２は、不揮発性データ記憶部２０４に記憶されるものであるが、その具体的な内容は、後述する図１３（ｂ）に示されるようなものである。
ここで、キャッシュファイルに住所文字列が含まれている場合は、データ取得処理部３０３が、非対話型ウェブクライアント３０２を介してその住所文字列を検索エンジン１０４に送信し、その住所に対応する位置情報（緯度・経度）を取得する。そして、これらの住所文字列及び位置情報を検索キー・ファイル名対応テーブル３１２の所定のフィールドにキャッシュファイル名と対応付けて追記する。
【００３１】
[ＷＡＭファイル生成処理部]
図５は、ＷＡＭファイル生成処理部３０４を中心とするブロック図である。
ＷＡＭファイル生成処理部３０４は、データ取得処理部３０３で生成され、キャッシュファイルディレクトリ３１１に記憶されたキャッシュファイル及び検索キー・ファイル名生成テーブル３１２を参照して、各関連語毎にＷＡＭファイル５０２を生成する。そして、生成された各ＷＡＭファイル５０２に所定の名称をそれぞれ付与し、ＷＡＭファイルディレクトリ３１３に記憶する。一つの関連語につき一つのＷＡＭファイル５０２が生成されるので、関連語の数だけＷＡＭファイル５０２が生成されることになる。
【００３２】
ここで、ＷＡＭファイル５０２とは、所定の関連語と、その関連語に対応するキャッシュファイル名と、キャッシュファイル内に含まれる関連語の前後にある名詞（以下、「周辺語」という）と、そのキャッシュファイルに含まれる、関連語及び周辺語の出現頻度とが対応付けられて書き込まれたファイルである。なお、ＷＡＭファイル５０２についての詳細な説明及びＷＡＭファイル５０２の具体的な生成方法については、図１４及び図１５に基づいて後述する。
【００３３】
また、ＷＡＭファイル生成処理部３０４は、データ取得処理部３０３で生成された検索キー・ファイル名対応テーブル３１２に、関連語のフィールドの各関連語に対応するようにＷＡＭファイル名を追記し、検索キー・ファイル名対応テーブル３１２を更新する。
【００３４】
[関連語出現テーブル生成処理］
図６は、関連語出現テーブル生成処理部３０５を中心とするブロック図である。
関連語出現テーブル生成処理部３０５は、ＷＡＭファイル生成処理部３０４で生成され、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２から関連語出現テーブル３１４を生成する処理を行う。この関連語出現テーブル生成処理部３０５の処理により、一つの地名に対応する複数の関連語毎の、全てのＷＡＭファイル５０２から一つの関連語出現テーブル３１４が生成される。
【００３５】
ここで、関連語出現テーブル３１４とは、一つの地名に対する複数の関連語が、各キャッシュファイル内に含まれるか否かの判定が書き込まれたテーブルである。この関連語出現テーブル３１４は、ＧＰＳ地名マスタ３０８に含まれる地名の数だけ生成されることになる。なお、関連語出現テーブル３１４についての詳細な説明及び関連語出現テーブル３１４の具体的な生成方法については、図１６及び図１７に基づいて後述する。
【００３６】
[ベストスコアテーブル生成処理部］
図７は、ベストスコアテーブル生成処理部３０６を中心とするブロック図である。
ベストスコアテーブル生成処理部３０６は、ＷＡＭファイル生成処理部３０４で生成され、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２、及び関連語出現テーブル生成処理部３０５で生成された関連語出現テーブル３１４に基づいて、仮ベストスコアテーブル３１５（一時ファイル）を不揮発性データ記憶部２０４に生成する。そして、仮ベストスコアテーブル３１５に対し所定の処理及び計算等行い、仮スコアテーブルを順次更新し、本ベストスコアテーブル３１６を生成し、不揮発性データ記憶部２０４に記憶する。本ベストスコアテーブル３１６は、ＧＰＳ地名マスタ３０８に含まれる地名の数だけ生成される。ここで、ベストスコアテーブルとは、所定の地名の関連語から、所定の関連語との類似度が最も高くなる他の関連語２語を選び、これら二つの関連語とその類似度を、各関連語毎に書き込んだテーブルのことである。なお、ベストスコアテーブルについての詳細な説明及びベストスコアテーブルの具体的な生成方法については、図１８〜図２１に基づいて詳細に説明する。
【００３７】
[本クラスタ生成処理部]
図８は、本クラスタ生成処理部３０７を中心として機能させた場合の機能ブロック図である。
本クラスタ生成処理部３０７は、ベストスコアテーブル生成処理部３０６で生成されたベストスコアテーブルから、仮クラスタ３１７（一時ファイル）を不揮発性データ記憶部２０４に生成する。そして、仮クラスタ３１７に対し、所定の処理及び計算を行い、仮クラスタ３１７を順次更新し、本クラスタ８０２を生成し、本クラスタディレクトリ３１８に記憶する。この本クラスタ８０２は、ベストスコアテーブルの数、すなわちＧＰＳ地名マスタ３０８に含まれる地名の数だけ生成される。
【００３８】
ここで、本クラスタ８０２とは、所定の地名の関連語全てをグループ分けし、そのグループに含まれる関連語について、類似度の合計の高い順に並べたテーブルである。なお、全ての関連語と記載したが、不必要な関連語に関連する項目は本クラスタ８０２には含まれていない。本クラスタ８０２についての詳細な説明及び本クラスタ８０２の具体的な生成方法については、図２２〜図３２に基づいて行われる。
【００３９】
[バッチ処理の動作説明]
次に、本実施形態の情報検索システム１０１におけるモバイル情報検索サーバ１０３のバッチ処理の流れを説明する。
図９は、モバイル情報検索サーバ１０３を中心とするバッチ処理の動作の流れを示すシーケンス図である。
まず、モバイル情報検索サーバ１０３（クライアント）は、予めＧＰＳ地名テーブルに記憶してある地名の文字列を検索エンジン１０４側へ送信する（ステップＳ９０１）。
【００４０】
検索エンジン１０４は、地名の文字列を受けて、その地名の関連語１００語をモバイル情報検索サーバ１０３に返信する（ステップＳ９０２）。
【００４１】
図１０（ａ）は、地名とその関連語の例を示す図である。
まず、関連語の詳細について図１０（ａ）を参照して説明する。
例えば不特定多数の人が、検索エンジン１０４による検索を行う際、「新宿」プラス「単語Ｘ」を検索クエリとして入力したとする。このとき「単語Ｘ」が「新宿」の関連語となる。本実施例では、このような「単語Ｘ」の中で、「新宿」という単語と最も多い頻度で組み合わせられた「単語Ｘ」のうち上位１００語を関連語とする。なお、検索クエリとは、ユーザが検索エンジンにからウェブページを訪問する際に検索エンジンから入力したキーワードのことである。
【００４２】
図１０（ａ）では、「ルミネ（登録商標）」が１番多い頻度で「新宿」と組み合わされた関連語１である。「イタリアン」及び「レストラン」は、２番目及び３番目多い頻度で「新宿」と組み合わされた関連語２及び関連語３である。ただし、「新宿」は地名の一例であるので、「新宿」以外の地名の関連語も存在する。
【００４３】
再び、図９の説明に戻る。
モバイル情報検索サーバ１０３は、関連語１００語を受信すると、前述の地名関連語文字列１００通りを検索エンジン１０４側に送信する（ステップＳ９０３）。
【００４４】
検索エンジン１０４は、１００通りの地名関連語文字列を受けて、各地名関連語文字列を検索クエリとして検索を実行する。そして、１００通りの地名関連語文字列毎の検索結果のｈｔｍｌファイルである図１０（ｂ）に示す検索結果ｈｔｍｌファイル１００３をモバイル情報検索サーバ１０３（クライアント）側へ送信する（ステップＳ９０４）。
【００４５】
モバイル情報検索サーバ１０３は、検索結果ｈｔｍｌファイル１００３を受信すると、各検索結果ｈｔｍｌファイル１００３毎にリンクが付与されている１０００件のキャッシュページのリンク先ＵＲＬ１００４を検索エンジン１０４に送信する（Ｓ９０５）。ここでは、クライアントが受信した検索結果ｈｔｍｌファイル１００３は１００通りなので、クライアントから検索エンジン１０４に送信されるキャッシュページのリンク先ＵＲＬ１００４は１００×１０００件となる。
【００４６】
検索エンジン１０４は、キャッシュページのリンク先ＵＲＬ１００４を受信すると、そのＵＲＬにアクセスして、図１１に示すキャッシュファイル１１０２を取得する。そして、検索エンジン１０４は、１つの検索結果ｈｔｍｌファイル１００３に付き、キャッシュファイル１１０２が取得できたものの中から１００件のキャッシュファイル１１０２をクライアント側へ送信する（Ｓ９０６）。ここでは、検索結果ｈｔｍｌファイル１００３は、１００通りなので、検索エンジン１０４からモバイル情報検索サーバ１０３側に送信されるキャッシュファイル１１０２は１００×１００件となる。
【００４７】
そして、モバイル情報検索サーバ１０３側のＧＰＳ地名マスタ３０８に書き込まれている地名文字列の数だけステップＳ９０１〜ステップＳ９０６の処理を繰り返す（ステップＳ９０７）。
【００４８】
ステップＳ９０７の処理が完了すると、モバイル情報検索サーバ１０３は、地名及び検索エンジン１０４から取得した、関連語、検索結果ｈｔｍｌファイル１００３及びキャッシュファイル１１０２に対し所定の内部処理を行い前述の本クラスタ８０２を生成する。
【００４９】
[バッチ処理メインフロー]
図１２は、本実施形態の情報検索システム１０１において、バッチ処理部２０２の動作を示すフローチャートである。
データ取得処理部３０３（図３を参照）は、ＧＰＳ地名マスタ３０８に含まれる地名の検索を開始する（ステップＳ１２０１）。
【００５０】
図１３（ａ）は、ＧＰＳ地名マスタ３０８を示す図である。ＧＰＳ地名マスタ３０８の詳細について図１３（ａ）を参照して説明する。前述したように、ＧＰＳ地名マスタ３０８は、予め不揮発性データ記憶部２０４に蓄積されている。このＧＰＳ地名マスタ３０８の「地名」フィールドには、例えば「新宿」等各地の地名文字列が書き込まれている。また、「緯度範囲」フィールドには、同一のレコードにある地名の緯度範囲が書き込まれている。例えば「新宿」の緯度範囲は、「（×，○）」となる。また、「経度範囲」フィールドには、同一のレコードにある地名の経度範囲が書き込まれている。例えば「新宿」の経度範囲は、「（△，■）」となる。
【００５１】
再び、図１２の説明に戻る。
これ以降はループ処理である。最初に、カウンタを構成する変数ｉを１に初期化する（ステップＳ１２０２）。データ取得処理部３０３は、非対話型ウェブクライアント３０２を介して、ＧＰＳ地名マスタ３０８のｉ番目のレコードの「地名」をインターネット１０６上の検索エンジン１０４に送信する。そして、送信した「地名」の関連語１００語の文字列（図１０（ａ）を参照）を検索エンジン１０４から取得する（ステップＳ１２０３）。そして、地名及びその１００語の関連語がフィールドセパレータで区切られた地名関連語リスト３０９を不揮発性データ記憶部２０４に記憶する。
【００５２】
次に、データ取得処理部３０３は、地名関連語リスト３０９に書き込まれた関連語１００語の文字列を「（地名）＋（スペース）＋（関連語１）」、「（地名）＋（スペース）＋（関連語２）」、…、「（地名）＋（スペース）＋（関連語１００）」に変換するコマンドを実行し、地名関連語文字列を１００件取得する。そして、非対話型ウェブクライアント３０２を介して、１００件の地名関連語文字列をインターネット１０６上の検索エンジン１０４に順次送信し、各地名関連語文字列を含むウェブページの検索結果ｈｔｍｌファイル１００３（図１０（ｂ）を参照）１００件を検索エンジン１０４から取得する（ステップＳ１２０４）。その後、各検索結果ｈｔｍｌファイル１００３毎に検索結果ｈｔｍｌファイル名を付与し、検索結果ディレクトリに記憶する。
【００５３】
次に、データ取得処理部３０３は、検索結果ディレクトリに記憶された各検索結果ｈｔｍｌファイル１００３毎に記載された１０００件のキャッシュページのリンク先ＵＲＬに、アクセスする。このアクセスは、非対話型ウェブクライアント３０２及び検索エンジン１０４を介して行われる。そして、各検索結果ｈｔｍｌファイル１００３につき１００件のキャッシュファイル１１０２（図１１を参照）を、キャッシュファイル１１０２を取得できるキャッシュページ１００件から取得する（ステップＳ１２０５）。そして、各キャッシュファイル１１０２毎にキャッシュファイル名を付与し、キャッシュファイルディレクトリ３１１に記憶する。
【００５４】
ここで、データ取得処理部３０３は、キャッシュファイル１１０２内に住所文字列が含まれているか否かを判定する。住所文字列が含まれているならば、この住所文字列を非対話型ウェブクライアント３０２を介して、インターネット１０６上の検索エンジン１０４へ送信する。そして、住所に応じた位置情報（緯度、経度）を検索エンジン１０４から受信する。
【００５５】
そして、データ取得処理部３０３は、各地名と、各検索結果ｈｔｍｌファイル名と、各キャッシュファイル名と、各住所と、各位置情報（緯度、経度）とが対応付けられた検索キー・ファイル名対応テーブル３１２（図１３（ｂ）を参照）を生成し、不揮発性データ記憶部２０４に記憶する。ただし、住所文字列を含まないキャッシュファイル１１０２と同一レコードにある住所フィールド及び位置情報（緯度、経度）フィールドについては、空のままにしておく。また、検索キー・ファイル名対応テーブル３１２のＷＡＭファイル名のフィールドについては、後述する。
【００５６】
次に、ＷＡＭファイル生成処理部３０４は、キャッシュファイルディレクトリ３１１に記憶されたキャッシュファイル１１０２及び検索キー・ファイル名対応テーブル３１２に書き込まれている情報に基づいて各関連語毎にＷＡＭファイル５０２を生成する（ステップＳ１２０６）。そして、各ＷＡＭファイル５０２に名称を付与し、ＷＡＭファイルディレクトリ３１３に記憶する。それと同時に、関連語とＷＡＭファイル５０２が対応するように、各ＷＡＭファイル５０２の名称を検索キー・ファイル名対応テーブル３１２のＷＡＭファイル名のフィールドに書き込み、検索キー・ファイル名対応テーブル３１２を更新する。このステップＳ１２０６のＷＡＭファイル生成処理の詳細は、図１４に基づいて後述する。
【００５７】
次に、関連語出現テーブル生成処理部３０５は、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２に基づいて、関連語出現テーブル３１４を生成し（ステップＳ１２０７）、不揮発性データ記憶部２０４に記憶する。なお、このステップＳ１２０７の関連語出現テーブル生成処理については、図１６に後述する。
【００５８】
次に、ＷＡＭファイルディレクトリ３１３に記憶されたＷＡＭファイル５０２及び関連語出現テーブル生成処理部３０５で生成された関連語出現テーブル３１４に書き込まれている情報に基づいて、ベストスコアテーブルが生成され（ステップＳ１２０８）、不揮発性データ記憶部２０４に記憶する。
ステップＳ１２０８のベストスコアテーブル生成処理については、図１８に後述する。
【００５９】
次に、ベストスコアテーブル生成処理部３０６で生成され、ベストスコアテーブルに書き込まれている情報に基づいて、本クラスタ８０２を生成する（ステップＳ１２０９）。そして、ステップＳ１２０９で生成された本クラスタ８０２が、本クラスタディレクトリ３１８に記憶される。このステップＳ１２０９の本クラスタ生成処理の詳細については、図２２に後述する。
【００６０】
以上の処理完了後、カウンタを構成する変数ｉをインクリメントする（ステップＳ１２１０）。
そして、変数ｉがＧＰＳ地名マスタ３０８の最大レコード数を超えたか否かを確認し（ステップＳ１２１１）、超えていなければ再び繰り返す（ステップＳ１２１１のＮ）。超えていれば（ステップＳ１２１１のＹ）、処理を終了する（ステップＳ１２１２）。
【００６１】
[ＷＡＭファイル生成処理フロー]
図１４は、図１２のステップＳ１２０６のＷＡＭファイル生成処理の詳細な処理の流れを示すフローチャートである。
【００６２】
図１２のステップＳ１２０６で、ＷＡＭファイル生成処理部３０４がＷＡＭファイル生成処理を開始すると（ステップＳ１４０１）、まず、現在対象としている地名で検索キー・ファイル名対応テーブル３１２（図１３（ｂ）を参照）を絞り込む（ステップＳ１４０２）。
【００６３】
以降はループ処理である。最初に、カウンタを構成する変数ｊを１に初期化する（ステップＳ１４０３）。次に、検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの検索結果ＨＴＭＬファイル名を一時変数fnameに代入する（ステップＳ１４０４）。そして、この一時変数fnameからＷＡＭファイル名を生成する（ステップＳ１４０５）。
【００６４】
続いて、ＷＡＭファイ生成処理部３０４（図３参照）は、地名で絞り込まれた検索キー・ファイル名対応テーブル３１２のｊ番目のレコードのキャッシュ名でキャッシュファイルディレクトリ３１１を検索する。そして、検索したキャッシュファイル１１０２をプレーンテキストに変換する（ステップＳ１４０６）。
【００６５】
次に、ＷＡＭファイル生成処理部３０４が、プレーンテキストに対し形態素解析を行い、プレーンテキストの形態素から名詞のみを抽出する。そして、抽出した名詞の形態素のテキスト（以下、「形態素テキスト」という）を生成する（ステップＳ１４０７）。
ここで、プレーンテキストに対して行われる形態素解析とは、対象言語の文法の知識（文法のルールの集まり）や辞書（品詞等の情報付きの単語リスト）を情報源として用い、自然言語で書かれた文書を形態素（言語で意味を持つ最小単位）の列に分割し、それぞれの品詞を判別する作業のことである。
【００６６】
次に、ＷＡＭファイル生成処理部３０４は、形態素テキストを検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの関連語で検索し、関連語及びその周辺語を抽出する。そして、ステップＳ１４０４の処理にて生成された名称のＷＡＭファイル５０２へ出力する（ステップＳ１４０８）。
このステップＳ１４０８の処理の際には、検索キー・ファイル名対応テーブル３１２のｊ番目のレコードのキャッシュファイル名と、形態素テキストにおける関連語と各周辺語の出現頻度とが、同時にステップＳ１４０４にて生成された名称のＷＡＭファイル５０２へ出力される。なお、本実施形態例では、周辺語の定義を、形態素テキスト内で関連語に一致する形態素の前後に２語ずつある、合計４語の形態素としている。
【００６７】
以上の処理完了後、カウンタを構成する変数ｊをインクリメントする（ステップＳ１４０９）。
そして、検索キー・ファイル名対応テーブル３１２に、インクリメントしたｊ番目のレコードが存在するか否かを確認する（ステップＳ１４１０）。そして、インクリメントしたｊ番目のレコードが存在する場合は（ステップＳ１４１０のＮ）、続いて、fnameと、検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの検索結果ｈｔｍｌファイル名が一致するか否かを確認する（ステップＳ１４１１）。
そして、両者が一致すると判定された場合は（ステップＳ１４１１のＹ）、ステップＳ１４０６の処理に戻り、再びステップＳ１４０６以降の処理を繰り返す。検索キー・ファイル名対応テーブル３１２のｊ番目のレコードの検索結果ｈｔｍｌファイル名がfnameと一致しない場合は（ステップＳ１４１１のＮ）、ステップＳ１４０３の処理に戻り、それ以降の処理を再び繰り返す。
【００６８】
一方、ステップＳ１４１０において、検索キー・ファイル名対応テーブル３１２のｉ番目のレコードが存在しないと判定された場合は（ステップＳ１４１０のＹ）、処理を終了する（ステップＳ１４１２）。
【００６９】
図１５は、ＷＡＭファイル生成処理によって生成されるＷＡＭファイル５０２の例を示す図である。
ＷＡＭファイル５０２は、検索結果ｈｔｍｌファイル名が「shinjyuku_001」、すなわちＷＡＭファイル名が「shinjyuku_001.wam」（図１４のステップＳ１４０４の処理を参照）で、関連語が「新宿二丁目」（図１３（ｂ）を参照）のＷＡＭファイルである。ＷＡＭファイル５０２を例に、ＷＡＭファイルの構造について説明する。
【００７０】
ＷＡＭファイル５０２の括弧部分１５０２は、図１４のステップＳ１４０５の処理〜ステップＳ１４０７の処理（一回目）で生成される箇所に相当する。この括弧部分１５０２に注目すると、一行目には、図１３(ｂ)に示す検索キー・ファイル名対応テーブル３１２の１番目のレコードのキャッシュファイル名である「shinjyuku_001_001」が書かれている。また、２行目以降には、関連語である「新宿二丁目」と、その周辺語である「東京」、「都」、「写真」、「街」、「開催」、「バー」及び「こんど」と、が記載されている。関連語及び各周辺語の左には、キャッシュファイル１１０２「shinjyuku_001_001」の形態素テキストに出現する関連語及び各周辺語の出現頻度が書かれている。なお、ＷＡＭファイル５０２において、キャッシュファイル名「shinjyuku_001_002」、「shinjyuku_001_003」、…、「shinjyuku_001_100」に相当する箇所は、ステップＳ１４０５〜ステップＳ１４０７の処理（二回目、三回目、…、百回目）にて書き込まれる。なお、上述したように、ＷＡＭファイル５０２は、一つの地名につき、その関連語の数だけ生成される。
【００７１】
[関連語出現テーブル生成処理フロー]
図１６は、図１２のステップＳ１２０７の関連語出現テーブル生成処理の詳細な処理の流れを示すフローチャートである。
【００７２】
図１２のステップＳ１２０７で説明したように、関連語出現テーブル生成処理部３０５が関連語出現テーブル３１４生成処理を開始すると（ステップＳ１６０１）、まず、現在対象としている地名に対応する全てのＷＡＭファイル５０２（図１３（ｂ）を参照）から図１７（ａ）に示す全フィールドが“０”の関連語出現テーブル３１４を作成する（ステップＳ１６０２）。
ここで、図１７（ａ）に示す関連語出現テーブル３１４の関連語のレコードの「term（1）」、「term（2）」、「term（3）」、…、「term（100）」は、ステップＳ１６０２の処理で対象とした各ＷＡＭファイル５０２に対応する関連語に相当する。また、関連語出現テーブル３１４のキャッシュファイル名のフィールドの「shinjyuku_001_001」、「shinjyuku_001_002」、…、「shinjyuku_100_100」は、ステップＳ１６０２の処理で対象とした全てのＷＡＭファイル５０２に書かれているキャッシュファイル名に相当する。
【００７３】
再び、図１６の説明に戻る。
これ以降はループ処理である。最初に、カウンタを構成する変数ｋ，ｌ，ｍを１に初期化する（ステップＳ１６０３、ステップＳ１６０４及びステップＳ１６０５）。そして、ｌ番目のＷＡＭファイル５０２（図１５を参照）のｍ行目がキャッシュファイル名であるか否かを確認する（ステップＳ１６０６）。キャッシュ名であるならば（Ｓ１６０６のＹ）、そのキャッシュ名に対応する関連語出現テーブル３１４のレコードに移動する（ステップＳ１６０７）。
【００７４】
キャッシュ名でないならば（ステップＳ１６０６のＮ）、ｌ番目のＷＡＭファイル５０２のｍ行目の単語が関連語出現テーブル３１４のｋ番目のフィールドに対応する関連語と一致するか否かを確認する（ステップＳ１６０８）。両者が一致すると判定された場合は（ステップＳ１６０８のＹ）、ステップＳ１６０７の処理で移動した、関連語出現テーブル３１４のレコードのｋ番目のフィールドに“１”を書き込む（ステップＳ１６０９）。
【００７５】
以上の処理完了後、カウンタを構成する変数ｍをインクリメントする（ステップＳ１６１０）。
続いて、ｌ番目のＷＡＭファイル５０２において、インクリメントしたｍ行目が存在するか否かを確認する（ステップＳ１６１１）。ｌ番目のＷＡＭファイル５０２のｍ行目が、まだ存在すると判定された場合は（ステップＳ１６１１のＮ）、ステップＳ１６０６の処理に戻り、それ以降の処理を繰り返す。ステップＳ１６１１の処理でｌ番目のＷＡＭファイル５０２のｍ行目が存在しないと判定された場合は（ステップＳ１６１１のＹ）、カウンタを構成する変数ｌをインクリメントする（ステップＳ１６１２）。
【００７６】
以上の処理完了後、続いて、インクリメントされたｌ番目のＷＡＭファイル５０２が存在するか否かを確認する（ステップＳ１６１３）。ｌ番目のＷＡＭファイル５０２が、まだ存在すると判定された場合は（ステップＳ１６１３のＮ）、ステップＳ１６０５の処理に戻り、それ以降の処理を繰り返す。ｌ番目のＷＡＭファイル５０２が存在しないと判定されると（ステップＳ１６１３のＹ）、カウンタを構成する変数ｋをインクリメントする（ステップＳ１６１４）。
【００７７】
次に、関連語出現テーブル３１４のｋ番目のフィールドが存在するか否かを確認する（ステップＳ１６１５）。そして、インクリメントされたｋ番目のフィールドが関連語出現テーブル３１４に存在すると判定された場合は（ステップＳ１６１５のＮ）、ステップＳ１６０４の処理に戻り、以降の処理を繰り返す。関連語出現テーブル３１４にｋ番目のフィールドが存在しないと判定された場合は（ステップＳ１６１５のＹ）、関連語出現テーブル３１４の全フィールドが“０”のレコードを削除し（ステップＳ１６１６）、処理を終了する（ステップＳ１６１７）。
【００７８】
図１７は、関連語出現テーブルの例を示す図である。
図１７（ａ）は、初期状態の関連語出現テーブルである。この関連語出現テーブルは、図１６のステップＳ１６０２の処理で生成されるものであり、その全フィールドには“０”が書き込まれている。
【００７９】
図１７（ｂ）は、不要レコード削除前の関連語出現テーブルを示す図である。この関連語出現テーブルは、図１６のステップＳ１６１５において、インクリメントされたｋ番目のレコードがないとき（ステップＳ１６１５のＹ）に生成されるテーブルであり、テーブルの各フィールドには、“０”或いは“１”が書き込まれている。
また、図１７（ｂ）に示す関連語出現テーブルには、キャッシュファイル名の形態素テキストに関連語が含まれる場合は“１”が、含まれない場合は“０”が書き込まれている。例えば、キャッシュファイル名「shinjyuku_001_001」の形態素テキストには、関連語「tem1(1)」が含まれていない。そのため、関連語出現テーブル３１４の「shinjyuku_001_001」のレコードの「temp(1)」のフィールドには、“０”が書き込まれている。また、キャッシュファイル名「shinjyuku_100_001」の形態素テキストには、関連語「tem1(3)」が含まれている。そのため、関連語出現テーブル３１４の「shinjyuku_100_001」のレコードの「temp(3)」のフィールドには、“１”が書き込まれている。
【００８０】
図１７（ｃ）は、不要レコード削除後の関連語出現テーブルを示す図である。
この関連語出現テーブル３１４は、図１６に示すステップＳ１６１６の処理により、図１７（ｂ）に示す関連語出現テーブル３１４から全フィールドが“０”のレコードが削除されたものである。例えば、図１７（ｂ）に示す関連語出現テーブル３１４の「shinjyuku_001_001」のレコードに注目すると、「term(1)」〜「term(100)」までのすべてのフィールドが“０”となっている。このような、レコードがステップＳ１６１６の処理にて削除されることにより、図１７（ｃ）の関連語出現テーブル３１４が生成される。
【００８１】
[ベストスコアテーブル生成処理フロー]
図１８及び図１９は、図１２のステップＳ１２０８のベストスコアテーブル生成処理の詳細な処理の流れを示すフローチャートである。
【００８２】
図１２のステップＳ１２０８で、ベストスコアテーブル生成処理部３０６がベストスコアテーブル生成処理を開始すると（ステップＳ１８０１）、それ以降はループ処理となる。
最初に、カウンタを構成する変数ｎ，ｐを１に初期化する（ステップＳ１８０２及びステップＳ１８０３）。次に、ｎとｐとが等しいか否かを確認する（ステップＳ１８０４）。ｎとｐが等しくない場合には（ステップＳ１８０４のＹ）、不揮発性データ記憶部２０４に記憶された関連語出現テーブル３１４（図１７（ｃ）を参照）のｎ番目のフィールドに対応する関連語を配列変数term_xに、ｐ番目のフィールドの関連語を配列変数term_yに追記する（ステップＳ１８０５）。
【００８３】
次に、関連語出現テーブル３１４のｎ番目のterm(n)とｐ番目のterm(ｐ)のいずれかに“１”が立っているレコード数を、配列変数ornumに追記する（ステップＳ１８０６、図２０参照）。そして、関連語出現テーブル３１４のｎ番目のterm(n)とｐ番目のterm(ｐ)の両方に“１”が立っているレコード数を、配列変数andnumに追記する（ステップＳ１８０７、図２０参照）。
【００８４】
そして、ステップＳ１８０７の処理の最後に、図２０に示すandnumとornumへ追記された各値に基づいて、term_xとterm_yに最後に追記された関連語間の類似度を計算し、この類似度を、配列変数scoreに追記する（ステップＳ１８０８）。ここで、類似度とは、相異なる２つの単語間にある関連性の強さを数値で表したものである。別の言い方をすると、これらの２つの単語の共起関係を数値で示したものである。なお、類似度の計算式を以下に示す。
【００８５】
〔数１〕
score=(andnum/ornum)*log(andnum)
【００８６】
以上の処理完了後、カウンタを構成する変数ｐをインクリメントする（ステップＳ１８０９）。
そして、関連語出現テーブル３１４のｐ番目のフィールドが存在するか否かを確認する（ステップＳ１８１０）。ｐ番目のフィールドが存在する場合は（ステップＳ１８１０のＮ）、ステップＳ１８０４の処理に戻り、それ以降の処理を繰り返す。ｐ番目のフィールドが存在しないと判定された場合は（ステップＳ１８１０のＹ）、続いて、カウンタを構成する変数ｎをインクリメントする（Ｓ１８１１）。
【００８７】
次に、関連語出現テーブル３１４のｎ番目のフィールドが存在するか否かを確認する（ステップＳ１８１２）。ｎ番目のフィールドが存在する場合は（ステップＳ１８１２のＮ）、ステップＳ１８０３の処理に戻り、以降の処理を繰り返す。
【００８８】
以上の処理完了後、ステップＳ１８１２で、関連語出現テーブル３１４のｎ番目のフィールドが存在しないと判定された場合は（ステップＳ１８１２のＹ）、図１９の処理に移行する（○囲みＡ）。そして、上述したscore、andnum、ornum、term_x及びterm_yの各配列から、図２０（ａ）に示すソート前仮ベストスコアテーブル２００２を生成する（ステップＳ１９０１）。
【００８９】
そして、図２０（ａ）に示したソート前仮ベストスコアテーブル２００２のterm_xが一致するレコードの中で、score（類似度）の大きさが上位２に含まれるレコードのみ残して他のレコードは削除し、図２０（ｂ）に示すソート済仮ベストスコアテーブル２００３を生成する（ステップＳ１９０２）。このソート済仮ベストスコアテーブル２００３が、図３で示した仮ベストスコアテーブル３１５に相当する。以下、このソート済仮ベストスコアテーブル２００３を、仮ベストスコアテーブル３１５と呼ぶ。
【００９０】
これ以降はループ処理である。最初、カウンタを構成する変数ｑを初期化する（ステップＳ１９０３）。ここで、仮ベストスコアテーブル３１５のｑ番目と（ｑ＋１）番目の２レコード２１０２（図２１（ａ）を参照）より、ソート前本ベストスコアテーブル３１６の（ｑ＋１）／２番目の１レコード２１０３（図２１（ｂ）を参照）を生成する（ステップＳ１９０４）。すなわち、２レコードを１レコードに変換する処理を行う。具体的には、仮ベストスコアテーブル３１５のｑ番目のレコードのscore及びterm_yを、score_1及びterm_1にそれぞれ書き込み、（ｑ＋１）番目のレコードのscore及びterm_yはscore_2及びterm_2にそれぞれ書き込む。
【００９１】
また、仮ベストスコアテーブル３１５のｑ番目及び（ｑ＋１）番目のレコードのterm_xは等しいので、term_xをtermに書き込む。なお、ソート前本ベストスコアテーブル３１６のtotalのレコードに書き込まれる値については、後述する。
【００９２】
ステップＳ１９０４の処理完了後、ソート前本ベストスコアテーブル３１６の（ｑ＋１）／２番目のレコードのscore_1とscore_2の和を当該レコードのtotalに書き込む。
【００９３】
以上の処理完了後、カウンタを構成する変数ｑを２インクリメントする（ステップＳ１９０６）。そして、仮ベストスコアテーブル３１５のｑ番目のレコードが存在するか否かを確認する（ステップＳ１９０７）。
【００９４】
仮ベストスコアテーブル３１５にインクリメントされたｑ番目のレコードが存在する場合は（ステップＳ１９０７のＮ）、ステップ１９０４の処理に戻り、それ以降の処理を繰り返す。一方、仮ベストスコアテーブル３１５にｑ番目のレコードが存在しないと判定された場合は（ステップＳ１９０７のＹ）、図２１（ｃ）に示すように、ソート前本ベストスコアテーブル３１６の各レコードのtotalの値の大きい順に、当該各レコードを並び替える（ステップＳ１９０８）。そして、処理を終了する（ステップＳ１９０９）。なお、このステップＳ１９０８の処理によってソートされたソート前本ベストスコアテーブル３１６が、図３に示した本ベストスコアテーブル３１６に相当するものである。
【００９５】
[本クラスタ生成処理フロー]
図２２は、図１２のステップＳ１２０６の処理である、本クラスタ生成処理の詳細な処理の流れを示すフローチャートである。
【００９６】
まず、本クラスタ生成処理部３０７が本クラスタ８０２生成処理を開始する（ステップＳ２２０１）。これ以降はループ処理である。
最初に、カウンタを構成する変数ｒを１に初期化する（ステップＳ２２０２）。そして、不揮発性データ記憶部２０４に記憶された本ベストスコアテーブル３１６（図２１（ｃ）を参照）のｒ番目のレコードから仮クラスタ３１７のcid=ｒ,tid=1のレコード（図２３（ａ）を参照）を生成する（ステップＳ２２０３）。具体的には、本ベストスコアテーブル３１６のｒ番目のレコードの「total」、「term」、「score_1」、「term_1」、「score_2」及び「term_2」を仮クラスタ３１７のcid=ｒ,tid=1のレコードの「total」、「term」、「score_1」、「term_1」、「score_2」及び「term_2」にそれぞれ書き込む。
【００９７】
次に、ステップＳ２２０３の処理完了後、本ベストスコアテーブル３１６から仮クラスタ３１７のcid=ｒ,tid=2のレコード（図２３（ｂ）を参照）を生成する（ステップＳ２２０４）。具体的には、まず本ベストスコアテーブル３１６のｒ番目のレコードの「term_1」を仮クラスタ３１７のcid=ｒ,tid=2のレコードの「term」に書き込む。そして、その「term」で本ベストスコアテーブル３１６のtermフィールドを検索し、該当するレコードの「total」、「score_1」、「term_1」、「score_2」及び「term_2」を仮クラスタ３１７のcid=ｒ,tid=2のレコードの「total」、「score_1」、「term_1」、「score_2」にそれぞれ書き込む。
【００９８】
ステップＳ２２０４の処理完了後、本ベストスコアテーブル３１６から仮クラスタ３１７のcid=ｒ,tid=3のレコードを生成する（ステップＳ２２０５）。具体的には、まず本ベストスコアテーブル３１６のｒ番目のレコードの「term_2」を仮クラスタ３１７のcid=ｒ,tid=3のレコードの「term」に書き込む。そして、その「term」で本ベストスコアテーブル３１６のtermフィールドを検索し、該当するレコードの「total」、「score_1」、「term_1」、「score_2」及び「term_2」を仮クラスタ３１７のcid=ｒ,tid=3のレコードの「total」、「score_1」、「term_1」、「score_2」にそれぞれ書き込む。
【００９９】
そして、ステップＳ２２０５の処理完了後、仮クラスタ３１７のcid=ｒ,tid=1,2,3のレコードの各「term」の文字列長を当該レコードの「len」にそれぞれ書き込む（ステップＳ２２０６）。なお、以上の処理１回により生成される仮クラスタ３１７を図２３（ｃ）に示す。
【０１００】
ここで、図２３の仮クラスタ３１７の「cid」及び「tid」のフィールドについて説明する。
「cid」とは、クラスタ番号であり、「term」、つまり関連語を所定のクラスタに分類するための番号のことである。このクラスタとは、類似した特性を持つ複数の関連語の集合のことを言う。つまり、同一のクラスタ番号が付されている各関連語は、類似した特性を有している。また、クラスタ番号が小さいほど、分類された関連語と地名の関連性（共起関係）が強いということを意味する。また、「tid」とは、ターム番号であり、同一クラスタ番号の各レコード内での「term」の順位付けを行うための番号である。すなわち、仮クラスタとは、「cid」、「tid」の優先順位で各レコードが並んでいるテーブルである。
【０１０１】
なお、仮クラスタ３１７の「cnt」、「valid」、「alt」及び「stop」の各フィールドについての詳細は、図２６，図２８，図３０及び図３１にて後述する。
【０１０２】
再び、図２２の説明に戻り、本クラスタ生成処理について説明する。
以上の処理完了後、カウンタを構成する変数ｒをインクリメントする（ステップＳ２２０７）。続いて、このインクリメントされたｒ番目のレコードが本ベストスコアテーブル３１６に存在するか否かを確認する（ステップＳ２２０８）。そして、ｒ番目のレコードが存在する場合は（ステップ２２０８のＮ）、ステップＳ２２０３の処理に戻る。そして、本ベストスコアテーブル３１６のレコードの数に応じた回数の処理を繰り返し、図２４に示す仮クラスタ３１７を生成する。
【０１０３】
インクリメントされたｒ番目のレコードが本ベストスコアテーブル３１６に存在しない場合、つまり、仮クラスタ３１７の生成が完了した場合は（ステップＳ２２０８のＹ）、仮クラスタ３１７の「cnt」のフィールドに所定の値を書き込むｃｎｔ付与処理を行う（ステップＳ２２０９）。
【０１０４】
[ｃｎｔ付与処理フロー]
図２５は、図２２のステップＳ２２０９のｃｎｔ付与処理の詳細な処理の流れを示すフローチャートである。
【０１０５】
本クラスタ生成処理部３０７がｃｎｔ付与処理を開始すると（ステップＳ２５０１）、図２５に示すループ処理が行われる。
最初に、カウンタを構成する変数ｓ１に初期化し、更に仮クラスタ３１７の全レコードの「ｃｎｔ」を０に初期化する（ステップＳ２５０２）。次に、カウンタを構成する変数ｔを１に初期化する（ステップＳ２５０３）。次に、図２４に示す仮クラスタ３１７のcid=s,tid=tのレコードの「term_1」が、cid=s,tid=1,2,3の各レコードの「term」にあるか否かを確認する（ステップＳ２５０４）。「term_1」がある場合には（ステップＳ２５０４のＹ）、仮クラスタ３１７のcid=s,tid=tのレコードの「cnt」に１を加算して書き込む（ステップＳ２５０５）。
【０１０６】
そして、仮クラスタ３１７のcid=s,tid=tのレコードの「term_2」が、cid=d,tid=1,2,3の各レコードの「term」にあるか否かを確認する（ステップＳ２５０６）。「term_2」がある場合には（ステップＳ２５０４のＹ）、仮クラスタ３１７のcid=s,tid=tのレコードの「cnt」に１を加算して書き込む（ステップＳ２５０７）。
【０１０７】
以上の処理完了後、カウンタを構成する変数ｔをインクリメントする。そして、変数ｔが３より大きいか否かを確認する（ステップＳ２５０９）。インクリメントされた変数ｔが３以下であれば（ステップＳ２５０９のＮ）、ステップＳ２５０４の処理に戻り、処理を繰り返す。変数ｔが３より大きい場合には（ステップＳ２５０９のＹ）、続いて、カウンタを構成する変数ｓをインクリメントする。
【０１０８】
そして、本ベストスコアテーブル３１６にインクリメントされたｓ番目のレコードが存在するか否かを確認する（ステップＳ２５１１）。ｓ番目のレコードが存在する場合は（ステップＳ２５１１のＮ）、ステップＳ２５０３の処理に戻り、処理を繰り返す。ｓ番目のレコードが存在しないならば（ステップＳ２５１１のＹ）、処理を終了する（ステップＳ２５１２）。
【０１０９】
図２６は、ｃｎｔ付与処理によりｃｎｔ値が書き込まれた状態の仮クラスタ３１７の例を示す図である。このｃｎｔ値について図２６を参照して説明する。仮クラスタ３１７の「cnt」のフィールドには、ｃｎｔ値として０，１又は２のいずれかの値が書き込まれている。
【０１１０】
仮クラスタ３１７のcid=1,tid=1のレコードに注目する。このレコードの「南口（term_1）」及び「西口（term_2）」の両方が、仮クラスタ３１７のcid=1,tid=1,2,3のいずれかのレコードの「term」に含まれている。このような場合、ｃｎｔ値は２となる。
【０１１１】
また、仮クラスタ３１７のcid=2,tid=2のレコードに注目する。このレコードの「西口（term_1）」及び「東口（term_2）」の片方、すなわち「西口（term_1）」しか仮クラスタ３１７のcid=2,tid=1,2,3の各レコードの「term」に含まれていない。このような場合、ｃｎｔ値は１となる。
【０１１２】
また、仮クラスタ３１７のcid=6,tid=3のレコードに注目する。このレコードの「野村ビル（term_1）」及び「住友ビル（term_2）」のいずれも、仮クラスタ３１７のcid=6,tid=1,2,3の各レコードの「term」に含まれていない。このような場合、ｃｎｔ値は０となる。
【０１１３】
すなわち、ｃｎｔ値とは、所定の関連語（term）が、同一クラスタ番号に属する他の２つの関連語（term）との関連性を示す値である。ｃｎｔ値“２”は関連性がすごくあるということを、ｃｎｔ値“１”は関連性があるということを、ｃｎｔ値“０”は関連がないということを、それぞれ示している。
【０１１４】
再び、図２２に戻り、本クラスタ生成処理について説明する。
以上、図２２のステップＳ２２０９のｃｎｔ付与処理について図２５、図２６に基づいて説明したが、このｃｎｔ付与処理が完了すると、図２６に示す仮クラスタ３１７の「valid」のフィールドに所定の値を書き込むｖａｌｉｄ付与処理が行われる（ステップＳ２２１０）。次に、このｖａｌｉｄ付与処理について、その詳細を説明する。
【０１１５】
[ｖａｌｉｄ付与処理フロー]
図２７は、図２２のステップＳ２２１０のｖａｌｉｄ付与処理の詳細な処理の流れを示すフローチャートである。
以下、図２６に示すｃｎｔが付与された仮クラスタ３１７の「valid」のフィールドを更新する際の本クラスタ生成部３０７の動作について説明する。なお、以下ではｃｎｔが付与された仮クラスタ３１７のことを、説明の便宜上、単に仮クラスタ３１７と記載する。
【０１１６】
本クラスタ生成処理部３０７がｖａｌｉｄ付与処理を開始すると（ステップＳ２７０１）、まず、仮クラスタ３１７の全レコードの「valid」を０に初期化する（ステップＳ２７０２）。
これ以降はループ処理となる。最初に、カウンタを構成する変数ａを１に初期化する（ステップＳ２７０３）。
【０１１７】
そして、仮クラスタ３１７のａ番目のレコードの「valid」が“０”であるか否かを確認する（ステップＳ２７０４）。ａ番目のレコードの「valid」が“０”である場合は（ステップＳ２７０４のＹ）、仮クラスタ３１７のａ番目のレコードの「term」を一時変数tmpstrに代入する（ステップＳ２７０５）。
【０１１８】
次に、term=tmpstr及びvalid=0で仮クラスタ３１７を絞り込む（ステップＳ２７０６）。そして、絞り込んだ仮クラスタ３１７の各レコードの「cid」の小さい順に、当該各レコードを並び替える（ステップＳ２７０７）。そして、この並び替えた各レコードの最上位レコードの「valid」に１を書き込み、その他のレコードの「valid」に−１を書き込む（ステップＳ２７０８）。
【０１１９】
以上の処理完了後、カウンタを構成する変数ａをインクリメントする（ステップＳ２７０９）。一方、ステップＳ２７０４の判断で、仮クラスタ３１７のａ番目のレコードの「valid」が０でないと判定された場合は（ステップＳ２７０４）、ステップＳ２７０５〜ステップＳ２７０８の処理をすることなく、ステップＳ２７０９の処理へ移行する。
【０１２０】
次に、インクリメントされたａ番目のレコードが仮クラスタ３１７の中に存在するか否かを確認する（ステップＳ２７１０）。ａ番目のレコードが存在する場合には（ステップＳ２７１０のＮ）、ステップＳ２７０３の処理へ戻り、処理を繰り返す。ａ番目のレコードが存在しないときは（ステップＳ２７１０のＹ）、処理を終了する。
【０１２１】
図２８は、図２７で説明したｖａｌｉｄ付与処理によりｖａｌｉｄ値が書き込まれた状態の仮クラスタ３１７の例を示す図である。ｃｎｔ値について図２８を参照して説明する。仮クラスタ３１７の「valid」のフィールドには、ｖａｌｉｄ値として−１又は１いずれかの値が書き込まれている。
【０１２２】
仮クラスタ３１７のcid=1,tid=3のレコードに注目する。このレコードの「西口（term）」は、当該レコードより上位にあるレコードに含まれていない。このような場合、ｖａｌｉｄ値は“１”となる。
【０１２３】
また、仮クラスタ３１７のcid=2,tid=1のレコードに注目する。このレコードの「西口（term）」は、当該レコードより上位にあるcid=1,tid=3のレコードの「西口（term）」と一致する。このような場合、ｖａｌｉｄ値は“−１”となる。
【０１２４】
ここで、ｖａｌｉｄ値とは、仮クラスタ３１７において、対象としているレコードの「term」が、当該レコードより上位にあるレコードの「term」と重複しているか否かを判断するための設定値である。つまり、重複がない場合は、“１”が記入され、重複が有る場合は“−１”が記入される。
【０１２５】
再び、図２２の本クラスタ生成処理の説明に戻る。
以上、図２２のステップＳ２２１０のｖａｌｉｄ付与処理について図２７、図２８に基づいて説明したが、このｖａｌｉｄ付与処理が完了すると、図２８に示す仮クラスタ３１７の「alt」のフィールドに所定の値を書き込むａｌｔ付与処理に移行する（ステップＳ２２１１）。
【０１２６】
[ａｌｔ付与処理フロー]
図２９は、図２２のステップＳ２２１１のａｌｔ付与処理の詳細な処理の流れを示すフローチャートである。
以下、図２８に示すｖａｌｉｄが付与された仮クラスタ３１７の「alt」のフィールドを更新する際の本クラスタ生成処理部３０７（図３を参照）の動作について説明する。なお、以下ではｖａｌｉｄが付与された仮クラスタ３１７のことを、説明の便宜上、単に仮クラスタ３１７と呼ぶことにする。
【０１２７】
まず、図３の本クラスタ生成処理部３０７がａｌｔ付与処理を開始する（ステップＳ２９０１）。そして、仮クラスタ３１７をvalid=1で絞り込む（ステップＳ２９０２）。
【０１２８】
最初に、カウンタを構成する変数ｂを２に初期化し（ステップＳ２９０３）、図２９に示したループ処理に移行する。そして、絞り込んだ仮クラスタ３１７の「cid」がｂと一致するレコードを全て検索し、それらのレコードを一時ファイルに書き出す（ステップＳ２９０４）。
【０１２９】
ここで、一時ファイルに書き出されたレコードの数を確認する（ステップＳ２９０５）。一時ファイルに書き出されたレコードが複数ある場合には（ステップＳ２９０５のＮ）、続いて、絞り込んだ仮クラスタ３１７の「cid」がｂの全レコードの「len」の合計が１６以下であるか否かを確認する（ステップＳ２９０６）。そして、「len」の合計が１６以下である場合は（ステップＳ２９０６のＹ）、カウンタを構成する変数ｃを１に初期化する（ステップＳ２９０７）。また、ステップＳ２９０５で、一時ファイルに書き出されたレコードの数が一つだけであると判定された場合も（ステップＳ２９０５のＹ）、ステップＳ２９０７の処理に移行する。
【０１３０】
次に、一時ファイルの「cid」がｂ、レコード番号がｃのレコードの「term_1」及び「term_2」で、絞り込んだ仮クラスタ３１７の当該レコードより上位にあるレコードの「term」を検索する（ステップＳ２９０８）。そして、検索がヒットしたか否かを確認する（ステップＳ２９０９）。なお、レコード番号とは、一時ファイルの各レコードに降順に割り当てられた番号のことである。
【０１３１】
また、ステップＳ２９０９で、仮クラスタ３１７の当該レコードより上位にあるレコードの「term」検索がヒットした場合は（ステップＳ２９０９のＹ）、ヒットしたレコードの「cid」を、絞り込んだ仮クラスタ３１７の所定のレコードの「alt」に書き込む（ステップ２９１０）。この検索でヒットしたレコードの「cid」がない場合は（ステップＳ２９０９のＮ）、絞り込んだ仮クラスタ３１７の所定のレコードの「alt」に“−１”を書き込む（ステップＳ２９１１）。ここで、所定のレコードとは、一時ファイルの「cid」がｂ、レコード番号がｃのレコードの「cid」及び「tid」と一致する、仮クラスタ３１７のレコードのことである。
【０１３２】
以上の処理完了後、カウンタを構成するレコード番号の変数ｃをインクリメントする（ステップＳ１９１２）。そして、一時ファイルの「cid」がｂで、レコード番号がインクリメントされたｃのレコードが存在するか否かを確認する（ステップＳ２９１３）。該当するレコードが存在する場合には（ステップＳ１９１３のＮ）、ステップＳ２９０８の処理に戻り、以降の処理を繰り返す。該当するレコードが存在しない場合は（ステップＳ１９１３のＹ）、カウンタを構成する、一時ファイルの「cid」である変数ｂをインクリメントする（ステップＳ２９１４）。また、ステップＳ２９０６で、絞り込んだ仮クラスタ３１７の「cid」である変数ｂの全レコードの「len」の合計が“１６”を超えるときも（ステップＳ２９０６のＮ）、ステップＳ２９１４の処理へ移行し、変数ｂをインクリメントする。
【０１３３】
次に、絞り込んだ仮クラスタ３１７の「cid」の中にインクリメントされた変数ｂのレコードが存在するか否かを確認する（ステップＳ１９１５）。そして、インクリメントされた変数ｂのレコードが存在する場合には（ステップＳ２９１５のＮ）、ステップＳ２９０４の処理へ戻る。インクリメントされた変数ｂのレコードが存在しない場合は（ステップＳ２９１５のＹ）、処理を終了する（ステップＳ２９１６）。
【０１３４】
なお、仮クラスタ３１７の「alt」のフィールドに“０”以外の値が設定される条件（以下、「ａｌｔ値設定条件」という）を以下にまとめる。具体的には、以下に示す条件（１）かつ（２）または条件（１）かつ（３）の場合に、仮クラスタ３１７の「alt」のフィールドに“０”以外の値が設定される。
（１）仮クラスタ３１７の「valid」が“１”である。
（２）ステップＳ２９０４の処理で書き出された一時ファイルの各レコードの「len」の合計が“１６”以下である。
（３）ステップＳ２９０４の処理で書き出された一時ファイルのレコードが一つである。
【０１３５】
図３０は、図２９で説明したａｌｔ付与処理によりａｌｔ値が書き込まれた状態の仮クラスタ３１７の例を示す図であるである。この図３０を参照して、ａｌｔ値について説明する。仮クラスタ３１７の「alt」のフィールドには、ｃｎｔ値として−１，０又はクラスタ番号（cid）のいずれかの値が書き込まれている。
【０１３６】
例えば、仮クラスタ３１７のcid=2,tid=3のレコードに注目する。このレコードは、前述のａｌｔ値設定条件を満たしていないレコードである。そのため当該レコードの「alt」には、０が書き込まれている。
【０１３７】
また、仮クラスタ３１７のcid=9,tid=1のレコードに注目する。このレコードは、前述のａｌｔ値設定条件を満たしているレコードである。さらに、当該レコードの「ビジネスホテル（term_1）」及び「ヒルトン（商標登録）（term_2）」の両方とも、これらのレコードより上位にある全てのレコードの各「term」と一致しない場合は、ａｌｔ値は“−１”となる。ここで、当該レコードより上位にあるレコードとは、仮クラスタ３１７テーブルの中で、cidが１〜８の各レコードのことである。
【０１３８】
また、仮クラスタ３１７のcid=61,tid=1のレコードに注目する。このレコードのクラスタ番号は“６１”でありcid=61且つvalid=1の全てのレコードの「len」の合計は１０であるから、前述のａｌｔ値設定条件を満たしているレコードである。さらに、このレコードより上位にあり、同一のｃｉｄ値を有するレコード（cid=17,tid=1,2）の各「term」が、当該レコードの「映画館（term_1）」及び「映画（term_2）」の両方と一致する。このような場合、ａｌｔ値は、一致した上位のレコードの「cid」である“１７”となる。
【０１３９】
以上、図２２のステップＳ２２１１のａｌｔ付与処理について図２９、図３０に基づいて説明した。再び、図２２の本クラスタ生成処理の説明に戻る。
ステップＳ２２１１のａｌｔ付与処理が完了すると、図３０に示す仮クラスタ３１７の全レコードを検索して、ストップワードのフラグを立てる（ステップＳ２２１２）。具体的には、仮クラスタ３１７の各レコードの「term」が予め設計者の設定したストップワードに一致する場合、当該レコードの「stop」に１を書き込む。なお、ストップワードのフラグが立てられた仮クラスタ３１７の例を図３１に示す。
【０１４０】
そして、図３１に示す仮クラスタ３１７の不要なレコードを削除する（ステップＳ２２１３）。このステップＳ２２１３で削除される不要なレコードの条件は以下の通りである。
（１）「valid」のフィールドが−１のレコード
（２）「stop」のフィールドが１のレコード
（３）「cnt」のフィールドが０のレコード
【０１４１】
ここで、不要なレコードを削除した仮クラスタ３１７の「alt」が“１”以上の値が設定されているレコードを検索し、そのレコードの「cid」と「alt」を入れ替える。そして、不要なレコードを削除した仮クラスタ３１７の中で、各レコードの「cid」の小さい順に、当該各レコードを並び替え（ステップＳ２２１４）、処理を終了する（ステップＳ２２１５）。
【０１４２】
ステップＳ２２１４の処理によって並び替えられた仮クラスタ３１７は、図３で説明した本クラスタ８０２に該当する。本クラスタ８０２の例を図３２及び図３３に示す。
以上で、図２２に基づいたモバイル情報検索サーバ１０３のバッチ処理部２０２の説明を終了する。
【０１４３】
[リアルタイム処理部］
次に、図２のリアルタイム処理部２０３について説明する。
図３４は、リアルタイム処理部２０３及びデータ記憶部の一部の機能的な構成を示すブロック図である。
リアルタイム処理部２０３は、概略的にはＨＴＴＰを用いて、図１に示す携帯電話１０２にｈｔｍｌ文書を送信する、ｗｅｂサーバの機能を有している。この機能は、携帯電話１０２のｗｅｂブラウザプログラム１１３からの要求に応じて行われるものである。
【０１４４】
リアルタイム処理部２０３は、一般的なネットワークＯＳが稼働するコンピュータである。ネットワークＯＳは、一例として、ＦｒｅｅＢＳＤ等のＢＳＤ系、或いはＬｉｎｕｘ（登録商標）等のＰＯＳＩＸ（Portable Operating System Interface for UNIX）（ＵＮＩＸは登録商標）系ＯＳ等が挙げられる。
【０１４５】
以下、図３４に示す機能ブロック図に基づいて、リアルタイム処理部２０３の構成について説明する。
リアルタイム処理部２０３は、上述したように、ｗｅｂサーバ機能を持つｗｅｂサーバプログラム３４０２を備えている。このｗｅｂサーバプログラム３４０２は、携帯電話１０２から来る要求（コマンド）を受信し、これに応じて、ＨＴＴＰにてｈｔｍｌ文書をクライアントへ送信する機能を提供する。端的に言えば、ｗｅｂサーバソフトウェアであり、一例としてはＡｐａｃｈｅ（http://www.apache.org/）等が、これに該当する。
【０１４６】
また、ｗｅｂサーバプログラム３４０２は、携帯電話１０２の要求に応じ、ｃｇｉ（Common Gateway Interface）の実行も行う。ｃｇｉの実体は、標準出力にテキストを出力するプログラムである。このｃｇｉが生成するテキストが、ｗｅｂサーバプログラムによってＨＴＴＰにて携帯電話１０２へ送信される。図３４では、第１のｃｇｉ３４０３の他、第２のｃｇｉ３４０７〜第４のｃｇｉ３４０９まで用意されている。
【０１４７】
これらのｃｇｉを構成する要素としては、どのようなプログラミング言語であってもよい。ｐｅｒｌ（http://www.perl.org/）やＰＨＰ（http://php.net/）、ｐｙｔｈｏｎ（http://www.python.org/ja/）、ｒｕｂｙ（http://www.ruby-lang.org/ja/）等のインタプリタ言語のみならず、Ｃ言語やＪａｖａ（登録商標）等のコンパイルを要する言語であってもよい。簡単な内容であれば、シェルスクリプトであってもよい。
【０１４８】
各々のｃｇｉは、主にｗｅｂブラウザに表示する画面を作るためのｈｔｍｌ文書を作成する。つまり、ｈｔｍｌ文書はｗｅｂブラウザを通じてＧＵＩを作成する手段である。
なお、図３４では、上述のように、携帯電話の表示部に表示させる画面ごとに４つのｃｇｉが個別に設けられているが、単一のｃｇｉで構成することも可能である。ただし、その場合は、単一のｃｇｉの中に複数の表示画面を作成する機能が含まれることとなる。
【０１４９】
第一のｃｇｉ３４０３は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行される。
第一のｃｇｉ３４０３は、携帯電話１０２から得られたパラメータであるユーザの現在位置情報で不揮発性データ記憶部２０４に記憶されているＧＰＳ地名マスタ３０８を検索する。そして、ＧＰＳ地名マスタ３０８から現在位置情報に応じた地名を取得する。また、第一のｃｇｉ３４０３は、取得した地名をキーとして、本クラスタディレクトリ３１８を検索し、入力した地名と対応する本クラスタ８０２を取得する。
【０１５０】
そして、この取得した本クラスタ８０２を表示用本クラスタ３４０４に変換し、不揮発性データ記憶部に表示用一時ファイル３４０４として記憶する。なお、表示用本クラスタ３４０４とは、本クラスタ８０２から所定のレコードを削除したものである。この表示用本クラスタ３４０４の詳細については図３８及び図３９にて後述する。
【０１５１】
また、本クラスタ８０２から表示用本クラスタ３４０４に変換する際には、第一のｃｇｉ３４０３は、携帯電話１０２の表示部の大きさ、フォントの大きさ及びフォントの種類を考慮した表示用本クラスタ３４０４を生成するようにする。この表示用本クラスタ３４０４の生成は、予め不揮発性データ記憶部２０４に記憶された携帯端末マスタ３４０５及びリアルタイム処理部２０３に存在しているプロポーショナルフォントファイル３４０６を参照しながら第一のｃｇｉ３４０３によって行われる。
【０１５２】
携帯端末マスタ３４０５には、様々な携帯電話の画面（表示部）の大きさを示す情報が記憶されている。また、プロポーショナルフォントファイル３４０６には、携帯電話１０２がプロポーショナルフォントでの画面表示を要求してきた際に、そのフォント幅に対応した表示用本クラスタ３４０４を生成するための情報が記憶されている。
【０１５３】
第一のｃｇｉ３４０３は、この表示用本クラスタ３４０４（表示用一時ファイル）に基づいて、携帯電話１０２の表示部に、分類の選択画面を表示するｈｔｍｌ文書を作成する。なお、分類の選択画面とは、表示用本クラスタ３４０４を、その「cid」毎に分類して「term」が表示された画面のことである。ただし、分類の選択画面の詳細については、図３６にて後述する。第一のｃｇｉは、本クラスタ送信部ともいえる。
【０１５４】
第二のｃｇｉ３４０７は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行されるｃｇｉである。
第二のｃｇｉ３４０７は、分類の選択画面を表示している携帯電話から、得られたパラメータである地名及び関連語で検索キー・ファイル名対応テーブル３１２（図１３（ｂ）を参照）を検索する。そして、検索キー・ファイル名対応テーブル３１２から、地名及び関連語に対応する検索結果ｈｔｍｌファイル名を取得する。
【０１５５】
第二のｃｇｉ３４０７は、この検索結果ｈｔｍｌファイル名で検索結果ｈｔｍｌファイルディレクトリ３１０を検索し、検索結果ｈｔｍｌファイルを取得する。そして、第二のｃｇｉ３４０７は、取得した検索結果ｈｔｍｌファイルを携帯電話用のｈｔｍｌファイルに変換し、携帯電話１０２の表示部に検索結果画面を表示するためのｈｔｍｌ文書を作成する。
なお、検索結果画面とは、地名及び関連語を検索クエリとして、検索エンジン１０４（図１参照）で検索を行った際の画面のことであり、その詳細については図３７（ａ）にて後述する。ただし、ここでの地名及び関連語は、分類の選択画面を表示している携帯電話１０２から得られるパラメータのことである。
【０１５６】
第三のｃｇｉ３４０８は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行される。このプログラムによって実行される第三のｃｇｉ３４０８による処理が後述するリアルタイム処理（３）を行うブロック（図３５のステップＳ３５０８、図４２）である。
第三のｃｇｉ３４０８は、検索結果画面を表示している携帯電話１０２から、得られたパラメータであるキャッシュファイル名で検索キー・ファイル名対応テーブル３１２を検索する。そして、検索キー・ファイル名対応テーブル３１２から、キャッシュファイル名を取得する。第三のｃｇｉ３４０８は、このファイル名でキャッシュファイルディレクトリ３１１を検索して、キャッシュファイルを取得する。
【０１５７】
キャッシュファイルのプレーンテキストに住所文字列が含まれていない場合、第三のｃｇｉ３４０８は、取得したキャッシュファイルを携帯電話ｈｔｍｌに変換する。第三のｃｇｉ３４０８によって変換された携帯電話ｈｔｍｌは、携帯電話１０２の表示部１１１にキャッシュファイルのプレーンテキストを表示するｈｔｍｌ文書である。
【０１５８】
一方、キャッシュファイルのプレーンテキストに住所文字列が含まれている場合、第三のｃｇｉ３４０８は、検索キー・ファイル名対応テーブル３１２の緯度・経度のフィールドから位置情報を取得して、地図サーバ１０５へのＡタグを生成する。そして、第三のｃｇｉ３４０８は、Ａタグ及びキャッシュファイルを基にして、携帯電話１０２の表示部１１１に地図付きキャッシュ画面を表示するｈｔｍｌ文書を作成する。なお、地図付きキャッシュ画面とは、キャッシュファイルのプレーンテキストと共にプレーンテキストに記載された位置情報を中心とする地図を含む画面のことである。ただし、地図付きキャッシュ画面の詳細については、図３７にて後述する。
【０１５９】
第四のｃｇｉ３４０９は、携帯電話１０２から来るアクセス要求に応じて、ｗｅｂサーバプログラム３４０２によって実行される。このプログラムによる第四のｃｇｉ３４０９の処理が後述する連想語検索処理を行うブロック（図４３のステップＳ４３０３，図４５）である。
第四のｃｇｉ３４０９は、分類の選択画面３６０２を表示している携帯電話１０２から得られるパラメータの中で、クラスタ番号で第一のｃｇｉにて生成された表示用本クラスタ３４０４クラスタ番号(cid)に属する関連語（term）を全て取得する。そして、この取得した各関連語でＷＡＭファイルディレクトリ３１３を検索する。
この検索により、ＷＡＭファイルディレクトリ３１３から各関連語のＷＡＭファイル全てを取得し、これらＷＡＭファイルから連想語テーブル３４１０を生成する。連想語テーブル３４１０とは、携帯電話１０２から得られた各関連語の連想語が書かれたテーブルのことである。なお、連想語とは、各関連語から連想される単語のことである。この連想語テーブルについては、図４６にて後述する。
【０１６０】
第四のｃｇｉ３４０９は、連想語テーブル３４１０に基づいて、携帯電話１０２の表示部１１１に連想語画面を表示するｈｔｍｌ文書を作成する。なお、連想語画面とは、連想語テーブル３４１０に書かれている各連想語を羅列した画面のことである。ただし、連想語画面の詳細については、図４４にて後述する。
【０１６１】
[リアルタイム処理部の動作]
次に、リアルタイム処理の流れを説明する。
図３５は、携帯電話１０２（クライアント）、モバイル情報検索サーバ１０３及び地図サーバ１０５の間で行われる動作を示すシーケンス図である。
まず、ユーザは、携帯電話１０２の所定のアプリケーションを起動する。すると、携帯電話１０２は、ＧＰＳ受信部１０８において、ＧＰＳ衛星１０７より携帯電話１０２の現在位置情報（以下、「ＧＰＳ位置データ」という）を取得し、入出力制御部１０９を通じてモバイル情報検索サーバ１０３に送信する（ステップＳ３５０１）。ここで、ＧＰＳ位置データとは、携帯電話１０２の現在位置の緯度及び経度のことである。以下では、携帯電話１０２の現在位置が新宿の場合を例として、リアルタイム処理の流れを説明する。また、ステップＳ３５０１の処理の際に、携帯電話１０２は、入出力制御部１０９を通じて、携帯電話１０２のユーザエージェント文字列もモバイル情報検索サーバ１０３に送信するようにしている。
【０１６２】
モバイル情報検索サーバ１０３は、ＧＰＳ位置データすなわち新宿の緯度及び経度を受信する。そして、現在位置情報及びユーザエージェント文字列に基づいて、図３８にて後述するリアルタイム処理（１）を実行し（ステップＳ３５０２）、携帯電話１０２の表示部１１１に図３６に示す分類の選択画面３６０２を表示するｈｔｍｌ文書を作成して、クライアント側へ送信する（ステップＳ３５０３）。
【０１６３】
次に、携帯電話１０２は、後述するリアルタイム処理（１）で作成されたｈｔｍｌ文書を入出力制御部１０９により取得・解釈する。そして、このｈｔｍｌ文書は表示制御部１１０を通じて表示部１１１に入力される。これにより、携帯電話１０２の表示部１１１に分類の選択画面３６０２が表示される。図３６に示されるように、分類の選択画面３６０２には、現在位置の地名「新宿」に対する関連語がクラスタ番号毎に、すなわちクラスタ毎に分類されて表示されている。ユーザは、携帯電話１０２の入力部１１２を操作して、分類の選択画面３６０２から、例えば「レストラン」という関連語を選択する。すると、携帯電話１０２は、「（現在位置の地名）＋（スペース）＋（関連語）」である「（新宿）＋（スペース）＋（レストラン）」の文字列をモバイル情報検索サーバ１０３側に送信する（ステップＳ３５０４）。
【０１６４】
モバイル情報検索サーバ１０３は、「（新宿）＋（スペース）＋（レストラン）」という文字列を受信する。そして、この文字列に基づいて、図４１にて後述するリアルタイム処理（２）を実行し（ステップＳ３５０５）、携帯電話１０２の表示部１１１に図３７（ａ）に示す検索結果画面３７０２を表示するｈｔｍｌ文書を作成して、クライアント側へ送信する（ステップＳ３５０６）。
【０１６５】
携帯電話１０２は、後述するリアルタイム処理（２）で作成されたｈｔｍｌ文書を入出力制御部１０９により取得・解釈する。そして、このｈｔｍｌ文書は表示制御部１１０を通じて表示部１１１に入力され、携帯電話１０２の表示部１１１に検索結果画面３７０２が表示される。このとき、検索結果画面３７０２には、「（新宿）＋（スペース）＋（レストラン）」を検索クエリにしてウェブページを検索した検索結果が表示されている。ユーザは、携帯電話１０２の入力部１１２を操作して、検索結果画面３７０２の「■（黒四角）」ボタン３７０３或いは「□（白四角）」ボタン３７０４を選択すると、所定のキャッシュファイル名がモバイル情報検索サーバ１０３側へ送信される（ステップＳ３５０７）。なお、「■（黒四角）」ボタン３７０３は、モバイル情報検索サーバ１０３側へ送信されるキャッシュファイル名のキャッシュファイル内に住所が含まれているリンクボタンであり、「□（白四角）」ボタン３７０４はキャッシュファイル内に住所が含まれていないリンクボタンである。
【０１６６】
モバイル情報検索サーバ１０３は、例えば「■（黒四角）」ボタン３７０３に対応するキャッシュファイル名を受信したとする。すると、このキャッシュファイル名に基づいて、図４２にて後述するリアルタイム処理（３）を行う。そして、携帯電話１０２の表示部１１１に地図キャッシュ画面を表示するｈｔｍｌ文書を作成し（ステップＳ３５０８）、クライアント側へ送信する（ステップＳ３５０９）。
【０１６７】
携帯電話１０２は、リアルタイム処理（３）で作成されたｈｔｍｌ文書を入出力制御部１０９により取得・解釈する。そして、地図サーバ１０５に地図画像要求を送信する（ステップＳ３５１０）。すなわち、このリアルタイム処理（３）で生成されたｈｔｍｌ文書には、地図画像３７０６の所在を示す地図サーバ１０５のＵＲＬが記載されており、携帯電話１０２の入出力制御部１０９は、携帯電話１０２に当該ＵＲＬの地図画像３７０６を送信するように地図サーバ１０５に要求する。この要求を受けて、地図サーバ１０５は、地図画像３７０６を携帯電話１０２（クライアント）側へ送信する（ステップＳ３５１１）。
【０１６８】
携帯電話１０２は、地図サーバ１０５から地図画像３７０６を受信して、表示部１１１に、図３７（ｂ）に示されるような地図付きキャッシュ画面３７０５を表示する。なお、地図付きキャッシュ画面３７０５の「☆（星印）」記号３７０７の位置は、キャッシュファイル内に含まれる住所に一致している。具体的には、地図付きキャッシュ画面３７０５に表示された、東京都新宿区歌舞伎町○−△□−□という住所に当たる。
【０１６９】
[リアルタイム処理（１）フロー]
図３８は、図３５のＳ３５０２のリアルタイム処理（１）の詳細な処理の流れを示すフローチャートである。
【０１７０】
図３５のステップＳ３５０２で説明したように、第一のｃｇｉが処理を開始すると（ステップＳ３８０１）、第一のｃｇｉ３４０３は携帯電話１０２から受信したＧＰＳ位置データで、ＧＰＳ地名マスタ３０８（図３を参照）を検索する（ステップＳ３８０２）。そして、ＧＰＳ地名マスタ３０８から検索がヒットした地名を取得する。
【０１７１】
次に、地名を検索クエリとして本クラスタディレクトリ３１８を検索し（ステップＳ３８０４）、地名に応じた本クラスタ８０２（図８、図３２及び図３３を参照）を取得する。そして、第一のｃｇｉ３４０３は、ＧＰＳ位置データと共に携帯電話１０２が取得したユーザエージェント文字列を基にして、携帯端末マスタ３４０５を検索する。そして、携帯端末マスタ３４０５の検索によって、携帯電話１０２の機種名を取得する。
なお、携帯端末マスタ３４０５の中には、携帯電話１０２の機種名及びその画面に関する諸情報が記録されている。例えば、等幅フォントであれば、画面の幅はバイト数で決定できる。また、プロポーショナルフォントを使っている場合は、画面に収められる文字数がその文字列によって変化する。そこで、携帯端末マスタ３４０５で画面に関する諸情報を取得して、本クラスタ８０２をその携帯端末に最適な表示用本クラスタ３４０４に変換するのである（ステップＳ３８０５）。
【０１７２】
次に、このようにして変換した表示用本クラスタ３４０４を携帯電話ｈｔｍｌ文書に変換する（ステップＳ３８０６）。最後に、第一のｃｇｉ３４０３は、変換したｈｔｍｌ文書をクライアントに送信して（ステップＳ３８０７）、一連の処理を終了する（ステップＳ３８０８）。なお、等幅フォントを使用する場合は、画面のバイト数で本クラスタ８０２から表示用本クラスタ３４０４に変換する文字数が一意的に“１”に決められる。ただし、プロポーショナルフォントを使う場合は、本クラスタ８０２で表示しようとする関連語の文字列を、プロプロポーショナルフォントファイル３４０６を使って参照し、それら文字列を表示するのに必要な画面のピクセル数を得る。画面のピクセル数と携帯電話１０２の画面の横幅とを比較して最適な文字数を決定する。
【０１７３】
図３９は、表示用の本クラスタの一例を示す。
この例は、図３２及び図３３に示す本クラスタ８０２を携帯端末毎に最適な表示用形態に変換したものである。ここで、図３２及び図３３に示す本クラスタ８０２の各レコードと、図３９に示す表示用本クラスタ３４０４の各レコードとを比較する。すると、表示用本クラスタ３４０４は、本クラスタ８０２から所定のレコードを削除したものであることが確認できる。つまり、携帯電話上で最適化できる表示に変換した結果、表示用本クラスタ３４０４は、本クラスタ８０２のcid=3,8,12,17,33,48,62のレコードのみを残して削除したものとなっている。なお、本クラスタ８０２から削除するレコードの条件は、同一の「cid」のレコードの各「term」の文字列数すなわち「len」合計が２０以上３０以下のレコードである。ただし、「term」が複数ある場合は、各「term」の間にはスペースが入るので、「term」の数だけスペースの文字列数が追加される。
【０１７４】
また、本クラスタ８０２から表示用本クラスタ３４０４に変換する際、cid=17の各レコードに注目すると、図３２に示されるcid=17，tid=4のレコードのみ削除されている。このレコードを含めてしまうと合計文字列数が３１となり、レコードを削除する条件を満たしてしまうためである。図３２のcid=3,tid=3のレコードも同様の理由で削除される。
【０１７５】
図４０は、表示用本クラスタ３４０４のｈｔｍｌ文書の一例を示した図である。
表示用本クラスタｈｔｍｌ文書４００２は、携帯電話１０２の表示部１１１に図３６に示す分類の表示画面を表示させるｈｔｍｌ文書である。
以下、表示用本クラスタｈｔｍｌ文書４００２に記載されている単語の並びについて説明する。
【０１７６】
図３９に示す表示用本クラスタ３４０４の各パラメータの中で、表示用本クラスタｈｔｍｌ文書４００２を生成するのに必要なパラメータは、「cid」、「tid」及び「term」である。
ここで、表示用本クラスタｈｔｍｌ文書４００２の一行目に注目する。
この行には、表示用本クラスタ３４０４の「cid」が最も小さいレコードの「term」である「カプセルホテル」及び「新宿区役所」が、「tid」の小さい順に左から並んでいる。また、一番左の「カプセルホテル」のさらに左脇には、表示用本クラスタ３４０４の中で最も「cid」が小さい、つまり「新宿」という地名に最も関連しているクラスタであることを示す「（０１）」が付与されている。なお、表示用本クラスタｈｔｍｌ文書４００２の一行目以降も一行目と同様の特徴を持っている。
【０１７７】
以上のような特徴を持った表示用本クラスタｈｔｍｌ文書４００２を携帯電話１０２に送信することにより、携帯電話１０２は、その表示部１１１に図３６に示す分類の選択画面３６０２を表示する。
【０１７８】
[リアルタイム処理（２）フロー]
図４１は、図３５のＳ３５０５のリアルタイム処理（２）の詳細な処理の流れを示すフローチャートである。
【０１７９】
図３５のステップＳ３５０５で説明したように、携帯電話１０２から地名＋関連語というパラメータが送られると（ステップＳ４１０１）、第二のｃｇｉ３４０７は、この携帯電話１０２から受信した地名＋関連語を検索クエリとして、検索キー・ファイル名対応テーブル３１２を検索する。そして、その結果、検索結果ｈｔｍｌファイル名を取得する（ステップS４１０２）。
【０１８０】
この検索結果ｈｔｍｌファイル名の検索結果ｈｔｍｌファイルは、検索エンジン１０４から取得した検索結果のｈｔｍｌファイルである。このｈｔｍｌファイルに書かれているＡタグを選択すると検索エンジン１０４にアクセスしてしまうので、そこはモバイル情報検索サーバ１０３宛のアクセスを示すＡタグに書き換えなければならない。
そこで、第二のｃｇｉ３４０７は、この検索結果ｈｔｍｌファイルに記されている検索エンジン１０４宛のＡタグを、モバイル情報検索サーバ１０３宛のＡタグに変換する処理を行う（ステップＳ４１０３）。そして、変換されたｈｔｍｌファイルを携帯電話（クライアント）１０２に送信して（ステップＳ４１０４）、処理を終了する（ステップＳ４１０５）。
【０１８１】
[リアルタイム処理（３）フロー]
図４２は、図３５のＳ３５０８のリアルタイム処理（３）の詳細な処理の流れを示すフローチャートである。
【０１８２】
図３５のステップＳ３５０８で説明したように、ユーザが携帯電話１０２で検索結果ｈｔｍｌファイルのＡタグの一つを選択すると、そこに埋め込まれているキャッシュファイル名がモバイル情報検索サーバ１０３に送信される（ステップＳ４２０１）。
【０１８３】
第三のｃｇｉ３４０８は、キャッシュファイル名を検索キーとして、検索キー・ファイル名対応テーブル３１２を検索する。そして、検索にヒットしたレコードの住所フィールドをみる（ステップＳ４２０２）。そこで、この住所フィールドが何らかの文字列が含まれるかどうか、すなわち住所が含まれているかどうか確認する（ステップＳ４２０３）。もし住所フィールドに住所が含まれているのであれば、そのレコードの緯度・経度フィールドを読んで、地図サーバ１０５へのイメージタグを生成する（ステップＳ４２０４）。そして、キャッシュファイルを地図サーバ１０５へのイメージタグを含む携帯用ｈｔｍｌファイルに変換する（ステップＳ４２０５）。
そして、このようにして生成した携帯用ｈｔｍｌファイルをクライアントである携帯電話１０２へ送信して（ステップＳ４２０６）、処理を終了する（ステップＳ４２０７）。
【０１８４】
もし、ステップＳ４２０３の処理において、住所フィールドが空である場合、すなわち住所を含んでいなかったならば、住所がないので先に説明したステップＳ４２０４のような変換は一切行わず、単にキャッシュファイルを携帯用ｈｔｍｌファイルに変換する（ステップＳ４２０８）。それをクライアントに送信し（ステップＳ４２０６）、処理を終了する（ステップＳ４２０７）。
【０１８５】
[連想語検索処理フロー]
図４３は、携帯電話１０２とモバイル情報検索サーバ１０３との間で行われる連想語検索処理の流れを示すシーケンス図である。
ここでは、図３５におけるリアルタイム処理（１）から、ユーザがクラスタを選択した場合の動作の流れを示している。
【０１８６】
図３６において関連語をクリックした動作は、図３５で説明した動作であったが、この図４３に示される動作は、図３６の関連語の前にある「ｗ」の記号をクリックした時の動作である。
【０１８７】
リアルタイム処理（１）までの処理は、図３５で説明した処理と同じである。
携帯電話１０２を保有するユーザは、表示用本クラスタ３４０４ｈｔｍｌ、すなわち分類の選択画面３６０２を表示した中で、「ｗ」の記号３６０３を選択する。これは、クラスタの選択に相当する。すると、「ｗ」の記号３６０３の中に埋め込まれているクラスタ番号が、第四のｃｇｉ３４０９に向けて送信される。そして、第四のｃｇｉ３４０９は、連想語検索を行って連想語表示画面を携帯電話１０２の表示部１１１に表示するｈｔｍｌ文書（以下、「連想語検索結果ｈｔｍｌ文書」という）を携帯電話１０２（クライアント）に送信する。以降、この連想語結果検索ｈｔｍｌ文書に従って、ユーザは連想語のさらに絞り込みを行ったり、連想語の連想語を検索したりする等の操作を継続することとなる。
【０１８８】
図４４は、連想語検索処理の結果として、携帯電話１０２の表示部１１１に表示される連想検索結果を示す一例である。
図４４（ａ）は、新宿のレストラン及びイタリアンという単語について連想語検索処理を行った結果を示す図である。
ここで、図４４（ａ）に示す関連語の連想語検索結果画面４４０２上のフレンチの横にあるｗ記号４４０３をクリックすると、図４４（ｂ）に示す連想語の連想語検索結果画面４４０４が表示されることとなる。ここでは、新宿のフレンチ、レストラン及びイタリアンの連想語検索結果画面４４０４が表示されている。すなわち、レストラン及びイタリアンという単語に、さらにフレンチという連想語が追加されて検索されたものとなる。このようにして、連想語の連想語、更に、連想語の連想語の連想語、…、という風に、芋づる式に、連想語検索処理を行うことができる。
【０１８９】
ここから、このような連想語検索処理の動作について、図４５に基づいて詳細に説明する。
図４５は、図４３のＳ４３０３の連想語検索処理の詳細な処理の流れを示すフローチャートである。
【０１９０】
図４３のステップＳ４３０３で説明したように、携帯電話１０２からクラスタ番号を受信すると（ステップＳ４５０１）、第四のｃｇｉ３４０９は表示用本クラスタ３４０４から得られた同一クラスタに属する関連語のＷＡＭファイルを全て取得する（ステップＳ４５０２）。
【０１９１】
そして、第四のｃｇｉ３４０９は、取得した処理対象のＷＡＭファイルをソートする。そうすると、キャッシュファイル名は上の方に、単語（関連語及び周辺語）はその単語の出現頻度と共に、キャッシュファイル名の下に並ぶこととなる。そこで、単語の部分のみを抜き出して、出現する単語の出現頻度を加算する。そして、単語を連想語テーブル３４１０の「aterm」のフィールドに、当該単語の出現頻度を加算した結果を連想語テーブル３４１０の「wcnt」のフィールドに順次書き込む（ステップＳ４５０３）。
【０１９２】
次に、処理対象となるＷＡＭファイルから、関連語テーブルの「aterm」フィールドの各単語が出現するキャッシュファイルの数を、連想語テーブル３４１０の「pcnt」フィールドに順次書き込む（ステップＳ４５０４）。
【０１９３】
続いて、第四のｃｇｉ３４０９は、連想語テーブル３４１０の各レコード毎に、「wcnt」及び「pcnt」からＴＦＩＤＦ値を計算し、その計算結果を当該各レコードの「tfidf」のフィールドに順次書き込む（ステップＳ４５０５）。ＴＦＩＤＦ値とは、文章中の特徴的な単語（重要とみなされる単語）を抽出するためのアルゴリズムであり、主に情報検索や文章要約などの分野で利用される。なお、ＴＦＩＤＦ値の計算式を以下に示す。計算式において、“１００００”は検索エンジン１０４からモバイル検索サーバ１０３が取得したキャッシュファイルの総数に対応している。また、対数の項に加算される“１”は、ｐｃｎｔの値が小さいときに、ＴＦＩＤＦ値が“０”となることを回避するための調整値である。
【０１９４】
〔数２〕
tfidf=wcnt*(1+log(10000/pcnt))
【０１９５】
第四のｃｇｉ３４０９は、さらにＴＦＩＤＦ値の大きい順に連想語テーブル３４１０の並び替えを行う。そして、連想語テーブル３４１０の「aterm」が連想語またはストップワードと一致するレコードを削除する（ステップ４５０７）。その結果として、第四のｃｇｉ３４０９は、連想語テーブル３４１０からｈｔｍｌ文書を作成し、それを送信して（ステップＳ４５０８）、処理を終了する（ステップＳ４５０９）。
【０１９６】
図４６は、連想語テーブル３４１０の中身の一例を示す図である。
図４６（ａ）は、図４５のステップＳ４５０５の処理の時点の連想語テーブル３４１０の中身である。
図４６（ｂ）は、図４５のステップ４５０７の処理を経た連想語テーブル３４１０の中身である。
図４６（ａ）の連想語テーブル３４１０に対して、ＴＦＩＤＦ値の大きい順に連想語テーブル３４１０の各レコードをソートした後に、「aterm」がストップワード（東京）及び関連語（レストラン、イタリアン）と一致するレコードを削除する。すると、連想語のみが抽出された図４６（ｂ）の連想語テーブル３４１０が生成される。なお、以上の処理により生成された連想語テーブル３４１０をｈｔｍｌ文書に変換して、携帯電話１０２の表示部１１１に表示させたものが、図４４（ｂ）に示す連想語検索結果画面である。
【０１９７】
本実施形態には、以下のような応用例が考えられる。
（１）例えば、検索エンジン１０４には、検索対象の言葉のカテゴリの深さを開示する機能がある。そこで、このカテゴリの深さというものを検索結果に反映させることで、より最適な検索結果の表示を実現することができる。
【０１９８】
図４７は、深さ付与処理の流れを示すフローチャートである。
深さ付与処理とは、検索対象の関連語（term）の深さを表示用本クラスタ３４０４に与える処理である。
図３８には図示していないが、この深さ付与処理は、図３８のステップＳ３８０５の処理とステップＳ３８０６の処理の間に挿入される処理である。この処理は、オプションで必要に応じて行われる。
【０１９９】
ここで、処理を開始すると（ステップＳ４７０１）、表示用本クラスタ３４０４の先頭レコードに注目する（ステップＳ４７０２）。そして、変数ｄに現在注目しているレコードの「cid」を代入する（ステップＳ４７０３）。
【０２００】
次に、表示用本クラスタ３４０４の現在のレコードの「term」を、図示しない深さテーブルで検索して、「term」の深さを得る（ステップＳ４７０４）。なお、深さテーブルとは、表示用本クラスタ３４０４の「term」とその深さが対応付けられて書き込まれているテーブルのことである。ただし、この深さの情報は、予め検索エンジン１０４から取得して、深さテーブルに書き込んでおく。
【０２０１】
以上のようにして得た「深さ」の情報を、表示用本クラスタ３４０４の現在のレコードの「new_tid」に書き込む（ステップＳ４７０５）。
以上の処理が完了すると、表示用本クラスタ３４０４のレコードをインクリメントし、現在のレコードの次にあるレコードに注目する（ステップＳ４７０６）。
【０２０２】
次に、表示用本クラスタ３４０４にまだレコードが存在するか否かを確認する（ステップＳ４７０７）。レコードがまだ存在する場合には（ステップＳ４７０７のＹ）、現在注目しているレコードの「cid」が変数ｄと等しいか否かを確認する（ステップＳ４７０８）。注目レコードの「cid」が変数ｄと等しい場合は（ステップＳ４７０８のＮ）、ステップＳ４７０４の処理に戻り、再びステップＳ４７０４以降の処理を繰り返す。注目レコードの「cid」が変数ｄと等しくない場合には（ステップＳ４７０８のＹ）、表示用本クラスタ３４０４のcid=dの各レコードの「new_tid」の最小値を、当該各レコードの「new_cid」に書き込む（ステップＳ４７０９）。
【０２０３】
ステップＳ４７０７の処理にて、表示用本クラスタ３４０４のレコードが存在しない場合には（ステップＳ４７０７のＮ）、「new_cid」、「cid」、「new_tid」の順にソートのキーの優先順位を設定して、表示用本クラスタ３４０４の各レコードを並び替え（ステップＳ４７１０）、処理を終了する（ステップＳ４７１１）。
【０２０４】
図４８は、図４７で説明した深さ付与処理において用いる表示用本クラスタ４８０２である。
図３９の表示用本クラスタ３４０４と違う点は、「new_cid」及び「new_tid」というフィールドが新たに付与されている点である。これらのフィールドが深さ付与処理において有効に機能することとなる。
図４９は、深さで分類した表示用本クラスタの中身を示す図である。すなわち、図４９の表示用本クラスタ４９０２は、図４８の表示用本クラスタ４９０２をステップＳ４７１０で処理することによって、並び替えたものである。具体的には、「new_cid」が第一優先、「cid」が第二優先「new_tid」が第三優先となった並び替え結果となる。
【０２０５】
図５０は、携帯電話１０２の表示画面に関連する図である。
図５０（ａ）は、深さ付与処理がなされた表示用本クラスタｈｔｍｌ文書の一例である。
深さで分類した表示用本クラスタｈｔｍｌ文書５００２は、携帯電話１０２の表示部１１１に図５０（ｂ）に示す分類の選択画面５００３を表示させるｈｔｍｌ文書である。なお、分類の選択画面５００３は、図３６に示す分類の選択画面３６０２と同じ特徴を持っているので、説明は省略する。
【０２０６】
以下、本クラスタｈｔｍｌ文書に記載されている単語の並びについて説明する。
図４９に示す本クラスタの各パラメータの中で、深さで分類した表示用本クラスタｈｔｍｌ文書５００２を生成するのに必要なパラメータは、「cid」、「new_cid」及び「new_tid」である。
ここで、深さで分類した表示用本クラスタｈｔｍｌ文書５００２の一行目に注目する。
この行には、図４９に示す表示用本クラスタ４８０２の「cid」と「new_cid」の合計が最も小さいレコードの「term」である「レストラン」及び「イタリアン」が、「new_tid」の小さい順に左から並んでいる。また、図５０（ａ）に示すように、一番左の「レストラン」のさらに左脇には、表示用本クラスタ４８０２の中で最も「cid」と「new_cid」の合計が小さい、つまり「新宿」という地名に最も関連しているクラスタであることを示す「（０１）」が付与されている。なお、深さで分類した表示用本クラスタｈｔｍｌ文書５００２の一行目以降も一行目と同様の特徴を持っている。
【０２０７】
以上のような、深さ付与処理を行うことによって、表示内容が表示される関連語（term）がより最適化されて分類される。
【０２０８】
（２）上述の実施形態においては、携帯電話１０２の現在位置の地名を検索クエリとして、自動的にモバイル情報検索サーバ１０３に送信した。その代替えとして、検索エンジン１０４のリアルタイム処理部２０２に、図５１に示すアプリケーション起動時表示画面５１０２を携帯電話１０２に表示するｈｔｍｌ文書を作成するｃｇｉを設けておけば、入力部１１２からユーザの所望する文字列、例えば地名以外の固有名詞等を入力することにより、その文字列を検索クエリとしてモバイル情報検索サーバ１０３に送信できるようにしてもよい。なお、携帯電話１０２から地名以外の固有名詞を検索クエリとしてリアルタイムサーバに送信する場合は、ＧＰＳ地名マスタの代わりに、固有名詞等が書かれたマスタを不揮発性記憶装置に用意しておく必要がある。
【０２０９】
（３）上述の実施形態においては、携帯電話１０２の現在位置の地名を検索クエリとして、自動的にモバイル情報検索サーバ１０３に送信したが、その代替えとして、携帯電話１０２の現在位置付近の駅名或いは地名等を選択的にモバイル情報検索サーバ１０３に送信できるようにしてもよい。
【０２１０】
（４）上述の実施形態においては、モバイル情報検索サーバ１０３と検索エンジン１０４はインターネット１０６を介して接続されているが、その代替として、モバイル情報検索サーバ１０３及び検索エンジン１０４を一体化したサーバを用いることもできる。
【０２１１】
（５）上述の実施形態において、モバイル情報検索サーバ１０３は、検索エンジン１０４から所定の地名の関連語を取得したが、当該地名に関連するような単語を取得できるのであればいかなるものから取得してもかまわない。例えば、関連語を取得できる場所としては、その地名に関連する情報が記載されているホームページ等があげられる。
【０２１２】
（６）上記の実施形態においては、ＷＡＭファイル生成処理部３０４は、検索対象として日本語を想定し、形態素解析を行ったが、日本語以外の言語に対しては、接辞処理（ｓｔｅｍｍｉｎｇ）を行うことで、語形変化の多様性を正規化することができる。ここで、接辞処理とは、予め用意された規則にしたがって接尾辞や接頭辞を削除し、語基（ｓｔｅｍ）のみを残す処理のことである。
【０２１３】
また、検索エンジン１０４には、単語を別の単語に翻訳する機能がある。関連語の分類表示は単語の羅列であり、文法構造を含まないため、係り受け構造の解析などの複雑な翻訳処理を必要としない。上記の実施形態においては、携帯電話１０２の表示言語として日本語を想定しているが、関連語を日本語以外の別の言語の翻訳することにより、言語横断検索を行ってもよい。関連語の翻訳処理は、携帯電話１０２の表示の直前に行われる処理である。すなわち図４７に示す深さ付与処理のステップＳ４７１０の処理とステップＳ４７１１の処理の間で行われる処理である。この処理は、必要に応じてオプションスイッチとして提供することが望ましい。
【０２１４】
（７）上記の実施形態においては、〔数１〕により、単語間の関連性の強さを計算している。これは、発明者の行ったデータ実験において、〔数１〕が他の計算式よりも、良い精度で共起関係を抽出できることが確認されたためである。〔数１〕の代替として、共起関係を抽出するための計算式として情報検索の分野でよく知られている、相互情報量、カイ二乗値、シンプソン係数などの計算式を用いても良い。なお、これらの計算式によっても、ある程度の精度で、関連語の共起関係を抽出することができることが発明者によって確認されている。
【０２１５】
（８）また、ＷＡＭファイルに対し、全文検索を実行してもよい。このためには、予めインデックス作成プログラムを用いて、ＷＡＭファイル内に含まれるキャッシュファイル名、検索結果ｈｔｍｌファイル名及びＷＡＭファイル内の単語の出現頻度等を高速に検索することができる、インデックスファイルを作成しておく。そして、全文検索実行時には、全文検索エンジンがインデックスファイルにアクセスして、高速な検索を実現する。これにより、図１６に示すステップＳ１６１１、ステップＳ１６１３及びステップＳ１６１５のループ処理をする必要がなくなり、処理の高速化を実現できる。
【０２１６】
また、ＷＡＭファイルに対して全文検索エンジンによる全文検索を用いることにより、第二のｃｇｉ３４０７の処理を一部代替することができる。具体的には、図４１のステップＳ４１０２を、「地名＋関連語で全てのＷＡＭファイルを対象に全文検索を実行する」、とする。そして、ステップＳ４１０３は、「検索にヒットしたＷＡＭファイル名からキャッシュファイル名へのＡタグを生成する」、とする。
【０２１７】
また、図４１のステップＳ４１０２は、上記ＷＡＭファイルに対する全文検索エンジンによる全文検索に代えて、キャッシュファイルに対する全文検索エンジンによる全文検索を用いた処理とすることができる。この場合は、検索結果にノイズがやや増えるものの、詳細な検索を行いたい場合に向いている。
【０２１８】
なお、このような全文検索エンジンを用いることで、地名＋関連語に限らず、連想語を含む任意の単語を用いた検索も実現できる。
【０２１９】
（９）また、第二のｃｇｉ３４０７は、図１３の検索キー・ファイル名対応テーブル３１２から取得した検索結果ｈｔｍｌファイル１００３を、検索クエリのＴＦＩＤＦ値の大きいものの順で順序付けしてから、携帯電話１０２に検索結果画面を表示するためのｈｔｍｌ文書を作成してもよい。
【０２２０】
また、検索結果ｈｔｍｌファイル１００３は、図１３の検索キー・ファイル名対応テーブル３１２から取得した（緯度、経度）とユーザの現在位置の（緯度、経度）のユークリッド距離の小さいものの順で順序付けしても良い。
【０２２１】
検索結果ｈｔｍｌファイル１００３の順序付けは、必要に応じてオプションスイッチとして提供することが望ましい。また、順序付けは、ユーザからの要求に応じて選択的に行うようにしてもよい。
【０２２２】
（１０）上記の実施形態においては、ＧＰＳ受信部１０８から得られる位置情報に対応する地名を取得しているが、携帯電話１０２の保有する音声認識の機能により地名等の固有名詞を取得してもよい。
また、ユーザが受信したメールからコピーアンドペーストの機能により切り出した固有名詞を取得してもよい。これらの処理は、図３８のステップＳ３８０２及びステップＳ３８０３の処理、すなわち地名（固有名詞）を取得する手段の代替となる。なお、これらの処理は、必要に応じてオプションスイッチとして提供することが望ましい。
【０２２３】
以上説明したように、本実施形態では、検索エンジンが提供する、地名に対して強い結びつきを示す関連語を出力するサービスを有効活用している。「地名＋関連語＜１＞」、「地名＋関連語＜２＞」、…、で検索して、そこから得られる各ウェブサイトのキャッシュファイルに対し、各関連語の前後の数単語だけに情報を絞り込んでいる。この情報を基に、各キャッシュファイルにおける各関連語同士の出現頻度を計算して、各関連語の分類を行う。情報が絞り込まれているから、情報の純度が高い、逆に言えば、ノイズが少ない。こうして、分類分けされた各関連語の群をユーザに提示することで、情報をその地名に由来するクラスタ毎に整理して提供できる。
それにより、ユーザは目的地に立って、携帯電話に所定の操作を行うだけで、地名入力せずとも、その土地に由来する情報が整理された状態で提供される。したがって、ユーザの利便性が向上するという利点がある。
【０２２４】
また、本実施形態では、本クラスタを作成する際に、仮クラスタの各レコードにストップワードのフラグを設定する。つまり、ストップワードを含むレコードを最後に削除する。このため、ユーザにとって不要な情報を除外できるので、関連語を各カテゴリに分類する際の分類精度を向上させることができる。
【０２２５】
また、本実施形態は、携帯画面の表示可能文字数に合わせて、適切な文字列長で各クラスタに分類した関連語を表示できるように、本クラスタを表示用本クラスタに変換する。これにより、関連語の意味的な類似性を保ちつつ、携帯電話の小さな画面を有効活用した、分類表示が実現できる。
【０２２６】
また、本実施形態は、携帯画面に限らず、表示可能文字数が制限されている入出力機器一般、任意文字列の入力が制限されるタッチパネルモニタ付情報端末、高齢者、障害者、幼児など入出力の自由度が制限されたユーザ向けの端末においても、適応可能である。その際、本実施形態の特色である、ユーザの直感に合致する、適切なキーワード（検索クエリ）をクラスタリングして提供できるので、ユーザにとって易しい操作性を提供できると共に、検索出力結果もユーザが希望する内容に合致し易い。
【０２２７】
以上、本発明の実施形態の例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含むことはいうまでもない。
【図面の簡単な説明】
【０２２８】
【図１】本発明の一実施の形態による、情報検索システムの全体概略図及び携帯電話の機能ブロック図である。
【図２】モバイル情報検索サーバの機能ブロック図である。
【図３】バッチ処理部及び不揮発性データ記憶部の機能ブロック図である。
【図４】データ取得処理部を中心とする機能ブロック図である。
【図５】ＷＡＭファイル生成処理部を中心とする機能ブロック図である。
【図６】関連語出現テーブル生成処理部を中心とする機能ブロック図である。
【図７】ベストスコアテーブル生成処理部を中心とする機能ブロック図である。
【図８】本クラスタ生成処理部を中心とする機能ブロック図である。
【図９】モバイル情報検索サーバと検索エンジンとの間で行われる動作を示すシーケンス図である。
【図１０】検索エンジンから送信される関連語及び検索結果ｈｔｍｌファイルを示す図である。
【図１１】検索エンジンから送信されるキャッシュファイルを示す図である。
【図１２】モバイル情報検索サーバを構成するバッチ処理部の動作の流れを示すフローチャートである。
【図１３】ＧＰＳ地名マスタ及び検索キー・ファイル名対応テーブルを示す図である。
【図１４】バッチ処理部を構成するＷＡＭファイル生成処理部の動作の流れを示すフローチャートである。
【図１５】ＷＡＭファイル示す図である。
【図１６】バッチ処理部を構成する関連語出現テーブル生成処理部の動作の流れを示すフローチャートである。
【図１７】関連語出現テーブルを示す図である。
【図１８】バッチ処理部を構成するベストスコアテーブル生成処理部の動作の流れを示すフローチャートである。
【図１９】バッチ処理部を構成するベストスコアテーブル生成処理部の動作の流れを示すフローチャートの続きである。
【図２０】仮ベストスコアテーブルの更新を示す図である。
【図２１】本ベストスコアテーブルを示す図である。
【図２２】バッチ処理部を構成する本クラスタ生成処理部の動作の流れを示すフローチャートである。
【図２３】仮クラスタの生成手順を示す図である。
【図２４】仮クラスタを示す図である。
【図２５】本クラスタ生成処理部のｃｎｔ付与処理の詳細な処理の流れを示すフローチャートである。
【図２６】ｃｎｔが付与された仮クラスタを示す図である。
【図２７】本クラスタ生成処理部のｖａｌｉｄ付与処理の詳細な処理の流れを示すフローチャートである。
【図２８】ｖａｌｉｄが付与された仮クラスタを示す図である。
【図２９】本クラスタ生成処理部のａｌｔ付与処理の詳細な処理の流れを示すフローチャートである。
【図３０】ａｌｔが付与された仮クラスタを示す図である。
【図３１】ストップワードが付与された仮クラスタを示す図である。
【図３２】本クラスタを示す図である。
【図３３】本クラスタを示す図の続きである。
【図３４】リアルタイム処理部及び不揮発性データ記憶部の機能ブロック図を示す図である。
【図３５】携帯電話とモバイル情報検索サーバと地図サーバとの間で行われる動作の流れを示すシーケンス図である。
【図３６】携帯電話の画面に表示される分類の表示画面を示す図である。
【図３７】携帯電話の画面に表示される検索結果画面及び地図付きキャッシュ画面を示す図である。
【図３８】リアルタイム処理部を構成する第一のｃｇｉで行われる動作の流れを示すフローチャートである。
【図３９】表示用本クラスタを示す図である。
【図４０】表示用本クラスタｈｔｍｌ文書を示す図である。
【図４１】リアルタイム処理部を構成する第二のｃｇｉで行われる動作の流れを示すフローチャートである。
【図４２】リアルタイム処理部を構成する第三のｃｇｉで行われる動作の流れを示すフローチャートである。
【図４３】携帯電話とモバイル情報検索サーバとの間で行われる連想語検索に関する動作の流れを示すシーケンス図である。
【図４４】携帯電話に表示される連想語検索結果画面を示す図である。
【図４５】リアルタイム処理部を構成する第四のｃｇｉで行われる動作の流れを示すフローチャートである。
【図４６】連想語テーブルを示す図である。
【図４７】リアルタイム処理部を構成する第一のｃｇｉで行われる深さ付与処理の流れを示すフローチャートである。
【図４８】深さを付与した表示用本クラスタを示す図である。
【図４９】深さで分類した表示用本クラスタを示す図である。
【図５０】深さで分類した分類の選択画面を示す図である。
【図５１】携帯電話に表示されるアプリケーション起動時の表示画面を示す図である。
【符号の説明】
【０２２９】
１０１…情報検索システム、１０２…携帯電話、１０３…モバイル情報検索サーバ、１０４…検索エンジン、１０５…地図サーバ、１０６…インターネット、１０７…ＧＰＳ衛星、１０８…ＧＰＳ受信部、１０９…入出力制御部、１１０…表示制御部、１１１…表示部、１１２…入力部、１１３…ｗｅｂブラウザプログラム、２０２…バッチ理部、２０３…リアルタイム処理部、２０４…不揮発性データ記憶部、３０２…非対話型ウェブクライアント、３０３…データ取得処理部、３０４…ＷＡＭファイル生成処理部、３０５…関連語出現テーブル生成処理部、３０６…ベストスコアテーブル生成処理部、３０７…本クラスタ生成処理部、３０８…ＧＰＳ地名マスタ、３０９…地名関連語リスト、３１０…検索結果ファイルディレクトリ、３１１…キャッシュファイルディレクトリ、３１２…検索キー・ファイル名対応テーブル、３１３…ＷＡＭファイルディレクトリ、３１４…関連語出現テーブル、３１５…仮ベストスコアテーブル、３１６…本ベストスコアテーブル、３１７…仮クラスタ、３１８…本クラスタディレクトリ、３１９…本クラスタ作成部、５０２…ＷＡＭファイル、８０２…本クラスタ、１００３…検索結果ｈｔｍｌファイル、１００４…リンク先ＵＲＬ、１１０２…キャッシュファイル、１５０２…括弧、２００２…ソート前仮ベストスコアテーブル、２００３…ソート済仮ベストスコアテーブル（仮ベストスコアテーブル）、２１０２…２レコード、２１０３…１レコード、３４０２…ｗｅｂサーバプログラム、３４０３…第一のｃｉ、３４０４…表示用本クラスタ、３４０５…携帯端末マスタ、３４０６…プロポーショナルフォントファイル、３４０７…第二のｃｇｉ、３４０８…第三のｃｇｉ、３４０９…第四のｃｇｉ、３４１０…連想語テーブル、３６０２…分類の選択画面、記号…３６０３、３７０２…検索結果画面、３７０３…ボタン、３７０４…ボタン、３７０５…地図付きキャッシュ画面、３７０６…地図画像、３７０７…記号、４００２…表示用本クラスタｈｔｍｌ文書、４４０２…関連語の連想語検索結果画面、４４０３…記号、４４０４…連想語の連想語検索結果画面、４８０２…表示用本クラスタ、５００２点深さで分類した表意洋本クラスタｈｔｍｌ文書、５００３…深さで分類した分類の選択画面、５１０２…アプリケーション起動時表示画面
【特許請求の範囲】
【請求項１】
クライアントと、前記クライアントに情報を提供する情報検索サーバと、前記情報検索サーバの要求にしたがって所定の情報を出力する検索エンジンとよりなる情報検索システムであって、
前記クライアントは、
現在位置情報を取得するＧＰＳ受信部と、
所定の情報を表示する表示部と、
前記表示部を制御する表示制御部と、
前記ＧＰＳ受信部から得られる前記位置情報を送信すると共に、所定の情報を受信して前記表示制御部に渡す入出力制御部と
を備え、
前記検索エンジンは、所定の単語が入力されると前記単語の関連語を出力するものであり、
前記情報検索サーバは、
前記情報検索エンジンから前記所定の情報を受信して加工するバッチ処理部と、
前記バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、
前記不揮発性データ記憶部に蓄積された前記加工された情報を前記クライアントに送信するリアルタイム処理部と
を備え、
前記不揮発性データ記憶部は、
前記ＧＰＳ受信部から前記入出力制御部を通じて得られる前記現在位置情報に対応する地名が格納されているＧＰＳ地名マスタと、
前記情報検索エンジンから得られる、前記地名とその関連語群が格納される地名関連語リストと、
前記地名と前記関連語群から作成される前記地名と各々の関連語の組よりなる複数の検索クエリをそれぞれ前記情報検索エンジンにて検索した結果が記録される検索結果ファイル群が格納される検索結果ファイルディレクトリと、
前記検索結果ファイル群に記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、
前記検索結果ファイル毎に作成され、前記ネットワーク上の文書群に含まれる前記関連語を中心とする前後の単語が前記ネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、
前記ＷＡＭファイル中に出現する前記関連語の関係が記されている関連語出現テーブルと、
前記ＷＡＭファイル中に出現する前記関連語の類似度が記されている本ベストスコアテーブルと、
前記本ベストスコアテーブルから生成され、前記クライアントへ送信される本クラスタが格納される本クラスタディレクトリと
を備え、
前記バッチ処理部は、
前記ＧＰＳ地名マスタに含まれている前記地名を前記検索エンジンに与えて前記地名関連語リストを取得し、前記地名関連語リストから前記地名と前記関連語の組を前記検索エンジンに与えて前記検索結果ファイルを前記検索結果ファイルディレクトリに格納すると共に、前記検索結果ファイルに記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書を前記キャッシュファイルディレクトリに格納するデータ取得処理部と、
前記ネットワーク上の文書に含まれる前記関連語を中心とする前後の単語を取り出して前記ネットワーク上の文書のファイル名と共に前記ＷＡＭファイルに書き出し、前記ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、
同一の地名に係る複数の前記ＷＡＭファイルに基づいて、前記ネットワーク上の文書群と前記関連語の有無の関係を前記関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、
前記関連語出現テーブルを基に全ての前記各関連語同士の類似度を算出した後、前記類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、前記第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、前記第一関連語、前記第二関連語及び前記第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、
前記本ベストスコアテーブルを基に、前記クライアントへ送信される本クラスタを作成して前記本クラスタディレクトリに格納する本クラスタ生成処理部と
を備え、
前記リアルタイム処理部は、
前記クライアントから得られる前記現在位置情報を受けて対応する地名を前記ＧＰＳ地名マスタから取得して、前記本クラスタディレクトリから前記地名に対応する前記本クラスタを取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部と
を備えることを特徴とする情報検索システム。
【請求項２】
前記本クラスタ生成処理部は、
前記本ベストスコアテーブルの一のレコード中の前記第二関連語が前記第一関連語に存在するレコードと、前記一のレコード中の前記第三関連語が前記第一関連語に存在するレコードとを前記一のレコードと共に同一のクラスタ番号を付与し、
同一の前記クラスタ番号が付与された三レコードの一のレコードの前記第二関連語及び前記第三関連語のいずれも他のレコードの前記第一関連語と一致しない前記一のレコードを削除し、
前記第一関連語が一致する複数のレコードのうち前記類似度が最高値を示すレコード以外のレコードを削除し、
前記第一関連語が所定のストップワードと一致するレコードを削除し、
前記第二関連語と前記第三関連語が上位クラスタの各レコードの前記第一関連語の組と一致するレコードであり、前記レコードが当該クラスタ唯一である場合、或は前記レコードが属する同一クラスタの全てのレコードの前記第一関連語の文字列長が所定長以下である場合、前記レコードに前記上位クラスタのクラスタ番号を付与することによって前記本クラスタを作成することを特徴とする、請求項１記載の情報検索システム。
【請求項３】
予め情報検索エンジンから所定の情報を取得した後に所定の加工を行い、ＧＰＳ受信部を内蔵するクライアントから現在位置情報を受信して、前記クライアントに前記現在位置情報に対応する前記加工した情報を提供する情報検索装置であって、
前記情報検索エンジンから受信した前記所定の情報を加工するバッチ処理部と、
前記バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、
前記不揮発性データ記憶部に蓄積された前記加工された情報を前記クライアントに送信するリアルタイム処理部と
を備え、
前記不揮発性データ記憶部は、
前記クライアントから得られる前記現在位置情報に対応する地名が格納されているＧＰＳ地名マスタと、
前記情報検索エンジンから得られる、前記地名とその関連語群が格納される地名関連語リストと、
前記地名と前記関連語群から作成される前記地名と各々の関連語の組よりなる複数の検索クエリをそれぞれ前記情報検索エンジンにて検索した結果が記録される検索結果ファイル群が格納される検索結果ファイルディレクトリと、
前記検索結果ファイル群に記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、
前記検索結果ファイル毎に作成され、前記ネットワーク上の文書群に含まれる前記関連語を中心とする前後の単語が前記ネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、
前記ＷＡＭファイル中に出現する前記関連語の関係が記されている関連語出現テーブルと、
前記ＷＡＭファイル中に出現する前記関連語の類似度が記されている本ベストスコアテーブルと、
前記本ベストスコアテーブルから生成され、前記クライアントへ送信される本クラスタが格納される本クラスタディレクトリと
を備え、
前記バッチ処理部は、
前記ＧＰＳ地名マスタに含まれている前記地名を前記検索エンジンに与えて前記地名関連語リストを取得し、前記地名関連語リストから前記地名と前記関連語の組を前記検索エンジンに与えて前記検索結果ファイルを前記検索結果ファイルディレクトリに格納すると共に、前記検索結果ファイルに記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書を前記キャッシュファイルディレクトリに格納するデータ取得処理部と、
前記ネットワーク上の文書に含まれる前記関連語を中心とする前後の単語を取り出して前記ネットワーク上の文書のファイル名と共に前記ＷＡＭファイルに書き出し、前記ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、
同一の地名に係る複数の前記ＷＡＭファイルに基づいて、前記ネットワーク上の文書群と前記関連語の有無の関係を前記関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、
前記関連語出現テーブルを基に全ての前記各関連語同士の類似度を算出した後、前記類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、前記第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、前記第一関連語、前記第二関連語及び前記第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、
前記本ベストスコアテーブルを基に、前記クライアントへ送信される本クラスタを作成して前記本クラスタディレクトリに格納する本クラスタ生成処理部と
を備え、
前記リアルタイム処理部は、
前記クライアントから得られる前記現在位置情報を受けて対応する地名を前記ＧＰＳ地名マスタから取得して、前記本クラスタディレクトリから前記地名に対応する前記本クラスタを取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部と
を備えることを特徴とする情報検索装置。
【請求項４】
前記本クラスタ生成処理部は、
前記本ベストスコアテーブルの一のレコード中の前記第二関連語が前記第一関連語に存在するレコードと、前記一のレコード中の前記第三関連語が前記第一関連語に存在するレコードとを前記一のレコードと共に同一のクラスタ番号を付与し、
同一の前記クラスタ番号が付与された三レコードの一のレコードの前記第二関連語及び前記第三関連語のいずれも他のレコードの前記第一関連語と一致しない前記一のレコードを削除し、
前記第一関連語が一致する複数のレコードのうち前記類似度が最高値を示すレコード以外のレコードを削除し、
前記第一関連語が所定のストップワードと一致するレコードを削除し、
前記第二関連語と前記第三関連語が上位クラスタの各レコードの前記第一関連語の組と一致するレコードであり、前記レコードが当該クラスタ唯一である場合、或は前記レコードが属する同一クラスタの全てのレコードの前記第一関連語の文字列長が所定長以下である場合、前記レコードに前記上位クラスタのクラスタ番号を付与することによって前記本クラスタを作成することを特徴とする、請求項３記載の情報検索装置。
【請求項５】
クライアントと、前記クライアントに情報を提供する情報検索サーバと、前記情報検索サーバの要求にしたがって所定の情報を出力する検索エンジンとよりなる情報検索システムであって、
前記クライアントは、
ユーザの操作によって固有名詞である所定の検索クエリの入力を受け付ける入力部と、
所定の情報を表示する表示部と、
前記表示部を制御する表示制御部と、
前記入力部から得られる前記検索クエリを送信すると共に、所定の情報を受信して前記表示制御部に渡す入出力制御部と
を備え、
前記検索エンジンは、所定の単語が入力されると前記単語の関連語を出力するものであり、
前記情報検索サーバは、
前記情報検索エンジンから前記所定の情報を受信して加工するバッチ処理部と、
前記バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、
前記不揮発性データ記憶部に蓄積された前記加工された情報を前記クライアントに送信するリアルタイム処理部と
を備え、
前記不揮発性データ記憶部は、
固有名詞が格納されている固有名詞マスタと、
前記情報検索エンジンから得られる、前記入力部から前記入出力制御部を通じて得られる前記検索クエリに対応する関連語群が格納される固有名詞関連語リストと、
前記固有名詞と各々の関連語の組よりなる複数の検索クエリをそれぞれ前記情報検索エンジンにて検索した結果を記録する検索結果ファイル群が格納される検索結果ファイルディレクトリと、
前記検索結果ファイル群に記載されているＵＲＬから得られる、前記固有名詞と前記関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、
前記検索結果ファイル毎に作成され、前記ネットワーク上の文書群に含まれる前記関連語を中心とする前後の単語が前記ネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、
前記ＷＡＭファイル中に出現する前記関連語の関係が記されている関連語出現テーブルと、
前記ＷＡＭファイル中に出現する前記関連語の類似度が記されている本ベストスコアテーブルと、
前記本ベストスコアテーブルから生成され、前記クライアントへ送信される本クラスタが格納される本クラスタディレクトリと
を備え、
前記バッチ処理部は、
前記固有名詞マスタに含まれている前記固有名詞を前記検索エンジンに与えて前記固有名詞関連語リストを取得し、前記固有名詞関連語リストから前記固有名詞と前記関連語の組を前記検索エンジンに与えて前記検索結果ファイルを前記検索結果ファイルディレクトリに格納すると共に、前記検索結果ファイルに記載されているＵＲＬから得られる、前記固有名詞と前記関連語の組が含まれているネットワーク上の文書を前記キャッシュファイルディレクトリに格納するデータ取得処理部と、
前記ネットワーク上の文書に含まれる前記関連語を中心とする前後の単語を取り出して前記ネットワーク上の文書のファイル名と共に前記ＷＡＭファイルに書き出し、前記ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、
同一の固有名詞に係る複数の前記ＷＡＭファイルに基づいて、前記ネットワーク上の文書群と前記関連語の有無の関係を前記関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、
前記関連語出現テーブルを基に全ての前記各関連語同士の類似度を算出した後、前記類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、前記第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、前記第一関連語、前記第二関連語及び前記第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、
前記本ベストスコアテーブルを基に、前記クライアントへ送信される本クラスタを作成して前記本クラスタディレクトリに格納する本クラスタ生成処理部と
を備え、
前記リアルタイム処理部は、
前記クライアントから得られる前記固有名詞である前記検索クエリに対応する前記本クラスタを前記本クラスタディレクトリから取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部と
を備えることを特徴とする情報検索システム。
【請求項６】
前記本クラスタ生成処理部は、
前記本ベストスコアテーブルの一のレコード中の前記第二関連語が前記第一関連語に存在するレコードと、前記一のレコード中の前記第三関連語が前記第一関連語に存在するレコードとを前記一のレコードと共に同一のクラスタ番号を付与し、
同一の前記クラスタ番号が付与された三レコードの一のレコードの前記第二関連語及び前記第三関連語のいずれも他のレコードの前記第一関連語と一致しない前記一のレコードを削除し、
前記第一関連語が一致する複数のレコードのうち前記類似度が最高値を示すレコード以外のレコードを削除し、
前記第一関連語が所定のストップワードと一致するレコードを削除し、
前記第二関連語と前記第三関連語が上位クラスタの各レコードの前記第一関連語の組と一致するレコードであり、前記レコードが当該クラスタ唯一である場合、或は前記レコードが属する同一クラスタの全てのレコードの前記第一関連語の文字列長が所定長以下である場合、前記レコードに前記上位クラスタのクラスタ番号を付与することによって前記本クラスタを作成することを特徴とする、請求項５記載の情報検索システム。
【請求項１】
クライアントと、前記クライアントに情報を提供する情報検索サーバと、前記情報検索サーバの要求にしたがって所定の情報を出力する検索エンジンとよりなる情報検索システムであって、
前記クライアントは、
現在位置情報を取得するＧＰＳ受信部と、
所定の情報を表示する表示部と、
前記表示部を制御する表示制御部と、
前記ＧＰＳ受信部から得られる前記位置情報を送信すると共に、所定の情報を受信して前記表示制御部に渡す入出力制御部と
を備え、
前記検索エンジンは、所定の単語が入力されると前記単語の関連語を出力するものであり、
前記情報検索サーバは、
前記情報検索エンジンから前記所定の情報を受信して加工するバッチ処理部と、
前記バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、
前記不揮発性データ記憶部に蓄積された前記加工された情報を前記クライアントに送信するリアルタイム処理部と
を備え、
前記不揮発性データ記憶部は、
前記ＧＰＳ受信部から前記入出力制御部を通じて得られる前記現在位置情報に対応する地名が格納されているＧＰＳ地名マスタと、
前記情報検索エンジンから得られる、前記地名とその関連語群が格納される地名関連語リストと、
前記地名と前記関連語群から作成される前記地名と各々の関連語の組よりなる複数の検索クエリをそれぞれ前記情報検索エンジンにて検索した結果が記録される検索結果ファイル群が格納される検索結果ファイルディレクトリと、
前記検索結果ファイル群に記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、
前記検索結果ファイル毎に作成され、前記ネットワーク上の文書群に含まれる前記関連語を中心とする前後の単語が前記ネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、
前記ＷＡＭファイル中に出現する前記関連語の関係が記されている関連語出現テーブルと、
前記ＷＡＭファイル中に出現する前記関連語の類似度が記されている本ベストスコアテーブルと、
前記本ベストスコアテーブルから生成され、前記クライアントへ送信される本クラスタが格納される本クラスタディレクトリと
を備え、
前記バッチ処理部は、
前記ＧＰＳ地名マスタに含まれている前記地名を前記検索エンジンに与えて前記地名関連語リストを取得し、前記地名関連語リストから前記地名と前記関連語の組を前記検索エンジンに与えて前記検索結果ファイルを前記検索結果ファイルディレクトリに格納すると共に、前記検索結果ファイルに記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書を前記キャッシュファイルディレクトリに格納するデータ取得処理部と、
前記ネットワーク上の文書に含まれる前記関連語を中心とする前後の単語を取り出して前記ネットワーク上の文書のファイル名と共に前記ＷＡＭファイルに書き出し、前記ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、
同一の地名に係る複数の前記ＷＡＭファイルに基づいて、前記ネットワーク上の文書群と前記関連語の有無の関係を前記関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、
前記関連語出現テーブルを基に全ての前記各関連語同士の類似度を算出した後、前記類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、前記第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、前記第一関連語、前記第二関連語及び前記第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、
前記本ベストスコアテーブルを基に、前記クライアントへ送信される本クラスタを作成して前記本クラスタディレクトリに格納する本クラスタ生成処理部と
を備え、
前記リアルタイム処理部は、
前記クライアントから得られる前記現在位置情報を受けて対応する地名を前記ＧＰＳ地名マスタから取得して、前記本クラスタディレクトリから前記地名に対応する前記本クラスタを取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部と
を備えることを特徴とする情報検索システム。
【請求項２】
前記本クラスタ生成処理部は、
前記本ベストスコアテーブルの一のレコード中の前記第二関連語が前記第一関連語に存在するレコードと、前記一のレコード中の前記第三関連語が前記第一関連語に存在するレコードとを前記一のレコードと共に同一のクラスタ番号を付与し、
同一の前記クラスタ番号が付与された三レコードの一のレコードの前記第二関連語及び前記第三関連語のいずれも他のレコードの前記第一関連語と一致しない前記一のレコードを削除し、
前記第一関連語が一致する複数のレコードのうち前記類似度が最高値を示すレコード以外のレコードを削除し、
前記第一関連語が所定のストップワードと一致するレコードを削除し、
前記第二関連語と前記第三関連語が上位クラスタの各レコードの前記第一関連語の組と一致するレコードであり、前記レコードが当該クラスタ唯一である場合、或は前記レコードが属する同一クラスタの全てのレコードの前記第一関連語の文字列長が所定長以下である場合、前記レコードに前記上位クラスタのクラスタ番号を付与することによって前記本クラスタを作成することを特徴とする、請求項１記載の情報検索システム。
【請求項３】
予め情報検索エンジンから所定の情報を取得した後に所定の加工を行い、ＧＰＳ受信部を内蔵するクライアントから現在位置情報を受信して、前記クライアントに前記現在位置情報に対応する前記加工した情報を提供する情報検索装置であって、
前記情報検索エンジンから受信した前記所定の情報を加工するバッチ処理部と、
前記バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、
前記不揮発性データ記憶部に蓄積された前記加工された情報を前記クライアントに送信するリアルタイム処理部と
を備え、
前記不揮発性データ記憶部は、
前記クライアントから得られる前記現在位置情報に対応する地名が格納されているＧＰＳ地名マスタと、
前記情報検索エンジンから得られる、前記地名とその関連語群が格納される地名関連語リストと、
前記地名と前記関連語群から作成される前記地名と各々の関連語の組よりなる複数の検索クエリをそれぞれ前記情報検索エンジンにて検索した結果が記録される検索結果ファイル群が格納される検索結果ファイルディレクトリと、
前記検索結果ファイル群に記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、
前記検索結果ファイル毎に作成され、前記ネットワーク上の文書群に含まれる前記関連語を中心とする前後の単語が前記ネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、
前記ＷＡＭファイル中に出現する前記関連語の関係が記されている関連語出現テーブルと、
前記ＷＡＭファイル中に出現する前記関連語の類似度が記されている本ベストスコアテーブルと、
前記本ベストスコアテーブルから生成され、前記クライアントへ送信される本クラスタが格納される本クラスタディレクトリと
を備え、
前記バッチ処理部は、
前記ＧＰＳ地名マスタに含まれている前記地名を前記検索エンジンに与えて前記地名関連語リストを取得し、前記地名関連語リストから前記地名と前記関連語の組を前記検索エンジンに与えて前記検索結果ファイルを前記検索結果ファイルディレクトリに格納すると共に、前記検索結果ファイルに記載されているＵＲＬから得られる、前記地名と前記関連語の組が含まれているネットワーク上の文書を前記キャッシュファイルディレクトリに格納するデータ取得処理部と、
前記ネットワーク上の文書に含まれる前記関連語を中心とする前後の単語を取り出して前記ネットワーク上の文書のファイル名と共に前記ＷＡＭファイルに書き出し、前記ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、
同一の地名に係る複数の前記ＷＡＭファイルに基づいて、前記ネットワーク上の文書群と前記関連語の有無の関係を前記関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、
前記関連語出現テーブルを基に全ての前記各関連語同士の類似度を算出した後、前記類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、前記第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、前記第一関連語、前記第二関連語及び前記第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、
前記本ベストスコアテーブルを基に、前記クライアントへ送信される本クラスタを作成して前記本クラスタディレクトリに格納する本クラスタ生成処理部と
を備え、
前記リアルタイム処理部は、
前記クライアントから得られる前記現在位置情報を受けて対応する地名を前記ＧＰＳ地名マスタから取得して、前記本クラスタディレクトリから前記地名に対応する前記本クラスタを取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部と
を備えることを特徴とする情報検索装置。
【請求項４】
前記本クラスタ生成処理部は、
前記本ベストスコアテーブルの一のレコード中の前記第二関連語が前記第一関連語に存在するレコードと、前記一のレコード中の前記第三関連語が前記第一関連語に存在するレコードとを前記一のレコードと共に同一のクラスタ番号を付与し、
同一の前記クラスタ番号が付与された三レコードの一のレコードの前記第二関連語及び前記第三関連語のいずれも他のレコードの前記第一関連語と一致しない前記一のレコードを削除し、
前記第一関連語が一致する複数のレコードのうち前記類似度が最高値を示すレコード以外のレコードを削除し、
前記第一関連語が所定のストップワードと一致するレコードを削除し、
前記第二関連語と前記第三関連語が上位クラスタの各レコードの前記第一関連語の組と一致するレコードであり、前記レコードが当該クラスタ唯一である場合、或は前記レコードが属する同一クラスタの全てのレコードの前記第一関連語の文字列長が所定長以下である場合、前記レコードに前記上位クラスタのクラスタ番号を付与することによって前記本クラスタを作成することを特徴とする、請求項３記載の情報検索装置。
【請求項５】
クライアントと、前記クライアントに情報を提供する情報検索サーバと、前記情報検索サーバの要求にしたがって所定の情報を出力する検索エンジンとよりなる情報検索システムであって、
前記クライアントは、
ユーザの操作によって固有名詞である所定の検索クエリの入力を受け付ける入力部と、
所定の情報を表示する表示部と、
前記表示部を制御する表示制御部と、
前記入力部から得られる前記検索クエリを送信すると共に、所定の情報を受信して前記表示制御部に渡す入出力制御部と
を備え、
前記検索エンジンは、所定の単語が入力されると前記単語の関連語を出力するものであり、
前記情報検索サーバは、
前記情報検索エンジンから前記所定の情報を受信して加工するバッチ処理部と、
前記バッチ処理部で加工された情報を蓄積する不揮発性データ記憶部と、
前記不揮発性データ記憶部に蓄積された前記加工された情報を前記クライアントに送信するリアルタイム処理部と
を備え、
前記不揮発性データ記憶部は、
固有名詞が格納されている固有名詞マスタと、
前記情報検索エンジンから得られる、前記入力部から前記入出力制御部を通じて得られる前記検索クエリに対応する関連語群が格納される固有名詞関連語リストと、
前記固有名詞と各々の関連語の組よりなる複数の検索クエリをそれぞれ前記情報検索エンジンにて検索した結果を記録する検索結果ファイル群が格納される検索結果ファイルディレクトリと、
前記検索結果ファイル群に記載されているＵＲＬから得られる、前記固有名詞と前記関連語の組が含まれているネットワーク上の文書が格納されるキャッシュファイルディレクトリと、
前記検索結果ファイル毎に作成され、前記ネットワーク上の文書群に含まれる前記関連語を中心とする前後の単語が前記ネットワーク上の文書のファイル名と共に記憶されるＷＡＭファイルを格納するＷＡＭファイルディレクトリと、
前記ＷＡＭファイル中に出現する前記関連語の関係が記されている関連語出現テーブルと、
前記ＷＡＭファイル中に出現する前記関連語の類似度が記されている本ベストスコアテーブルと、
前記本ベストスコアテーブルから生成され、前記クライアントへ送信される本クラスタが格納される本クラスタディレクトリと
を備え、
前記バッチ処理部は、
前記固有名詞マスタに含まれている前記固有名詞を前記検索エンジンに与えて前記固有名詞関連語リストを取得し、前記固有名詞関連語リストから前記固有名詞と前記関連語の組を前記検索エンジンに与えて前記検索結果ファイルを前記検索結果ファイルディレクトリに格納すると共に、前記検索結果ファイルに記載されているＵＲＬから得られる、前記固有名詞と前記関連語の組が含まれているネットワーク上の文書を前記キャッシュファイルディレクトリに格納するデータ取得処理部と、
前記ネットワーク上の文書に含まれる前記関連語を中心とする前後の単語を取り出して前記ネットワーク上の文書のファイル名と共に前記ＷＡＭファイルに書き出し、前記ＷＡＭファイルディレクトリに格納するＷＡＭファイル生成処理部と、
同一の固有名詞に係る複数の前記ＷＡＭファイルに基づいて、前記ネットワーク上の文書群と前記関連語の有無の関係を前記関連語出現テーブルに書き出す関連語出現テーブル生成処理部と、
前記関連語出現テーブルを基に全ての前記各関連語同士の類似度を算出した後、前記類似度にてソートし、基準となる第一関連語に最も類似度が高い第二関連語のレコードと、前記第二関連語の次に類似度が高い第三関連語のレコードとを抜粋して、前記第一関連語、前記第二関連語及び前記第三関連語を夫々フィールドに持つ一レコードを列挙した本ベストスコアテーブルを生成するベストスコアテーブル生成処理部と、
前記本ベストスコアテーブルを基に、前記クライアントへ送信される本クラスタを作成して前記本クラスタディレクトリに格納する本クラスタ生成処理部と
を備え、
前記リアルタイム処理部は、
前記クライアントから得られる前記固有名詞である前記検索クエリに対応する前記本クラスタを前記本クラスタディレクトリから取得した後、所定の文書形式に変換してクライアントに送信する本クラスタ送信部と
を備えることを特徴とする情報検索システム。
【請求項６】
前記本クラスタ生成処理部は、
前記本ベストスコアテーブルの一のレコード中の前記第二関連語が前記第一関連語に存在するレコードと、前記一のレコード中の前記第三関連語が前記第一関連語に存在するレコードとを前記一のレコードと共に同一のクラスタ番号を付与し、
同一の前記クラスタ番号が付与された三レコードの一のレコードの前記第二関連語及び前記第三関連語のいずれも他のレコードの前記第一関連語と一致しない前記一のレコードを削除し、
前記第一関連語が一致する複数のレコードのうち前記類似度が最高値を示すレコード以外のレコードを削除し、
前記第一関連語が所定のストップワードと一致するレコードを削除し、
前記第二関連語と前記第三関連語が上位クラスタの各レコードの前記第一関連語の組と一致するレコードであり、前記レコードが当該クラスタ唯一である場合、或は前記レコードが属する同一クラスタの全てのレコードの前記第一関連語の文字列長が所定長以下である場合、前記レコードに前記上位クラスタのクラスタ番号を付与することによって前記本クラスタを作成することを特徴とする、請求項５記載の情報検索システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図１１】
【公開番号】特開２００９−１８７３０５（Ｐ２００９−１８７３０５Ａ）
【公開日】平成２１年８月２０日（２００９．８．２０）
【国際特許分類】
【出願番号】特願２００８−２６８６４（Ｐ２００８−２６８６４）
【出願日】平成２０年２月６日（２００８．２．６）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１９年度、独立行政法人科学技術振興機構委託研究、「平成１９年度地域イノベーション創出総合支援事業 シーズ発掘試験」、産業活力特別措置法第３０条の適用を受ける特許出願
【出願人】（５０４１４５３６４）国立大学法人群馬大学 (352)
【Ｆターム（参考）】
【公開日】平成２１年８月２０日（２００９．８．２０）
【国際特許分類】
【出願日】平成２０年２月６日（２００８．２．６）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１９年度、独立行政法人科学技術振興機構委託研究、「平成１９年度地域イノベーション創出総合支援事業 シーズ発掘試験」、産業活力特別措置法第３０条の適用を受ける特許出願
【出願人】（５０４１４５３６４）国立大学法人群馬大学 (352)
【Ｆターム（参考）】
[ Back to top ]