JP2017228115A - 情報を提供するための方法、当該方法をコンピュータに実行させるためのプログラム、および情報を提供するための装置 - Google Patents

Abstract

【課題】街情報が効率よく取得され、また、効率よく提示されるシステムを提供する。
【解決手段】システム１００は、管理部１２０と、通信端末を用いて、名所のように既に知られた場所の写真や動画その他の街情報の提供を要求し閲覧する利用者１３０と、複数のタクシー１１０とを備え、管理部１２０は、複数のタクシー１１０その他の移動体によって取得された情報を蓄積する街情報データベース１２１と、管理部１２０に対する情報の要求に応答して、要求されたデータが街情報データベース１２１に存在するか否かを判定する判定部１２２と、情報を提供するための移動体として登録されている各タクシーの配車状況を保持する配車データベース１２３とを含む。
【選択図】図１

Description

本開示は、情報の収集と提供に関し、より特定的には、位置と時間に関連付けられる情報を提供する技術に関する。

セキュリティカメラのように公共の場所等に設置されるカメラが増えている。今後も、スマートフォンやデジタルカメラのように人が保持するカメラ、自動車に搭載されるカメラ、ドローンに搭載されるロボットカメラのように、カメラの社会需要は更に高まっていくことが想定される。このような社会において、様々な街情報（例えば、人や自動車の流れ、その属性情報、店舗の開閉店の状態、路上駐車の有無など）は、カメラ映像として収集され、画像解析される。それらの街情報の解析結果を、オンデマンドで利用したいというニーズが存在し得る。

情報の収集に関し、例えば、特開２０１５−１９１３５５号公報（特許文献１）は、「移動体を利用するユーザの車内での自然な行動に基づいて、移動体が情報を収集する機会を高め、移動体を情報収集手段として活用して、地域に埋もれている情報の発見に繋がる地域情報発見システム」を開示している（段落０００９）。この地域情報発見システムは、「自動走行可能な移動体と、移動体管理サーバとによる交通システムにおいて、移動体は、乗客の車内映像及び車内音声を、乗客の所定の動作、所定の発言又は所定の操作のうち少なくともいずれかをトリガとし、そのときの車内映像及び車内音声を、移動体の位置情報と移動体がそのときに撮影した車外映像に関連付けて車内情報として記録する。移動体管理サーバは、移動体に記録された車内情報を受信して収集し、車内情報に含まれた車内映像及び車内音声を分析し、乗客が所定の動作、所定の発言又は所定の操作をしたときの車外映像と車外映像の撮影地点の位置情報を関付けして、地域発見情報データベースに格納する。また、このとき記録する車内情報には、乗客がその場で入力した文字情報を付加情報として含ませる。」というものである（［要約］の［解決手段］）。

特開２０１５−１９１３５５号公報

特許文献１に開示された技術によると、地域情報の位置情報は、乗客の発言または動作をトリガにして収集される。しかし、想定される街情報のニーズはそれらのトリガによって得られた地域情報と必ずしも一致すると限らない。また地域情報は時間帯までは考慮されておらず、特定の時間帯の街情報を得たいというニーズに答えることができない。そのため、様々な場所や時間帯の要求が考えられる街情報の要望にオンデマンドで答えられない可能性が高くなる。したがって、要求に応じて地域情報を提供できる技術が必要とされている。

また、多くの地域情報が蓄積されると、要求に応じた情報を検索して提供するまでの時間が長くなる可能性もある。例えば、ドライブレコーダの映像から要求された街情報を得るためには、ドライブレコーダの蓄積する大量の映像情報の中から要求された時間帯と場所の映っている画像を探し出す必要がある。これらを探し出す手段は、多くの時間や作業量を必要とするため、ニーズに対してオンデマンドで即座に答えることができない。したがって、要求された地域情報を効率よく取得するための技術が必要とされている。

本開示は上述のような問題点を解決するためになされたものであって、ある局面における目的は、要求に応じて地域情報を提供するための技術を提供することである。他の局面における目的は、要求された地域情報を効率よく取得するための技術を提供することである。

一実施の形態に従うと、コンピュータが１つ以上の端末に情報を提供するための方法が提供される。この方法は、端末で閲覧可能な情報が存在する場所を特定するための位置情報と情報が取得される時間を特定するための時間情報とを含む要求を端末から受信するステップと、コンピュータと通信可能な１つ以上の移動体に、当該情報を取得する指示を送信するステップと、１つ以上の移動体のうち当該情報を取得した移動体から、時間における場所の情報を受信するステップと、情報を蓄積するステップと、蓄積されている情報から、要求により特定される情報を抽出するステップと、抽出された情報を、要求を送信した端末に送信するステップとを含む。

ある局面において、要求に応じて地域情報を提供することができる。また、別の局面において、要求された地域情報を効率よく取得することができる。

この発明の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解されるこの発明に関する次の詳細な説明から明らかとなるであろう。

第１の形態に係るシステム１００の構成を概念的に表わすブロック図である。 管理部１２０の街情報データベース１２１に保存されているデータのやり取りを表わす図である。 ある局面において取得された映像または画像にふせんが付けられまたはふせんがはずされる一態様を表わす図である。 管理部１２０がふせん付けのルールを変更するために実行する処理の一部を表わすフローチャートである。 ルール生成部２４０が実行する処理の一部を概念的に表わす図である。 街情報データベース１２１に保存されているテーブル６００の構成の一態様を概念的に表わす図である。 別の局面に従ってふせん付けルールを変更する処理の一部を表わすフローチャートである。 別の局面に従うシステム１００における処理の一部を表わすフローチャートである。 ある局面に従って街情報を利用し管理する一態様を概念的に表わす図である。 ある局面に従うシステム１００の構成の一例を表わすブロック図である。 管理装置１０１０の構成を表わすブロック図である。 管理装置１０１０と、利用端末１０４０とが実行する処理の一部を表わすフローチャートである。 ステップＳ１２４０の処理を概念的に表わす図である。 別の局面に従うステップＳ１２４０の処理の内容を概念的に表わす図である。 ステップＳ１２４０の他の局面に従う処理を表わす図である。 管理装置１０１０と取得端末１０２０とが実行する処理の一部を表わすフローチャートである。 複数のタクシーがある場合における映像の取得のコストを算出する一態様を表わす図である。 管理装置１０１０と利用端末１０４０とが実行する処理の一部を表わすフローチャートである。 管理装置１０１０と取得端末１０２０と利用端末１０４０とが実行する処理の一部を表わすフローチャートである。 第２の実施の形態に係るシステムの構成の概要を表わす図である。 管理装置２１００のハードウェア構成の概要を表わすブロック図である。 第３の実施の形態に係るシステムの構成を概念的に表わす図である。 管理装置２３００の構成を表わすブロック図である。 取得端末１０２０または利用端末１０４０として機能する通信端末２４００のハードウェア構成を表わすブロック図である。 管理部１２０、または管理装置１０１０，２１００，２３００として機能するコンピュータ２５００のハードウェア構成を表わすブロック図である。

以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

［技術思想］

まず、本開示に係る技術思想について説明する。本開示に係る技術は、利用者によって時価と場所が指定された遠隔地の映像、音声その他の情報をタクシーその他の移動体に搭載されたカメラその他の情報収集端末を通して、オンデマンドで、見たい利用者に当該映像その他の情報を提供するというものである。

利用者から見ると、例えば、街情報収集を主目的にする車両を活用すると、情報を取得するためのコストが高くなる。本開示に係る技術によれば、すでに車載カメラを搭載していて、街で走行している空車タクシーのような移動体を活用することで、情報の取得コストを低減できる。また、タクシー会社のように移動体を業として運営する企業から見れば、本来のサービスの提供のために使用されていない移動体（例えば、空車タクシー）を、所謂タイムシェアという形式で、有効利用できるので、収益の向上にも寄与し得る。

本開示に係る技術で実行される処理の概要は、以下のとおりである。以下、移動体の一例として、タクシーを例示するが、移動体はタクシーに限られず、宅配バイク、自転車、路線バス等も含み得る。

（１）映像を見たいと思う利用者は、位置情報と時刻とを含む要求を、街情報管理部に送付する。街情報管理部は、例えば、情報提供事業者が運営するコンピュータ装置によって実現される。

（２）街情報管理部は、要求された情報がすでに蓄積されているか否かを判定する。例えば、プロセッサが、ハードディスク装置に構成されている街情報データベースにアクセスして、利用者によって求められた情報が存在しているか否かを判定する。

（３）求められた情報が存在していない場合には、街情報管理部は、情報を取得するため、タクシー配車データベースに含まれているデータ、すなわち、各タクシーの位置座標と、情報取得のために使用可あるいは不可を表す情報とを参照して、目的地の付近にいる使用可のタクシー（すなわち空車のタクシー）に、街情報のデータ取得依頼を、電子メールその他のメッセージの形式で送信する。

（４）データ取得依頼を受けたタクシーは、目的地まで移動して、目的地で撮影を実施した後、街情報管理部に街情報（写真、動画、音声またはこれらの組み合わせ）と、当該街情報に関連付けられた位置情報とを送信する。街情報管理部は、街情報データベースと配車データベースとを更新する。

＜第１の実施の形態＞

以下、本開示に係る第１の実施の形態について説明する。まず、第１の実施の形態に係る街情報の収集方法およびシステムの概要について説明する。

今の街情報を、次の行動の判断情報にしたいという要望を持つ人は数多く存在する。例えば、今現在の桜の名所の開花情報を映像で見れば、今日桜を見に行くか、あるいは見に行かないかをより納得感を持って判断できる。または、これから自動車で通る峠道の今現在における路面の積雪状態を映像で見ることができれば、運転者は、峠道で行けそうなのか、あるいは、迂回路で行くべきかをより納得感を持って判断できる。特に有名な桜の名所であれば、インターネット上のウェブなどで開花映像をライブで流すこともあるかもしれないが、このように映像として情報が提供される名所は全体から見ればごく僅かである。したがって、多くの場所では、今現在の開花情報を知る手段がないのが現状といえる。

［概要］

まず、街情報の利用を希望する人は、映像が欲しい位置や場所と撮影希望時間の情報などを含む映像取得要求を、パーソナルコンピュータまたはスマートフォンを介して、インターネット上に存在する街情報管理者のウェブ画面に入力する。この時、利用者は、当該利用者を識別することができる利用者識別番号（例えば、サービスを受けるための会員番号）等も同時に入力する。この要求は、街情報の管理者（例えば、街情報の提供事業者）が運営するコンピュータに送られる。

映像取得要求を受信したコンピュータは、街情報の価値を算出する。映像取得要求のあった映像が、すでに街情報管理者の保管する街情報データベース（ＤＢ）に蓄積されている過去映像情報の情報タグ（位置情報＋撮影時間など）と合致すれば、コンピュータは、取得価値（取得コスト）は比較的低いと判断し、その判断に応じて取得価値を数値化する。なお、本実施の形態において、街情報の価値は、例えば、以下のようにして算出される。コンピュータは、各移動経路毎に、データ取得予測数（情報の入手の容易性の高低）と、レア度（情報の取得の困難性の程度）と、利用者の要求度（同じ情報を求める利用者の累積人数、あるいは、一定期間中の利用者数）に基づいて、予め定められた計算式に基づいて算出される。レア度や要求度は、予め複数段階にレベル分けされて各レベルに応じて点数が付与されている。

