JP5068002B2 - ネットワークを介した位置情報の提供 - Google Patents

Description

本発明は、ネットワークを介して地理的な位置を表す情報を提供する技術に関するものである。

近年、インターネットの普及により、Ｗｅｂサーバ等を用いたシステムによって多種多様な情報が提供されている。また、提供される情報を閲覧するための装置として、提供された情報が示す地理的な位置（例えば、店の場所等）を地図で表す装置が提案されている（例えば、特許文献１、２参照）。

特開平７−２８８１３号公報 特開２００３−６７３７９号公報

ところで、このような情報を提供するシステムでは、ユーザがテキストや画像等を含む記事（情報）を登録すれば、他の多数のユーザがその記事を閲覧することができる。この際、頻繁に新しい情報が登録されていれば、他のユーザは、頻繁に新しい情報を閲覧することが可能となる。ところが、情報を登録するためのユーザの負担が大きい場合があった。特に、地理的な位置を表す情報を準備することは、情報を登録するユーザにとって大きな負担となっていた。

本発明は、上述した従来の課題を解決するためになされたものであり、地理的な位置を表す情報を提供するためのユーザの負担を軽減することができる技術を提供することを目的とする。

上述の課題の少なくとも一部を解決するために、本発明による第１の態様に係るサーバは、ネットワークを介して情報を提供するサーバであって、前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する投稿情報受信部と、前記投稿情報を含む情報である提供情報を生成する提供情報生成部と、前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する位置文字列抽出部と、前記抽出された位置文字列に関連付けられた地理的位置を含むとともに地理的な範囲が定められた地図画像に関連する地図画像情報を生成する地図画像情報生成部と、前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記地図画像情報とを、前記第２クライアント装置へ送信することが可能な情報送信部と、を備える。

このサーバによれば、ユーザが地理的位置を表す文字列を含む記事をサーバに登録すれば、サーバによって、その地理的位置を含む地図画像に関連する地図画像情報が提供されるので、地理的な位置を表す情報を提供するためのユーザの負担を軽減することができる。

上記サーバにおいて、前記情報送信部は、前記第２クライアント装置から、前記提供情報と前記地図画像情報とのうちの一方のみを指定する要求を受けた場合には、前記提供情報と前記地図画像情報との代わりに、前記指定された情報のみを前記第２クライアント装置へ送信することとしてもよい。

この構成によれば、サーバは、第２クライアント装置の要求に応じた適切な情報を送信することが可能となる。

上記各サーバにおいて、前記投稿情報受信部が前記投稿情報を受信する度に、前記位置文字列抽出部は、前記投稿情報受信部が受信した新たな投稿情報のみを対象として前記抽出処理を実行し、前記提供情報生成部は、前記新たな投稿情報を前記提供情報に追加することによって、前記抽出処理済みの提供情報を生成することとしてもよい。

この構成によれば、投稿された複数の投稿情報に対して、投稿される度に逐次、位置文字列抽出部による抽出処理が実行されるので、複数の投稿情報を含む提供情報を提供する場合でも、各投稿情報に対して抽出処理を行うためのサーバへの負担が短時間に集中することを抑制することができる。

上記各サーバにおいて、前記地図画像情報生成部が生成する前記地図画像情報は地図画像であってもよい。

この構成によれば、サーバによって、その地理的位置を含む地図画像が提供されるので、地理的な位置を表す情報を提供するためのユーザの負担を軽減することができる。

上記サーバにおいて、前記提供情報生成部は、複数種類の提供情報を生成することが可能であるとともに、前記投稿情報を、前記第１クライアント装置からの指示で指定された種類の提供情報に追加し、前記地図画像情報生成部は、地理的な範囲が同じであるとともに表示される内容が互いに異なる複数種類の地図画像を生成することが可能であるとともに、前記地図画像の内容の種類を、前記投稿情報が追加される提供情報の種類に応じて決定してもよい。

この構成によれば、サーバによって提供される地図画像の内容を、提供情報の内容の種類に適したものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

なお、この構成においては、前記情報送信部は、前記複数種類の提供情報の中から、前記第２クライアント装置からの指示で指定された種類の提供情報である指定提供情報と、前記指定提供情報に含まれる投稿情報に応じて生成された地図画像とを、前記第２クライアント装置へ送信することが好ましい。

上記各サーバにおいて、前記地図画像情報生成部は、地理的な範囲が同じであるとともに表示される内容が互いに異なる複数種類の地図画像を生成することが可能であり、前記サーバは、さらに、前記テキストの中から、前記地図画像の種類のいずれかに関連付けられた文字列である地図種文字列を抽出する地図種文字列抽出部を備え、前記地図画像情報生成部は、生成する地図画像の内容の種類を、前記抽出された地図種文字列に基づいて決定してもよい。

この構成によれば、サーバによって提供される地図画像の内容を、テキストの内容に適したものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

上記各サーバにおいて、前記地図画像情報生成部は、地理的な範囲の大きさが互いに異なる複数種類の地図画像を生成することが可能であり、前記サーバは、さらに、前記テキストの中から、地理的な範囲の大きさに関連付けられた文字列である範囲文字列を抽出する範囲文字列抽出部を備え、前記地図画像情報生成部は、生成する地図画像が表す地理的な範囲の大きさを、前記抽出された範囲文字列に基づいて決定してもよい。

この構成によれば、サーバによって提供される地図画像が表す範囲の大きさを、テキストの内容に適したものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

上記各サーバにおいて、前記地図画像情報生成部は、地理的な範囲が同じであるとともに時期範囲が互いに異なる複数種類の地図画像を生成することが可能であり、さらに、生成する地図画像の時期範囲の種類を、前記投稿情報に関する時間に基づいて決定してもよい。

この構成によれば、サーバによって提供される地図画像の時期範囲を、記事に関する時間に適したものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

上記各サーバにおいて、前記地図画像情報生成部は、１つの前記投稿情報に含まれる前記テキストから複数の位置文字列が抽出された場合には、前記複数の位置文字列のそれぞれが表す地理的位置を通る経路を表す地図画像を生成してもよい。

この構成によれば、サーバによって提供される地図画像の内容を、複数の位置を通る経路を表すものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

上記各サーバにおいて、さらに、前記第２クライアント装置から、地理的な位置を表す情報である追加位置情報を受信する追加位置情報受信部を備え、前記地図画像情報生成部は、前記追加位置情報が表す地理的位置と、前記抽出された位置文字列に関連付けられた地理的位置と、を通る経路を表す地図画像を生成してもよい。

この構成によれば、サーバによって提供される地図画像の内容を、追加位置情報が表す位置と、記事に含まれる位置文字列に関する位置と、を通る経路を表すものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

上記各サーバにおいて、前記第１クライアント装置からの要求に応じて、前記投稿情報受信部は、前記投稿情報のうちの前記テキストを含む少なくとも一部の情報を受信するとともに、前記地図画像情報生成部は、前記テキストに基づいて前記地図画像を生成し、さらに、前記情報送信部は、前記投稿情報の修正が可能な状態で、前記地図画像を前記第１クライアント装置へ送信してもよい。

この構成によれば、ユーザは、サーバによって提供された地図画像を確認して投稿情報を修正することができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

また、本発明による第２の態様に係るサーバは、ネットワークを介して情報を提供するサーバであって、前記ネットワークに接続された第１クライアント装置の要求に応じて前記サーバへ送信された地理的な位置を表す位置情報を受信する位置情報受信部と、前記位置情報に基づいて、前記位置情報が表す地理的位置に関連付けられた文字列である位置表示文字列を生成する位置表示文字列生成部と、前記位置表示文字列を前記第１クライアント装置へ送信する位置表示文字列送信部と、前記第１クライアント装置から、前記位置表示文字列を含むテキストを含む情報である投稿情報を受信する投稿情報受信部と、前記投稿情報を含む情報である提供情報を生成する提供情報生成部と、前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報を前記第２クライアント装置へ送信する提供情報送信部と、を備える。

このサーバによれば、位置情報が表す地理的位置に関する文字列がサーバによって提供されるので、地理的な位置を表す情報を提供するためのユーザの負担を軽減することができる。

上記サーバにおいて、前記位置情報受信部は、前記第１クライアント装置から前記位置情報を受信してもよい。

この構成によれば、サーバによって提供される文字列を、ユーザが記事を投稿するために用いる第１クライアント装置から送られた位置情報に適したものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

上記各サーバにおいて、さらに、前記地理的な位置の指定に用いられる指定用地図画像を生成する指定用地図画像生成部と、前記指定用地図画像を前記ネットワークを介して送信する指定用地図画像送信部と、を備え、前記位置情報受信部が前記位置情報を受信する前に、前記指定用地図画像生成部が前記指定用地図画像を生成するとともに、前記指定用地図画像送信部が前記生成された指定用地図画像を前記第１クライアント装置へ送信し、前記位置情報受信部は、前記送信された指定用地図画像上の位置を表す位置情報を前記第１クライアント装置から受信してもよい。

この構成によれば、サーバによって提供される文字列を、第１クライアント装置に予め送信された指定用地図画像上における位置に適したものとすることができるので、地理的な位置を表す情報を提供するためのユーザの負担を大幅に軽減することができる。

なお、上述した第１の態様と第２の態様とにおいて、第１クライアント装置と第２クライアント装置とは、同じクライアント装置であってもよい。

なお、本発明は種々の形態で実現することが可能であり、例えば、情報提供方法および情報提供装置、それらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体等の形態で実現することができる。

次に、この発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．第１実施例：
Ｂ．第２実施例：
Ｃ．第３実施例：
Ｄ．第４実施例：
Ｅ．第５実施例：
Ｆ．第６実施例：
Ｇ．第７実施例：
Ｈ．第８実施例：
Ｉ．第９実施例：
Ｊ．第１０実施例：
Ｋ．変形例：

Ａ．第１実施例：
図１は、本発明の一実施例としてのネットワークシステム３００の構成を示す説明図である。このネットワークシステム３００は、インターネットＩＮＥＴを介して接続された、２つのクライアントコンピュータ１００ａ、１００ｂと、Ｗｅｂサーバ２００と、を有している。

各クライアントコンピュータ１００ａ、１００ｂでは、Ｗｅｂブラウザ（以下、単に「ブラウザ」とも呼ぶ）が動作している。Ｗｅｂブラウザは、Ｗｅｂサーバ２００からＷｅｂページを取得し、モニタ（図示省略）にＷｅｂページを表示する。ユーザは、Ｗｅｂブラウザを操作することによって、Ｗｅｂサーバ２００に対して種々の指示を行うことができる。

