JP2006330964A

JP2006330964A - 運行遅延情報連絡方法

Info

Publication number: JP2006330964A
Application number: JP2005151934A
Authority: JP
Inventors: Harumi Takeda; 春美武田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2005-05-25
Filing date: 2005-05-25
Publication date: 2006-12-07

Abstract

【課題】交通機関に発生した事象が利用者に与える影響の程度に応じて適切な連絡先に適切な連絡をする。
【解決手段】コンピュータが、交通機関の運行遅延情報を受信するステップと、前記交通機関に関係するユーザを検索するユーザ検索ステップと、前記運行遅延情報を受信したときにその運行遅延情報の種類に応じたレベル情報を記憶する記憶手段を参照するステップと、前記運行遅延情報の種類に応じたレベル情報で指定されるレベルが所定のレベルを超えるか否かを判定するステップと、前記レベルが所定のレベルを超える場合に、前記ユーザに対して前記レベルに応じて指定されているレベル別連絡先の記憶手段を参照し、そのレベル別連絡先に前記運行遅延情報で示される情報および前記ユーザの状況を通知する第１の通知ステップと、前記レベルが所定のレベルを超えない場合に、前記ユーザに対して指定されている規定連絡先の記憶手段を参照し、その規定連絡先に前記運行遅延情報で示される情報を通知する第２の通知ステップと、を実行する。
【選択図】図１

Description

本発明は、交通機関の事故情報を処理する技術に関する。

交通機関が高度に発達し、所望の目的地へ極めて便利に移動できるようになっている。しかし、複雑に発達した交通機関に一旦事故が発生した場合、重大な影響が生じることも多い。また、現代社会では、人々は、過密スケジュールの中で忙しく生活しており、交通機関の事故の影響が大きくなりやすい。

特に、多数の人が行き交い、人間関係が希薄な現代社会では、一旦交通機関に事故等が発生した場合、その事故に巻き込まれた利用者は、独力で適切な連絡を適切な連絡先にする必要がある。

しかしながら、実際に交通機関の事故、トラブル、その他不慮の事態に巻き込まれた場合、その事態に巻き込まれた利用者は、冷静に行動することは難しく、適切な連絡をすることができない可能性が高い。

そのため、従来、交通機関に事故が発生すると、予め登録された関係者へ連絡するようなシステムが提案されている（例えば、下記特許文献１参照）。また、一旦、事故が発生すると、乗車中の利用者に打診し、依頼があれば電車事故証明を利用者の職場に発信するするシステムが提案されている（例えば、下記特許文献２参照）。
特開２００４−２３０９７８号公報特開２００２−２４５１３３号公報

しかし、上述した技術は、事故発生時、単純に所定の関係者に連絡するものであるため、必ずしも適切な連絡が適切な連絡先になされるとは限らない。すなわち、事故の被害の状況、被害の深刻度、あるいは、その事故と利用者との関わりの程度により、連絡先を変更する方が望ましい場合があるからである。

本発明の目的は、交通機関に発生した事象が利用者に与える影響の程度に応じて適切な連絡先に適切な連絡をする技術を提供することである。

本発明は前記課題を解決するために、以下の手段を採用した。すなわち、本発明は、コンピュータが、交通機関の運行遅延情報を受信するステップと、前記交通機関に関係するユーザを検索するユーザ検索ステップと、前記運行遅延情報を受信したときにその運行遅延情報の種類に応じたレベル情報を記憶する記憶手段を参照するステップと、前記運行遅延情報の種類に応じたレベル情報で指定されるレベルが所定のレベルを超えるか否かを判定するステップと、前記レベルが所定のレベルを超える場合に、前記ユーザに対して前記レベルに応じて指定されているレベル別連絡先の記憶手段を参照し、そのレベル別連絡先に前記運行遅延情報で示される情報および前記ユーザの状況を通知する第１の通知ステップと、前記レベルが所定のレベルを超えない場合に、前記ユーザに対して指定されている規定連絡先の記憶手段を参照し、その規定連絡先に前記運行遅延情報で示される情報を通知する第２の通知ステップと、を実行する運行遅延情報連絡方法である。

本発明によれば、前記運行遅延情報のレベルを判定し、そのレベルに応じた適切な連絡先に、前記運行遅延情報で示される情報、あるいはユーザの状況を通知することができる。

前記ユーザ検索ステップは、前記ユーザを登録した登録情報記憶手段からユーザを検索するステップと、前記登録されたユーザが前記運行遅延情報で通知される事象の発生地付近に位置するか否かを判定する位置判定ステップとを有するものでもよい。

