JP5593041B2 - 緊急通報方法とシステム - Google Patents

Description

本発明は、地震などの緊急事態発生時に緊急通報を確実且つリアルタイムに発信でき且つ配信可能状態が常時確立されている緊急通報方法に関し、受信端末機の設置が簡単であって誰でも容易に使用できる緊急通報システムに関する。

緊急通報の例としては、緊急地震速報が最も一般的である。この緊急地震速報とは、比較的早く到達する弱い縦波であるＰ波（プライマリ波）の観測によって地震の発生をいち早く捉え、地震の主要動である横波のＳ波（セカンダリ波）が到達する前にＳ波到達地域の住民に通報することにより、Ｓ波による物的、人的被害を最小限に抑制しようとする試みである。緊急地震速報の技術は、常時観測によってＰ波を捕捉し、その諸特性を分析することによって地震の規模や震源地を特定できる。緊急地震速報の技術は、気象庁が有する多機能型地震計などによる地震観測網の情報に基づいて、地震規模や震源地を特定する震源決定システムを構築している。

緊急地震速報は、防災活動を実施するうえで重要であり、ホームセキュリティなどのシステムや情報家電と連動させることにより、低コスト化を図って広く普及することが期待されている。近年開発された地震情報の応用方法において、例えば、特許文献１〜４では、緊急地震速報を受信する携帯電話のような携帯端末を含む装置やシステムを提案し、さらに特許文献５は、気象庁などの緊急地震速報の配信機関、データ所有者、情報加工・提供者、ネットワーク・放送運営者、各種防災対応システム管理者を包含するプラットフォームを構築している。

前記の応用方法では、インターネット回線網や専用回線網を利用してサーバから緊急地震速報のデータを配信するけれども、速報配信先が数千件のオーダーに達した場合、伝送レベルがＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）形式のような通常のコネクション型プロトコル形式によってプッシュ通信すると、配信先において送信データに数秒間のタイムラグが生じ、一部の配信先では緊急地震速報を緊急に受信できない事態が発生する。また、これらの応用方法は、緊急地震速報を携帯端末機などに発信するので便利であっても、中程度以上の地震発生という実際に利用される場合が年に１回もないような使用態様であるため、地震通報システムが実際に作動していることを常に確認していないと、実際に地震が発生した際にシステムが作動せずに配信できないことが起こりかねない。

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

プッシュ通信におけるデータ配信のタイムラグを減らすには、伝送レベルがＵＤＰ／ＩＰ（User Datagram Protocol/Internet Protocol）形式のようなコネクションレス型プロトコル形式によって配信すると、伝送時間がより高速で好ましいけれども、配信中にあるパケットが消失しても再送信されず、全ての端末機に確実にデータ配信されることが保証されない。このような不確実な通信手順は、確実な送信が強く要求される緊急地震速報の配信に利用することはできない。特許文献６は、コネクションレス型プロトコル形式による不確実な通信手順を補うために、ＴＣＰ／ＩＰ形式で確実に通信するサーバと、ＵＤＰ／ＩＰ形式で高速に通信するサーバとの２台のサーバで緊急通報システムを構成する。特許文献６では、配信先に対して高速なＵＤＰ／ＩＰ形式で高速に送信し、配信先からの応答は確実なＴＣＰ／ＩＰ形式で通信することにより、確実で高速な通信手順を確立する。

特許文献６では、多数の配信先からの応答を低速のＴＣＰ／ＩＰ形式で送信するので、例えば２００６年に発生した伊豆半島・伊東−川奈沖での群発地震のように同一地域において地震が短時間に頻発した場合に、後発の地震の緊急速報が遅延していくことがあり、緊急通報システムの作動を常時確認していないので、該システムが実際に地震が発生した際に配信できないことも起こりうる。特許文献６において、緊急通報システムの配信サーバは、ＴＣＰ／ＩＰ形式の通信サーバと、ＵＤＰ／ＩＰ形式の通信サーバとの少なくとも２台のサーバを必要とするため、この緊急通報システムは比較的高価なシステムになってしまう。また、特許文献６の緊急通報システムにおいて、ハッカーが愉快犯的な目的などで偽の地震データを通信回線網へ発信すれば、個々の地震警報装置では偽の地震データをそのまま受信して地震警報を発令してしまい、偽情報で社会に混乱を招くことになる。

本発明は、従来の緊急地震システムなどに関する前記の問題を改善して緊急情報を確実に配信するために提案されたものであり、センターサーバからの速報データおよび各受信端末機からの応答信号（Ａｃｋ信号）をともに実質的にコネクションレス型プロトコル形式で送信することにより、速報配信先が数千件以上のオーダーでも緊急情報が短時間で完了する緊急通報方法およびシステムを提供することを目的としている。本発明の他の目的は、コネクションレス型プロトコル形式で速報データを高速送信しても該速報データの変更や消失が起こらず、且つ配信可能状態を常時確立している緊急通報方法およびシステムを提供することである。

本発明の別の目的は、受信端末機が記憶する受信認証コードと速報データに含まれる認証確認データとが一致すれば、この速報データを受信端末機が受信することにより、受信端末機が偽の速報データの受信を排除できる緊急通報方法を提供することである。本発明の別の目的は、センターサーバから一定時間ごとに送信する死活確認信号を発信することにより、システムが配信可能状態であることを常時確認でき、且つ受信端末機の時間も正確に調整できる緊急通報方法を提供することである。本発明の別の目的は、受信端末機のグローバルＩＰアドレスが動的であっても、センターサーバは該受信端末機のＩＰアドレスを常に正確に認識できる緊急通報方法を提供することである。本発明のさらに別の目的は、センターサーバを少なくとも受信サーバおよび演算配信サーバの組で構成し、該演算配信サーバで高速演算が可能であることにより、受信端末機の負担を軽減する緊急通報システムを提供することである。

本発明に係る緊急通報方法は、通信回線網を介してセンターサーバから複数台の受信端末機へ緊急情報をリアルタイムに配信する。この緊急通報方法は、センターサーバから各受信端末機へコネクションレス型プロトコル形式の死活確認信号を定時的に配信し、この死活確認信号に対して受信端末機がセンターサーバへ端末管理番号付き応答信号を返信することにより、センターサーバが応答信号を返信した受信端末機をそのＩＰヘッド部から確定し、応答信号を返信しなかった受信端末機について同じ死活確認信号を再送信することで配信可能状態を常時確立している。緊急事態発生時にはセンターサーバが緊急速報を受信して、コネクションレス型プロトコル形式の速報データを各受信端末機へ配信し、この速報データに対して受信端末機がセンターサーバへコネクションレス型プロトコル形式の応答信号を返信することにより、センターサーバは応答信号を返信した受信端末機をそのＩＰヘッド部から確定し、応答信号を返信しなかった受信端末機について同じ速報データを再送信することで緊急情報を確実に通報する。