Ｗｅｂサーバ２００は、データ処理部２１０と、通信部２５０と、日時を計測するタイマ２６０と、種々のデータを格納するデータ格納部２７０と、を備えている。データ処理部２１０は、クライアントコンピュータ１００ａ、１００ｂからの要求に応じてＷｅｂページの更新と送信とを行う。この際、データ処理部２１０は、通信部２５０を介してインターネットＩＮＥＴとのデータのやり取りを行う。データ格納部２７０は、Ｗｅｂページを表すＷｅｂページデータと、Ｗｅｂページの更新に用いる種々のデータとを格納する。データ格納部２７０としては、ＨＤＤやＲＡＭ等の種々のメモリを用いることができる。なお、第１実施例では、Ｗｅｂページデータは、ＨＴＭＬ（Hyper Text Markup Language）で記述されている。ただし、Ｗｅｂページデータの形式としては、他の任意の形式（例えば、Ｊａｖａ（Sun Microsystems社の登録商標））を採用してもよい。

図１には、データ処理部２１０の内部構成が示されている。第１実施例のデータ処理部２１０は、Ｗｅｂデータ受信部２１２と、Ｗｅｂデータ送信部２１４と、Ｗｅｂデータ生成部２１６と、構文解析部２１８と、位置データ管理部２２０と、地図データ管理部２２２と、を備えている。データ処理部２１０はＣＰＵとメモリとを有しており、コンピュータプログラムを実行することによって各構成要素の機能を実現する。各構成要素の機能の詳細については後述する。

データ処理部２１０が実行するコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に記録された形態で供給され得る。このような記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等の、コンピュータが読み取り可能な種々の媒体を利用できる。なお、データ処理部２１０の機能の一部、または、全部をハードウェアによって実現してもよい。

図２は、Ｗｅｂサーバ２００が提供するＷｅｂページの一例を示す説明図である。このＷｅｂページは、カレンダ領域ＣＬと、年月指定領域ＹＭＡと、カテゴリ指定領域ＣＡと、記事表示領域ＲＡと、を有している。記事表示領域ＲＡには、テキスト（図中では破線で示されている）を含む複数の記事が表示されている。これら複数の記事は、インターネットＩＮＥＴを介して投稿されたものである。各記事の上部には、その記事が投稿された日付が表されている。複数の記事は記事表示領域ＲＡ内に時系列の新しい順に提示されている。

また、各記事の下部には、その記事の投稿時刻と、その記事に対するコメントへのリンクと、その記事に関連するＷｅｂページへのリンク（「トラックバック」とも呼ばれる）と、が示されている。Ｗｅｂページの閲覧者が「コメント」を操作すると、その記事に関連するコメントが表示され、「トラックバック」を操作するとその記事に関連するＷｅｂページへのリンクの一覧が表示される（図示省略）。「コメント」と「トラックバック」とは、Ｗｅｂページの閲覧者が自由に追加（投稿）することができる。「コメント」としては、上述の記事と同様に、テキストを含む情報（記事）を投稿することができる。また、括弧内の数字は、それぞれ、コメントの数と、トラックバックの数とを示している。なお、「リンク」は、ＨＴＭＬでは「ハイパーリンク」とも呼ばれ、ユーザはリンクを操作することによって、リンク先の情報を閲覧することが可能である。

また、カレンダ領域ＣＬには、１箇月分のカレンダが表示されている。日付を操作すると、その日に投稿された記事が記事表示領域ＲＡに表示される。また、年月指定領域ＹＭＡを操作すれば、指定された年と月とのカレンダがカレンダ領域ＣＬに表示される。また、第１実施例では、記事が複数種類のカテゴリに分類されている。カテゴリ指定領域ＣＡには、記事を分類する３つのカテゴリ（「買い物」「グルメ」「映画」）が表示されている。ユーザが、カテゴリ指定領域ＣＡに提示されたカテゴリの１つを操作すると、記事表示領域ＲＡには、指定されたカテゴリの記事が表示される。なお、カテゴリの総数としては、３に限らず任意の数を採用することができる。

図３は、記事を投稿する処理の手順を示すフローチャートである。図３には、クライアントコンピュータ１００ａから記事を投稿する場合が示されている。ステップＳ１００では、ユーザが記事を入力する。この入力は、Ｗｅｂブラウザが表示する入力画面を用いて行われる。

図４は、入力画面の一例を示す説明図である。この入力画面ＩＳは、図２のＷｅｂページと同様に、Ｗｅｂサーバ２００によって提供されるＷｅｂページである。この入力画面ＩＳは、カテゴリメニューＣＭと、タイトルフィールドＴＦと、本文フィールドＢＦと、登録ボタンＲＢと、を有している。ユーザは、カテゴリメニューＣＭを操作することによって、記事を投稿するためのカテゴリを指定することができる。さらに、ユーザは、タイトルフィールドＴＦにタイトルを表すテキスト（以下「タイトルテキスト」と呼ぶ）を入力し、本文フィールドＢＦに本文を表すテキスト（以下「本文テキスト」と呼ぶ）を入力することができる。

ユーザが、登録ボタンＲＢを操作すると、入力画面ＩＳに入力された各情報を含む記事データが、クライアントコンピュータ１００ａからＷｅｂサーバ２００へ送信される（図３：ステップＳ１１０）。Ｗｅｂサーバ２００では、受信した記事を追加したＷｅｂページが、以下の手順（ステップＳ１２０〜Ｓ１５０）に従って作成される。

図５は、記事を追加する処理の概要を示す説明図である。Ｗｅｂサーバ２００（図１）では、まず、Ｗｅｂデータ受信部２１２が記事データを受信する。次に、ステップＳ１２０（図３）で、構文解析部２１８が、本文テキストの中から位置文字列を抽出する。図５には、位置文字列が登録された位置データベースＰＤＢの一例が示されている。位置データベースには、種々の文字列と、地理的な位置を表す座標（図５の例では、緯度と経度）と、が関連付けられて登録されている。このように、位置文字列とは、地理的位置に関連付けられた文字列を意味している。このような位置データベースＰＤＢは、Ｗｅｂサーバ２００のデータ格納部２７０に格納されている。図５の例では、構文解析部２１８は、本文テキストから「Ｂ駅」という位置文字列を抽出している。なお、位置文字列としては、建物の名前に限らず、行政区域の名前（例えば、市名や町名）や店舗の名前等、地理的な位置に関連のある種々の文字列を採用することができる。

次のステップＳ１３０では、位置データ管理部２２０が、抽出された位置文字列に関連付けられた緯度と経度とを位置データベースＰＤＢを用いて取得する。次のステップＳ１４０では、Ｗｅｂデータ生成部２１６が、Ｗｅｂページデータの更新を行う。この際、本文テキストと、タイトルテキストと、緯度と経度とを表すデータ（以下「緯度/経度データ」とも呼ぶ）と、タイマ２６０から得られる記事データの受信日時と、が用いられる（詳細は後述）。次のステップＳ１５０では、Ｗｅｂデータ生成部２１６は、生成した更新済のＷｅｂページデータをデータ格納部２７０に格納する。なお、データ格納部２７０には、各カテゴリ毎にＷｅｂページデータが格納されている。Ｗｅｂデータ生成部２１６は、指定されたカテゴリのＷｅｂページデータに、記事を追加する。

図６は、生成されたＷｅｂページの一例を示す説明図である。記事表示領域ＲＡには、投稿された最新の記事（最も上の記事）を含む複数の記事が表示されている。また、投稿された記事の下部には、地図ボタンＭＢが表示されている。この地図ボタンＭＢは、地図画像へのリンクを示している。このリンク先を表すデータ（以下「リンク先データ」と呼ぶ。例えばＵＲＬ（Uniform Resource Locator））は、上述した「緯度/経度データ」を含んでいる。このリンク先の地図画像は、Ｗｅｂサーバ２００によって提供される（詳細は後述）。なお、図３に示す処理は、記事が投稿される度に実行される。また、地図ボタンＭＢは、記事毎に設けられる。ただし、位置文字列が抽出されなかった記事に対しては、地図ボタンＭＢは設けられない。

図７は、このような更新されたＷｅｂページを閲覧する処理の手順を示すフローチャートである。図７には、クライアントコンピュータ１００ｂ（図１）でＷｅｂページを閲覧する場合が示されている。ステップＳ２００では、クライアントコンピュータ１００ｂがＷｅｂサーバ２００へＷｅｂページの閲覧要求を送信する。このような閲覧要求は、例えば、クライアントコンピュータ１００ｂで動作しているブラウザにおいて、ユーザが所定のＵＲＬを入力した場合や、ユーザがＷｅｂページへのリンクを操作した場合に、送信される。

次のステップＳ２１０では、Ｗｅｂサーバ２００において、Ｗｅｂデータ受信部２１２が閲覧要求を受信し、Ｗｅｂデータ送信部２１４が、閲覧要求で指定されたＷｅｂページデータをクライアントコンピュータ１００ｂに送信する。すると、クライアントコンピュータ１００ｂでは、ブラウザがＷｅｂページデータを受信し、その内容（図６）を表示する（ステップＳ２２０）。

次に、ユーザが地図ボタンＭＢ（図６）を操作すると、クライアントコンピュータ１００ｂは、Ｗｅｂサーバ２００から地図画像を取得する。図８は、クライアントコンピュータ１００ｂが、地図画像を取得する様子の概要を示す説明図である。ユーザが地図ボタンＭＢを操作すると、クライアントコンピュータ１００ｂがＷｅｂサーバ２００へ、「緯度/経度データ」を含むリンク先の閲覧要求（リンク先データ）を送信する（図７：ステップＳ２３０：Ｙｅｓ）。リンク先データは、Ｗｅｂサーバ２００のＷｅｂデータ受信部２１２によって受信される。

次に、地図データ管理部２２２が、リンク先データに含まれる「緯度/経度データ」を抽出するとともに、地図データベースＭＤＢを参照することによって、「緯度/経度データ」が表す位置を中心とする地図画像を表す地図画像データを生成する（図７：ステップＳ２４０）。ここで、地図データベースＭＤＢは、データ格納部２７０（図１）に格納されたデータベースであり、地図情報（道路や建物等の地物の位置と形状）が地理的な座標（例えば、緯度と経度）に関連付けられて登録されたデータベースである。なお、地図データ管理部２２２は、地図画像が表す地理的な範囲の大きさとして、所定の大きさ（例えば、500m×500m）を採用する。

