JP2024061308A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】利便性をさらに改善した情報処理装置および情報処理方法を提供すること。【解決手段】情報処理装置は、複数のユーザそれぞれの移動状態情報を収集し、移動状態情報に基づいて危険状態の可能性の有無を判定する情報処理装置であって、複数のユーザそれぞれの属性情報を取得する取得部と、危険状態の可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置のうちのどの端末装置で注意喚起動作を実行するかを決定する制御部と、を有する。【選択図】図１

Description

本開示は、情報処理装置および情報処理方法に関する。

従来、携帯端末の所持者と車両との異常接近が回避されるように、所持者または車両の運転者のいずれかを支援する装置が知られている。例えば、特許文献１には、携帯端末の所持者が自転車に乗っている状態であるか否かを判別し、その結果に応じて、異なる態様で注意喚起を行う装置が開示されている。

特開２００９－２５１７５８号公報

しかしながら、従来の装置では、利便性に改善の余地があった。

本開示の目的は、利便性をさらに改善した情報処理装置および情報処理方法を提供することである。

本開示の一態様に係る情報処理装置は、複数のユーザそれぞれの移動状態情報を収集し、前記移動状態情報に基づいて危険状態の可能性の有無を判定する情報処理装置であって、前記複数のユーザそれぞれの属性情報を取得する取得部と、前記危険状態の可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置のうちのどの端末装置で注意喚起動作を実行するかを決定する制御部と、を有する。

本開示の一態様に係る情報処理方法は、複数のユーザそれぞれの移動状態情報を収集し、前記移動状態情報に基づいて危険状態の可能性の有無を判定する装置で実行される情報処理方法であって、前記複数のユーザそれぞれの属性情報を取得し、前記危険状態の可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置のうちのどの端末装置で注意喚起動作を実行するかを決定する。

本開示によれば、利便性をさらに改善した情報処理装置および情報処理方法を提供することができる。

本開示の実施の形態に係る安全支援システムの構成例を示すブロック図 本開示の実施の形態に係る携帯端末またはサーバに含まれるコンピュータのハードウェア構成例を示す図 本開示の実施の形態に係る属性判定処理の一例を示すフローチャート 本開示の実施の形態に係る属性毎の危険対象および保護対象の一覧を示す図 本開示の実施の形態に係る複数のユーザの移動状況の一例を真上から見た模式図 本開示の実施の形態に係る携帯端末およびサーバの動作例を示すシーケンスチャート

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

本実施の形態に係る安全支援システム１の構成例について、図１を用いて説明する。図１は、安全支援システム１の構成例を示すブロック図である。

図１に示すように、安全支援システム１は、携帯端末１００と、サーバ２００とを有する。携帯端末１００およびサーバ２００はともに、本開示の「情報処理装置」の一例に相当する。

携帯端末１００およびサーバ２００は、それぞれ、図２に示すように、ハードウェアとして、例えば、ＣＰＵ（Central Processing Unit）１０、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）などの主記憶装置２０、コンピュータプログラムを格納したハードディスク、フラッシュメモリなどの補助記憶装置３０、それらを接続するバス４０を有する。

以下に説明する携帯端末１００およびサーバ２００それぞれの機能は、ＣＰＵ１０が補助記憶装置３０から読み出したコンピュータプログラムを主記憶装置２０のＲＡＭに展開して実行することにより実現される。なお、そのコンピュータプログラムは、所定の記録媒体に記録されて、または、ネットワーク配信により、ユーザ等に提供されてもよい。

まず、携帯端末１００について説明する。

携帯端末１００は、移動するユーザに所持（携帯）される端末装置である。携帯端末１００としては、例えば、スマートフォン、タブレット、スマートウォッチ等が挙げられるが、それらに限定されない。なお、以下に説明する携帯端末１００の機能は、クラウドコンピューティングのサーバとユーザ端末との間におけるエッジサーバで実現されてもよい。

なお、図１では、便宜上、携帯端末１００を１つだけ図示しているが、実際には、携帯端末１００は、複数存在するものとする。

図１に示すように、携帯端末１００は、通信部１１０、取得部１２０、制御部１３０、出力部１４０を有する。

通信部１１０は、インターネット通信などのネットワーク通信やセルラー通信（移動体通信網を利用した通信）を行う通信デバイスである。

例えば、通信部１１０は、後述する移動状態情報および属性情報をサーバ２００へ送信したり、後述する判定結果情報をサーバ２００から受信したりする。

また、通信部１１０は、ＲＦＩＤ（Radio Frequency Identification）やBluetooth（登録商標）、Ｗｉ－Ｆｉ（登録商標）といった無線通信を行う通信デバイスを含む。

すなわち、本実施の形態における通信部１１０は、インターネット通信を実現するデバイスと無線通信を実現するデバイスの両方を含む概念である（それら両方の通信機能を１つのデバイスで実現するという意味ではない）。

取得部１２０は、各種情報を取得する取得デバイスである。ここでいう「取得」には、「検知」や「推定」といった意味が含まれるとする。

例えば、取得部１２０は、定期的に、携帯端末１００を所持するユーザ（以下、単にユーザという）の移動状態を示す移動状態情報を取得する。移動状態情報には、例えば、ユーザ（携帯端末１００と言ってもよい）の現在位置、進行方向、移動速度、および傾き等を示す情報が含まれる。この場合、取得部１２０としては、例えば、ＧＰＳ信号を受信するＧＰＳ（Global Positioning System）受信機、ＧＰＳ信号を基に現在位置等の測定を行うプロセッサ、加速度センサ等が挙げられる。なお、移動状態情報には、少なくとも現在位置情報が含まれればよく、それに加えて進行方向情報、速度情報、傾き情報等が含まれてもよい。