一方、街情報データベースに蓄積されていない映像情報が利用者によって要求された場合には、当該コンピュータは、新たに映像を取得する作業を開始する。この場合、コンピュータは、予め取得契約を締結しているタクシーを利用して、タクシーに搭載されているカメラで街情報を撮影することとする。コンピュータは、利用者から送られた映像取得要求データとタクシーの配車及び走行データから、映像取得コストを算出する。映像の取得が要求された場所から近い場所に空車タクシーが走行していれば、取得コストは安くなる。一方、映像の取得が求められた場所が空車タクシーの走行場所から離れている場合には、取得コストは高くなる。

また、コンピュータは、時間帯別に予測された渋滞情報をさらに考慮して取得コストを計算する。例えば、短距離でも移動にかかる時間が極めて長くなることが予測される場合には、コンピュータは、この予測結果を考慮して、予め定められた規程に則り街情報価値を算出する。コンピュータは、街情報の利用者に電子メールあるいはウェブ画面を用いて取得のための料金を提示する。街情報の利用者は、その料金に納得がいけば提示金額の支払処理を実行する。一方、利用者は、その料金に納得がいかない場合には、映像取得の要求をキャンセルしてもよい。

金額の支払が完了した時点で、コンピュータによって指定されたタクシーが目的地に向かい、目的地に到着した後、車載カメラで映像を撮影する。このとき、撮影した車載カメラに内蔵されている、あるいは、タクシーに搭載されているＧＰＳ（Global Positioning System）の信号に基づく位置情報と当該信号に含まれる時刻情報（または、車載カメラ内蔵されているタイマから得られる時間情報）も、撮影した映像情報と共に、街情報の管理者に運営される当該コンピュータに送られる。

コンピュータは、受信した映像情報と位置情報と時間情報とを街情報データベースに蓄積し、映像取得要求テーブルを参照して、利用者の識別番号に対応する利用者に対して、要求された映像を送信する。街情報の管理者は、例えば契約タクシーでその月内に映像を取得したタクシーに対して、取得コスト（すなわち、街情報の価値）に応じた金額を定期的に（例えば、月毎に）あるいは、都度支払う。

［システム１００の構成］

次に、図１を参照して、システム１００の構成について説明する。図１は、本実施の形態に係るシステム１００の構成を概念的に表わすブロック図である。

システム１００は、情報を収集する移動体としての複数のタクシー１１０と、管理部１２０と、街情報の利用者１３０とを含む。移動体は、タクシー１１０に限られず、物品または人を搬送するために使用される車両であって情報通信機能を備える車両であればよい。より具体的には、移動体は、例えば、自転車、バイク、路線バス、宅配トラックその他の車両を用いて実現される。情報通信機能は、例えば、撮影機能、集音機能等を含み得る。情報通信機能は、車両に対して着脱式あるいは固定式の通信装置によって実現される。通信装置は、例えば、スマートフォン、タブレット端末その他の情報通信機器、あるいは、車両に組み込まれたカメラや通信機器として実現される。以下の説明では、タクシーでの実施について説明を行う。

管理部１２０は、街情報データベース１２１と、判定部１２２と、配車データベース１２３とを含む。ある局面において、管理部１２０は、周知の構成を有するコンピュータ装置として実現され得る。管理部１２０は、例えば、情報提供事業者により運営される。街情報データベース１２１は、複数のタクシー１１０その他の移動体によって取得された情報を蓄積する。当該情報は、例えば、名所のように既に知られた場所の写真や動画を含む。当該情報は、その場所で得られた音声（例えば、鳥の鳴き声、滝の音等）を含んでもよい。さらに、当該情報は、写真、動画あるいは音声が取得された日時を含む。当該日時は、システム１００によって提供される情報の利用者から指定された日時、その場所においてイベントその他の行事が行なわれる時として予め定められた日時等を含む。

判定部１２２は、管理部１２０に対する情報の要求に応答して、要求されたデータが街情報データベース１２１に存在するか否かを判定する。さらに、要求されたデータが街情報データベース１２１に存在しない場合は、配車管理部１２４によって要求された情報の位置に最も早くアクセスが可能で使用が可能であるタクシーを、情報が要求された場所に向かわせるよう指示を送る。

配車データベース１２３は、情報を提供するための移動体として登録されている各タクシーの配車状況を保持する。より具体的には、配車データベース１２３は、例えば、各タクシーの識別データと、各タクシーの現在地の位置座標と、各タクシーが情報収集端末として機能し得るかどうかを表すデータとを含む。例えば、あるタクシーが乗客を乗せて走行している場合には、当該タクシーが情報収集端末として使用できないことを表すフラグが当該タクシーのデータレコードに付されている。また、あるタクシーが乗客を乗せていない場合には、当該タクシーは情報収集端末として使用できることを表すフラグが当該タクシーのデータレコードに付されている。なお、街情報データベース１２１と配車データベース１２３とは、判定部１２２として機能するコンピュータの内部または外部のいずれにおいても実現可能である。

利用者１３０は、例えば、スマートフォン、タブレット端末その他の情報通信端末を使用する個人あるいは法人その他の団体であり得る。

次に、システム１００における情報の要求および提供の流れについて説明する。

ステップＳ１４０にて、街情報の利用者１３０は、管理部１２０に対して、データの位置情報と、時刻情報とを送信する。例えば、利用者１３０が、コンピュータと通信可能な携帯情報端末においてアプリケーションプログラムを起動すると、携帯情報端末は、必要な情報の要求を受け付ける画面を表示する。より具体的には、利用者１３０がスマートフォンに表示された画面を操作して、情報を必要とする場所を特定するデータと、その情報が取得される日時を特定するデータとを入力する。場所を特定するデータの入力は、タッチ操作に基づく文字入力によってまたは発話に基づく音声入力によって実現される。別の局面において、場所を特定するデータは、スマートフォンのモニタに表示される地図が利用者１３０によってタッチされることによって入力されてもよい。

ステップＳ１５０にて、判定部１２２は、位置情報と時刻情報とを利用者１３０から受信すると、利用者１３０によって要求されたデータが街情報データベース１２１上にあるか否かを判定する。判定部１２２は、例えば、コンピュータのプロセッサが判定処理を実行することにより実現される。

要求されたデータが街情報データベース１２１にない場合（ステップ１６０）、ステップ１６５にて、配車管理部１２４は、配車データベース１２３に格納されているデータに基づいて、どのタクシーを向かわせるか判定する。この処理が実行されると、情報取得端末としてのタクシーが決定される。配車データベース１２３に格納されているデータは、例えば、情報取得端末として登録された各タクシーの識別番号、現在の位置、乗客を乗せて走行しているか否かを表すステータス情報等を含む。

ステップＳ１７０にて、配車管理部１２４は、決定したタクシーに対して、利用者１３０によって要求された位置に向かうように指示を送信する。当該指示は、例えば、目的地、情報を取得する時間、取得される情報の内容（静止画あるいは動画）、情報の数（写真の撮影枚数、動画の撮影時間等）を含む。目的地は、利用者１３０によって与えられた位置情報に基づいて、車両に搭載されたカーナビゲーションシステムに反映される。時間は、情報の取得が要求された日時を含む。なお、情報の取得が要求された日時と、当該要求が利用者１３０によって与えられた日時との間隔と、当該決定されたタクシーによる目的地までの移動時間との差が大きくない場合、例えば、一時間以内である場合には、当該タクシーは、目的地に向かうようにカーナビゲーションシステムが音声案内を開始し得る。当該差が大きい場合、例えば、翌日以降の情報の取得が要求された場合には、配車管理部１２４は、当日に、配車データベース１２３にアクセスして、当日の配車状況に応じて、情報を取得させるタクシーを決定し得る。

ステップＳ１８０にて、情報を取得するように管理部１２０によって決定されて指示されたタクシーは、指示された位置に向かい、車載カメラを用いて街情報を撮影し、その撮影が行なわれた位置座標と時間情報とを管理部１２０に送信する。管理部１２０は、受信した各データを互いに関連付けて、街情報データベース１２１に保存する。

ステップＳ１９０にて、管理部１２０は、ステップＳ１４０において要求されたデータを利用者１３０が使用している携帯情報端末に送信する。

図２を参照して、本実施の形態に係るシステム１００についてさらに説明する。図２は、管理部１２０の街情報データベース１２１に保存されているデータのやり取りを表わす図である。ある局面において、管理部１２０は、情報検索部２２０と、ルール生成部２４０とをさらに備える。ルール生成部２４０は、ルール判定要素データ２３０に基づいてルールを生成する。情報検索部２２０とルール生成部２４０とは、プロセッサによって実現される。街情報データベース１２１は、画像映像＋付加情報２１０と、ふせん付け／はずしルール２１１とをさらに含む。ふせん付け／はずしルール２１１は、ある局面において、例えば、街情報の管理者によって付与基準あるいは除外基準として予め規定され得る。付与基準は、例えば、利用者による閲覧の希望が多いと予想される名所、草木等を含む。管理者が、名所や草木を指定すると、これらを含む画像あるいは映像にはふせん情報が付されるべきものとして、ふせん付け／はずしルール２１１を更新する。また、管理者が、名所や草木の指定を削除すると、これらを含む画像あるいは映像にはふせん情報が付されないように、ふせん付け／はずしルール２１１を更新する。

次に、ふせん付けのルールの生成について説明する。

ステップＳ２５０にて、ルール生成部２４０は、ルール判定要素データ２３０を読み込む。ルール判定要素データ２３０は、たとえば、街情報の利用回数、暦情報、時間情報、利用者検索キーワードのランキング、ＳＮＳで話題のキーワードのランキングなどを含み得る。

ルール生成部２４０は、そのデータを用いてふせん付け／はずしルール２１１としてルールを書き込む。たとえば、ある局面において、街情報の利用者１３０による利用が多くなると、ルール生成部２４０は、推測される画像または映像にふせんを付け、利用が少なくなると推測される画像映像に対してふせんを外す。ルール生成部２４０は、複数のルール判定要素データを組合せて、ふせん付けのルールまたはふせんはずしのルールを生成する。

なお、本実施の形態において、「ふせん」とは、画像または映像に紐付けられる特定の付加情報をいう。ふせん付け／はずしルール２１１は、たとえば、画像２１２および２１３、ならびに映像２１４にそれぞれ適用される。図２に示される例では、ある局面において、画像２１２にはふせん２８０が付けられている。

次に、利用者１３０と、街情報データベース１２１との間の処理について説明する。

ステップＳ２６０にて、利用者１３０は、データの位置情報と時刻情報とを含む要求を管理部１２０に送信する。管理部１２０は、情報検索部２２０を含む。この要求は、情報検索部２２０によって処理される。

ステップＳ２６５にて、情報検索部２２０は、街情報データベース１２１にアクセスして、最初に、ふせん付き情報から利用者１３０によって要求された情報を検索する。情報検索部２２０は、ふせん付き情報に要求されたデータがない場合には、さらに、ふせんなしデータを検索する。ある局面において、ふせんは、当該ふせんが付された情報が予め定められた回数以上要求されることを示す。最初に、ふせん付き情報を検索することにより、頻繁に求められる情報が検索されるので、利用者１３０によって要求されるデータが、ふせん付きの情報であれば、検索結果が速やかに得られるので、利用者１３０に対する応答レスポンスが向上し得る。

ステップＳ２７０にて、情報検索部２２０は、街情報データベース１２１から情報の検索結果を取得する。