このようにすれば、ユーザが、前記運行遅延情報で通知される事象の発生地付近に位置するか否かを判定するので、運行遅延情報との関わり合いの程度が大きいユーザを検知できる。

前記位置判定ステップにより前記ユーザが前記事象の発生地付近に位置すると判定されたときに、そのユーザに安否を確認する問い合わせを送信するステップをさらに実行するようにしてもよい。このようにすれば、運行遅延情報との関わり合いの程度が大きいユーザに、安否を確認することができる。

前記第１の通知ステップは、前記安否を確認する問い合わせに対して応答を取得できない場合に、前記規定連絡先の記憶手段および前記ユーザのレベル別連絡先の記憶手段を検索し、前記ユーザに関連して検索されたすべての連絡先に、そのユーザの安否確認ができないことを通知するステップを有するものでもよい。このようにすれば、ユーザの安否確認ができない状況において、可能な限りの連絡先にその旨を通知できる。

前記第２の通知ステップは、前記ユーザの予定を格納した予定記憶手段を検索し、今後の予定に関係する連絡先に前記運行遅延情報を通知するステップを有するものでもよい。このようにすれば、ユーザの予定が遅延する可能性があることをその予定に関係する関係者に通知できる。

前記ユーザ検索ステップは、前記ユーザの予定を格納した予定記憶手段を検索し、前記運行遅延情報で通知される事象の発生後に前記ユーザが前記交通機関の利用を終了する予定であるか否かを判定するステップを有するようにしてもよい。このようにすれば、その運行遅延情報が示す運行遅延の影響を受けるユーザを検知できる。

本発明によれば、交通機関に発生した事象と利用者との関わり合いの程度に応じて適切な連絡先に適切な連絡をすることができる。

以下、図１から図１２の図面を参照して本発明を実施するための最良の形態（以下、実施形態という）に係る情報システムについて説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

＜システム構成＞
図１は、本情報システムのシステム構成図である。この情報システムは、電車および駅構内のコンピュータシステムを監視する運行情報監視サーバから、電車の運行状況に係る情報を受信する。そして、この情報システムは、その受信した情報に応じて、利用者の安否を確認するとともに、利用者ごとの所定の連絡先に安否確認結果、スケジュール遅延に関する連絡の通知等のサービスを提供する。

図１のように、この情報システムは、運行情報監視サーバから情報を受信する管理サー
バ１と、管理サーバ１が利用者の安否を確認するために安否情報を送受信する通信先となる利用者端末２と、公衆データネットワーク、交換機網、インターネット、あるいは携帯電話網を介して接続される連絡先の携帯電話、連絡先端末等から構成される。

管理サーバ１（本発明のコンピュータに相当）は、ＣＰＵ、メモリ、入出力インターフェース、通信インターフェース、ハードディスク等を有するコンピュータである。コンピュータの構成は、広く知られているのでその説明を省略する。

管理サーバ１は、ハードディスクにインストールされた連絡制御プログラムを実行し、本情報システムの機能を提供する。すなわち、管理サーバ１は、運行情報監視サーバから送信された電車、バス、航空機、船舶等（以下、交通機関という）の運行情報を入手する。そして、監視サーバ１は、運行情報を解析し、利用者に影響を与える可能性のある事象を検知した場合に、その事象に応じて利用者ごとに適切な連絡先に情報を通知する。通知手段は、例えば、電子メールである。

このようなサービスを提供するため、管理サーバ１は、ハードディスク上に利用者テーブル、遅延原因テーブル、スケジュールテーブル、曜日テーブル、レベル別連絡先テーブルという各種テーブルを有している。管理サーバ１は、以上のテーブルを参照することにより運行情報監視サーバから受信した情報を解析し、各利用者への影響の程度を判定し、連絡先を決定する。

運行情報監視サーバは、例えば、公共交通機関を運行する各社が情報を提供するサーバである。運行情報監視サーバは、例えば、所定の契約を交わした事業者の管理サーバ１に情報を提供する。

また、運行情報監視サーバは、公共交通機関を運行する各社が運行状況を公開するためのサーバであってもよい。その場合には、管理サーバ１は、例えば、ＨＴＴＰ（HyperText Transfer Protocol ）等にしたがって運行情報監視サーバから情報を入手するようにすればよい。