以後、Ｗｅｂデータ生成部２１６が、地図画像を表示するためのＷｅｂページデータを生成し（図７：ステップＳ２５０）、Ｗｅｂデータ送信部２１４が、Ｗｅｂページデータをクライアントコンピュータ１００ｂへ送信する（ステップＳ２６０）。クライアントコンピュータ１００ｂでは、Ｗｅｂブラウザが、地図画像を含むＷｅｂページ（図８）を表示する（ステップＳ２７０）。

このように、第１実施例では、地理的な位置を表す文字列を含むテキストをサーバに登録すれば、テキストに加えて、その位置を含む地図画像もサーバによって提供される。その結果、情報を登録するユーザが地図画像を準備しなくても、閲覧者はその位置を含む地図画像を閲覧することができるので、情報を登録するユーザの負担を大幅に軽減することが可能となる。

なお、図５の例では、抽出された位置文字列が１つだけであったが、複数の位置文字列が抽出される場合もある。このような場合には、Ｗｅｂページに各位置文字列毎の地図ボタンを表示することとすればよい。この代わりに、地図データ管理部２２２が、全ての位置を含む１つの地図画像を生成することとしてもよい。また、地図ボタンを表示する代わりに、本文テキストにおける位置文字列自身が地図画像へのリンクを示すこととしてもよい。

また、第１実施例では、地図画像が表す地理的な範囲の大きさが予め決まっていたが、この代わりに、ユーザが範囲の大きさを指定することとしてもよい。この際、記事を投稿するユーザが大きさを指定することとしてもよく、また、記事を閲覧するユーザが大きさを指定することとしてもよい。この際、ユーザが、複数の大きさの候補の中から１つを指定することとしてもよい。例えば、ユーザが、複数の候補を表すプルダウンメニュー（図示省略）を操作することによって、候補の中の１つを指定することとしてもよい。

なお、地理的な範囲を定める形式としては、範囲の位置を表す座標と、範囲の形と大きさ（例えば、500m×500mの四角）とを用いる形式に限らず、任意の形式を採用することができる。例えば、地図画像の形と大きさとを予め定めておき、地図画像の中心位置を表す座標と、地図画像の縮尺と、を用いて地理的な範囲を定めてもよい。

なお、第１実施例では、投稿された記事に対して地図画像を提供することとしているが、さらに、コメントに対しても地図画像を提供することとしてもよい。この際、コメントに位置文字列が含まれている場合であっても、その位置文字列が基の記事にも含まれている場合には、そのコメントに関しては、その位置文字列に関する地図画像を提供しないこととしてもよい。こうすれば、基の記事を閲覧した後に、その記事に関連するコメントを閲覧しているユーザに、同じ地図画像を２重に提供することを防止することができる。

なお、本実施例では、位置データ管理部２２０と地図データ管理部２２２との全体が、本発明における「地図画像情報生成部」に相当する。また、地図データ管理部２２２が生成する地図画像が「地図画像情報」に相当する。

Ｂ．第２実施例：
図９は、第２実施例におけるＷｅｂページと地図画像との概要を示す説明図である。図５、図８に示す第１実施例との差異は、地図データ管理部２２２が、地図データベースＭＤＢを参照することによって、地理的な範囲が同じであるとともに、表示内容が互いに異なる複数種類の地図画像を生成することが可能である点である。他の構成は、図１に示す第１実施例と同じである。

図９に示す例では、地図データ管理部２２２は、店舗地図と、映画館地図と、飲食店地図と、の３種類の地図画像を生成することが可能である。店舗地図には店舗の位置と名称とが表示され、映画館地図には映画館の位置と名称とが表示され、飲食店地図には飲食店の位置と名称とが表示される。

また、図９には、Ｗｅｂデータ生成部２１６がＷｅｂページデータに記事を追加する様子が示されている。図５に示す第１実施例との差異は、地図ボタンＭＢに関連付けられたリンク先データが、地図種類を識別するデータ（以下「地図種類データ」と呼ぶ）を含む点である。なお、記事を追加する処理は、図３と同様の手順に従って行われる。

図９の右上には、地図種類と、Ｗｅｂページのカテゴリと、の対応関係を定めるテーブル（以下「カテゴリ地図種類テーブル」と呼ぶ）が示されている。図９の例では、「買い物」には「店舗地図」が関連付けられ、さらに、「映画」には「映画館地図」が、「グルメ」には「飲食店地図」が、それぞれ、関連付けられている。このカテゴリ地図種類テーブルは、Ｗｅｂサーバ２００のデータ格納部２７０に予め格納されている。Ｗｅｂデータ生成部２１６は、記事を登録すべきカテゴリに関連付けられた地図の種類を表す「地図種類データ」を「緯度/経度データ」とともに、地図ボタンＭＢのリンク先データに組み込む（図３：ステップＳ１４０）。図９の例では、カテゴリ「映画」に関連付けられた「映画館地図」を表す地図種類データが組み込まれる。

また、図９の下部には、地図データ管理部２２２が地図画像を生成する様子が示されている。この処理は、図７と同様の手順に従って行われる。Ｗｅｂページを閲覧するユーザが地図ボタンＭＢを操作すると、「緯度/経度データ」と「地図種類データ」とを含むリンク先データが、Ｗｅｂサーバ２００へ送信される（図７：ステップＳ２３０）。地図データ管理部２２２は、「緯度/経度データ」に基づいて地図画像が表す位置を決定し、「地図種類データ」に基づいて地図画像の種類を決定する。図９の例では、カテゴリ「映画」に関連付けられた映画館地図が生成される（図７：ステップＳ２４０）。

このように、第２実施例では、記事が登録されたＷｅｂページの種類に応じて、地図画像の種類が決定されるので、Ｗｅｂページの種類に適した地図画像を提供することが可能となる。なお、位置データベースＰＤＢの内容は、ユーザの指示に従って修正できることとしてもよい。

なお、飲食店地図において、特定の飲食店のみを表示することとしてもよい。例えば、広告料を提供した飲食店のみを飲食店地図に表示することとしてもよい。こうすれば、Ｗｅｂページの閲覧者に、広告料を提供した飲食店を積極的に紹介することができる。これは、他の種類の地図（例えば、店舗地図や映画館地図）についても同様である。

Ｃ．第３実施例：
図１０は、第３実施例におけるＷｅｂページと地図画像との概要を示す説明図である。図９に示す第２実施例との差異は、本文テキストの解析結果に基づいて地図画像の種類が決定される点である。他の構成は、図９に示す第２実施例と同じである。図１０の例では、地図データ管理部２２２は、図９に示す第２実施例と同様に、店舗地図と、映画館地図と、飲食店地図と、を生成することが可能である。

図１０には、Ｗｅｂデータ生成部２１６がＷｅｂページデータに記事を追加する様子が示されている。第３実施例では、構文解析部２１８（図１）は、本文テキストの中から、位置文字列に加えてカテゴリ文字列を抽出する。図１０の右上には、カテゴリ文字列が登録されたカテゴリ文字列データベースＣＤＢが示されている。このカテゴリ文字列データベースＣＤＢには、種々の文字列と地図種類とが関連付けられて登録されている。例えば、「鞄」には「店舗地図」が関連付けられ、さらに、「食事」には「飲食店地図」が、「映画」には「映画館地図」が、それぞれ、関連付けられている。このように、カテゴリ文字列とは、地図の内容の種類のいずれかに関連付けられた文字列を意味している。このようなカテゴリ文字列データベースＣＤＢは、Ｗｅｂサーバ２００のデータ格納部２７０に格納されている。図１０の例では、構文解析部２１８は、本文テキストから「食事」というカテゴリ文字列を抽出している。なお、カテゴリ文字列としては、地図の内容の種類に関連のある任意の文字列を採用することができる。

Ｗｅｂデータ生成部２１６は、抽出されたカテゴリ文字列に関連付けられた地図種類を識別する地図種類データを、「緯度/経度データ」とともに、リンク先データに組み込む（図３：ステップＳ１４０）。図１０の例では、「飲食店地図」を示す地図種類データが組み込まれる。

Ｗｅｂページを閲覧するユーザが地図ボタンＭＢを操作すると、「緯度/経度データ」と「地図種類データ」とを含むリンク先データが、Ｗｅｂサーバ２００へ送信される（図７：ステップＳ２３０）。地図データ管理部２２２は、「緯度/経度データ」に基づいて地図画像が表す位置を決定し、「地図種類データ」に基づいて地図画像の種類を決定する。図１０の例では、カテゴリ文字列「食事」に関連付けられた飲食店地図が生成される（図７：ステップＳ２４０）。

このように、第３実施例では、本文テキストから抽出されたカテゴリ文字列に応じて、地図画像の種類が決定されるので、記事の内容に適した地図画像を提供することが可能となる。なお、カテゴリ文字列データベースＣＤＢの内容は、ユーザの指示に従って修正できることとしてもよい。

なお、１つの本文テキストから複数のカテゴリ文字列が抽出される場合もある。この場合には、カテゴリ文字列の数を地図種類毎に算出し、カテゴリ文字列の数の最も多い地図種類を採用することとすればよい。また、本文テキストからカテゴリ文字列を抽出する際には、位置文字列を含む１文（１つの文章）のみからカテゴリ文字列を抽出することとしてもよい。なお、地図種類を決定する方法としては、本文テキストから抽出されたカテゴリ文字列に基づいて地図種類を決定する任意の方法を用いることができる。例えば、本文テキストにおける文字列の位置が最も前にあるカテゴリ文字列に関連付けられた地図種類を採用してもよく、最も後ろにあるカテゴリ文字列に関連付けられた地図種類を採用してもよい。

Ｄ．第４実施例：
図１１は、第４実施例におけるＷｅｂページと地図画像との概要を示す説明図である。図５、図８に示す第１実施例との差異は、本文テキストの解析結果に基づいて地図画像が表す範囲の大きさが決定される点である。他の構成は、図１に示す第１実施例と同じである。

図１１の例では、地図データ管理部２２２は、「10km×10km」と「100m×100m」と「40m×40m」と、の地理的な範囲の大きさが異なる３種類の地図画像を生成することが可能である。

また、図１１には、Ｗｅｂデータ生成部２１６がＷｅｂページデータに記事を追加する様子が示されている。第４実施例では、構文解析部２１８（図１）は、本文テキストの中から、位置文字列に加えて範囲文字列を抽出する。図１１右上には、範囲文字列が登録された範囲文字列データベースＲＤＢの一例が示されている。この範囲文字列データベースＲＤＢには、種々の文字列と範囲の大きさとが関連付けられて登録されている。例えば、「前」には「半径20m」が関連付けられ、さらに、「近く」には「半径50m」が関連付けられている。このように、範囲文字列とは、地理的な範囲の大きさに関連付けられた文字列を意味している。このような範囲文字列データベースＲＤＢは、Ｗｅｂサーバ２００のデータ格納部２７０に格納されている。図１１の例では、構文解析部２１８は、本文テキストから「前」という範囲文字列を抽出している。なお、範囲文字列としては、距離や範囲の大きさを表す任意の文字列を採用することができる。