ステップＳ２７５にて、情報検索部２２０は、要求されたデータを利用者１３０に送信する。

［ふせん付け／はずしのルール］

図３を参照して、ふせん付け／はずしのルールについて説明する。図３は、ある局面において取得された映像または画像にふせんが付けられまたはふせんがはずされる一態様を表わす図である。

一実施の形態に従うと、街情報データベース１２１は、画像映像＋付加情報を保持している。画像映像＋付加情報は、たとえば画像２１２，２１３と映像２１４と、ふせんとにより構成される。

ステップＳ３１０にて、ルール生成部２４０は、ふせん付けルールを変更する。この変更により、たとえばふせん付け／はずしルール２１１が更新される。管理部１２０は、更新後のふせん付け／はずしルール２１１に基づいてたとえば画像２１２にふせん３２０を追加する。街情報データベース１２１は、ふせん３２０が追加された画像２１２を保持する。

ステップＳ３３０にて、ルール生成部２４０は、ふせんはずしのルールを変更する。この変更に基づいてふせん付け／はずしルール２１１が更新される。管理部１２０は、更新後のふせん付け／はずしルール２１１に基づいて画像２１２に付されていたふせん３２０を外す。街情報データベース１２１は、ふせん３２０がはずされた画像２１２を保持する。その他の画像２１３あるいは映像２１４は従来と同様である。

図４を参照して、ふせん付け／はずしルールについてさらに説明する。図４は、管理部１２０がふせん付けのルールを変更するために実行する処理の一部を表わすフローチャートである。

ステップＳ４１０にて、ルール生成部２４０は、ふせん付けルールを変更する。たとえば、ある局面において、ふせん付けルールの対象の例として桜の花の開花が考えられる。たとえば、ふせんが付される情報は、取得される時期が３月２５日から４月１５日までであり、取得される位置が関東地方であるような情報である。この場合、ルール生成部２４０は、暦に紐付けられた過去の履歴ルールに従い、該当の開始日時が到来すると、指定された位置（関東地方）において取得された情報（写真、動画、音声）にふせんを追加する。

ステップＳ４２０にて、ルール生成部２４０は、ふせん付け／はずしルールを変更する。たとえば、ふせんを外すルールとして、対象が桜の花であり暦は３月２５日から４月１５日であり、位置は関東地方である。ふせん付けのルールとして、対象は桜の花であり、暦は４月１５日から５月１０日であり、位置は東北地方である。

ステップＳ４３０にて、ルール生成部２４０は、ふせんはずしルールを変更する。たとえば、その対象は桜の花であり、暦は４月１５日から５月１０日であり、位置は東北地方である。該当の終了日時が到来すると、ルール生成部２４０は、ふせんはずしルールを自動的に生成する。

［制御構造］

図５を参照して、管理部１２０の制御構造について説明する。図５は、ルール生成部２４０が実行する処理の一部を概念的に表わす図である。ある局面において、利用者１３０は、管理部１２０に対して入力情報５０１を送る。入力情報５０１は、たとえば利用者１３０によって指定されたデータ（位置情報、日時）と、当該データの提供の要求とを含む。

ステップＳ５１０にて、管理部１２０は、指定された日時が到来したことを検出する。

ステップＳ５２０にて、管理部１２０は、ルール生成部２４０に対して、利用者１３０によって指示された日時が到来したことを通知する。

ステップＳ５３０にて、ルール生成部２４０は、３月２５日に紐付けされた履歴ルールを街情報データベース１２１から読み出す。

ステップＳ５４０にて、ルール生成部２４０は、履歴ルールが既にふせん付けルールに設定済であるか否かを判断する。この判断は、たとえばふせん付け／はずしルール２１１に格納されているデータに基づいて行なわれる。ルール生成部２４０は、履歴ルールが既にふせん付けルールに設定されていると判断すると（ステップＳ５４０にてＹＥＳ）、制御をステップＳ５３０に戻す。そうでない場合には（ステップＳ５４０にてＮＯ）、ルール生成部２４０は、制御をステップＳ５５０に切り換える。

ステップＳ５５０にて、ルール生成部２４０は、３月２５日に紐付けされた履歴ルールをふせん付け／はずしルール２１１において確保された領域に書き込む。

ステップＳ５６０にて、ルール生成部２４０は、履歴ルールを書き込んだことを情報検索部２２０に通知する。

ステップＳ５７０にて、情報検索部２２０は、３月２５日に紐付けされた履歴ルールをふせん付けルールに書き込む。

［データ構造］

図６を参照して、システム１００のデータ構造について説明する。図６は、街情報データベース１２１に保存されているテーブル６００の構成の一態様を概念的に表わす図である。テーブル６００は、データベース番号６１０と、緯度６２０と、経度６３０と、取得時間６４０と、タグ６５０と、取得者ＩＤ６６０と、利用回数６７０と、最終利用日６８０と、ふせんフラグ６９０とを含む。

データベース番号６１０は、各データレコードを識別する。緯度６２０は、情報が取得された緯度を表す。経度６３０は、当該情報が取得された経度を表す。取得時間６４０は、当該情報が取得された日時を表す。タグ６５０は、当該情報に関連付けられるタグを表す。タグは、例えば、取得された写真から抽出されたものを表す。抽出されたものは、例えば、人（HUMAN）、車（CAR）、花（FLOWER）等であるば、タグが付される対象は図示されたものに限られない。

取得者ＩＤは、当該情報を取得した移動体（例えば、タクシー、宅配便のバイク等）を識別する。取得者ＩＤは、当該情報を取得する取得端末として予め登録された移動体に付与される。

利用回数６７０は、当該情報が利用者によって要求された回数を表す。最終利用日６８０は、当該情報が最後に利用された年月日を表す。ふせんフラグ６９０は、当該情報にふせんが付されていることを表す。図６に示される例では、データベース番号６１０が１１５５である情報の利用回数６７０が最多（６回）である。そこで、当該情報が頻繁に利用されることを示すふせんフラグ６９０がオン（＝１）に設定されている。
ここで、ふせんフラグ６９０について説明する。ある局面において、ドライブレコーダの画像解析によるタグ情報のみでは、例えば、花の種類までは知ることができない。そのため、特定の花が咲いているか否か等の開花情報を知りたい時は、ネットワークから専用画像解析ソフトをダウンロードして解析を行い、他の解析結果から、当該情報をもたらす解析結果を区別するための印をふせんとして当該解析結果に付与する。例えば、検索キーワードなどで「桜」が人気ワードとなった場合、ユーザは、ネットワークからドライブレコーダに桜を画像解析させるソフトウェアをダウンロードする。解析の結果、桜が画像から認識された場合、管理部１２０は、解析された場所の位置情報とタグ情報から、該当するエントリのふせんフラグをオンに設定する。なお、ふせんが付される画像の一例として花の場合が説明されたが、ふせんが付される対象は、花に限られない。

さらに別の局面において、テーブル６００は、各情報を要求した利用者の所在地を蓄積してもよい。このようにすると、特定の情報を求める利用者がどこに集中しているかを知ることが可能となる。

図７を参照して、ふせん付け／はずしルールについてさらに説明する。図７は、別の局面に従ってふせん付けルールを変更する処理の一部を表わすフローチャートである。

ステップＳ７１０にて、ルール生成部２４０は、ふせん付けルールを変更する。ふせん付けルールの対象は、たとえば桜の花であり暦は３月２３日から４月１５日であり、位置は関東地方である。ある局面において利用者１３０が検索画面において検索キーワードとして桜および関東を入力したとする。このような検索キーワードが複数の利用者によって入力されると、ルール生成部２４０は、その入力結果に基づいて新たなふせん付けルールを生成する。

ステップＳ７２０にて、ルール生成部２４０は、ふせん付けルールを変更するか否かを判断する。たとえば、３月２５日が到来した場合、ルール生成部２４０は、ステップＳ７１０において生成したルールを反映するか否かを判断する。この場合、ステップＳ７１０において生成されたルールの暦は、３月２３日から４月１５日である。一方、ふせん付け／はずしルール２１１には、ふせん付けルールとして対象が桜の花であり、暦の３月２５日から４月１５日であり、位置は関東地方であるというルールが既に存在する。したがって、ルール生成部２４０は、３月２５日に紐付けされた履歴ルールが存在することを確認すると、３月２５日におけるふせん付けのルール変更をキャンセルする。

図８を参照して、システム１００の制御構造についてさらに説明する。図８は、別の局面に従うシステム１００における処理の一部を表わすフローチャートである。この局面において、入力情報８０１は、利用者１３０によって入力される（ステップＳ２６０）。情報検索部２２０は、その入力情報８０１に基づいて、ステップＳ８１０にて、検索キーワードの検索値「３月２３日」が上昇したことを検出する。

ステップＳ８２０にて、情報検索部２２０は、ルール生成部２４０に対して、検索キーワードのレベルが上昇したことを通知する。

ステップＳ８３０にて、ルール生成部２４０は、桜および関東で紐付けられた履歴ルールを街情報データベース１２１から読み出す。

ステップＳ８４０にて、ルール生成部２４０は、読み出したルールを変更する。ルール生成部２４０は、ルール変更を行なったことを出力する。

ステップＳ８５０にて、管理部１２０は、変更されたルールをふせん付け／はずしルール２１１に書き込む。

ステップＳ８６０にて、情報検索部２２０は、管理部１２０から出力される時刻データに基づいて指定された日時（３月２５日）が到来したことを検出する。情報検索部２２０は、その日時を検出したことをルール生成部２４０に通知する。

ステップＳ８７０にて、ルール生成部２４０は、３月２５日に紐付けされた履歴ルールをふせん付け／はずしルール２１１から読み出す。

ステップＳ８８０にて、ルール生成部２４０は、履歴ルールが既にふせん付けルールに設定されているか否かを判断する。

ルール生成部２４０は、履歴ルールが既にふせん付けルールに設定されていると判断すると（ステップＳ８８０にてＹＥＳ）、制御をステップＳ８７０に戻す。そうでない場合には（ステップＳ８８０にてＮＯ）、ルール生成部２４０は、予め定められた次の処理を実行する。

図９を参照して、街情報の収集および利用について説明する。図９は、ある局面に従って街情報を利用し管理する一態様を概念的に表わす図である。

街情報利用者モジュール９１０は、たとえば、画像９１１，９１２，９１３を見たいという利用者９１４に相当する。

街情報管理モジュール９２０は、システム１００の管理部１２０によって実現される。具体的には、街情報管理モジュール９２０は、街情報データベース１２１と、街情報価値の算出モジュール９２１とを含む。算出モジュール９２１は、蓄積済の街情報データベース９２３と、映像取得コストを算出して数値化する処理が行なわれるステップＳ９２２と、配車データベース１２３とを含む。

街情報取得モジュール９３０は、ステップＳ９３１と、ステップＳ９３２とを含む。ステップＳ９３１は、車載カメラで撮影して映像を管理者へ送信することを含む。ステップＳ９３２は、取得端末（例えば、タクシーに搭載された車載カメラ、情報通信端末、スマートフォン等）が備えるＧＰＳ（Global Positioning System）で位置を測定し、また当該端末が備えるタイマで時間を記録することを含む。

より具体的には、ステップＳ９４０にて、利用者９１４は、映像取得要求を、街情報管理モジュール９２０として機能するシステム１００に送信する。この要求は、位置情報と時刻情報とを含む。街情報管理モジュール９２０は、その要求を受信すると、算出モジュール９２１として、ステップＳ９２２を実行し、映像取得コストを計算する。