利用者端末２は、無線通信部、ＣＰＵ、メモリ、入出力インターフェース、通信インターフェース等を有する。利用者端末２は、携帯情報端末（ＰＤＡ、Personal Digital(Data) Assistants ）、携帯電話、ＰＨＳ（Personal Handyphone System ）等である。利用
者端末２の構成も、広く知られているので、その説明を省略する。連絡先端末の構成は、利用者端末２と同様である。ただし、連絡先端末は、パーソナルコンピュータ、デジタルテレビ、または、ケーブルテレビや衛星方法のセットトップボックス等であってもよい。

＜システムの処理概要＞
図２に、本情報システムの全体の処理フローを示す。図２では、運行監視サーバ、管理サーバ１、携帯電話基地局、利用者端末２および連絡先携帯電話・連絡先端末間での情報の授受を示すフローが示されている。

交通機関に、運行遅延、事故等の事象が発生すると、運行情報監視サーバは、その事情を示す情報（以下、運行遅延情報）を管理サーバ１に配信する（Ｓ１）。運行遅延情報を受信した管理サーバ１は、その運行遅延情報を解析し、遅延原因テーブルをと照合することによって遅延レベルを確認する（Ｓ２）。

次に、管理サーバ１は、利用者ごとに現在の位置を問い合わせる（Ｓ３）。この場合、利用者の有する利用者端末２の電話番号を指定すればよい。すると、携帯電話基地局は、電話番号を基に利用者位置情報を検索する（Ｓ４）。そして、携帯電話基地局は、管理サ
ーバ１に該当する利用者位置情報を提供する。このようなコンピュータに対して監視対象の携帯電話・ＰＨＳ等の位置情報を提供するサービスは、携帯電話会社から提供されている。

次に、管理サーバ１は、遅延レベルにしたがい、レベル別の連絡先を確認する（Ｓ６）。そして、管理サーバ１は、利用者へ運行遅延情報を通知するとともに、安否状況を問い合わせる（Ｓ７）。問い合わせは、利用者端末２に対してなされる。この問い合わせに対して、利用者が回答できる状況にある場合には、安否状況を回答する（Ｓ８）。

すると、管理サーバ１は、遅延レベル、安否状況の回答の有無およびその内容を基に、所定の連絡先（連絡先携帯電話・連絡先端末）へ運行遅延情報を通知する。また、それらの連絡先に安否状況を通知する（Ｓ９）。

＜テーブルのデータ構造＞
以下、本管理サーバ１が、運行遅延情報の解析、利用者の安否確認、および連絡先確定等のために利用するテーブルのデータ構造を説明する。なお、以下では、交通機関が鉄道である場合を例にして詳細を説明する。

図３は、遅延原因テーブル（本発明のレベル情報を記憶する記憶手段に相当）の構成を示す図である。遅延原因テーブルは、遅延原因を示す文字列情報と、レベルを示す数値情報（本発明のレベル情報に相当）とを組みにして構成される。ただし、遅延原因は、文字列情報でなく、遅延原因を示すコードで示して良い。コードは、例えば、遅延原因マスタのような管理テーブルに定義すればよい。

図３の例では、レベルが１から８の８段階に分類されている。レベル１につては、例えば、大雪、大雨、強風、台風、土砂崩れの遅延原因が指定されている。また、レベル５は、地震（震度４以下）、レベル７は、地震（震度５）、レベル８は、地震（震度６以上）のように、遅延原因が深刻になるほど、大きなレベルの値に設定されている。

図４は、本情報システムを利用する利用者を定義した利用者テーブル（本発明の登録情報記憶手段に相当）の構成を示す図である。本情報システムでは、利用者テーブルは、ＩＤ、氏名、メールアドレス、緊急連絡先氏名、および緊急連絡先メールアドレスの各フィールドを有している。

ここで、ＩＤは、本情報システムにおいて各利用者を識別する識別情報である。また、メールアドレスは、各利用者に安否確認等を通知するために使用される。一方、緊急連絡（緊急連絡先氏名、緊急連絡先メールアドレス）は、深刻な運行遅延が発生した場合で、その遅延原因に応じたレベル別の連絡先が指定されていない利用者について、状況を通知する通知先である。

図５は、本情報システムにおいて、各利用者のスケジュールを管理するスケジュールテーブルの構成を示す図である。スケジュールテーブルの各行には、利用者ごとの１つのスケジュールが記録される。一人の利用者が複数のスケジュールを有する場合には、その利用者についてスケジュールテーブルの複数行が使用される。

図５のように、スケジュールテーブルは、ＩＤ、日付、乗車駅、下車駅、発車時刻、電車、連絡先氏名、および連絡先メールアドレスの各フィールドを有している。

