JP7828808B2 - 事故情報配信システム - Google Patents

Description

本発明は、事故情報配信システム、特に、車両と歩行者の衝突事故に関する情報を第三者に配信するシステムに関する。

近年、自動車にはドライブレコーダが搭載されることが多く、自動車の衝突事故等の際にドライブレコーダの映像等から事故の状況を解析することも可能となっている。また、将来的に自動運転が実現するようになる際には、自動運転車両やＡＤＡＳ（先進運転支援システム）搭載車には、ＥＤＲ（イベントデータレコーダ）が標準搭載される見通しであり、事故前後の自車の運転についての挙動が記録され、事故状況を自車側の視点から解析することができる。

このため、自動車同士の衝突事故の場合、各々の車両でデータが記録され、衝突車両の両者の視点から事故を解析することができる。これに対して、自動車と自転車や歩行者との衝突事故においては、自転車や歩行者側が、事故状況を解析するための記録装置等を保有する可能性は低く、事故状況は自動車側の記録データにより一方的に解析されることになり、自転車や歩行者が事故の責任において不利に扱われる可能性も生ずる。また、逆に、自転車や歩行者の暴走や飛び出しなどの原因による事故で、自動車側の責任が小さい場合に、それを証明する手段が限られるという課題があった。自転車や歩行者側の記録データを配信することができず、その救護に必要なデータの配信をすることができないという課題も生じていた。

特許文献１には、車両に搭載されるモバイルデバイス（車両端末）と歩行者が携帯するデバイス（スマホ）の間で通信を行い、衝突の可能性を判断して、車両の運転者と歩行者の少なくとも一方に警報を発するシステムの発明が記載されている。しかしながら、特許文献１の発明は、衝突事故前にデータを送信し、事故を回避しようとするものであって、事故に事故についてのデータを配信するものではない。

特開２０１５－３２３１２号公報

自動車と自転車や歩行者との衝突事故において、事故前後の自転車や歩行者の挙動を記録し、車両側の記録データと合わせて配信することにより、事故解析や責任の証明に役立て、また、両者を同時にいち早く救急サポートセンター等に配信して負傷者の救護に役立てるという技術はこれまでに開発されていない。

本発明は、上記の実状に鑑み、自転車や歩行者の挙動を記録し、車両との衝突事故時に事故前後の自転車や歩行者の挙動を記録し、車両側の記録データと合わせていち早く配信することを目的とする。

上記課題を解決するために、本発明の事故情報配信システムは、歩行者と車両の衝突事故の発生時に、歩行者の保持する携帯端末で取得した情報及び車両に備えられた車両端末で取得した情報を他の第三者に配信する事故情報配信システムであって、前記携帯端末は、衝突事故の情報を取得する歩行者側事故情報取得部と、前記歩行者側事故情報取得部で取得した歩行者側事故情報を前記車両端末へ送信する歩行者側事故情報送信部と、を備え、前記車両端末は、衝突事故の情報を取得する車両側事故情報取得部と、前記携帯端末の前記歩行者側事故情報送信部から送信された歩行者側事故情報を受信する歩行者側事故情報受信部と、前記車両側事故情報取得部で取得した車両側事故情報と前記歩行者側事故情報を関連付ける歩車情報関連付け処理部と、前記歩車情報関連付け処理部で関連付けられた歩車情報を他の第三者へ送信する歩車情報送信部とを備える事故情報配信システムである。

上記の本発明の構成により、車両側で記録した事故前後の情報に加えて、歩行者側で記録した事故前後の情報も第三者へ配信されることにより、配信された情報は、車両側及び歩行者側の双方の視点からの事故の解析・事故の責任の証明が可能となるとともに、事故のよる負傷者の救護にも役立てることができるという効果を奏する。

本発明は、また、歩行者側事故情報取得部は、携帯端末の自己位置を検出する自己位置検出部と、携帯端末を保持する歩行者に衝突が生じたことを検知する衝突検知部と、を備える。この構成により、歩行者が事故に遭遇した地点を配信することができることによって、歩行者の救護をいち早くすることができるとともに、歩行者側の衝突検知により、歩行者側の視点に基づく事故の記録を配信することができる。