また、例えば、取得部１２０は、ユーザの属性を示す属性情報を取得する。属性としては、例えば、歩行者、サイクリスト（自転車の運転手）、ライダー（オートバイの運転手）、ドライバー（自動車の運転手）が挙げられる。この場合、取得部１２０としては、例えば、属性判定処理（詳細は後述）を行うプロセッサが挙げられる。

ここで、図３を用いて、携帯端末１００で行われる属性判定処理の流れを説明する。図３は、属性判定処理の一例を示すフローチャートである。図３のフローの開始時では、ユーザの属性は歩行者であるとする。また、ユーザの属性は切り替わる可能性があることから、図３のフローは、定期的に行われる。

まず、取得部１２０は、ユーザが車道から所定距離以内に存在するか否かを判定する（ステップＳ１）。

例えば、取得部１２０は、ＧＰＳ信号に基づいて測定された現在位置と、地図情報に示される車道の位置とを照合し、ユーザが車道から所定距離以内に存在しているか否かを判定する。ここでの地図情報は、例えば、携帯端末１００の記憶部（図示略）に記憶されているものである。

ユーザが車道から所定距離以内に存在していない場合（ステップＳ１／ＮＯ）、取得部１２０は、ユーザが安全支援の対象外であると判定する（ステップＳ２）。

安全支援の対象外とは、換言すると、後述する注意喚起を必要としない者である。ユーザが車道から所定距離以内に存在していない場合では、ユーザは、交通事故に遭う可能性が低い場所にいると考えられるため、安全支援の対象外と判定される。

なお、ユーザが安全支援の対象外であると判定された場合、端末がサーバに対象外である旨を送信する。なお、対象外であると判定された場合に、そのユーザの移動状態情報および属性情報は、サーバ２００へ送信されなくてもよい。これにより、携帯端末１００において通信に係る電力の消費を抑制できる。

一方、ユーザが車道から所定距離以内に存在している場合（ステップＳ１／ＹＥＳ）、取得部１２０は、ＧＰＳ信号のＣＮ（Carrier to Noise Ratio）値が予め定められた閾値以上であるか否かを判定する（ステップＳ３）。

ＧＰＳ信号のＣＮ値が閾値以上ではない場合（ステップＳ３／ＮＯ）、取得部１２０は、ユーザが安全支援の対象外であると判定する（ステップＳ２）。

ＣＮ値が閾値以上ではない場合では、ユーザは、屋内、または、現在位置の精度が十分ではない環境にいると推察されるため、安全支援が不要である、または、適切な支援が行えないと判断され、支援の対象外と判定される。

一方、ＧＰＳ信号のＣＮ値が閾値以上である場合（ステップＳ３／ＹＥＳ）、取得部１２０は、例えば加速度センサ等の検知結果に基づいて、一定時間内に歩行検知があるか否かを判定する（ステップＳ４）。

この判定処理は、ユーザが信号待ち等により歩行を停止している時間を考慮したものである。

一定時間内に歩行検知がある場合（ステップＳ４：ＹＥＳ）、取得部１２０は、ユーザが歩行者であると判定する（ステップＳ５）。

一方、一定時間内に歩行検知がない場合（ステップＳ４：ＮＯ）、取得部１２０は、携帯端末１００のホルダーへの装着の有無を判定する（ステップＳ６）。

ホルダーは、例えば、自転車またはオートバイの車体に取り付けられ、携帯端末１００を装着（収容）可能な器具である。このホルダーには、例えば、非接触ＩＣタグ（センサでもよい）が設けられている。通信部１１０は、携帯端末１００がホルダーに装着されたときに、非接触ＩＣタグから予め登録された二輪車種別情報を受信する。この二輪車種別情報には、ホルダーが取り付けられた二輪車が、自転車であるか、または、オートバイであるかが示されている。取得部１２０は、二輪車種別情報が受信された場合、携帯端末１００のホルダーへの装着があると判定し、二輪車種別情報が受信されない場合、携帯端末１００のホルダーへの装着がないと判定する。

携帯端末１００のホルダーへの装着がある場合（ステップＳ６／ＹＥＳ）、取得部１２０は、二輪車種別情報がオートバイまたは自転車のどちらを示すかを判定する（ステップＳ７）。

二輪車種別情報がオートバイを示す場合（ステップＳ７／オートバイ）、取得部１２０は、ユーザがライダーであると判定する（ステップＳ８）。

二輪車種別情報が自転車を示す場合（ステップＳ７／自転車）、取得部１２０は、ユーザがサイクリストであると判定する（ステップＳ９）。

携帯端末１００のホルダーへの装着がない場合（ステップＳ６／ＮＯ）、取得部１２０は、携帯端末１００と車載装置との間における認証の有無を判定する（ステップＳ１０）。

ここでいう認証としては、例えば、Bluetooth（登録商標）のペアリングが挙げられるが、これに限定されない。また、車載装置としては、例えば、Bluetooth（登録商標）通信機能を備えたカーナビゲーションシステムが挙げられるが、これに限定されない。

携帯端末１００と車載装置との間で認証が行われた場合（ステップＳ１０／ＹＥＳ）、取得部１２０は、ユーザがドライバーであると判定する（ステップＳ１１）。

携帯端末１００と車載装置との間で認証が行われない場合（ステップＳ１０／ＮＯ）、取得部１２０は、ユーザが安全支援の対象外であると判定する（ステップＳ２）。

以上、属性判定処理について説明した。なお、図３のフローは一例であり、これ以外の公知の方法を用いて属性を判定してもよい。また、ここでは携帯端末１００が属性判定処理を行う場合を例に挙げて説明したが、サーバ２００が行ってもよい。その場合、サーバ２００は、属性判定処理に必要な情報を携帯端末１００または他の装置から取得するものとする。以下、取得部１２０の説明に戻る。

取得部１２０は、上述した属性判定処理の結果に基づいて、ユーザが歩行者、サイクリスト、ライダー、ドライバーのいずれかであることを示す属性情報を取得（生成）する。

なお、本実施の形態では、取得部１２０は、属性判定処理を実行することにより属性情報を取得する場合を例に挙げたが、これに限定されない。例えば、取得部１２０は、ユーザによる属性入力操作を受け付けることで、属性情報を取得してもよい。

また、ユーザの属性は変更される場合がある。例えば、家を出たユーザが駐車場まで歩いて行き、そこから自動車に乗って移動する場合、取得部１２０は、属性を、歩行者からドライバーへ変更する。このように属性の変更があった場合、変更後の属性情報は、変更時点の移動状態情報とともにサーバ２００へ送信される。

制御部１３０は、各種制御を実行する制御デバイスである。

例えば、制御部１３０は、上述した移動状態情報および属性情報をサーバ２００へ送信するように通信部１１０を制御する。なお、送信される移動状態情報および属性情報には、携帯端末１００（またはユーザ）の識別情報が含まれる。また、移動状態情報の送信は、随時行われる。

また、例えば、制御部１３０は、通信部１１０がサーバ２００から受信した判定結果情報（詳細は後述）に基づいて、出力部１４０に注意喚起動作（詳細は後述）を実行させる。

出力部１４０は、注意喚起動作を行う出力デバイスである。

注意喚起動作とは、携帯端末１００のユーザが他のユーザと衝突する可能性（以下、衝突可能性という。衝突リスクといってもよい）がある場合に、携帯端末１００のユーザの注意を喚起させる動作である。

例えば、出力部１４０が携帯端末１００のディスプレイである場合、注意喚起動作として、衝突可能性がある旨を示す画像の表示が行われる。

また、例えば、出力部１４０が携帯端末１００のスピーカである場合、注意喚起動作として、衝突可能性がある旨を示す音声（単なる警告音でもよい）の出力が行われる。

また、例えば、出力部１４０が携帯端末１００のバイブレータである場合、注意喚起動作として、携帯端末１００が振動する。

なお、上述した各種注意喚起動作は、組み合わせて行われてもよい。

また、本実施の形態では、出力部１４０が携帯端末１００に設けられる場合を例に挙げたが、これに限定されない。例えば、出力部１４０は、携帯端末１００の外部に設けられ、携帯端末１００と無線通信が可能な出力デバイスであってもよい。このような出力デバイスとしては、例えば、サイクリストやライダーが使用するヘルメットに内蔵されたスピーカやヘッドアップディスプレイ、自動車の車室内に搭載されたディスプレイ、スピーカ、ステアリングホイールやシートを振動させるバイブレータ等が挙げられる。この場合、制御部１３０は、通信部１１０を介した無線通信により、外部の出力部１４０に注意喚起の実行を指示する。

次に、サーバ２００について説明する。

サーバ２００は、複数のユーザ（携帯端末１００と言ってもよい）それぞれの移動状態情報を収集し、それらの移動状態情報に基づいてユーザ同士の衝突可能性の有無を判定する情報処理装置である。図１では、サーバ２００を１つの装置として図示しているが、サーバ２００は、以下に説明する各部を分散させた複数のサーバの集合体であってもよい。

図１に示すように、サーバ２００は、通信部２１０、記憶部２２０、判定部２３０、制御部２４０を有する。

通信部２１０は、インターネット通信などのネットワーク通信を行う通信デバイスである。

例えば、通信部２１０は、上述した移動状態情報および属性情報を携帯端末１００から受信したり、後述する判定結果情報を携帯端末１００へ送信したりする。なお、通信部２１０は、「属性情報を取得する取得部」の一例に相当する。

記憶部２２０は、各種情報を記憶する記憶デバイスである。

例えば、記憶部２２０は、複数の携帯端末１００のそれぞれから収集された移動状態情報および属性情報をユーザ（識別情報）毎に記憶する。

また、例えば、記憶部２２０は、歩道、車道、建物等を示す地図情報を記憶する。

判定部２３０は、各ユーザの移動状態情報および地図情報に基づいて、互いに近い位置にいるユーザ同士の衝突の可能性の有無を判定（予測）する判定デバイスである。本実施の形態では、判定部２３０により判定される危険状態の可能性が、ユーザ同士の衝突の可能性である場合を例に挙げて説明する、なお、危険状態の可能性のその他の例については、後述の変形例で説明する。

具体的には、まず、判定部２３０は、属性情報に基づいて、ユーザ毎に、危険対象および保護対象を設定する。

危険対象とは、交通事故の加害者になる確率が高い属性である。保護対象とは、交通事故の被害者になる確率が高い属性である。

ここで、図４を用いて、危険対象および保護対象の例について説明する。図４は、属性毎の危険対象および保護対象の一覧を示す図である。

例えば、ユーザの属性が歩行者である場合、危険対象として、ドライバー、ライダー、サイクリストが設定され、保護対象は設定されない。

例えば、ユーザの属性がサイクリストである場合、危険対象として、ドライバー、ライダー、サイクリストが設定され、保護対象として、歩行者が設定される。

例えば、ユーザの属性がライダーである場合、危険対象として、ドライバー、ライダーが設定され、保護対象として、歩行者、サイクリストが設定される。

例えば、ユーザの属性がドライバーである場合、危険対象として、ドライバーが設定され、保護対象として、歩行者、サイクリスト、ライダーが設定される。

このように、ある属性に対して、相対的に交通強者となる属性が危険対象に設定され、相対的に交通弱者となる属性が保護対象に設定される。

このように危険対象と保護対象とに分類する目的としては、例えば、危険対象側のみに危険回避を促すこととし、保護対象側は通知の煩わしさを感じずに、危険対象側が知らない間に安全に導くといった安全支援サービスの融通性を拡げることが挙げられる。

以上、危険対象および保護対象の例について説明した。以下、判定部２３０の説明に戻る。

次に、判定部２３０は、属性情報に基づいて、ユーザ毎に、安全領域および危険領域を設定する。

安全領域とは、ユーザが交通事故に遭いにくい領域である。危険領域とは、ユーザが交通事故に遭いやすい領域である。