ＩＤは、図４の利用者テーブルで説明したＩＤであり、当該スケジュールが管理される利用者である。また、日付のフィールドには、当該スケジュールが設定される日を定義す
る。例えば、日付が１，２，３，４，５とあるのは、曜日を示すコードであり、月曜：１、火曜：２、水曜：３、木曜：４、金曜：５の各日で定期的に実行されるスケジュールを意味する。なお、曜日を示すコードは曜日テーブルに定義されている。また、２００５／０２／０１とあるのは、２００５年２月１日に実施されるべきスケジュールを示す。

乗車駅は、そのスケジュールにおいて利用者が電車に乗車する乗車駅である。また、下車駅は、そのスケジュールにおいて利用者が電車に下車する降車駅である。発車時刻は、電車が乗車駅を発車する時刻である。電車は、そのスケジュールで使用される電車の路線名である。

連絡先（連絡先氏名、連絡先メールアドレス（本発明の規定連絡先に相当）は、当該スケジュールの電車に運行遅延が発生した場合に、その旨を通知する連絡先である。通常、当該スケジュールの対象となるイベントの参加者、例えば、会議の主催者、商談の相手先等が連絡先となる。スケジュールに連絡先を登録することにより、スケジュールに影響を及ぼす運行遅延が発生した場合に、情報システムがその連絡先に遅延状況を通知する。

図６は、曜日テーブルの構成を示す図である。曜日テーブルには、曜日を示すコードが定義される。

図７は、レベル別連絡先テーブル（本発明のレベル別連絡先の記憶手段に相当）の構成を示す図である。レベル別連絡先テーブルは、遅延原因のレベルごと、利用者ごとに、運行遅延の状況を連絡すべき連絡先を定義する。例えば、遅延レベルが高い場合には、すなわち、運行遅延の状況が深刻な場合には、スケジュールテーブルの連絡先や、利用者テーブルの緊急連絡先とは異なる特別の連絡先に状況を連絡したい場合がある。レベル別連絡先テーブルは、そのような特別の連絡先を定義するテーブルである。

レベル別連絡先テーブルの各行は、レベルごと、利用者ごとに異なる連絡先を格納する。すなわち、各行は、レベル、ＩＤ、連絡先氏名、および連絡先メールアドレスの各フィールドを有している。

レベルとは、図３に示した遅延原因のレベルである。また、ＩＤは、図４に示した利用者テーブルのＩＤである。連絡先（連絡先氏名、連絡先メールアドレス）は、当該遅延レベルの運行遅延が発生したときに連絡を通知することをその利用者が希望する連絡先を定義する。例えば、地震（震度６以上）に対応するレベル８の場合として、実家の両親を連絡先に定義するような運用がなされる。

＜通知情報の画面サンプル＞
図８から図１１に、本情報システムで利用者に通知される安否確認情報、あるいは、連絡先に通知されるメッセージを表示する画面サンプルを示す。

図８の例では、利用者が脱線事故（遅延原因レベル８）に巻き込まれた場合の画面内容が例示されている。この例では、まず、管理サーバ１から利用者に安否の確認メールが送信される。画面１１は、確認メールの内容を示している。この確認メールでは、利用者に対して、インターネット上の所定のウェブサイト（URLで指定）にアクセスし、確認を応
答するように利用者に依頼している。

続いて、画面１２では、利用者が、インターネット上の所定のウェブサイト（URLで指
定）にアクセスした場合の画面が例示されている。この例では、ウェブサイトは、安否を示す選択肢を明示し、利用者にいずれかの選択肢を選択して回答するように依頼している。この依頼に対して、利用者が選択肢を選択してウェブサイト（または管理サーバ１）に
応答している。

続いて、画面１３では、管理サーバ１から利用者に、所定の連絡先へ連絡が終了したことが報告されている。さらに、画面１４では、その利用者について所定の連絡先に通知されたメッセージの内容が例示されている。

図９の例では、信号機トラブル（遅延原因レベル６）の場合の画面内容が例示されている。この例では、図８と同様に、まず、管理サーバ１から電車に乗車している利用者に確認メールが送信される（画面２１）。

続いて、画面２２では、その確認メールに対する利用者の応答内容が例示されている。この例では、管理サーバ１が利用者に所定の連絡先に通知する必要があるか否かを回答するように依頼し、利用者が回答を選択して管理サーバ１に応答している
さらに、画面２３および２４では、図８の画面１３および１４と同様、管理サーバ１から利用者および所定の連絡先へのメッセージの内容が例示されている。