ステップＳ９４１にて、街情報管理モジュール９２０は、要求された映像を取得するために必要な金額を提示する。

ステップＳ９４２にて、街情報の利用者９１４は、その金額を見て納得する場合はＯＫを回答し、示された代金を支払う。

ステップＳ９４３にて、街情報管理モジュール９２０は、街情報取得モジュール９３０に対して、タクシー配車システムにて目的地付近の登録済の空車タクシーに映像の取得を依頼する。その依頼に基づき、その依頼を受けたタクシーは、指示された位置に向かって走行し、車載カメラ（図示しない）を用いて映像を取得する。

ステップＳ９４４にて、当該空車タクシーは、取得した映像を街情報管理モジュール９２０に送信する。

ステップＳ９４５にて、街情報管理モジュール９２０は、街情報取得モジュール９３０から送られた映像データを街情報利用者モジュール９１０に送信する。

ステップＳ９４６にて、街情報管理モジュール９２０は、街情報取得モジュール９３０に対して、所定の代金を支払う。例えば、街情報管理モジュール９２０は、情報を取得したタクシーのアカウントに当該代金を支払う。

［システム１００の構成］

図１０を参照して、システム１００の構成についてさらに説明する。図１０は、ある局面に従うシステム１００の構成の一例を表わすブロック図である。システム１００は、管理装置１０１０と、取得端末１０２０と、利用端末１０４０とを備える。

管理装置１０１０は、周知の構成を有するコンピュータによって実現される。取得端末１０２０は、タクシーその他の移動体に搭載される。取得端末１０２０は、例えば、カメラ、マイク、通信装置を含むスマートフォン、タブレット、ドライブレコーダ等により実現される。利用端末１０４０は、情報の利用者によって使用される。利用端末１０４０は、例えば、スマートフォンその他の情報通信端末によって実現される。

取得端末１０２０は、制御部１０２１と、センサ部／撮影部１０２２と、街データ蓄積データベース１０２３と、位置情報取得部１０２４と、表示部１０２５と、入出力部１０２６と、送信部１０２７と、ユーザ識別子１０２８と、街データ抽出部１０２９と、情報提供可否選択部１０３０と、受信部１０３１とを含む。各構成は、それぞれバス１０３２に接続されている。

制御部１０２１は、取得端末１０２０の動作を制御する。制御部１０２１は、タイマその他の計時機能も含む。制御部１０２１は、例えばプロセッサにより実現される。

センサ部／撮影部１０２２は、取得端末１０２０の外部の情報を検出する。また、センサ部／撮影部１０２２は、取得端末１０２０のレンズ（図示しない）が向けられた方向の景色を撮影する。

街データ蓄積ＤＢ１０２３は、センサ部／撮影部１０２２によって取得された情報をデータベースとして蓄積する。街データ蓄積ＤＢ１０２３は、例えば、ハードディスク装置、フラッシュメモリ、外部メモリ等に作成される。

位置情報取得部１０２４は、取得端末１０２０の位置を検出する。位置情報取得部１０２４は、例えば、ＧＰＳその他の測位回路によって実現される。他の局面において、位置情報取得部１０２４は、近傍の無線基地局の位置を、取得端末１０２０の位置として取得してもよい。

表示部１０２５は、取得端末１０２０において取得された映像や取得端末１０２０が受信した文字その他の情報を表示する。表示部１０２５は、たとえば、タッチパネル式のモニタとして実現される。

入出力部１０２６は、取得端末１０２０に対する命令の入力を受け付ける。また、ある局面において、入出力部１０２６は、音声を出力し、あるいは、ＬＥＤ（Light Emitting Diode）を点灯し得る。

送信部１０２７は、取得端末１０２０で取得された情報（静止画像、動画像、音声、取得日時等）を管理装置１０１０に送信する。送信部１０２７は、例えば、移動体通信網の電話回線、ＷｉＦｉ（Wireless Fidelity）等により実現される。

ユーザ識別子１０２８は、取得端末１０２０を識別するデータであって、フラッシュメモリその他の記憶装置に格納されている。

街データ抽出部１０２９は、画像処理認識技術を用いて、センサ部／撮影部１０２２によって取得された画像から、予め定められた特徴を抽出する。予め定められた特徴は、例えば、管理装置１０１０によって指定される。当該特徴は、例えば、名所の風景、桜その他の草木の花等を含む。

情報提供可否選択部１０３０は、取得した情報を管理装置１０１０に送信してもよいか否かを判断する。例えば、情報提供可否選択部１０３０は、情報の取得に応じた対価が支払われていることを確認すると、取得した情報を管理装置１０１０に送信する。情報提供可否選択部１０３０は、プロセッサまたは当該処理を実行するように構成された回路として実現される。

受信部１０３１は、管理装置１０１０から情報を受信する。受信する情報は、利用者１３０により要求された情報の取得要求、取得場所、取得日時、当該情報の取得と提供に対して支払われる対価等を含む。受信部１０３１は、移動体通信網の電話回線、ＷｉＦｉ等により実現される。

図１０を再び参照して、利用端末１０４０は、制御部１０４１と、受信部１０４２と、送信部１０４３と、表示部１０４４と、入力部１０４５と、ユーザ識別子１０４７と、街データ蓄積データベース１０４８とを含む。各構成は、それぞれバス１０４９に接続されている。

制御部１０４１は、利用端末１０４０の動作を制御する。制御部１０４１は、例えばプロセッサにより実現される。

表示部１０４４は、利用端末１０４０において保持されている映像、文字その他の情報を表示する。表示部１０４４は、たとえば、タッチパネル式のモニタとして実現される。

入力部１０４５は、利用端末１０４０に対する命令の入力を受け付ける。入力部１０４５は、タッチセンサ、ハードスイッチ等により実現される。

送信部１０４３は、利用者１３０により要求された情報の提供要求を管理装置１０１０に送信する。送信部１０２７は、例えば、移動体通信網の電話回線と通信可能な回路、ＷｉＦｉモジュールその他の通信回路により実現される。

ユーザ識別子１０４７は、利用端末１０４０を識別するデータであって、フラッシュメモリその他の記憶装置に格納されている。

街データ蓄積ＤＢ１０４８は、受信部１０４２によって受信された情報をデータベースとして蓄積する。街データ蓄積ＤＢ１０４８は、例えば、ハードディスク装置、フラッシュメモリ、外部メモリ等に作成される。

［管理装置１０１０の構成］

図１１を参照して、管理装置１０１０の詳細について説明する。図１１は、管理装置１０１０の構成を表わすブロック図である。管理装置１０１０は、制御部１１００と、配車データベース１２３と、街情報データベース１２１と、取得要求テーブル１１３０と、累積ポイントテーブル１１４０と、通信部１１５０と、判定部１２２と、ポイント算出部１１７０と、情報検索部１１８０と、ルール生成部２４０とを備える。通信部１１５０は、取得端末１０２０または利用端末１０４０とそれぞれ通信可能である。各構成は、それぞれバス１１９１に接続されている。

制御部１１００は、管理装置１０１０の動作を制御する。制御部１１００は、例えば、プロセッサにより実現される。

配車データベース１２３は、移動体としてのタクシーの配車状況を保持している。移動体として、宅配バイク、路線バス、自転車その他の車両が使用される場合には、各車両の運行状況が配車データベース１２３に保持される。

街情報データベース１２１は、取得端末１０２０によって取得された街の情報を保持している。街の情報は、静止画、動画、音声、取得日時、抽出された特徴データ等を含む。

取得要求テーブル１１３０は、各利用端末１０４０から送られた情報の取得要求を保持している。取得要求テーブル１１３０は、例えば、各利用端末１０４０の識別データ、取得が要求された場所の位置情報、取得の日時、取得される情報の形式（静止画、動画、音声の有無）等を含む。管理装置１０１０は、これらの項目を含む要求を取得端末１０２０に送信する。

累積ポイントテーブル１１４０は、各取得端末１０２０について、情報の取得と提供に応じたポイントを蓄積している。当該ポイントは、各取得端末１０２０による情報の提供に対して支払われる対価の計算に用いられる。例えば、頻繁に利用される情報を提供する取得端末１０２０には、通常のポイントに加えて一定割合で加算されたポイントが付与され得る。

通信部１１５０は、インターネットや移動体電話通信網を介して、取得端末１０２０や利用端末１０４０と通信する。

判定部１２２は、利用端末１０４０によって要求された情報が街情報データベース１２１に存在しているか否かを判定する。また、判定部１２２は、情報を取得するために、配車データベース１２３に基づいて、いずれの移動体を現地に向かわせるかを判定する。

ポイント算出部１１７０は、取得端末１０２０により取得された情報の利用頻度に基づいて、当該情報をランク付けするためのポイントを算出する。例えば、利用端末１０４０による情報の要求について、予め定められたポイントが当該情報に加算される。別の局面において、ポイント算出部１１７０は、利用頻度について予め規定された基準値と、情報のレア度について予め設定されたレベル別の基準値とに基づいて、ポイントを算出する。

情報検索部２２０は、利用端末１０４０からの要求に応じて、街情報データベース１２１にデータが保存されているか否かを判断する。

ルール生成部２４０は、１つ以上のルール判定要素を用いて、各情報に普選を付す場合のルールおよびふせんを外すためのルールを生成する。ルールの生成に用いられるルール判定要素は、街情報の利用回数、暦情報、時間情報、位置情報、利用者検索キーワードランキング、ＳＮＳ（Social Network Service）で話題のキーワードランキング等を含む。

ある局面において、利用者による情報の要求が利用端末１０４０から管理装置１０１０に送信される。要求を受信した管理装置１０１０は、管理装置１０１０内にある数多く存在する要求に対応するために要求テーブルを保有しており、新たな要求データに対して一意の番号（管理ＩＤ）をつけて登録する。管理装置１０１０は、新たに登録された要求データの内容を検索して、過去の要求であれば、管理装置１０１０に管理されている街情報データベース１２１の街情報テーブルを参照して、要求されているデータの有無を確認する。当該データが街情報データベース１２１に「有る」場合には、管理装置１０１０は、予め決められている規定に従い、比較的安い請求金額を算出する。一方、当該データが街情報データベース１２１に「ない」場合には、管理装置１０１０は、街情報を取得するために目的地まで移動することについて予め承諾されているタクシーの配車データを用いて、取得希望時間に近い時間帯で取得位置に最も近いタクシーを選択する。管理装置１０１０は、その選択したタクシーに対して、電子メール、ＳＭＳ（Short Message Service）その他の通信手段を用いて、要求データ（位置＋時間＋管理ＩＤ）を送信する。

要求データを受信したタクシーの運転手は、対応の可否を応答する。当該タクシーが要求に対応可能である場合には、管理装置１０１０は、タクシーの移動距離及び予想時間から、予め決められている規程に従い、取得コストを算出して、利用者に請求する金額を決定し、利用端末１０４０に金額を通知する。

利用端末１０４０の利用者が、管理装置１０１０から送信された金額を見て承諾する旨を回答すると、管理装置１０１０は、例えば、クレジットカードなどを利用したネット決済システムを利用した支払処理を実行する。管理装置１０１０は、支払処理の完了を確認すると、当該タクシーに映像取得依頼を電子メール等で送信する。