例えば、ユーザの属性が歩行者またはサイクリストである場合、安全領域として、歩道が設定され、危険領域として、車道が設定される。

例えば、ユーザの属性がライダーまたはドライバーである場合、危険領域として、車道が設定され、安全領域は設定されない。

次に、判定部２３０は、上記各設定と、移動状態情報と、地図情報とに基づいて、衝突可能性の有無を判定する。この衝突可能性判定処理は、危険領域に存在するユーザに対して行われ、安全領域に存在するユーザに対しては行われなくてもよい。

ここで、図５を用いて、衝突可能性判定処理の例について説明する。図５は、複数のユーザの移動状況の一例を真上から見た模式図である。

図５に示すように、車道Ｒは、同一方向に２つの車両通行帯（左側通行帯と右側通行帯）を備えている。図中の矢印ａは、自転車Ｂ、自動車Ｖ１、Ｖ２の進行方向を示している。左側通行帯において、走行中の自転車Ｂの前方には、自動車Ｖ２が停車している。右側通行帯を走行中の自動車Ｖ１は、自転車Ｂの後方に接近している。

まず、判定部２３０は、自転車Ｂに搭乗しているユーザ（サイクリスト）、自動車Ｖ１に搭乗しているユーザ（ドライバー）、自動車Ｖ２に搭乗しているユーザ（ドライバー）それぞれの移動状態情報に示される現在位置と、地図情報とを照合することにより、各ユーザが危険領域にいると判断し、各ユーザを衝突可能性判定処理の対象に決定する。ここでいう３人のユーザはいずれも、携帯端末１００のユーザであるとする。なお、駐車車両である自動車Ｖ２の搭乗者が携帯端末１００のユーザではない場合、道路に設置されたカメラ等により、移動状態情報が取得されてもよい。

次に、判定部２３０は、移動状態情報および地図情報に基づいて、自転車Ｂ、自動車Ｖ１、Ｖ２それぞれの位置関係（例えば図５に示す位置関係）、進行方向、移動速度を認識する。

例えば、判定部２３０は、左側通行帯において自動車Ｖ２が停車している（車速がゼロである）こと、自動車Ｖ２よりも後方の左側通行帯において自転車Ｂが矢印ａの方向へ走行していること、自転車Ｂよりも後方の右側通行帯において自動車Ｖ１が自転車Ｂよりも速い速度で矢印ａの方向へ走行していること、を認識した場合、自転車Ｂは左側通行帯から右側通行帯へ進路変更すると予測し、自転車Ｂと自動車Ｖ１との衝突可能性があると判定する。

なお、移動状態情報に例えば自転車Ｂの右方向への傾きを示す情報が含まれる場合、判定部２３０は、自転車Ｂの左側通行帯から右側通行帯への進路変更を予測してもよい。傾き情報を用いることで、より正確な予測が可能となる。

一方、例えば、判定部２３０は、左側通行帯において自動車Ｖ２が停車している（車速がゼロである）こと、自動車Ｖ２よりも後方の左側通行帯において自転車Ｂが停車していること、自転車Ｂよりも後方の右側通行帯において自動車Ｖ１が矢印ａの方向へ走行していること、を認識した場合、自動車Ｖ１は停車中の自転車Ｂを追い抜くと予測し、自転車Ｂと自動車Ｖ１との衝突可能性がないと判定する。

なお、上述した衝突可能性判定処理は、あくまで一例であり、判定部２３０は、他の公知の方法を用いて衝突可能性の有無を判定してもよい。

以上、衝突可能性判定処理の例について説明した。以下、判定部２３０の説明に戻る。

判定部２３０は、衝突可能性がないと判定した場合、各携帯端末１００から新たに受信した移動状態情報および属性情報に基づいて、再度、上述した危険対象、保護対象、安全領域、および危険領域の設定処理や、衝突可能性判定処理を行う。

一方、判定部２３０により衝突可能性があると判定された場合、制御部２４０による処理（詳細は後述）が行われる。

制御部２４０は、衝突可能性のあるユーザそれぞれの携帯端末１００のうちのどの携帯端末１００で注意喚起を実行するかを決定し、その携帯端末１００への通知を実行するように通信部２１０を制御する制御デバイスである。

具体的には、まず、制御部２４０は、衝突可能性があるユーザそれぞれの属性情報を比較し、相対的に交通強者であるユーザの携帯端末１００を、注意喚起動作を実行する端末装置に決定する。

例えば、図５に示した自転車Ｂと自動車Ｖ１との衝突可能性がある場合では、図４に示したようにサイクリストからみてドライバーは危険対象（交通強者）であるため、制御部２４０は、自転車Ｂのユーザの携帯端末１００と自動車Ｖ１のユーザの携帯端末１００のうち、自動車Ｖ１のユーザの携帯端末１００を、注意喚起動作を実行する端末装置に決定する。

次に、制御部２４０は、注意喚起動作を実行する端末装置に決定された携帯端末１００へ、衝突可能性がある旨を示す判定結果情報を送信するように通信部２１０を制御する。これにより、通信部２１０から携帯端末１００へ判定結果情報が送信される。

判定結果情報は、単に衝突可能性がある旨を示す情報でもよいし、衝突のおそれがあるユーザの属性情報や現在位置情報を含んでもよい。例えば、図５に示した自動車Ｖ１へ送信される判定結果情報には、自動車Ｖ１の左前方を走行中の自転車Ｂと衝突するおそれがある旨が含まれてもよい。

上述したとおり、携帯端末１００（具体的には、通信部１１０）が判定結果情報を受信した場合、制御部１３０は、その判定結果情報に基づいて、出力部１４０に注意喚起動作を実行させる。

例えば、判定結果情報が単に衝突可能性がある旨を示す場合、制御部１３０は、その旨を示す画像の表示、音声の出力、携帯端末１００の振動を出力部１４０に実行させる。また、例えば、判定結果情報が衝突のおそれがあるユーザの属性情報や現在位置情報を含んでいる場合、制御部１３０は、衝突可能性がある旨に加えて、属性情報や現在位置情報を示す画像の表示や音声の出力を出力部１４０に実行させる。なお、判定結果情報に基づいて行われる注意喚起動作は、判定結果情報の内容如何にかかわらず、携帯端末１００の設定に基づいて行われてもよい。

なお、携帯端末１００の制御部１３０は、サーバ２００から受信した判定結果情報と、自転車Bの右方向への傾きを示す情報とに基づき、出力部１４０に注意喚起動作を実行させてもよい。例えば、判定部２３０が、左側通行帯において自動車Ｖ２が停車していること、自動車Ｖ２よりも後方の左側通行帯において自転車Ｂが矢印ａの方向へ走行していること、自転車Ｂよりも後方の右側通行帯において自動車Ｖ１が自転車Ｂよりも速い速度で矢印ａの方向へ走行していること、を認識した場合、サーバ２００は、注意喚起動作を実行する端末装置に決定された携帯端末１００へ判定結果情報が送信される。携帯端末１００は、サーバ２００から判定結果情報を受信するが、判定結果情報を受信した時点では、注意喚起動作を実行せず、注意喚起動作の実行を待機する。その後、注意喚起動作の待機中に携帯端末１００の備えるセンサにて、携帯端末１００の傾きが検知された場合（例えば、ユーザが自動車Ｖ２を回避するために右方向へ自転車Ｂを傾けた場合）、携帯端末１００は注意喚起動作を実行する。言い換えると、注意喚起動作の待機中に携帯端末１００の傾き検知を契機として、ユーザに通知する事ができる。そのため、ユーザの行動変化を認識し、危険状態の可能性が有る場合にユーザに通知し、危険状態の可能性がない場合にはユーザに通知しないため、ユーザにとって不必要で煩わしい通知を減らすことができる。

以上、本実施の形態の安全支援システム１（携帯端末１００およびサーバ２００）の構成例について、説明した。

次に、本実施の形態の携帯端末１００およびサーバ２００の動作例について、図６を用いて説明する。図６は、携帯端末１００およびサーバ２００の動作例を示すシーケンスチャートである。なお、図６では、１つの携帯端末１００とサーバ２００との間の処理について図示しているが、複数の携帯端末１００のそれぞれとサーバ２００との間で図６に示すフローが実行される。よって、サーバ２００は、各携帯端末１００を識別情報（ＩＤ）で管理しており、各携帯端末１００からサーバ２００へ送信される情報には、識別情報が含まれる。これにより、サーバ２００は、どの携帯端末１００から受信した情報であるかを認識できる。

まず、各携帯端末１００は、移動状態情報および属性情報を取得し、それらに携帯端末１００自身のＩＤを紐付けてサーバ２００へ送信する（ステップＳ２０）。

次に、サーバ２００は、各携帯端末１００から、ＩＤが紐付けられた移動状態情報および属性情報を受信する（ステップＳ２１）。

次に、サーバ２００は、ＩＤ毎に属性を設定し、それらを地図上にマッピングする（ステップＳ２２）。

次に、サーバ２００は、属性情報に基づいて、危険対象および保護対象を設定する（ステップＳ２３）。

次に、サーバ２００は、属性情報に基づいて、安全領域および危険領域を設定する（ステップＳ２４）。

次に、サーバ２００は、移動状態情報および地図情報に基づいて、危険状態の可能性の有無を判定する（ステップＳ２５）。なお、本実施の形態では、危険状態の可能性は、例えば、ユーザ同士の衝突可能性である。

危険状態の可能性がない場合（ステップＳ２６／ＮＯ）、フローは、ステップＳ２１へ戻る。この場合、サーバ２００は、ステップＳ２１において携帯端末１００から新たに受信した移動状態情報および属性情報に基づいて、再度ステップＳ２２～Ｓ２５を実行する。

一方、危険状態の可能性がある場合（ステップＳ２６／ＹＥＳ）、サーバ２００は、可能性があるユーザの携帯端末１００のうち、注意喚起動作を実行すべき端末装置を決定する（ステップＳ２７）。

サーバ２００は、注意喚起動作を実行すべき端末装置に決定した携帯端末１００へ、判定結果情報を送信する（ステップＳ２８）。

携帯端末１００は、サーバ２００から判定結果情報を受信する（ステップＳ２９）。

携帯端末１００は、所定の出力部に注意喚起動作を実行させる（ステップＳ３０）。

以上、実施の形態に係る携帯端末１００およびサーバ２００の動作例について、説明した。

上述した本実施の形態のサーバ２００は、複数のユーザそれぞれの移動状態情報を収集し、移動状態情報に基づいて危険状態の可能性の有無を判定する情報処理装置であって、
複数のユーザそれぞれの属性情報を取得する取得部（例えば、通信部２１０）と、
危険状態の可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置（例えば、携帯端末１００）のうちのどの端末装置で注意喚起動作を実行するかを決定する制御部２４０と、を有する、ことを特徴とする。

この特徴により、衝突可能性のあるユーザのうちいずれかに対してのみ注意喚起が行われることになるため、注意喚起が頻繁に行われることがなく、ユーザが感じる煩わしさを低減することができる。すなわち、本実施の形態のサーバ２００は、安全支援システム１における利便性をさらに改善することができる。その結果、安全支援システム１の参加者を増やすことができ、交通事故の抑制に寄与することができる。

特に、本実施の形態のサーバ２００は、衝突可能性があるユーザそれぞれの属性情報を比較し、相対的に交通強者であるユーザの端末装置を、注意喚起動作を実行する端末装置に決定することを特徴とする。

この特徴により、交通弱者（例えば、歩行者、サイクリスト）に対して頻繁に注意喚起が行われることを回避することができる。すなわち、注意喚起の頻度が多くなりがちな交通弱者にとっての煩わしさを抑制することができる。

上述した実施の形態は、何れも本開示を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本開示の技術的範囲が限定的に解釈されてはならないものである。すなわち、本開示はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

以下、実施の形態に適用可能な変形例について説明する。

［変形例１］
実施の形態では、サーバ２００が複数の携帯端末１００から移動状態情報および属性情報を収集することにより、複数のユーザそれぞれが衝突可能性の判定対象となる場合を例に挙げて説明したが、これに限定されない。

例えば、携帯端末１００（以下、自端末という）が、他端末（自端末以外の携帯端末１００）のユーザの移動状態情報および属性情報を受信し、それらの情報に基づいて、自端末のユーザと他ユーザとの衝突可能性を判定してもよい。

その場合、自端末は、図１に示した各部に加えて、サーバ２００の記憶部２２０、判定部２３０を備えてもよい。以下、この場合の動作の流れについて簡単に説明する。

まず、取得部１２０は、実施の形態と同様に、自端末のユーザの属性情報と移動状態情報を取得する。

また、通信部１１０は、他端末のユーザの属性情報および移動状態情報を受信する。このとき、通信部１１０は、他端末のユーザの属性情報および移動状態情報を、他端末から直接受信してもよいし、または、図示しない配信用サーバから受信してもよい。

次に、判定部２３０は、取得部１２０および通信部１１０により取得された属性情報および移動状態情報と、記憶部２２０に記憶された地図情報とに基づいて、実施の形態と同様の処理（例えば、危険対象および保護対象の設定、安全領域および危険領域の設定、衝突可能性判定処理）を行う。ただし、衝突可能性判定処理については、自端末のユーザを対象とする（逆に言えば、他端末のユーザ同士の衝突可能性判定処理は実行しない）。

判定部２３０により衝突可能性があると判定された場合、制御部１３０は、実施の形態で説明した制御部２４０と同様に、注意喚起動作を実行する端末装置を決定する。

制御部１４０は、注意喚起動作を実行する端末装置を自端末に決定した場合、所定の注意喚起動作を出力部１４０に実行させる。

一方、制御部１４０は、注意喚起動作を実行する端末装置を他端末に決定した場合、実施の形態と同様の判定結果情報を他端末へ送信するように通信部１１０を制御する。これにより、判定結果情報は、直接他端末へ、または、図示しない配信サーバを介して他端末へ送信される。そして、他端末の制御部１３０は、判定結果情報を受信すると、所定の注意喚起動作を実行するように出力部１４０を制御する。

このように、本変形例の携帯端末１００は、複数のユーザそれぞれの移動状態情報を収集し、移動状態情報に基づいてユーザ同士の衝突可能性の有無を判定する情報処理装置であって、複数のユーザそれぞれの属性情報を取得する取得部（例えば、通信部１１０および取得部１２０）と、衝突可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置（例えば、携帯端末１００）のうちのどの端末装置で注意喚起動作を実行するかを決定する制御部１３０と、を有することを特徴とする。

この特徴により、本変形例の携帯端末１００は、上述した実施の形態と同様の効果を得ることができる。

［変形例２］
実施の形態では、歩行者については歩道が安全領域に設定されるため、歩道にいる歩行者は、衝突可能性判定処理の対象にならない。しかし、自転車が歩道を走行する場合もあり、その場合には、歩行者とサイクリストとの衝突可能性が生じうる。

そこで、判定部２３０は、歩行者が存在する歩道にサイクリストが存在するか否かを判定してもよい。そして、同一歩道上に歩行者とサイクリストが存在する場合には、制御部２４０は、歩行者の携帯端末１００へ、サイクリストの存在を知らせる通知情報を送信するとともに、サイクリストの携帯端末１００へ、走行路の変更を促す催促情報を送信する。

歩行者の携帯端末１００の制御部１３０は、受信した通知情報に基づいて、サイクリストの存在を報知する画像の表示や音声の出力等を出力部１４０に実行させる。

サイクリスト携帯端末１００の制御部１３０は、受信した催促情報に基づいて、走行路の変更を促す画像の表示や音声の出力等を出力部１４０に実行させる。

このような動作により、歩道に存在する歩行者とサイクリストとの衝突可能性を低減することができる。

［変形例３］
ユーザの属性がドライバーである場合には、携帯端末１００の代わりに、備え付けの車載機器（図示略。例えば、カーナビゲーションシステム、Ｖ２Ｘ通信ユニット等）が用いられてもよい。すなわち、図１に示した通信部１１０、取得部１２０、制御部１３０、および出力部１４０は、車載機器に設けられてもよい。

その場合、サーバ２００へ送信される移動状態情報には、車載センサ等で検知されたステアリング操作や方向指示操作を示す情報等が含まれてもよい。これにより、サーバ２００（具体的には、判定部２３０）において、ドライバー（自動車）の進路の予測精度を向上させることができる。

実施の形態で説明したとおり、例えば、ユーザの属性が歩行者からドライバーへ変更される場合がある。この場合、携帯端末１００を所持したユーザが自動車に搭乗したときに、携帯端末１００と車載機器との間で無線通信により認証処理を行うことで、携帯端末１００の各部の機能を、車載機器が引き継ぐようにしてもよい。これにより、携帯端末１００と車載機器とで動作が競合することを防ぐことができる。なお、ユーザが降車し、ユーザの属性がドライバーから歩行者に変更された場合には、車載機器は動作の引き継ぎを終了し、携帯端末１００において各部の動作が再実行される。

例えば、属性判定処理において、ユーザの属性が歩行者からドライバーに更新された場合、携帯端末１００は、携帯端末１００の各部の機能を引き継ぐことが可能な車載機器があるかどうか判断する。ここで、引き継ぐことが可能な車載機器は、ダッシュボードやカーナビゲーション用のオペレーティングシステムや、Ｖ２Ｘ通信ユニットであればよい。また、引き継ぐことが可能な車載機器があるかどうかの判断においては、車載機器がダッシュボードやカーナビゲーション用のオペレーティングシステムの場合、携帯端末１００とコネクション確立(ケーブル接続)がされたことにより、引き継ぐことが可能な車載機器があると判断してもよい。また、車載機器がＶ２Ｘ通信ユニットの場合、サーバを介して携帯端末１００と、車載機器とを認証することで、引き継ぐことが可能な車載機器があると判断してもよい。そして、引き継ぐことが可能な車載機器がある場合、車載機器は携帯端末１００の各部の機能を引き継ぎ実行し、携帯端末１００は属性判定のみが実行される。一方、引き継ぐことが可能な車載機器がない場合は、携帯端末１００において、引き続き各部の機能を実行する。一例として、車載機器がダッシュボードやカーナビゲーション用のオペレーティングシステムの場合は、カーナビゲーションの表示パネルや音声出力を介して注意喚起動作が実行される。車載機器がＶ２Ｘ通信ユニットの場合、HUD（Head-Up Display）、液晶メーターの表示パネルや音声出力を介して注意喚起動作が実行される。これにより、携帯端末１００と車載機器とで動作が競合することにより、双方で注意喚起が発生しユーザが煩わしさを感じてしまうことを防ぐことができる。なお、ダッシュボードやカーナビゲーション用のオペレーティングシステムとＶ２Ｘ通信ユニットがどちらも存在する場合、地図情報をもとにした単位面積当たりのユーザ数によって、引き継ぐ車載機器を決定してもよい。具体的には、携帯端末１００は、Ｖ２Ｘ通信ユニットにより確認された単位面積当たりの周囲のユーザ数（Ｎｖｘ）を受信する。さらに、サーバ２００により確認された単位面積当たりの周囲のユーザ数（Ｎｃ）を問い合わせ、ユーザ数（Ｎｃ）を受信する。そして、携帯端末１００は、ユーザ数（Ｎｖｘ）とユーザ数（Ｎｃ）を比較し、ユーザ数（Ｎｖｘ）の数が多い場合は、Ｖ２Ｘ通信ユニットを引き継ぎ先に決定し、ユーザ数（Ｎｃ）の数が多い場合は、ダッシュボードやカーナビゲーション用のオペレーティングシステムを引き継ぎ先に決定する。なお、ユーザ数（Ｎｃ）に補正係数αを加減した数と、ユーザ数（Ｎｖｘ）を比較してもよい。これにより、周囲にユーザがより多く確認できる車載機器を優先することができ、より精度のよい注意喚起動作を実行することができる。

［変形例４］
実施の形態では、ユーザの属性が歩行者である場合、そのユーザが歩道にいるかぎり（換言すると、車道に出なければ）、そのユーザの携帯端末１００において注意喚起動作は実行されない場合を例に挙げたが、ユーザ自身が、所持する携帯端末１００では注意喚起動作が実行されないように設定できるようにしてもよい。これにより、歩行者に対しては一切注意喚起が行われないため、ユーザに煩わしさを感じさせないこととなり、安全支援サービスの利用拡大が促進する。その結果、多くのユーザが参加やすくなり、全体として、確実性が高い安全支援サービスが実現される。

［変形例５］
実施の形態では、危険状態の可能性がユーザ同士の衝突可能性である場合を例に挙げて説明したが、これに限定されない。以下、別の例について説明する。なお、以下の各例において、図６のステップＳ２０～Ｓ２３、Ｓ２７～Ｓ２９は、実施の形態と同様であるので、ここでの説明は省略する。

＜例１＞
例えば、危険状態の可能性は、車両の速度超過に基づいて判定されてもよい。

この場合では、移動状態情報に、属性がサイクリスト（自転車の運転手）、ライダー（オートバイの運転手）、ドライバー（自動車の運転手）であるユーザの移動速度（すなわち、ユーザが搭乗している自転車、オートバイ、自動車のいずれかの車速）の情報が含まれる。移動速度は、例えば、ＧＰＳ信号のドップラー効果等に基づいて算出された値でもよい。

判定部２３０は、移動状態情報に示される現在位置および移動速度、地図情報に示される道路の制限速度に基づいて、ユーザ（自転車、オートバイ、自動車）が速度超過しているか否かを判定する。ユーザが速度超過していると判定された場合、制御部２４０は、そのユーザの携帯端末１００を、注意喚起動作を実行すべき端末装置に決定する。なお、速度超過の判定は、携帯端末１００で行われてもよく、サーバ２００から地図情報に示される道路の制限速度を受信し、制限速度と移動速度とを制御部１３０で比較することで判定してもよい。

＜例２＞
例えば、危険状態の可能性は、自転車が歩道を走行しているか否かに基づいて判定されてもよい。

判定部２３０は、属性がサイクリストであるユーザの移動状態情報に示される現在位置と、地図情報とに基づいて、ユーザ（自転車）が歩道上に存在し、かつ、走行しているかを判定する。ユーザが自転車で歩道を走行していると判定された場合、制御部２４０は、そのユーザの携帯端末１００を、注意喚起動作（例えば、変形例２で説明した催促情報に基づく通知）を実行すべき端末装置に決定する。

＜例３＞
例えば、危険状態の可能性は、駐車車両への追突可能性に基づいて判定されてもよい。

判定部２３０は、属性がサイクリスト、ライダーまたはドライバーであるユーザの移動状態情報に示される現在位置と、外部装置から取得した検知情報（例えば、見通し外交差点に設置したカメラ等による検知情報結果）とに基づいて、ユーザ（自転車または自動車）が駐車車両への追突する可能性があるかを判定する。ユーザが駐車車両へ追突する可能性があると判定された場合、制御部２４０は、そのユーザの携帯端末１００を、注意喚起動作を実行すべき端末装置に決定する。なお、駐車車両の検知方法は、携帯端末１００の属性判定において、属性がドライバーから歩行者に切り替わった位置の座標が車道上である場合、サーバ２００は、当該携帯端末１００のユーザが運転していた車両（携帯端末１００と位置情報や通信認証により紐づいた車両）を駐車車両と判断してもよい。