図１０は、乗車予定の電車で人身事故が発生した場合のメッセージの内容が例示されている。画面の構成は、図９の場合と同様である。最終的には、利用者の所定連絡先（例えば、会議の出席者等）に電車遅延速報が通知され、利用者が１５分程度遅刻することが例示されている。

図１１は、衝突事故（遅延原因レベル８）が発生し、さらに、利用者が安否確認メールに応答しない場合の画面例が例示されている。すなわち、画面４１、４２で例示される安否確認に対して、緊急連絡先へ通知したことが利用者に通知され（画面４３）、さらに、その緊急連絡先へのメッセージの内容が画面４４に例示されている。

＜処理フロー＞
図１２に、管理サーバ１が実行する事故情報解析・連絡先通知処理の処理フローを示す。この処理は、図１の連絡制御プログラムにより実行される。管理サーバ１は、運行情報管理サーバから運行遅延情報を受信したときに（本発明の受信ステップに相当）、この処理を起動する。

この処理では、管理サーバ１は、運行遅延情報の内容と、遅延原因テーブル（図３）とを対照し、遅延レベルを確認する（Ｓ２０、本発明のレベル情報を記憶する記憶手段を参照するステップに相当）。この場合、遅延原因テーブルの遅延原因が文字列で記述され、運行遅延情報の内容中に、遅延原因に相当する文字列が含まれているか否かを判定すればよい。また、遅延原因テーブルの遅延原因がコードで記述され、運行遅延情報の内容中に、遅延原因に相当するコードが含まれているか否かを判定してもよい。

次に、管理サーバ１は、利用者テーブル（図４参照）を参照し、本情報システムの利用者を検索する（本発明のユーザ検索ステップ、およびユーザを検索するステップに相当）。そして、管理サーバ１は、各利用者の利用者端末２に利用者の現在の位置情報を問い合わせる（Ｓ２１）。各利用者端末２は、管理サーバ１からの位置情報問い合わせに対して、ＧＰＳ（Global Positioning System ）により現在位置を測定して管理サーバ１に応答する。

次に、管理サーバ１は、１名以上の利用者が現場付近にいるか否かを判定する（Ｓ２２、本発明の位置判定ステップに相当）。どの利用者も現場付近にいない場合、管理サーバ１は、スケジュールテーブル（図５参照）において、各利用者のスケジュールを確認する（Ｓ２３）。そして、管理サーバ１は、当該遅延情報と関係するスケジュールがスケジュ
ールテーブルに登録されているか、否かを判定する（Ｓ２４）。関係するスケジュールが登録されていない場合、管理サーバ１は、処理を終了する。

一方、当該遅延情報と関係するスケジュールが登録されている場合、そのスケジュールで登録されて利用者（図５のＩＤで指定される利用者）に対して、連絡先に運行遅延情報を通知するか否かを確認する（Ｓ２５）。そして、管理サーバ１は、確認に対して、連絡先へ通知する旨の回答を取得できたか否かを判定する（Ｓ２６）。

連絡先へ通知する旨の回答を取得できた場合、管理サーバ１は、当該スケジュールに関係する連絡先（図５のスケジュールテーブルの連絡先氏名・連絡先メールアドレス）に運行遅延情報を通知する（Ｓ２７）。この画面例は、図１０（画面サンプル３）に例示されている。一方、連絡先へ通知する旨の回答を取得できない場合、管理サーバ１は、そのまま処理を終了する。

Ｓ２２の判定で、現場付近に利用者が１名以上いることが検出された場合、管理サーバ１は、遅延原因レベルが７以上か否かを判定する（Ｓ２８、本発明のレベルが所定のレベルを超えるか否かを判定するステップに相当）。遅延原因レベルが７未満の場合、管理サーバ１は、スケジュールテーブル（図５参照）において、現場付近にいるその利用者のスケジュールを確認する（Ｓ３０）。そして、管理サーバ１は、その利用者について、当該遅延情報と関係するスケジュールがスケジュールテーブルに登録されているか、否かを判定する（Ｓ３１）。関係するスケジュールが登録されていない場合、管理サーバ１は、処理を終了する。

一方、当該遅延情報と関係するスケジュールが登録されている場合、その利用者に対して、連絡先に運行遅延情報を通知するか否かを確認する（Ｓ３２）。そして、管理サーバ１は、確認に対して、連絡先へ通知する旨の回答を取得できたか否かを判定する（Ｓ３３）。

連絡先へ通知する旨の回答を取得できた場合、管理サーバ１は、当該スケジュールに関係する連絡先（図５のスケジュールテーブルの連絡先氏名・連絡先メールアドレス）に運行遅延情報を通知する（Ｓ３４）。この画面例は、図１０（画面サンプル３）に例示されている。一方、連絡先へ通知する旨の回答を取得できない場合、管理サーバ１は、そのまま処理を終了する。Ｓ３４が本発明の第２の通知ステップに相当する。

Ｓ２８の判定で、遅延原因レベルが７以上の場合、管理サーバ１は、さらに、遅延原因レベルが８以上か否かを判定する（Ｓ４０、本発明のレベルが所定のレベルを超えるか否かを判定するステップに相当）。遅延原因レベルが８未満の場合、管理サーバ１は、レベル別連絡先テーブル（図７）を参照する。そして、当該利用者（Ｓ２２の判定で現場付近にいることが検出された利用者）がレベル別連絡先テーブルに連絡先を登録しているか否かを判定する（Ｓ４１）。

利用者がレベル別連絡先に連絡先を登録していない場合、管理サーバ１は、スケジュールテーブルを参照する（Ｓ４３）。そして、管理サーバ１は、スケジュールテーブルに当該利用者に関係するスケジュールが登録されているか否かを判定する（Ｓ４４）。

スケジュールテーブルに当該利用者に関係するスケジュールが登録されていない場合、管理サーバ１は、利用者へ安否状況を問い合わせる（Ｓ４５）。そして、管理サーバ１は、安否状況を確認できた否かを判定する（Ｓ４６）。安否状況を確認できた場合、管理サーバ１は、レベル別連絡先またはスケジュールに関係する連絡先へ電車事故速報および安否状況を通知する（Ｓ４７）。この場合の画面サンプルは、図８に示されている。

一方、Ｓ５５の判定で安否状況が確認できない場合、管理サーバ１は、処理を終了する。遅延原因レベルが低い（この場合、８未満である）ためである。

また、Ｓ４０の判定で遅延レベルが８以上の場合、管理サーバ１は、レベル別連絡先テーブル（図７）を参照する。そして、当該利用者（Ｓ２２の判定で現場付近にいることが検出された利用者）がレベル別連絡先テーブルに連絡先を登録しているか否かを判定する（Ｓ５１）。

利用者がレベル別連絡先に連絡先を登録していない場合、管理サーバ１は、スケジュールテーブルを参照する（Ｓ５２）。そして、管理サーバ１は、スケジュールテーブルに当該利用者に関係するスケジュールが登録されているか否かを判定する（Ｓ５３）。

スケジュールテーブルに当該利用者に関係するスケジュールが登録されていない場合、管理サーバ１は、利用者へ安否状況を問い合わせる（Ｓ５４）。そして、管理サーバ１は、安否状況を確認できた否かを判定する（Ｓ５５）。安否状況を確認できた場合、管理サーバ１は、緊急連絡先へ電車事故速報および安否状況を通知する（Ｓ５６）。この場合の画面サンプルは、図８に示されている。

一方、Ｓ５５の判定で安否状況が確認できない場合、管理サーバ１は、把握できているすべての連絡先へ電車事故速報および安否状況取得不能の旨を通知する（Ｓ５９）。

また、Ｓ５１の判定で、当該利用者がレベル別連絡先テーブルに連絡先を登録している場合も、利用者に安否状況を問い合わせる（Ｓ５７）。また、Ｓ５３の判定で、当該利用者に関係するスケジュールがスケジュールテーブルに登録されている場合も、利用者に安否状況を問い合わせる（Ｓ５７）。

そして、管理サーバ１は、安否状況を確認できた否かを判定する（Ｓ５８）。安否状況を確認できた場合、管理サーバ１は、レベル別連絡先またはスケジュールに関係する連絡先（スケジュールテーブルの連絡先氏名・連絡先メールアドレス）へ電車事故速報および安否状況を通知する（Ｓ６０）。この場合の画面サンプルは、図８に示されている。

一方、Ｓ５８の判定で安否状況が確認できない場合、管理サーバ１は、把握できているすべての連絡先へ電車事故速報および安否状況取得不能の旨を通知する（Ｓ５９）。Ｓ５９およびＳ６０が本発明の第１の通知ステップに相当する。

以上述べたように、本実施形態の情報システムによれば、電車のような交通機関に遅延原因が発生した場合に、遅延原因を解析し、遅延原因をレベル分けする。そして、この情報システムは、遅延原因のレベルに応じて、必要な処置を執る。

例えば、この情報システムは、遅延原因の発生した交通機関の付近（例えば、電車の線路付近）に利用者がいたか否かを利用者端末２に問い合わせて判定する。

そして、利用者がその交通機関の付近にいない場合には、利用者のスケジュールからその交通機関の遅延が利用者に影響を与えるか否か（関係するスケジュールが登録されているか否か）を判定し、影響を与える場合に、利用者に所定の連絡先へ通知すべきか否かを問い合わせて、通知の回答を得た場合に、その連絡先に運行遅延情報を通知する。

また、本情報システムは、利用者がその交通機関の付近にいる場合には、遅延原因のレベルが所定値以上か否かを判定する。そして、本情報システムは、遅延原因のレベルが所
定値（例えば、７）未満の場合、利用者がその交通機関の付近にいない場合と同様の処理を実行する。

また、本情報システムは、利用者がその交通機関の付近にいる場合であって、遅延原因のレベルが所定値（例えば、７）以上の場合、レベル別連絡テーブルを参照する。そして、本情報システムは、レベル別連絡テーブルに登録された連絡先、または、スケジュールテーブルで指定された連絡先に、安否確認の結果を通知する。

また、本情報システムは、利用者がその交通機関の付近にいる場合で、遅延原因のレベルが所定値（例えば、８）以上の場合で、その利用者に関係するスケジュールが登録されているか、レベル別連絡先が定義されている場合で、利用者の安否状況を確認できた場合には、そのスケジュールに関係する連絡先またはレベル別連絡先に交通機関の遅延情報および安否状況を連絡する。

また、本情報システムは、利用者がその交通機関の付近にいる場合で、遅延原因のレベルが所定値（例えば、８）以上の場合で、その利用者に関係するスケジュールが登録されておらず、レベル別連絡先も定義されていない場合で、利用者の安否を確認できた場合には、その利用者の緊急連絡先に交通機関の遅延情報および安否状況を連絡する。

また、本情報システムは、利用者がその交通機関の付近にいる場合で、遅延原因のレベルが所定値（例えば、８）以上の場合で、その利用者の安否を確認できない場合には、その利用者について把握できているすべての連絡先に交通機関の遅延情報および安否状況取得不能の旨を連絡する。

このように、本情報システムによれば、交通機関の遅延原因のレベル、利用者が交通機関運行現場の付近にいるか否か、安否確認ができたか否かに応じて、適切な連絡先に状況を通知できる。

このため、利用者への影響が遅延で済むような軽微な場合には、例えば、スケジュール上関係する連絡先に遅延の旨を通知できる。一方、安否確認ができない深刻な状況にある場合、本情報システムは、その利用者に関して把握されているすべての連絡先に状況を通知する。さらに、その利用者のスケジュール上関係する連絡先およびレベル別連絡先が登録されていない場合には、本情報システムは、その利用者の緊急連絡先に状況を通知する。

＜その他＞
さらに、本実施の形態は以下の発明を開示する。また、以下の各発明（以下付記と呼ぶ）のいずれかに含まれる構成要素を他の付記の構成要素と組み合わせてもよい。
（付記１）
コンピュータが、
交通機関の運行遅延情報を受信するステップと、
前記交通機関に関係するユーザを検索するユーザ検索ステップと、
前記運行遅延情報を受信したときにその運行遅延情報の種類に応じたレベル情報を記憶する記憶手段を参照するステップと、
前記運行遅延情報の種類に応じたレベル情報で指定されるレベルが所定のレベルを超えるか否かを判定するステップと、
前記レベルが所定のレベルを超える場合に、前記ユーザに対して前記レベルに応じて指定されているレベル別連絡先の記憶手段を参照し、そのレベル別連絡先に前記運行遅延情報で示される情報および前記ユーザの状況を通知する第１の通知ステップと、
前記レベルが所定のレベルを超えない場合に、前記ユーザに対して指定されている規定
連絡先の記憶手段を参照し、その規定連絡先に前記運行遅延情報で示される情報を通知する第２の通知ステップと、を実行する運行遅延情報連絡方法。（１）
（付記２）
前記ユーザ検索ステップは、
前記ユーザを登録した登録情報記憶手段からユーザを検索するステップと、
前記登録されたユーザが前記運行遅延情報で通知される事象の発生地付近に位置するか否かを判定する位置判定ステップとを有する付記１に記載の運行遅延情報連絡方法。（２）
（付記３）
前記位置判定ステップにより前記ユーザが前記事象の発生地付近に位置すると判定されたときに、そのユーザに安否を確認する問い合わせを送信するステップをさらに実行する付記２に記載の運行遅延情報連絡方法。（３）
（付記４）
前記第１の通知ステップは、前記安否を確認する問い合わせに対して応答を取得できない場合に、前記規定連絡先の記憶手段および前記ユーザのレベル別連絡先の記憶手段を検索し、前記ユーザに関連して検索されたすべての連絡先に、そのユーザの安否確認ができないことを通知するステップを含む付記３に記載の運行遅延情報連絡方法。
（付記５）
前記第２の通知ステップは、前記ユーザの予定を格納した予定記憶手段を検索し、今後の予定に関係する連絡先に前記運行遅延情報を通知するステップを含む付記３に記載の運行遅延情報連絡方法。
（付記６）
前記ユーザ検索ステップは、前記ユーザの予定を格納した予定記憶手段を検索し、前記運行遅延情報で通知される事象の発生後に前記ユーザが前記交通機関を利用を終了する予定であるか否かを判定するステップとを有する付記１に記載の運行遅延情報連絡方法。
（付記７）
交通機関の運行遅延情報を受信する手段と、
前記交通機関に関係するユーザを検索する手段と、
前記運行遅延情報の種類に応じたレベル情報を記憶する記憶手段と、
前記運行遅延情報を受信したときに前記記憶手段から前記レベル情報を参照する手段と、
前記運行遅延情報の種類に応じたレベル情報で指定されるレベルが所定のレベルを超えるか否かを判定する手段と、
前記レベルが所定のレベルを超える場合に、前記ユーザに対して前記レベルに応じて指定されているレベル別連絡先の記憶手段を参照し、そのレベル別連絡先に前記運行遅延情報で指定される交通機関および前記ユーザの状況を通知する手段と、
前記レベルが所定のレベルを超えない場合に、前記ユーザに対して指定されている規定連絡先の記憶手段を参照し、その規定連絡先に前記運行遅延情報で指定される交通機関および前記ユーザの状況を通知する手段と、備える運行遅延情報連絡装置。

本発明の実施形態に係る情報システムのシステム構成図である。情報システムの全体の処理フローを示す図である。遅延原因テーブルの構成を示す図である。利用者テーブルの構成を示す図である。スケジュールテーブルの構成を示す図である曜日テーブルの構成を示す図である。レベル別連絡先テーブルの構成を示す図である。利用者が脱線事故（遅延原因レベル８）に巻き込まれた場合の画面内容を例示する図である。信号機トラブル（遅延原因レベル６）の場合の画面内容を例示する図である。乗車予定の電車で人身事故が発生した場合のメッセージの内容を例示する図である。衝突事故（遅延原因レベル８）が発生し、さらに、利用者が安否確認メールに応答しない場合の画面例を例示する図である。事故情報解析・連絡先通知処理の処理フローである。

符号の説明

１管理サーバ
２利用者端末

Claims

コンピュータが、
交通機関の運行遅延情報を受信するステップと、
前記交通機関に関係するユーザを検索するユーザ検索ステップと、
前記運行遅延情報を受信したときにその運行遅延情報の種類に応じたレベル情報を記憶する記憶手段を参照するステップと、
前記運行遅延情報の種類に応じたレベル情報で指定されるレベルが所定のレベルを超えるか否かを判定するステップと、
前記レベルが所定のレベルを超える場合に、前記ユーザに対して前記レベルに応じて指定されているレベル別連絡先の記憶手段を参照し、そのレベル別連絡先に前記運行遅延情報で示される情報および前記ユーザの状況を通知する第１の通知ステップと、
前記レベルが所定のレベルを超えない場合に、前記ユーザに対して指定されている規定連絡先の記憶手段を参照し、その規定連絡先に前記運行遅延情報で示される情報を通知する第２の通知ステップと、を実行する運行遅延情報連絡方法。
前記ユーザ検索ステップは、
前記ユーザを登録した登録情報記憶手段からユーザを検索するステップと、
前記登録されたユーザが前記運行遅延情報で通知される事象の発生地付近に位置するか否かを判定する位置判定ステップとを有する請求項１に記載の運行遅延情報連絡方法。
前記位置判定ステップにより前記ユーザが前記事象の発生地付近に位置すると判定されたときに、そのユーザに安否を確認する問い合わせを送信するステップをさらに実行する請求項２に記載の運行遅延情報連絡方法。