また、本発明では、車両側で記録した事故前後の情報及び歩行者側で記録した事故前後の情報が配信される他の第三者は情報配信サーバであり、前記情報配信サーバは、救急サポートセンターに接続される。この構成により、本発明の事故情報配信システムを、車両側及び歩行者側の負傷者をいち早く救護することに役立てることができる。

また、本発明では、救急サポートセンターは、周囲情報端末に救護要請を行い、歩行者の携帯端末は、救急サポートセンターから自己位置近傍での衝突事故発生情報を受信する。この構成により、本発明の事故情報配信システムを、車両側及び歩行者側の負傷者をさらに早く救護することに役立てることができる。

また、本発明では、車両側事故情報取得部は、車両端末の自己位置を検出する自己位置検出部と、車両端末を備える車両に衝突が生じる可能性を算出する衝突可能性算出部と、車両端末を備える車両に衝突が生じたことを検知する衝突検知部と、を備える。車両側端末において、自己位置検出部、衝突検知部に加えて、衝突可能性算出部を設けて、ドライバーに衝突の可能性が生じた状況について学習させることにより、今後の事故を未然に防ぐことに帰することができる。

また、本発明では、車両端末は、衝突可能性算出部で算出した衝突の可能性が閾値を超える場合に、情報配信サーバに、ヒヤリ・ハット発生情報を送信し、歩行者の携帯端末は、情報配信サーバから自己についてのヒヤリ・ハット発生情報を受信する。この構成により、歩行者についても、車両との衝突の可能性が生じた状況について学習させ、今後の事故を未然に防ぐことに帰することができる。

以上のように、本発明によれば、自動車と自転車や歩行者との衝突事故において、事故前後の自転車や歩行者の挙動を記録し、車両側の記録データと合わせて配信することにより、事故解析や責任の証明に役立て、また、両者を同時にいち早く救急サポートセンター等に配信して負傷者の救護に役立てることができるという顕著な作用効果を奏する。

本発明の事故情報配信システムを示すブロック線図である。 本発明の四輪（車両）側のシステムの使用のフローを示す図である。 本発明の歩行者側のシステムの使用のフローを示す図である。 本発明の緊急サポートセンターのシステムの使用のフローを示す図である。

以下、図面を参照しながら、本発明の実施形態について説明する。

図１は、本発明の事故情報配信システムを示すブロック線図である。本発明の事故情報配信システム１は、歩行者携帯端末１００、車両端末２００及び情報配信サーバ３００からなり、３者相互の間で通信を行っている。

歩行者携帯端末１００は、歩行者側事故情報取得部１１０と通信部１２０を備える。歩行者側事故情報取得部１１０は、自己位置検出部１１１と衝突検知部１１２を備え、通信部１２０は、歩行者側事故情報送信部を兼ね備える送信部１２１と受信部１２２を備える。自己位置検出部１１１で検出した歩行者側の自己位置の情報と衝突検知部１１２で検知した歩行者側の衝突の情報は、歩行者携帯端末１００に紐づけられた情報として、通信部１２０の歩行者側事故情報送信部である送信部１２１から、車両端末２００へ送ることができる。

車両端末２００は、車両側事故情報取得部２１０と通信部２２０と、歩車情報関連付け処理部２３０を備える。車両側事故情報取得部２１０は、自己位置検出部２１１と衝突検知部２１２と衝突可能性算出部２１３とを備え、通信部２２０は、歩車報送信部を兼ね備える送信部２２１と、歩行者側事故情報受信部を兼ね備える部受信部２２２とを備える。自己位置検出部２１１で検出した車両側の自己位置の情報及び衝突検知部２１２で検知した車両側の衝突の情報は、それぞれ、歩行者側事故情報受信を兼ね備える部受信部２２２において受信した歩行者側の自己位置の情報及び歩行者側の衝突の情報とともに、歩車情報関連付け処理部２３０に送られ、歩車情報関連付け処理部２３０において関連付け処理がなされて歩車情報が形成される。歩車情報関連付け処理部２３０において処理され、形成された歩車情報は、歩車情報送信部を兼ね備える送信部２２１から、外部の情報配信サーバに送信され得る。