本発明に係る他の緊急通報方法では、各受信端末機からセンターサーバへコネクションレス型プロトコル形式の端末管理番号付きＤＤＮＳ（Dynamic Domain Name System）データを定時的に送信し、このＤＤＮＳデータの送信に対してセンターサーバは該データのＩＰヘッド部から個々の受信端末機を確定し、センターサーバが各受信端末機へＤＤＮＳ応答信号を返信している。緊急事態発生時にはセンターサーバが緊急速報を受信して、コネクションレス型プロトコル形式の速報データを各受信端末機へ配信し、この速報データに対して受信端末機がセンターサーバへコネクションレス型プロトコル形式の応答信号を返信することにより、センターサーバは応答信号を返信した受信端末機をそのＩＰヘッド部から確定し、応答信号を返信しなかった受信端末機について同じ速報データを再送信することで緊急情報を確実に通報する。

本発明に係る緊急通報方法において、センターサーバから各受信端末機へ受信認証コード付きのＤＤＮＳ応答信号または死活確認信号を送信し、この受信認証コードを受信端末機は複数個記憶し、センターサーバが緊急速報を受信すると、ヘッダ部および認証確認データを含むデータ長を１パケットに収めた速報データを各受信端末機へ配信し、この認証確認データが受信端末機で記憶した受信認証コードと一致すれば、受信端末機がこの速報データを受信すると好ましい。特に、緊急事態発生時に配信する速報データに含まれる認証確認データが、受信端末機に記憶された過去２〜５世代の受信認証コードのいずれかと一致したならば、その緊急通報信号が正しいものと認定して各受信端末機が速報データを受信する。また、センターサーバは、同じ死活確認信号を複数回送信しても受信端末機から応答信号の返信がなかった場合には、該受信端末機への配信断絶数をカウントして配信状態に復帰し、一方、受信端末機は、センターサーバから同じ緊急速報である速報データが複数回送信されても応答信号を返信しなかった場合には、速報データの送信を中止して待機状態に復帰すると好ましい。

本発明に係る緊急通報方法において、センターサーバから各受信端末機へコネクションレス型プロトコル形式の時報信号を定時に配信し、この時報信号に対して受信端末機がセンターサーバへ応答信号を返信し、各受信端末機は時報信号の時報データを受信することで時間調整が可能である。典型的には、緊急情報は緊急地震情報であり、この緊急地震情報は、気象庁および気象業務支援センターから随時配信される緊急地震速報に基づいて作成される。また、受信端末機は、一定時間ごとに、ルータに対してポートの割り当てを要求してポート番号が更新され、ポート割り当てが拒否された場合には、その拒否と同時または一定時間ごとにＵＰｎＰ（Universal Plug and Play）動作で取得したプライベートアドレスおよびポート番号をリセットし、プライベートアドレスおよびポート番号の再設定を要求するように動作すると好ましい。

本発明に係る緊急通報システムでは、通信回線網を介して緊急情報をリアルタイムに送信するセンターサーバと、該センターサーバに通信回線網を介して接続された複数台のルータと、該ルータに接続される少なくとも１台の受信端末機とで構成する。このセンターサーバは、地震認証データを一定時間ごとに作成し且つ緊急速報を受信する受信サーバと、各受信端末機の設置場所における速報地震の震度および配信順位などを高速演算する演算配信サーバとを含む。緊急事態発生時には、演算配信サーバにおいて緊急速報からヘッダを含むデータ長を１パケットに収めた速報データを作成し、この速報データをコネクションレス型プロトコル形式で各受信端末機へ配信し、該速報データに対して受信端末機がセンターサーバへコネクションレス型プロトコル形式の応答信号を返信することにより、センターサーバは応答信号を返信した受信端末機をそのＩＰヘッド部から確定する。

本発明の緊急通報システムにおいて、センターサーバはＤＤＮＳサーバを含み、該ＤＤＮＳサーバにおいて全受信端末機のグローバルＩＰアドレスを記録して、各受信端末機の装置ＩＤとグローバルＩＰアドレスおよびポート番号の対応付けを行い、ＤＤＮＳサーバから演算配信サーバにグローバルＩＰアドレスの更新を連絡すると好ましい。また、受信端末機にはコールボタンなどが無線接続され、該受信端末機がコールボタンなどからの信号を受信すると、センターサーバに登録され通信回線網を介して接続された携帯電話機などに、該センターサーバから速報データやコールボタン信号などがメール配信されると好ましい。

本発明に係る緊急通報方法は、センターサーバからの速報データをコネクションレス型プロトコル形式で送信し、この速報データの受信を認める各受信端末機からの応答信号をコネクションレス型プロトコル形式またはこれと類似の形式で発信する。本発明の緊急通報方法は、速報配信先が数千件から数万件であっても、緊急地震通報１つがほんの数秒間で完了し、群発地震があっても後発の地震通報が遅延することは発生しない。本発明の緊急通報方法は、速報データをコネクションレス型プロトコル形式で送信する際に、該速報データの変更や消失が起こりうることを回避するために、この速報データはヘッダを含むデータ長を１パケット例えば１００バイト以内に収めるようにプログラム設計する。

本発明に係る緊急通報方法では、受信端末機が一定時間ごとに受信するＤＤＮＳ応答信号または死活確認信号に含まれる受信認証コードを記憶しており、緊急地震通報の速報データが送信された際に、該速報データに含まれる認証確認データを前記の受信認証コードと比較する。この結果、この認証確認データが前記の受信認証コードと一致すると受信端末機はこの速報データを受信し、両者が不一致であれば受信端末機はこの速報データの受信を拒否する。この結果として、仮にハッカーなどが偽の速報データを通信回線網へ発信しても、個々の受信端末機においてその偽の速報データの受信を拒否するから、虚偽の地震警報が発令されることがなく、偽情報による社会の混乱を未然に防止できる。