Ｗｅｂデータ生成部２１６は、抽出された範囲文字列に関連付けられた範囲の大きさを識別する地図範囲データを、「緯度/経度データ」とともに、リンク先データに組み込む（図３：ステップＳ１４０）。図１１の例では、「半径20m」を示す地図範囲データが組み込まれる。なお、範囲文字列が抽出されなかった場合には、「範囲文字列無し」に関連付けられた「半径5km」を示す地図範囲データが採用される。

Ｗｅｂページを閲覧するユーザが地図ボタンＭＢを操作すると、「緯度/経度データ」と「地図範囲データ」とを含むリンク先データが、Ｗｅｂサーバ２００へ送信される（図７：ステップＳ２３０）。地図データ管理部２２２は、「緯度/経度データ」に基づいて地図画像が表す位置を決定し、「地図範囲データ」に基づいて地図画像の範囲の大きさを決定する。第４実施例では、地図画像の範囲の大きさは、利用可能な範囲の大きさの中の、「地図範囲データ」が示す範囲を含む最も狭い範囲の大きさに決定される。図１１の例では、範囲文字列「前」に関連付けられた「半径20m」を含む最も狭い範囲「40m×40m」を表す地図画像が生成される（図７：ステップＳ２４０）。

このように、第４実施例では、本文テキストから抽出された範囲文字列に応じて地図画像の範囲の大きさが決定されるので、記事の内容に適した範囲を表す地図画像を提供することができる。

なお、地図画像の範囲の大きさを決定する方法としては、抽出された範囲文字列に基づいて範囲の大きさを決定する任意の方法を採用することができる。例えば、範囲文字列と、生成される地図画像の範囲の大きさ（例えば「1km×1km」）と、を予め関連付けておき、抽出された範囲文字列に関連する範囲の大きさを、そのまま採用してもよい。なお、範囲文字列データベースＲＤＢの内容は、ユーザの指示に従って修正できることとしてもよい。

また、本文テキストから範囲文字列を抽出する際には、位置文字列を修飾する言葉（単語や熟語等）の中から範囲文字列を抽出することが好ましい。例えば、本文テキストでの言葉の並び順において、位置文字列に隣接する言葉の中から範囲文字列を抽出することとしてもよい。こうすれば、「...Ｂ駅近く...」のような文から、位置文字列「Ｂ駅」を修飾する範囲文字列「近く」を抽出することができる。また、位置文字列との間に所定の接続言葉が挟まれた言葉の中から範囲文字列を抽出することとしてもよい。所定の接続言葉としては、例えば、「の」を採用することができる。こうすれば、「...Ｂ駅の近く...」のような文から、位置文字列「Ｂ駅」を修飾する範囲文字列「近く」を抽出することができる。また、「の近く」のように位置文字列に隣接して使用されるとともに、複数の単語で構成される文字列を範囲文字列として採用してもよい。

また、範囲文字列としては、距離や範囲の大きさを直接に表す文字列に限らず、他の文字列を採用してもよい。例えば、移動距離に関する文字列を範囲文字列として用いてもよい。例えば、「ドライブ」や「車」といった文字列が本文テキストに含まれている場合には、投稿された記事は、比較的長い距離を移動したときの話題に関する可能性が高い。そこで、「ドライブ」「車」を、比較的広い大きさ（例えば、縮尺１／５０００や、1km×1km）に関連付けて用いることとしてもよい。一方、「散歩」や「徒歩」といった文字列が本文テキストに含まれている場合には、投稿された記事は、比較的短い距離を移動したときの話題に関する可能性が高い。そこで、「散歩」「徒歩」を、比較的狭い大きさ（例えば、縮尺１／１５００や、200m×200m）に関連付けて用いることとしてもよい。このように、移動距離に関する文字列を範囲文字列として用いれば、話題に適した範囲を表す地図画像を生成することができる。なお、移動距離に関する文字列としては、上述の文字列に限らず、他の文字列を採用してもよい。

Ｅ．第５実施例：
図１２は、第５実施例におけるＷｅｂページと地図画像との概要を示す説明図である。図８に示す第１実施例との差異は、地図データ管理部２２２が、地図データベースＭＤＢを参照することによって、地理的な範囲が同じであるとともに、年月の範囲が互いに異なる複数種類の地図画像を生成することが可能である点である。他の構成は、図１に示す第１実施例と同じである。

図１２に示す例では、地図データ管理部２２２は、「２００２年１２月以前」の地図画像と、「２００３年１月〜１２月」の地図画像と、「２００４年１月以降」の地図画像と、の３種類の地図画像を生成することが可能である。「２００２年１２月以前」の地図画像には、２００２年１２月以前の道路や建物の様子が表示され、「２００３年１月〜１２月」の地図画像には、２００３年１月〜１２月における道路や建物の様子が表示され、「２００４年１月以降」の地図画像には、２００４年１月以降の道路や建物の様子が表示される。

また、図１２には、Ｗｅｂデータ生成部２１６が記事を追加して生成したＷｅｂページデータが示されている。第５実施例では、Ｗｅｂデータ生成部２１６は、記事データを受信した年月、すなわち、記事が投稿された年月を表す年月データを、「緯度/経度データ」とともに、地図ボタンＭＢのリンク先データに組み込む（図３：ステップＳ１４０）。

Ｗｅｂページを閲覧するユーザが地図ボタンＭＢを操作すると、「緯度/経度データ」と「年月データ」とを含むリンク先データが、Ｗｅｂサーバ２００へ送信される（図７：ステップＳ２３０）。地図データ管理部２２２は、「緯度/経度データ」に基づいて地図画像が表す位置を決定し、「年月データ」に基づいて地図画像の年月の範囲を決定する。第５実施例では、投稿年月を含む年月の範囲が選択される。図１２の例では、投稿年月「２００３年７月」を含む「２００３年１月〜１２月」の地図画像が生成される（図７：ステップＳ２４０）。

図１２には、生成された地図画像を表示するＷｅｂページＷＰ２が示されている。このＷｅｂページＷＰ２は、地図ボタンＭＢを操作することによって、クライアントコンピュータ１００ｂのブラウザに表示される。このＷｅｂページＷＰ２は、地図画像ＭＩと、地図画像を説明するコメントＭＣと、最新地図ボタンＬＭＢと、を有している。コメントＭＣは、表示されている地図画像の適用年月範囲が「２００３年１月〜１２月」である旨を表している。また、最新地図ボタンＬＭＢは、最新の地図画像へのリンクを示している。この最新地図ボタンＬＭＢを操作すると、最新の地図画像がブラウザに表示される。

このように、第５実施例では、本文テキストの受信時期（年月）、すなわち、記事の投稿時期に応じて地図画像の年月の範囲が決定されるので、記事の投稿時の年月に適した地図画像を提供することができる。

なお、地図画像の適用時期を表す形式としては、年月を用いる形式に限らず、任意の形式を採用することができる。例えば、年月日を用いてもよく、年月日時分を用いてもよい。

また、生成される地図画像の時期範囲を選択する方法としては、投稿時期に応じて時期範囲を選択する任意の方法を採用することができる。例えば、地図データ管理部２２２が、投稿時期を含む時期範囲の地図画像に加えて最新の地図画像を生成し、さらに、Ｗｅｂデータ生成部２１６が、これら２種類の地図画像を同時に表示するＷｅｂページを生成することとしてもよい。いずれの場合も、生成される地図画像は、投稿時期を含む時期範囲の地図画像を含むことが好ましい。こうすれば、Ｗｅｂページを閲覧するユーザは、記事が投稿された時期における道路や建物の様子を確認することができる。

なお、投稿時期を特定する方法としては、記事データを受信した受信時を用いる方法に限らず、種々の方法を用いることができる。例えば、記事を投稿するクライアント装置から、記事の発信時を表す情報が送信される場合には、その発信時を用いてもよい。また、投稿時期の代わりに、投稿された記事に関する種々の時間に基づいて地図画像の時期範囲を選択することとしてもよい。例えば、本文テキストに日時を表す文字列が含まれている場合には、その文字列が表す日時に応じて時期範囲を選択することとしてもよい。この際、構文解析部２１８が日時を表す文字列を抽出することとすればよい。このように投稿された記事に関する時間としては、Ｗｅｂサーバ２００が記事を受信した時間や、クライアント装置が記事を送信した時間に限らず、本文テキストを解析して得られる時間を用いることができる。

ところで、地図データベースＭＤＢは適宜更新される。ただし、新たな地図データベースの整備には長期間（例えば、１年）を要する場合がある。例えば、半年前の様子を表す地図画像を、現在は提供できない場合がある。ところが、さらに半年後には、地図データベースＭＤＢが更新されて提供可能となる場合がある。従って、地図データ管理部２２２は、クライアントコンピュータ１００ｂから地図画像の閲覧の要求がある度に、地図画像を生成し直すことが好ましい。こうすれば、常に最新の地図画像を提供することが可能となる。

Ｆ．第６実施例：
図１３は、第６実施例におけるＷｅｂページと地図画像との概要を示す説明図である。図５、図８に示す第１実施例との差異は、複数の位置文字列が抽出された場合に、地図データ管理部２２２が、各位置を通る経路を表す地図画像を生成する点である。他の構成は、図１に示す第１実施例と同じである。

図１３には、Ｗｅｂデータ生成部２１６がＷｅｂページデータに記事を追加する様子が示されている。図１３の例では、構文解析部２１８（図１）は、本文テキストの中から、３つの位置文字列（「Ｉ広場」「Ｊ灯台」「Ｋ公園」）を抽出している。そこで、位置データ管理部２２０は、各位置文字列に関連する緯度と経度とを取得する。次に、Ｗｅｂデータ生成部２１６は、３つの緯度と経度との組み合わせを用いてＷｅｂページデータを生成する。具体的には、Ｗｅｂデータ生成部２１６は、３つの「緯度/経度データ」（以下、位置文字列の登場順に「第１〜第３緯度/経度データ」と呼ぶ）を１つの地図ボタンＭＢのリンク先データに組み込む（図３：ステップＳ１４０）。