当該タクシーは、映像取得依頼を受信すると、車載ナビゲーションシステムに目的地を入力し、ナビゲーションシステムからの音声案内等に従って要求場所に向かう。取得端末１０２０が目的地に到達すると、周りの風景を車載カメラで撮影し、取得した映像を管理装置１０１０に送信する。

管理装置１０１０は、撮影された映像を、管理番号識別子に従い、利用端末１０４０に送信し、また街情報データベース１２１にも蓄積する。蓄積の際、街情報を管理するテーブル６００の内容（例えば、位置情報、取得時間、取得者など）が更新される。同時に、配車データも更新される。映像の取得者に対しては、一か月などの一定期間において映像その他の情報を取得するために要した費用に応じて、管理装置１０１０の管理者から費用が支払われる。

［制御構造］

以下、本開示に係る街情報の収集プロセスの概要について説明する。

図１２を参照して、システム１００の制御構造について説明する。図１２は、管理装置１０１０と、利用端末１０４０とが実行する処理の一部を表わすフローチャートである。

ステップＳ１２１０にて、利用端末１０４０のプロセッサは、映像取得要求が入力されたことを検出する。

ステップＳ１２２０にて、利用端末１０４０は、入力された要求から得られた位置情報と時間情報と利用者の識別情報とを、管理装置１０１０に送信する。

ステップＳ１２３０にて、管理装置１０１０は、入力された要求を取得要求テーブル１１３０に入力する。要求データを受信した管理装置１０１０は、管理装置１０１０内にある数多く存在する要求に対応するために要求テーブルを保有しており、新たな要求データに対して一意の要求管理番号をつけて登録する。

ステップＳ１２４０にて、制御部１１００は、要求された映像が街情報データベース１２１に蓄積済であるか否かを判断する。管理装置１０１０は、新たに登録された要求データの内容を検索して、現時刻より過去の要求であれば、管理装置１０１０に管理されている街情報データベースの街情報テーブルを参照して要求されているデータの有無を判断する。制御部１１００は、要求された映像が街情報データベース１２１に蓄積済であると判断すると（ステップＳ１２４０にてＹＥＳ）、制御をステップＳ１２５０に切り換える。そうでない場合には（ステップＳ１２４０にてＮＯ）、制御部１１００は、制御をステップＳ１６００に切り換える。

ステップＳ１２５０にて、制御部１１００は、予め決められている規定に従い、比較的安い街情報価値（＝請求金額）を算出する。例えば、要求された映像が既に蓄積されていれば、取得コストは不要であるため、制御部１１００は、取得コストが含まれていない請求金額を街情報価値として算出し得る。

ステップＳ１２６０にて、制御部１１００は、請求金額を決定する。たとえば、ある局面において、制御部１１００は、予め定められた固定の一定価格を請求金額として決定してもよい。別の局面において、制御部１１００は、請求金額を検索要求の頻度に応じて決定してもよい。

ステップＳ１６００にて、制御部１１００は、要求された映像の取得問い合せ処理を実行する。この処理が実行されると、街情報の取得の可否の問い合わせが、管理装置１０１０によって選定された１つ以上の取得端末１０２０に送信される。この処理の詳細は、後述する。

ステップＳ１８００にて、制御部１１００は、後述する映像配信処理を実行する。この処理が実行されると、街情報は、その要求を送信した利用端末１０４０に送信される。

図１３を参照して、システム１００の制御構造についてさらに説明する。図１３は、ステップＳ１２４０の処理を概念的に表わす図である。ある局面において、街情報データベース１２１にはテーブル６００が保存されている。一実施の形態として、管理装置１０１０は、街情報データベース１２１に画像、映像その他の情報を蓄積する時に、画像処理技術等を用いて当該情報を解析して、利用端末１０４０の利用者によって提供が要求されると考えられる対象物を抽出し、その対象物にタグを付し、対象物とタグとを関連付けて保存してもよい。当該対象物は、例えば、花、看板、人、自動車、特定の場所の景色、転記（例、空模様）等を含み得る。

より詳しくは、ステップＳ１３１０にて、取得された画像のデータが新たにデータベースに蓄積されるとき、ルール生成部２４０は、たとえば「FLOWER」のタグを画像に付する。たとえば、データベース番号６１０が「１１５５」であるデータレコードについて、映像には、「FLOWER」のタグが付されている。また、ふせん１３２１，１３２２，１３２０がその映像に付されている。その後、処理はステップＳ１２４２に移される。

図１４を参照して、街情報の蓄積および検索の別の態様について説明する。図１４は、別の局面に従うステップＳ１２４０の処理の内容を概念的に表わす図である。

ある局面において、映像を取得するべき旨の要求１４１０は、緯度１４１２と、経度１４１３と、取得時間１４１４と、選択肢１４１５と、識別情報１４１６とを含む。緯度１４１２と経度１４１３とは、映像が存在している場所を表す。取得時間１４１４は、映像の取得が行なわれるべき（あるいは、行なわれた）時間を表す。選択肢１４１５は、検索のオプションとして、例えばふせんフラグの有無を表す。図１４に示される例では、選択肢１４１５として、タグに「FLOWER」が付された映像が検索対象として指定されている。識別情報１４１６は、要求１４１０を識別する。

データレコード１４２０は、データベース番号１４２１と、緯度１４２２と、経度１４２３と、取得時間１４２４と、タグ１４２５と、取得者ＩＤ１４２６と、利用回数１４２７と、最終利用日１４２８と、ふせんフラグ１４２９とを含む。

データベース番号１４２１と、緯度１４２２と、経度１４２３と、取得時間１４２４と、タグ１４２５と、取得者ＩＤ１４２６と、利用回数１４２７と、最終利用日１４２８と、ふせんフラグ１４２９とは、それぞれ、データベース番号６１０と、緯度６２０と、経度６３０と、取得時間６４０と、タグ６５０と、取得者ＩＤ６６０と、利用回数６７０と、最終利用日６８０と、ふせんフラグ６９０と同様である。ふせんフラグ１４２９は、データレコード１４２０にはふせんが付されていることを表す。

別の局面に従う情報検索部１１８０は、要求１４１０と各検索キーとに基づいて、緯度、経度、取得時間などに合致するデータを、最初に、データレコード１４２０を含む、ふせんフラグありのデータベースから検索する。さらに、情報検索部１１８０は、要求されたデータがふせんフラグありのデータベースにない場合には、ふせんフラグなしのデータベースから検索する。このように、頻繁に利用されるデータレコードを含むデータベースから先に検索することにより、管理装置１０１０は、平均の検索時間を短くすることができる。

図１５を参照して、さらに別の局面について説明する。図１５は、ステップＳ１２４０の他の局面に従う処理を表わす図である。

別の局面において、管理装置１０１０は、ふせんフラグありのデータを物理的に異なる小容量で高速の高頻度街情報データベース１５１０に蓄積してもよい。このようにデータベースを高頻度街情報データベース１５１０と通常の街情報データベース１２１とに物理的に分けることで、平均の検索時間を短くでき、また使用しない間の街情報データベース１２１については駆動を一時的に停止することにより電力の消費を抑制することができる。

図１６を参照して、システム１００の制御構造についてさらに説明する。図１６は、管理装置１０１０と取得端末１０２０とが実行する処理の一部を表わすフローチャートである。

ステップＳ１６００にて、管理装置１０１０は、取得問合せ処理を開始する。

より具体的には、Ｓ１６１０にて、制御部１１００は、要求された位置と時間とに近いタクシーを配車データベース１２３から割り出す。例えば、制御部１１００は、街情報を取得するために目的地まで移動することについて予め承諾されているタクシーの配車データを用いて、取得希望時間に近い時間帯で取得位置に最も近いタクシーを選択する。

ステップＳ１６２０にて、制御部１１００は、割り出したタクシーに対して映像の取得を依頼する。

より具体的には、ステップＳ１６３０にて、管理装置１０１０は、取得端末１０２０との通信を確立し、位置情報と時間情報と管理ＩＤ情報とをその割り出したタクシーとしての取得端末１０２０に送信する。例えば、制御部１１００は、その選択したタクシーに対して、電子メール、ＳＭＳ（Short Message Service）その他の通信手段を用いて、要求データ（位置＋時間＋管理ＩＤ情報）を送信する。

ステップＳ１６４０にて、取得端末１０２０は、管理装置１０１０から受信した依頼に基づいて映像の取得が可能であるか否かを判断する。たとえば、取得端末１０２０としてのタクシーが空車であれば取得可能であると判断し得る。また、当該タクシーが客を乗せて走行中である場合には、取得端末１０２０は取得できないと判断し得る。

ステップＳ１６４０にて、取得端末１０２０は、たとえば取得が可能である旨を返信する。

ステップＳ１６５０にて、取得端末１０２０は、管理ＩＤ情報と取得が可能である旨を表わす情報とを管理装置１０１０に送信する。

ステップＳ１６６０にて、制御部１１００は、現在のタクシーの位置から映像を取得する位置および予想される移動時間を考慮した移動コストを算出する。

ステップＳ１６７０にて、制御部１１００は、請求金額を決定する。たとえば、ある局面において、制御部１１００は、移動コストを基礎とする算出式に基づいて金額を算定する。

ステップＳ１８００にて、制御部１１００は、後述する映像配信処理を実行する。この処理が実行されると、取得端末１０２０によって取得された映像がその映像を要求する利用端末１０４０に送られる。

図１７を参照して、利用者への請求金額の算出について説明する。図１７は、複数のタクシーがある場合における映像の取得のコストを算出する一態様を表わす図である。

ある局面において、ステップＳ１７１０にて、利用者の映像取得の要求データ（位置座標と取得日時）とが管理装置１０１０に送られる。管理装置１０１０は、たとえば、タクシー運行予定データ１７２０と渋滞予測データ１７３０とに基づいて、複数のタクシー１７４０，１７５０，１７６０のうちいずれのタクシーが映像取得位置に適切にアクセスできるかを判断する。ある局面において、タクシー１７４０が乗客を乗せて走行している場合には、映像の取得を要求する対象から除外する。タクシー１７５０と、タクシー１７６０とについてはいずれも空車であるとする。この場合、映像取得位置１７７０から各タクシーまでの距離を制御部１１００は計算し、さらにその経路における渋滞の有無を渋滞予測データ１７３０から確認する。その結果、制御部１１００は、乗客を乗せておらずまた映像取得位置１７７０に最も近い場所にいるタクシー１７５０を映像の取得を要求する端末として割り出す。制御部１１００は、さらに、タクシー１７５０が映像取得位置１７７０に移動するまでの距離（移動コスト）に応じて利用者に請求される金額を計算する。

図１８を参照して、システム１００の制御構造についてさらに説明する。図１８は、管理装置１０１０と利用端末１０４０とが実行する処理の一部を表わすフローチャートである。

ステップＳ１８００にて、管理装置１０１０は、映像配信処理を開始する。

ステップＳ１８１０にて、制御部１１００は、請求金額を利用端末１０４０に通知する。より具体的には、ステップＳ１８２０にて、管理装置１０１０は、利用端末１０４０に対して、識別情報と管理ＩＤと金額とを送信する。利用端末１０４０は、管理装置１０１０から送られた情報を表示装置に表示する。利用端末１０４０のユーザは表示された内容を見て承諾する旨の操作を行なう。

