JP3685393B2 - 情報配信装置、情報配信方法、およびプログラム - Google Patents
情報配信装置、情報配信方法、およびプログラム Download PDFInfo
- Publication number
- JP3685393B2 JP3685393B2 JP2001083891A JP2001083891A JP3685393B2 JP 3685393 B2 JP3685393 B2 JP 3685393B2 JP 2001083891 A JP2001083891 A JP 2001083891A JP 2001083891 A JP2001083891 A JP 2001083891A JP 3685393 B2 JP3685393 B2 JP 3685393B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- disaster
- customer
- area
- distribution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/26—Government or public services
- G06Q50/265—Personal security, identity or safety
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネット等のネットを介して情報を流通させるシステムに関し、特に災害情報を顧客に対して配信するシステムに関するものである。
【０００２】
【従来の技術】
災害に関する情報は速やかに、全ての人々によって共有されなければならないという性格を持つ。現状ではそういった類の情報はマスメディアによって配信される、マスな情報のみである。しかし、前述のように、災害に関するあらゆる情報、つまり災害情報の共有は災害大国日本における社会基盤整備の中でも急務の課題である。
災害情報を流通させるために、インターネットを用いることができる。しかしながら、現状の情報伝達体制をそのままインターネットに持ち込んでしまっては、膨大な災害情報を無差別に個々人に送りつけることになる。これでは、個々人が受け取る情報が過多になり、その個々人にとって本当に必要な情報が埋没してしまうおそれがある。また、さらには個々人と無関係の情報が送られることによって災害情報への無関心を逆に促進させる結果ともなり兼ねない。
【０００３】
【発明が解決しようとする課題】
災害情報は、火災・気象（豪雨・雷・雪等）・電車運行・道路・大災害（地震・噴火・津波・台風等）情報といった、日々の日常的な災害から何年かに一度の大災害に関する情報を包含する。このような膨大な情報の中から、個々人にとって必要な災害情報を的確に伝えるかという部分が非常に重要な課題となっている。しかし、現存するインターネットのシステムを用いる場合には、顧客が必要とする情報配信を受けるためには、一つ一つの配信登録条件を設定する必要がある。遠方で起こった災害の際には、どのような情報が欲しいか、電車の運行情報は必要か、気象情報ならどうなのか、一方、近所で発生した災害については、どれほど小規模な災害まで受け取るか、小火火災は必要か、交通事故はどうなのか、など煩雑な条件設定が必要とされる。しかしながら、ここまでの詳細な設定は現実的ではないため、おおまかな設定項目のみで、マスな情報配信となろう。したがって、現存するシステムでは、顧客が本当に必要とする情報を個別に配信することを実現することができない。
したがって本発明は、顧客が煩雑な設定をすることなく、当該顧客に対して必要な情報配信を行なうことのできるシステムを提供することを課題とする。
【０００４】
【課題を解決するための手段】
本発明者等は、膨大な調査を行なうことにより、顧客は、地理的な情報を基準にして自分が必要とする災害情報を取捨選択することを知見した。つまり、顧客は、自分に近い地域ほど細かい災害情報を要求し、遠くなるほど大災害に関しての情報しか要求しないという傾向がある。
これを図示したものが図１に示すテーブルである。このテーブルは、Ｘ軸が顧客からの距離（Distance）、Ｙ軸が災害レベル（Level）およびＺ軸が災害カテゴリ（Category）を示している。このテーブルは、距離（Distance）、災害レベル（Level）および災害カテゴリ（Category）の頭文字を採って、ＤＬＣテーブルと称することができる。
ＤＬＣテーブルにおいて、顧客からの距離は、通常、顧客の自宅住所地からの距離となる。被害の小さいものがレベル小となり、被害の大きいものはレベル大となる。同じ地震であっても、その震度（あるいは地震のエネルギーを示すマグニチュード）の値によって、レベル小〜大が決定される。災害カテゴリは、例えば、テーブルａが火災、テーブルｂが地震、テーブルｃが台風、テーブルｄが津波というように、災害の種別を示している。テーブルは、災害カテゴリ毎に用意される。テーブルａ〜ｄはあくまで例示であり、他の災害に対応する数のテーブルを用意することができる。
【０００５】
ＤＬＣテーブルにおいて、テーブルａ上に記述された台形状の領域が、顧客が欲する距離と災害レベルの関係を示している。つまり、顧客自身からの距離が近い場合には、災害レベルの低い情報であっても、顧客は取得することを欲する。しかし、顧客自身からの距離が遠くなると、災害レベルの小さい災害についての情報の取得は望まなくなる。台形状の領域は顧客の災害情報に関するニーズを示している。したがって、この領域を配信設定領域として、これに含まれる災害情報を顧客に対して配信すれば、顧客の災害情報に関する取得ニーズを満足できることになる。そして、ＤＬＣテーブルは、災害のカテゴリ毎に地域および災害レベルという２つの要素を選定するという簡易な手続きだけで、顧客がそのニーズにマッチする災害情報を取得できることを示している。
【０００６】
さて、本発明はＤＬＣテーブルに示された理論に基づいて災害情報を配信することを基本とする。そのために、情報配信者側は、取得した災害情報をデータ・ベースに格納する際に、災害発生地、災害レベルおよび災害カテゴリを含む災害情報を作成する。一方、配信サービスを受ける顧客側は、地域を設定する。情報配信者は、設定された地域を含む顧客情報を作成する。この災害情報および顧客情報をＤＬＣテーブルが反映された所定の条件下で照合すれば、顧客のニーズに合った災害情報を配信することができる。
【０００７】
したがって本発明は、災害情報を顧客側端末に配信する情報配信装置であって、災害が発生した地域を特定する災害地域情報とあらかじめ設定された複数の設定災害レベルのうち当該災害が該当する実災害レベルとを対応付けて記憶する災害情報記憶部と、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、前記実災害レベルと一致する前記設定災害レベルについて、前記災害地域情報と前記顧客地域情報との照合を行なうことにより前記災害情報の配信可否を判断する配信情報管理部と、前記配信情報管理部における配信可否の判断に基づき配信可とされた災害情報を前記顧客側端末に配信する情報配信部と、を備えていることを特徴とする情報配信装置である。
本発明の情報配信装置において、顧客は、顧客地域情報を登録しておけば、そのニーズに合った災害情報の配信を受けることができる。
本発明の情報配信装置において、顧客が設定する顧客地域情報は、地域情報を階層化して記憶しておくことが望ましい。階層化とは、例えば、都道府県と市区町村の関係が該当する。より具体的には、「東京都」と「港区」あるいは「神奈川県」と「藤沢市」との関係が該当する。もっとも、本発明の顧客地域情報はこのような行政単位に限定されない。このように地域情報を階層化して記憶するのは、災害のレベルによっては、「港区」内で発生した災害情報の配信を要求するが、「東京都」内であっても「港区」外で発生した災害情報の配信を要求しない、という顧客のニーズに対応するためである。したがって、前記災害情報記憶部は、前記災害地域情報を、階層的に記憶することが、前記配信情報管理部における照合にとって望ましい。
本発明の情報配信装置はインターネット等のネットワークを介して顧客側端末に情報を配信する。本発明の情報配信装置において、顧客側端末の形態は問われないが、携帯端末、特にネットワークに接続の可能な携帯電話が有効である。
【０００８】
本発明において、前記災害情報記憶部は、前記災害地域情報および前記実災害レベルに対応して災害の種別を記憶することができる。そしてその場合、前記配信情報管理部は、前記災害の種別毎に配信可否を判断することになる。災害には、前述のように、火災、気象、地震等多くの種別があり、災害の種別に応じた適切な判断を行なうためである。
また本発明において、前記災害情報記憶部は、前記災害地域情報および前記実災害レベルに対応してさらに災害の内容を記憶し、前記情報配信部は、前記災害の種別、前記災害地域情報および前記災害の内容を前記災害情報として前記顧客側端末に配信することが望ましい。
【０００９】
以上の情報配信装置は、配信する情報として災害情報を対象とした。しかし、災害情報に限らず、本発明の思想は、発生地域を特定できる事象に関する情報一般に適用することができる。経済情報、選挙を含む政治情報、スポーツ情報等のように、全国的な情報とローカル的な情報とに区別できる事象情報について本発明の思想を適用することができる。すなわち本発明の情報配信装置は、発生地域を特定できる事象に関する事象情報を入手しかつ所定の条件を満足する顧客に対してのみ当該事象情報を配信する情報配信装置であって、階層化された地理的な単位毎に事象のレベルに関連付けて情報配信の要否を定める判断基準を備えた配信情報管理部と、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、を備え、前記配信情報管理部は、新たな事象情報を入手すると、前記地理的な単位のいずれかにおいて、前記顧客地域情報が前記発生地域と一致する場合に、前記判断基準に基づいて情報配信の可否を決定することを特徴とする。
この情報配信装置において、配信の可否は事象のレベルを考慮しつつ地理的な情報を比較することを基本としている。
【００１０】
本発明の情報配信装置において、前記配信情報管理部は、前記判断基準を複数備えるとともに、複数の前記判断基準毎に前記各判断基準を引用するための引用情報を設定し、前記顧客情報登録部は、いずれかの前記引用情報を登録し、前記配信情報管理部は、前記顧客情報登録部に登録された前記引用情報を確認し、確認された前記引用情報に該当する判断基準に基づいて情報配信の可否を決定することができる。経済情報、選挙を含む政治情報、スポーツ情報等、事象の種別に対応するためである。
また本発明の情報配信装置において、前記配信情報管理部は、前記顧客に対して前記事象情報を配信する際に、前記事象に関するアンケートを配信することができる。例えば、災害情報を配信した場合に、災害発生地あるいはその近傍にいる顧客から、災害の最新情報を受信し、その情報を新たに顧客に対して配信することができる。アンケートは事象ごとに用意されるのが望ましい。
さらに本発明の情報配信装置において、前記配信情報管理部は、 前記顧客に対して前記事象情報を配信する際に、前記顧客に対して見舞金の支払いの用意があることを通知することができる。災害に罹災した顧客に対し、迅速な見舞金の支払いを可能にする。
【００１１】
本発明を鉄道、道路等の路線において生じた事象についての情報配信装置に適用する場合には以下の構成とすることが推奨される。すなわち本発明の情報配信装置は、路線によって発生地域を特定できる事象情報を入手しかつ所定の条件を満足する顧客に対して当該事象情報を配信する情報配信装置であって、階層化された地理的な単位毎に災害のレベルに関連付けて情報配信の要否を定める判断基準を備えた配信情報管理部と、事象の発生した路線情報を、当該路線が通過する地域情報に変換する路線−地域変換部と、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、を備え、前記配信情報管理部は、新たな事象情報を入手すると、前記地理的な単位のいずれかにおいて、前記地理的な単位が前記発生地域と一致する場合に、前記判断基準に基づいて情報配信の可否を決定することを特徴とする。
鉄道における故障、事故は、当該路線によって発生地を特定する。しかし、路線情報は地域情報の一種と言えるものの、そのままでは顧客情報登録部に登録された顧客地域情報との対比が行なえない。そこで本発明では、この路線情報を、当該路線が通過する地域の情報に変換するのである。
【００１２】
本発明は、また、所定の地域で発生した災害に関する情報を顧客に配信するための情報配信装置であって、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、前記災害の発生地域および前記災害のレベルを記憶する災害情報記憶部と、前記レベルを考慮しつつ前記顧客地域情報と前記発生地域とを比較することにより前記災害に関する情報を前記顧客に配信するか否か判断する配信情報管理部と、を備えたことを特徴とする情報配信装置である。
本発明の情報配信装置において、前記配信情報管理部は、前記顧客地域と前記発生地域との距離的な関係を比較することにより、前記災害に関する情報を前記顧客に配信するか否か判断する。
【００１３】
本発明はまた、所定の地域で発生した災害に関する情報を顧客に配信するための情報配信方法であって、前記顧客が情報の配信を要求する根拠となる顧客地域情報を登録するステップ（ａ）と、前記災害の発生地域および前記災害のレベルを特定するステップ（ｂ）と、前記レベルを考慮しつつ前記顧客地域と前記発生地域との距離的な関係を比較することにより前記災害に関する情報を前記顧客に配信するか否か判断するステップ（ｃ）と、を備えたことを特徴とする情報配信方法を提供する。
本発明の情報配信方法において、前記ステップ（ｃ）は、前記レベルが高い場合には、前記顧客地域と前記発生地域とが離間していても前記災害に関する情報を前記顧客に配信するものと判断することができる。重大な災害については、遠方で発生してもその情報を入手したいという要求に応えるためである。
さらに本発明は、前記ステップ（ｃ）は、前記レベルが低い場合には、前記顧客地域と前記発生地域とが一致または近接している場合に前記災害に関する情報を前記顧客に配信するものと判断することができる。
【００１４】
本発明は、さらに以下の情報配信方法を提供する。すなわち本発明の情報配信方法は、 災害情報を顧客側端末に配信する情報配信方法であって、災害が発生した地域を特定する災害地域情報とあらかじめ設定された複数の設定災害レベルのうち当該災害が該当する実災害レベルとを対応付けて記憶するステップと、前記顧客が設定する顧客地域情報を登録するステップと、前記実災害レベルと一致する前記設定災害レベルについて、前記災害地域情報と前記顧客地域情報との照合を行なうことにより前記災害情報の配信可否を判断するステップと、前記配信可否の判断に基づき配信可とされた災害情報を前記顧客側端末に配信するステップと、を備えていることを特徴とする。
また本発明の情報配信方法は、発生地域を特定できる事象に関する事象情報を入手しかつ所定の条件を満足する顧客に対して当該事象情報を配信する情報配信方法であって、階層化された地理的な単位毎に事象のレベルに関連付けて情報配信の要否を定める判断基準を用意するステップと、前記顧客が設定する顧客地域情報を登録するステップと、新たな事象情報を入手すると、前記地理的な単位のいずれかにおいて、前記顧客地域情報が前記発生地域と一致する場合に、前記判断基準に基づいて情報配信の可否を決定するステップと、を備えることを特徴とする。
さらに本発明の情報配信方法は、所定の地域で発生した災害に関する情報を顧客に配信するための情報配信方法であって、前記顧客が設定する顧客地域情報を登録するステップと、前記災害の発生地域および前記災害のレベルを記憶するステップと、前記レベルを考慮しつつ前記顧客地域情報と前記発生地域とを比較することにより前記災害に関する情報を前記顧客に配信するか否か判断するステップと、を備えたことを特徴とする。
本発明はさらに、コンピュータに、顧客が情報の配信を要求する根拠となる顧客地域を設定する処理（ａ）と、災害の発生地域および災害のレベルを特定する処理（ｂ）と、前記レベルを考慮しつつ前記顧客地域と前記発生地域との距離的な関係を比較することにより前記災害に関する情報を前記顧客に配信するか否か判断する処理（ｃ）と、を実行するためのプログラムを提供する。
【００１５】
【発明の実施の形態】
以下本発明を実施の形態に基づいて説明する。
（第１の実施形態）
図２は、第１の実施形態による災害情報配信システムの構成概略を示すブロック図である。図２に示すように、第１の実施形態による災害情報配信システムは、災害情報を提供する情報配信者が情報配信装置１を構築している。情報配信装置１は、災害情報ソース３から災害情報を入手する。そして、入手した災害情報をカスタマイズして顧客２へ配信する。
顧客２は、例えばインターネット４を介して携帯電話、パーソナル・コンピュータ（ＰＣ）、カーナビ、電光掲示板、コンビニエンスストアに設置されている端末（コンビニ端末）、デジタル家電等の端末によって、情報配信装置１から提供される災害情報を取得することができる。
情報配信装置１、災害情報ソース３から種々の災害情報を入手する。災害情報ソース３における災害情報としては、消防情報、河川情報、鉄道情報、道路情報、交通情報、気象情報、地震情報、火山情報、リコール情報、犯罪情報を含む。消防情報は、火災の発生のほか、爆発事故を含む。河川情報は、河川の増水警報を含む。鉄道情報は、電車の遅延あるいは復旧に関する情報を含む。道路情報は、自動車事故に関する情報、渋滞情報を含む。気象情報は、天気、各種注意報・警報、降水確率を含む。地震情報は地震の震度、地震による被害状況を含む。火山情報は、火山の噴火情報を含む。リコール情報は、食品、機械その他市場に流通している製品についてのリコール情報を含む。情報配信者は、これら種々の災害情報を入手し、かつ後述する情報配信装置１のデータ・ベースに格納する。
【００１６】
図３は、情報配信装置１の具体的構成を示すためのブロック図である。なお、図３に示すシステムは、顧客の携帯電話５１〜５４に災害情報を配信する例を示してある。
情報配信装置１は、災害情報管理部１０と、顧客情報管理部２０と、配信情報管理部３０と、情報配信部４０とを備えている。
災害情報管理部１０は、情報入力アプリケーション１１と、自動入力アプリケーション１２と、災害情報ＤＢ（データ・ベース）１３とを備えている。
情報入力アプリケーション１１は、災害情報ソース３から入手した災害情報をマニュアルで入力するためのアプリケーションである。また、自動入力アプリケーション１２は、災害情報ソース３からデジタル情報として入手した災害情報を自動で入力するためのアプリケーションである。情報入力アプリケーション１１および自動入力アプリケーション１２から入力された災害情報は、災害情報ＤＢ１３に格納される。
災害情報ＤＢ１３には、地理的な情報、災害の種別、災害のレベルおよび災害の内容に区分されて災害情報が格納される。図４にその１例を示す。地理的な情報は、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＴＯＷＮ」の３つの階層に区分される。図４に示すように、「ＳＴＡＴＥ」は東京都、北海道等の都道府県を示す情報である。「ＣＩＴＹ」は港区、藤沢市等の行政単位としての区および市町村を示す情報である。「ＴＯＷＮ」は、六本木３丁目、桐原町等の区および市町村内の地域単位を示す情報である。図４において、「ＣＡＴＥＧＯＲＹ」は災害の種別を示す情報である。具体的には、出火報、気象情報、地震情報といった災害の種別を示す。図４において、「ＬＶ」は災害のレベルを示す。このレベルは、災害の種別（「ＣＡＴＥＧＯＲＹ」）毎に、１〜３の３つにランク付けした情報である。第１の実施形態では、１が重大な災害を、２が中程度の災害を、また３が軽度の災害を示している。また、図４において、「ＤＥＴＡＩＬ」は、「ビル１３階爆発火災」、「倉庫 小火」というように、災害の内容を示す情報である。災害情報ＤＢ１３の災害情報は、災害情報ソース３から災害情報を入手する度に更新される。また、災害情報ＤＢ１３が更新されるたびに、当該新たな災害情報は配信情報管理部３０に転送される。
【００１７】
顧客情報管理部２０は、顧客情報登録アプリケーション２１および顧客情報ＤＢ（データ・ベース）２２を備えている。顧客情報登録アプリケーション２１、本システムによるサービスの提供を受ける各顧客に関する情報を顧客情報ＤＢ２２に登録する作業を支援する。顧客情報は、図５に示すような形式で顧客情報ＤＢ２２に登録される。
図５において、「ＵＳＥＲ」は顧客を特定する情報を示す。図５の例は、Ｘ、ＹおよびＺという３名の顧客に関する情報が示されている。「ＵＳＥＲ」には、携帯電話に用いられるメール・アドレスを用いることができる。各顧客について、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＴＯＷＮ」からなる階層化された地理的な情報、ならびに「ＣＯＵＲＳＥ」についての情報が登録される。地理的な情報は、各顧客が設定する顧客地域情報であり、自宅住所を設定することができる。その場合、図５は、顧客Ｘの自宅住所が東京都港区六本木に存在し、顧客Ｙの自宅住所が東京都港区大門に存在し、さらに顧客Ｚは東京都港区六本木に自宅住所が存在していることを示す。顧客は、自宅住所を含む地域に発生した災害情報に最も注目するからである。図５において、「ＣＯＵＲＳＥ」は、ＡおよびＢの２種類から選択することができるが、その具体例は後述する。
【００１８】
配信情報管理部３０は、災害情報ＤＢ１３から新たな災害情報を受信する。そして、配信情報管理部３０は、新たな災害情報を受信すると、顧客情報ＤＢ２２に登録されている各顧客情報とマッチング処理を行なう。このマッチング処理の結果、新たな災害情報を配信する顧客が決定される。配信情報管理部３０は、マッチング処理を行なうためのマッチング・テーブルを備えている。災害情報の種別、つまり「ＣＡＴＥＧＯＲＹ」毎にマッチング・テーブルは用意される。また、各「ＣＡＴＥＧＯＲＹ」において、前述したコース毎にマッチング・テーブルは用意される。
【００１９】
図６に出火報についてのマッチング・テーブルの例を示している。マッチング・テーブルは、コースＡおよびコースＢの２枚から構成される。
マッチング・テーブルは、階層化された地理的な情報と災害のレベルとを関連付けかつ災害情報の配信の要否を定めるものである。コースＡについてのマッチング・テーブルについてその内容を説明する。災害レベルＬＶが３の災害情報については、配信情報管理部３０から転送された災害情報の「ＴＯＷＮ」と顧客情報ＤＢ２２から入手した顧客情報の「ＴＯＷＮ」とが一致した場合にのみ、当該災害情報を当該顧客に配信する。マッチング・テーブルの「○」は、情報を配信することを意味している。災害レベルＬＶが２の災害情報については、配信情報管理部３０から転送された災害情報の「ＣＩＴＹ」と顧客情報ＤＢ２２から入手した顧客情報の「ＣＩＴＹ」とが一致した場合に、当該災害情報を当該顧客に配信する。この場合、配信情報管理部３０から転送された災害情報の「ＴＯＷＮ」と顧客情報ＤＢ２２から入手した顧客情報の「ＴＯＷＮ」とが不一致でも、当該災害情報が当該顧客に配信される。さらに、災害レベルＬＶが１の災害情報については、配信情報管理部３０から転送された災害情報の「ＳＴＡＴＥ」と顧客情報ＤＢ２２から入手した顧客情報の「ＳＴＡＴＥ」とが一致した場合に、当該災害情報を当該顧客に配信する。この場合、配信情報管理部３０から転送された災害情報の「ＴＯＷＮ」と顧客情報ＤＢ２２から入手した顧客情報の「ＴＯＷＮ」と、また配信情報管理部３０から転送された災害情報の「ＣＩＴＹ」と顧客情報ＤＢ２２から入手した顧客情報の「ＣＩＴＹ」とが不一致でも、当該災害情報が当該顧客に配信される。また、マッチング・テーブルの「ＡＬＬ」は、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＴＯＷＮ」のいずれもが不一致であっても、情報の配信を行なうことを意味する。これは、顧客地域情報と災害の発生地域とが離間していても情報の配信を行なうケースの１つである。コースＢについてのマッチング・テーブルも同様の規則にしたがっている。
【００２０】
情報配信部４０は、配信情報管理部３０において配信することを決定した災害情報を所定の顧客にメール情報として配信する。顧客は、この配信情報を携帯電話５１〜５４にて受信する。第１の実施形態では、図２に示したように、インターネット４を介して顧客の携帯電話５１〜５４に配信するため、携帯電話５１〜５４は、インターネット対応型の携帯電話である。携帯電話５１〜５４は、キャリア（携帯電話会社）毎に通信方式が異なるため、情報配信部４０は、携帯電話５１〜５４の通信方式に応じた情報を配信する。
【００２１】
第１の実施形態による災害情報配信サービスを利用する顧客となるためには、図３に示すように、携帯電話５１，５２によって顧客登録を行なう必要がある。顧客登録の手順を図７〜図９に基づいて説明する。
携帯電話５１（５２）から情報配信装置１にアクセスすると、図７（ａ）に示すように、パスワード入力画面が表示される。顧客は、この入力画面で自分が使用するパスワードを入力する。また、この入力画面には、携帯電話５１に付与されるメール・アドレスが表示される。パスワード入力、送信後には、図７（ｂ）に示すように、自宅住所の設定画面が表示される。この画面では、関東、東海等のエリアを選択する。図７（ｂ）の例では関東を選択している。エリア選択後には、図７（ｃ）に示すように、都道府県を選択する画面が表示される。図７（ｃ）の例では東京２３区を選択している。都道府県を選択後には、図７（ｄ）に示すように、市区町村を選択する画面が表示される。図７（ｄ）の例では目黒区を選択している。次いで、図８（ｅ）に示すように、市区町村内の地域を選択する画面が表示される。以上で自宅住所に関する情報の登録が終了する。次に、図８（ｆ）に示すように、コースを選択する画面が表示される。コースはＡまたはＢから選択する。図８（ｆ）の例では、Ａコースを選択している。コース選択が終了すると、登録事項を確認するための画面が表示される。図８（ｇ）に示すように、選択地域として「東京都目黒区中目黒」が、また選択コースとして「Ａ」が表示される。またこの画面では、他の地域についての登録を促しており、例えば実家の住所、勤務先の住所、その他を登録することもできる。次いで、図８（ｈ）に示すように、携帯電話５１の種類を登録する画面が表示される。携帯電話５１の種類が３種類表示され、その中から選択することになる。いずれかを選択すると、図９（ｉ）に示すように、携帯電話５１の種類を確認する画面が表示される。確認を送信すると、図９（ｊ）に示すような登録完了を告げる画面が表示される。
【００２２】
次に、配信情報管理部３０におけるマッチング処理の詳細を図１０に基づいて説明する。
図１０に示す例は、図４に示した災害情報のうち、六本木で発生した爆発火災が新たに災害情報ＤＢ１３に登録された際に、図５に示した３名の顧客Ｘ、ＹおよびＺに対して当該災害情報を配信するか否かを図６に示したマッチング・テーブルに基づいて決定する手順を示している。
配信情報管理部３０は、災害情報ＤＢ１３から災害情報を、また顧客情報ＤＢ２２から顧客情報を入手する。図１０の例では、災害情報は「東京都」「港区」「六本木」「ＬＶ＝２」「出火報」を示している。
顧客ＸはコースＡを選択しているので、コースＡについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。ＬＶ＝２であるから、マッチング・テーブルのＬＶ２の欄を参照することになる。顧客情報の「ＣＩＴＹ」が「港区」であり、災害情報の「ＣＩＴＹ」と一致する。そして、マッチング・テーブルのＬＶ２欄の「ＣＩＴＹ」には、配信することを示す○が付されているから、この災害情報は顧客Ｘに配信されることになる。図１５（ａ）に顧客の携帯電話５３，５４の配信された情報を示す画面の一例を示す。
【００２３】
顧客ＹはコースＡを選択しているので、顧客Ｘと同様に、コースＡについてのマッチング・テーブルを用いてマッチング処理が行なわれる。顧客Ｙの「ＴＯＷＮ」は「大門」であり、災害情報の「ＴＯＷＮ」と異なるが、その上のレベルの「ＣＩＴＹ」で「港区」が一致している。しかも、コースＡでは「ＣＩＴＹ」のＬＶ２についての情報は配信されることになっている。したがって、この災害情報は顧客Ｙに対して配信される。
顧客ＺはコースＢを選択しているので、コースＢについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。ＬＶ＝２であるから、マッチング・テーブルのＬＶ２の欄を参照することになる。顧客Ｚについての顧客情報は、「ＣＩＴＹ」が「港区」、「ＴＯＷＮ」が「六本木」であるから、災害情報の「ＣＩＴＹ」および「ＴＯＷＮ」が一致している。しかし、コースＢに関するマッチング・テーブルのＬＶ２の欄には、配信を意味する○が付されていないので、当該災害情報は顧客Ｚに対しては配信されない。
以上のように、マッチング処理は、災害のレベルを考慮しつつ顧客地域情報と災害発生地域を比較する処理ということができる。そして、この比較は、顧客地域情報と災害発生地域との距離的な関係を比較するものと言うこともできる。例えば、「ＴＯＷＮ」同士のみが一致する場合、近距離の関係にある。一方、「ＳＴＡＴＥ」同士のみが一致する場合、遠距離の関係にある。
【００２４】
本発明は、先に説明したように、電車故障・事故といった鉄道情報も災害情報として取り扱っている。鉄道情報の場合、路線および駅によって災害発生の地理的情報を特定するという特殊性を有している。したがって、鉄道情報に関しては、路線および駅についての情報をそのまま用いて図６に示したマッチング・テーブルによりマッチング処理を行なうことはできないので、路線から地理的情報に変換する処理を行なう必要がある。
図１１は、鉄道に関する災害情報における災害情報ＤＢ１３における情報格納の内容を示す図である。鉄道に関する災害情報は、災害種別を示す「ＣＡＴＥＧＯＲＹ」、災害が発生した路線を示す「ＲＡＩＬＷＡＹ」、災害が発生した駅を示す「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」に分類される。ここで、駅について「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」と２つの駅を格納するのは、２つの駅間で災害が発生する場合を考慮したためである。駅構内で災害が発生した場合には、「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」の駅名が一致する。「ＬＶ」は災害のレベルを示す。また、「ＤＥＴＡＩＬ」は災害の具体的な内容を示す。
図１１の例では、「ＣＡＴＥＧＯＲＹ」には全て、電車故障・事故が記述される。図１１の最上行の記載された災害情報は、山手線（「ＲＡＩＬＷＡＹ」）の渋谷駅（「ＳＴＡＴＩＯＮ１」）と原宿駅（「ＳＴＡＴＩＯＮ２」）との間で、ドア故障が発生したこと、このドア故障の災害レベルは３（ＬＶ）と軽度であることを示している。次の行に記載の災害は、中央線（「ＲＡＩＬＷＡＹ」）の国立駅構内（「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」が「国立」）で、災害レベルが１の人身事故が発生したことを示している。
【００２５】
電車故障・事故についても、顧客情報ＤＢ２２に格納されている顧客情報を用いる。ただし、用いる情報は他の災害情報の場合よりも限定することができる。図１２に電車故障・事故の場合にマッチング処理に用いる顧客情報を示すが、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＣＯＵＲＳＥ」を用いる。
【００２６】
以上のように、鉄道情報の場合、路線および駅を特定するが、そのままでは顧客情報として格納されている地理的情報とのマッチング処理を行なうことができない。そこで、路線を地理的情報に変換する処理を行なう。そのために、配信情報管理部３０は、図１３に示すような路線−地域変換テーブルを備える。路線−地域変換テーブルは、路線が通過する地域の情報を有している。この地域は、顧客情報における「ＣＩＴＹ」に該当する地理的情報として与えられる。具体的には、図１３に示すように、東急東横線であれば、東急東横線が通過する目黒区、渋谷区、横浜市、その他が記述されている。また、ＪＲ山手線であれば、山手線が通過する千代田区、目黒区、渋谷区、その他が記述されている。路線−地域変換テーブルは、このように、路線毎にその路線が通過する地理的情報を記述する。
また、配信情報管理部３０は、マッチング・テーブルを備えているが、その形式が図１０に示したものと同様であるので、その説明を省略する。
【００２７】
さて、図１４に基づいて鉄道情報についてのマッチング処理を説明する。
図１４に示す例は、図１１に示した災害情報のうち、山手線で発生したドア故障が新たに災害情報ＤＢ１３に登録された際に、図１２に示した３名の顧客Ｘ、ＹおよびＺに対して当該災害情報を配信するか否かをマッチング・テーブルに基づいて決定する手順を示している。
災害情報ＤＢ１３から配信情報管理部３０に転送された災害情報は、路線−地域変換テーブルにより、その路線情報が地理的な情報に変換される。具体的には、「ＲＡＩＬＷＡＹ」の「山手線」が、路線−地域変換テーブルによって、渋谷区、目黒区…の情報に変換される。
【００２８】
顧客ＸはコースＡを選択しているので、コースＡについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。対象としている電車故障・事故の災害レベルであるＬＶは２であるから、マッチング・テーブルのＬＶ２の欄を参照することになる。マッチング・テーブルのＬＶ２の欄を参照すると、「ＣＩＴＹ」および「ＴＯＷＮ」の欄に配信を意味する○が付されている。顧客Ｘの顧客情報における「ＣＩＴＹ」は目黒区である。一方、路線−地域変換テーブルから山手線は目黒区、渋谷区…に変換されている。したがって、災害情報と顧客情報とは「ＣＩＴＹ」が一致するから、当該災害情報は顧客Ｘに配信される。図１５（ｂ）に顧客の携帯電話５３，５４に配信された情報を示す画面の一例を示す。
顧客ＹはコースＢを選択しているので、コースＢについてのマッチング・テーブルを参照する。コースＢについてのマッチング・テーブルは、ＬＶ２の災害情報を配信しないこととしている。したがって、当該災害情報は、顧客Ｙに対して配信されない。
顧客ＺはコースＢを選択している。したがって、コースＡについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。顧客Ｚの「ＣＩＴＹ」は渋谷区であり、顧客Ｘと同様に、災害情報と顧客情報とは「ＣＩＴＹ」が一致することになるから、当該災害情報は顧客Ｚに配信される。
【００２９】
（第２の実施形態）
以上の第１の実施形態では、情報配信装置１から顧客の携帯電話５３，５４に所定の災害情報を配信する。災害情報が配信された顧客が、その時点で当該災害の発生した地域にいたとすると、当該災害に関する情報をその顧客から入手することができる。そこで、本発明では、顧客の携帯電話５３，５４に災害情報を配信するのみならず、アンケートという形で顧客から当該災害に関する情報を入手することを提案する。
図１６は、顧客から当該災害に関する情報を入手することを実現するための情報配信装置２００の構成を示すブロック図である。なお、第１の実施形態による情報配信装置１と同一の構成部分については同一の符号を付すことによりその説明を省略する。
【００３０】
情報配信装置２００は、アンケートＤＢ（データ・ベース）６０、アンケート管理部７０およびＷＥＢサイト８０を備えている。
アンケートＤＢ６０は、災害の種別に応じた種々のアンケートを格納している。配信情報管理部３０が災害情報を顧客の携帯電話５３に配信する際に、災害の種別に応じたアンケートをアンケートＤＢ６０から入手して携帯電話５３に配信する。図１８（ａ）に携帯電話５３に送信したアンケート画面の一例を示す。この例では、地震情報を顧客に対して配信した際のアンケートを示している。
アンケート管理部７０は、顧客に対して行なった災害情報のアンケートの回答を回収し、かつ解析を行なう。解析した結果は、アンケートＤＢ６０に転送して格納する。さらに、アンケート結果はＷＥＢサイト８０に掲載する。このＷＥＢサイト８０を参照することにより、災害の詳しい情報を得ることができる。
アンケートＤＢ６０に格納された情報は、自動入力アプリケーション１２を介して災害情報ＤＢ１３に格納される。そして、この情報は、新たな災害情報として、顧客への配信情報として活用することができる。
【００３１】
（第３の実施形態）
第１の実施形態では、情報配信装置１から顧客の携帯電話５３，５４に所定の災害情報を配信する。その配信システムを用いることにより、第３の実施形態では、罹災した顧客に対して見舞金の支払いを実行するシステムを提案する。
図１７は、見舞金の支払いを実行するための情報配信装置３００の構成を示すブロック図である。なお、第１の実施形態による情報配信装置１と同一の構成部分については同一の符号を付すことによりその説明を省略する。
【００３２】
情報配信装置３００は、受信メール管理部８５、顧客口座ＤＢ（データ・ベース）９０および見舞金支払い管理部１００を備えている。
情報配信装置３００の配信情報管理部３０は、例えば地震情報を配信するに際して、見舞金の支払いについての問い合わせを行なう。見舞金の支払いを問い合わせる画面の例を図１８（ｂ）に示す。顧客が現実に罹災して見舞金の支払いを依頼するときは、この問い合わせに対する返信を利用することができる。
受信メール管理部８５は、顧客の携帯電話５３からの見舞金支払いを依頼するメールを受信する。受信メール管理部８５は、見舞金支払いを依頼するメールを受信すると、依頼された顧客を特定する情報、例えばメール・アドレスを見舞金支払い管理部１００に転送する。
顧客口座ＤＢ９０は、メール・アドレス等の顧客を特定する情報と当該顧客があらかじめ登録している銀行、郵便局等の預貯金の口座とを対応して格納している。
見舞金支払い管理部１００は、メール・アドレスを受信メール管理部８５から受信すると、顧客口座ＤＢ９０に格納されている情報を入手して、当該顧客の預貯金口座を特定する。さらに、その預貯金口座が開設された金融機関１１０に対して、見舞金を振り込む。
【００３３】
以上本発明の実施の形態について説明してきたが、本発明は以上の実施形態に限定されない。例えば、配信される情報は災害に限定されず、その発生地を特定することのできる情報に普遍的に適用することができる。
【００３４】
【発明の効果】
以上説明したように、本発明によれば、顧客は、顧客地域情報あるいはさらにコース情報を登録するという簡易な手続きで、自分の欲しい情報の配信を受けることができる。
【図面の簡単な説明】
【図１】 ＤＬＣテーブルを示す図である。
【図２】 第１の実施形態による災害情報配信システムの構成概略を示すブロック図である。
【図３】 第１の実施形態による情報配信装置の具体的構成を示すためのブロック図である。
【図４】 第１の実施形態における災害情報ＤＢの内容を示す図である。
【図５】 第１の実施形態における顧客情報ＤＢの内容を示す図である。
【図６】 第１の実施形態におけるマッチング・テーブルの内容を示す図である。
【図７】 第１の実施形態における顧客情報の登録の手順を示す図である。
【図８】 第１の実施形態における顧客情報の登録の手順を示す図である。
【図９】 第１の実施形態における顧客情報の登録の手順を示す図である。
【図１０】 第１の実施形態におけるマッチング・ロジックを示す図である。
【図１１】 第１の実施形態における災害情報ＤＢの内容を示す図である。
【図１２】 第１の実施形態における顧客情報ＤＢの内容を示す図である。
【図１３】 第１の実施形態における路線−地域変換テーブルの内容を示す図である。
【図１４】 第１の実施形態におけるマッチング・ロジックを示す図である。
【図１５】 第１の実施形態において顧客の携帯電話に表示される画面の例を示す図である。
【図１６】 第２の実施形態による情報配信装置の構成を示す図である。
【図１７】 第３の実施形態による情報配信装置の構成を示す図である。
【図１８】 第２および第３の実施形態において顧客の携帯電話に表示される画面の例を示す図である。
【符号の説明】
１，２００，３００…情報配信装置、２…顧客、３…災害情報ソース、４…インターネット、１０…災害情報管理部、１１…情報入力アプリケーション、１２…自動入力アプリケーション、１３…災害情報ＤＢ、２０…顧客情報管理部、２１…顧客情報登録アプリケーション、２２…顧客情報ＤＢ、３０…配信情報管理部、４０…情報配信部、５１，５２，５３，５４…携帯電話、６０…アンケートＤＢ、７０…アンケート管理部、８０…ＷＥＢサイト、８５…受信メール管理部、９０…顧客口座ＤＢ、１００…見舞金支払い管理部
【発明の属する技術分野】
本発明は、インターネット等のネットを介して情報を流通させるシステムに関し、特に災害情報を顧客に対して配信するシステムに関するものである。
【０００２】
【従来の技術】
災害に関する情報は速やかに、全ての人々によって共有されなければならないという性格を持つ。現状ではそういった類の情報はマスメディアによって配信される、マスな情報のみである。しかし、前述のように、災害に関するあらゆる情報、つまり災害情報の共有は災害大国日本における社会基盤整備の中でも急務の課題である。
災害情報を流通させるために、インターネットを用いることができる。しかしながら、現状の情報伝達体制をそのままインターネットに持ち込んでしまっては、膨大な災害情報を無差別に個々人に送りつけることになる。これでは、個々人が受け取る情報が過多になり、その個々人にとって本当に必要な情報が埋没してしまうおそれがある。また、さらには個々人と無関係の情報が送られることによって災害情報への無関心を逆に促進させる結果ともなり兼ねない。
【０００３】
【発明が解決しようとする課題】
災害情報は、火災・気象（豪雨・雷・雪等）・電車運行・道路・大災害（地震・噴火・津波・台風等）情報といった、日々の日常的な災害から何年かに一度の大災害に関する情報を包含する。このような膨大な情報の中から、個々人にとって必要な災害情報を的確に伝えるかという部分が非常に重要な課題となっている。しかし、現存するインターネットのシステムを用いる場合には、顧客が必要とする情報配信を受けるためには、一つ一つの配信登録条件を設定する必要がある。遠方で起こった災害の際には、どのような情報が欲しいか、電車の運行情報は必要か、気象情報ならどうなのか、一方、近所で発生した災害については、どれほど小規模な災害まで受け取るか、小火火災は必要か、交通事故はどうなのか、など煩雑な条件設定が必要とされる。しかしながら、ここまでの詳細な設定は現実的ではないため、おおまかな設定項目のみで、マスな情報配信となろう。したがって、現存するシステムでは、顧客が本当に必要とする情報を個別に配信することを実現することができない。
したがって本発明は、顧客が煩雑な設定をすることなく、当該顧客に対して必要な情報配信を行なうことのできるシステムを提供することを課題とする。
【０００４】
【課題を解決するための手段】
本発明者等は、膨大な調査を行なうことにより、顧客は、地理的な情報を基準にして自分が必要とする災害情報を取捨選択することを知見した。つまり、顧客は、自分に近い地域ほど細かい災害情報を要求し、遠くなるほど大災害に関しての情報しか要求しないという傾向がある。
これを図示したものが図１に示すテーブルである。このテーブルは、Ｘ軸が顧客からの距離（Distance）、Ｙ軸が災害レベル（Level）およびＺ軸が災害カテゴリ（Category）を示している。このテーブルは、距離（Distance）、災害レベル（Level）および災害カテゴリ（Category）の頭文字を採って、ＤＬＣテーブルと称することができる。
ＤＬＣテーブルにおいて、顧客からの距離は、通常、顧客の自宅住所地からの距離となる。被害の小さいものがレベル小となり、被害の大きいものはレベル大となる。同じ地震であっても、その震度（あるいは地震のエネルギーを示すマグニチュード）の値によって、レベル小〜大が決定される。災害カテゴリは、例えば、テーブルａが火災、テーブルｂが地震、テーブルｃが台風、テーブルｄが津波というように、災害の種別を示している。テーブルは、災害カテゴリ毎に用意される。テーブルａ〜ｄはあくまで例示であり、他の災害に対応する数のテーブルを用意することができる。
【０００５】
ＤＬＣテーブルにおいて、テーブルａ上に記述された台形状の領域が、顧客が欲する距離と災害レベルの関係を示している。つまり、顧客自身からの距離が近い場合には、災害レベルの低い情報であっても、顧客は取得することを欲する。しかし、顧客自身からの距離が遠くなると、災害レベルの小さい災害についての情報の取得は望まなくなる。台形状の領域は顧客の災害情報に関するニーズを示している。したがって、この領域を配信設定領域として、これに含まれる災害情報を顧客に対して配信すれば、顧客の災害情報に関する取得ニーズを満足できることになる。そして、ＤＬＣテーブルは、災害のカテゴリ毎に地域および災害レベルという２つの要素を選定するという簡易な手続きだけで、顧客がそのニーズにマッチする災害情報を取得できることを示している。
【０００６】
さて、本発明はＤＬＣテーブルに示された理論に基づいて災害情報を配信することを基本とする。そのために、情報配信者側は、取得した災害情報をデータ・ベースに格納する際に、災害発生地、災害レベルおよび災害カテゴリを含む災害情報を作成する。一方、配信サービスを受ける顧客側は、地域を設定する。情報配信者は、設定された地域を含む顧客情報を作成する。この災害情報および顧客情報をＤＬＣテーブルが反映された所定の条件下で照合すれば、顧客のニーズに合った災害情報を配信することができる。
【０００７】
したがって本発明は、災害情報を顧客側端末に配信する情報配信装置であって、災害が発生した地域を特定する災害地域情報とあらかじめ設定された複数の設定災害レベルのうち当該災害が該当する実災害レベルとを対応付けて記憶する災害情報記憶部と、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、前記実災害レベルと一致する前記設定災害レベルについて、前記災害地域情報と前記顧客地域情報との照合を行なうことにより前記災害情報の配信可否を判断する配信情報管理部と、前記配信情報管理部における配信可否の判断に基づき配信可とされた災害情報を前記顧客側端末に配信する情報配信部と、を備えていることを特徴とする情報配信装置である。
本発明の情報配信装置において、顧客は、顧客地域情報を登録しておけば、そのニーズに合った災害情報の配信を受けることができる。
本発明の情報配信装置において、顧客が設定する顧客地域情報は、地域情報を階層化して記憶しておくことが望ましい。階層化とは、例えば、都道府県と市区町村の関係が該当する。より具体的には、「東京都」と「港区」あるいは「神奈川県」と「藤沢市」との関係が該当する。もっとも、本発明の顧客地域情報はこのような行政単位に限定されない。このように地域情報を階層化して記憶するのは、災害のレベルによっては、「港区」内で発生した災害情報の配信を要求するが、「東京都」内であっても「港区」外で発生した災害情報の配信を要求しない、という顧客のニーズに対応するためである。したがって、前記災害情報記憶部は、前記災害地域情報を、階層的に記憶することが、前記配信情報管理部における照合にとって望ましい。
本発明の情報配信装置はインターネット等のネットワークを介して顧客側端末に情報を配信する。本発明の情報配信装置において、顧客側端末の形態は問われないが、携帯端末、特にネットワークに接続の可能な携帯電話が有効である。
【０００８】
本発明において、前記災害情報記憶部は、前記災害地域情報および前記実災害レベルに対応して災害の種別を記憶することができる。そしてその場合、前記配信情報管理部は、前記災害の種別毎に配信可否を判断することになる。災害には、前述のように、火災、気象、地震等多くの種別があり、災害の種別に応じた適切な判断を行なうためである。
また本発明において、前記災害情報記憶部は、前記災害地域情報および前記実災害レベルに対応してさらに災害の内容を記憶し、前記情報配信部は、前記災害の種別、前記災害地域情報および前記災害の内容を前記災害情報として前記顧客側端末に配信することが望ましい。
【０００９】
以上の情報配信装置は、配信する情報として災害情報を対象とした。しかし、災害情報に限らず、本発明の思想は、発生地域を特定できる事象に関する情報一般に適用することができる。経済情報、選挙を含む政治情報、スポーツ情報等のように、全国的な情報とローカル的な情報とに区別できる事象情報について本発明の思想を適用することができる。すなわち本発明の情報配信装置は、発生地域を特定できる事象に関する事象情報を入手しかつ所定の条件を満足する顧客に対してのみ当該事象情報を配信する情報配信装置であって、階層化された地理的な単位毎に事象のレベルに関連付けて情報配信の要否を定める判断基準を備えた配信情報管理部と、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、を備え、前記配信情報管理部は、新たな事象情報を入手すると、前記地理的な単位のいずれかにおいて、前記顧客地域情報が前記発生地域と一致する場合に、前記判断基準に基づいて情報配信の可否を決定することを特徴とする。
この情報配信装置において、配信の可否は事象のレベルを考慮しつつ地理的な情報を比較することを基本としている。
【００１０】
本発明の情報配信装置において、前記配信情報管理部は、前記判断基準を複数備えるとともに、複数の前記判断基準毎に前記各判断基準を引用するための引用情報を設定し、前記顧客情報登録部は、いずれかの前記引用情報を登録し、前記配信情報管理部は、前記顧客情報登録部に登録された前記引用情報を確認し、確認された前記引用情報に該当する判断基準に基づいて情報配信の可否を決定することができる。経済情報、選挙を含む政治情報、スポーツ情報等、事象の種別に対応するためである。
また本発明の情報配信装置において、前記配信情報管理部は、前記顧客に対して前記事象情報を配信する際に、前記事象に関するアンケートを配信することができる。例えば、災害情報を配信した場合に、災害発生地あるいはその近傍にいる顧客から、災害の最新情報を受信し、その情報を新たに顧客に対して配信することができる。アンケートは事象ごとに用意されるのが望ましい。
さらに本発明の情報配信装置において、前記配信情報管理部は、 前記顧客に対して前記事象情報を配信する際に、前記顧客に対して見舞金の支払いの用意があることを通知することができる。災害に罹災した顧客に対し、迅速な見舞金の支払いを可能にする。
【００１１】
本発明を鉄道、道路等の路線において生じた事象についての情報配信装置に適用する場合には以下の構成とすることが推奨される。すなわち本発明の情報配信装置は、路線によって発生地域を特定できる事象情報を入手しかつ所定の条件を満足する顧客に対して当該事象情報を配信する情報配信装置であって、階層化された地理的な単位毎に災害のレベルに関連付けて情報配信の要否を定める判断基準を備えた配信情報管理部と、事象の発生した路線情報を、当該路線が通過する地域情報に変換する路線−地域変換部と、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、を備え、前記配信情報管理部は、新たな事象情報を入手すると、前記地理的な単位のいずれかにおいて、前記地理的な単位が前記発生地域と一致する場合に、前記判断基準に基づいて情報配信の可否を決定することを特徴とする。
鉄道における故障、事故は、当該路線によって発生地を特定する。しかし、路線情報は地域情報の一種と言えるものの、そのままでは顧客情報登録部に登録された顧客地域情報との対比が行なえない。そこで本発明では、この路線情報を、当該路線が通過する地域の情報に変換するのである。
【００１２】
本発明は、また、所定の地域で発生した災害に関する情報を顧客に配信するための情報配信装置であって、前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、前記災害の発生地域および前記災害のレベルを記憶する災害情報記憶部と、前記レベルを考慮しつつ前記顧客地域情報と前記発生地域とを比較することにより前記災害に関する情報を前記顧客に配信するか否か判断する配信情報管理部と、を備えたことを特徴とする情報配信装置である。
本発明の情報配信装置において、前記配信情報管理部は、前記顧客地域と前記発生地域との距離的な関係を比較することにより、前記災害に関する情報を前記顧客に配信するか否か判断する。
【００１３】
本発明はまた、所定の地域で発生した災害に関する情報を顧客に配信するための情報配信方法であって、前記顧客が情報の配信を要求する根拠となる顧客地域情報を登録するステップ（ａ）と、前記災害の発生地域および前記災害のレベルを特定するステップ（ｂ）と、前記レベルを考慮しつつ前記顧客地域と前記発生地域との距離的な関係を比較することにより前記災害に関する情報を前記顧客に配信するか否か判断するステップ（ｃ）と、を備えたことを特徴とする情報配信方法を提供する。
本発明の情報配信方法において、前記ステップ（ｃ）は、前記レベルが高い場合には、前記顧客地域と前記発生地域とが離間していても前記災害に関する情報を前記顧客に配信するものと判断することができる。重大な災害については、遠方で発生してもその情報を入手したいという要求に応えるためである。
さらに本発明は、前記ステップ（ｃ）は、前記レベルが低い場合には、前記顧客地域と前記発生地域とが一致または近接している場合に前記災害に関する情報を前記顧客に配信するものと判断することができる。
【００１４】
本発明は、さらに以下の情報配信方法を提供する。すなわち本発明の情報配信方法は、 災害情報を顧客側端末に配信する情報配信方法であって、災害が発生した地域を特定する災害地域情報とあらかじめ設定された複数の設定災害レベルのうち当該災害が該当する実災害レベルとを対応付けて記憶するステップと、前記顧客が設定する顧客地域情報を登録するステップと、前記実災害レベルと一致する前記設定災害レベルについて、前記災害地域情報と前記顧客地域情報との照合を行なうことにより前記災害情報の配信可否を判断するステップと、前記配信可否の判断に基づき配信可とされた災害情報を前記顧客側端末に配信するステップと、を備えていることを特徴とする。
また本発明の情報配信方法は、発生地域を特定できる事象に関する事象情報を入手しかつ所定の条件を満足する顧客に対して当該事象情報を配信する情報配信方法であって、階層化された地理的な単位毎に事象のレベルに関連付けて情報配信の要否を定める判断基準を用意するステップと、前記顧客が設定する顧客地域情報を登録するステップと、新たな事象情報を入手すると、前記地理的な単位のいずれかにおいて、前記顧客地域情報が前記発生地域と一致する場合に、前記判断基準に基づいて情報配信の可否を決定するステップと、を備えることを特徴とする。
さらに本発明の情報配信方法は、所定の地域で発生した災害に関する情報を顧客に配信するための情報配信方法であって、前記顧客が設定する顧客地域情報を登録するステップと、前記災害の発生地域および前記災害のレベルを記憶するステップと、前記レベルを考慮しつつ前記顧客地域情報と前記発生地域とを比較することにより前記災害に関する情報を前記顧客に配信するか否か判断するステップと、を備えたことを特徴とする。
本発明はさらに、コンピュータに、顧客が情報の配信を要求する根拠となる顧客地域を設定する処理（ａ）と、災害の発生地域および災害のレベルを特定する処理（ｂ）と、前記レベルを考慮しつつ前記顧客地域と前記発生地域との距離的な関係を比較することにより前記災害に関する情報を前記顧客に配信するか否か判断する処理（ｃ）と、を実行するためのプログラムを提供する。
【００１５】
【発明の実施の形態】
以下本発明を実施の形態に基づいて説明する。
（第１の実施形態）
図２は、第１の実施形態による災害情報配信システムの構成概略を示すブロック図である。図２に示すように、第１の実施形態による災害情報配信システムは、災害情報を提供する情報配信者が情報配信装置１を構築している。情報配信装置１は、災害情報ソース３から災害情報を入手する。そして、入手した災害情報をカスタマイズして顧客２へ配信する。
顧客２は、例えばインターネット４を介して携帯電話、パーソナル・コンピュータ（ＰＣ）、カーナビ、電光掲示板、コンビニエンスストアに設置されている端末（コンビニ端末）、デジタル家電等の端末によって、情報配信装置１から提供される災害情報を取得することができる。
情報配信装置１、災害情報ソース３から種々の災害情報を入手する。災害情報ソース３における災害情報としては、消防情報、河川情報、鉄道情報、道路情報、交通情報、気象情報、地震情報、火山情報、リコール情報、犯罪情報を含む。消防情報は、火災の発生のほか、爆発事故を含む。河川情報は、河川の増水警報を含む。鉄道情報は、電車の遅延あるいは復旧に関する情報を含む。道路情報は、自動車事故に関する情報、渋滞情報を含む。気象情報は、天気、各種注意報・警報、降水確率を含む。地震情報は地震の震度、地震による被害状況を含む。火山情報は、火山の噴火情報を含む。リコール情報は、食品、機械その他市場に流通している製品についてのリコール情報を含む。情報配信者は、これら種々の災害情報を入手し、かつ後述する情報配信装置１のデータ・ベースに格納する。
【００１６】
図３は、情報配信装置１の具体的構成を示すためのブロック図である。なお、図３に示すシステムは、顧客の携帯電話５１〜５４に災害情報を配信する例を示してある。
情報配信装置１は、災害情報管理部１０と、顧客情報管理部２０と、配信情報管理部３０と、情報配信部４０とを備えている。
災害情報管理部１０は、情報入力アプリケーション１１と、自動入力アプリケーション１２と、災害情報ＤＢ（データ・ベース）１３とを備えている。
情報入力アプリケーション１１は、災害情報ソース３から入手した災害情報をマニュアルで入力するためのアプリケーションである。また、自動入力アプリケーション１２は、災害情報ソース３からデジタル情報として入手した災害情報を自動で入力するためのアプリケーションである。情報入力アプリケーション１１および自動入力アプリケーション１２から入力された災害情報は、災害情報ＤＢ１３に格納される。
災害情報ＤＢ１３には、地理的な情報、災害の種別、災害のレベルおよび災害の内容に区分されて災害情報が格納される。図４にその１例を示す。地理的な情報は、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＴＯＷＮ」の３つの階層に区分される。図４に示すように、「ＳＴＡＴＥ」は東京都、北海道等の都道府県を示す情報である。「ＣＩＴＹ」は港区、藤沢市等の行政単位としての区および市町村を示す情報である。「ＴＯＷＮ」は、六本木３丁目、桐原町等の区および市町村内の地域単位を示す情報である。図４において、「ＣＡＴＥＧＯＲＹ」は災害の種別を示す情報である。具体的には、出火報、気象情報、地震情報といった災害の種別を示す。図４において、「ＬＶ」は災害のレベルを示す。このレベルは、災害の種別（「ＣＡＴＥＧＯＲＹ」）毎に、１〜３の３つにランク付けした情報である。第１の実施形態では、１が重大な災害を、２が中程度の災害を、また３が軽度の災害を示している。また、図４において、「ＤＥＴＡＩＬ」は、「ビル１３階爆発火災」、「倉庫 小火」というように、災害の内容を示す情報である。災害情報ＤＢ１３の災害情報は、災害情報ソース３から災害情報を入手する度に更新される。また、災害情報ＤＢ１３が更新されるたびに、当該新たな災害情報は配信情報管理部３０に転送される。
【００１７】
顧客情報管理部２０は、顧客情報登録アプリケーション２１および顧客情報ＤＢ（データ・ベース）２２を備えている。顧客情報登録アプリケーション２１、本システムによるサービスの提供を受ける各顧客に関する情報を顧客情報ＤＢ２２に登録する作業を支援する。顧客情報は、図５に示すような形式で顧客情報ＤＢ２２に登録される。
図５において、「ＵＳＥＲ」は顧客を特定する情報を示す。図５の例は、Ｘ、ＹおよびＺという３名の顧客に関する情報が示されている。「ＵＳＥＲ」には、携帯電話に用いられるメール・アドレスを用いることができる。各顧客について、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＴＯＷＮ」からなる階層化された地理的な情報、ならびに「ＣＯＵＲＳＥ」についての情報が登録される。地理的な情報は、各顧客が設定する顧客地域情報であり、自宅住所を設定することができる。その場合、図５は、顧客Ｘの自宅住所が東京都港区六本木に存在し、顧客Ｙの自宅住所が東京都港区大門に存在し、さらに顧客Ｚは東京都港区六本木に自宅住所が存在していることを示す。顧客は、自宅住所を含む地域に発生した災害情報に最も注目するからである。図５において、「ＣＯＵＲＳＥ」は、ＡおよびＢの２種類から選択することができるが、その具体例は後述する。
【００１８】
配信情報管理部３０は、災害情報ＤＢ１３から新たな災害情報を受信する。そして、配信情報管理部３０は、新たな災害情報を受信すると、顧客情報ＤＢ２２に登録されている各顧客情報とマッチング処理を行なう。このマッチング処理の結果、新たな災害情報を配信する顧客が決定される。配信情報管理部３０は、マッチング処理を行なうためのマッチング・テーブルを備えている。災害情報の種別、つまり「ＣＡＴＥＧＯＲＹ」毎にマッチング・テーブルは用意される。また、各「ＣＡＴＥＧＯＲＹ」において、前述したコース毎にマッチング・テーブルは用意される。
【００１９】
図６に出火報についてのマッチング・テーブルの例を示している。マッチング・テーブルは、コースＡおよびコースＢの２枚から構成される。
マッチング・テーブルは、階層化された地理的な情報と災害のレベルとを関連付けかつ災害情報の配信の要否を定めるものである。コースＡについてのマッチング・テーブルについてその内容を説明する。災害レベルＬＶが３の災害情報については、配信情報管理部３０から転送された災害情報の「ＴＯＷＮ」と顧客情報ＤＢ２２から入手した顧客情報の「ＴＯＷＮ」とが一致した場合にのみ、当該災害情報を当該顧客に配信する。マッチング・テーブルの「○」は、情報を配信することを意味している。災害レベルＬＶが２の災害情報については、配信情報管理部３０から転送された災害情報の「ＣＩＴＹ」と顧客情報ＤＢ２２から入手した顧客情報の「ＣＩＴＹ」とが一致した場合に、当該災害情報を当該顧客に配信する。この場合、配信情報管理部３０から転送された災害情報の「ＴＯＷＮ」と顧客情報ＤＢ２２から入手した顧客情報の「ＴＯＷＮ」とが不一致でも、当該災害情報が当該顧客に配信される。さらに、災害レベルＬＶが１の災害情報については、配信情報管理部３０から転送された災害情報の「ＳＴＡＴＥ」と顧客情報ＤＢ２２から入手した顧客情報の「ＳＴＡＴＥ」とが一致した場合に、当該災害情報を当該顧客に配信する。この場合、配信情報管理部３０から転送された災害情報の「ＴＯＷＮ」と顧客情報ＤＢ２２から入手した顧客情報の「ＴＯＷＮ」と、また配信情報管理部３０から転送された災害情報の「ＣＩＴＹ」と顧客情報ＤＢ２２から入手した顧客情報の「ＣＩＴＹ」とが不一致でも、当該災害情報が当該顧客に配信される。また、マッチング・テーブルの「ＡＬＬ」は、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＴＯＷＮ」のいずれもが不一致であっても、情報の配信を行なうことを意味する。これは、顧客地域情報と災害の発生地域とが離間していても情報の配信を行なうケースの１つである。コースＢについてのマッチング・テーブルも同様の規則にしたがっている。
【００２０】
情報配信部４０は、配信情報管理部３０において配信することを決定した災害情報を所定の顧客にメール情報として配信する。顧客は、この配信情報を携帯電話５１〜５４にて受信する。第１の実施形態では、図２に示したように、インターネット４を介して顧客の携帯電話５１〜５４に配信するため、携帯電話５１〜５４は、インターネット対応型の携帯電話である。携帯電話５１〜５４は、キャリア（携帯電話会社）毎に通信方式が異なるため、情報配信部４０は、携帯電話５１〜５４の通信方式に応じた情報を配信する。
【００２１】
第１の実施形態による災害情報配信サービスを利用する顧客となるためには、図３に示すように、携帯電話５１，５２によって顧客登録を行なう必要がある。顧客登録の手順を図７〜図９に基づいて説明する。
携帯電話５１（５２）から情報配信装置１にアクセスすると、図７（ａ）に示すように、パスワード入力画面が表示される。顧客は、この入力画面で自分が使用するパスワードを入力する。また、この入力画面には、携帯電話５１に付与されるメール・アドレスが表示される。パスワード入力、送信後には、図７（ｂ）に示すように、自宅住所の設定画面が表示される。この画面では、関東、東海等のエリアを選択する。図７（ｂ）の例では関東を選択している。エリア選択後には、図７（ｃ）に示すように、都道府県を選択する画面が表示される。図７（ｃ）の例では東京２３区を選択している。都道府県を選択後には、図７（ｄ）に示すように、市区町村を選択する画面が表示される。図７（ｄ）の例では目黒区を選択している。次いで、図８（ｅ）に示すように、市区町村内の地域を選択する画面が表示される。以上で自宅住所に関する情報の登録が終了する。次に、図８（ｆ）に示すように、コースを選択する画面が表示される。コースはＡまたはＢから選択する。図８（ｆ）の例では、Ａコースを選択している。コース選択が終了すると、登録事項を確認するための画面が表示される。図８（ｇ）に示すように、選択地域として「東京都目黒区中目黒」が、また選択コースとして「Ａ」が表示される。またこの画面では、他の地域についての登録を促しており、例えば実家の住所、勤務先の住所、その他を登録することもできる。次いで、図８（ｈ）に示すように、携帯電話５１の種類を登録する画面が表示される。携帯電話５１の種類が３種類表示され、その中から選択することになる。いずれかを選択すると、図９（ｉ）に示すように、携帯電話５１の種類を確認する画面が表示される。確認を送信すると、図９（ｊ）に示すような登録完了を告げる画面が表示される。
【００２２】
次に、配信情報管理部３０におけるマッチング処理の詳細を図１０に基づいて説明する。
図１０に示す例は、図４に示した災害情報のうち、六本木で発生した爆発火災が新たに災害情報ＤＢ１３に登録された際に、図５に示した３名の顧客Ｘ、ＹおよびＺに対して当該災害情報を配信するか否かを図６に示したマッチング・テーブルに基づいて決定する手順を示している。
配信情報管理部３０は、災害情報ＤＢ１３から災害情報を、また顧客情報ＤＢ２２から顧客情報を入手する。図１０の例では、災害情報は「東京都」「港区」「六本木」「ＬＶ＝２」「出火報」を示している。
顧客ＸはコースＡを選択しているので、コースＡについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。ＬＶ＝２であるから、マッチング・テーブルのＬＶ２の欄を参照することになる。顧客情報の「ＣＩＴＹ」が「港区」であり、災害情報の「ＣＩＴＹ」と一致する。そして、マッチング・テーブルのＬＶ２欄の「ＣＩＴＹ」には、配信することを示す○が付されているから、この災害情報は顧客Ｘに配信されることになる。図１５（ａ）に顧客の携帯電話５３，５４の配信された情報を示す画面の一例を示す。
【００２３】
顧客ＹはコースＡを選択しているので、顧客Ｘと同様に、コースＡについてのマッチング・テーブルを用いてマッチング処理が行なわれる。顧客Ｙの「ＴＯＷＮ」は「大門」であり、災害情報の「ＴＯＷＮ」と異なるが、その上のレベルの「ＣＩＴＹ」で「港区」が一致している。しかも、コースＡでは「ＣＩＴＹ」のＬＶ２についての情報は配信されることになっている。したがって、この災害情報は顧客Ｙに対して配信される。
顧客ＺはコースＢを選択しているので、コースＢについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。ＬＶ＝２であるから、マッチング・テーブルのＬＶ２の欄を参照することになる。顧客Ｚについての顧客情報は、「ＣＩＴＹ」が「港区」、「ＴＯＷＮ」が「六本木」であるから、災害情報の「ＣＩＴＹ」および「ＴＯＷＮ」が一致している。しかし、コースＢに関するマッチング・テーブルのＬＶ２の欄には、配信を意味する○が付されていないので、当該災害情報は顧客Ｚに対しては配信されない。
以上のように、マッチング処理は、災害のレベルを考慮しつつ顧客地域情報と災害発生地域を比較する処理ということができる。そして、この比較は、顧客地域情報と災害発生地域との距離的な関係を比較するものと言うこともできる。例えば、「ＴＯＷＮ」同士のみが一致する場合、近距離の関係にある。一方、「ＳＴＡＴＥ」同士のみが一致する場合、遠距離の関係にある。
【００２４】
本発明は、先に説明したように、電車故障・事故といった鉄道情報も災害情報として取り扱っている。鉄道情報の場合、路線および駅によって災害発生の地理的情報を特定するという特殊性を有している。したがって、鉄道情報に関しては、路線および駅についての情報をそのまま用いて図６に示したマッチング・テーブルによりマッチング処理を行なうことはできないので、路線から地理的情報に変換する処理を行なう必要がある。
図１１は、鉄道に関する災害情報における災害情報ＤＢ１３における情報格納の内容を示す図である。鉄道に関する災害情報は、災害種別を示す「ＣＡＴＥＧＯＲＹ」、災害が発生した路線を示す「ＲＡＩＬＷＡＹ」、災害が発生した駅を示す「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」に分類される。ここで、駅について「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」と２つの駅を格納するのは、２つの駅間で災害が発生する場合を考慮したためである。駅構内で災害が発生した場合には、「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」の駅名が一致する。「ＬＶ」は災害のレベルを示す。また、「ＤＥＴＡＩＬ」は災害の具体的な内容を示す。
図１１の例では、「ＣＡＴＥＧＯＲＹ」には全て、電車故障・事故が記述される。図１１の最上行の記載された災害情報は、山手線（「ＲＡＩＬＷＡＹ」）の渋谷駅（「ＳＴＡＴＩＯＮ１」）と原宿駅（「ＳＴＡＴＩＯＮ２」）との間で、ドア故障が発生したこと、このドア故障の災害レベルは３（ＬＶ）と軽度であることを示している。次の行に記載の災害は、中央線（「ＲＡＩＬＷＡＹ」）の国立駅構内（「ＳＴＡＴＩＯＮ１」および「ＳＴＡＴＩＯＮ２」が「国立」）で、災害レベルが１の人身事故が発生したことを示している。
【００２５】
電車故障・事故についても、顧客情報ＤＢ２２に格納されている顧客情報を用いる。ただし、用いる情報は他の災害情報の場合よりも限定することができる。図１２に電車故障・事故の場合にマッチング処理に用いる顧客情報を示すが、「ＳＴＡＴＥ」、「ＣＩＴＹ」および「ＣＯＵＲＳＥ」を用いる。
【００２６】
以上のように、鉄道情報の場合、路線および駅を特定するが、そのままでは顧客情報として格納されている地理的情報とのマッチング処理を行なうことができない。そこで、路線を地理的情報に変換する処理を行なう。そのために、配信情報管理部３０は、図１３に示すような路線−地域変換テーブルを備える。路線−地域変換テーブルは、路線が通過する地域の情報を有している。この地域は、顧客情報における「ＣＩＴＹ」に該当する地理的情報として与えられる。具体的には、図１３に示すように、東急東横線であれば、東急東横線が通過する目黒区、渋谷区、横浜市、その他が記述されている。また、ＪＲ山手線であれば、山手線が通過する千代田区、目黒区、渋谷区、その他が記述されている。路線−地域変換テーブルは、このように、路線毎にその路線が通過する地理的情報を記述する。
また、配信情報管理部３０は、マッチング・テーブルを備えているが、その形式が図１０に示したものと同様であるので、その説明を省略する。
【００２７】
さて、図１４に基づいて鉄道情報についてのマッチング処理を説明する。
図１４に示す例は、図１１に示した災害情報のうち、山手線で発生したドア故障が新たに災害情報ＤＢ１３に登録された際に、図１２に示した３名の顧客Ｘ、ＹおよびＺに対して当該災害情報を配信するか否かをマッチング・テーブルに基づいて決定する手順を示している。
災害情報ＤＢ１３から配信情報管理部３０に転送された災害情報は、路線−地域変換テーブルにより、その路線情報が地理的な情報に変換される。具体的には、「ＲＡＩＬＷＡＹ」の「山手線」が、路線−地域変換テーブルによって、渋谷区、目黒区…の情報に変換される。
【００２８】
顧客ＸはコースＡを選択しているので、コースＡについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。対象としている電車故障・事故の災害レベルであるＬＶは２であるから、マッチング・テーブルのＬＶ２の欄を参照することになる。マッチング・テーブルのＬＶ２の欄を参照すると、「ＣＩＴＹ」および「ＴＯＷＮ」の欄に配信を意味する○が付されている。顧客Ｘの顧客情報における「ＣＩＴＹ」は目黒区である。一方、路線−地域変換テーブルから山手線は目黒区、渋谷区…に変換されている。したがって、災害情報と顧客情報とは「ＣＩＴＹ」が一致するから、当該災害情報は顧客Ｘに配信される。図１５（ｂ）に顧客の携帯電話５３，５４に配信された情報を示す画面の一例を示す。
顧客ＹはコースＢを選択しているので、コースＢについてのマッチング・テーブルを参照する。コースＢについてのマッチング・テーブルは、ＬＶ２の災害情報を配信しないこととしている。したがって、当該災害情報は、顧客Ｙに対して配信されない。
顧客ＺはコースＢを選択している。したがって、コースＡについてのマッチング・テーブル上で、災害情報と顧客情報とが照合される。顧客Ｚの「ＣＩＴＹ」は渋谷区であり、顧客Ｘと同様に、災害情報と顧客情報とは「ＣＩＴＹ」が一致することになるから、当該災害情報は顧客Ｚに配信される。
【００２９】
（第２の実施形態）
以上の第１の実施形態では、情報配信装置１から顧客の携帯電話５３，５４に所定の災害情報を配信する。災害情報が配信された顧客が、その時点で当該災害の発生した地域にいたとすると、当該災害に関する情報をその顧客から入手することができる。そこで、本発明では、顧客の携帯電話５３，５４に災害情報を配信するのみならず、アンケートという形で顧客から当該災害に関する情報を入手することを提案する。
図１６は、顧客から当該災害に関する情報を入手することを実現するための情報配信装置２００の構成を示すブロック図である。なお、第１の実施形態による情報配信装置１と同一の構成部分については同一の符号を付すことによりその説明を省略する。
【００３０】
情報配信装置２００は、アンケートＤＢ（データ・ベース）６０、アンケート管理部７０およびＷＥＢサイト８０を備えている。
アンケートＤＢ６０は、災害の種別に応じた種々のアンケートを格納している。配信情報管理部３０が災害情報を顧客の携帯電話５３に配信する際に、災害の種別に応じたアンケートをアンケートＤＢ６０から入手して携帯電話５３に配信する。図１８（ａ）に携帯電話５３に送信したアンケート画面の一例を示す。この例では、地震情報を顧客に対して配信した際のアンケートを示している。
アンケート管理部７０は、顧客に対して行なった災害情報のアンケートの回答を回収し、かつ解析を行なう。解析した結果は、アンケートＤＢ６０に転送して格納する。さらに、アンケート結果はＷＥＢサイト８０に掲載する。このＷＥＢサイト８０を参照することにより、災害の詳しい情報を得ることができる。
アンケートＤＢ６０に格納された情報は、自動入力アプリケーション１２を介して災害情報ＤＢ１３に格納される。そして、この情報は、新たな災害情報として、顧客への配信情報として活用することができる。
【００３１】
（第３の実施形態）
第１の実施形態では、情報配信装置１から顧客の携帯電話５３，５４に所定の災害情報を配信する。その配信システムを用いることにより、第３の実施形態では、罹災した顧客に対して見舞金の支払いを実行するシステムを提案する。
図１７は、見舞金の支払いを実行するための情報配信装置３００の構成を示すブロック図である。なお、第１の実施形態による情報配信装置１と同一の構成部分については同一の符号を付すことによりその説明を省略する。
【００３２】
情報配信装置３００は、受信メール管理部８５、顧客口座ＤＢ（データ・ベース）９０および見舞金支払い管理部１００を備えている。
情報配信装置３００の配信情報管理部３０は、例えば地震情報を配信するに際して、見舞金の支払いについての問い合わせを行なう。見舞金の支払いを問い合わせる画面の例を図１８（ｂ）に示す。顧客が現実に罹災して見舞金の支払いを依頼するときは、この問い合わせに対する返信を利用することができる。
受信メール管理部８５は、顧客の携帯電話５３からの見舞金支払いを依頼するメールを受信する。受信メール管理部８５は、見舞金支払いを依頼するメールを受信すると、依頼された顧客を特定する情報、例えばメール・アドレスを見舞金支払い管理部１００に転送する。
顧客口座ＤＢ９０は、メール・アドレス等の顧客を特定する情報と当該顧客があらかじめ登録している銀行、郵便局等の預貯金の口座とを対応して格納している。
見舞金支払い管理部１００は、メール・アドレスを受信メール管理部８５から受信すると、顧客口座ＤＢ９０に格納されている情報を入手して、当該顧客の預貯金口座を特定する。さらに、その預貯金口座が開設された金融機関１１０に対して、見舞金を振り込む。
【００３３】
以上本発明の実施の形態について説明してきたが、本発明は以上の実施形態に限定されない。例えば、配信される情報は災害に限定されず、その発生地を特定することのできる情報に普遍的に適用することができる。
【００３４】
【発明の効果】
以上説明したように、本発明によれば、顧客は、顧客地域情報あるいはさらにコース情報を登録するという簡易な手続きで、自分の欲しい情報の配信を受けることができる。
【図面の簡単な説明】
【図１】 ＤＬＣテーブルを示す図である。
【図２】 第１の実施形態による災害情報配信システムの構成概略を示すブロック図である。
【図３】 第１の実施形態による情報配信装置の具体的構成を示すためのブロック図である。
【図４】 第１の実施形態における災害情報ＤＢの内容を示す図である。
【図５】 第１の実施形態における顧客情報ＤＢの内容を示す図である。
【図６】 第１の実施形態におけるマッチング・テーブルの内容を示す図である。
【図７】 第１の実施形態における顧客情報の登録の手順を示す図である。
【図８】 第１の実施形態における顧客情報の登録の手順を示す図である。
【図９】 第１の実施形態における顧客情報の登録の手順を示す図である。
【図１０】 第１の実施形態におけるマッチング・ロジックを示す図である。
【図１１】 第１の実施形態における災害情報ＤＢの内容を示す図である。
【図１２】 第１の実施形態における顧客情報ＤＢの内容を示す図である。
【図１３】 第１の実施形態における路線−地域変換テーブルの内容を示す図である。
【図１４】 第１の実施形態におけるマッチング・ロジックを示す図である。
【図１５】 第１の実施形態において顧客の携帯電話に表示される画面の例を示す図である。
【図１６】 第２の実施形態による情報配信装置の構成を示す図である。
【図１７】 第３の実施形態による情報配信装置の構成を示す図である。
【図１８】 第２および第３の実施形態において顧客の携帯電話に表示される画面の例を示す図である。
【符号の説明】
１，２００，３００…情報配信装置、２…顧客、３…災害情報ソース、４…インターネット、１０…災害情報管理部、１１…情報入力アプリケーション、１２…自動入力アプリケーション、１３…災害情報ＤＢ、２０…顧客情報管理部、２１…顧客情報登録アプリケーション、２２…顧客情報ＤＢ、３０…配信情報管理部、４０…情報配信部、５１，５２，５３，５４…携帯電話、６０…アンケートＤＢ、７０…アンケート管理部、８０…ＷＥＢサイト、８５…受信メール管理部、９０…顧客口座ＤＢ、１００…見舞金支払い管理部
Claims (6)
- 災害情報を顧客側端末に配信する情報配信装置であって、
災害が発生した地域を特定する災害地域情報とあらかじめ設定された複数の設定災害レベルのうち当該災害が該当する実災害レベルとを、顧客に近い地域ほど細かい災害情報を提供し、顧客に遠い地域ほど大きな災害に関しての情報を提供するように、階層化された地理的な情報と災害のレベルとを関連付けかつ災害情報の発信の要否を定めたマッチング・テーブルを複数、記憶する災害情報記憶部と、
前記顧客が設定する顧客地域情報を登録する顧客情報登録部と、
前記実災害レベルと一致する前記設定災害レベルについて、前記災害地域情報と前記顧客地域情報との照合を前記災害情報記憶部に記憶された複数のマッチング・テーブルから顧客の選択に基づいて選ばれる特定のマッチング・テーブルを介して行なうことにより前記災害情報の配信可否を判断する配信情報管理部と、
前記配信情報管理部における配信可否の判断に基づき配信可とされた災害情報を前記顧客側端末に配信する情報配信部と、
を備えていることを特徴とする情報配信装置。 - 前記災害情報記憶部は、前記災害地域情報および前記実災害レベルに対応して災害の種別を記憶し、
前記配信情報管理部は前記災害の種別毎に前記配信可否を判断することを特徴とする請求項１に記載の情報配信装置。 - 前記災害情報記憶部は、前記災害地域情報および前記実災害レベルに対応してさらに災害の内容を記憶し、
前記情報配信部は、前記災害の種別、前記災害地域情報および前記災害の内容を前記災害情報として前記顧客側端末に配信することを特徴とする請求項２に記載の情報配信装置。 - 前記顧客情報登録部は前記顧客地域情報を階層化して登録し、
前記災害情報記憶部は前記災害地域情報を階層化して記憶することを特徴とする請求項１に記載の情報配信装置。 - 災害情報を顧客側端末に配信する情報配信方法であって、
災害が発生した地域を特定する災害地域情報とあらかじめ設定された複数の設定災害レベルのうち当該災害が該当する実災害レベルとを、顧客に近い地域ほど細かい災害情報を提供し、顧客に遠い地域ほど大きな災害に関しての情報を提供するように、階層化された地理的な情報と災害のレベルとを関連付けかつ災害情報の発信の要否を定めたマッチング・テーブルを複数、記憶するステップと、
前記顧客が設定する顧客地域情報を登録するステップと、
前記実災害レベルと一致する前記設定災害レベルについて、前記災害地域情報と前記顧客地域情報との照合を、複数のマッチング・テーブルから顧客の選択に基づいて選ばれる特定のマッチング・テーブルを介して行なうことにより前記災害情報の配信可否を判断するステップと、
前記配信可否の判断に基づき配信可とされた災害情報を前記顧客側端末に配信するステップと、
を備えていることを特徴とする情報配信方法。 - コンピュータに、
顧客が情報の配信を要求する根拠となる顧客地域を登録する処理（ａ）と、
災害の発生地域および災害のレベルを特定する処理（ｂ）と、
前記レベルを考慮しつつ前記顧客地域と前記発生地域との距離的な関係を比較して、顧客に近い地域ほど細かい災害情報を提供し、顧客に遠い地域ほど大きな災害に関しての情報を提供するように、階層化された地理的な情報と災害のレベルとを関連付けかつ災害情報の発信の要否を定めるものとして記憶された複数のマッチング・テーブルから、顧客の選択に基づいて選ばれる特定のマッチング・テーブルを用いて前記災害に関する情報を前記顧客に配信するか否か判断する処理（ｃ）と、
を実行するためのプログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001083891A JP3685393B2 (ja) | 2001-03-22 | 2001-03-22 | 情報配信装置、情報配信方法、およびプログラム |
| US10/102,344 US8160891B2 (en) | 2001-03-22 | 2002-03-20 | Method and system for distributing disaster information |
| US13/405,423 US8615402B2 (en) | 2001-03-22 | 2012-02-27 | Method and system for distributing disaster information |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001083891A JP3685393B2 (ja) | 2001-03-22 | 2001-03-22 | 情報配信装置、情報配信方法、およびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002288202A JP2002288202A (ja) | 2002-10-04 |
| JP3685393B2 true JP3685393B2 (ja) | 2005-08-17 |
Family
ID=18939648
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001083891A Expired - Lifetime JP3685393B2 (ja) | 2001-03-22 | 2001-03-22 | 情報配信装置、情報配信方法、およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (2) | US8160891B2 (ja) |
| JP (1) | JP3685393B2 (ja) |
Families Citing this family (60)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3685393B2 (ja) | 2001-03-22 | 2005-08-17 | 日本アイ・ビー・エム株式会社 | 情報配信装置、情報配信方法、およびプログラム |
| JP2004192283A (ja) * | 2002-12-10 | 2004-07-08 | Shindenden Network:Kk | 学校教育総合情報配信システム |
| EP1872347B1 (en) * | 2005-04-07 | 2012-05-23 | Lars Lidgren | Emergency warning service |
| JP4627719B2 (ja) * | 2005-12-16 | 2011-02-09 | 日本電信電話株式会社 | 防災情報共有システム |
| JP4740744B2 (ja) * | 2006-01-12 | 2011-08-03 | 能美防災株式会社 | 防災システム |
| US20070219812A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Subscription-based multi-person emergency shelter method |
| US20070233501A1 (en) * | 2006-03-17 | 2007-10-04 | Moore Barrett H | Subscription-based private civil security facilitation method |
| US20070239480A1 (en) * | 2006-03-30 | 2007-10-11 | Moore Barrett H | Subscription-based catastrophe-triggered medical services facilitation method |
| US20070219810A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Personal profile-based private civil security subscription method |
| US20070203727A1 (en) * | 2006-02-24 | 2007-08-30 | Moore Barrett H | Emergency supplies pre-positioning and access control method |
| US20070219813A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Purchase option-based emergency supplies provisioning method |
| JP2007233612A (ja) * | 2006-02-28 | 2007-09-13 | Sky Kk | 電子メール処理システム |
| US20100250352A1 (en) * | 2006-03-17 | 2010-09-30 | Moore Barrett H | System and Method for a Private Civil Security Loyalty Reward Program |
| US20080275308A1 (en) * | 2006-03-17 | 2008-11-06 | Moore Barrett H | Premium-Based Civilly-Catastrophic Event Threat Assessment |
| US20100312722A1 (en) * | 2006-03-17 | 2010-12-09 | Moore Barrett H | Privately Provisioned Sub-Unit-Based Survival Supplies Provisioning Method |
| US20070219914A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Document-based civilly-catastrophic event personal action guide facilitation method |
| US20070219913A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Subscription-based catastrophe-triggered rescue services facilitation method and apparatus |
| US20070233506A1 (en) * | 2006-03-17 | 2007-10-04 | Moore Barrett H | Privately Managed Entertainment and Recreation Supplies Provisioning Method |
| US20070219425A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Waste Disposal Device |
| US20080255868A1 (en) * | 2006-03-17 | 2008-10-16 | Moore Barrett H | Subscription-Based Private Civil Security Facilitation Method and Apparatus |
| US20070219431A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Method to Facilitate Providing Access to a Plurality of Private Civil Security Resources |
| US20070225994A1 (en) * | 2006-03-17 | 2007-09-27 | Moore Barrett H | Method for Providing Private Civil Security Services Bundled with Second Party Products |
| US20070215434A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Subscription Based Shuttle Method |
| US20070256564A1 (en) * | 2006-05-04 | 2007-11-08 | Moore Barrett H | Positive pressure filtration kit apparatus and method |
| US20070225995A1 (en) * | 2006-03-17 | 2007-09-27 | Moore Barrett H | Method and Security Modules for an Incident Deployment and Response System for Facilitating Access to Private Civil Security Resources |
| US20070276681A1 (en) * | 2006-03-17 | 2007-11-29 | Moore Barrett H | Method Of Providing Bearer Certificates For Private Civil Security Benefits |
| US20070219429A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Privately Provisioned Interlocking Sub-Unit-Based Survival Supplies Provisioning Method |
| US20090100772A1 (en) * | 2006-03-17 | 2009-04-23 | Moore Barrett H | Fractionally-possessed underground shelter method and apparatus |
| US20070232220A1 (en) * | 2006-03-17 | 2007-10-04 | Moore Barrett H | Private civil defense-themed broadcasting method |
| US20080195426A1 (en) * | 2006-03-17 | 2008-08-14 | Moore Barrett H | Subscription-Based Mobile Shelter Method |
| US20070219423A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Privately Provisioned Survival Supplies Content Acquisition Method |
| US20080319766A1 (en) * | 2006-03-17 | 2008-12-25 | Moore Barrett H | Subscription-based catastrophe-triggered transport services facilitation method and apparatus |
| US20070219421A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Privately Provisioned Survival Supplies Delivery Method |
| US20070219426A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Subscription-Based Private Civil Security Resource Customization Method |
| US20070219814A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Publicly-Funded Privately Facilitated Access to Survival Resources Method |
| US20070219428A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Method of providing a floating life-sustaining facility |
| US20070225993A1 (en) * | 2006-03-17 | 2007-09-27 | Moore Barrett H | Method for Civilly-Catastrophic Event-Based Transport Service and Vehicles Therefor |
| US20070219427A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Premium-Based Private Civil Security Policy Methods |
| US20070217577A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Private civil defense-themed television broadcasting method |
| US20070223658A1 (en) * | 2006-03-17 | 2007-09-27 | Moore Barrett H | Method and Apparatus to Facilitate Deployment of One or More Private Civil Security Resources |
| US20070219420A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Subscription-Based Catastrophe-Triggered Rescue Services Facilitation Method Using Wireless Location Information |
| US20070261899A1 (en) * | 2006-03-17 | 2007-11-15 | Moore Barrett H | Subscription-based pre-provisioned towable unit facilitation method |
| US20090112777A1 (en) * | 2006-03-17 | 2009-04-30 | Moore Barrett H | Method of providing variable subscription-based access to an emergency shelter |
| US20070214729A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Resource Container And Positioning Method And Apparatus |
| US20070219424A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Method To Privately Provision Survival Supplies That Include Third Party Items |
| US20070228090A1 (en) * | 2006-03-17 | 2007-10-04 | Seidel Gregory E | Method of Providing Survival Supplies Container with an Illumination Apparatus |
| US20070219422A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Privately Provisioned Survival Supplies Sub-Unit-Based Delivery Method |
| US20110030310A1 (en) * | 2006-03-17 | 2011-02-10 | Moore Barrett H | Subscription-Based Intermediate Short-Term Emergency Shelter Method |
| US20070219430A1 (en) * | 2006-03-17 | 2007-09-20 | Moore Barrett H | Electricity Providing Privately Provisioned Subscription-Based Survival Supply Unit Method And Apparatus |
| US20090321663A1 (en) * | 2006-03-17 | 2009-12-31 | Moore Barrett H | Radiation-blocking bladder apparatus and method |
| US20090125316A1 (en) * | 2006-03-17 | 2009-05-14 | Moore Barrett H | Rescue container method and apparatus |
| WO2008027981A2 (en) * | 2006-08-29 | 2008-03-06 | Moore Barrett H | Subscription-based private civil security facilitation method |
| JP2008107899A (ja) * | 2006-10-23 | 2008-05-08 | Nec Corp | 情報蓄積提供装置、情報蓄積提供方法、情報蓄積提供プログラム |
| JP2008209992A (ja) * | 2007-02-23 | 2008-09-11 | Fuji Xerox Co Ltd | 画像処理装置およびプログラム |
| JP2013089144A (ja) * | 2011-10-20 | 2013-05-13 | Nippon Telegr & Teleph Corp <Ntt> | 情報検索装置及びプログラム |
| JP6260134B2 (ja) * | 2013-08-05 | 2018-01-17 | 株式会社リコー | 画像処理装置及びプログラム |
| US10077855B2 (en) | 2015-09-22 | 2018-09-18 | Ina Acquisition Corp. | Method of lining pipe with high strength liner, high strength liner, and pipe lined with high strength liner |
| US10930132B1 (en) * | 2018-10-31 | 2021-02-23 | United Services Automobile Association (Usaa) | Disaster detection system |
| US10930125B1 (en) | 2018-10-31 | 2021-02-23 | United Services Automobile Association (Usaa) | Criminal act detection system |
| JP6881518B2 (ja) * | 2019-08-06 | 2021-06-02 | 株式会社ぐるなび | 多言語変換装置、多言語変換方法、および多言語変換プログラム |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3425276B2 (ja) * | 1995-08-11 | 2003-07-14 | 株式会社日立製作所 | 情報通知システム |
| US5990805A (en) * | 1997-02-13 | 1999-11-23 | Sony Corporation | Astronomical and meteoroligical information pager |
| JPH1153668A (ja) | 1997-07-31 | 1999-02-26 | F F C:Kk | 災害時情報システム |
| JPH11110454A (ja) * | 1997-10-07 | 1999-04-23 | Matsushita Joho System Kk | 防災情報提供装置、防災情報提供方法及びその方法を記録した記録媒体 |
| JPH11285053A (ja) * | 1998-03-27 | 1999-10-15 | Mitsubishi Electric Corp | 無線通信システム、情報検索サーバ及び移動無線通信端末 |
| JP2000148719A (ja) | 1998-11-06 | 2000-05-30 | Ntt Data Corp | 被災状況の情報収集システム及び方法 |
| US6023223A (en) * | 1999-03-18 | 2000-02-08 | Baxter, Jr.; John Francis | Early warning detection and notification network for environmental conditions |
| JP2001053906A (ja) * | 1999-08-06 | 2001-02-23 | Ddi Corp | ネットワークにおける特定地域情報の自動検索方法、センタ装置及び端末装置 |
| US6462665B1 (en) * | 2000-05-16 | 2002-10-08 | Wheelock, Inc. | Method and apparatus for sending a weather condition alert |
| US6886045B1 (en) * | 2000-08-14 | 2005-04-26 | At&T Corp. | Subscription-based priority interactive help services on the internet |
| US6654689B1 (en) * | 2000-11-06 | 2003-11-25 | Weather Central, Inc. | System and method for providing personalized storm warnings |
| WO2002069300A1 (en) * | 2001-02-22 | 2002-09-06 | Koyo Musen America, Inc. | Collecting, analyzing, consolidating, delivering and utilizing data relating to a current event |
| JP3685393B2 (ja) | 2001-03-22 | 2005-08-17 | 日本アイ・ビー・エム株式会社 | 情報配信装置、情報配信方法、およびプログラム |
-
2001
- 2001-03-22 JP JP2001083891A patent/JP3685393B2/ja not_active Expired - Lifetime
-
2002
- 2002-03-20 US US10/102,344 patent/US8160891B2/en not_active Expired - Fee Related
-
2012
- 2012-02-27 US US13/405,423 patent/US8615402B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020138298A1 (en) | 2002-09-26 |
| US8615402B2 (en) | 2013-12-24 |
| US20120158418A1 (en) | 2012-06-21 |
| US8160891B2 (en) | 2012-04-17 |
| JP2002288202A (ja) | 2002-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3685393B2 (ja) | 情報配信装置、情報配信方法、およびプログラム | |
| CN109691044A (zh) | 基于物理地址生成唯一的电子通信账户 | |
| US20060265350A1 (en) | Computerized national online parcel-level map data portal | |
| US20020035432A1 (en) | Method and system for spatially indexing land | |
| CN107315762A (zh) | 服务网点匹配方法和系统 | |
| WO2014084438A1 (ko) | 온라인을 통한 식품안전 관리 시스템 및 방법 | |
| CN107615328A (zh) | 风险信息传输装置及风险信息传输方法 | |
| CN102637358A (zh) | 立足市民满意度的公共自行车服务系统及调度配送方法 | |
| Boslett et al. | Shale gas transmission and housing prices | |
| US7729997B2 (en) | Determination of an entity's assets associated with an event | |
| JP2007079945A (ja) | 地域指定による情報配信システム | |
| CN104933581A (zh) | 市场主体监管方法和系统 | |
| CN102880943A (zh) | 校车运营管理方法及系统 | |
| US20040068520A1 (en) | Information management system | |
| AU2019101193A4 (en) | LAND USE INDICATORS FOR REAL ESTATE MARKET Residential and Commercial Real Estate Market Data-Driven Decision-Making | |
| KR20220110349A (ko) | 부동산 물건의 유형별 입지 및 상권 분석 서비스 제공 시스템 | |
| JP3302986B1 (ja) | 情報管理システム | |
| JP2003233646A (ja) | 書類データ連携方法、書類データ連携プログラム、書類データ連携装置、および記録媒体 | |
| JP2002149788A (ja) | インターネットを利用した登記簿情報の収集・配信方法 | |
| JP6703220B2 (ja) | 法人情報提供装置、および方法、ならびにシステム | |
| KR101404103B1 (ko) | 앱입찰용 클라우드 어플리케이션 모듈을 통한 스마트폰 상에서의 실시간 입찰분석정보 제공장치 및 방법 | |
| JP7333548B2 (ja) | ごみの収集運搬管理システム | |
| JP2002203026A (ja) | 不動産情報管理支援システムおよびその方法 | |
| Imgrüth et al. | Collection, Standardization and Attribution of Robust Disaster Event Information—A Demonstrator of a National Event-Based Loss and Damage Database in Austria | |
| Zonato et al. | Very-high-resolution simulations with Harmonie-AROME of a heatwave case for the city of Pari with different landuse datasets. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040921 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041118 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041214 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050308 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050425 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050524 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050526 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3685393 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080610 Year of fee payment: 3 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110610 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110610 Year of fee payment: 6 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140610 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |