以下に、本願にかかる情報処理装置、情報処理方法および情報処理プログラムを実施するための形態(以下、「実施形態」と呼ぶ)について図面を参照しつつ説明する。なお、この実施形態により本願にかかる情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。
また、以下に、本願にかかる表示制御プログラム、表示制御方法および端末装置を実施するための形態(同様に、以下、「実施形態」と呼ぶ)について図面を参照しつつ説明する。なお、この実施形態により本願にかかる表示制御プログラム、表示制御方法および端末装置が限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。
〔1.第1の提示処理の概要〕
まず、図1を用いて、実施形態にかかる提示処理のうち第1の提示処理の概要を示す。図1は、実施形態にかかる第1の提示処理の一例を示す図である。第1の提示処理は、情報処理装置100によって行われる。
なお、第1の提示処理については、後に詳述するが、1つの第1の提示処理は、ユーザが移動体に対して所定の行動を行う地点であって仮想的な地点である仮想地点に関する情報に基づいて、ユーザ以外のユーザであって仮想地点を利用するユーザである他ユーザに関する情報をユーザに提示する処理である。かかる提示処理を「提示処理1−1」とする。
また、別の1つの第1の提示処理は、移動体における空席状況を示す空席情報に基づいて、移動体に乗車予定のユーザを移動体に乗車させる順番を決定し、決定した順番をユーザに提示する処理である。かかる提示処理を「提示処理1−2」とする。
また、実施形態にかかるシステム1は、図4に示すように、端末装置10と、移動体制御装置30と、情報処理装置100とを含む。図4は、実施形態にかかるシステム1の構成例を示す図である。図4に示すように、端末装置10、移動体制御装置30、情報処理装置100は、ネットワークNを介して有線または無線により通信可能に接続される。
端末装置10は、ユーザによって利用される情報処理装置である。端末装置10は、例えば、スマートフォンや、タブレット型端末や、ノート型PC(Personal Computer)や、デスクトップPCや、携帯電話機や、PDA(Personal Digital Assistant)等である。また、端末装置10は、タッチパネルの表示画面Dを有する。また、端末装置10には、移動体に関する情報登録が行われたり、移動体に関する各種情報を提示可能にするアプリケーション(以下、「アプリAP1」と表記する)が予めインストールされているものとする。
アプリAP1は、実施形態にかかる情報処理装置100と連携することにより、移動体に関する各種情報を取得し、取得した情報をユーザに提示する。また、例えば、ユーザは、アプリAP1に対して、移動体に関する情報を「お気に入り登録」することができる。
また、本実施形態では、情報処理装置100が対象とする移動体は「オンデマンドバス」であるものとする。オンデマンドバスは、路線バスの一種であるが、ユーザがインターネット等の通信手段を用いて手続きを行った場合に、例えば、基本路線の外の迂回路線を経由して、例えば、仮想的に設置されたバス停留所へとユーザを迎えに行く。基本路線に存在する従来からの物理的なバス停留所(「既存バス停」と表記する場合がある)に対して、このように仮想的に設置されるバス停留所を「仮想バス停」とする。仮想バス停は、ユーザがオンデマンドバス(移動体の一例)に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点の一例である。
また、以下の実施形態では、移動体をオンデマンドバスとして説明するが、実施形態にかかる移動体は、運行スケジュールに沿って基本路線を走行するオンデマンドバスに限定されるものではない。例えば、移動体は、基本路線が決められておらず、ユーザによって指定された場所に逐一ユーザを迎えに出向くことのできる乗り合い形式のオンデマンドバスであってもよい。また、移動体は、ユーザによって指定された場所に逐一ユーザを迎えに出向くことのできる乗り合い形式のタクシー(乗り合いタクシー)であってもよい。
移動体制御装置30は、移動体に搭載される端末装置である。例えば、移動体制御装置30は、移動体の現在位置、移動体の現在位置からバス停までの距離、バス停への到着予定時刻等を取得し情報処理装置100に送信する。なお、移動体の現在位置、移動体の現在位置からバス停までの距離、バス停への到着予定時刻等は、情報処理装置100によって取得および算出されてもよい。
また、移動体制御装置30は、例えば、移動体に各種センサ(例えば、カメラや人感センサ等)が搭載されている場合、センサによって検出された情報をセンサから取得することができる。また、移動体制御装置30は、センサによって検出された情報を情報処理装置100に送信することができる。また、例えば、移動体が、乗客の乗り降りを制御するブザー(例えば、移動体にこれ以上人が乗ることができない場合、警告音を出力するブザー)が搭載されている場合、警告音の出力制御を行う。
ここで、情報処理装置100によって提示処理1−1が行われる前提について説明する。情報処理装置100は、例えば、サーバ装置である。上記の通り、オンデマンドバスは、物理的に実在する既存バス停に停車する場合もあるが、物理的には実在しない仮想バス停に停車する場合もある。当然ながら、ユーザは、仮想バス停については目視することができない。ただし、情報処理装置100は、ユーザの端末装置10(アプリAP1)を介して、仮想バス停の位置をユーザに知らせることができるため、ユーザは端末装置10を用いて仮想バス停の大まかな位置を把握することができる。
このような場合において、例えば、仮想バス停Zからオンデマンドバスに乗車しようとするユーザUX1とユーザUX2が居るものと仮定する。また、ユーザUX1およびユーザUX2は、互いに全く知らない同士(他人同士)であるとする。ユーザUX1およびユーザUX2は、端末装置10を介して知らされた仮想バス停Zの位置にてオンデマンドバスが到着するまで待機することになるが、この位置には既存バス停のように、例えば、ポール、ベンチあるいは施設(待合施設)が存在する訳ではない。そうすると、例えば、ユーザUX1から見て近くにユーザUX2が居ると、ユーザUX2は本当にオンデマンドバスに乗ろうとしているのか確証が無く、例えば、自身に対して不審な行動を起こそうとしているのではないかといった不安感が募る場合がある。ユーザUX2から見ても同様のことがいえる。
また、ユーザUX1を女性、ユーザUX2を男性とすると、上記のような不安感はより大きくなると考えられるうえ、例えば、周囲から見てユーザUX2は不審人物ではないかと誤解される場合もあり得る。しかしながら、仮想バス停Zからオンデマンドバスに乗車しようとする、いわば同一目的のユーザ同士であるとの、ある程度の確証が互いに得られていれば不安感は随分と解消される可能性が高くなる。
このようにユーザ間で防犯上都合が悪くなるような前提を基に、実施形態にかかる情報処理装置100は、提示処理1−1を行う。具体的には、情報処理装置100は、提示処理1−1として、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点に関する情報である仮想乗車地点情報を取得し、取得した仮想乗車地点情報に基づいて、仮想乗車地点を利用するユーザである他ユーザに関する情報をユーザに提示する。例えば、情報処理装置100は、他ユーザに関する情報として、仮想乗車地点から移動体に乗車予定の他ユーザの有無を示す情報を提示する。
次に、情報処理装置100によって提示処理1−2が行われる前提について説明する。上記の通り、既存バス停には、例えば、ポール、ベンチあるいは施設(待合施設)が存在する。このように目視可能な物理目標があれば、ユーザは特性上、この物理目標を目印として、例えば、オンデマンドバスが到着するまで列を成して順に並んで待機することができる。また、このように並んで待機することができると、列の順にオンデマンドバスに乗り込み、空席があれば乗り込んだ順に空席に座ればよいと、ユーザは暗黙の上で了承している場合が多い。
一方で、既存バス停には、目視可能な物理目標が存在する訳ではないので、ユーザはどこにどう並んでよいかわからない場合がある。結果として、複数のユーザがなんとなく同じくらいの位置に散らばって待機するといった状況が起こり得る。このような状態において、オンデマンドバスが到着すると、ユーザは周りの他のユーザを気にせず自身の好きな順で乗り込むため、空席があれば当然ながらより早く乗り込んだユーザがその空席に座ろうとする。そうすると、空席に座ることができなかったユーザから見れば、並んでもいないのに好き勝手に乗り込んで席を取られた、といった負の感情が生まれてしまうことがあり得る。さらにいうと、空席をめぐって、ユーザ間で言い争い等に発展してしまうこともあり得る。
このような問題を解消するためには、物理目標が存在せず並んで待機させることが困難な状況において、あたかも並んでいたの如く乗車順を予め各ユーザに割り当てておくことが効果的であると考えられる。
このように、並んで待機させることが困難な状況における前提を基に、実施形態にかかる情報処理装置100は、提示処理1−2を行う。具体的には、情報処理装置100は、第2の提示処理として、移動体における空席状況を示す空席情報を取得し、取得した空席情報に基づいて、移動体に乗車予定のユーザを移動体に乗車させる順番を決定する。そして、情報処理装置100は、決定した順番をユーザに提示する。例えば、情報処理装置100は、空席情報として、移動体が有する空席の数を示す空席情報を取得し、移動体に乗車予定のユーザを前記移動体に乗車させる順番として、空席の数に応じた順番を決定する。
以下では、図1を用いて、実施形態にかかる第1の提示処理の一例について説明する。なお、図1では、情報処理装置100は、仮想バス停が設置される設置位置の候補(以下、「候補位置」と表記する場合がある)をユーザに提示することにより、候補位置の中からオンデマンドバスに乗車を希望する位置、すなわち乗車希望位置を指定させるものとする。また、情報処理装置100は、乗車希望位置だけでなく乗車希望時刻をさらに指定させることもできる。
まず、図1のMAP1に示されるエリアでは、オンデマンドバスB1(バスB1)が基本路線RT10を走行するものとする。また、基本路線RT10上には、既存バス停ST1およびST2が存在する。また、既存バス停ST1が位置する位置情報は「S−PT1」であり、既存バス停ST2が位置する位置情報は「S−PT2」である。
また、図1の例では、ユーザU1の現在位置は現在位置「HP11」であり、ユーザU2の現在位置は現在位置「HP21」であり、ユーザU3の現在位置は現在位置「HP31」である。ユーザU1、U2およびU3は、それぞれ自身の端末装置10を有している。
ここで、図1の例では、既にユーザU1およびU2によって、バスB1への乗車の意思表示が行われているものとする。具体的には、情報処理装置100は、図1(a)に示すように、ユーザU1の端末装置10に対して、MAP1上のどこに候補位置が存在するかといったことを示す情報を含むページP1aを表示させる。なお、図1(a)では、ユーザU3の端末装置10を例示しているが、表示のUI(ユーザインタフェース)はどのユーザでも同様であるため、ここでは、図1(a)はユーザU1のものとして説明する。
情報処理装置100は、MAP1上における候補位置CP1に「ココで乗る」と表示されたアイコンF1を表示させる。また、情報処理装置100は、MAP1上における候補位置CP2に「ココで乗る」と表示されたアイコンF2を表示させる。また、情報処理装置100は、MAP1上における候補位置CP3に「ココで乗る」と表示されたアイコンF3を表示させる。ユーザU1は、候補位置CP1〜CP3の中に乗車希望位置が存在する場合には、その候補位置に対応するアイコンを選択(例えば、タップ)することで、選択した候補位置について乗車の位置表示を行うことができる(乗車希望位置を指定することができる)。図1では、ユーザU1は、候補位置CP1を乗車希望位置として指定し、さらに、候補位置CP1に「2018年7月1日10時5分」に来るよう指定したものとする。
かかる場合、情報処理装置100は、候補位置CP1を仮想バス停が設置される設置位置として決定するとともに、候補位置CP1に仮想バス停を設置する。また、実施形態にかかるバスB1は、候補位置CP1に「2018年7月1日10時5分」に到着予定のオンデマンドバスである。なお、候補位置CP1は、設置位置CP1と言い換えることもできる。また、候補位置CP1の「CP1」は、候補位置を識別する識別情報と、例えば、候補位置の位置情報を示す座標といった両方の概念を含み得るものとする。他の候補位置についても同様である。
さて、上記のように、ユーザU1による意思表示により候補位置CP1に仮想バス停が設置され、候補位置CP1に「2018年7月1日10時5分」に到着予定のバスB1が発生した状態において、ユーザU2も図1(a)のページP1aを参照し、候補位置CP1からの意思表示を行ったものとする。つまり、ユーザU2もアイコンF1を選択することで、候補位置CP1を乗車希望位置として指定したとする。ユーザU2が個のような指定を行う際には、アイコンF1中に到着予定時刻「2018年7月1日10時5分」がさらに表示されてもよい。
このようにユーザU1およびU2が候補位置CP1での乗車の意思表示を行っている状態において、ユーザU3も意思表示を行いたいために情報処理装置100にアクセスしたとする。かかる場合、情報処理装置100は、ユーザU3に対して仮想バス停の候補位置を提示する(ステップS11)。既に説明した通り、情報処理装置100は、図1(a)に示すようなページP1aを端末装置10に表示させる。候補位置CP1に「2018年7月1日10時5分」に到着予定のバスB1については、ユーザU1およびU2が乗車予定であることが既に決まっている。そして、ユーザU3も候補位置CP1からの意思表示を行ったものとする。つまり、ユーザU3もアイコンF1を選択することで、候補位置CP1を乗車希望位置として指定したとする。これにより、情報処理装置100は、ユーザU3から候補位置C1からの乗車の意思表示を受け付ける、すなわち乗車希望位置として候補位置CP1を指定する旨を受け付ける(ステップS12)。
次に、情報処理装置100は、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザの人数を更新する(ステップS13)。ユーザU1が意思表示を行った時点では、情報処理装置100は、ユーザ人数を「0」から「1」へと更新する。また、ユーザU2がさらに意思表示を行った時点では、情報処理装置100は、ユーザ人数を「1」から「2」へと更新する。そして、今回、ユーザU3が意思表示を行った時点では、情報処理装置100は、ユーザ人数を「2」から「3」へと更新する。
次に、情報処理装置100は、提示処理1−1に対応する情報提示を行うタイミングであるか否かを判定し、情報提示を行うタイミング(例えば、候補位置CP1にバスB1が到着するまでの残り時間が5分を切ったタイミング)であると判定した場合には、ユーザU3以外のユーザであって、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザ、すなわちユーザU1およびU2に関する情報をユーザU3に提示する(ステップS14)。例えば、情報処理装置100は、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザが居るかいないか(有無)をユーザU3に提示する。
図1の例では、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザとして、ユーザU1およびU2がいる。かかる場合、情報処理装置100は、ユーザU3以外に乗車予定のユーザが居る旨をユーザU3に提示する。例えば、情報処理装置100は、図1(b)に示すように、ユーザU3以外に乗車予定のユーザが居る旨を示す情報J1を含むページP1bを表示させる。
なお、図1の例では、ユーザU1目線では、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザとして、ユーザU2およびU3がいる。したがって、情報処理装置100は、ユーザU1にはユーザU1以外に乗車予定のユーザが居る旨を提示する。また、ユーザU2目線では、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザとして、ユーザU1およびU3がいる。したがって、情報処理装置100は、ユーザU2にはユーザU2以外に乗車予定のユーザが居る旨を提示する。
また、情報処理装置100は、提示処理1−2に対応する情報提示を行うタイミングであるか否かを判定する。言い換えれば、情報処理装置100は、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1における現在の空席状況を示す空席情報を取得するタイミング(例えば、候補位置CP1にバスB1が到着するまでの残り時間が3分を切ったタイミング)であるか否かを判定し、空席情報を取得するタイミングであると判定した場合には、空席情報を取得する(ステップS15)。例えば、かかるバスB1が有する移動体制御装置30がバスB1内の空席を検知することで、検知した空席に基づく空席情報を情報処理装置100に送信する。これにより、情報処理装置100は、空席情報を取得することができる。
次に、情報処理装置100は、取得した空席情報に基づいて、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1に乗車予定のユーザを、かかるバスB1に乗車させる順番(乗車順)を決定する(ステップS16)。かかる例で乗車予定のユーザとは、ユーザU1、U2およびU3(ユーザU1〜U3)である。したがって、情報処理装置100は、ユーザU1〜U3それぞれに対して、バスB1に乗車させる乗車順を決定する。一例を示すと、情報処理装置100は、ユーザU1〜U3それぞれの現在位置を示す位置情報を取得(監視)しておくことで、候補位置CP1に到着した到着順を取得する。そして、情報処理装置100は、例えば、ユーザU1〜U3のうち到着順が早いユーザほど早い(若い)乗車順を決定する。
図1の例では、ユーザU1の到着順が「1」、ユーザU2の到着順が「3」、ユーザU3の到着順が「2」であったとする。かかる場合、情報処理装置100は、ユーザU1に対して乗車順「1」を決定し、ユーザU2に対して乗車順「3」を決定し、ユーザU3に対して乗車順「2」を決定する。なお、情報処理装置100は、例えば、ユーザU1〜U3の中に身体的に障害を有するユーザが居れば、そのユーザについては到着順を無視し優先的に早い乗車順を決定することもできる。これにより、情報処理装置100は、身体的に障害を有するユーザを空席に座らせることができる。
そして、情報処理装置100は、ユーザU1〜U3それぞれに対して、乗車順を提示する(ステップS17)。ユーザU3を例に挙げると、情報処理装置100は、図1(c)に示すように、ユーザU3の乗車順は「3」であることを示す情報J2を含むページP1cを表示させる。
ここで、例えば、図1(b)に示す情報J1をユーザU3に提示する前に、図1(c)に示す情報J2をユーザU3に提示した場合、ユーザU3は自分以外に乗車予定のユーザが何人いるかを予測できてしまう場合がある。かかる例では、最低一人は自分以外に乗車予定のユーザがいることをユーザU3に予測されてしまう場合がある。防犯上、各ユーザについて、バスB1に乗車する直前までは、自分以外に何人のユーザが乗車予定であることは、隠しておくことが好ましい。なぜなら、乗車予定のユーザが他に1人しかいないならそのユーザに何らかの悪事を働いてやろうと考える者や、乗車予定のユーザが他に多数存在する場合には、集団を相手にした悪事を働いてやろうと考える者が出てくるかもしれない。情報処理装置100は、このような状況に成り得ることを防止するために、好ましくは、情報J1を提示した後に情報J2を提示する。このためには、ステップS14でのタイミングが、ステップS15でのタイミングよりも時間的に早くなるよう設定される。
さて、ここまで実施形態にかかる提示処理のうち第1の提示処理について説明してきた。まず、実施形態にかかる情報処理装置100は、提示処理1−1により、バスB1を利用する際における防犯面での安心感をバスB1のユーザに与えることができる。例えば、ユーザU3は、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1を利用するユーザが自分以外にも居ることを予め知ることができるため、バス停を示す物理目標が存在しない候補位置CP1において、誰かが居たとしてもその人は不審者ではなく同じ利用者なのだという安心感を得ることができる。
また、実施形態にかかる情報処理装置100は、提示処理1−2により、バスB1の到着まで並んで待機させることが困難な状況において、バスB1の空席に適切にユーザを着座させることができる。候補位置CP1にはバス停を示す物理目標が存在しないため、ユーザU1〜U3それぞれは、候補位置CP1の周辺でなんとなく散らばってバスB1を待つことになり、隊列が発生しない。しかしながら、ユーザU1〜U3には、予め乗車順が割り当てられることになるため、バスB1が来てもスムーズに乗り込むことができ、空席があれば乗り込んだ順に座ることができる。このためユーザ間で空席の奪い合い等が生じることもない。
また、情報処理装置100は、候補位置CP1に仮想バス停を設置したことで、候補位置CP1へ向かうよう基本ルートRT10から迂回した迂回ルートRT20を決定する。そして、情報処理装置100は、迂回ルートRT20を通り候補位置CP1にて停車するようバスB1に指示する。例えば、情報処理装置100は、バスB1の移動体制御装置30に迂回ルートRT20に関する情報を送信する。
〔2.第2の提示処理の概要〕
次に、図2を用いて、実施形態にかかる提示処理のうち第2の提示処理の概要を示す。図2は、実施形態にかかる第2の提示処理の一例を示す図である。第2の提示処理も情報処理装置100によって行われる。第2の提示処理は、ユーザが移動体に乗車する乗車地点に関する情報である乗車地点情報、または、ユーザが移動体から降車する降車地点に関する情報である降車地点情報に基づいて、移動体の利用に関する位置をユーザに提示する処理である。また、第2の提示処理では、移動体はオンデマンドバスとする。
ここで、情報処理装置100によって第2の提示処理が行われる前提について説明する。例えば、オンデマンドバスからユーザUX3が降車する場合を例に挙げる。また、ユーザUX3は自宅(自宅Hとする)前にて降車したい旨を予め情報処理装置100に対して登録しているものとする。かかる場合、通常であれば、情報処理装置100に従って、オンデマンドバスは自宅Hの前に停車することでユーザを降車させる。
このような場合、まだオンデマンドバスに乗っている乗客から、例えば、窓越しにユーザUX3の自宅が自宅Hであることがわかってしまう恐れがある。例えば、ユーザUX3がオンデマンドバスから降車して建物に入っていった場合、それを窓越しに見ていたユーザによっては、その建物がユーザUX3の自宅Hであると推測されてしまう恐れがある。さらに乗客の中にユーザUX3に対して特別な感情を有する者がいたとすると、その乗客に自宅Hが判明してしまうことは防犯上非常に危険である。また、ユーザUX3も、他の乗客に自宅Hの場所がわかってしまうことを避けたい、自宅Hの場所を他の乗客から隠蔽したいと望む場合がある。
乗客に自宅Hが判明してしまうことを回避するもっとも単純な方法は、自宅Hからある程度離れた場所においてユーザUX3を降車させることが考えられる。この場合、降車させる位置によっては、ユーザUX3が自宅Hまでの移動ルートとして、治安や交通において安全性の低いルート(例えば、晩において街灯の無い暗がりのルート、不審者出没歴のあるルート、事故多発ルート等)を選択して自宅Hに向かう可能性がある。
上記の前提をまとめると、防犯上の観点からオンデマンドバスの乗客から特定の場所(例えば、自宅や職場等)がわからないよう隠蔽できるような位置にて、対象のユーザを乗降させる必要がある。また、安全性の観点から特定の場所(例えば、自宅や職場等)と、乗降位置との間のルートは、より安全性の高いルートが好ましい。
このように、防犯や治安上の安全性を基に、実施形態にかかる情報処理装置100は、第2の提示処理を行う。具体的には、情報処理装置100は、ユーザが移動体に乗車する乗車地点に関する情報である乗車地点情報、または、ユーザが移動体から降車する降車地点に関する情報である降車地点情報に基づいて、移動体の利用に関する位置を決定し、決定した位置を示す位置情報をユーザに提示する。
例えば、情報処理装置100は、乗車希望地点(または、降車希望地点)であってユーザにより指定された乗車希望地点(または、降車希望地点)が移動体の乗客によって特定されないような位置を乗車(または、降車)位置として決定する。また、例えば、情報処理装置100は、乗車希望地点(または、降車希望地点)、および、乗車位置(または、降車位置)との間の所定エリアの周辺環境を示す環境情報に基づいて、移動体の利用に関する位置として、乗車希望地点(または、降車希望地点)から乗車位置(または、降車位置)までのユーザの移動ルートを決定する。
以下では、図2を用いて、実施形態にかかる第2の提示処理の一例について説明する。なお、図2では、情報処理装置100は、オンデマンドバスに乗車する乗車希望地点の位置情報(以下「乗車希望位置」とする)、または、オンデマンドバスから降車する降車希望地点の位置情報(以下「降車希望位置」とする)を指定させるものとする。図1では、情報処理装置100は、候補位置の中からいずれかを指定させたが、図2では、候補位置を提示することなく任意の位置を指定させる。なお、図2では、ユーザU4がオンデマンドバスであるバスB2から降車する場合を例に説明するが、乗車の場合であっても情報処理装置100が行う処理は同様である。
まず、情報処理装置100は、乗車希望位置または降車希望位置の指定をユーザU4から受け付ける(ステップS21)。つまり、情報処理装置100は、乗車希望位置または降車希望位置を取得する。乗車希望位置は、ユーザが移動体に乗車する乗車地点に関する情報の一例である。また、降車希望位置は、ユーザが移動体から降車する降車地点に関する情報の一例である。例えば、情報処理装置100は、ユーザU4からのアクセスに応じて、乗車希望位置または降車希望位置を入力させるページP2aを配信することで、乗車希望位置または降車希望位置の指定をユーザU4から受け付ける。
図2(a)の例では、ページP2aには、乗車希望位置を入力させる入力欄、降車希望位置を入力させる入力欄、他者から乗車希望地点あるいは降車希望地点を隠蔽したい場合にチェックを入れるチェックボックス、隠蔽したい場所を追加登録させる入力欄が含まれる。図2では、ユーザU4は、降車希望地点として自宅HP1(降車希望地点の一例)をオンデマンドバスの乗客から隠蔽したいものとする。かかる場合、ユーザU4は、乗車希望位置に対応する入力欄に自宅HP1の位置を示す位置情報(例えば、住所)を入力しOKボタンを押下する。これにより、情報処理装置100は、降車希望位置の指定をユーザU4から受け付ける。
次に、情報処理装置100は、自宅HP1方面に向かうバスと、自宅HP1へ向う走行ルートとを特定する(ステップS22)。例えば、情報処理装置100は、自宅HP1方面に向かうバスとしてバスB2を特定し、自宅HP1へ向う走行ルートとして走行ルートRT30を特定したとする。例えば、走行ルートRT30へ入る前のいずれかの走行ルートのいずれかの位置からバスB2に人が乗車してきたり、人が降車するといった状況が起こり得る。したがって、自宅HP1に差し掛かる直前においてバスB2にはユーザU4以外にもユーザが乗車している可能性は十分にある。
このような状態において、情報処理装置100は、自宅HP1と、バスB2が走行する走行ルートRT30との位置関係に基づいて、自宅HP1がバスの乗客によって特定されないような位置を、ユーザU4を降車させる降車位置として決定する(ステップS23)。例えば、情報処理装置100は、自宅HP1から所定範囲内のエリアであるエリアAR1において、自宅HP1がバスB2の乗客によって特定されないような位置として、バスB2の乗客からは自宅HP1が死角となる位置を降車位置として決定する。例えば、情報処理装置100は、自宅HP1の前の通りの走行ルートRT30を直進し、走行ルート30を左へ曲った先の位置XP11を降車位置として決定する。
例えば、自宅HP1の前でユーザU4が降車した場合、自宅HP1の前の走行ルートRT30は、しばらく直進しているため乗客からユーザU4が自宅HP1へ入ってゆくところが見えてしまう。そうすると、乗客に中には、「あの建物はきっとユーザU1の自宅に違いない」と特定されてしまう恐れがある。一方、走行ルート30を左へ曲った先の位置XP11からは、バスB2の乗客にとっては自宅HP1は死角になっており、また、ユーザU4は角を自宅HP1へ向かうことになるので、バスB2の乗客はユーザU4がどの建物に入ってゆくかも確認することができない。このようなことから、情報処理装置100は、位置XP11を降車位置として決定することによりバスB2の乗客から自宅H1を隠蔽することができる。
ここで、ユーザU4には、位置XP11から自宅HP1へ向かうにあたって複数の移動ルートが存在する。図2の例では、複数の移動ルートとして、移動ルートRT41、移動ルートRT42および移動ルートRT43が存在する。この3つの移動ルートのうち、どの移動ルートを利用するかはユーザU4次第であるが、中には防犯や治安の観点から安全性が低いルートが存在する場合がある。情報処理装置100は、位置XP11でユーザU4を降車させることによりユーザU4を自宅HP1まで歩かせることになるが、歩かせたことによりユーザU4が何らかの犯罪や事故等に巻き込まれてしまうことはなるべく回避したい。
このようなことから情報処理装置100は、自宅HP1および降車位置である位置XP11との間のエリアAR1の周辺環境を示す環境情報に基づいて、バスB2の利用に関する位置として、位置XP11から自宅HP1までのユーザU4の移動ルートを決定する。
移動ルートを決定するにあたって、情報処理装置100は、まず、自宅HP1および降車位置である位置XP11との間のエリアAR1内において、位置XP11から自宅HP1までの移動ルートの候補(候補ルート)を特定する(ステップS24)。図2の例では、情報処理装置100は、移動ルートRT41、移動ルートRT42および移動ルートRT43といった3つの候補ルートを特定したものとする。
次に、情報処理装置100は、候補ルート毎に、街灯の有無、交通量、店舗の数、犯罪件数、事故件数といった各項目についてスコアを算出することで、候補ルートの安全性を示す安全性スコアを算出する(ステップS25)。この点について、図2に示す「スコア情報」を用いて説明する。
まず、情報処理装置100は、候補ルートにおいて街灯が存在する場合にはスコアとして「+1」を加算し、街灯が存在しない場合にはスコアとして「0」を加算するものとする。なお、情報処理装置100は、街灯の数が多いほど高いスコアを加算してもよい。また、情報処理装置100は、候補ルートの交通量が所定量より多い場合にはスコアとして「+1」を加算し、交通量が所定量より少ない場合にはスコアとして「0」を加算するものとする。なお、情報処理装置100は、交通量が多いほど高いスコアを加算してもよい。
また、情報処理装置100は、候補ルートの店舗数が所定数より多い場合にはスコアとして「+1」を加算し、店舗数が所定数より少ない場合にはスコアとして「0」を加算するものとする。なお、情報処理装置100は、店舗数が多いほど高いスコアを加算してもよい。
また、情報処理装置100は、犯罪件数に応じたスコアを加算する。例えば、情報処理装置100は、犯罪件数が少ないほど高いスコアを加算する。例えば、情報処理装置100は、犯罪件数が0件の場合には、スコアとして「0」を加算し、犯罪件数が1件の場合にはスコアとして「−1」を加算する。また、情報処理装置100は、事故件数に応じたスコアを加算する。例えば、情報処理装置100は、事故件数が少ないほど高いスコアを加算する。例えば、情報処理装置100は、事故件数が0件の場合には、スコアとして「0」を加算し、事故件数が1件の場合にはスコアとして「−1」を加算する。
情報処理装置100は、候補ルートRT41には街灯が存在するためスコア「+1」を加算し、交通量が所定量より多いためスコア「+1」を加算し、店舗数が所定数より多いためスコア「+1」を加算し、犯罪件数0件のためスコア「0」を加算し、事故件数2件のためスコア「−2」を加算する。合計として、情報処理装置100は、「1」を算出する。したがって、情報処理装置100は、候補ルートRT41について安全性スコア「1」を算出する。
また、情報処理装置100は、候補ルートRT42には街灯が存在しないためスコア「0」を加算し、交通量が所定量より少ないためスコア「0」を加算し、店舗数が所定数より少ないためスコア「0」を加算し、犯罪件数1件のためスコア「−1」を加算し、事故件数2件のためスコア「−2」を加算する。合計として、情報処理装置100は、「−3」を算出する。したがって、情報処理装置100は、候補ルートRT42について安全性スコア「−3」を算出する。
また、情報処理装置100は、候補ルートRT43には街灯が存在するためスコア「+1」を加算し、交通量が所定量より少ないためスコア「0」を加算し、店舗数が所定数よ少ないためスコア「0」を加算し、犯罪件数0件のためスコア「0」を加算し、事故件数1件のためスコア「−1」を加算する。合計として、情報処理装置100は、「0」を算出する。したがって、情報処理装置100は、候補ルートRT43について安全性スコア「0」を算出する。
そして、情報処理装置100は、各候補ルートについて算出した安全性スコアに基づいて、ユーザU4に提示する対象の移動ルートを決定する(ステップS26)。安全性スコアが高い候補ルートほど、防犯や治安面でより安全といえる。このため、情報処理装置100は、安全性スコアが「1」で最も高い候補ルートRT41を対象の移動ルートとして決定する。そして、情報処理装置100は、ステップS23で決定した降車位置と、ステップS26で決定した移動ルートRT41とをユーザU4に提示する(ステップS27)。例えば、情報処理装置100は、図2(b)に示すように、降車位置が位置XP11であることと、位置XP11から自宅HP1へは移動ルートRT41が安全であることを示す情報J3を含むページP2bを表示させる。
図で説明したように、実施形態にかかる情報処理装置100は、乗車希望地点が移動体の乗客から特定出来ないような位置を乗車位置として決定する。また、情報処理装置100は、降車希望地点が移動体の乗客から特定出来ないような位置を降車位置として決定する。また、情報処理装置100は、乗車希望地点と乗車位置との間の移動ルートとしてより安全性の高い移動ルートを決定する。また、情報処理装置100は、降車希望地点と降車位置との間の移動ルートとしてより安全性の高い移動ルートを決定する。これにより、情報処理装置100は、防犯や治安上の安全性を考慮して移動体を利用させることができる。
例えば、ユーザの自宅の真正面でバスから降りるとバスの乗客から、このユーザの自宅が特定されてしまう恐れがあり、自宅前でバスから降りることは防犯上好ましくない場合がある。しかしながら、情報処理装置100は、自宅が特定されないような位置でユーザを降車させることができるためユーザの防犯を確保することができる。また、情報処理装置100は、ユーザを降ろした位置から自宅までの安全なルートを提案することができるため、どのような位置でユーザを降ろしてもその後の防犯や治安上の安全性も確保することができる。
〔3.表示制御処理の概要〕
次に、図3を用いて、実施形態にかかる表示制御処理の概要を示す。図3は、実施形態にかかる表示制御処理の一例を示す図である。実施形態にかかる表示制御処理は、情報制御プログラムによって行われる。具体的には、情報制御プログラムによる制御に従って、端末装置10が実施形態にかかる表示制御処理を行う。
ここで、実施形態にかかる表示制御プログラムによって端末装置10が、実施形態にかかる表示制御処理を行う前提について説明する。例えば、ユーザが端末装置10を向けている方向や傾きによっては、周りから他人を無断撮影しているのではといった誤解を招く場合がある。一例を示すと、ユーザが端末装置10を地面に対して90度に立てて操作し、さらに端末装置10が向けられている方向に人物が居た場合、周りからは、いかにもユーザがその人物を無断撮影しているのではないかと思われてしまう場合がある。また、ユーザ自体もこのように誤解されてしまうことを好ましく思わない場合がある。
しかしながら、誰かを無断撮影するといった気はなくとも、端末装置10を地面に対して90度にして操作しなければならないといった状況に成り得る場合もある。例えば、仮想バス停はユーザが目視することができない代わりに、実施形態にかかる情報処理装置100による表示制御処理によって、ユーザは端末装置10を介してどのあたりに仮想バス停が存在するかを知ることができる。
端末装置10は撮像部(カメラ機能)を有するため、撮像部によって取り込まれた実空間の映像が表示画面Dに表示される。このとき、撮像部によって取り込まれた実空間の映像の中に仮想バス停の設置位置が存在する場合には、情報処理装置100による表示制御処理によって、その設置位置に、例えば、仮想バス停の画像が3次元(以下、「3D」と表記する)の仮想現実画像として表示される。すなわち、実空間の映像に対して、仮想バス停の形状をした3D仮想現実画像が重畳して表示される。
このような表示制御が行われる場合、ユーザは、端末装置10を様々な方向に向けることにより仮想バス停がどこに存在するかを確かめる必要があり、特にユーザは端末装置10を下に向けるのではなく、正面方向に向けて確認作業を行うことを求められる。そうすると、上記のように、誰かを無断撮影しているのではないかと誤解されてしまう場合がある。
このような誤解を招かないためには、端末装置10をなるべく地面の方向に向けて操作すればよいが、そうすると当然ながら表示画面Dには地面方向の映像しか表示されないため、正面方向に存在し得る仮想バス停の位置を確認することができなくなってしまう。したがって、端末装置10を地面方向に向けていたとしても、正面の映像も表示画面Dに表示されれば、誤解を招くこともなく仮想バス停の位置を確認することができる。
このような前提を基に、表示制御プログラムは、実施形態にかかる表示制御処理を端末装置10に対して行わせる。具体的には、表示制御プログラムは、端末装置10の撮影方向と傾きとを検知する検知手順と、検知手順により検知された傾きが所定の条件情報を満たすと判定された場合には、端末装置10に撮影方向に関する情報を表示させる表示制御手順とを端末装置10に実行させる。例えば、表示制御手順は、所定の条件情報を満たす場合として、検知手順により検知された傾きが所定の角度以下となった場合には、端末装置10に撮影方向に関する情報を表示させる。
以下では、図3を用いて、実施形態にかかる表示制御処理の一例について説明する。図の例では、端末装置10の撮像部13(カメラ)によって取り込まれる実空間の中に、図1で説明した候補位置CP1が存在する場合に、情報処理装置100による表示制御処理によって、実空間の映像に対して、仮想バス停の形状をした3D仮想現実画像が重畳して表示される。なお、情報処理装置100による表示制御処理と、表示制御プログラムによる表示制御処理とは、互いに連動するもので一つの表示制御処理として解釈することができるものとする。また、表示制御プログラムは、撮像部13を制御するアプリケーションプログラム(カメラアプリ)の一種でもある。
また、図3では、候補位置CP1についてバスB1への乗車の意思表示を行ったユーザU1〜U3のうち、ユーザU3の端末装置10を例に説明する。候補位置CP1にはバス停の存在を示す物理目標が存在する訳ではないため、図3では、ユーザU3は、端末装置10のカメラアプリを起動することにより、撮像部13によって取り込まれた実空間の映像の映像であって、表示画面Dに表示された映像を見ながら、候補位置CP1の位置を探る、という作業を行っている。
まず、図3(a)は、ユーザU3およびユーザU3の周辺環境を上空から見た図である。端末装置10には撮像部13が内蔵されている。言い換えれば、撮像部13は、端末装置10の本体と一体化されている。したがって、ユーザU3によって端末装置10が向けられた方向が撮像部13が撮影を行う撮影方向に対応する。なお、本実施形態では、端末装置10の撮影方向とは、撮像部13が撮影を行う方角(東西南北の方角)、あるいは、撮像部13が向けられている方角(東西南北の方角)といった意味を含み得るものとする。また、図3(a)の例では、現在における端末装置10の撮影方向を撮影方向PD1とする。具体的には、撮影方向PD1は、端末装置10が向けられている正面方向である。より具体的には、撮影方向PD1は、端末装置10の上端が向けられている正面方向である。
撮影方向PD1には、女性である人物NPがおり、人物NPの後ろには、図1のMAP1に示す迂回ルートRT20が通っている。また、迂回ルートRT20には、候補位置CP1が存在する。
次に、図3(b)は、現在における端末装置10の傾きを示す図である。本実施形態では、端末装置10の傾きは、地面に対する端末装置10の角度として定義する。図3(b)では、端末装置10を横から眺めており、水平の地面に対して90度の角度で端末装置10は傾けられている。
以上、図3(a)および図3(b)の図から、ユーザU3は、地面に対して90度の角度で端末装置10を傾けて、かつ、端末装置10を撮影方向PD1の方向に向けた状態で所持している。つまり、撮像部13は、端末装置10が地面に対して90度の角度に傾けられ、かつ、端末装置10が撮影方向PD1の方向に向けられた際に(レンズによって)取得可能となった実空間の映像を表示画面Dに表示することになる。簡単に言うと、図3(a)および図3(b)の例から、ユーザU3は、端末装置10を用いて、自身の正面の様子を表示画面Dに表示させている。
ここで、図3(a)によると、現在、ユーザU3の正面には、人物NPがいるため、ユーザU3は端末装置10を用いて仮想バス停の位置を確認したいだけであるのに、人物NPからは自身が無断撮影されているのではないかと誤解されてしまう可能性がある。また、周囲に人が居た場合、その人からもユーザU3は人物NPを無断撮影しているのではないかと誤解されてしまう可能性がある。そこで、端末装置10は、実施形態にかかる表示制御プログラムの制御に従って、以下の処理を実行する。
端末装置10は、自装置の撮影方向と傾きとを常時、検知している。撮影方向と傾きの定義については上で説明済みであるが、端末装置10は、撮影方向として端末装置10が有する撮像部13が向けられている方向と、傾きとして地面に対する端末装置10の角度に対応する傾きとを検知する。図3(a)および図3(b)の例では、端末装置10は、撮影方向が撮影方向PD1であることと、傾きが90度であることを検知する。
そして、端末装置10は、傾きが90度であることを検知すると、これまで表示画面Dに表示されていた撮影方向PD1の映像を非表示とする。
ここで、傾きが90度であるということは、人物NPから見ると、いかにも自身が撮影されているかのごとく見えてしまう。しかしながら、ユーザU3にとっても、傾きを90度程度にしないと、撮影方向PD1すなわち正面の映像を表示画面Dに表示させることができない。そして、撮影方向PD1の映像を表示画面Dに表示させることができないということは、すなわち、前方のどこかに存在するはずの候補位置CP1を含む実空間の映像を表示画面Dに表示させることができないことを意味する。例えば、図3(c)に示すように、地面に対する端末装置10の角度を30度あるいはそれ以下程度にした場合、人物NPから見ると、自身が撮影されているようには見えないかもしれない。だが、表示画面Dにはほぼ地面の様子しか表示されず、候補位置CP1を探したいユーザU3にとっては都合が悪い。
図3(c)に示すように、地面に対する端末装置10の角度を30度あるいはそれ以下程度にした状態でも、撮影方向PD1の映像を表示画面Dに表示させることができれば、ユーザU3は、誤解されることなく候補位置CP1を探すことができる。
このようなことから、端末装置10は、傾きとして地面に対する端末装置10の角度が30度以下となった場合には、端末装置10に撮影方向PD1に関する情報を表示させる。この点について、図3(c)を用いて説明する。ユーザU3は、図3(b)に示すように、撮影方向PD1の映像が非表示とされたことで、端末装置10の傾きを90度から下げてゆく。この間も端末装置10は、自装置の傾きを検知している。そして、端末装置10は、自装置の角度が30度以下となったことを検知すると、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像を表示する。このとき端末装置10は、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像をそのまま表示するのではなく、かかる映像に対応する3D仮想現実画像である画像VG1を表示する。より具体的には、端末装置10は、表示画面Dの上半分の領域RE1に画像VG1を表示する。
また、端末装置10は、自装置の角度が30度以下となったことを検知すると、撮像部13によって取り込まれた現在の実空間の映像であって、撮影方向PD1と角度が30に対応する映像である映像RG1を表示する。具体的には、端末装置10は、表示画面Dの下半分の領域RE2に映像RG1を表示する。
以上まとめると、端末装置10は、自装置の角度が30度以下となったことを検知すると、表示画面Dの上半分に、撮影方向PD1の景色を示す3D仮想現実画像である画像VG1を表示させ、表示画面Dの下半分に、撮影方向PD1と角度が30に対応する方向の景色をそのまま表示させる。このようなことから、ユーザU3は、端末装置10の傾きを角度90度にせずとも、撮影方向PD1の景色を表示画面Dの上半分に表示させることができるため、無断撮影と誤解されることなく候補位置CP1を探すことができる。このようなことから、実施形態にかかる表示制御プログラムは、端末装置10を用いた無断撮影に伴う社会的不安を解消することができる。
なお、図3を用いて、端末装置10が、表示制御プログラムの制御に従って、自装置の方の傾きが所定の角度以下となった場合には、画面上半分に撮影方向の景色に対応する仮想現実画像を、画面下半分に現在の方向のリアル映像を表示させる例を示した。しかし、端末装置10は、撮像部13によって取り込まれた映像であって、撮像部13が向けられている方角の映像の中に人物が存在する場合には、現在の映像を非表示とする。そして、端末装置10は、撮像部13により取り込まれた映像の中に人物が存在しなくなるまで、端末装置10の姿勢を変えるようユーザU3に指示する。そして、端末装置10は、自装置の姿勢が変えられたことにより、撮像部13により取り込まれた映像の中に人物が存在しなくなった場合には、図3(c)と同様の表示制御を行う。
具体的には、端末装置10は、撮像部13により取り込まれた映像の中に人物が存在しなくなった場合には、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像を表示する。つまり、端末装置10は、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像に対応する3D仮想現実画像である画像VG1を画面上半分に表示させる。また、端末装置10は、撮像部13によって取り込まれた現在の実空間の映像である映像RG1を画面下半分に表示させる。
例えば、図3(b)に示すように90度の角度で端末装置10をユーザU3が持っていた場合、撮像部13によって取り込まれた映像の中には人物が入ってしまうことが多くなる。このような場合、ユーザU3は、映像の中に人物が入らないよう、例えば、図3(c)のように端末装置10の姿勢を変える場合がある。しかしこのような姿勢にした場合、ユーザU3は、正面方向に存在し得る仮想バス停の位置を確認することができなくなってしまう。
このため、端末装置10は、例えば、90度の角度で端末装置10をユーザU3が持っていることにより、撮像部13により取り込まれた映像の中に人物が存在する場合には、人物が存在しなくなるまで、端末装置10の姿勢を変えるようユーザU3に指示する。そして、例えば、図3(c)のように端末装置10の姿勢を変えたことにより映像の中に人物が存在しなくなった場合であっても、端末装置10は、撮影方向PD1の景色をに対応する仮想現実画像を表示画面Dの上半分に表示させる。
これにより、ユーザU3は、無断撮影と誤解されることなく候補位置CP1を探すことができる。したがって、実施形態にかかる表示制御プログラムは、端末装置10を用いた無断撮影に伴う社会的不安を解消することができる。
〔4.システムの構成〕
次に、図4を用いて、実施形態にかかるシステムの構成について説明する。図4は、実施形態にかかるシステム1の構成例を示す図である。実施形態にかかるシステム1は、図4に示すように、端末装置10と、移動体制御装置30と、情報処理装置100とを含む。また、端末装置10、移動体制御装置30、情報処理装置100は、ネットワークNを介して有線または無線により通信可能に接続される。
情報処理装置100は、図1で説明した第1の提示処理、および、図2で説明した第2の提示処理を行うサーバ装置である。そして、実施形態にかかるシステム1には、複数台の情報処理装置100が含まれてよい。
端末装置10は、実施形態にかかる表示制御プログラムに従い、図3で説明した表示制御処理を行うユーザ端末である。そして、実施形態にかかるシステム1には、複数台の端末装置10が含まれてよい。
また、移動体制御装置30は、各移動体に搭載されるが、各移動体に搭載される数は限定されない。
〔5.情報処理装置の構成〕
次に、図5を用いて、実施形態にかかる情報処理装置100について説明する。図5は、実施形態にかかる情報処理装置100の構成例を示す図である。図5に示すように、情報処理装置100は、通信部110と、記憶部120と、制御部130とを有する。
(通信部110について)
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。そして、通信部110は、ネットワークNと有線または無線で接続され、例えば、端末装置10や移動体制御装置30との間で情報の送受信を行う。
(記憶部120について)
記憶部120は、例えば、RAM(Random Access Memory)、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部120は、候補位置情報記憶部121と、移動体情報記憶部122と、登録情報記憶部123と、位置−経路情報記憶部124とを有する。
(候補位置情報記憶部121について)
図1では、仮想バス停が設置される設置位置の候補(候補位置)をユーザに提示することにより、候補位置の中からオンデマンドバスに乗車を希望する位置、すなわち乗車希望位置をユーザに指定させる例を示した。候補位置情報記憶部121は、この例に対応する記憶部である。すなわち、候補位置情報記憶部121は、候補位置に関する情報を記憶する。ここで、図6に実施形態にかかる候補位置情報記憶部121の一例を示す。図6の例では、候補位置情報記憶部121は、「バス停ID」、「位置情報」といった項目を有する。
「バス停ID」は、候補位置を識別する識別情報を示す。「位置情報」は、「バス停ID」によって識別される候補位置の位置を示す。例えば、「位置情報」は、経緯度に基づく座標によって示される。
すなわち、図6の例では、バス停ID「CP1」によって識別される候補位置(候補位置CP1)は、位置情報「X1、Y1」によって示される位置にあることを示す。
(移動体情報記憶部122)
移動体情報記憶部122は、ユーザによって指定された(乗車の意思表示が行われた)乗車希望位置や、ユーザをオンデマンドバスに乗車させる乗車順や、オンデマンドバスの空席状況等を記憶する。ここで、図7に実施形態にかかる移動体情報記憶部122の一例を示す。図7の例では、移動体情報記憶部122は、「バスID」、「ユーザID」、「乗車希望位置(バス停ID)」、「設置位置」、「到着予定時刻」、「予定人数」、「空席情報」、「乗車順」といった項目を有する。
「バスID」は、移動体であるオンデマンドバスを識別する識別情報を示す。「ユーザID」は、「バスID」によって識別されるオンデマンドバスに乗車予定の意思表示を行ったユーザを識別する識別情報を示す。「乗車希望位置(バス停ID)」は、図5の「バス停ID」によって識別される候補位置のうち、ユーザに指定された候補位置であって、「バスID」によって識別されるオンデマンドバスにユーザが乗車を希望する位置を示す。このようなことから、「乗車希望位置(バス停ID)」には、図5の「バス停ID」のいずれかが入力される。「設置位置」は、「乗車希望位置(バス停ID)」を示す位置情報であって、仮想バス停が設置される設置位置を示す。
「到着予定時刻」は、「バスID」によって識別されるオンデマンドバスが、対応する「乗車希望位置(バス停ID)」に到着する到着予定時刻を示す。「予定人数」は、「乗車希望位置(バス停ID)」からオンデマンドバスに乗車予定のユーザの人数を示す。具体的には、「予定人数」は、対応する「乗車希望位置(バス停ID)」に、対応する「到着予定時刻」に到着予定のオンデマンドバスに乗車予定のユーザの人数を示す。
「空席情報」は、対応する「乗車希望位置(バス停ID)」に、対応する「到着予定時刻」に到着予定のオンデマンドバスにおける現在の空席の数を示す。「乗車順」は、「バスID」によって識別されるオンデマンドバスにユーザを乗車させる乗車順を示す。
すなわち、図7の例では、ユーザID「U1」によって識別されるユーザ(ユーザU1)が、候補位置CP1を乗車希望位置と指定する旨の乗車意思表示を行った例を示し、また、候補位置CP1の位置は座標「X1、Y1」である例を示す。また、図7の例では、バスID「BT1」によって識別されるオンデマンドバス(バスB1)は、候補位置CP1に「2018年7月1日10時5分」に到着予定のバスである例を示す。
また、図7の例では、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1に、乗車予定のユーザはユーザU1、U2、U3の「3人」であるとともに、現在の空席は「3席」である例を示す。また、図7の例では、乗車予定ユーザU1に対し、候補位置CP1からバスB1に乗車する際の乗車順は「1」であることが決定された例を示す。また、図7の例では、乗車予定ユーザU2に対し、候補位置CP1からバスB1に乗車する際の乗車順は「3」であることが決定された例を示す。また、図7の例では、乗車予定ユーザU3に対し、候補位置CP1からバスB1に乗車する際の乗車順は「2」であることが決定された例を示す。
(登録情報記憶部123について)
図2では、情報処理装置100は、オンデマンドバスに乗車する乗車希望地点の位置情報(乗車希望位置)、または、オンデマンドバスから降車する降車希望地点の位置情報(降車希望位置」)をユーザに指定させる例を示した。登録情報記憶部123は、この例に対応する記憶部である。すなわち、登録情報記憶部123は、乗車希望位置および降車希望位置に関する情報を記憶する。ここで、図8に実施形態にかかる登録情報記憶部123の一例を示す。図8の例では、登録情報記憶部123は、「ユーザID」、「乗車希望位置」、「降車希望位置」、「隠蔽設定」といった項目を有する。
「ユーザID」は、乗車希望地点の位置、または、降車希望地点の位置を指定したユーザを識別する識別情報を示す。「乗車希望位置」は、ユーザによって指定された「乗車希望位置」を識別する識別情報を示す。なお、「乗車希望位置」には、ユーザによって指定された「乗車希望位置」の位置を示す位置情報がさらに含まれてもよい。「降車希望位置」は、ユーザによって指定された「降車希望位置」を識別する識別情報を示す。なお、「降車希望位置」には、ユーザによって指定された「降車希望位置」の位置を示す位置情報がさらに含まれてもよい。「隠蔽設定」は、乗車希望地点、または、降車希望地点を隠蔽したい場合に設定される情報を示す。
すなわち、図8の例では、ユーザID「U4」によって識別されるユーザ(ユーザU4)が、乗車希望地点として乗車希望地点CP3の位置、および、降車希望地点として降車希望地点HP1(図2の「自宅HP1」に対応)の位置を指定した例を示す。また、図8の例では、ユーザU3が乗車希望地点、および、降車希望地点を隠蔽するよう隠蔽設定した例を示す。
(位置−経路情報記憶部124について)
位置−経路情報記憶部124は、乗車位置、降車位置および移動ルートに関する情報を記憶する。ここで、図9に実施形態にかかる位置−経路情報記憶部124の一例を示す。図9の例では、位置−経路情報記憶部124は、「ユーザID」、「乗車希望位置」、「降車希望位置」、「決定位置」、「対象ルート」といった項目を有する。
「ユーザID」は、乗車希望地点の位置、または、降車希望地点の位置を指定したユーザを識別する識別情報を示す。「乗車希望位置」は、図8と同様に、ーザによって指定された「乗車希望位置」を識別する識別情報を示す。「降車希望位置」は、図8と同様に、ユーザによって指定された「降車希望位置」を識別する識別情報を示す。
「決定位置」、具体的には、「乗車希望位置」に対応付けられる「決定位置」は、オンデマンドバスに乗車させるための乗車地点の位置である乗車位置であって、乗車希望地点がオンデマンドバスの乗客によって特定されないような位置を示す。また、「降車希望位置」に対応付けられる「決定位置」は、オンデマンドバスから降車させるための降車地点の位置である乗車位置であって、降車希望地点がオンデマンドバスの乗客によって特定されないような位置を示す。
「対象ルート」は、具体的には、「乗車希望位置」に対応付けられる「対象ルート」は、乗車希望地点から「決定位置」(乗車位置)までの移動ルートを示す。また、「降車希望位置」に対応付けられる「対象ルート」は、「決定位置」(降車位置)から降車位置までの移動ルートを示す。
すなわち、図9の例では、ユーザU4が、降車希望地点HP1の位置を指定したとに応じて、位置XP11が降車位置として決定され、移動ルートRT41が位置XP11から降車希望地点HP1までの対象ルートとして決定された例を示す。
(制御部130について)
図5に戻り、制御部130は、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、情報処理装置100内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部130は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
図5に示すように、制御部130は、地点情報取得部131a、更新部131b、空席情報取得部131c、乗車順決定部131d、第1提示部131e、検知部131f、表示制御部131g、登録情報受付部132a、乗降位置決定部132b、ルート決定部132c、第2提示部132dとを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部130の内部構成は、図5に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部130が有する各処理部の接続関係は、図5に示した接続関係に限られず、他の接続関係であってもよい。
(地点情報取得部131aについて)
地点情報取得部131aは、ユーザが移動体に対して所定の行動を行う地点であって、仮想的な地点である仮想地点に関する情報である仮想地点情報を取得する。具体的には、地点情報取得部131aは、仮想地点情報として、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点に関する情報である仮想乗車地点情報を取得する。例えば、地点情報取得部131aは、仮想乗車地点情報として、仮想乗車地点が設置される設置位置を示す設置位置情報を取得する。また、地点情報取得部131aは、仮想乗車地点情報として、仮想乗車地点から移動体に乗車予定の意思表示を行ったユーザを示すユーザ情報を取得する。
図1では、ユーザU1が候補位置CP1〜CP3のうち、候補位置CP1に対応するアイコンF1を選択することにより、候補位置CP1にてオンデマンドバスへ乗車したい旨の意思表示を行っている。これにより、地点情報取得部131aは、乗車希望位置を候補位置CP1とする指定をユーザU1から受け付ける。すなわち、地点情報取得部131aは、候補位置CP1からオンデマンドバスに乗車予定の意思表示を行ったユーザがユーザU1であることを示すユーザ情報として、ユーザID「U1」を取得する。なた、図1の例では、ユーザU2およびU3も同様に、候補位置CP1にてオンデマンドバスへ乗車したい旨の意思表示を行っている。したがって、地点情報取得部131aは、ユーザID「U2」および「U3」も取得する。
また、地点情報取得部131aは、仮想乗車地点が設置される設置位置を決定することにより、この設置位置を示す設置位置情報を取得することができる。図1の例では、候補位置CP1にてオンデマンドバスへ乗車したい旨の意思表示を初めにユーザU1が行ったことにより、地点情報取得部131aは、候補位置CP1を設置位置として決定する。また、地点情報取得部131aは、このようにして取得した各情報を移動体情報記憶部122に格納する。
なお、設置位置を決定する処理は、地点情報取得部131a以外の処理部(例えば、設置位置決定部)によって行われてもよい。また、地点情報取得部131aは、候補位置の中から乗車希望位置を指定させるために、ページP1aを端末装置10に表示させることもできる。しかしながら、情報処理装置100は、例えば、ページP1aを端末装置10に配信する配信部を有してもよい。
(更新部131bについて)
更新部131bは、移動体に乗車予定のユーザの人数を更新する。例えば、更新部131bは、特定の移動体毎に、当該移動体の乗車予定のユーザの人数を更新する。例えば、更新部131bは、移動体情報更新部122にアクセスし「予定人数」に入力される数値を更新する。
図1の例では、更新部131bは、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザの人数を更新する。ユーザU1が意思表示を行った時点では、更新部131bは、ユーザ人数を「0」から「1」へと更新する。また、ユーザU2がさらに意思表示を行った時点では、更新部131bは、ユーザ人数を「1」から「2」へと更新する。そして、ユーザU3が意思表示を行った時点では、更新部131bは、ユーザ人数を「2」から「3」へと更新する。
(空席情報取得部131cについて)
空席情報取得部131cは、移動体における空席状況を示す空席情報を取得する。具体的には、空席情報取得部131cは、移動体として、仮想の乗車地点である仮想乗車地点から乗車される移動体における空席状況を示す空席情報を取得する。例えば、空席情報取得部131cは、空席情報として、移動体が有する空席の数を示す空席情報を取得する。また、空席情報取得部131cは、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点から移動体に乗車予定のユーザが、仮想乗車地点に到着した順番である到着順をさらに取得する。
図1の例では、空席情報取得部131cは、提示処理1−2に対応する情報提示を行うタイミングであるか否かを判定する。言い換えれば、空席情報取得部131cは、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1における現在の空席状況を示す空席情報を取得するタイミング(例えば、候補位置CP1にバスB1が到着するまでの残り時間が3分を切ったタイミング)であるか否かを判定し、空席情報を取得するタイミングであると判定した場合には、空席情報を取得する。また、空席情報取得部131cは、例えば、ユーザU1〜U3それぞれの現在位置を示す位置情報を取得(監視)しておくことで、候補位置CP1に到着した到着順を取得する。
なお、空席情報取得部131cは、移動体に乗車予定のユーザの属性を示す属性情報をさらに取得することもできる。
(乗車順決定部131dについて)
乗車順決定部131dは、空席情報取得部131cにより取得された空席情報に基づいて、移動体に乗車予定のユーザを移動体に乗車させる順番を決定する。具体的には、乗車順決定部131dは、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点のうち、共通の仮想乗車地点において一の時刻に到着する共通の移動体に乗車予定のユーザを当該移動体に乗車させる順番を決定する。また、乗車順決定部131dは、移動体に乗車予定のユーザのうち、到着順が早いユーザほど前記移動体に早く乗車させるよう順番を決定する。
図1の例では、乗車順決定部131dは、空席情報取得部131cにより取得された空席情報に基づいて、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1に乗車予定のユーザについて、かかるバスB1に乗車させる順番(乗車順)を決定する。つまり、乗車順決定部131dは、ユーザU1〜U3それぞれに対して、バスB1に乗車させる乗車順を決定する。
図1の例では、空席情報取得部131cが、ユーザU1の到着順「1」、ユーザU2の到着順「3」、ユーザU3の到着順「2」を取得したとする。かかる場合、乗車順決定部131dは、ユーザU1に対して乗車順「1」を決定し、ユーザU2に対して乗車順「3」を決定し、ユーザU3に対して乗車順「2」を決定する。
なお、乗車順決定部131dは、属性情報に基づいて、移動体に乗車予定のユーザを移動体に乗車させる順番を決定することもできる。具体的には、乗車順決定部131dは、空席情報取得部131cにより取得された属性情報に基づいて、移動体に乗車予定のユーザを移動体に乗車させる順番を決定する。例えば、乗車順決定部131dは、属性情報として、年齢、身体障害または乳幼児の有無を示す属性情報に基づいて、移動体に乗車予定のユーザを移動体に乗車させる順番を決定する。例えば、乗車順決定部131dは、ユーザU1〜U3の中に身体的に障害を有するユーザが居れば、そのユーザについては到着順を無視し優先的に早い乗車順を決定する。
(第1提示部131eについて)
第1提示部131eは、図1で説明した第1の提示処理に対応する処理部である。具体的には、第1提示部131eは、第1の提示処理として、提示処理1−1および提示処理1−2を行う。
まず、第1提示部131eによって行われる提示処理1−1について説明する。第1提示部131eは、地点情報取得部131aにより取得された仮想地点情報に基づいて、ユーザ以外のユーザであって、仮想地点を利用するユーザである他ユーザに関する情報をユーザに提示する。具体的には、第1提示部131eは、地点情報取得部131aにより取得された仮想乗車地点情報に基づいて、他ユーザとして、仮想乗車地点を利用するユーザである他ユーザに関する情報をユーザに提示する。
例えば、第1提示部131eは、ユーザによって仮想乗車地点から移動体に乗車予定の意思表示が行われた場合に、他ユーザに関する情報として、ユーザによる意思表示の対象となった仮想乗車地点から移動体に乗車予定の他ユーザの有無を示す情報を提示する。例えば、第1提示部131eは、他ユーザに関する情報として、仮想乗車地点から移動体に乗車予定の他ユーザの有無を示す情報を提示する。
また、第1提示部131eは、ユーザによって仮想乗車地点から移動体に乗車予定の意思表示が行われた場合に、他ユーザに関する情報として、ユーザによる意思表示の対象となった仮想乗車地点から移動体に乗車予定の他ユーザの有無を示す情報を提示する。また、第1提示部131eは、ユーザによる意思表示の対象となった仮想乗車地点に移動体が到着する到着予定時刻までの残り時間が所定時間以下となった場合に、他ユーザの有無を示す情報を提示する。
図1の例では、第1提示部131eは、情報提示を行うタイミング(例えば、候補位置CP1にバスB1が到着するまでの残り時間が5分を切ったタイミング)であると判定した場合には、ユーザU3以外のユーザであって、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザ、すなわちユーザU1およびU2に関する情報をユーザU3に提示する。例えば、第1提示部131eは、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザが居るかいないか(有無)をユーザU3に提示する。
図1の例では、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザとして、ユーザU1およびU2がいる。かかる場合、第1提示部131eは、ユーザU3以外に乗車予定のユーザが居る旨をユーザU3に提示する。例えば、第1提示部131eは、図1(b)に示すように、ユーザU3以外に乗車予定のユーザが居る旨を示す情報J1を含むページP1bを表示させる。
次に、第1提示部131eによって行われる提示処理1−2について説明する。第1提示部131eは、乗車順決定部131dにより決定された乗車順をユーザに提示する。例えば、第1提示部131eは、移動体と、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点との位置関係に関する情報が所定の条件情報を満たす場合に、乗車順決定部131dにより決定された乗車順をユーザに提示する。例えば、第1提示部131eは、前記所定の条件情報を満たす場合として、移動体が仮想乗車地点に到着するまでの残り時間が所定の時間より短くなった場合に、乗車順決定部131dにより決定された乗車順をユーザに提示する。
図1の例では、第1提示部131eは、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1と候補位置CP1との位置関係として、候補位置CP1にバスB1が到着するまでの残り時間が3分という位置関係となったか否かを判定する。そして、第1提示部131eは、かかる位置関係になったと判定した場合には、ユーザU1〜U3それぞれに対して、乗車順を提示する。ユーザU3を例に挙げると、第1提示部131eは、図1(c)に示すように、ユーザU3の乗車順は「3」であることを示す情報J2を含むページP1cをユーザU3の端末装置10に表示させる。
また、第1提示部131eは、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点との位置関係に関する情報が所定の条件情報を満たす場合として、移動体の現在位置から仮想乗車地点が設置される設置位置までの距離が所定距離より短くなった場合に、乗車順決定部131dにより決定された順番をユーザに提示してもよい。
(検知部131fについて)
検知部131fは、乗車順決定部131dにより決定された乗車順でユーザが移動体に乗車したか否かを検知する検知部をさらに有する。具体的には、検知部131fは、乗車順決定部131dにより決定された乗車順で移動体に乗車しないユーザがいることを検知した場合には、当該ユーザに対して決定された乗車順で乗車するよう当該ユーザに警告が行われるよう制御する。例えば、検知部131fは、乗車順決定部131dにより決定された乗車順で移動体に乗車しないユーザがいることを検知した場合には、当該ユーザに対して決定された乗車順で乗車するよう当該ユーザに警告する警告音を、当該ユーザの端末装置または移動体が出力するよう制御する。
図1の例では、乗車順決定部131dは、ユーザU1に対して乗車順「1」を決定し、ユーザU2に対して乗車順「3」を決定し、ユーザU3に対して乗車順「2」を決定してる。そして、第1提示部131eは、ユーザU1には乗車順「1」を提示し、ユーザU2には乗車順「3」を提示し、ユーザU3には乗車順「2」を提示する。
このような状態において、バスB1の移動体制御装置30は、バスB1内のセンサ(例えば、カメラや赤外線センサ)によって検出された検出情報であって、例えば、乗車順に関する検出情報をセンサから取得する。かかる情報は、例えば、乗車口の人の様子が撮影された画像あるいは動画データである。そして、移動体制御装置30は、取得した検出情報を情報処理装置100に送信する。
検知部131fは、移動体制御装置30から検出情報を取得すると、検出情報を解析し、乗車順決定部131dにより決定された乗車順でユーザがバスB1に乗車したか否かを検知(判定)する。ユーザU3の正しい乗車順は「2」であるのに、検知部131fは、ユーザU3が乗車順は「1」でバスB1に乗車したことを検知したとする。かかる場合、検知部131fは、移動体制御装置30に対して、ユーザU3に向けて警告音を出力するよう制御する。あるいは、検知部131fは、ユーザU3の端末装置10に対して、ユーザU3を正しい乗車順で乗車させるための警告を出力するよう制御する。かかる場合、端末装置10は、警告音を出力してもよいし、音声付で警告文を表示してもよい。つまり、端末装置10がどのように警告するかは限定されない。
(表示制御部131gについて)
表示制御部131gは、仮想地点の位置を示す情報をユーザの端末装置10に表示させる。例えば、表示制御部131gは、仮想乗車地点の設置位置を示す情報をユーザの端末装置10に表示させる。例えば、表示制御部131gは、端末装置10の撮像部13によって表示される映像の中に設置位置が含まれる場合には、当該設置位置において、映像に対して仮想乗車地点を示す画像が重畳して表示されるよう制御する。
図の例では、表示制御部131gは、端末装置10の撮像部13(カメラ)によって取り込まれる実空間の中に、図1で説明した候補位置CP1が存在する場合に、この実空間の映像に対して、仮想バス停の形状をした3D仮想現実画像が重畳して表示されるよう制御する。これにより、図1の例では、ユーザU1〜U3は、物理目標が存在しない候補位置CP1の所在を、端末装置10の映像を基に探ることができるようになる。
(登録情報受付部132aについて)
登録情報受付部132aは、図2で説明した第2の提示処理に対応する処理部である。登録情報受付部132aは、ユーザから移動体に関する各種情報登録を受け付ける。特に、図2の例において、登録情報受付部132aは、ユーザが移動体に乗車する乗車地点に関する情報である乗車地点情報、または、ユーザが移動体から降車する降車地点に関する情報を受け付ける。
図2の例では、登録情報受付部132aは、乗車希望位置または降車希望位置の指定をユーザU4から受け付ける。例えば、登録情報受付部132aは、ユーザU4からのアクセスに応じて、乗車希望位置または降車希望位置を入力させるページP2aを配信することで、乗車希望位置または降車希望位置の指定をユーザU4から受け付ける。
(乗降位置決定部132bについて)
乗降位置決定部132bは、ユーザが移動体に乗車する乗車地点に関する情報である乗車地点情報、または、ユーザが前記移動体から降車する降車地点に関する情報である降車地点情報に基づいて、移動体の利用に関する位置を決定する。
例えば、乗降位置決定部132bは、移動体の利用に関する位置として、ユーザを移動体に乗車させるための乗車地点の位置である乗車位置を決定する。例えば、乗降位置決定部132bは、ユーザが移動体への乗車を希望する地点である乗車希望地点であってユーザにより指定された乗車希望地点が移動体の乗客によって特定されないような位置を乗車位置として決定する。一例を示すと、乗降位置決定部132bは、乗車希望地点と、移動体が走行する走行ルートとの位置関係に基づいて、乗車希望地点が移動体の乗客によって特定されないような位置を乗車位置として決定する。すなわち、乗降位置決定部132bは、乗車希望地点から所定範囲内のエリアにおいて、乗車希望地点が移動体の乗客によって特定されないような位置として、移動体の乗客からは乗車希望地点が死角となる位置を乗車位置として決定する。
また、例えば、乗降位置決定部132bは、移動体の利用に関する位置として、ユーザが移動体から降車するための降車地点の位置である降車位置を決定する。例えば、乗降位置決定部132bは、ユーザが移動体からの降車を希望する地点である降車希望地点であってユーザにより指定された降車希望地点が移動体の乗客によって特定されないような位置を前記降車位置として決定する。例えば、乗降位置決定部132bは、降車希望地点と、移動体が走行する走行ルートとの位置関係に基づいて、降車希望地点が移動体の乗客によって特定されないような位置を降車位置として決定する。すなわち、乗降位置決定部132bは、降車希望地点から所定範囲内のエリアにおいて、降車希望地点が前記移動体の乗客によって特定されないような位置として、移動体の乗客からは前記降車希望地点が死角となる位置を前記降車位置として決定する。
図2の例では、乗降位置決定部132bは、自宅HP1方面に向かうバスと、自宅HP1へ向う走行ルートとを特定する。例えば、乗降位置決定部132bは、自宅HP1方面に向かうバスとしてバスB2を特定し、自宅HP1へ向う走行ルートとして走行ルートRT30を特定したとする。このような状態において、乗降位置決定部132bは、自宅HP1から所定範囲内のエリアであるエリアAR1において、自宅HP1がバスB2の乗客によって特定されないような位置として、バスB2の乗客からは自宅HP1が死角となる位置を降車位置として決定する。例えば、乗降位置決定部132bは、自宅HP1の前の通りの走行ルートRT30を直進し、走行ルート30を左へ曲った先の位置XP11を降車位置として決定する。
(ルート決定部132cについて)
ルート決定部132cは、ユーザが移動体への乗車を希望する地点である乗車希望地点、および、ユーザを移動体に乗車させるための乗車地点の位置である乗車位置との間の所定エリアの周辺環境を示す環境情報に基づいて、移動体の利用に関する位置として、乗車希望地点から乗車位置までのユーザの移動ルートを決定する。また、ルート決定部132cは、ユーザが移動体からの降車を希望する地点である降車希望地点、および、ユーザが移動体から降車するための降車地点の位置である降車位置との間の所定エリアの周辺環境を示す環境情報に基づいて、移動体の利用に関する位置として、降車位置から降車希望地点までのユーザの移動ルートを決定する。
例えば、ルート決定部132cは、環境情報として、所定エリアを移動するうえでの安全性を評価する項目に基づいて、移動ルートを決定する。具体的には、ルート決定部132cは、項目として、街灯の有無、交通量、所定の施設の数、犯罪件数、または、事故件数のうちの少なくとも1つに基づいて、移動ルートを決定する。例えば、ルート決定部132cは、項目に基づき算出されたスコアであって、所定エリアを移動するうえでの安全性を評価する評価値である安全性スコアに基づいて、移動ルートを決定する。
図2の例では、ルート決定部132cは、自宅HP1および降車位置である位置XP11との間のエリアAR1内において、位置XP11から自宅HP1までの移動ルートの候補(候補ルート)を特定する。図2の例では、ルート決定部132cは、例えば、移動ルートRT41、移動ルートRT42および移動ルートRT43といった3つの候補ルートを特定する。
次に、ルート決定部132cは、候補ルート毎に、街灯の有無、交通量、店舗の数、犯罪件数、事故件数といった各項目についてスコアを算出することで、候補ルートの安全性を示す安全性スコアを算出する。スコア算出例については、図2で説明した例の通りであるため、ここでは省略する。図2の例では、ルート決定部132cは、移動ルートRT41について安全性スコア「1」を算出する。また、ルート決定部132cは、移動ルートRT42について安全性スコア「−3」を算出する。また、ルート決定部132cは、移動ルートRT43について安全性スコア「0」を算出する。
安全性スコアが高い移動ルートほど、防犯や治安面でより安全といえる。このため、ルート決定部132cは、安全性スコアが「1」で最も高い移動ルートRT41を提示対象の移動ルートとして決定する。なお、ルートを決定する処理は、乗降位置決定部132bにより行われてもよい。
(第2提示部132dについて)
第2提示部132dは、乗降位置決定部132bにより決定された乗車位置をユーザに提示する。また、第2提示部132dは、乗降位置決定部132bにより決定された降車位置をユーザに提示する。また、第2提示部132dは、ルート決定部132cにより決定された移動ルートをユーザに提示する。
図2の例では、第2提示部132dは、降車位置である位置XP11と、移動ルートRT41とをユーザU4に提示する。例えば、第2提示部132dは、図2(b)に示すように、降車位置が位置XP11であることと、位置XP11から自宅HP1へは移動ルートRT41が安全であることを示す情報J3を含むページP2bをユーザU4の端末装置10に表示させる。
〔6.端末装置の構成〕
次に、図10を用いて、実施形態にかかる端末装置10について説明する。図10は、実施形態にかかる端末装置10の構成例を示す図である。図10に示すように、端末装置10は、通信部11と、表示部12と、撮像部13と、アプリ制御部14を有する。
(通信部11について)
通信部11は、例えば、NIC等によって実現される。そして、通信部11は、ネットワークNと有線または無線で接続され、例えば、移動体制御装置30や情報処理装置100との間で情報の送受信を行う。
(表示部12について)
表示部12は、各種情報を表示する表示デバイスであり、いわゆる表示画面に相当する。例えば、表示部12には、タッチパネルが採用される。また、表示部12は、例えば、撮像部13によってレンズから取り込まれた映像を表示する。本実施形態では、表示部12は表示画面Dに相当するものとする。
(撮像部13について)
撮像部13は、撮像素子を内蔵し、画像や動画を撮像するデバイスである。撮像素子は、CCD(Charge Coupled Device)、COMS(Complementary Metal Oxide Semiconductor)など何れでもよい。例えば、撮像部13は、レンズから取り込んだ映像であって表示部12に現在表示されている映像を静止画像として写真撮影したり、動画撮影することができる。
(アプリ制御部14について)
アプリ制御部14は、CPUやMPU等によって、端末装置10内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、アプリ制御部14は、例えば、ASICやFPGA等の集積回路により実現される。また、アプリ制御部14は、実施形態にかかる表示制御プログラムにより実行される処理部である。
図10に示すように、アプリ制御部14は、検知部14aと、指示部14bと、表示制御部14cとを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、アプリ制御部14の内部構成は、図10に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、アプリ制御部14が有する各処理部の接続関係は、図10に示した接続関係に限られず、他の接続関係であってもよい。
(検知部14aについて)
検知部14aは、端末装置の撮影方向と傾きとを検知する。例えば、検知部14aは、撮影方向として端末装置10が有する撮像部13が向けられている方角と、傾きとして地面に対する端末装置10の角度に対応する傾きとを検知する。図3(a)および図3(b)の例では、検知部14aは、撮影方向が撮影方向PD1であることと、傾きが90度であることを検知する。なお、検知部14aは、例えば、ジャイロセンサ、加速度センサ、地磁気センサ等の各種センサであってよい。
(指示部14bについて)
指示部14bは、前記撮影方向に対応する映像の中に人物が存在する場合には、前記端末装置が有する撮像部により取り込まれた映像の中に人物が存在しなくなるまで、前記端末装置の姿勢を変えるようユーザに指示する指示手順をさらにコンピュータに実行させる。
(表示制御部14cについて)
表示制御部14cは、検知部14aにより検知された傾きが所定の条件情報を満たすと判定された場合には、端末装置10に撮影方向に関する情報を表示させる。例えば、表示制御部14cは、所定の条件情報を満たす場合として、検知部14aにより検知された傾きが所定の角度以下となった場合には、端末装置10に撮影方向に関する情報を表示させる。
また、表示制御部14cは、撮影方向に対応する映像の中に人物が存在する場合には、撮影方向に関する情報を表示させてもよい。例えば、表示制御部14cは、撮影方向に対応する映像として、端末装置10が有する撮像部13により取り込まれた映像であって、撮像部13が向けられている方角の映像の中に人物が存在する場合には、撮影方向に関する情報を表示させる。例えば、表示制御部14cは、指示部14bによる指示に応じて、端末装置10の姿勢が変えられたことにより、撮像部13により取り込まれた映像の中に人物が存在しなくなった場合には、撮影方向に関する情報を表示させる。
また、表示制御部14cは、撮影方向に関する情報として、端末装置10が有する撮像部13によって取り込まれた映像であって、撮影方向の映像を表示させる。例えば、表示制御部14cは、撮影方向の映像に対応する仮想現実画像を表示させる。例えば、表示制御部14cは、撮影方向の映像に対応する仮想現実画像を前記端末装置の表示画面内の所定の領域(例えば、表示画面の上半分領域)に表示させる。また、表示制御部14cは、撮像部13によって現在取り込まれている映像であって、現在の実空間の映像を所定の領域以外の領域(例えば、表示画面の下半分領域)に表示させる。
図3の例では、検知部14aは、撮影方向と傾きとを常時、検知する。図3(a)および図3(b)の例では、検知部14aは、撮影方向が撮影方向PD1であることと、傾きが90度であることを検知する。かかる場合、表示制御部14cは、傾きが90度であることにより、これまで表示画面Dに表示されていた撮影方向PD1の映像を非表示とする。
ここで、ユーザU3は、映像が非表示とされたことで端末装置10の姿勢を変えたとする。例えば、ユーザU3は、端末装置の傾きを30度にしたとする。つまり、検知部14aは、端末装置の傾きが30度となったことを検出したとする。かかる場合、表示制御部14cは、検知部14aにより検知された傾きが条件情報を満たすと判定し、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像に対応する3D仮想現実画像である画像VG1を表示する。具体的には、表示制御部14cは、図3(c)に示すように、表示画面Dの上半分の領域RE1に画像VG1を表示させる。
なお、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像の中に候補位置CP1が含まれる場合には、表示制御部14cは、情報処理装置100の表示制御部131gと連携して、候補位置CP1に仮想バス停を示す画像を表示させる。
また、表示制御部14cは、検知部14aにより検知された傾きが条件情報を満たすと判定し、撮像部13によって取り込まれた現在の実空間の映像であって、撮影方向PD1と角度が30に対応する映像である映像RG1を表示する。具体的には、表示制御部14cは、図3(c)に示すように、表示画面Dの下半分の領域RE2に映像RG1を表示する。
〔7.処理手順(1)〕
(第1の提示処理について)
以下、図11に示すフローチャートを用いて、実施形態にかかる情報制御装置100の各処理部が実行・実現する制御処理の内容について説明する。図11は、実施形態にかかる第1の提示処理の一例を示すフローチャートである。第1の提示処理の一例については、図1を用いて説明した。したがって、ここでは、適宜、図1の例を用いることにする。なお、ここでは、ユーザU1およびU2が、既に候補位置CP1からバスB1に乗車したい旨の意思表示を行っているものとする。
このような状態において、第1提示部131eは、ユーザU3からのアクセスに応じて、候補位置CP1〜CP3の中から乗車希望位置を指定させるためのページP1aを、ユーザU3に提示する(配信する)(ステップS101)。そして、地点情報取得部131aは、乗車希望位置の指定をユーザU3から受け付ける(ステップS102)。ユーザU3は、候補位置CP1を乗車希望位置として指定したとする。かかる場合、地点情報取得部131aは、候補位置CP1からバスB1に乗車予定の意思表示を行ったユーザがユーザU3であることを示すユーザ情報として、ユーザID「U3」を取得する。
次に、更新部131bは、指定された乗車希望位置である候補位置CP1から同一同時刻においてバスB1に乗車予定のユーザの人数を更新する(ステップS103)。図1の例では、更新部131bは、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザの人数を更新する。
次に、第1提示部131eは、乗車希望位置である候補位置CP1にバスB1が到着するまでの残り時間が5分との条件を満たすか否かを判定する(ステップS104)。第1提示部131eは、残り時間が5分より長い場合には(ステップS104;No)、残り時間が5分となるまで待機する。一方、第1提示部131eは、残り時間が5分となった場合には(ステップS104;Yes)、ユーザU3に対して他ユーザの有無を提示する(ステップS105)。具体的には、第1提示部131eは、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザが居るかいないか(有無)をユーザU3に提示する。図1の例では、第1提示部131eは、ユーザU3以外に乗車予定のユーザが居る旨をユーザU3に提示する。
次に、空席情報取得部131cは、候補位置CP1にバスB1が到着するまでの残り時間が3分との条件を満たすか否かを判定する(ステップS106)。空席情報取得部131cは、残り時間が3分より長い場合には(ステップS106;No)、残り時間が3分となるまで待機する。一方、空席情報取得部131cは、残り時間が3分となった場合には(ステップS106;Yes)、バスB1の現在の空席情報と、候補位置CP1への到着順とを取得する(ステップS107)。なお、この時点で、ユーザU1〜U3が候補位置CP1に到着しているとは限らない。かかる場合、空席情報取得部131cは、ユーザU1〜U3の候補位置CP1への到着順を予測してもよい。例えば、空席情報取得部131cは、ユーザU1〜U3それぞれの現在位置から候補位置CP1までの距離を算出し、算出した距離が短い順に到着順を予測する。例えば、空席情報取得部131cは、距離が短いほど早い到着順を予測する。
次に、乗車順決定部131dは、、空席情報取得部131cにより取得された空席情報と乗車順とに基づいて、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1に乗車予定のユーザについて、かかるバスB1に乗車させる順番(乗車順)を決定する(ステップS108)。図1の例では、、乗車順決定部131dは、ユーザU1に対して乗車順「1」を決定し、ユーザU2に対して乗車順「3」を決定し、ユーザU3に対して乗車順「2」を決定する。
そして、第1提示部131eは、ユーザU1〜U3それぞれに対して、乗車順決定部131dにより決定された乗車順を提示する(ステップS109)。ユーザU3を例に挙げると、第1提示部131eは、図1(c)に示すように、ユーザU3の乗車順は「3」であることを示す情報J2を含むページP1cをユーザU3に提示する。
(第2の提示処理について)
図12は、実施形態にかかる第2の提示処理の一例を示すフローチャートである。第2の提示処理の一例については、図2を用いて説明した。したがって、ここでは、適宜、図2の例を用いることにする。また、ここでは、提示対象のユーザをユーザU4として説明する。
登録情報受付部132aは、乗車希望位置または降車希望位置の指定をユーザU4から受け付ける(ステップS201)。例えば、登録情報受付部132aは、ユーザU4からのアクセスに応じて、乗車希望位置または降車希望位置を入力させるページP2aを配信することで、乗車希望位置または降車希望位置の指定をユーザU4から受け付ける。図2の通り、登録情報受付部132aは、降車希望位置の指定として、降車希望地点である自宅HP1の位置の指定をユーザU4から受け付けたものとする。
次に、乗降位置決定部132bは、自宅HP1方面に向かうバスと、自宅HP1へ向う走行ルートとを特定する(ステップS202)。例えば、乗降位置決定部132bは、自宅HP1方面に向かうバスとしてバスB2を特定し、自宅HP1へ向う走行ルートとして走行ルートRT30を特定したとする。そして、乗降位置決定部132bは、バスB2の乗客からは自宅HP1が死角となる位置を降車位置として決定する(ステップS203)。例えば、乗降位置決定部132bは、自宅HP1の前の通りの走行ルートRT30を直進し、走行ルート30を左へ曲った先の位置XP11を降車位置として決定する。
また、ルート決定部132cは、まず、自宅HP1および降車位置である位置XP11との間のエリアAR1内において、位置XP11から自宅HP1までの移動ルートの候補(候補ルート)を特定する(ステップS204)。そして、ルート決定部132cは、候補ルート毎に、街灯の有無、交通量、店舗の数、犯罪件数、事故件数といった各項目についてスコアを算出することで、候補ルートの安全性を示す安全性スコアを算出する(ステップS205)。なお、ルート決定部132cは、街灯の有無、交通量、店舗の数、犯罪件数、事故件数の全ての項目ではなく、各項目を任意に組み合わせた複数項目で安全性スコアを算出することもできる。
そして、ルート決定部132cは、ステップS205で算出した安全性スコアに基づいて、候補ルートの中から提示対象の移動ルートを決定する(ステップS206)。例えば、ルート決定部132cは、安全性スコアが最も高い移動ルートRT41を提示対象の移動ルートとして決定する。
そして、第2提示部132dは、乗降位置決定部132bにより決定された降車位置と、ルート決定部132cにより決定された移動ルートとをユーザに提示する(ステップS207)。図2の例では、第2提示部132dは、降車位置である位置XP11と、移動ルートRT41とをユーザU4に提示する。例えば、第2提示部132dは、図2(b)に示すように、降車位置が位置XP11であることと、位置XP11から自宅HP1へは移動ルートRT41が安全であることを示す情報J3を含むページP2bをユーザU4に提示する。
〔8.処理手順(2)〕
以下、図13に示すフローチャートを用いて、実施形態にかかる端末装置10の各処理部が実行・実現する制御処理の内容について説明する。図13は、実施形態にかかる表示制御処理の一例を示すフローチャートである。端末装置10による表示制御処理の一例については、図3を用いて説明した。したがって、ここでは、適宜、図3の例を用いることにする。端末装置10は、実施形態にかかる表示制御プログラムによって表示制御処理を実行する。
まず、検知部14aは、自装置である端末装置10の撮影方向と向きとを検知する(ステップS301)。
表示制御部14cは、検知部14aにより検知された傾きである角度が所定の条件情報を満たすか否かを判定する(ステップS302)。例えば、表示制御部14cは、検知部14aにより検知された傾きが角度が30度以下であるか否かを判定する。表示制御部14cは、角度が30度以下でないと判定した場合には(ステップS302;No)、これまで表示画面Dに表示されていた撮影方向PD1の映像を非表示とし(ステップS303a)、検知部14aにより検知された傾きが角度が30度以下になるまで待機する。一方、表示制御部14cは、検知部14aにより検知された傾きが角度が30度以下であると判定した場合には(ステップS303b)、表示画面Dの上半分の領域RE1に、撮影方向PD1の映像に対応する3D仮想現実画像である画像VG1を表示させ、表示画面Dの下半分の領域RE2に、撮影方向PD1と角度が30に対応するリアル映像である映像RG1を表示させる。
〔9.変形例〕
上記実施形態にかかる情報処理装置100は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、情報処理装置100の他の実施形態について説明する。
〔9−1.人数も提示〕
上記実施形態では、情報処理装置100は、他ユーザに関する情報として、仮想乗車地点から移動体に乗車予定の他ユーザの有無を示す情報を提示する例を示した。図1の例では、第1提示部131eが、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザが居る旨をユーザU3に提示する例を示した。しかし、第1提示部131eは、他ユーザに関する情報として、仮想乗車地点から移動体に乗車予定の他ユーザの人数を示す情報も提示してよい。
図1の例では、ユーザU3以外に、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザとして、ユーザU1およびU2がいる。したがって、かかる場合、第1提示部131eは、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザが「2人」居る旨をユーザU3に提示する。
候補位置CP1には、バス停を示す物理目標が存在する訳ではないが、この付近にユーザU3以外に人が2人いれば、ユーザU3は、この人たちは不審者等ではなく、同じ目的の人(バスB1の乗車したい人)なのだと予測でき安心することができる。このようなことから、実施形態にかかる情報処理装置100は、防犯面での安心感をユーザに与えることができる。
〔9−2.関係者が居れば提示〕
また、第1提示部131eは、他ユーザに関する情報として、他ユーザのうちユーザと所定の関係性を有する他ユーザに関する情報を、このユーザに提示する。例えば、第1提示部131eは、他ユーザに関する情報として、他ユーザのうちユーザと血縁関係にある他ユーザに関する情報をユーザに提示する。
説明を簡単にするために図1の例において、例えば、ユーザU3は「子」であり、ユーザU1は「母」であるとする。つまり、ユーザU3とU1とは親子関係であるものとする。かかる場合、第1提示部131eは、これまでの説明の様に他ユーザの有無や他ユーザの人数を提示するだけでなく、ユーザU3に対して、「母親も同時刻のバスに乗車予定です」といったように、親子関係にある他ユーザ(母)も乗車予定である旨を提示する。また、この場合、第1提示部131eは、ユーザU1に対しては、「息子も同時刻のバスに乗車予定です」といったように、親子関係にある他ユーザ(子)も乗車予定である旨を提示する。
これにより、例えば、ユーザU3は、同じ場所から母親もバスに乗る予定なのだ、ということを知ることができる。身内が同じところからバスB1に乗車するのであれば、それだけで安心感を得ることができる。したがって、実施形態にかかる情報処理装置100は、防犯面での安心感をユーザに与えることができる。
同様の考え方で、第1提示部131eは、他ユーザに関する情報として、他ユーザのうちユーザと友人関係にある他ユーザに関する情報をユーザに提示する。ここで、友人関係とは、リアルでの友人関係であってもよいし、インターネット上での友人関係であってもよい。インターネット上での友人関係とは、例えば、所定のSNS(Social Networking Service)での友人関係である。
説明を簡単にするために図1の例において、例えば、ユーザU3とユーザU1とはSNS上での友人であるものとする。かかる場合、第1提示部131eは、これまでの説明の様に他ユーザの有無や他ユーザの人数を提示するだけでなく、ユーザU3に対して、「SNSのお友達も乗車予定です」といったように、SNS友人関係にある他ユーザも乗車予定である旨を提示する。また、この場合、第1提示部131eは、ユーザU1に対しても、「SNSのお友達も乗車予定です」といったように提示する。
これにより、例えば、ユーザU3は、同じ場所から友人もバスに乗る予定なのだ、ということを知ることができる。友人が同じところからバスB1に乗車するのであれば、それだけで安心感を得ることができる。したがって、実施形態にかかる情報処理装置100は、防犯面での安心感をユーザに与えることができる。
〔9−3.出力形態〕
上記実施形態では、第1提示部131eが、テキストをユーザの端末装置10に表示させることにより情報提示を行う例を示した。例えば、第1提示部131eは、図1(b)に示すように、ユーザU3以外に乗車予定のユーザが居る旨を示す情報J1(テキスト)を含むページP1bを表示させている。しかしながら、第1提示部131eは、情報を音声出力させてもよい。言い換えれば、第1提示部131eは、ヒアラブル形式で情報提示を行ってもよい。図1(b)の例では、第1提示部131eは、ユーザU3の端末装置30に対して、「あなた以外に乗車予定の人が居ます」といったテキストに対応する自動音声を出力させる。
また、第1提示部131eは、乗車予定の他ユーザが存在しない場合にのみ、乗車予定の他ユーザが存在しないことを音声出力させてもよい。例えば、「2018年7月1日10時5分」において候補位置CP1からバスB1に乗車予定のユーザが、ユーザU3しかいなかったとする。かかる場合、第1提示部131eは、「あなた以外に乗る人はいません」を音声出力させる。
〔9−4.予約席について〕
上記実施形態では、空席情報取得部131cが、移動体が有する空席の数を示す空席情報を取得する例を示した。図1の例では、空席情報取得部131cが、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1における現在の空席状況を示す空席情報を取得する例を示した。しかし、空席情報取得部131cは、移動体が有する空席のうち予約済みの席を除く空席の数を示す空席情報を取得してもよい。
例えば、「2018年7月1日10時5分」に候補位置CP1に到着予定のバスB1にある空席のうち、いくつかの空席は予約席の場合がある。例えば、図1の例において、ユーザU2が、かかるバスB1の席の一つを予約していたとする。例えば、現在の空席数が「2」でこのうち1つはユーザU2に予約されてるものとする。かかる場合、空席情報取得部131cは、空席情報として空席数「1」を取得する。
この場合、ユーザU2よりも早い乗車順がユーザU1またはU3に割り当てられてしまった場合、ユーザU1またはU3のどちらかがユーザU2の予約席に座ってしまうことが考えられる。したがって、乗車順決定部131dは、予約席が存在する場合には、その予約席を予約しているユーザが確実にそこに座れるよう乗車順を決定する。例えば、予約しているユーザを優先的に早くバスに乗車させることができれば、予約しないないユーザに予約席を取られてしまうことを回避することができる。したがって、上記例では、乗車順決定部131dは、ユーザU2に対して最も早い乗車順「1」を決定し、ユーザU1およびU3については例えば、意思表示を行った順が早い順に乗車順を決定する。例えば、乗車順決定部131dは、ユーザU1に対して乗車順「2」を決定し、ユーザU3に対して乗車順「3」を決定する。
これにより、実施形態にかかる情報処理装置100は、予約済みの席が存在する場合であっても、ユーザ間の衝突を回避しつつ適切にユーザを着座させることができる。
〔9−5.移動ルート決定について〕
上記実施形態では、ルート決定部132cが、安全性スコアに基づいて、移動ルートを決定する例を示した。図2の例では、ルート決定部132cは、例えば、移動ルートRT41、移動ルートRT42および移動ルートRT43といった3つの候補ルートそれぞれについて安全性スコアを算出し、算出した安全性スコアに基づいて、候補ルートの中から対象の移動ルートを決定する例を示した。このとき、ルート決定部132cは、安全性を評価する項目のうちユーザに指定された項目に対して所定の重み付けを行うことにより算出された安全性スコアに基づいて、移動ルートを決定してもよい。
安全性を評価する項目としては、街灯の有無、交通量、所定の施設の数、犯罪件数、事故件数等の項目があることも説明した。ここで、ルート決定部132cは、例えば、この項目の中から特に重要視して欲しい項目の指定をユーザから受け付けることができる。例えば、図2で示したユーザU4は、女性であり、特に項目「街灯の有無」について重要視して欲しいため、この項目を指定したとする。なお、ユーザは、複数の項目を指定したり、複数の項目を指定したうえで、指定した複数の項目に対して、例えば、重要度の高さに応じた順位を付与することもできる。
説明を戻す。ルート決定部132cは、項目「街灯の有無」の指定をユーザU4から受け付けとする。この指定は、ユーザU4は、街灯の有る移動ルートが優先的に選ばれるように項目「街灯の有無」を指定する、と言い換えることができる。したがって、ルート決定部132cは、図2の「スコア情報」において、各候補ルートの項目毎にスコアを加算するときに、「街頭あり」の場合には、所定のスコアにさらに重み付けとして、所定の重み値を乗じる。具体的には、ルート決定部132cは、街灯有の場合「+1」を加算しているが、「+1」に対して重み値として、例えば、「5」を乗じた「+5」を加算する。
これにより、実施形態にかかる情報処理装置100は、ユーザに指定された項目に重点が置かれた移動ルートを優先的に決定することができるため、ユーザの意図を反映したルート決定処理を実現することができる。また、情報処理装置100は、ユーザの満足度を高めることもできる。
〔9−6.ヘルプボタンについて〕
また、表示制御部131gは、助けを呼ぶことができるヘルプボタンをユーザの端末装置10に表示させてもよい。例えば、第2提示部132dは、図2(b)に示すように、降車位置が位置XP11であることと、位置XP11から自宅HP1へは移動ルートRT41が安全であることを示す情報J3を含むページP2bをユーザU4の端末装置10に表示させる。このとき、表示制御部131gは、ページP2bに対して、助けを呼ぶことができるヘルプボタンを含める。例えば、ユーザU4は、移動ルートRT41を移動中に不審人物に絡まれてしまった場合、このヘルプボタンを押すことで、すぐに最寄りの警察署と連絡を取ることができるようになる。なお、端末装置10は、ヘルプボタンが押下されたことに応じて、ユーザU4の現在位置情報を警察署に送信してもよい。
なお、表示制御部131gは、必ずしも警察署と連絡がつながるようなヘルプボタンを表示制御するのではなく、例えば、ユーザU4に指定された指定先(例えば、身内のだれかの携帯電話)と連絡を取ることができるヘルプボタンを表示制御してもよい。
〔9−7.表示制御について〕
表示制御部14cは、情報処理装置100の表示制御部131gと連動して、仮想現実画像を表示させる点について図3を用いて説明した。図3の例では、表示制御部14cは、検知部14aにより検知された傾きが条件情報を満たすと判定すると、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像に対応する3D仮想現実画像である画像VG1を表示する。具体的には、表示制御部14cは、図3(c)に示すように、表示画面Dの上半分の領域RE1に画像VG1を表示させる。
また、撮像部13によって取り込まれた映像であって、撮影方向PD1の映像の中に候補位置CP1が含まれる場合には、表示制御部14cは、情報処理装置100の表示制御部131gと連携して、候補位置CP1に仮想バス停を示す画像を表示させる。このとき、第1提示部131eは、表示制御部14cに対して、画像VG1の中に他ユーザの有無や乗車順を表示させてもよい。
〔10.ハードウェア構成〕
また、上述してきた各実施形態にかかる情報処理装置100および端末装置10は、例えば図14に示すような構成のコンピュータ1000によって実現される。以下、情報処理装置100を例に挙げて説明する。図14は、情報処理装置100の機能を実現するコンピュータ1000の一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、及びメディアインターフェイス(I/F)1700を有する。
CPU1100は、ROM1300又はHDD1400に格納されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を格納する。
HDD1400は、CPU1100によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス1500は、通信網50を介して他の機器からデータを受信してCPU1100へ送り、CPU1100が生成したデータを、通信網50を介して他の機器へ送信する。
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、生成したデータを、入出力インターフェイス1600を介して出力装置へ出力する。
メディアインターフェイス1700は、記録媒体1800に格納されたプログラム又はデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、例えばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
例えば、コンピュータ1000が実施形態にかかる情報処理装置100として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部130の機能を実現する。また、HDD1400には、記憶部120内のデータが格納される。コンピュータ1000のCPU1100は、これらのプログラムを、記録媒体1800から読み取って実行するが、他の例として、他の装置から、通信網50を介してこれらのプログラムを取得してもよい。
また、例えば、コンピュータ1000が端末装置10として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、アプリ制御部14の機能を実現する。
〔11.その他〕
上記各実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上述してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
以上、本願の実施形態をいくつかの図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。