本発明に係る緊急通報方法は、センターサーバから一定時間ごとに送信する死活確認信号を発信することにより、緊急通報システムが配信可能状態であることを常時確認している。例えば、震度３のような中程度以上の地震発生という実際に利用される場合が年に１回もないような使用態様において、個別の配信先が定時的に死活確認信号を受信することにより、実際に地震が発生した際に緊急通報システムが作動しないという事態を未然に防止する。

本発明に係る緊急通報方法において、受信端末機は、一定時間ごとにポート番号が更新され、さらにＵＰｎＰ動作で取得したプライベートアドレスおよびポート番号が随時にリセットされ、プライベートアドレスおよびポート番号を再設定することにより、該受信端末機が常時接続において作動不能になることを回避する。また、センターサーバは、ＤＤＮＳ応答信号を返信することによってグローバルＩＰアドレスの更新を定期的に受信端末機に連絡する。したがって、各受信端末機は、そのグローバルＩＰアドレスが比較的高価な固定アドレスでなく、比較的安価な静的アドレスであっても緊急通報を確実に受信することが可能である。

本発明に係る緊急通報システムは、センターサーバを少なくとも受信サーバおよび演算配信サーバの組で構成し、さらにＤＤＮＳサーバを含んでおり、該演算配信サーバは高性能で高速演算が可能である。この緊急通報システムでは、演算配信サーバにおいて高速演算することにより、各受信端末機では演算せずに負荷分散することなく、受信端末機の負担を軽減することで低価格のものが使用でき、システム全体としても安価になる。この緊急通報システムは、システムの演算式が改良される際に、各受信端末機の交換またはその演算プログラムを変更する必要がなく、センターサーバだけで改良が完了するので、システム改良を迅速に実施できる。

本発明に係る緊急通報システムにおけるシステム構成の一例を示す説明図である。 センターサーバのユーザ情報データベースを示すテーブルである。 地震情報演算部から送信される緊急地震情報のデータ内容を例示する図である。 センターサーバから各受信端末機へ配信する速報データのデータ構成を示すデータフレーム図である。 図３の緊急地震情報に関する震源位置を示す地図である。 センターサーバの配信順位の一例を示す説明図である。 受信端末機などにおける地震情報の画面表示例を示す図である。 受信端末機における地震警報の一例を示す図である。 センターサーバと受信端末機との間の通報シーケンスを概略的に示す説明図である。 受信端末機におけるＵＰｎＰ動作を概略で示すフローチャートである。 センターサーバの処理動作を概略で示すフローチャートである。

本発明に係る緊急通報システムは、以下で説明する気象庁からの緊急地震速報のほかに、武力攻撃等における国民保護のための情報伝達に関して、官邸（対策本部）から内閣府が配信する中央防災無線に適用できる。また、比較的小規模なシステムについて、消防庁が配信する消防防災無線にも適用可能である。

本発明を図面によって具体的に説明すると、本発明に係る緊急通報システムは、一例として、通信回線網３を介してセンターサーバ１を個別配信先５と接続するために、ルータ７を個別配信先ごとに取り付け、該ルータに少なくとも１台の受信端末機８をＬＡＮ接続する。図１において、通信回線網３は、通常、常時接続型のインターネット回線であり、仮想閉域網、光通信網またはデジタル通信網のような専用通信回線網を用いてもよい。通信回線網３は、具体的には、光アクセスネットワークやＩＰ−ＶＰＮ（Vertual Private Network）などであり、専用回線１８と同一または異なる回線網である。

この緊急通報システムにおいて、地震情報演算部２は、気象庁および気象業務支援センターに存在し、地震発生の検知、地震の規模・位置・発生時刻の推定および結果を「緊急地震速報」として随時配信する。この緊急地震速報は、専用回線１８を経由して高度利用者のデータセンターに送られる。このデータセンターには、停電、地震などの自然災害にも耐えうるセンターサーバ１を設置し、該サーバを年中無休体制で管理しているので、緊急地震速報の受信時に遅延なく正確に配信することが可能である。

センターサーバ１は、図１において、基本的に受信サーバ１２、演算配信サーバ１４およびＤＤＮＳサーバ１６とからなり、基本的な構成で一致するならば、演算配信サーバ１４を演算サーバと配信サーバに分離したり、管理サーバや専用データサーバを別個に設置してもよく、ＤＤＮＳサーバ１６を基本構成外に配置することも可能である。また、センターサーバ１には、ユーザ情報データベース１７（図２）用のサーバを設置したり、このユーザ情報データベース１７をサーバ１２または１４あるいは両者に分散させて構築してもよい。

この緊急通報システムは、高速処理の演算配信サーバ１４を用いたセンターサーバ演算方式であり、通常、受信端末機８では予報演算を行わない。受信端末機８で予報演算を行うと、負荷分散が可能であるけれども、システムの演算式が改良された際に、各受信端末機を交換したり、各受信端末機の演算プログラムを変更する必要があり、変更情報を各受信端末機へ配信する作業が発生して緊急地震情報の配信が遅延することが起こりうる。一方、センターサーバ１での演算方式であると、演算式が改良された場合に、高速演算のサーバの演算式を改良すれば、全ての受信端末機への改良が完了するので、システム改良を迅速に実施できる。また、受信端末機８が必要とする変更データのみに限定して配信するので、変更データ配信による遅延をきわめて小さくできる。

この緊急通報システムにおいて、受信端末機８は、ＣＰＵおよびメモリなどを備えるけれども、予報演算を行わないので比較的低速処理のものであり、１パケットが１００バイトである。ルータ７は、通常、市販品であり、個別配信先５の規模に応じて機種を選定すればよく、受信端末機８として市販のパソコンを用いることも可能である。受信端末機８は、ルータ７によってＩＰアドレス（プライベートアドレス）が動的に割り当てられ、このＩＰアドレスはその装置ＩＤおよびポート番号とともにＤＤＮＳサーバ１６に動的に登録される。ＤＤＮＳサーバ１６は、常時接続の通信回線網３において動的に割り当てられたグローバルＩＰアドレスを変更のつど登録することで更新する。

本発明の緊急通報方法において、各受信端末機８からのＤＤＮＳデータおよび応答信号、センターサーバ１からのＤＤＮＳ応答信号、死活確認信号および速報データ（例えば、地震データ）は、いずれもコネクションレス型プロトコル形式で送信し、この形式は通常はＵＤＰ／ＩＰ形式である。ＵＤＰ方式は、ＴＣＰ方式のようなコネクション型プロトコル形式と比べて、送信側と受信側との間で仮想的な通信回線を確立することがないので転送速度が速く、個別配信先５が数千件で１秒以内に、数万件になっても数秒以内に一斉配信することが可能である。この反面、ＵＤＰ方式は、ＴＣＰ方式と比べて信頼性が低く、複数のパケットを送った場合にその順序が入れ替わったり、一部のパケットが消失するという問題が発生しやすい。本発明の緊急通報方法では、ＵＤＰ方式の欠点を回避するために、速報データおよび死活確認信号の送信に対して、受信端末機８が応答信号を返信することにより、センターサーバ１が各受信端末機８のデータ受信を確認するとともに、すべての送受信データを１パケット以内に納めている。

ＵＤＰ方式のデータ形態について図４を参照すると、そのデータフレームはヘッダとデータ域からなり、該ヘッダはイーサネット（登録商標）ヘッダ部６４、ＩＰヘッダ部６６、ＵＤＰヘッダ部６８からなり、これはどのＵＤＰ方式のデータでも同じである。イーサネットヘッダ部６４を除いた部分がアプリケーションに読み込まれ、センターサーバ１は、ＩＰヘッダ部６６内の発信元ＩＰアドレスと宛先ＩＰアドレスから発信元の受信端末機８のグローバルＩＰアドレスを認識し、ＵＤＰヘッダ部６８内の発信元ポート番号と宛先ポート番号から受信端末機８のポート番号を認識できる。また、データ域はデータヘッド３９は１バイトであり、これによって送受信データの種類を決定する。一般に、速報データや死活確認信号に対する受信端末機８からの応答信号は、データヘッド３９だけを有するＵＤＰ／ＩＰ形式であり、これによって応答時間を短縮する。

本発明の緊急通報方法において、緊急情報が地震情報ならば速報データは地震データであり、遅滞なく正確に地震データを配信できるように、センターサーバ１から受信端末機８へ定時的つまり一定時間ごと（例えば、１分間、１０分間または１日数回）に死活確認信号を発信し、この死活確認信号を受信端末機８が受信したことをセンターサーバ１が認識することにより、緊急通報システムが配信可能状態であることを常時確認している。この死活確認信号の送信は、受信端末機８のリセットなどと重なった際に、センターサーバ１からの地震データの配信にタイムラグが発生しないように、これらと送信時間をずらすように設定している。

センターサーバ１は、応答信号を待ち時間（例えば、１００ｍｓｅｃ）以内に返信しなかった受信端末機８について、同じ死活確認信号を複数回再送信することで配信可能状態を常時確立し、または同じ地震データを再送信することで地震情報の確実且つ継続的な通報を達成する。しかしながら、センターサーバ１は、同じ死活確認信号を複数回送信しても受信端末機８が応答信号を返信しなかった場合には、例えば、センターサーバ１は配信不成功を記憶し、端末機管理者などにメールで警告したり、受信端末機８に警告表示や警報報知などを行ってから配信可能状態に復帰させる（図１１参照）。一方、同じ緊急地震速報である地震データを複数回送信しても受信端末機８が応答信号を返信しなかった場合には、例えば、センターサーバ１など配信停止を記録してから配信可能状態に復帰する（図１１参照）。これらの復帰後に応答信号を受信できたならば、通信が復活したものとみなして配信失敗の記録をクリアする。受信端末機８は、センターサーバ１からの死活確認信号やＤＤＮＳ応答信号を所定時間内に受信できなかった場合、自ら警告表示や警報報知などを行って端末機管理者に点検を促してよい。

個々の死活確認信号には、データ域において数バイトの地震認証コードを付加し、秘匿性を確保するために、該地震認証コードは乱数を付加して作成する。個々の受信端末機８は、死活確認信号を受信すると、センターサーバ１へ応答信号を返信するとともに、当該死活確認信号における地震認証コードを記憶する。この地震認証コードは、通常、過去２〜５世代に亘って受信端末機８に保存され、それ以降の世代になればメモリから抹消する。一方、センターサーバ１は、ＵＤＰ方式の応答信号を受信すると、そのヘッダから当該受信端末機８のグローバルＩＰアドレスとポート番号を認識し、該サーバに登録しているユーザ情報データベース１７（図２）から受信端末機８の装置ＩＤを特定する。

この地震認証コードは、受信端末機８からのＤＤＮＳデータの送信に対するセンターサーバ１からのＤＤＮＳ応答信号に付加してもよい（実施例２参照）。この場合には、死活確認信号には地震認証コードを付加しない。

受信端末機８からのＤＤＮＳデータの送信は、その起動とともに開始され、これは定時的（例えば、１分間、１０分間、１日に数回）に送信され、ビジネス用途では１分間隔である。これに伴うＤＤＮＳ応答信号の送信は、送信間隔が短いほどＤＤＮＳ応答信号による受信端末機８のＩＰアドレスの更新が迅速に行われるので好ましい。ＤＤＮＳデータは、個々の端末管理番号（例えば、装置ＩＤ）を付加したデータであり、このＤＤＮＳデータを受信したセンターサーバ１は、ＤＤＮＳサーバ１６が、該データにおけるヘッドのＩＰヘッダ部内の発信元グローバルＩＰアドレスと装置ＩＤとを関連づけて登録する。

センターサーバ１から配信される緊急地震速報の地震データ２２（図４参照）は、ＵＤＰ方式であるので転送速度が速く、送信時のデータ錯誤や消失を防ぐために、全体で８０バイト程度で１００バイト以下であり、ヘッダおよびデータ域を含んでも１パケットに収めている。地震データ２２のデータフレームには、図４に例示するように、データ域にデータヘッド３９、地震ＩＤ４０、発生時刻４２、予測震度階４４などが記入され、さらに少なくとも１個の認証確認コード４８〜５２を加えている。図４では３個の認証確認コード４８〜５２は、例えば、直近の死活確認信号またはＤＤＮＳ応答信号に付加された地震認証コードさらに過去数世代のおよび死活確認信号に付加された地震認証コードに対応する。地震データ２２に付加された複数個の認証確認データは、受信端末機８が記憶した過去２〜５世代の地震認証コードと比較され、その地震認証コードの少なくともいずれかと一致したならば、その地震通報が正しいものと認定し、該受信端末機は地震データ２２を受信する。