ステップＳ１８３０にて、利用端末１０４０の制御部１０４１は、利用端末１０４０に対する入力に基づいて、請求金額が承認され管理装置１０１０に対する入金が指示されたことを検知する。たとえば、ユーザが表示部１０４４に表示されたアイコンのうち承認ボタンを押下し、さらに入金の指示を与えると、制御部１０４１は、請求金額が承認されて入金が指示されたことを検知する。

ステップＳ１８４０にて、利用端末１０４０は、管理装置１０１０に対して、識別情報と管理ＩＤと金額と入金指示とを送信する。

ステップＳ１８５０にて、管理装置１０１０は、利用端末１０４０から通知された金額が入金されたことを確認する。

ステップＳ１８６０にて、制御部１１００は、要求された映像が街情報データベース１２１に蓄積済であるか否かを判断する。制御部１１００は、要求された映像が街情報データベース１２１に蓄積済であると判断すると（ステップＳ１８６０にてＹＥＳ）、制御をステップＳ１８７０に切り換える。そうでない場合には（ステップＳ１８６０にてＮＯ）、制御部１１００は制御をステップＳ１９００に切り換える。

ステップＳ１８７０にて、制御部１１００は、街情報データベース１２１の映像を利用端末１０４０に送付する。

より具体的には、ステップＳ１８８０にて、管理装置１０１０は、通信部１１５０を介して識別情報と管理ＩＤと映像データとを利用端末１０４０に送信する。利用端末１０４０は、映像データを受信すると表示部１０４４にその映像を表示する。

ステップＳ１９００にて、管理装置１０１０は、後述する映像取得処理を実行する。

図１９は、管理装置１０１０と取得端末１０２０と利用端末１０４０とが実行する処理の一部を表わすフローチャートである。

ステップＳ１９００にて、管理装置１０１０は、映像取得処理を開始する。

ステップＳ１９１０にて、制御部１１００は、映像取得を取得端末１０２０に指示する。より具体的には、ステップＳ１９２０にて、管理装置１０１０は、位置情報と時刻情報と管理ＩＤ情報と取得指示とを取得端末１０２０に送信する。取得端末１０２０は、たとえば複数のタクシーのうち映像取得に最も適切であると判断されたタクシーに相当する。

ステップＳ１９３０にて、取得端末１０２０は、指示された取得場所へ移動し、要求された映像を取得する。

ステップＳ１９４０にて、利用端末１０４０は、管理装置１０１０に対して、管理ＩＤと映像データと位置データと時間データとを送信する。

ステップＳ１９５０にて、管理装置１０１０は、取得端末１０２０から受信したデータを街情報データベース１２１に蓄積する（図６参照）。

ステップＳ１９６０にて、管理装置１０１０は、取得要求テーブル１１３０に格納されているデータに基づいて要求映像を利用端末１０４０に送付する。より具体的には、ステップＳ１９７０にて、管理装置１０１０は、利用端末１０４０に対して、識別情報と管理ＩＤと映像データとを送信する。利用端末１０４０は、その映像データを受信すると表示部１０４４に映像を表示する。

ステップＳ１９８０にて、管理装置１０１０は、月毎の映像取得の代金を取得端末１０２０に支払う。なお、代金の支払いのタイミングは月毎に限られず、たとえば取得の都度あるいは予め定められた一定期間毎に支払われてもよい。より具体的には、ステップＳ１９９０にて、管理装置１０１０は、取得端末１０２０に対して代金の支払いに関するデータ（管理ＩＤ、取得された日時、取得されたデータ、コストを表わす情報など）を取得端末１０２０のアカウント情報に送信する。

［まとめ］

以上のようにして、本実施の形態によれば、一般のおよび特定の取得者による街情報の収集に関し、特別な知識や経験のない人の参加を促すことができる。また、取得された情報の価値が数値で取得者に対してフィードバックされるので、取得意識が高まり、網羅的で更新頻度の高い有用な情報を収集することができる。
利用者から見ると、街情報収集を主目的にする車両を活用すると、情報取得コストが高くなるところ、開示された技術によれば、すでに車載カメラあるいはドライブレコーダのような撮像装置を搭載した、街で走行している空車タクシーその他の輸送車両が情報取得に使用されるので、情報の取得コストが安くなる。また、タクシー企業その他の輸送事業者から見れば、空いている輸送車両を、タイムシェアという形で利用できるので、新たな収益源ともなり得る。

＜第２の実施の形態＞

以下、本開示に係る第２の実施の形態について説明する。なお、本開示に係るシステムは、第１の実施の形態に係るシステムと同様の構成を用いて実現される。したがって、同様の構成についての説明は繰り返さない。

本実施の形態に係るシステムは、同一の映像を必要とする複数の利用者を募り、映像をシェアすることができる点で、前述の第１の実施の形態と異なる。

図２０を参照して、本実施の形態に係る技術思想について説明する。図２０は、本実施の形態に係るシステムの構成の概要を表わす図である。

本開示に係るシステムは、街情報管理モジュール２０００を備える。街情報管理モジュール２０００は、利用者数の算出モジュール２０１０と、街情報データベース１２１と、街情報価値の算出モジュール２０２０とを含む。街情報価値の算出モジュール２０２０は、蓄積済の街情報データベース９２３と、映像取得コストを算出して数値化する処理モジュール（ステップＳ１０２１）と、配車データベース１２３とを含む。

街情報管理モジュール２０００は、映像の視野機能により、同一映像の利用者を算出し、街情報価値（支払い金額）の算出に利用する。たとえば、利用者数が多ければ多いほど、その映像の単価は低くなる。

算出モジュール２０１０は、映像をシェアする利用者数を算出し、街情報の価値を算出する。例えば、渋滞の開始地点の映像を求める利用者が５名いる場合において、当該映像の単価が５００円であれば、算出モジュール２０１０は、利用者一人あたりの当該映像についての情報価値を１００円（＝５００÷５）と計算する。路上積雪の映像を求める利用者が一人の場合において、当該映像の単価が３００円であれば、算出モジュール２０１０は、その情報価値を３００円（＝３００÷１）と算出する。

ステップＳ２０２１にて、街情報価値の算出モジュール２０２０は、取得が要求された位置と時刻情報とから、蓄積済の街情報データベース９２３および配車データベース１２３から、映像取得コストを算出して数値化する。

図２１を参照して、本実施の形態に係る管理装置２１００の構成について説明する。図２１は、管理装置２１００のハードウェア構成の概要を表わすブロック図である。管理装置２１００は、図１１に示される管理装置１０１０の構成に対して、利用者数の算出部２１１０をさらに備える。

本実施の形態によれば、街情報の管理者側が、同じ映像の購入希望者を募ることができ、映像をシェアする態様で利用者を募集することができる。例えば、管理装置１０１０は、対象映像、募集中の映像、現在の人数、価格情報を提示することができる。複数の利用者が同一の映像その他の情報をシェアできるので、一人あたりの映像取得コストが低減され得る。

＜第３の実施の形態＞

以下、本開示に係る第３の実施の形態について説明する。

街情報データベースに蓄積される情報量が増えると、記憶装置の台数が増え、記憶装置を稼働する電力が大きくなり、街情報データベース１２１において情報を維持管理するコストが上昇することが想定される。そこで、必要とされないデータや古くなったデータが削減され得る。本実施の形態は、街情報の購入履歴データを参照して、過去の購入頻度が高い街情報や、ある特定の利用者に定期的に購入されている街情報を特定して、それら以外の情報を街情報データベース１２１から削除する構成を有する点で前述の実施の形態と異なる。

図２２を参照して、第３の実施の形態に係る技術思想について説明する。図２２は、第３の実施の形態に係るシステムの構成を概念的に表わす図である。

街情報管理モジュール２２００は、映像利用履歴データベース２２１０と、街情報データベース１２１と、街情報価値の算出モジュール２０２０とを備える。街情報管理モジュール２２００は、管理部１２０に相当する。

映像利用履歴データベース２２１０は、利用者に求められた映像の利用の履歴を保持している。利用の履歴は、例えば、映像の識別情報、当該映像の利用者の識別情報、利用日時、利用回数等を含む。ある局面において、街情報管理モジュール２２００のプロセッサは、利用の履歴に基づいて、予め定められた削除条件を満たす映像、例えば、利用頻度が予め設定された基準よりも少ない映像、あるいは、取得されてから予め定められた時間が経過した映像を削除する。なお、利用の履歴に基づいて削除される情報は、映像に限られず、画像、音声等であってもよい。

図２３を参照して、本実施の形態に係る管理装置２３００について説明する。図２３は、管理装置２３００の構成を表わすブロック図である。

管理装置２３００は、図１１に示される構成に加えて、映像利用履歴データベース２２１０をさらに備える。制御部１１００は、映像利用履歴データベース２２１０に保存されている各映像について、予め定められた削除条件が成立したか否かを監視する。制御部１１００は、当該削除条件が成立した映像のデータレコードを映像利用履歴データベース２２１０から削除する。
このような構成によれば、利用の頻度が高い情報は、予め定められた保存条件が満たされる限り、街情報データベース１２１に保存されるので、情報の取得コストは増大しない。また、利用の頻度が低い情報は、上記の削除条件を満たす場合に削除されるので、街情報データベース１２１における保存のコストの増大が抑制される。

［端末の構成］

図２４を参照して、取得端末１０２０および利用端末１０４０の構成について説明する。図２４は、取得端末１０２０または利用端末１０４０として機能する通信端末２４００のハードウェア構成を表わすブロック図である。

通信端末２４００は、ＣＰＵ（Central Processing Unit）２０と、アンテナ２３と、通信装置２４と、入力スイッチ２５と、カメラ２６と、フラッシュメモリ２７と、ＲＡＭ（Random Access Memory）２８と、ＲＯＭ（Read-Only Memory）２９と、メモリカード駆動装置３０と、マイク３２と、スピーカ３３と、音声信号処理回路３４と、モニタ３５と、ＬＥＤ（Light Emitting Diode）３６と、通信インターフェイス３７と、バイブレータ３８と、ＧＰＳアンテナ３９と、ＧＰＳモジュール４０と、加速度センサ４１と、地磁気センサ４２とを備える。メモリカード駆動装置３０には、メモリカード３１が装着され得る。

アンテナ２３は、基地局によって発信される信号を受信し、または、基地局を介して他の通信装置と通信するための信号を送信する。アンテナ２３によって受信された信号は、通信装置２４によってフロントエンド処理が行なわれ、処理後の信号は、ＣＰＵ２０に送られる。

ＣＰＵ２０は、通信端末２４００に対して与えられる命令に基づいて通信端末２４００の動作を制御するための処理を実行する。通信端末２４００が信号を受信すると、ＣＰＵ２０は、通信装置２４から送られた信号に基づいて予め規定された処理を実行し、処理後の信号を音声信号処理回路３４に送出する。音声信号処理回路３４は、その信号に対して予め規定された信号処理を実行し、処理後の信号をスピーカ３３に送出する。スピーカ３３は、その信号に基づいて音声を出力する。

入力スイッチ２５は、通信端末２４００に対する命令の入力を受け付ける。入力スイッチ２５は、タッチセンサ、通信端末２４００の筐体に設けられたボタン等により実現される。入力された命令に応じた信号は、ＣＰＵ２０に入力される。

マイク３２は、通信端末２４００に対する発話を受け付けて、発話された音声に対応する信号を音声信号処理回路３４に対して送出する。音声信号処理回路３４は、その信号に基づいて通話のために予め規定された処理を実行し、処理後の信号をＣＰＵ２０に対して送出する。ＣＰＵ２０は、その信号を送信用のデータに変換し、変換後のデータを通信装置２４に対して送出する。通信装置２４は、そのデータを用いて送信用の信号を生成し、アンテナ２３に向けてその信号を送出する。

フラッシュメモリ２７は、ＣＰＵ２０から送られるデータを格納する。また、ＣＰＵ２０は、フラッシュメモリ２７に格納されているデータを読み出し、そのデータを用いて予め規定された処理を実行する。

ＲＡＭ２８は、入力スイッチ２５に対して行なわれた操作に基づいてＣＰＵ２０によって生成されるデータを一時的に保持する。ＲＯＭ２９は、通信端末２４００に予め定められた動作を実行させるためのプログラムあるいはデータを格納している。ＣＰＵ２０は、ＲＯＭ２９から当該プログラムまたはデータを読み出し、通信端末２４００の動作を制御する。

メモリカード駆動装置３０は、メモリカード３１に格納されているデータを読み出し、ＣＰＵ２０に送出する。メモリカード駆動装置３０は、ＣＰＵ２０によって出力されるデータを、メモリカード３１の記憶領域に書き込む。

音声信号処理回路３４は、上述のような通話のための信号処理を実行する。なお、図２４に示される例では、ＣＰＵ２０と音声信号処理回路３４とが別個の構成として示されているが、他の局面において、ＣＰＵ２０と音声信号処理回路３４とが一体として構成されていてもよい。

モニタ３５は、タッチ操作式のモニタであるが、タッチ操作を受け付ける機構は特に限られない。モニタ３５は、ＣＰＵ２０から取得されるデータに基づいて、当該データによって規定される画像を表示する。たとえば、フラッシュメモリ２７に格納されている静止画、動画、地図などを表示する。

ＬＥＤ３６は、ＣＰＵ２０から出力される信号に基づいて発光する。ある局面において、通信インターフェイス３７は、ＷｉＦｉ、Bluetooth（登録商標）、ＮＦＣ（Near Field Communication）等により実現される。別の局面において、通信インターフェイス３７は、データ通信用のケーブルの装着を受け付ける。通信インターフェイス３７は、ＣＰＵ２０から出力される信号を発信する。あるいは、通信インターフェイス３７は、通信端末２４００の外部から受信した信号に含まれるデータを、ＣＰＵ２０に対して送信する。

バイブレータ３８は、ＣＰＵ２０から出力される信号に基づいて、予め定められた周波数で発振動作を実行する。

ＧＰＳアンテナ３９は、４つ以上の衛星からそれぞれ送信されるＧＰＳ信号を受信する。受信された各ＧＰＳ信号は、ＧＰＳモジュール４０に入力される。ＧＰＳモジュール４０は、各ＧＰＳ信号と公知の技術とを用いて測位処理を実行し、通信端末２４００の位置情報を取得する。

加速度センサ４１は、通信端末２４００に作用する加速度を検出する。ある局面において、加速度センサ４１は、３軸加速度センサとして実現される。検出された加速度は、ＣＰＵ２０に入力される。ＣＰＵ２０は、この加速度に基づいて、通信端末２４００の動きや姿勢（傾き）を検出する。

地磁気センサ４２は、通信端末２４００が向いている方角を検出する。この検出により取得された情報は、ＣＰＵ２０に入力される。

［コンピュータのハードウェア構成］

図２５を参照して、本実施の形態に係る管理部１２０、管理装置１０１０，２１００，２３００の具体的構成について説明する。図２５は、管理部１２０、または管理装置１０１０，２１００，２３００として機能するコンピュータ２５００のハードウェア構成を表わすブロック図である。

コンピュータ２５００は、主たる構成要素として、プログラムを実行するＣＰＵ１と、コンピュータ２５００の利用者による指示の入力を受けるマウス２およびキーボード３と、ＣＰＵ１によるプログラムの実行により生成されたデータ、又はマウス２若しくはキーボード３を介して入力されたデータを揮発的に格納するＲＡＭ４と、データを不揮発的に格納するハードディスク５と、光ディスク駆動装置６と、モニタ８と、通信インターフェイス７とを備える。各構成要素は、相互にバスによって接続されている。光ディスク駆動装置６には、ＣＤ−ＲＯＭ９その他の光ディスクが装着される。通信インターフェイス７は、ＵＳＢ（Universal Serial Bus）インターフェイス、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ、Bluetooth（登録商標）インターフェイス等を含むが、これらに限られない。

コンピュータ２５００における処理は、各ハードウェアおよびＣＰＵ１により実行されるソフトウェアによって実現される。このようなソフトウェアは、ハードディスク５に予め格納されている場合がある。また、ソフトウェアは、ＣＤ−ＲＯＭ９その他のコンピュータ読み取り可能な不揮発性のデータ記録媒体に格納されて、プログラム製品として流通している場合もある。あるいは、当該ソフトウェアは、インターネットその他のネットワークに接続されている情報提供事業者によってダウンロード可能なプログラム製品として提供される場合もある。このようなソフトウェアは、光ディスク駆動装置６その他のデータ読取装置によってデータ記録媒体から読み取られて、あるいは、通信インターフェイス７を介してダウンロードされた後、ハードディスク５に一旦格納される。そのソフトウェアは、ＣＰＵ１によってハードディスク５から読み出され、ＲＡＭ４に実行可能なプログラムの形式で格納される。ＣＰＵ１は、そのプログラムを実行する。

図２５に示されるコンピュータ２５００を構成する各構成要素は、一般的なものである。したがって、本実施の形態に係る最も本質的な部分は、コンピュータ２５００に格納されたプログラムであるともいえる。コンピュータ２５００の各ハードウェアの動作は周知であるので、詳細な説明は繰り返さない。

なお、データ記録媒体としては、ＣＤ−ＲＯＭ、ＦＤ（Flexible Disk）、ハードディスクに限られず、磁気テープ、カセットテープ、光ディスク（ＭＯ（Magnetic Optical Disc）／ＭＤ（Mini Disc）／ＤＶＤ（Digital Versatile Disc））、ＩＣ（Integrated Circuit）カード（メモリカードを含む）、光カード、マスクＲＯＭ、ＥＰＲＯＭ（Electronically Programmable Read-Only Memory）、ＥＥＰＲＯＭ（Electronically Erasable Programmable Read-Only Memory）、フラッシュＲＯＭなどの半導体メモリ等の固定的にプログラムを担持する不揮発性のデータ記録媒体でもよい。

ここでいうプログラムとは、ＣＰＵ１により直接実行可能なプログラムだけでなく、ソースプログラム形式のプログラム、圧縮処理されたプログラム、暗号化されたプログラム等を含み得る。

［まとめ］

要約すると、開示された技術的特徴は、以下のように構成される。

（１）ある局面に従うと、コンピュータ２５００が１つ以上の利用端末１０４０に情報（例えば、映像、画像、音声等）を提供するための方法が提供される。この方法は、ＣＰＵ１が、利用端末１０４０で閲覧可能な情報が存在する場所を特定するための位置情報と情報が取得される時間を特定するための時間情報とを含む要求を利用端末１０４０から受信するステップと、ＣＰＵ１が、コンピュータ２５００と通信可能な１つ以上の移動体（例えば、取得端末１０２０が搭載されたタクシー、バイクその他の車両）に、当該情報を取得する指示を送信するステップと、ＣＰＵ１が、１つ以上の移動体のうち当該情報を取得した移動体から、時間における場所の情報を受信するステップと、ＣＰＵ１が、ハードディスク５その他の内部の記憶装置または外部の記憶装置に情報を蓄積するステップと、ＣＰＵ１が、上記記憶装置に蓄積されている情報から、要求により特定される情報を抽出するステップと、ＣＰＵ１が、抽出された情報を、要求を送信した利用端末１０４０に送信するステップとを含む。
かかる構成によると、利用端末１０４０によって要求された情報が、移動体によって取得されて、コンピュータ２５００によって提供されるので、利用者は、容易に情報を入手し閲覧することができる。

（２）好ましくは、上記の方法は、ＣＰＵ１が、蓄積されている情報に目印となるふせん情報（例えば、ふせん３２０）を関連付けるステップを含む。情報を抽出するステップは、ふせん情報が関連付けられている情報から、要求により特定される情報を検索するステップを含む。
かかる構成によると、ＣＰＵ１は、ふせん３２０の有無に応じて情報を検索できるので、例えば頻繁に要求されるような情報にふせん３２０を付しておくことにより、速やかに情報を利用端末１０４０に提供することができる。
（３）好ましくは、蓄積されている情報に目印となるふせん情報を関連付けるステップは、当該情報の利用頻度に基づいてふせん情報を関連付けること、または、予め指定された基準に基づいてふせん情報を関連付けることを含む。
かかる構成によると、利用頻度に応じた情報の検索、あるいは、桜の花の有無その他の指定された基準に応じた情報の検索が可能になるので効率よく情報が提供される。
（４）好ましくは、上記の方法は、複数の移動体の各々が情報を取得するためのコストを計算するステップをさらに含む。指示を１つ以上の移動体に送信するステップは、コストが最少となる移動体に指示を送信することを含む。
かかる構成によると、情報を取得するためのコストを最小限にできるので、利用者に情報を提供するコストも抑制され得る。
（５）好ましくは、１つ以上の移動体は、輸送車両を含む。コストを計算するステップは、各輸送車両の走行状態を表す配車データにアクセスするステップと、配車データと位置情報とに基づいて、場所に向かうべき輸送車両を決定するステップとを含む。
かかる構成によると、有償で旅客または物品を運搬する輸送車両のうち、運搬していない輸送車両に情報を取得させることができるので、輸送車両の活用度が向上し得る。
（６）好ましくは、上記の方法は、移動体から受信した場所の情報を保存するステップと、利用端末から要求を受信したことに基づいて、時間における場所の情報が存在するか否かを確認するステップとをさらに含む。指示を送信するステップは、時間における場所の情報が存在しない場合に、当該指示を送信することを含む。
かかる構成によると、情報がコンピュータに蓄積されていない場合に、要求に応じた情報が取得されるので、合理的な情報取得および情報提供が可能になる。
（７）好ましくは、上記の方法は、時間における場所の情報が存在する場合に、蓄積されている当該情報を利用端末に送信するステップをさらに含む。
かかる構成によると、要求された時間および場所に該当する情報がコンピュータに存在すれば、その情報が利用端末に送られるので、再度情報を取得する必要がなくなる。
（８）他の実施の形態に従うと、遠隔地の情報を利用端末１０４０が提供するための方法が提供される。この方法は、利用端末１０４０で閲覧可能な情報が存在する場所を特定するための位置情報と情報が取得される時間を特定するための時間情報とを含む要求の入力を受け付けるステップと、１つ以上の移動体（例えば、取得端末１０２０が搭載された輸送車両）と通信可能なコンピュータ２５００に、要求を送信するステップと、要求に基づいて情報を取得した移動体からコンピュータ２５００に送られた情報を、コンピュータ２５００から受信するステップと、情報を出力するステップを含む。
かかる構成によれば、利用者が入力した情報が、取得端末１０２０によって取得されるので、利用者が現地に出向くことなく情報（例えば、桜の写真等）を楽しむことができる。
（９）好ましくは、上記の方法は、利用端末１０４０が、要求された情報を取得するためのコストをコンピュータ２５００から受信するステップと、コストを表示するステップとをさらに含む。
かかる構成によれば、情報の取得に必要なコストが事前に表示されるので、利用者は、コストを確認したうえで、情報の取得を依頼することができる。
（１０）好ましくは、要求の入力を受け付けるステップは、時間情報として、過去の時間または未来の時間の入力を受け付けるステップを含む。
かかる構成によると、利用者は、すでに取得されて蓄積されている過去の情報、または、現地に出向けないことが予め分かっている未来の時点における情報を入手することができる。
（１１）他の局面に従うと、上記のいずれかに記載の方法をコンピュータ２５００に実行させるためのプログラムが提供される。
かかる構成によれば、当該プログラムがインストールされたコンピュータ２５００は、利用者からの要求に応じた情報を提供することができる。
（１２）他の局面に従うと、利用端末１０４０に情報を提供するための装置が提供される。この装置は、ＲＡＭ４と、ＲＡＭ４に結合されて命令を実行するＣＰＵ１とを備える。ＣＰＵ１は、利用端末１０４０で閲覧可能な情報が存在する場所を特定するための位置情報と情報が取得される時間を特定するための時間情報とを含む要求を利用端末から受信し、当該装置と通信可能な１つ以上の移動体（例えば、取得端末１０２０）に、当該情報を取得する指示を送信し、１つ以上の移動体のうち当該情報を取得した移動体から、時間における場所の情報を受信し、情報をハードディスク５に蓄積し、蓄積されている情報から、要求により特定される情報を抽出し、抽出された情報を、要求を送信した利用端末１０４０に送信するように構成されている。
（１３）好ましくは、ＣＰＵ１は、蓄積されている情報に目印となるふせん情報を関連付けるようにさらに構成されている。情報を抽出することは、ふせん情報が関連付けられている情報から、要求により特定される情報を検索することを含む。
（１４）好ましくは、ＣＰＵ１が、蓄積されている情報に目印となるふせん情報を関連付けることは、当該情報の利用頻度に基づいてふせん情報を関連付けること、または、予め指定された基準に基づいてふせん情報を関連付けることを含む。
（１５）好ましくは、ＣＰＵ１は、複数の移動体の各々が情報を取得するためのコストを計算するようにさらに構成されている。指示を１つ以上の移動体に送信することは、コストが最少となる移動体に指示を送信することを含む。
（１６）１つ以上の移動体は、輸送車両を含む。輸送車両は、例えば、タクシー、バイク、バス、トラック、自転車その他の車両である。ある局面において、輸送車両は、有償で旅客または物品を運ぶ車両を含む。コストを計算することは、各輸送車両の走行状態を表す配車データにアクセスすることと、配車データと位置情報とに基づいて、場所に向かうべき輸送車両を決定することとを含む。
（１７）好ましくは、ＲＡＭ４は、移動体から受信した場所の情報を保存するように構成されている。ＣＰＵ１は、利用端末１０４０から要求を受信したことに基づいて、時間における場所の情報が存在するか否かを確認するように構成されている。指示を送信することは、時間における場所の情報が存在しない場合に、当該指示を送信することを含む。
（１８）好ましくは、ＣＰＵ１は、時間における場所の情報が存在する場合に、蓄積されている当該情報を利用端末１０４０に送信するようにさらに構成されている。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