Ｗｅｂページを閲覧するユーザが地図ボタンＭＢを操作すると、３つの「緯度/経度データ」を含むリンク先データが、Ｗｅｂサーバ２００へ送信される（図７：ステップＳ２３０）。地図データ管理部２２２は、３つの「緯度/経度データ」が表す位置を経由する経路を表す地図画像を生成する（図７：ステップＳ２４０）。この際、経路としては、複数の位置を、本文テキストにおいて位置文字列が登場した順番に辿る経路を採用すればよい。また、経路を探索する方法としては、ダイクストラ法等の種々の周知の方法を採用することができる。

このように、第６実施例では、本文テキストから複数の位置文字列が抽出された場合には、各位置を経由する経路を表す地図画像が提供される。その結果、情報（記事）を登録するユーザが、各位置を訪れるための経路を表す地図画像を準備しなくても、閲覧者は、各位置を訪れるための経路を閲覧することができるので、記事を登録するユーザの負担を大幅に軽減することができる。

なお、経路としては、各位置を通る任意の経路を採用することができる。例えば、本文テキストにおいて同じ位置文字列が重複して登場する場合には、最初に登場した位置文字列のみを用いて経路を決定することとしてもよい。また、各位置を１回ずつ通る複数の経路の中から、総移動距離が理論上の最短に比較的近い経路を近似的に求め、得られた経路を採用してもよい。

また、経路が通る位置に、Ｗｅｂページを閲覧するユーザの指示に従って、記事とは独立な他の位置（以下「追加位置」と呼ぶ）を追加することとしてもよい。この場合も、経路としては、任意の経路を採用することができる。例えば、追加位置を起点とする経路を採用してもよく、追加位置を終点とする経路を採用してもよい。

位置を追加する方法としては、任意の方法を採用することができる。例えば、ユーザが地図ボタンＭＢを操作することによって、クライアントコンピュータ１００ｂから、その現在位置を表す現在位置情報が、Ｗｅｂサーバ２００へ送信されることとしてもよい。Ｗｅｂサーバ２００では、Ｗｅｂデータ受信部２１２が現在位置情報を受信し、地図データ管理部２２２が、現在位置と、位置文字列が表す位置と、を通る経路を表す地図画像を生成する。ここで、クライアントコンピュータ１００ｂに位置検出装置を設けておけば、現在位置情報の送信のためのユーザの負担を軽減することができる。位置検出装置としては、例えば、GPS（Global Positioning System）を利用したものを用いることができる。

また、ユーザが任意に入力したテキストに基づいて追加位置を決定してもよい。例えば、地図ボタンＭＢを含むＷｅｂページにテキストを入力可能なフィールドを設け（図示省略）、位置データ管理部２２０が、入力されたテキストから位置文字列を抽出して追加位置を決定すればよい。入力されたテキストは、地図ボタンＭＢの操作によって、Ｗｅｂサーバ２００へ送信されることとすればよい。

このように、地図データ管理部２２２が、追加位置と、記事から抽出された位置文字列に関する地理的位置と、を通る経路を表す地図画像を生成すれば、地図画像を、Ｗｅｂページを閲覧するユーザの好みに適したものとすることができる。また、この場合には、記事から抽出された位置文字列の数は１つであってもよい。なお、Ｗｅｂサーバ２００へ送信される追加位置を表す情報としては、テキスト（位置文字列）や、緯度と経度とを表す情報等の、位置に関連する種々の情報を採用することができる。また、この実施例では、Ｗｅｂデータ受信部２１２が、本発明における「追加位置情報受信部」に相当する。

Ｇ．第７実施例：
上述した各実施例では、Ｗｅｂサーバ２００は、記事（テキスト）を表示するＷｅｂページと、地図画像を表示するＷｅｂページと、を独立に提供しているが（図８）、この代わりに、記事と地図画像との両方を含むＷｅｂページを提供することとしてもよい。図１４は、このようなＷｅｂページの一例を示す説明図である。図１４の例では、追加された記事の下部に地図画像が表示されている。Ｗｅｂデータ生成部２１６は、記事データと、地図データ管理部２２２が生成した地図画像データと、を用いることによって、記事と地図画像とを含むＷｅｂページを生成することができる。この際、図３のステップＳ１４０において、地図データ管理部２２２が、図７のステップＳ２４０と同様に、地図画像データを生成すればよい。

Ｈ．第８実施例：
図１５は、第８実施例における、記事の入力画面の一例を示す説明図である。図４に示す第１実施例の入力画面ＩＳとの差異は、地図ボタンＭＢａを有している点である。

図１６は、図１５の入力画面ＩＳａを用いて記事を投稿する処理の手順を示すフローチャートである。ステップＳ３００では、ユーザが入力画面ＩＳａに記事を入力する。さらに、ユーザが地図ボタンＭＢａを操作すると（ステップＳ３１０：Ｙｅｓ）、入力された各情報（記事データ）が、Ｗｅｂサーバ２００に送信される。

Ｗｅｂサーバ２００（図１）では、記事データに基づいて地図画像が生成される。まず、図３のステップＳ１２０、Ｓ１３０と同様に、構文解析部２１８が本文テキストから位置文字列を抽出し（ステップＳ３２０）、位置データ管理部２２０が位置文字列に関連する緯度と経度とを取得する（ステップＳ３３０）。次に、図７のステップＳ２４０、Ｓ２５０、Ｓ２６０と同様に、地図データ管理部２２２が、位置文字列が表す位置を含む地図画像を生成し（ステップＳ３４０）、Ｗｅｂデータ生成部２１６が地図画像を表示するためのＷｅｂページを生成し（ステップＳ３５０）、Ｗｅｂデータ送信部２１４がＷｅｂページデータをクライアントコンピュータ１００ａへ送信する（ステップＳ３６０）。

クライアントコンピュータ１００ａでは、Ｗｅｂブラウザが、地図画像を含むＷｅｂページを表示する（ステップＳ３７０。図示省略）。記事を投稿するユーザは、表示された地図画像を確認することによって、本文テキストが意図するものであるか否かを確認することができる。

ユーザが、もとの入力画面ＩＳａに戻り、登録ボタンＲＢを操作すると（ステップＳ３８０：Ｙｅｓ）、記事データが、Ｗｅｂサーバ２００へ送信される（ステップＳ３９０）。Ｗｅｂサーバ２００では、受信した記事を追加したＷｅｂページの作成と格納とが行われる（ステップＳ３９５）。このＷｅｂページ作成格納処理は、上述した各実施例と同様の手順（例えば、図３のステップＳ１２０〜Ｓ１５０）に従って行われる。

一方、ユーザは、もとの入力画面ＩＳａに戻り、登録ボタンＲＢを操作せずに（ステップＳ３８０：Ｎｏ）入力画面ＩＳａを操作することによって（ステップＳ３００）、記事を修正することができる。その後、ユーザは、地図ボタンＭＢａを操作することによって、修正後の記事に基づく地図画像を確認することができる。また、登録ボタンＲＢを操作することによって、修正後の記事を登録することができる。

このように、第８実施例では、地理的な位置を表す文字列を含む記事の修正が可能な状態で、その位置を含む地図画像がサーバによって提供される。その結果、ユーザは、地図画像を確認しながら、記事を修正することができるので、記事（情報）を登録するユーザの負担を大幅に軽減することができる。

なお、記事の修正が可能な状態で提供される地図画像としては、上述した各実施例と同様に種々のものを採用することができる。例えば、図９や図１０に示す実施例のように、地図画像の種類を、記事を登録するＷｅｂページの種類や本文テキストから抽出されたカテゴリ文字列に応じて決定してもよい。また、図１１に示す実施例のように、本文テキストから抽出された範囲文字列に応じて地図画像の範囲の大きさを決定してもよく、図１２に示す実施例のように、記事の投稿時期に応じて地図画像の時期の範囲を決定してもよい。さらに、図１３に示す実施例のように、本文テキストから複数の位置文字列が抽出された場合には、各位置を経由する経路を表す地図画像を提供することとしてもよく、また、追加位置と、位置文字列に関する位置と、を通る経路を表す地図画像を提供してもよい。また、ユーザが地図ボタンＭＢａを操作したときに（図１６：ステップＳ３１０：Ｙｅｓ）、クライアントコンピュータ１００ａからＷｅｂサーバ２００へ送信される情報は、記事データの全てを含んでいる必要はなく、地図画像の生成に要求される情報のみを含んでいればよい。

また、記事の修正が可能な状態で提供された地図画像を、記事として投稿することができることとしてもよい。この際、投稿者が地図画像を編集できることとしてもよい。こうすれば、目的地に目印を記入するなどした好みの地図画像を投稿することができる。

Ｉ．第９実施例：
図１７は、本発明の別の実施例としてのネットワークシステム３００ａの構成を示す説明図である。このネットワークシステム３００ａは、基地局ネットワークＢＮＥＴに接続された複数の基地局ＢＳ１〜ＢＳ５と、基地局と無線通信で接続された携帯電話６００と、インターネットＩＮＥＴに接続されたＷｅｂサーバ２００ａと、基地局ネットワークＢＮＥＴとインターネットＩＮＥＴとを接続する中継サーバ５００と、を有している。なお、基地局の数としては、５に限らず任意の数を採用することができる。

携帯電話６００は、通信部６１０と、データ処理部６２０と、位置検出部６３０と、モニタ６５０と、を備えている。データ処理部６２０はＣＰＵとメモリとを有しており、コンピュータプログラムを実行することによって、Ｗｅｂブラウザとしての機能を実現する。Ｗｅｂブラウザはモニタ６５０に表示される。ここで、データ処理部６２０は、通信部６１０を介して基地局とのデータのやり取りを行う。また、位置検出部６３０は、例えば、GPS（Global Positioning System）を利用して現在位置を検出することが可能である。検出した現在位置の利用方法については後述する。

Ｗｅｂサーバ２００ａは、図１に示すＷｅｂサーバ２００と同様に、インターネットＩＮＥＴを介してＷｅｂページを提供する。図１のＷｅｂサーバ２００との差異は、データ処理部２１０ａが、位置文字列提供部２２４を有している点だけであり、他の構成は、図１に示すＷｅｂサーバ２００と同じである。なお、図１７では、Ｗｅｂサーバ２００ａの構成要素として、データ処理部２１０ａと、通信部２５０と、のみが示されており、他の構成要素は図示が省略されている。