車両側の事故情報と歩行者側の事故情報が関連付けられて、外部の情報配信サーバに送信されることにより、車両側及び歩行者側の双方の視点から事故解析を行うことができるとともに事故の責任を証明することができる。また、外部の情報配信サーバが、緊急サポートセンターに接続されることにより、車両側及び歩行者側の双方の負傷者の救護活動に役立つものとなる。

また、車両端末２００の車両側事故情報取得部２１０は、衝突可能性算出部２１３も備え、他の車両や歩行者が自車に接近した場合に、衝突に至らなかった場合においても、衝突の可能性を算出する。衝突可能性算出部２１３は、衝突の可能性が閾値を超え、衝突の可能性有りと判断した場合には、ヒヤリ・ハット発生情報を生成し、生成したヒヤリ・ハット発生情報は、送信部２２１から、情報配信サーバ３００に送信される。車両端末２００の送信部２２１から送信され情報配信サーバ３００で受信されたヒヤリ・ハット発生情報は、歩行者携帯端末１００に配信することができ、歩行者携帯端末１００は、配信されたヒヤリ・ハット発生情報を、受信部１２２で受信することができる。車両側及び歩行者側の双方でヒヤリ・ハット発生情報を受け取ることにより、車両側及び歩行者側の双方で事故が生じ得る状況についての学習をすることができ、今後の事故を未然に防ぐことができるようになる。

次に、本発明の事故情報配信システムの活用方法について、図２において、四輪（車両）側のシステムの使用のフローを、図３において、歩行者側のシステムの使用のフローを、図４において、情報配信サーバのシステムの使用のフローを示す。なお、図２～４のフローにおいて、枝分かれのある判定（質問）型のステップでは、回答がＹＥＳの場合に直下の次のステップに進み、回答がＮＯの場合に左右の矢印の付いた線の方向へ進む。

図２は、四輪（車両）側のシステムの使用のフローを示す図である。このフローは主として四輪（車両）の乗員を対象として安全確認や救護の措置がなされるフローとなっている。四輪（車両）側のシステムの使用のフローは、四輪の車両が、歩行者又は自転車と衝突の可能性があるか否かを判断することから始まる（ステップＳ２０１）。回答がＹＥＳの場合、すなわち、車両が、歩行者又は自転車と衝突の可能性があると判断された場合には、情報配信サーバにヒヤリ・ハット発生情報を送信する（ステップＳ２０２）。回答がＮＯの場合、すなわち、車両が、歩行者又は自転車と衝突の可能性がないと判断された場合には、元に戻って、車両が、歩行者又は自転車と衝突の可能性があると判断されるまで待つことになる。

次に、車両が、歩行者又は自転車と衝突の可能性があると判断された場合において、情報配信サーバにヒヤリ・ハット発生情報が送信された（ステップＳ２０２）後、さらに衝突したかについて判定する（ステップＳ２０３）。回答がＮＯの場合、すなわち、衝突しなかった場合には、ステップＳ２０１に戻り、ステップＳ２０３でＹＥＳと回答されるまで、すなわち、衝突したと判定されるまで、ステップＳ２０１、ステップＳ２０２、ステップＳ２０３、ステップＳ２０１・・・・のループを繰り返すことになる。ステップＳ２０３で回答がＹＥＳの場合、すなわち、衝突したと判定された場合には、次のステップに進み、情報配信サーバに事故発生情報を送信し（ステップＳ２０４）、情報配信サーバは、緊急サポートセンターに接続される（ステップＳ２０５）。

次に、四輪（車両）の端末において、周辺のスマートフォン、すなわち、周辺の自転車の乗車者や歩行者の所有する携帯端末から情報を受信したかを判定する（ステップＳ２０６）。回答がＹＥＳの場合、すなわち、周辺のスマートフォンから情報を受信した場合、保存が必要なデータを車両のＥＤＲ（イベントデータレコーダ）等の記憶装置に保存し（ステップＳ２０７）、車両側で得たデータとともに、保存した周辺のスマートホンからの情報（データ）についても、両者を関連付けて情報配信サーバに送信する（ステップＳ２０８）。