また、センターサーバ１は、所望に応じて、各受信端末機８へコネクションレス型プロトコルのＵＤＰ方式の時報信号を定時（例えば、毎日正午）に配信し、この時報信号の時報データを受信することによって受信端末機８は１日１回時間調整が可能であり、受信端末機８の使用者に回線状態が正常であることを認識させる。各受信端末機８は、所望に応じて、時報信号に対する応答信号をＵＤＰ方式で返信してもよい。この時報信号は、死活確認信号のいずれかに時報データを加えるならば、死活確認信号で代用することも可能である。

この緊急通報方法では、センターサーバ１と受信端末機８との送受信に、グローバルＩＰアドレスとして比較的高価な固定アドレスでなく、比較的安価な動的アドレスを用い、ルータ７は受信端末機８にプライベートＩＰアドレスを付与する。受信端末機８は、通常、ＵＰｎＰの手順に則って動作し、設定されたプライベートＩＰアドレスとポート番号で一定時間が経過すると、該ルータと通信状態に入る。この通信が成功すれば、ルータ７に対してポート開放を再び要求し、通信ポート番号を再設定する。受信端末機８がポート割り当ての要求を繰り返すのは、常時接続時において、ルータ７に登録したはずのポート番号が消滅または閉鎖される現象に対応するためである。

受信端末機８が、ルータ７との通信が不成功であれば、現状の設定をリセットすると同時に、ルータ７に対する初期設定を繰り返し、プライベートアドレスおよびポート番号を再設定する。受信端末機８がルータ７による設定のリセットを繰り返すのは、常時接続時において、ルータ７が勝手に再起動してプライベートＩＰアドレスが変化したり、一部のルータが連続したポート割り当て要求を拒否する現象に対応するためである。

受信端末機８は、ルータ７との１回の通信不成功で直ちにリセットされても、ルータ７との通信を数回繰り返した後にリセットされるように設定してもよい。また、受信端末機８は、一定時間（例えば、１時間、１日１回）ごとに設定がリセットされ、ルータ７によって定時的にプライベートアドレスと通信ポート番号が再設定されてもよい。この際に、受信端末機８のＵＰｎＰ動作モードは、ルータ７に応じて変更可能であり、ＵＰｎＰ動作が遅い一部のルータ７において、センターサーバ１から定時的に送信される死活確認信号の送信時刻と重複しないように時間帯をずらして実行すると好ましい。また、ルータ７に登録された通信ポート番号は、他のネットワーク機器のポート番号と干渉する場合があり、このような事態を回避するために通信ポート番号の変更が可能である。

次に、本発明を実施例に基づいて説明するが、本発明は実施例に限定されるものではない。図１は、高速処理のセンターサーバ１によって構成する緊急通報システムの一例を概略的に示す。この緊急通報システムは、気象庁および気象業務支援センターにおける地震観測網からデータを集合・演算する地震情報演算部２と、該演算部から緊急地震情報２０（図３）を継続的に受信するセンターサーバ１と、通信回線網３であるインターネット回線を介して接続する個別配信先５のルータ７と、該配信先においてルータ７にＬＡＮ接続する少なくとも１台の受信端末機８とで構成する。集合住宅では、共有設備としてルータ７を設置し、各戸別に受信端末機８を取り付けてＬＡＮ接続すればよい。

気象庁または防災・減災害情報センターに設置した地震情報演算部２とセンターサーバ１とは、通常、専用回線網１８のインターネット回線で連絡する。情報演算部２では、多機能地震計などで構成した地震観測網からの情報に基づいて震源決定を行っている。この多機能地震計は、通常、地表面に設置されるため、その設置が比較的容易であって高密度の地震観測網を構築している。この観測網からのデータは、地震情報演算部２の受配信サーバ１０に送信し、該受配信サーバにおいて、地震ＩＤおよび発生時刻を付与し、震源位置、震源深さ、地震規模などを算出して緊急地震情報２０（図３）を作成する。

センターサーバ１は、図１に例示するように、受信サーバ１２、演算配信サーバ１４およびＤＤＮＳサーバ１６とで構成し、ユーザ情報データベース１７（図２）はサーバ１２または１４あるいは両者に分散させて構築する。各サーバ１２，１４，１６は相互に接続されて、相互にデータを送受信する。ＤＤＮＳサーバ１６は、システム全体をサービス領域として、全受信端末機８のグローバルＩＰアドレスを記録して、各受信端末機の装置ＩＤおよびポート番号とグローバルＩＰアドレスの対応付けを行い、演算配信サーバ１４にグローバルＩＰアドレスの更新を連絡する。

センターサーバ１における受信サーバ１２は、専用回線網１８のインターネット回線を介して地震情報演算部２の受配信サーバ１０と接続することにより、該地震情報演算部から緊急地震情報２０を継続的に受信するとともに、ＤＤＮＳサーバ１６からの更新ＩＰ情報を受信する。受信サーバ１２では、各受信端末機８に配信する地震データ２２（図４）の秘匿性を確保するために、２バイトの地震認証コードを乱数を付加して作成し、この２バイトコードをＵＤＰ方式の死活確認信号に付加して各受信端末機８へ定時的に配信する。また、受信サーバ１２は、各受信端末機８へコネクションレス型プロトコルのＵＤＰ方式の時報信号を定時（例えば、毎日正午）に配信する。

センターサーバ１における演算配信サーバ１４は、受信サーバ１２が受信した緊急地震情報２０を演算・解析し、得た地震データ２２（図４）を通信回線網３を介してＵＤＰ方式で個別配信先５のルータ７さらに各受信端末機８に配信する。演算配信サーバ１４は、例えば、緊急地震情報２０の受信とともに、該緊急地震情報に含まれる震源位置２４（図５参照）と各配信先５ａ〜５ｅ（図６参照）の位置とから距離Ｒを計測し、この距離Ｒと地震規模２６とから各配信先５ａ〜５ｅの仮震度の演算を行っている。図６において、この仮震度が所定規模以上になる近隣の配信先５ｂ、５ｃへ地震データ２２を震度強さ順またはＳ波到達の早い順に配信し、この仮震度が所定規模未満である遠隔地の配信先５ａ、５ｄ、５ｅへは地震データ２２の配信を中止する。

演算配信サーバ１４において、特定の配信先５の予想震度２８（図７参照）は、緊急地震情報２０に含まれる地震強度である地震規模２６および震源深さ３０から、震源位置２４と配信先５の位置との間の伝播距離による距離減衰を考慮して演算・解析する。この際に、この伝播距離間の地域に固有の地盤増幅率を考慮すればよく、地盤増幅率とは、地表面近傍の地盤の状態によって地震による震動加速度が増減速される程度を表す値である。地盤増幅率を考慮する場合には、それが全国の各地域に固有の値としてあらかじめデータベース（図示しない）に保存している。さらに、この伝播距離と地震規模２６から、各配信先５の予想震度２８を算出するとともに、地震のＳ波が各配信先５に到達するまでの猶予時刻３２（図７参照）を算出する。

個別配信先５では、ルータ７および複数台の受信端末機８を設置する。受信端末機８は、個別配信先５においてルータ７とＬＡＮ接続され、該ルータを経て演算・解析済みの地震データ２２をＵＤＰ方式で受信する。受信端末機８が液晶表示部を備える場合には、地震データ２２を受信すると、図７に示すような地震情報の警告画面３４を表示する。受信端末機８は、音声合成ボード（図示しない）を備え、該音声合成ボードは音声出力トランスを経てスピーカ用出力端子と配線する。受信端末機８は、地震データ２２を受信した場合に、その出力端子から稼働信号を出力することによって、インターホン総合盤を一斉放送状態に切り替えて各住戸内の各住居インターホンと接続し、インターホン親機に緊急地震速報の音声ガイダンス信号を送信することも可能である。

受信端末機８は、地震データ２２を受信すると、図８に示すような地震警報３６を猶予時刻に応じて発声する。例えば、猶予時刻が３０秒以上であれば、電子音に次いで「地震が発生しました」と３回繰り返す。猶予時刻が１０〜３０秒になると、電子音に次いで「まもなく地震がきます」と３回繰り返す。猶予時刻が１０秒未満になると、電子音に次いで「すぐに地震が来ます」と揺れが発生するまで繰り返す。この警報は日本語に加え、英語、中国語や韓国語など多言語で対応することも可能である。

所望に応じて、受信端末機８には、図１に示すようにコールボタン３８を特小無線で接続することが可能であり、図示しないけれども、さらに火災報知器やドア開放センサなどを特小無線で接続したり、エレベータの停止センサに接続し、センターサーバ１からエレベータ制御などの制御信号を出力してもよい。受信端末機８がコールボタン３８からデータ送信命令を受信すると、センターサーバ１へ送信要求信号を送信する。送信要求信号を受けたセンターサーバ１は、あらかじめ登録した携帯電話機のメールアドレスへ登録済の電文を送信する（図９参照）。

次に、緊急通報システムの作動を図９に基づいて説明し、図９では、センターサーバ１、ルータ７および受信端末機８の通報シーケンスを概略的に示している。センターサーバ１は、Ｓ１０において起動時に初期設定を行っている。受信端末機８をルータ７にＬＡＮ接続して電源をオンにすると、Ｓ１１でＤＨＣＰ（Dynamic Host Configuration Protocol）によってネットワークパラメータの自動設定を行い、通常、Ｓ１２でルータ７が受信端末機８に対してＩＰアドレス（プライベートアドレス）とポート番号を動的に割り当て、Ｓ１３で受信端末機８はＩＰアドレスを取得する。

受信端末機８は、Ｓ１４〜Ｓ１６において、ＵＰｎＰの手順に則って動作し、ルータ７に対してポート割り当ての要求を繰り返す。図１０には、受信端末機８におけるＵＰｎＰ動作を概略で示している。図１０において、受信端末機８は、Ｓ１３でプライベートアドレスを取得した後に、Ｓ１００においてルータ７に対してポート開放を要求し、Ｓ１０１で通信ポート番号を設定する。このポート設定は、Ｓ１４で一定時間（例えば１分間）維持され、その一定時間が経過すると、Ｓ１６においてルータ７と通信状態に入る。この通信が成功すれば、ルータ７に対してポート開放を再び要求し、Ｓ１０１で通信ポート番号を再設定し、以下、一定時間ごとにこの動作を繰り返す。

受信端末機８が、Ｓ１６においてルータ７と通信できなければ、Ｓ１０２でルータ７による設定をリセットし、Ｓ１１に戻って初期設定を繰り返し、プライベートアドレスおよびポート番号を再設定する。図１０では、ルータリセットはＳ１６でルータ７との通信不成功で直ちに行われるけれども、ルータ７との通信を数回繰り返した後にリセットされるように設定してもよく、または受信端末機８が一定時間（例えば、１日１回）ごとにリセットされるように設定してもよい。

受信端末機８のＵＰｎＰ動作モードは、ルータ７に応じて変更可能である。一部のルータ７ではＵＰｎＰ動作が遅く、前記のリセットと再設定の間にタイムラグが生じることがあり、このような事態を回避するためにＵＰｎＰ動作のモード変更を設けている。つまり、この再設定の要求動作中は数秒であるが、センターサーバ１からの死活確認信号を受信できない期間が生じるので、該センターサーバから定時的に送信される死活確認信号の送信時刻と重複しないように時間帯をずらして実行すると好ましい。

受信端末機８が起動されると、Ｓ２１において該受信端末機からルータ７を経てセンターサーバ１へＵＤＰ／ＩＰ形式の端末管理番号（例えば、装置ＩＤ）付きＤＤＮＳデータを送信し、この送信に対してセンターサーバ１はＳ２２で受信端末機８へＵＤＰ／ＩＰ形式のＤＤＮＳ応答信号を返信する。このＤＤＮＳ応答信号は、データ域がデータヘッドだけのデータフレームである。

センターサーバ１におけるＤＤＮＳサーバ１６は、ＤＤＮＳデータの受信により、受信したＵＤＰのＩＰヘッド部と装置ＩＤから、各受信端末機８のグローバルＩＰアドレスおよび装置ＩＤとポート番号を関連づけて登録する。このＤＤＮＳデータは、各受信端末機８の起動後においても一定時間（例えば、１０分間）ごとに送信され、ＤＤＮＳサーバ１６でその動的ＩＰアドレスとポート番号が更新される。

センターサーバ１は、図９に示すように、Ｓ３１において死活確認信号を１０分間ごとに各受信端末機８へ一斉に配信する。この死活確認信号は、ＵＤＰ／ＩＰ形式であり、２バイトの地震認証コードを付加している。一方、個々の受信端末機８では、Ｓ３２でＵＤＰ／ＩＰ形式の死活確認信号を受信すると、Ｓ３３でセンターサーバ１へＵＤＰ／ＩＰ形式の応答信号を返信し、この応答信号をセンターサーバ１はＳ３４において受信する。この応答信号は、データ域がデータヘッドだけのデータフレームである。