中継サーバ５００は、基地局ネットワークＢＮＥＴとインターネットＩＮＥＴとの間で、データを中継する。例えば、携帯電話６００から、Ｗｅｂサーバ２００ａへ対するＷｅｂページの閲覧要求が送信された場合には、携帯電話６００から基地局を介して基地局ネットワークＢＮＥＴに送られた閲覧要求を、インターネットＩＮＥＴへ中継する。また、Ｗｅｂサーバ２００ａから、携帯電話６００へ対するＷｅｂページデータが送信された場合には、Ｗｅｂサーバ２００ａからインターネットＩＮＥＴへ送られたＷｅｂページデータを、基地局ネットワークＢＮＥＴへ中継する。このようにして、携帯電話６００では、ブラウザが、Ｗｅｂサーバ２００ａによって提供されたＷｅｂページを表示する。また、同様に、携帯電話６００からＷｅｂサーバ２００ａへの記事の投稿も行われる。

図１８は、携帯電話６００から記事を投稿する手順を示すフローチャートである。ステップＳ４００では、ユーザが記事を入力する。この入力は、携帯電話６００のＷｅｂブラウザが表示する入力画面を用いて行われる。

図１９は、記事を投稿する様子を示す説明図である。図１９（Ａ）には、入力画面の一例が示されている。この入力画面ＩＳｂは、カテゴリメニューＣＭｂと、タイトルフィールドＴＦｂと、本文フィールドＢＦｂと、現在位置ボタンＰＢと、登録ボタンＲＢｂと、を有している。カテゴリメニューＣＭｂは図４のカテゴリメニューＣＭと同じ機能を有し、タイトルフィールドＴＦｂは図４のタイトルフィールドＴＦと、本文フィールドＢＦｂは図４の本文フィールドＢＦと、それぞれ、同じ機能を有している。

ユーザが、記事を入力し（図１８：ステップＳ４００）、さらに、現在位置ボタンＰＢを操作すると（ステップＳ４１０：Ｙｅｓ）、位置検出部６３０（図１７）が現在位置を検出し、現在位置を表す現在位置データが、通信部６１０によってＷｅｂサーバ２００ａへ送信される。この現在位置データは、本実施例では、緯度と経度とを表している。

Ｗｅｂサーバ２００ａでは、Ｗｅｂデータ受信部２１２が携帯電話６００から送られた現在位置データを受信し、位置文字列提供部２２４が、位置データベースＰＤＢを参照することによって、現在位置を表す文字列を取得する（ステップＳ４２０）。具体的には、現在位置データが表す現在位置（緯度/経度）に最も近い位置（緯度/経度）に関連付けられた位置文字列を取得する。図１９（Ｂ）には、位置データベースＰＤＢの一例が示されている。図１９（Ｂ）の例では、「Ｍ駅」という位置文字列が選択されている。

次のステップＳ４３０では、Ｗｅｂデータ送信部２１４（図１７）が、選択された位置文字列を、携帯電話６００へ送信する。すると、携帯電話６００では、本文フィールドＢＦｂの本文テキストに位置文字列が追加される（ステップＳ４４０）。図１９（Ｃ）には、位置文字列（この例では「Ｍ駅」）が追加された後の入力画面ＩＳｂが示されている。さらに、ユーザは、登録ボタンＲＢｂを操作せずに（ステップＳ４５０：Ｎｏ）、入力画面ＩＳｂを操作することによって、記事を修正することができる（ステップＳ４００、図１９（Ｄ））。

次に、ユーザが登録ボタンＲＢｂを操作すると、入力画面ＩＳｂに入力された各情報（記事）が、携帯電話６００からＷｅｂサーバ２００ａへ送信される（ステップＳ４５０：Ｙｅｓ、Ｓ４６０）。Ｗｅｂサーバ２００ａでは、受信した記事を追加したＷｅｂページの作成と格納とが行われる（ステップＳ４７０）。このＷｅｂページ作成格納処理は、上述した各実施例と同様の手順（例えば、図３のステップＳ１２０〜Ｓ１５０）に従って行われる。

このように、第９実施例では、サーバによって現在位置を表す文字列が提供されるので、現在位置を表す文字列を含む記事を投稿するユーザの負担を大幅に軽減することができる。例えば、初めて訪れた場所を表現する記事を登録する際に、その場所の名前を知らなくても、サーバによって提供される言葉を用いて、適切なテキストを登録することができる。

なお、図１９の例では、Ｗｅｂサーバ２００ａは、現在位置に最も近い位置に関連する１つの位置文字列を提供していたが、現在位置に近い複数の位置文字列を提供することとしてもよい。この場合には、携帯電話６００において、提供された複数の文字列の中から記事に使用する位置文字列をユーザが指定することとすればよい。

なお、本実施例では、携帯電話６００が、本発明における、記事を送信する「第１クライアント装置」に相当するとともに、位置情報（現在位置データ）を送信する装置にも相当する。また、Ｗｅｂデータ受信部２１２が「位置情報受信部」と「投稿情報受信部」とに相当し、位置文字列提供部２２４が「位置表示文字列生成部」に相当し、Ｗｅｂデータ送信部２１４が「位置表示文字列送信部」と「提供情報送信部」とに相当する。

また、図１７に示すネットワークシステム３００ａでは、携帯電話６００は、複数の基地局ＢＳ１〜ＢＳ５の中の１つの基地局を用いて通信を行う。この際、通常は、携帯電話６００に最も近い基地局が通信に使用される。従って、通信に使用されている基地局を識別することによって、携帯電話６００のおおよその現在位置を把握することができる。そこで、Ｗｅｂサーバ２００ａが、通信に使用されている基地局の識別結果に基づく位置文字列を携帯電話６００へ送信することとしてもよい。

例えば、携帯電話６００の現在位置ボタンＰＢ（図１９（Ａ））を操作すると、携帯電話６００が、現在位置ボタンＰＢを操作した旨の指示を中継サーバ５００へ送信し、さらに、指示を受けた中継サーバ５００が、通信に使用されている基地局を識別する基地局識別情報をＷｅｂサーバ２００ａに送信することとしてもよい。ここで、Ｗｅｂサーバ２００ａのデータ格納部２７０（図示省略）には、基地局識別情報と位置文字列との対応関係を定める基地局位置文字列テーブルを予め格納しておく（図示省略）。位置文字列としては、例えば、基地局ＢＳ１に対しては「Ｘ町」、基地局ＢＳ２に対しては「Ｙ町」、というように、その基地局が位置する住所を表す文字列を採用することができる。位置文字列提供部２２４は、この基地局位置文字列テーブルを参照することによって、基地局識別情報に応じた位置文字列を取得する。取得された位置文字列は、Ｗｅｂデータ送信部２１４によって携帯電話６００へ送信される。この場合には、携帯電話６００の位置検出部６３０を省略することができる。また、「基地局識別情報」が「位置情報」に相当し、さらに、中継サーバ５００が、位置情報（基地局識別情報）を送信する装置に相当する。

Ｊ．第１０実施例：
図２０は、第１０実施例における、携帯電話６００から記事を投稿する手順を示すフローチャートである。図１８に示す第９実施例との差異は、携帯電話６００の現在位置の代わりにユーザによって指定された地図上の位置を表す位置文字列が、Ｗｅｂサーバ２００ａから携帯電話６００へ提供される点だけである。他の構成は、図１７に示すネットワークシステム３００ａと同じである。

図２１は、記事を投稿する様子を示す説明図である。図２１（Ａ）には、入力画面の一例が示されている。図１９（Ａ）の入力画面ＩＳｂとの差異は、現在位置ボタンＰＢの代わりに地図検索ボタンＭＳＢが設けられている点である。他の構成は、入力画面ＩＳｂと同じである。

ユーザが、記事を入力し（図２０：ステップＳ５００）、さらに、地図検索ボタンＭＳＢを操作すると（ステップＳ５１０：Ｙｅｓ）、位置検出部６３０（図１７）が現在位置を検出し、検出された現在位置を表す現在位置データがＷｅｂサーバ２００ａへ送信される。これらの処理は、図１８のステップＳ４００、Ｓ４１０と同じである。

Ｗｅｂサーバ２００ａでは、Ｗｅｂデータ受信部２１２が携帯電話６００から送られた現在位置データを受信する。さらに、図７のステップＳ２４０、Ｓ２５０、Ｓ２６０と同様に、地図データ管理部２２２が、現在位置を含む地図画像を生成し（ステップＳ５１２）、Ｗｅｂデータ生成部２１６が、地図画像を表示するためのＷｅｂページデータを生成し（ステップＳ５１４）、Ｗｅｂデータ送信部２１４が、Ｗｅｂページデータを携帯電話６００へ送信する（ステップＳ５１６）。

次のステップＳ５１８では、携帯電話６００において、Ｗｅｂブラウザが、地図画像を含むＷｅｂページを表示する。図２１（Ｂ）には、Ｗｅｂページの一例が示されている。このＷｅｂページには、地図画像と、ＯＫボタンＯＢと、が示されている。ユーザは、Ｗｅｂブラウザを操作することによって、地図上の１つの位置を指定することができる。図２１（Ｂ）では、ユーザの指定した位置が十字印ＣＰで示されている。ユーザがＯＫボタンＯＢを操作すると、ユーザの指定した位置を表す位置データがＷｅｂサーバ２００ａへ送信される。この位置データは、例えば、地図画像中における相対的な位置を表す座標データ（例えば、Ｘ座標とＹ座標）である。

Ｗｅｂサーバ２００ａでは、Ｗｅｂデータ受信部２１２が携帯電話６００から送られた位置データを受信し、位置文字列提供部２２４が、位置データベースＰＤＢを参照することによって、位置を表す文字列を取得する（ステップＳ５２０）。この処理は、図１８のステップＳ４２０と同じである。図２１（Ｃ）の例では、「Ｐ会館」という文字列が選択されている。選択された位置文字列は、Ｗｅｂデータ送信部２１４によって携帯電話６００へ送信される（ステップＳ５３０）。なお、位置文字列提供部２２４は、位置データと、地図画像が表す緯度と経度とを用いることによって、指定された位置の緯度と経度とを算出することができる。

携帯電話６００では、本文フィールドＢＦｂの本文テキストに位置文字列が追加される（ステップＳ５４０）。図２１（Ｄ）には、位置文字列（この例では「Ｐ会館」）が追加された後の入力画面ＩＳｃが示されている。

以後、ユーザは、登録ボタンＲＢｂを操作せずに（ステップＳ５５０：Ｎｏ）、入力画面ＩＳｃを操作することによって、記事を修正することができる（ステップＳ５００、図２１（Ｅ））。また、ユーザが登録ボタンＲＢｂを操作すると、入力画面ＩＳｃに入力された各情報（記事）が、携帯電話６００からＷｅｂサーバ２００ａへ送信される（ステップＳ５６０）。Ｗｅｂサーバ２００ａでは、受信した記事を追加したＷｅｂページの作成と格納とが行われる（ステップＳ５７０）。これらの処理Ｓ５５０、Ｓ５６０、Ｓ５７０は、図１８のステップＳ４５０、Ｓ４６０、Ｓ４７０と、それぞれ、同じである。

このように、第１０実施例では、Ｗｅｂサーバ２００ａは、地図画像を提供するとともに、その地図画像上の一点を指定するユーザの指示に従って、指定された位置を表す文字列を提供する。その結果、ユーザは、地図上の位置を指定するだけで、その位置を表す文字列を含む記事を作成することができるので、位置を表す文字列を含む記事を投稿するユーザの負担を大幅に軽減することができる。

なお、位置を指定するための地図画像としては、携帯電話６００の現在位置を含む地図画像に限らず、任意の地図画像を採用することができる。例えば、ユーザが指定した住所位置を含む地図画像を採用してもよい。この場合には、携帯電話６００（図１７）の位置検出部６３０を省略することができる。

また、地図上で指定された位置を表す位置データとしては、地図画像中における相対的な位置を表す座標データに限らず、地理的な位置を表す任意のデータを採用することができる。例えば、地図画像中における相対的な位置から算出された緯度と経度とを表すデータを用いてもよい。

なお、本実施例では、Ｗｅｂデータ送信部２１４が、本発明における「指定用地図画像送信部」にも相当し、地図データ管理部２２２は「指定用地図画像生成部」にも相当する。

なお、上述の第９実施例と第１０実施例とでは、Ｗｅｂサーバ２００ａ（図１７）が構文解析部２１８と位置データ管理部２２０とを有しているが、これらの構成要素を省略してもよい。但し、これらの構成要素を有することとし、さらに、上述した各実施例（第１〜第８実施例）と同様に、Ｗｅｂサーバ２００ａが、記事と、記事に含まれる位置文字列が表す位置を含む地図画像と、を提供することが好ましい。

Ｋ．変形例：
なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。

変形例１：
上述の各実施例において、記事としては、テキスト（本文テキストとタイトルテキスト）に限らず、他の種々の種類のデータを含むものを採用してもよい。例えば、画像を含む記事を投稿できることとしてもよい。ここで、記事に画像が含まれている場合には、その記事に関する地図画像を閲覧用のクライアント装置に送信するか否かを、閲覧者が指定できることとしてもよい。こうすれば、投稿された画像を観察することによって地理的な位置を確認することができる場合に、さらに、地図画像を受信することを抑制することができる。また、記事を表すＷｅｂページにおいて投稿日時を記録しないこととしてもよい。この場合には、Ｗｅｂサーバ２００、２００ａからタイマ２６０を省略することができる。また、Ｗｅｂサーバ２００、２００ａが提供するＷｅｂページとしては、投稿された記事が累積的に追加されたものに限らず、投稿された記事を含む任意のＷｅｂページを採用することができる。例えば、最新の記事のみを含むＷｅｂページを提供することとしてもよい。

変形例２：
上述の各実施例において、Ｗｅｂページを閲覧するためのクライアント装置としては、クライアントコンピュータ１００ａや携帯電話６００に限らず、携帯情報端末（ＰＤＡとも呼ばれる）や、車載用のナビゲーション装置等の種々の装置を用いることができる。これは、記事を投稿するためのクライアント装置についても、同様である。

なお、上述の各実施例では、地図画像情報として地図画像を用いているが、地図画像情報としては、位置文字列に関連付けられた地理的位置を含むとともに地理的な範囲が定められた地図画像に関連する種々の情報を採用することができる。例えば、地図画像の中心位置を表す座標（以下「中心座標」と呼ぶ）と地図画像の縮尺との組み合わせを、地図画像情報として用いてもよい。通常のナビゲーション装置は、地図データベースＭＤＢと同様の地図データベースを格納している。そこで、このような地図データベースを格納する装置が、Ｗｅｂページを閲覧するクライアント装置として機能する場合には、地図画像そのものをサーバから受信する代わりに、中心座標と縮尺とを受信すれば、適切な地図画像を表示することができる。このように、地図画像情報としては、位置文字列に関連付けられた地理的位置を含む地理的な範囲を特定する情報を採用することができる。

変形例３：
上述の各実施例において、Ｗｅｂサーバ２００、２００ａが有する複数の機能は、別々のコンピュータハードウェア上に分散させて実現されていてもよい。

変形例４：
上述の各実施例では、地図画像の閲覧を要求する際に地図画像を特定するために用いる情報（以下「特定情報」と呼ぶ）として、「緯度/経度データ」を含む情報を用いている。但し、地図画像の特定情報としては、他の任意の種類の情報を採用することができる。例えば、地図画像データを格納するデータファイルのファイル名を特定情報として用いても良い。この場合には、地図データ管理部２２２（図１）が、記事の登録の際に、図７のステップＳ２４０と同様に地図画像データを生成して、データファイルをデータ格納部２７０に格納すればよい。また、地図画像を表すＷｅｂページのＵＲＬを特定情報として用いてもよい。この場合には、記事の登録の際に、地図データ管理部２２２が地図画像を生成して、データ格納部２７０に格納し、さらに、Ｗｅｂデータ生成部２１６が、その地図画像を表示するＷｅｂページを生成して、データ格納部２７０に格納すればよい。

変形例５：
上述の各実施例では、Ｗｅｂサーバ２００によって提供される地図画像は、以下の特徴を有している。
（１）地図画像は、投稿された記事（本文テキスト）から抽出された位置文字列が表す位置を含む（第１実施例：図５、図８）。
（２）地図画像の内容の種類が、記事が登録されたＷｅｂページの種類（カテゴリ）に応じて決定される（第２実施例：図９）。
（３）地図画像の内容の種類が、投稿された記事（本文テキスト）から抽出されたカテゴリ文字列に応じて決定される（第３実施例：図１０）。
（４）地図画像の範囲の大きさが、投稿された記事（本文テキスト）から抽出された範囲文字列に応じて決定される（第４実施例：図１１）。
（５）地図画像の時期範囲の種類が、記事の投稿時期に応じて決定される（第５実施例：図１２）。
（６）投稿された記事（本文テキスト）から複数の位置文字列が抽出された場合には、地図画像は、それら複数の位置を通る経路を表す（第６実施例：図１３）。
（７）地図画像は、投稿された記事（本文テキスト）から抽出された位置文字列が表す位置と、追加位置と、を通る経路を表す（第６実施例）。

なお、地図画像が有する特徴としては、これらの特徴（１）〜（７）の任意の組み合わせを採用することができる。ただし、少なくとも特徴（１）を有していることが好ましい。また、特徴（２）（３）に関しては、いずれか一方のみを採用することが好ましい。

また、地図画像としては、２次元的な地図画像に限らず、３次元的な地図画像を採用してもよい。３次元的な地図画像としては、例えば、道路や住宅等の地物の位置と形状とを３次元で表現した３次元モデル情報を用い、所定の視点から所定の視野枠内を通して地物を眺めて得られる画像を採用することができる。この際、画像内に位置文字列が表す位置が含まれるように視点と視野枠とを設定すればよい。また、３次元的な地図画像が表す地理的な範囲を、２次元的な地図画像を生成する場合と同様に、地表面における範囲を用いて定めてもよい。また、地図画像としては、静止画像に限らず動画像を採用してもよい。例えば、３次元的な地図画像を用いる場合に、視点を、位置文字列が表す位置を中心として回転させて得られる動画像を用いることとしてもよい。また、経路に沿って視点を移動させることによって得られる動画像を用いることとしてもよい。

変形例６：
上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。

変形例７：
上記実施例１において、クライアントコンピュータを携帯電話とし、当該携帯電話に位置検出部（たとえば、GPS)を付属し、このGPSにより取得された現在位置情報を、投稿情報とともにサーバに送信するよう、構成することも可能である。こうすることにより、投稿記事から位置文字列が抽出できない場合であっても、現在位置情報を利用することで、地図画像を生成することが可能となる。また、投稿記事から位置文字列が抽出できた場合であっても、その抽出された位置文字列の正確性を、現在位置情報と照合することで判断することができる。この場合、位置文字列の指し示す位置と、現在位置情報とが大きく異なる場合には、携帯電話（ユーザ）に問い合わせるよう構成することで、ユーザの意図に沿った地図画像を作成することが可能となる。

変形例８：
上述の各実施例では、Ｗｅｂサーバ２００は、投稿された記事と地図画像とを提供しているが、クライアントコンピュータ１００ｂからの要求に応じて、いずれか一方のみを提供することとしてもよい。例えば、携帯電話等の画像を充分に大きく表示できない装置を用いてＷｅｂページを閲覧する場合がある。このような場合には、テキストのみを送信することとしてもよい。また、車載用のナビゲーション装置を用いる場合には、地図画像のみを送信することとしてもよい。Ｗｅｂサーバ２００が送信する情報を切り替える方法としては、任意の方法を用いることが可能である。例えば、テキストのみを送信するためのＵＲＬと、画像のみを送信するためのＵＲＬを準備し、クライアント装置を操作するユーザが、適宜、好みのＵＲＬ指定する方法を用いることができる。

変形例９：
なお、上述の各実施例では、Ｗｅｂサーバ２００が地図画像情報を送信することとしているが、この代わりに、位置文字列が表す位置を通る経路を案内する文章（テキスト）を送信することとしてもよい。例えば、位置文字列が表す地理的な位置から最寄りの駅へ至る経路を案内する文章を送信することとしてもよい。この場合には、地図データベースＭＤＢに、道路や交差点の名前を格納しておき、さらに、経路を表す文章（テキスト）を生成する経路案内文章生成部（図示省略）をＷｅｂサーバ２００に設けておけばよい。経路案内文章生成部は、地図データベースＭＤＢを参照しつつ、「Ａ１通りを北進、Ｂ１交差点を右折・・・」といった経路を表すテキストを生成すればよい。

本発明の一実施例としてのネットワークシステム３００の構成を示す説明図である。 Ｗｅｂサーバ２００が提供するＷｅｂページの一例を示す説明図である。 記事を投稿する処理の手順を示すフローチャートである。 入力画面の一例を示す説明図である。 記事を追加する処理の概要を示す説明図である。 生成されたＷｅｂページの一例を示す説明図である。 更新されたＷｅｂページを閲覧する処理の手順を示すフローチャートである。 クライアントコンピュータ１００ｂが地図画像を取得する様子の概要を示す説明図である。 第２実施例におけるＷｅｂページと地図画像との概要を示す説明図である。 第３実施例におけるＷｅｂページと地図画像との概要を示す説明図である。 第４実施例におけるＷｅｂページと地図画像との概要を示す説明図である。 第５実施例におけるＷｅｂページと地図画像との概要を示す説明図である。 第６実施例におけるＷｅｂページと地図画像との概要を示す説明図である。 第７実施例におけるＷｅｂページの一例を示す説明図である。 第８実施例における記事の入力画面の一例を示す説明図である。 入力画面ＩＳａを用いて記事を投稿する処理の手順を示すフローチャートである。 本発明の別の実施例としてのネットワークシステム３００ａの構成を示す説明図である。 携帯電話６００から記事を投稿する手順を示すフローチャートである。 記事を投稿する様子を示す説明図である。 第１０実施例における携帯電話６００から記事を投稿する手順を示すフローチャートである。 記事を投稿する様子を示す説明図である。