ステップＳ２０６で回答がＮＯの場合、すなわち、周辺のスマートフォンから情報を受信しなかった場合には、四輪の車両側で得たデータのみを情報配信サーバに送信する（ステップＳ２０９）。ステップＳ２０８又はステップＳ２０９で送信されたデータ、すなわち、車両側で得たデータと保存した周辺のスマートホンからの情報（データ）が関連付けられたデータ又は四輪の車両側で得たのみのデータは、情報配信サーバを通じて、緊急サポートセンターに送られ、緊急サポートセンターのオペレータにより、四輪（車両）乗員の安全確認がなされる（ステップＳ２１０）。

次に、ステップＳ２１０のオペレータによる安全確認により、四輪（車両）乗員の反応があるか否かが確認される（ステップＳ２１１）。回答がＹＥＳの場合、すなわち、四輪（車両）乗員の反応がある場合には、次に、四輪（車両）乗員に負傷がないかが確認される（ステップＳ２１２）。ここでも回答がＹＥＳの場合、すなわち、四輪（車両）乗員に負傷がない場合には、オペレータの指示に基づいて、乗員向けに負傷者救護方法の音声ガイドや画像等が表示される（ステップＳ２１３）のみで、このフローは終了となる。

ステップＳ２１１に戻って、四輪（車両）乗員の反応があるか否かの確認（ステップＳ２１１）において、回答がＮＯの場合、すなわち、四輪（車両）乗員の反応がない場合には、緊急サポートセンターのオペレータより、事故があった四輪車両（自車）周囲のスマートフォンに、四輪乗員及び歩行者の救護要請なされる（ステップＳ２１４）。そして、この主として四輪（車両）の乗員を対象としたフローとしては、ここで終了となる。

また、ステップＳ２１１に戻って、四輪（車両）乗員の反応があるか否かの確認（ステップＳ２１１）において、回答がＹＥＳ、すなわち、四輪（車両）乗員の反応がある場合であって、次のステップＳ２１２に進み、四輪（車両）乗員に負傷がないかの確認（ステップＳ２１２）では回答がＮＯの場合、すなわち、四輪（車両）乗員に反応があり、乗員が負傷している場合には、オペレータにより四輪（車両）乗員の救護方法（対処方法）の指示がある（ステップＳ２１５）とともに、オペレータにより、四輪車両（自車）周囲のスマートフォンに、歩行者の救護要請なされる（ステップＳ２１６）。そして、この主として四輪（車両）の乗員を対象としたフローとしては、ここで終了となる。

図３は、歩行者側のシステムの使用のフローを示す図である。なお、歩行者側のフローにおいては、携帯端末（スマートフォン）を所持している歩行者自身が衝突事故に遭遇した場合の他、歩行者の近くで衝突事故が発生したときに救護者となる場合も含まれる。歩行者側のシステムの使用のフローは、時系列ＥＤＲデータの保存の準備をすることから始まる（ステップＳ３０１）。これは情報配信サーバ経由の通信遅れを考慮し、あらかじめ各種センサの時系列情報を記録しておくものである。

次に、情報配信サーバから、ヒヤリ・ハット発生情報を受信したか否かを確認する（ステップＳ３０２）。ここで受信したヒヤリ・ハット発生情報には、その情報を発信した車両端末の識別番号も付されている。ステップＳ３０２での回答がＹＥＳの場合、すなわち、ヒヤリ・ハット発生情報を受信した場合、次に、その発生地点が、受信した衝突予測地点の近くであるかを判断する（ステップＳ３０３）。ここでも回答がＹＥＳの場合、すなわち、ヒヤリ・ハット発生情報を受信し、その発生地点が、受信した衝突予測地点の近くである場合には、ヒヤリ・ハット警報を発信（表示）し（ステップＳ３０４）、携帯端末の所持者である歩行者に知らせるとともに、携帯端末の所持者である歩行者についての衝突判定の準備をする（ステップＳ３０５）。

そして、次のステップで衝突判定の結果、携帯端末の所持者である歩行者が衝突したか否かが判断される（ステップＳ３０６）。回答がＹＥＳの場合、すなわち、携帯端末の所持者である歩行者が衝突した場合、ステップＳ３０２で受信したヒヤリ・ハット発生情報に付されている識別番号の車両端末、すなわち、その情報を発信した車両端末に、事故に遭遇した端末である事故端末としての情報を送信する（ステップＳ３０７）。これによってこのフローは終了する。

ここで、ステップＳ３０２に戻り、回答がＮＯの場合、すなわち、ヒヤリ・ハット発生情報を受信していない場合には、次に、その携帯端末（スマートフォン）を保持する歩行者が近傍で事故が生じた際の救護者となり得るかについて、すなわち、その携帯端末（スマートフォン）が救護端末の候補となり得るか否かについての判定が行われる（ステップＳ３０８）。ここでの救護端末候補判定の詳細は後述する。

救護端末候補判定（ステップＳ３０８）の結果、救護端末候補に該当するか否かが判断され（ステップＳ３０９）、回答がＹＥＳの場合、すなわち、救護端末候補に該当すると判定された場合、救護端末処理が行われ（ステップＳ３１０）、このフローは終了する。救護端末処理の詳細は後述する。一方で、ステップＳ３０９の回答がＮＯの場合、すなわち、救護端末候補判定（ステップＳ３０８）の結果、救護端末候補に該当すると判定されなかった場合、ステップＳ３０２に戻り、その後、ステップＳ３０２又はステップＳ３０９でＹＥＳと回答されるまで、すなわち、ヒヤリ・ハット発生情報を受信するか、又は、救護端末候補に該当すると判断されるまで、ステップＳ３０２、ステップＳ３０８、ステップＳ３０９，ステップＳ３０２・・・・のループを繰り返すことになる。

次に、ステップＳ３０２で回答がＹＥＳとなり、ステップＳ３０３に進んでその回答がＮＯとなる場合、すなわち、ヒヤリ・ハット発生情報を受信するが、ヒヤリ・ハット発生情報の発信地が、それを受信した衝突予想地点の近くではない場合、ステップＳ３０２に戻り、ヒヤリ・ハット発生情報を受信し、しかも、ヒヤリ・ハット発生情報の発信地が、それを受信した衝突予想地点の近くである場合が生じるのを待つ。

次に、ステップＳ３０６へ移行し、回答がＮＯの場合、すなわち、衝突判定の結果、衝突しなかったと判定された場合のその後の処理は、ステップＳ３０２でＮＯと判定された場合、すなわち、ヒヤリ・ハット発生情報を受信しなかった場合と同様である。繰り返しになるが、再度説明すると、まずは、その携帯端末（スマートフォン）を保持する歩行者が近傍で事故が生じた際の救護者となり得るかについて、すなわち、その携帯端末（スマートフォン）が救護端末の候補となり得るか否かについての判定が行われる（ステップＳ３１１）。ここでの救護端末候補判定の詳細は後述する。

救護端末候補判定（ステップＳ３１１）の結果、救護端末候補に該当するか否かが判断され（ステップＳ３１２）、回答がＹＥＳの場合、すなわち、救護端末候補に該当すると判定された場合、救護端末処理が行われ（ステップＳ３１３）、このフローは終了する。救護端末処理の詳細は後述する。一方で、ステップＳ３１２の回答がＮＯの場合、すなわち、救護端末候補判定（ステップＳ３１１）の結果、救護端末候補に該当すると判定されなかった場合、ステップＳ３０６に戻り、その後、ステップＳ３０６又はステップＳ３１２でＹＥＳと回答されるまで、すなわち、衝突した判断されるか、又は、救護端末候補に該当すると判断されるまで、ステップＳ３０６、ステップＳ３１１、ステップＳ３１２，ステップＳ３０６・・・・のループを繰り返すことになる。

次に、上述した救護端末候補判定（サブルーチンＳ３５０）について説明する。救護端末候補判定（サブルーチンＳ３５０）は、まず、情報配信サーバから事故発生情報を受信したかを判断する（ステップＳ３５１）。ここで受信が判断される事故発生情報は、ヒヤリ・ハット発生情報を経ていない、いきなりの事故発生情報であるから、当該携帯端末（スマートフォン）を所持する歩行者の衝突事故の発生情報ではなく、他の歩行者における事故の発生情報であるものと推定される。ステップＳ３５１の回答がＹＥＳの場合、すなわち、情報配信サーバから事故発生情報を受信したと判定された場合、次に、その事故発生情報が発信された地点が、その事故発生情報の受信地点の近くかについて判断される（ステップＳ３５２）。

ステップＳ３５２の回答がＹＥＳの場合、すなわち、情報配信サーバから事故発生情報を受信したと判定され、かつ、その事故発生情報が発信された地点がその事故発生情報の受信地点の近くである場合、当該端末は、救護端末候補と判定され、このサブルーチンＳ３５０のフローは終了し、元に戻る。また、ステップＳ３５１又はステップＳ３５２の回答がＮＯの場合、すなわち、情報配信サーバから事故発生情報を受信しなかったと判定されるか、又は、その事故発生情報が発信された地点が受信地点の近くではない場合、当該端末は、救護端末候補と判定されることなく、このサブルーチンＳ３５０のフローは終了し、元に戻る。

次に、上述した救護端末処理（サブルーチンＳ３７０）について説明する。救護端末処理（サブルーチンＳ３７０）は、まず、当該携帯端末に救護要請候補依頼の表示をすることから始まる（ステップＳ３７１）。この表示は、当該携帯端末の所持者であるユーザに、救護要請の依頼をし、可能であれば、可能である旨の応答をするように催促する表示である。次に、当該携帯端末の所持者であるユーザから救護可能の応答があるか否か、すなわち、ユーザが携帯端末に救護可能の入力をしたか否かが確認される（ステップＳ３７２）。ステップＳ３７２の回答がＹＥＳの場合、すなわち、ユーザから救護可能の応答があることが確認された場合、サブルーチンＳ３５０のステップＳ３５１で受信した事故発生情報に付されている識別番号の車両端末、すなわち、その情報を発信した車両端末に、救護端末候補としての情報を送信し（ステップＳ３７３）、これによってこのサブルーチンＳ３７０フローは終了し、元に戻る。一方で、ステップＳ３７２の回答がＮＯの場合、すなわち、ユーザから救護可能の応答があることが確認されなかった場合、何らの処理もされることなく、このサブルーチンＳ３７０フローは終了し、元に戻る。

図４は、緊急サポートセンターのシステムの使用のフローを示す図である。緊急サポートセンターでは、まず、車両からの衝突事故が生じたという緊急通報データの受信を待ち（ステップＳ４０１）、緊急通報データを受信したかを監視する（ステップＳ４０２）。回答がNOの場合、すなわち、緊急通報データを受信していない場合、ステップＳ４０１に戻り、緊急通報データを受信するまで緊急通報データの受信を監視し続ける。ステップＳ４０２での回答がＹＥＳの場合、すなわち、緊急通報データを受信した場合には、受信した緊急通報データの情報に基づいて車両の乗員の死亡重症確立を推定する（ステップＳ４０３）。

続いて、車両と衝突した衝突対象の情報があるか否かについて確認する（ステップＳ４０４）。ここでの衝突対象の情報は、衝突対象の死亡重症確立の情報も含まれる。回答がＹＥＳの場合、すなわち、衝突対象の情報がある場合、ステップＳ４０３において算出した乗員の死亡重症確立を、消防本部、及び／又は、受信地点での基地病院に配信する（ステップＳ４０５）。また、衝突対象の情報は既にあることを前提として、算出した死亡重症確立に基づいて乗員と衝突対象の対処方法についてオペレータに指示し（ステップＳ４０６）、救護協力者の情報があるか否かを確認する（ステップＳ４０７）。

ここで、ステップＳ４０４に戻って、回答がＮＯの場合、すなわち、衝突対象の情報がない場合、受信した緊急通報データの情報に基づいて衝突対象を推定し（ステップＳ４０８）、また、受信した緊急通報データの情報に基づいて衝突部位を推定する（ステップＳ４０９）。そして、これらの衝突対象と衝突部についての推定結果のデータと、その他の受信した緊急通報データの情報に基づいて、乗員と衝突対象の死亡重症確立を算出し（ステップＳ４１０）、算出した乗員と衝突対象の死亡重症確立を、消防本部、及び／又は、受信地点での基地病院に配信する（ステップＳ４１１）。また、算出した死亡重症確立に基づいて乗員と衝突対象の対処方法についてオペレータに指示し（ステップＳ４１２）、救護協力者の情報があるか否かを確認する（ステップＳ４０７）。

そして、救護協力者の情報の確認についてのステップＳ４０７の回答がＹＥＳの場合、すなわち、救護協力者の情報がある場合には、救急サポートセンターにおけるこのフローは終了する。一方で、救護協力者の情報の確認についてのステップＳ４０７の回答がＮＯの場合、すなわち、救護協力者の情報がない場合には、救急サポートセンターが把握している周辺救護者についての情報から、救護協力者の連絡方法をオペレータに指示して（ステップＳ４１３）、救急サポートセンターにおけるこのフローは終了する。

以上、本発明を実施する態様について、実施例を用いて説明したが、本発明はこうした実施例に何ら限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々なる態様で実施できるものであることは勿論である。

１ 事故情報配信システム
１００ 歩行者携帯端末
１１０ 歩行者側事故情報取得部
１１１ 自己位置検出部
１１２ 衝突検知部
１２０ 通信部
１２１ 送信部（＝歩行者側事故情報送信部）
１２２ 受信部
２００ 車両端末
２１０ 車両側事故情報取得部
２１１ 自己位置検出部
２１２ 衝突検知部
２１３ 衝突可能性算出部
２２０ 通信部
２２１ 送信部（＝歩車情報送信部）
２２２ 受信部（＝歩行者側事故情報受信部）
３００ 情報配信サーバ

Claims (1)

1. 歩行者と車両の衝突事故の発生時に、歩行者の保持する携帯端末で取得した情報及び車両に備えられた車両端末で取得した情報を情報配信サーバに配信する事故情報配信システムにおいて、
   前記携帯端末は、
   衝突事故の情報を取得する歩行者側事故情報取得部と、
   前記歩行者側事故情報取得部で取得した歩行者側事故情報を前記車両端末へ送信する歩行者側事故情報送信部と、
   を備え、
   前記車両端末は、
   衝突事故の情報を取得する車両側事故情報取得部と、
   前記携帯端末の前記歩行者側事故情報送信部から送信された歩行者側事故情報を受信する歩行者側事故情報受信部と、
   前記車両側事故情報取得部で取得した車両側事故情報と前記歩行者側事故情報を関連付ける歩車情報関連付け処理部と、
   前記歩車情報関連付け処理部で関連付けられた歩車情報を前記情報配信サーバへ送信する歩車情報送信部と を備え、
   前記歩行者側事故情報取得部は、前記携帯端末の自己位置を検出する自己位置検出部と、前記携帯端末を保持する歩行者に衝突が生じたことを検知する衝突検知部と、を備え
   前記情報配信サーバは、救急サポートセンターに接続され、
   前記携帯端末は、前記救急サポートセンターから自己位置近傍での衝突事故発生情報を受信し、
   前記車両側事故情報取得部は、前記車両端末の自己位置を検出する自己位置検出部と、前記車両端末を備える車両に衝突が生じる可能性を算出する衝突可能性算出部と、前記車両端末を備える車両に衝突が生じたことを検知する衝突検知部とを備え、
   前記車両端末は、前記衝突可能性算出部で算出した衝突の可能性が閾値を超える場合に、前記情報配信サーバに、ヒヤリ・ハット発生情報を送信し、
   前記情報配信サーバで受信された前記ヒヤリ・ハット発生情報は、衝突事故に遭遇した歩行者の携帯端末、及び、衝突事項の発生個所の近くにいた歩行者の携帯端末に配信され、
   前記携帯端末が、前記ヒヤリ・ハット情報を受信していないか、又は、前記ヒヤリ・ハット情報を受信したが衝突した歩行者の端末でない場合であって、かつ、
   前記携帯端末が、前記情報配信サーバから事故発生情報を受信し、しかも、その事項発生情報受信地点の近くにある場合に救護端末候補と判定される
   事故情報配信システム。