センターサーバ１は、Ｓ３１で死活確認信号の一斉配信後に、Ｓ３４で各受信端末機８からの応答信号を受信し、該応答信号のＩＰヘッダ部から、この死活確認信号を受信した受信端末機８を確定する。センターサーバ１における各受信端末機８に対する処理動作を図１１においてフローチャートで示す。図１１において、応答信号を返信しなかった受信端末機８についてＳ３５で同じ死活確認信号を再送信することにより、個々の受信端末機８に対して配信可能状態を常時確立している。この配信可能状態である地震待機状態は、Ｓ３７において１０分間継続し、１０分間経過後に再び死活確認信号を配信することを繰り返す。

受信端末機８において、同じ死活確認信号が所定回数（例えば、３回）送信されても応答信号を返信しなかった場合には、Ｓ３６においてセンターサーバ１などへ配信断絶を連絡してから、復帰ライン６０を通って配信可能状態に戻る。配信断絶の連絡は、センターサーバ１から受信端末機８の使用者にメール配信したり、受信端末機８の使用者に電話連絡したり、当該受信端末機に設けた表示ＬＥＤを点灯したり警告音を出して使用者に告知してもよい。このような措置を数回行っても受信端末機８が受信不能のままである場合には、該受信端末機への配信を停止する。受信端末機８において、センターサーバ１からの死活確認信号やＤＤＮＳ応答信号を所定時間内に受信できなかった場合、自ら警告表示や警報報知などを行い端末機管理者に点検を促すことも可能である。

センターサーバ１は、地震発生時に地震情報演算部２から緊急地震情報２０を受信し、図４に示すようなＵＤＰ／ＩＰ形式の地震データ２２を作成する。地震データ２２のデータフレームは、例えば、ヘッダがイーサネットヘッダ部６４、ＩＰヘッダ部６６、ＵＤＰヘッダ部６８からなり、データ域にはデータヘッド３９、地震ＩＤ４０、発生時刻４２、受信端末機８がある配信先５の位置に応じた予測震度階４４、地震到達までの時間４６とが記入され、さらに２バイトの３個の認証確認コード４８，５０，５２を付加している。地震データ２２は、４０バイトのヘッダを加えても全体で１００バイト以下であり、そのデータフレームは１パケット内に収まっている。認証確認コード４８，５０，５２は、直近の死活確認信号に付加された地震認証コードさらに過去２世代のおよび死活確認信号に付加された地震認証コードに対応する。

センターサーバ１がＳ５１で地震データを各受信端末機８へ一斉に配信すると、受信端末機８において、地震データ２２に含まれる認証確認データ４８，５０，５２を、該受信端末機に記憶した過去３世代の地震認証コードと比較する。この結果、認証確認データ４８，５０，５２が地震認証コードの少なくともいずれかと一致したならば、その地震通報信号が正しいものと認定し、Ｓ５２において受信端末機８は地震データ２２を受信する。受信端末機８において、認証確認データ４８，５０，５２が、過去３世代の地震認証コードのいずれとも一致しないならば、偽の地震データと判定してその受信を拒否する。

センターサーバ１が地震データを各受信端末機８へ一斉に配信し、これが真正の地震データ２２であると各受信端末機８が認定してＳ５２で受信すれば、Ｓ５３でセンターサーバ１へＵＤＰ／ＩＰ形式の応答信号を返信し、この応答信号をセンターサーバ１はＳ５４において受信する。この応答信号は、データ域がデータヘッドだけのデータフレームである。応答信号がデータヘッドだけで単純であるので、緊急通報システム全体としての応答時間が早くなる。

センターサーバ１は、地震データ２２の一斉配信後に各受信端末機８からの応答信号を受信し、該応答信号のＩＰヘッダ部から、この地震データを受信した受信端末機８を確定する。図１１において、この応答信号を返信しなかった受信端末機８について同じ地震データ２２をＳ５５で再送信することにより、個々の受信端末機８に対して確実に送信する。受信端末機８について、同じ地震データ２２が所定回数（例えば、３回）送信されても応答信号を返信しなかった場合には、地震データ２２の送信を中止し、Ｓ５６においてセンターサーバ１などに配信停止を記録してから、復帰ライン６２を通って配信可能状態に戻る。

また、センターサーバ１は、Ｓ４０において、毎日正午に各受信端末機８へＵＤＰ／ＩＰ形式の時報信号を一斉に配信し、受信端末機８はＳ４２でこの時報信号の時報データを受信する。各受信端末機８は、所望に応じて、Ｓ４３で時報信号に対する応答信号をＵＤＰ／ＩＰ形式で返信し、センターサーバ１は、該応答信号のＩＰヘッダ部から、Ｓ４４においてこの時報信号を受信した受信端末機８を確定する。

受信端末機８は、図１に示すコールボタン３８を特小無線で接続している場合に、コールボタン３８が押されて受信端末機８がデータ送信命令を受信すると、Ｓ６１でセンターサーバ１へ送信要求信号をＵＤＰ方式で送信する。次に、Ｓ６２において、この送信要求信号をセンターサーバ１が受信すると、Ｓ６３においてセンターサーバ１は、あらかじめ登録した携帯電話機のメールアドレスへ登録済の電文を送信する。このメール配信は登録済の緊急連絡文から適宜選択され、これが緊急地震情報であるならば、図７に示すような地震情報の警告画面３４を携帯電話機に表示させる。

本発明の変形例では、説明を省略した部分は実施例１と実質的に同一である。各受信端末機８は、その起動時にルータ７を経てセンターサーバ１へＵＤＰ／ＩＰ形式の端末管理番号（例えば、装置ＩＤ）付きＤＤＮＳデータを送信し、この送信に対してセンターサーバ１はＳ２２で受信端末機８へＵＤＰ／ＩＰ形式のＤＤＮＳ応答信号を返信する。このＤＤＮＳデータは、各受信端末機８の起動後において定時的（たとえば、１分または１０分間）に頻繁に送信され、この送信に対してセンターサーバ１は受信端末機８へＵＤＰ／ＩＰ形式のＤＤＮＳ応答信号を返信する。このＤＤＮＳ応答信号は、データ域において２バイトの地震認証コードを付加している。