符号の説明

１００ａ、１００ｂ...クライアントコンピュータ
２００、２００ａ...Ｗｅｂサーバ
２１０、２１０ａ...データ処理部
２１２...Ｗｅｂデータ受信部
２１４...Ｗｅｂデータ送信部
２１６...Ｗｅｂデータ生成部
２１８...構文解析部
２２０...位置データ管理部
２２２...地図データ管理部
２２４...位置文字列提供部
２５０...通信部
２６０...タイマ
２７０...データ格納部
３００、３００ａ...ネットワークシステム
５００...中継サーバ
６００...携帯電話
６１０...通信部
６２０...データ処理部
６３０...位置検出部
６５０...モニタ
ＩＮＥＴ...インターネット
ＢＮＥＴ...基地局ネットワーク
ＣＡ...カテゴリ指定領域
ＲＡ...記事表示領域
ＰＢ...現在位置ボタン
ＯＢ...ＯＫボタン
ＲＢ、ＲＢｂ...登録ボタン
ＭＣ...コメント
ＴＦ、ＴＦｂ...タイトルフィールド
ＢＦ、ＢＦｂ...本文フィールド
ＣＬ...カレンダ領域
ＣＭ、ＣＭｂ...カテゴリメニュー
ＣＰ...十字印
ＩＳ、ＩＳａ、ＩＳｂ、ＩＳｃ...入力画面
ＢＳ１、ＢＳ２、ＢＳ３、ＢＳ４、ＢＳ５...基地局
ＰＤＢ...位置データベース
ＣＤＢ...カテゴリ文字列データベース
ＲＤＢ...範囲文字列データベース
ＹＭＡ...年月指定領域

Claims (9)

1. ネットワークを介して情報を提供するサーバであって、
   前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する投稿情報受信部と、
   前記投稿情報を含む情報である提供情報を生成する提供情報生成部と、
   前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する位置文字列抽出部と、
   前記テキストの中から、地図画像の種類に関連付けられた地図種文字列を抽出する地図種文字列抽出部と、
   前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲が同じであるとともに表示される内容が互いに異なる複数種類の地図画像のうちから、前記抽出された地図種文字列に基づいて決定した一種類の地図画像を生成する地図画像情報生成部と、
   前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信することが可能な情報送信部と、
   を備え、
   前記複数種類の地図画像は、前記地図画像の種類に応じた異なる種類の地物の位置と名称とをそれぞれ表示する地図画像であり、
   前記地図画像情報生成部は、
   複数の地図種文字列と地図画像の種類との対応関係を予め定めた地図種文字列データベースを参照して、前記抽出された地図種文字列に対応する地図画像の種類を決定し、
   前記決定した一種類の地図画像として、前記地図画像の種類に応じた種類の地物の位置と名称とを表示する地図画像を生成する、
   サーバ。
2. ネットワークを介して情報を提供するサーバであって、
   前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する投稿情報受信部と、
   前記投稿情報を含む情報である提供情報を生成する提供情報生成部と、
   前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する位置文字列抽出部と、
   前記テキストの中から、地理的な範囲の大きさに関連付けられた文字列である範囲文字列を抽出する範囲文字列抽出部と、
   前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲の大きさが互いに異なる複数種類の地図画像のうちから、前記抽出された範囲文字列に基づいて決定した一種類の地図画像を生成する地図画像情報生成部と、
   前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信することが可能な情報送信部と、
   を備える、
   サーバ。
3. ネットワークを介して情報を提供するサーバであって、
   前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する投稿情報受信部と、
   前記投稿情報を含む情報である提供情報を生成する提供情報生成部と、
   前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する位置文字列抽出部と、
   前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲が同じであるとともに時期範囲が互いに異なる複数種類の地図画像のうちから、前記投稿情報に関する時間に基づいて決定した一種類の地図画像を生成する地図画像情報生成部と、
   前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信することが可能な情報送信部と、
   を備える、
   サーバ。
4. ネットワークに接続されたコンピュータを用いて、前記ネットワークを介して情報を提供する方法であって、
   （ａ）前記コンピュータが、前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信してメモリに格納する工程と、
   （ｂ）前記コンピュータが、前記投稿情報を含む情報である提供情報を生成する工程と、
   （ｃ）前記コンピュータが、前記メモリに格納されたテキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する工程と、
   （ｄ）前記コンピュータが、前記テキストの中から、地図画像の種類に関連付けられた文字列である地図種文字列を抽出する工程と、
   （ｅ）前記コンピュータが、前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲が同じであるとともに表示される内容が互いに異なる複数種類の地図画像のうちから、前記抽出された地図種文字列に基づいて決定した一種類の地図画像を生成する工程と、
   （ｆ）前記コンピュータが、前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信する工程と、
   を備え、
   前記複数種類の地図画像は、前記地図画像の種類に応じた異なる種類の地物の位置と名称とをそれぞれ表示する地図画像であり、
   前記工程（ｅ）は、
   前記コンピュータが、複数の地図種文字列と地図画像の種類との対応関係を予め定めた地図種文字列データベースを参照して、前記抽出された地図種文字列に対応する地図画像の種類を決定する工程と、
   前記コンピュータが、前記決定した一種類の地図画像として、前記地図画像の種類に応じた種類の地物の位置と名称とを表示する地図画像を生成する工程と、を含む、
   情報の提供方法。
5. ネットワークに接続されたコンピュータを用いて、前記ネットワークを介して情報を提供する方法であって、
   （ａ）前記コンピュータが、前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信してメモリに格納する工程と、
   （ｂ）前記コンピュータが、前記投稿情報を含む情報である提供情報を生成する工程と、
   （ｃ）前記コンピュータが、前記メモリに格納されたテキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する工程と、
   （ｄ）前記コンピュータが、前記テキストの中から、地理的な範囲の大きさに関連付けられた文字列である範囲文字列を抽出する工程と、
   （ｅ）前記コンピュータが、前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲の大きさが互いに異なる複数種類の地図画像のうちから、前記抽出された範囲文字列に基づいて決定した一種類の地図画像を生成する工程と、
   （ｆ）前記コンピュータが、前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信する工程と、
   を備える、情報の提供方法。
6. ネットワークに接続されたコンピュータを用いて、前記ネットワークを介して情報を提供する方法であって、
   （ａ）前記コンピュータが、前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信してメモリに格納する工程と、
   （ｂ）前記コンピュータが、前記投稿情報を含む情報である提供情報を生成する工程と、
   （ｃ）前記コンピュータが、前記メモリに格納されたテキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する工程と、
   （ｄ）前記コンピュータが、前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲が同じであるとともに時期範囲が互いに異なる複数種類の地図画像のうちから、前記投稿情報に関する時間に基づいて決定した一種類の地図画像を生成する工程と、
   （ｅ）前記コンピュータが、前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信する工程と、
   を備える、情報の提供方法。
7. ネットワークに接続されたコンピュータに、前記ネットワークを介して情報を提供する処理を実行させるためのコンピュータプログラムであって、
   （ａ）前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する機能と、
   （ｂ）前記投稿情報を含む情報である提供情報を生成する機能と、
   （ｃ）前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する機能と、
   （ｄ）前記テキストの中から、地図画像の種類に関連付けられた文字列である地図種文字列を抽出する機能と、
   （ｅ）前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲が同じであるとともに表示される内容が互いに異なる複数種類の地図画像のうちから、前記抽出された地図種文字列に基づいて決定した一種類の地図画像を生成する機能と、
   （ｆ）前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信する機能と、
   をコンピュータに実現させるコンピュータプログラムであり、
   前記複数種類の地図画像は、前記地図画像の種類に応じた異なる種類の地物の位置と名称とをそれぞれ表示する地図画像であり、
   前記一種類の地図画像を生成する機能は、
   前記コンピュータが、複数の地図種文字列と地図画像の種類との対応関係を予め定めた地図種文字列データベースを参照して、前記抽出された地図種文字列に対応する地図画像の種類を決定する機能と、
   前記コンピュータが、前記決定した一種類の地図画像として、前記地図画像の種類に応じた種類の地物の位置と名称とを表示する地図画像を生成する機能と、を含む、コンピュータプログラム。
   をコンピュータに実現させるコンピュータプログラム。
8. ネットワークに接続されたコンピュータに、前記ネットワークを介して情報を提供する処理を実行させるためのコンピュータプログラムであって、
   （ａ）前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する機能と、
   （ｂ）前記投稿情報を含む情報である提供情報を生成する機能と、
   （ｃ）前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する機能と、
   （ｄ）前記テキストの中から、地理的な範囲の大きさに関連付けられた文字列である範囲文字列を抽出する機能と、
   （ｅ）前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲の大きさが互いに異なる複数種類の地図画像のうちから、前記抽出された範囲文字列に基づいて決定した一種類の地図画像を生成する機能と、
   （ｆ）前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信する機能と、
   をコンピュータに実現させるコンピュータプログラム。
9. ネットワークに接続されたコンピュータに、前記ネットワークを介して情報を提供する処理を実行させるためのコンピュータプログラムであって、
   （ａ）前記ネットワークに接続された第１クライアント装置からテキストを含む情報である投稿情報を受信する機能と、
   （ｂ）前記投稿情報を含む情報である提供情報を生成する機能と、
   （ｃ）前記テキストの中から、地理的位置に関連付けられた文字列である位置文字列を抽出する機能と、
   （ｄ）前記抽出された位置文字列に関連付けられた地理的位置を含む地図画像として、地理的な範囲が同じであるとともに時期範囲が互いに異なる複数種類の地図画像のうちから、前記投稿情報に関する時間に基づいて決定した一種類の地図画像を生成する機能と、
   （ｅ）前記ネットワークに接続された第２クライアント装置からの要求に応じて、前記提供情報と前記生成された地図画像とを、前記第２クライアント装置へ送信する機能と、
   をコンピュータに実現させるコンピュータプログラム。

Images