＜例４＞
例えば、危険状態の可能性は、属性が歩行者であるユーザが所定範囲内に所定数以上存在するか否かに基づいて判定されてもよい。

判定部２３０は、属性が歩行者であるユーザ（以下、第１ユーザという）の移動状態情報に示される現在位置と、属性がサイクリスト、ライダー、またはドライバーのいずれかであるユーザ（以下、第２ユーザという）の移動状態情報に示される現在位置（ユーザがドライバーである場合には、カーナビに登録された走行ルートを含んでもよい）とに基づいて、第２ユーザの進行方向に歩行者が所定範囲内に所定数以上存在するかを判定する。例えば、所定範囲内として１０ｍ^２内に、所定数として２０人以上の歩行者が存在するかを判定すればよい。歩行者が所定範囲内に所定数以上存在すると判定された場合、制御部２４０は、第２ユーザの携帯端末１００を、注意喚起動作を実行すべき端末装置に決定する。さらに、制御部２４０は、地図情報等に基づいて歩行者が多数存在する場所を回避可能な走行ルートを検索し、その走行ルートを示す案内情報を第２ユーザの携帯端末１００に送信してもよい。これにより、第２ユーザの携帯端末１００において、上記走行ルートの通知（注意喚起動作の一例）が行われる。これにより、第２ユーザは、容易に安全なルートを走行できる。さらに、第２ユーザは、目的地への到着遅延を防ぐことができる。

以上、変形例について説明した。上述した変形例は、適宜組み合わせてもよい。

本開示の情報処理装置および情報処理方法は、移動中のユーザの安全を支援する技術に有用である。

１ 安全支援システム
１００ 携帯端末
１１０ 通信部
１２０ 取得部
１３０ 制御部
１４０ 出力部
２００ サーバ
２１０ 通信部
２２０ 記憶部
２３０ 判定部
２４０ 制御部

Claims (12)

1. 複数のユーザそれぞれの移動状態情報を収集し、前記移動状態情報に基づいて危険状態の可能性の有無を判定する情報処理装置であって、
   前記複数のユーザそれぞれの属性情報を取得する取得部と、
   前記危険状態の可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置のうちのどの端末装置で注意喚起動作を実行するかを決定する制御部と、を有する、
   情報処理装置。
2. 前記危険状態の可能性は、前記ユーザの衝突可能性に基づいて判定され、
   前記制御部は、
   前記ユーザの衝突可能性がある場合に、どの端末装置で注意喚起動作を実行するかを決定する、
   請求項１に記載の情報処理装置。
3. 前記危険状態の可能性は、前記ユーザの速度超過に基づいて判定され、
   前記制御部は、
   前記ユーザの速度超過が検知された場合に、当該ユーザの端末装置で注意喚起動作を実行することを決定する、
   請求項１に記載の情報処理装置。
4. 前記危険状態の可能性は、前記ユーザが自転車で歩道を走行しているか否かに基づいて判定され、
   前記制御部は、
   前記ユーザが自転車で歩道を走行している場合に、当該ユーザの端末装置で注意喚起動作を実行することを決定する、
   請求項１に記載の情報処理装置。
5. 前記注意喚起動作は、走行経路の変更を促す通知である、
   請求項４に記載の情報処理装置。
6. 前記危険状態の可能性は、前記ユーザの駐車車両への追突可能性に基づいて判定され、
   前記制御部は、
   前記ユーザの駐車車両への追突可能性がある場合に、当該ユーザの端末装置で注意喚起動作を実行することを決定する、
   請求項１に記載の情報処理装置。
7. 前記危険状態の可能性は、前記ユーザの進行方向に歩行者が所定範囲内に所定数以上存在するか否かに基づいて判定され、
   前記制御部は、
   前記ユーザの進行方向に歩行者が所定範囲内に所定数以上存在する場合に、当該ユーザの端末装置で注意喚起動作を実行することを決定する、
   請求項１に記載の情報処理装置。
8. 前記注意喚起動作は、前記歩行者が所定数以上存在する場所を回避可能な走行ルートの通知である、
   請求項７に記載の情報処理装置。
9. 前記属性情報は、歩行者、自転車の運転手、オートバイの運転手、自動車の運転手のいずれかを示し、
   前記制御部は、
   前記衝突可能性があるユーザそれぞれの属性情報を比較し、相対的に交通強者であるユーザの端末装置を、前記注意喚起動作を実行する端末装置に決定する、
   請求項１に記載の情報処理装置。
10. 前記情報処理装置は、サーバであり、
    前記サーバは、
    前記注意喚起を実行する端末装置に決定された端末装置へ、前記衝突可能性がある旨を示す判定結果情報を送信し、
    前記端末装置は、
    前記判定結果情報に基づいて、前記注意喚起動作を所定の出力部に実行させる、
    請求項１に記載の情報処理装置。
11. 前記情報処理装置は、端末装置であり、
    前記複数のユーザには、前記情報処理装置のユーザが含まれ、
    前記制御部は、
    当該情報処理装置自身が前記注意喚起を実行する端末装置に決定された場合、前記注意喚起動作を所定の出力部に実行させる、
    請求項１に記載の情報処理装置。
12. 複数のユーザそれぞれの移動状態情報を収集し、前記移動状態情報に基づいて危険状態の可能性の有無を判定する装置で実行される情報処理方法であって、
    前記複数のユーザそれぞれの属性情報を取得し、
    前記危険状態の可能性があるユーザそれぞれの属性情報に基づいて、当該ユーザそれぞれの端末装置のうちのどの端末装置で注意喚起動作を実行するかを決定する、
    情報処理方法。

Images