センターサーバ１におけるＤＤＮＳサーバ１６は、ＤＤＮＳデータの受信により、受信したＵＤＰのＩＰヘッド部と装置ＩＤから、各受信端末機８のグローバルＩＰアドレスおよび装置ＩＤとポート番号を関連づけて登録する。一方、受信端末機８は、ＤＤＮＳ応答信号の受信により、動的ＩＰアドレスが更新された際にこれを記憶できる。各受信端末機８は、ＤＤＮＳデータを頻繁に受信するので、ＤＤＮＳサーバ１６でその動的ＩＰアドレスが更新されると、遅滞なくＩＰアドレスを更新できる。

また、センターサーバ１は、死活確認信号を定時的（例えば、１日に数回）に各受信端末機８へ一斉に配信する。この死活確認信号は、ＵＤＰ／ＩＰ形式であり、基本的にデータ域がデータヘッドだけのデータフレームである。一方、個々の受信端末機８では、この死活確認信号を受信すると、センターサーバ１へＵＤＰ／ＩＰ形式の応答信号を返信する。この応答信号は、データ域がデータヘッドだけのデータフレームである。センターサーバ１は、死活確認信号の一斉配信後に各受信端末機８からの応答信号を受信し、該応答信号のＩＰヘッダ部から、この死活確認信号を受信した受信端末機８を確定する。

センターサーバ１が地震データを各受信端末機８へ一斉に配信すると、受信端末機８において、地震データ２２に含まれる認証確認データ４８，５０，５２（図４）を、該受信端末機に記憶した過去３世代の地震認証コードと比較する。これらの地震認証コードは、センターサーバ１が返信するＤＤＮＳ応答信号に付加されたものである。この結果、認証確認データ４８，５０，５２が地震認証コードの少なくともいずれかと一致したならば、その地震通報信号が正しいものと認定し、受信端末機８は地震データ２２を受信する。受信端末機８において、認証確認データ４８，５０，５２が、過去３世代の地震認証コードのいずれとも一致しないならば、偽の地震データと判定してその受信を拒否する。

１ センターサーバ
２ 地震情報演算部
３ 専用通信回線網
５ 個別配信先
７ ルータ
８ 受信端末機
１２ 受信サーバ
１４ 演算配信サーバ
１６ ＤＤＮＳサーバ
１７ ユーザ情報データベース
２０ 緊急地震情報
２２ 地震データ
２４ 震源位置
３４ 警告画面
３６ 地震警報

Claims (7)

1. 通信回線網を介してセンターサーバから複数台の受信端末機へ緊急情報をリアルタイムに配信する緊急通報方法であって、各受信端末機からセンターサーバへコネクションレス型プロトコル形式の端末管理番号付きＤＤＮＳデータを定時的に送信し、このＤＤＮＳデータの送信に対してセンターサーバは該データのＩＰヘッド部から個々の受信端末機を確定し、センターサーバが各受信端末機へＤＤＮＳ応答信号を返信しており、緊急事態発生時にはセンターサーバが緊急速報を受信して、コネクションレス型プロトコル形式の速報データを各受信端末機へ配信し、この速報データに対して受信端末機がセンターサーバへコネクションレス型プロトコル形式の応答信号を返信することにより、センターサーバは応答信号を返信した受信端末機をそのＩＰヘッド部から確定し、応答信号を返信しなかった受信端末機について同じ速報データを再送信することで緊急情報を確実に通報する緊急通報方法。
2. センターサーバから各受信端末機へ受信認証コード付きのＤＤＮＳ応答信号または死活確認信号を送信し、この受信認証コードを受信端末機は複数個記憶し、センターサーバが緊急速報を受信すると、ヘッダ部および認証確認データを含むデータ長を１パケットに収めた速報データを各受信端末機へ配信し、この認証確認データが受信端末機で記憶した受信認証コードと一致すれば、受信端末機がこの速報データを受信する請求項１記載の緊急通報方法。
3. 緊急事態発生時に配信する速報データに含まれる認証確認データが、受信端末機に記憶された過去２〜５世代の受信認証コードのいずれかと一致したならば、その緊急通報信号が正しいものと認定して各受信端末機が速報データを受信する請求項２記載の緊急通報方法。
4. センターサーバから各受信端末機へコネクションレス型プロトコル形式の時報信号を定時に配信し、この時報信号に対して受信端末機がセンターサーバへ応答信号を返信し、各受信端末機は時報信号の時報データを受信することで時間調整が可能であり、さらに受信端末機の使用者は回線状態が正常であることを確認できる請求項１記載の緊急通報方法。
5. 受信端末機は、一定時間ごとに、ルータに対してポートの割り当てを要求してポート番号が更新され、ポート割り当てが拒否された場合には、その拒否と同時または一定時間ごとにＵＰｎＰ動作で取得したプライベートアドレスおよびポート番号をリセットし、プライベートアドレスおよびポート番号の再設定を要求するように動作する請求項１記載の緊急通報方法。
6. 通信回線網を介して緊急情報をリアルタイムに送信するセンターサーバと、該センターサーバに通信回線網を介して接続された複数台のルータと、該ルータに接続される少なくとも１台の受信端末機とで構成し、前記センターサーバは、地震認証データを一定時間ごとに作成し且つ緊急速報を受信する受信サーバと、各受信端末機の設置場所における速報地震の震度および配信順位などを高速演算する演算配信サーバとを含み、緊急事態発生時には、演算配信サーバにおいて緊急速報からヘッダを含むデータ長を１パケットに収めた速報データを作成し、この速報データをコネクションレス型プロトコル形式で各受信端末機へ配信し、該速報データに対して受信端末機がセンターサーバへコネクションレス型プロトコル形式の応答信号を返信することにより、センターサーバは応答信号を返信した受信端末機をそのＩＰヘッド部から確定し、さらにセンターサーバはＤＤＮＳサーバを含み、該ＤＤＮＳサーバにおいて全受信端末機のグローバルＩＰアドレスを記録して、各受信端末機の装置ＩＤとグローバルＩＰアドレスおよびポート番号の対応付けを行い、ＤＤＮＳサーバから演算配信サーバにグローバルＩＰアドレスの更新を連絡する緊急通報システム。
7. 受信端末機にはコールボタンが無線接続され、該受信端末機がコールボタンからの信号を受信すると、センターサーバに登録され通信回線網を介して接続された携帯電話機に、該センターサーバから速報データやコールボタン信号がメール配信される請求項６記載の緊急通報システム。

Images