１ ＣＰＵ、２ マウス、３ キーボード、４，２８ ＲＡＭ、５ ハードディスク、６ 光ディスク駆動装置、７，３７ 通信インターフェイス、８，３５ モニタ、９，２９ ＲＯＭ、２３，３９ アンテナ、２４ 通信装置、２５ 入力スイッチ、２６ カメラ、２７ フラッシュメモリ、３０ メモリカード駆動装置、３１ メモリカード、３２ マイク、３３ スピーカ、３４ 音声信号処理回路、３８ バイブレータ、４０ モジュール、４１ 加速度センサ、４２ 地磁気センサ、１００ システム、１１０，１７４０，１７５０，１７６０ タクシー、１２０ 管理部、１２１，９２３ 街情報データベース、１２２ 判定部、１２３ 配車データベース、１３０，９１４ 利用者、２１０ 付加情報、２１１ ルール、２１２，２１３，９１１，９１２，９１３ 画像、２１４ 映像、２２０，１１８０ 情報検索部、２３０ ルール判定要素データ、２４０ ルール生成部、５０１，８０１ 入力情報、６００ テーブル、６１０，１４２１ データベース番号、６２０，１４１２，１４２２ 緯度、６３０，１４１３，１４２３ 経度、６４０，１４１４，１４２４ 取得時間、６５０，１４２５ タグ、６７０，１４２７ 利用回数、６８０，１４２８ 最終利用日、６９０，１４２９ フラグ、９１０ 街情報利用者モジュール、９２０，２０００，２２００ 街情報管理モジュール、９２１，２０１０，２０２０ 算出モジュール、９３０ 街情報取得モジュール、１０１０，２１００，２３００ 管理装置、１０２０ 取得端末、１０２１，１０４１，１１００ 制御部、１０２２ 撮影部、１０２３，１０４８ 街データ蓄積データベース、１０２４ 位置情報取得部、１０２５，１０４４ 表示部、１０２６ 入出力部、１０２７，１０４３ 送信部、１０２８，１０４７ ユーザ識別子、１０２９ 街データ抽出部、１０３０ 情報提供可否選択部、１０３１，１０４２ 受信部、１０３２，１０４９，１１９１ バス、１０４０ 利用端末、１０４５ 入力部、１１３０ 取得要求テーブル、１１４０ 累積ポイントテーブル、１１５０ 通信部、１１７０ ポイント算出部、１４１０ 要求、１４１５ 選択肢、１４１６ 識別情報、１４２０ データレコード、１５１０ 高頻度街情報データベース、１７２０ タクシー運行予定データ、１７３０ 渋滞予測データ、１７７０ 映像取得位置、２１１０ 算出部、２２１０ 映像利用履歴データベース、２４００ 通信端末、２５００ コンピュータ。

Claims (18)

1. コンピュータが１つ以上の端末に情報を提供するための方法であって、
   前記端末で閲覧可能な情報が存在する場所を特定するための位置情報と前記情報が取得される時間を特定するための時間情報とを含む要求を端末から受信するステップと、
   前記コンピュータと通信可能な１つ以上の移動体に、当該情報を取得する指示を送信するステップと、
   前記１つ以上の移動体のうち当該情報を取得した移動体から、前記時間における前記場所の情報を受信するステップと、
   前記情報を蓄積するステップと、
   前記蓄積されている情報から、前記要求により特定される情報を抽出するステップと、
   前記抽出された情報を、前記要求を送信した端末に送信するステップとを含む、方法。
2. 前記蓄積されている情報に目印となるふせん情報を関連付けるステップをさらに含み、
   前記情報を抽出するステップは、前記ふせん情報が関連付けられている情報から、前記要求により特定される情報を検索するステップを含む、請求項１に記載の方法。
3. 前記蓄積されている情報に目印となるふせん情報を関連付けるステップは、当該情報の利用頻度に基づいて前記ふせん情報を関連付けること、または、予め指定された基準に基づいて前記ふせん情報を関連付けることを含む、請求項２に記載の方法。
4. 複数の移動体の各々が前記情報を取得するためのコストを計算するステップをさらに含み、
   前記指示を１つ以上の移動体に送信するステップは、前記コストが最少となる移動体に前記指示を送信することを含む、請求項１に記載の方法。
5. 前記１つ以上の移動体は、輸送車両を含み、
   前記コストを計算するステップは、
   各輸送車両の走行状態を表す配車データにアクセスするステップと、
   前記配車データと前記位置情報とに基づいて、前記場所に向かうべき輸送車両を決定するステップとを含む、請求項４に記載の方法。
6. 前記移動体から受信した前記場所の情報を保存するステップと、
   前記端末から前記要求を受信したことに基づいて、前記時間における前記場所の情報が存在するか否かを確認するステップとをさらに含み、
   前記指示を送信するステップは、前記時間における前記場所の情報が存在しない場合に、当該指示を送信することを含む、請求項１に記載の方法。
7. 前記時間における前記場所の情報が存在する場合に、蓄積されている当該情報を前記端末に送信するステップをさらに含む、請求項６に記載の方法。
8. 遠隔地の情報を端末が提供するための方法であって、
   前記端末で閲覧可能な情報が存在する場所を特定するための位置情報と前記情報が取得される時間を特定するための時間情報とを含む要求の入力を受け付けるステップと、
   １つ以上の移動体と通信可能なコンピュータに、前記要求を送信するステップと、
   前記要求に基づいて前記情報を取得した移動体から前記コンピュータに送られた情報を、前記コンピュータから受信するステップと、
   前記情報を出力するステップを含む、方法。
9. 要求された情報を取得するためのコストを前記コンピュータから受信するステップと、
   前記コストを表示するステップとをさらに含む、請求項８に記載の方法。
10. 前記要求の入力を受け付けるステップは、前記時間情報として、過去の時間または未来の時間の入力を受け付けるステップを含む、請求項８に記載の方法。
11. 請求項１〜１０のいずれかに記載の方法をコンピュータに実行させるためのプログラム。
12. 端末に情報を提供するための装置であって、
    メモリと、
    前記メモリに結合されて命令を実行するプロセッサとを備え、
    前記プロセッサは、
    前記端末で閲覧可能な情報が存在する場所を特定するための位置情報と前記情報が取得される時間を特定するための時間情報とを含む要求を端末から受信し、
    当該装置と通信可能な１つ以上の移動体に、当該情報を取得する指示を送信し、
    前記１つ以上の移動体のうち当該情報を取得した移動体から、前記時間における前記場所の情報を受信し、
    前記情報を蓄積し、
    前記蓄積されている情報から、前記要求により特定される情報を抽出し、
    前記抽出された情報を、前記要求を送信した端末に送信するように構成されている、装置。
13. 前記プロセッサは、
    前記蓄積されている情報に目印となるふせん情報を関連付けるように構成されており、
    前記情報を抽出することは、前記ふせん情報が関連付けられている情報から、前記要求により特定される情報を検索することを含む、請求項１２に記載の装置。
14. 前記蓄積されている情報に目印となるふせん情報を関連付けることは、当該情報の利用頻度に基づいて前記ふせん情報を関連付けること、または、予め指定された基準に基づいて前記ふせん情報を関連付けることを含む、請求項１３に記載の装置。
15. 前記プロセッサは、複数の移動体の各々が前記情報を取得するためのコストを計算するようにさらに構成されており、
    前記指示を１つ以上の移動体に送信することは、前記コストが最少となる移動体に前記指示を送信することを含む、請求項１２に記載の装置。
16. 前記１つ以上の移動体は、輸送車両を含み、
    前記コストを計算することは、
    各輸送車両の走行状態を表す配車データにアクセスすることと、
    前記配車データと前記位置情報とに基づいて、前記場所に向かうべき輸送車両を決定することとを含む、請求項１５に記載の装置。
17. 前記メモリは、前記移動体から受信した前記場所の情報を保存するように構成されており、
    前記プロセッサは、前記端末から前記要求を受信したことに基づいて、前記時間における前記場所の情報が存在するか否かを確認するように構成されており、
    前記指示を送信することは、前記時間における前記場所の情報が存在しない場合に、当該指示を送信することを含む、請求項１２に記載の装置。
18. 前記プロセッサは、前記時間における前記場所の情報が存在する場合に、蓄積されている当該情報を前記端末に送信するようにさらに構成されている、請求項１７に記載の装置。

Images