以下に、本願にかかる情報処理装置、情報処理方法および情報処理プログラムを実施するための形態(以下、「実施形態」と呼ぶ)について図面を参照しつつ説明する。なお、この実施形態により本願にかかる情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。
〔1.情報処理の概要〕
まず、図1を用いて、実施形態にかかる情報処理の概要を示す。図1は、実施形態にかかる情報処理の一例を示す図である。実施形態にかかる情報処理システムは、情報処理装置SVと、端末装置10とを含む。付図示であるが図1の例では、各ユーザ(ユーザU1、U2、U3)がそれぞれ端末装置10を所持する。実施形態にかかる情報処理は、図1に示す情報処理装置SVによって行われる。例えば、情報処理装置SVは、サーバ装置やクラウドシステム等、単数または複数の装置により実現され、移動通信網や無線LAN(Local Area Network)等のネットワークを介して、ユーザが使用する端末装置10と通信可能な情報処理装置である。
なお、情報処理装置SVによって行われる情報処理の詳細については、3つの実施形態、具体的には、第1の実施形態、第2の実施形態、第3の実施形態を用いて後ほど詳細に説明する。
端末装置10は、ユーザによって利用される情報処理装置である。端末装置10は、例えば、スマートフォンや、タブレット型端末や、ノート型PC(Personal Computer)や、デスクトップPCや、携帯電話機や、PDA(Personal Digital Assistant)等である。また、端末装置10には、路線バスの運行状況や路線バスの停留所の位置を検索可能なアプリケーション(以下、「乗車案内アプリAP」と表記する)が予めインストールされているものとする。
乗車案内アプリAPは、実施形態にかかる情報処理装置SVと連携することにより、情報処理装置SVから路線バスに関する各種情報を取得し、取得した情報をユーザに提示する。例えば、ユーザは、乗車案内アプリAPに対して、日常的に利用するバス停留所の名称を「お気に入り登録」することができる。かかる場合、乗車案内アプリAPは、任意のタイミングで、「お気に入り登録」されたバス停留所に関する情報を情報処理装置SVから取得し、ユーザに提示する。
また、情報処理装置SVが対象とする移動体は「オンデマンドバス」であるものとする。オンデマンドバスは、路線バスの一種であるが、ユーザがインターネット等の通信手段を用いて手続きを行った場合に、例えば、基本路線の外の迂回路線を経由して、例えば、仮想的に設置されたバス停留所へとユーザを迎えに行く。基本路線に存在する従来からの物理的なバス停留所(「既存バス停」と表記する場合がある)に対して、このように仮想的に設置されるバス停留所を「仮想バス停」とする。
〔2.第1の実施形態に対応する情報処理の概要〕
情報処理装置SVは、ユーザの属性情報、道路情報、交通状況等を加味して、任意の位置に仮想バス停を設置する。例えば、ユーザは情報処理装置SVに対して、オンデマンドバスに乗車を希望する乗車希望位置(以下、「希望位置」と表記する場合がある)を指定することができる。しかしながら、情報処理装置SVによって、全てのユーザの希望通りに仮想バス停が設置され、設置された仮想バス停の全てを通過する迂回路線での走行がオンデマンドバスに指示された場合、例えば、かかるオンデマンドバスの運行スケジュールに対して遅延が発生してしまう。
したがって、各オンデマンドバスに対して定められた基本路線を含む所定エリア内には、例えば、所定エリア毎に仮想バス停を設置する数に制限が設けられている。このため、情報処理装置SVは、各ユーザから受け付けた乗車希望位置のうち、どの乗車希望位置の仮想バス停を設置することが各ユーザから見てより平等であるかを算出し、算出結果に対応する乗車希望位置に仮想バス停を設置する。
また、情報処理装置SVは、乗車希望位置を指定したユーザの中に、例えば、移動するうえでより負担となり得る属性情報(例えば、妊娠している、あるいは、何らかの病気にかかっている)を有しているユーザが存在する場合には、残りのユーザから見て移動距離の観点から多少不平等になったとしても、このような移動するうえで負担となり得る属性情報を有するユーザの負担を軽減できるよう位置に仮想バス停を設置する。
この点について、図1の例を用いて説明する。まず、図1(a)に示すMAP1に示されるエリアでは、オンデマンドバスB1が基本路線RT10を走行するものとする。また、基本路線RT10上には、既存バス停ST1およびST2が存在する。また、既存バス停ST1が位置する位置情報は「S−PT1」であり、既存バス停ST2が位置する位置情報は「S−PT2」である。
また、図1(a)の例では、ユーザU1が「35歳、妊婦」といった属性情報を有する。また、図1(a)の例では、ユーザU1が希望位置「DP11」を指定している。また、図1(a)の例では、ユーザU1の現在位置が現在位置「HP11」である。
また、図1(a)の例では、ユーザU2が「20歳、男性」といった属性情報を有する。また、図1(a)の例では、ユーザU2が希望位置「DP21」を指定している。また、図1(a)の例では、ユーザU2の現在位置が現在位置「HP21」である。
また、図1(a)の例では、ユーザU3が「55歳、男性」といった属性情報を有する。また、図1(a)の例では、ユーザU3が希望位置「DP31」を指定している。また、図1(a)の例では、ユーザU3の現在位置が現在位置「HP31」である。
このような状態において、情報処理装置SVは、ユーザの属性情報を取得し、取得した属性情報に基づいて、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。例えば、情報処理装置SVは、ユーザの移動距離と、ユーザ属性情報とに基づいて、ユーザがその移動距離を移動することに要するコストである移動コストを算出する。そして、情報処理装置SVは、算出した移動コストに基づいて、設置位置を決定する。なお、MAP1に示されるエリアでは、仮想バス停を「1つ」だけ設置することができるものとする。
図1(a)の例では、ユーザU1は妊婦であり、ユーザU2およびU3と比較して移動にかかる身体的負担が大きいことが考えられる。例えば、希望位置「DP21」あるいは「DP31」のいずれかが仮想バス停が設置される設置位置として決定された場合、ユーザU1の移動距離は長くなり身体的負担が大きくなる。したがって、情報処理装置SVは、3つの希望位置のうち、ユーザU1に指定された希望位置であってユーザU1の現在位置HP11からユーザU1が移動するうえで最も移動距離が短い希望位置DP21を、仮想バス停が設置される設置位置として決定する。
希望位置DP21が仮想バス停が設置される設置位置として決定された場合、ユーザU2およびU3にとっては移動距離が長くなる。具体的には、ユーザU2は現在位置「HP21」から、自身が指定した希望位置「DP21」ではなく、ユーザU1が指定した希望位置「DP11」まで移動することになるため移動距離が長くなる。同様に、ユーザU3は現在位置「HP31」から、自身が指定した希望位置「DP31」ではなく、ユーザU1が指定した希望位置「DP11」まで移動することになるため移動距離が長くなる。
しかしながら、ユーザU2およびU3はその属性情報からして、ユーザU1に比べて、移動するうえでの身体的負担は少ないことが予測されるため、当初の希望位置に仮想バス停が設置されず移動距離が長くなったとしても、ユーザU1〜U3それぞれの属性情報および移動距離を総合的に判断すると、希望位置「DP11」が最も公平な設置位置となる。
このようなことから情報処理装置SVは、仮想バス停の設置位置に制限が設けられているうえで、複数のユーザから乗車希望位置の指定を受け付けた場合には、複数のユーザの属性情報および移動距離を考慮することで、複数のユーザから見てより公平な位置に仮想バス停を設置することができる。また、これにより情報処理装置SVは、移動体(例えば、オンデマンドバス)を利用するユーザの利便性を高めることができる。
なお、図1(a)の例では、希望位置「DP11」が設置位置として決定された場合、ユーザU2については、現在位置「HP21」から希望位置「DP11」までの移動距離よりも、現在位置「HP21」から既存バス停位置「S−PT2」までの移動距離の方が短くなっている。このような場合、ユーザU2にとっては乗車希望位置をした意味がなくなってしまう。したがって、情報処理装置SVは、ユーザU1〜U3のいずれから見ても、各自の現在位置から既存バス停までの移動距離よりも、移動距離が短くなるような位置であって、ユーザU1からの移動距離が最も短い位置を設置位置として決定してもよい。例えば、情報処理装置SVは、位置「XP10」を設置位置として決定してもよい。
〔3.第2の実施形態に対応する情報処理の概要〕
例えば、仮想バス停の設置位置が既存バス停の位置から近すぎる場合、既存バス停を利用すれば済むという観点から、そのような位置関係で仮想バス停を設置する意味合いが薄い。また、複数の設置位置を設ける場合、各設置位置間の距離が近すぎる場合、どちらかの設置位置だけで済むという観点から、そのような位置関係で仮想バス停を設置する意味合いが薄い。
また、上記例のような位置関係で仮想バス停が設置された場合、オンデマンドバスは頻繁に停車することを求められ運行効率が悪くなることが考えられる。オンデマンドバスは頻繁に停車することを求められた場合、運行にかかるコストが高くなることが考えられる。このような状況を回避できるよう、情報処理装置SVは、仮想バス停を設置可能な位置である設置可能位置を特定し、特定した設置可能位置に基づいて、設置位置を決定する。
例えば、図1(a)の例では、既存バス停ST1が存在する位置「S−PT1」を中心として半径Rの円領域が設けられており、かかる円領域内には仮想バス停を設置しないよう予め決められているものとする。また、同様に、既存バス停ST2が存在する位置「S−PT2」を中心として半径Rの円領域が設けられており、かかる円領域内には仮想バス停を設置しないよう予め決められているものとする。
また、不図示であるが、仮想バス停についても、その設置位置を中心とした半径Rの円領域内には、他の仮想バス停を設置しないことや、既存バス停が存在しないようにすることが予め決められているものとする。したがって、これら各バス停における半径Rの円領域は、仮想バス停を設置しない設置禁止領域である。言い換えれば、情報処理装置SVは、この設置禁止領域以外の領域には仮想バス停を設置することができる。
したがって、情報処理装置SVは、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置可能な位置である設置可能位置を特定し、特定した設置可能位置に基づいて、仮想乗車地点を設置する設置位置を決定する。図1の例では、情報処理装置SVは、上述したようにユーザU1〜U3により指定された情報や属性情報に基づいて、設置位置を設定するが、この際、既存バス停ST1が存在する位置「S−PT1」を中心とする半径Rの円領域、および、既存バス停ST2が存在する位置「S−PT2」を中心とする半径Rの円領域以外の領域を設置可能位置として特定する。そして、情報処理装置SVは、特定した設置可能位置において設置位置を決定し、決定した設置位置に仮想バス停を設置する。
これにより、情報処理装置SVは、例えば、既存バス停の位置に対して接近し過ぎた位置に仮想バス停を設置することがないので、移動体(例えば、オンデマンドバス)の運行効率の低下や、移動体の運行に要する費用の増大を効果的に抑えることができる。
〔4.第3の実施形態に対応する情報処理の概要〕
例えば、オンデマンドバスを運行スケジュールに従って運行させる場合、利用者の多い時間帯(例えば、通勤ラッシュの時間帯)や、利用者の少ない時間帯が発生する場合がある。オンデマンドバスを運行スケジュールに従って運行されるため、極端な例では、利用者が「0人」の場合でもオンデマンドバスを運行させなければならない。利用者が居ないにも拘らず、オンデマンドバスを運行させれば運行コストだけが大きくなってしまう。このようなことから、運行事業者は、いずれの時間帯もコンスタントにオンデマンドバスが利用されることを望む。このようなことから、情報処理装置SVは、オンデマンドバスに対する利用意欲を高められるよう、ユーザに様々なインセンティブを付与する。
具体的には、情報処理装置SVは、移動体を利用したユーザの利用状況を取得し、取得した利用状況に応じて、ユーザに対して、所定のインセンティブを付与する。例えば、情報処理装置SVは、取得した利用状況に基づき、所定の時間帯、または、所定の場所において、ユーザが移動体を利用したか否かを判定する。そして、情報処理装置SVは、判定結果に応じて、ユーザに対して、所定のインセンティブを付与する。この点について、図1(b)の例を用いて説明する。
図1(b)の例では、ユーザU1〜U3により指定された情報や属性情報に基づいて、設置位置が決定され、決定された設置位置からオンデマンドバスB1に乗車することでオンデマンドバスB1が利用されたものとする。情報処理装置SVは、例えば、オンデマンドバスB1内の各種のセンサを介して、オンデマンドバスB1の利用状況を取得することができる。例えば、情報処理装置SVは、ユーザがいつ、どこから、どの行き先(目的地)を基本路線とするオンデマンドバスに乗車したかといった利用状況を取得することができる。
図1(b)の例では、情報処理装置SVは、ユーザU1が「14時台」のオンデマンドバスB1を利用した例を示す。ここで、「14時台」においてオンデマンドバスB1が利用される利用量(利用者の数)が、オンデマンドバスB1における1日の平均利用量と比較して少ないことが判明しているとすると、情報処理装置100は、利用量の少ない「14時台」にユーザU1がオンデマンドバスB1を利用してくれたことに伴い、ユーザU1にインセンティブを付与する。例えば、情報処理装置100は、ユーザU1が本来支払うべき運賃(300円とする)よりも、運賃を安く(250円)する。
また、「10時台」においてオンデマンドバスB1が利用される利用量(利用者の数)が、オンデマンドバスB1における1日の平均利用量と比較して少ないことが判明しているとすると、情報処理装置100は、利用量の少ない「10時台」にユーザU3がオンデマンドバスB1を利用してくれたことに伴い、ユーザU3にインセンティブを付与する。例えば、情報処理装置100は、ユーザU3が本来支払うべき運賃(300円とする)よりも、運賃を安く(280円)する。
一方、情報処理装置100は、通勤ラッシュ等によりオンデマンドバスB1が利用される利用量(利用者の数)が、オンデマンドバスB1における1日の平均利用量より多い時間「8時台」にオンデマンドバスB1を利用したユーザU2にはインセンティブを付与しない。
これにより、情報処理装置SVは、運賃が安くなるなら今後も対応する時間帯にオンデマンドバスB1を利用しようといった動機付けをユーザに与えることができるため、オンデマンドバスB1が利用される利用状況を平滑化することができる。
(第1の実施形態)
〔1.情報処理の一例〕
次に、図2を用いて、第1の実施形態にかかる情報処理の一例を示す。図2は、第1の実施形態にかかる情報処理の一例を示す図である。第1の実施形態にかかる情報処理システムは、情報処理装置100と、端末装置10とを含む。付図示であるが図2の例では、各ユーザ(ユーザU1、U2、U3)がそれぞれ端末装置10を所持する。第1の実施形態にかかる情報処理は、図2に示す情報処理装置100によって行われる。情報処理装置100は、図1で説明した情報処理装置SVの一例である。例えば、情報処理装置100は、サーバ装置やクラウドシステム等、単数または複数の装置により実現され、移動通信網や無線LAN(Local Area Network)等のネットワークを介して、ユーザが使用する端末装置10と通信可能な情報処理装置である。
情報処理装置100は、「乗車案内アプリAP」を介して、ユーザからオンデマンドバスへの乗車予約を受け付けることができる。例えば、情報処理装置100は、現在日より翌日以降の日付でのオンデマンドバスへの乗車予約を受け付けることができる。例えば、情報処理装置100は、オンデマンドバスへの乗車予約として、オンデマンドバスへの乗車を希望する位置を示す乗車希望位置の指定を受け付けることができる。例えば、情報処理装置100は、仮想バス停を設置可能な設置位置の候補である候補位置をユーザに提示することにより、候補位置の中から選択されたものを乗車希望位置として受け付けることができる。
また、情報処理装置100は、「乗車案内アプリAP」を介して、ユーザからオンデマンドバスの「即時呼び」を受け付けることができる。「即時呼び」は、乗車予約と比較して緊急に対応できるもので、「即時呼び」はユーザの現在位置への移動体の配車指示と言い換えることができる。一例を示すと、ユーザは、「現在時刻から15分以内に現在位置(例えば、自宅)周辺にオンデマンドバスを配車」といった形で「即時呼び」を行うことができる。
以下の第1の実施形態では、ユーザから乗車予約として乗車希望位置の指定を受け付けた場合における情報処理について説明するが、即時呼びの場合であっても処理内容は同じである。
具体的には、情報処理装置100は、ユーザの属性情報を取得し、取得した属性情報に基づいて、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。例えば、情報処理装置100は、さらにユーザに関する位置情報に基づいて、設置位置を決定する。ここでの位置情報とは、乗車予約の際に指定された乗車希望位置を示す情報(乗車希望位置情報)、あるいは、即時呼びの際に指定された現在位置を示す情報(現在位置情報)である。なお、即時呼びの際に指定された現在位置も、ユーザが乗車を希望する位置であることには変わりないため、即時呼びの際の現在位置情報は、乗車希望位置情報と言い換えることができる。
また、例えば、情報処理装置100は、上記位置情報によって示される位置までのユーザの移動距離と、属性情報とに基づいて、ユーザが前記移動距離を移動することに要するコストである移動コストを算出する。そして、情報処理装置100は、算出した移動コストに基づいて、設置位置を決定する。この点について、図2の例を用いて説明する。なお、図2の例では、MAP1に示されるエリア内では、最大「2つ」の仮想バス停を設置してよいことが予め決められているものとする。
図1(a)と同様に、図2では、ユーザU1が希望位置「DP11」を指定している。また、図2の例でも、ユーザU1の現在位置は現在位置「HP11」である。
また、図1(a)と同様に、図2では、ユーザU2が希望位置「DP21」を指定している。また、図2の例でも、ユーザU2の現在位置は現在位置「HP21」である。
図1(a)と同様に、図2では、ユーザU3が希望位置「DP31」を指定している。また、図2の例でも、ユーザU3の現在位置は現在位置「HP31」である。
例えば、情報処理装置100は、ユーザの属性情報として、ユーザの年齢情報、性別情報、健康状態に関する情報、身体障害に関する情報、乳幼児の有無に関する情報等を取得する。なお、属性情報として取得される情報は、これらに限定されるものではない。図2では、情報処理装置100が、例えば、ユーザU1の属性情報として、年齢「33」、性別「女性」、健康状態「妊婦」、身体障害「なし」を取得した例を示す。また、図2では、情報処理装置100が、例えば、ユーザU2の属性情報として、年齢「20」、性別「男性」、健康状態「良」、身体障害「なし」を取得した例を示す。また、図2では、情報処理装置100が、例えば、ユーザU3の属性情報として、年齢「55」、性別「男性」、健康状態「良」、身体障害「なし」を取得した例を示す。
次に、情報処理装置100は、各ユーザの属性情報毎に、当該属性情報を示すスコアである属性スコアを算出する。属性スコアの算出方法は限定されないが、一例を示すと、情報処理装置100は、移動するうえでより負担に成り得る属性情報ほど高いスコアを算出する。例えば、情報処理装置100は、年齢情報(ユーザU1であれば「33」)を、そのまま属性スコア「33」と算出することができる。また、情報処理装置100は、属性情報「女性」に対しては、属性情報「男性」に対応する属性スコア「1」より高い「2」を算出することができる。
また、情報処理装置100は、健康状態がより悪いと考えられる属性情報ほど高い属性スコアを算出することができる。例えば、健康状態が最悪と考えられる属性情報に最大値「10」を算出する場合には、情報処理装置100は、例えば、属性情報「妊婦」に対応する属性スコア「8」を算出することができる。また、情報処理装置100は、属性情報「身体障害」については、身体障害がより重度であるほど高い属性スコアを算出することができる。
次に、情報処理装置100は、移動コストを算出する。移動コストは、ユーザが対応する移動距離を移動することに要するコストであり、ユーザが対応する移動距離を移動するうえでの身体的負担の程度を示す情報ともいえる。
ここで、図2の例では、ユーザU1に指定された希望位置DP11、ユーザU2に指定された希望位置DP21、ユーザU3に指定された希望位置DP31の3つお希望位置が存在する。上記の通り、情報処理装置100は、最大「2つ」の仮想バス停を設置してよいため、3つの希望位置のうち、どの2つの希望位置を設置位置とするかを決定する。図2の例では、情報処理装置100は、成立し得る希望位置の組合せ毎に、各ユーザの移動コストを算出するとともに、算出した移動コストを総和を算出する。そして、情報処理装置100は、希望位置の組合せ毎に算出された移動コストの総和のうち、総和が最小となる位置を設置位置として決定する。
なお、希望位置の組合せ毎に移動コストを算出する方法の一例については後ほど説明する。図2の例では、情報処理装置100が、ユーザU1に対して、ユーザU1により指定された希望位置DP11を設置位置(1つ目の設置位置)として決定した例を示す。また、情報処理装置100が、ユーザU2およびU3に対して、ユーザU2により指定された希望位置DP21を設置位置(2つ目の設置位置)として決定した例を示す。
また、不図示であるが、情報処理装置100は、ユーザU1に対して、希望位置DP11に仮想バス停を設置する旨と、その仮想バス停までの道のりを案内する案内情報を提示する。同様に、情報処理装置100は、ユーザU2およびU3に対して、希望位置DP21に仮想バス停を設置する旨と、その仮想バス停までの道のりを案内する案内情報を提示する。
これにより、第1の実施形態にかかる情報処理装置100は、複数のユーザから見てより公平な位置に仮想バス停を設置することができる。また、第1の実施形態にかかる情報処理装置100は、移動体を利用するユーザの利便性を高めることができる。
〔2.情報処理装置の構成〕
次に、図3を用いて、第1の実施形態にかかる情報処理装置100について説明する。図3は、第1の実施形態にかかる情報処理装置100の構成例を示す図である。図3に示すように、情報処理装置100は、通信部110と、記憶部120と、制御部130とを有する。
(通信部110について)
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。そして、通信部110は、ネットワークNと有線または無線で接続され、例えば、端末装置10との間で情報の送受信を行う。
(記憶部120について)
記憶部120は、例えば、RAM(Random Access Memory)、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部120は、仮想バス停位置情報記憶部121と、運行スケジュール記憶部122と、ユーザ情報記憶部123と、運行実績記憶部124とを有する。
(仮想バス停位置情報記憶部121について)
仮想バス停位置情報記憶部121は、仮想バス停を設置する位置の候補を記憶する記憶部である。ここで、図4に第1の実施形態にかかる仮想バス停位置情報記憶部121の一例を示す。図4の例では、仮想バス停位置情報記憶部121は、「都道府県」、「事業者」、「系統ID」、「位置情報(座標)」といった項目を有する。
「事業者」は、対応する「都道府県」に存在する路線バス運行事業主の名称を示す。「系統ID」は、対応する「事業者」によって運営される路線バスが走行する路線を示す識別情報である。「位置情報(座標)」は、仮想バス停を設置可能な位置を示す位置情報であって、仮想バス停を設置する位置の候補を示す位置情報を示す。
すなわち、図4の例では、都道府県「東京都」に存在する路線バス運行事業主「TK交通」により運営される路線バス(オンデマンドバス)が走行する路線のうち、系統ID「20」によって識別される路線(20系統路線)における位置「X1,Y1」には、仮想バス停を設置可能である例を示す。
(運行スケジュール記憶部122について)
運行スケジュール記憶部122は、オンデマンドバス毎の運行スケジュールを記憶する記憶部である。ここで、図5に第1の実施形態にかかる運行スケジュール記憶部122の一例を示す。図5の例では、運行スケジュール記憶部122は、「事業者名」、「系統ID」、「スケジュール情報」といった項目を有する。
「事業者名」および「系統ID」については、図4で説明した通りであるため説明を省略する。「スケジュール情報」は、オンデマンドバスの運行スケジュールを示す。図5の例では、「スケジュール情報」として概念記号(例えば、「DA20」)を用いているが、実際には、例えば、出発時刻、行き先、行き先への到着時刻、基本路線を示す地図情報等が記憶される。
すなわち、図5の例では、都道府県「東京都」に存在する路線バス運行事業主「TK交通」により運営される路線バス(オンデマンドバス)は、スケジュール情報「DA20」によって示されるスケジュールで運行される例を示す。
(ユーザ情報記憶部123について)
ユーザ情報記憶部123は、ユーザに関する各種の情報(例えば、属性情報)を記憶する記憶部である。ここで、図6に第1の実施形態にかかるユーザ情報記憶部123の一例を示す。図6の例では、ユーザ情報記憶部123は、「ユーザID」、「年齢」、「性別」、「健康状態」、「身体障害」、「乳幼児情報」といった項目を有する。
「ユーザID」は、ユーザまたはユーザの端末装置10を識別する識別情報を示す。「年齢」は、ユーザの年齢を示す。「性別」は、ユーザの性別を示す。「健康状態」は、ユーザの健康状態に関する情報(妊娠しているか等)を示す。「身体障害」は、ユーザの身体障害に関する情報を示す。例えば、「身体障害」は、ユーザが身体障害を有するか否か、有する場合にはどのような身体障害であるかを示す。「乳幼児情報」は、乳幼児の有無に関する情報や、乳幼児同伴であるか否かを示す情報である。
すなわち、図6の例では、ユーザU1の属性情報が、年齢「33」、性別「女性」、健康状態「妊婦」、身体障害「なし」、乳幼児情報「小学生同伴」である例を示す。なお、不図示であるが情報処理装置100は、属性情報を示す情報(値)である属性スコアを算出するための情報を記憶する記憶部をさらに有してもよい。例えば、情報処理装置100は、かかる記憶部を参照することにより、健康状態「妊婦」に対してどのような属性スコアを算出するかを判断することができる。
(運行実績記憶部124について)
運行実績記憶部124は、路線バスの運行実績に関する情報を記憶する記憶部である。ここで、図7に第1の実施形態にかかる運行実績記憶部124の一例を示す。図7の例では、運行実績記憶部123は、「事業者」、「系統ID」、「日付情報」、「遅延情報」といった項目を有する。
「事業者」は、路線バス運行事業主の名称を示す。「系統ID」は、対応する「事業者」によって運営される路線バス(オンデマンドバス)が走行する路線を示す識別情報である。「日付情報」は、「遅延情報」によって示される区間を路線バスが走行していた際の日時を示す。「遅延情報」は、「系統ID」によって識別される路線において、運行スケジュールに遅延が発生した区間を示す。例えば、乗車人数や下車人数が多いバス停留所が連続しているような区間では、運行スケジュールに遅延が発生しやすい。
すなわち、図7の例では、系統ID「20」によって識別される路線(20系統路線)において、日付情報「2017年9月5日 8時15分〜8時30分」の間に、区間X1で運行スケジュールに遅延が発生した例を示す。
なお、運行実績記憶部124は、渋滞が発生した日時を示す日付情報と、渋滞が発生した区間を示す渋滞情報とを対応付けて記憶してもよい。
(制御部130について)
図3に戻り、制御部130は、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、情報処理装置100内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部130は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
図3に示すように、制御部130は、受信部131と、取得部132と、算出部133と、決定部134と、提示部135と、指示部136とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部130の内部構成は、図3に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部130が有する各処理部の接続関係は、図3に示した接続関係に限られず、他の接続関係であってもよい。
(受信部131について)
受信部131は、端末装置10から各種情報を受信する。例えば、受信部131は、コンテンツやコンテンツに関する情報の配信要求を受信する。
また、受信部131は、端末装置10から移動体に関して指定する各種の指定情報を受け付ける。例えば、受信部131は、ユーザに関する位置情報を受信する。例えば、受信部131は、オンデマンドバスの乗車予約に関する情報を受信する。一例を示すと、受信部131は、オンデマンドバスの乗車予約に関する情報として、オンデマンドバスへの乗車を希望する位置を示す乗車希望位置の指定を受け付ける。
また、例えば、受信部131は、オンデマンドバスの即時呼びに関する情報を受信する。一例を示すと、受信部131は、ユーザから、当該ユーザの現在位置(または、現在位置周辺の位置)への移動体の配車指示を受け付ける。
(取得部132について)
取得部132は、ユーザの属性情報を取得する。例えば、取得部132は、連携する外部の情報処理装置(各種のサーバ装置)から、ユーザの属性情報を取得する。例えば、取得部132は、コンテンツ(記事コンテンツ、広告コンテンツ等)の配信を行うコンテンツサーバからユーザの属性情報を取得する。また、取得部132は、商品の売買を管理するショッピングサーバからユーザの属性情報を取得する。また、取得部132は、各種のアプリケーションを管理するアプリサーバからユーザの属性情報を取得する。また、取得部132は、取得した属性情報をユーザ情報記憶部123に格納する。
なお、取得部132は、移動体に乗車するための乗車地点を示す乗車位置情報と、ユーザの現在位置を示すユーザ位置情報との間での位置関係を取得してもよい。また、取得部132は、移動体の現在位置を示す移動***置情報も取得してよい。また、取得部132は、取得した情報に基づいて、ユーザに提示するための情報を算出することもできる。例えば、取得部132は、既存バス停ST1およびST2それぞれにオンデマンドバスB1が到着するまでの残り時間を算出することができる。また、取得部132は、決定部134により設置された仮想バス停それぞれにオンデマンドバスB1が到着するまでの残り時間を算出することができる。また、このような算出処理は、取得部132以外の処理部で行われてもよい。
(算出部133について)
算出部133は、位置情報によって示される位置までのユーザの移動距離と、ユーザの属性情報とに基づいて、ユーザが当該移動距離を移動することに要するコストである移動コストを算出する。移動コストは、ユーザが対応する移動距離を移動することに要するコストであり、ユーザが対応する移動距離を移動するうえでの身体的負担の程度を示す情報ともいえる。なお、ここでの位置情報とは、例えば、乗車予約や即時呼びの際にユーザにより指定された乗車希望位置を示す乗車希望位置情報である。
例えば、算出部133は、位置情報によって示される位置までのユーザの移動距離と、ユーザの属性情報を示す属性スコアとを乗じることにより、移動コストを算出する。なお、算出部133は、属性スコアの算出も行ってよい。
(決定部134について)
決定部134は、取得部132により取得された属性情報に基づいて、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。例えば、決定部134は、ユーザに関する位置情報に基づいて、設置位置を決定する。
また、例えば、決定部134は、ユーザから移動体への乗車予約が受け付けられた場合に、位置情報として、移動体への乗車を希望する位置を示す乗車希望位置情報であって当該ユーザが乗車予約の際に指定した乗車希望位置情報に基づいて、設置位置を決定する。また、決定部134は、ユーザから、ユーザの現在位置への移動体の配車指示(即時呼び)が受け付けられた場合に、位置情報として、当該現在位置を示す現在位置情報に基づいて、設置位置を決定する。
また、決定部134は、算出部133により算出された移動コストに基づいて、設置位置を決定する。具体的には、決定部134は、複数のユーザそれぞれの移動コストの総和が最小となるように設置位置を決定する。例えば、決定部134は、位置情報によって示される位置のうち、複数のユーザそれぞれの移動コストの総和が最小となる位置を設置位置として決定する。また、決定部134は、算出部133により算出された移動コストに基づいて、予め決められている数の設置位置を決定する。
また、決定部134は、以上のようにして決定した設置位置に対して、実際に、仮想バス停を設置する。
(提示部135について)
提示部135は、ユーザに対してコンテンツを提示する。具体的には、提示部136は、決定部134により設置された仮想バス停に関するコンテンツをユーザに提示する。例えば、提示部135は、決定部134により設置された仮想バス停までの道のりを案内する案内情報を提示する。一例を示すと、提示部135は、ユーザの現在位置から仮想バス停までの道のりが表示された地図情報を案内情報として提示する。また、仮想バス停は既存バス停と違い物理的に存在するものではないため、ユーザはその正確な位置を認識し難い場合がある。したがって、提示部135は、仮想バス停周辺の環境情報(例えば、写真)を提示してもよい。
(指示部136について)
指示部136は、移動体に対して、決定部134により設置された仮想バス停へと移動するよう指示する。例えば、指示部136は、移動体の本来の走行ルートに基づいて、仮想バス停への迂回ルートを決定し、決定した迂回ルートを走行するよう移動体に指示する。
〔3.情報処理における作用の一例〕
以下、図8に示すフローチャートを用いて、各処理部131〜136が実行・実現する処理の内容について説明する。図8は、第1の実施形態にかかる情報処理の一例を示すフローチャートである。また、適宜、図2の例を用いることにする。
まず、受信部131は、ユーザから位置情報の指定を受け付けたか否かを判定する(ステップS101)。例えば、受信部131は、位置情報として、乗車予約により指定された乗車希望位置を示す位置情報、すなわち乗車希望位置情報を受信したか否かを判定する。また、受信部131は、位置情報として、即時呼びにより指定された乗車希望位置を示す位置情報、すなわち乗車希望位置情報を受信したか否かを判定してもよい。
受信部131は、乗車希望位置情報を受信していない場合(ステップS101;No)は、受信するまで待機する。一方、受信部131は、乗車希望位置情報を受信した場合には(ステップS101;Yes)、取得部132へと処理を移行する。
ここでは、受信部131は、図2に示すように、ユーザU1から希望位置「DP11」の指定を受け付けたものとする。また、受信部131は、ユーザU1の端末装置10からユーザU1の現在位置が現在位置「HP11」である旨受信したものとする。また、受信部131は、図2に示すように、ユーザU2から希望位置「DP21」の指定を受け付けたものとする。また、受信部131は、ユーザU2の端末装置10からユーザU2の現在位置が現在位置「HP21」である旨受信したものとする。また、受信部131は、図2に示すように、ユーザU3から希望位置「DP31」の指定を受け付けたものとする。また、受信部131は、ユーザU3の端末装置10からユーザU3の現在位置が現在位置「HP31」である旨受信したものとする。
取得部132は、受信部131により乗車希望位置情報が受信された場合には(ステップS101;Yes)、ユーザの属性情報を取得する(ステップS102)。取得部132は、ユーザ情報記憶部123に既にユーザU1〜U3の属性情報が記憶されている場合には、ユーザ情報記憶部123からその属性情報を取得する。一方、取得部132は、ユーザ情報記憶部123にユーザU1〜U3の属性情報が記憶されていない場合には、例えば、所定の外部装置から属性情報を取得してもよい。
図2の例では、取得部132が、ユーザU1の属性情報として、年齢「33」、性別「女性」、健康状態「妊婦」、身体障害「なし」を取得した例を示す。また、図2では、取得部132が、例えば、ユーザU2の属性情報として、年齢「20」、性別「男性」、健康状態「良」、身体障害「なし」を取得した例を示す。また、図2では、取得部132が、例えば、ユーザU3の属性情報として、年齢「55」、性別「男性」、健康状態「良」、身体障害「なし」を取得した例を示す。
次に、取得部132は、既存バス停の位置情報を取得する(ステップS103)。図2の例では、取得部132は、既存バス停ST1の位置を示す位置情報「S−PT1」、および、既存バス停ST2の位置を示す位置情報「S−PT2」を取得する。
次に、算出部133は、取得部132により取得された各ユーザ毎の属性情報毎に、当該属性情報を示す属性スコアを算出する(ステップS104)。算出部133による属性スコアの算出方法は限定されないが、一例を示すと、算出部133は、ユーザが移動するうえでより負担に成り得る属性情報ほど高いスコアを算出する。例えば、算出部133は、年齢情報(ユーザU1であれば「33」)を、そのまま属性スコア「33」と算出することができる。また、算出部133は、属性情報「女性」に対しては、属性情報「男性」に対応する属性スコア「1」より高い「2」を算出することができる。
また、算出部133は、健康状態がより悪いと考えられる属性情報ほど高い属性スコアを算出することができる。例えば、健康状態が最悪と考えられる属性情報に最大値「10」を算出する場合には、算出部133は、例えば、属性情報「妊婦」に対応する属性スコア「8」を算出することができる。また、算出部133は、属性情報「身体障害」については、身体障害がより重度であるほど高い属性スコアを算出することができる。
図2の例では、算出部133が、ユーザU1の各属性情報について、年齢「33」に対して属性スコア「33」、性別「女性」に対して属性スコア「2」、健康状態「妊婦」に対して属性スコア「8」、身体障害「なし」に対して属性スコア「1」を算出した例を示す。ユーザU2およびU3については説明を省略する。
次に、算出部133は、各希望位置までのユーザの移動距離と、属性スコアとに基づいて、移動コストを算出する(ステップS105)。なお、かかる例では、情報処理装置100は、MAP1に示されるエリアにおいて最大「2つ」の仮想バス停を設置してよいものとする。したがって、後述する決定部134は、3つの希望位置のうち、どの2つの希望位置を設置位置とするかを決定する。
図2の例では、算出部133は、成立し得る希望位置の組合せ毎に、各ユーザの移動コストを算出するとともに、算出した移動コストを総和を算出する。図2のように、希望位置「DP11」、希望位置「DP21」、希望位置「DP31」といった3つの希望位置が存在し、このうち2つを設置位置として決定してよい場合、算出部133は、この3つの希望位置のうち、2つの希望位置を組合せた、各組合せ毎に各ユーザの移動コストを算出するとともに、算出した移動コストを総和を算出する。
希望位置の組合せとしては、組合せ(DP11、DP21)、組合せ(DP11、DP31)、組合せ(DP21、DP31)、といった3通りの組合せが考えられるが、組合せ(DP11、DP21)を例に説明する。例えば、希望位置DP11およびDP21の例では、ユーザU1〜U3それぞれは、希望位置DP11およびDP21のうち、いずれかに自身に対応する仮想バス停が設置される可能性がある。ユーザU1〜U3それぞれについて2通りの設置位置の候補がある。したがって、算出部133は、組合せ(DP11、DP21)について、18通りの移動コストを算出することができる。
18通りのうち、一つを例に挙げると、ユーザU1に対して希望位置DP11が設置位置となり、ユーザU2に対して希望位置DP11が設置位置となり、ユーザU3に対して希望位置DP11が設置位置となる場合がある。これは、図2に示すL1に対応し、かかる場合、算出部133は、ユーザU1が希望位置DP11へ移動する際の移動コスト「U1(DP11)」、ユーザU2が希望位置DP11へ移動する際の移動コスト「U2(DP11)」、ユーザU3が希望位置DP11へ移動する際の移動コスト「U3(DP11)」それぞれ算出し、算出した3つの移動コストを合計した移動コストの総和「SM11」を算出する。ここで、算出部133は、ユーザU1が希望位置DP11へ移動する際の移動コスト「U1(DP11)」を、ユーザU1が現在位置HP11から希望位置DP11まで移動する移動距離K1と、ユーザU1の各属性スコア(33、2、8、1)を乗じることにより算出することができる。すなわち、K1×33×2×8×1=U1(DP11)、が成立する。
また、ユーザU1に対して希望位置DP11が設置位置となり、ユーザU2に対して希望位置DP11が設置位置となり、ユーザU3に対して希望位置DP21が設置位置となる場合がある。これは、図2に示すL2に対応し、かかる場合、算出部133は、ユーザU1が希望位置DP11へ移動する際の移動コスト「U1(DP11)」、ユーザU2が希望位置DP11へ移動する際の移動コスト「U2(DP11)」、ユーザU3が希望位置DP21へ移動する際の移動コスト「U3(DP21)」それぞれ算出し、算出した3つの移動コストを合計した移動コストの総和「SM12」を算出する。
また、ユーザU1に対して希望位置DP11が設置位置となり、ユーザU2に対して希望位置DP31が設置位置となり、ユーザU3に対して希望位置DP31が設置位置となる場合がある。これは、図2に示すL3に対応し、かかる場合、算出部133は、ユーザU1が希望位置DP11へ移動する際の移動コスト「U1(DP11)」、ユーザU2が希望位置DP21へ移動する際の移動コスト「U2(DP31)」、ユーザU3が希望位置DP21へ移動する際の移動コスト「U3(DP31)」それぞれ算出し、算出した3つの移動コストを合計した移動コストの総和「SM13」を算出する。
同様の手法で、算出部133は、希望位置の各組合せ毎に移動コストの総和を算出する。そして、決定部134は、算出部133により算出された移動コストの総和が最小となる位置を設置位置として決定する(ステップS106)。例えば、図2の例では、算出された全ての総和のうち、L3に対応する移動コストの総和が最小であったとする。かかる場合、決定部134は、ユーザU1に対して、ユーザU1により指定された希望位置DP11を設置位置として決定する。また、決定部134は、ユーザU2およびU3に対して、ユーザU2により指定された希望位置DP31として決定する。また、決定部134は、希望位置DP11およびDP21といった2つの設置位置を決定したことで、これらの設置位置に、実際に、仮想バス停を設置する。
次に、提示部135は、決定部134により設置された仮想バス停に関する案内情報をユーザに提示する(ステップS107)。また、指示部136は、図2の例では、オンデマンドバスB1に対して、仮想バス停が設置された希望位置DP11およびDP21を通過する迂回ルートRT20を走行するよう指示する(ステップS108)。
〔4.変形例〕
上記第1の実施形態にかかる情報処理装置100は、上記第1の実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、情報処理装置100の他の実施形態について説明する。
〔4−1.待ち時間を考慮した位置決め〕
決定部134は、仮想乗車地点が設置された場合に当該仮想乗車地点が設置された設置位置において予測されるユーザの待ち時間に基づいて、仮想乗車地点を設置する設置位置を決定する。例えば、図2の例において、ユーザU1〜U3から希望地点の指定が受け付けられた際の天候が悪天候条件(例えば、降雨、降雪、強風、高気温、寒気温)であったとする。かかる天候条件の場合、算出部133は、希望位置DP11、DP21、DP31それぞれに仮想バス停を設置した場合における待ち時間を予測算出する。
例えば、算出部133は、オンデマンドバスB1の現在位置、オンデマンドバスB1の運行速度、オンデマンドバスB1の現在位置から希望位置DP11、DP21、DP31それぞれまでの距離、各ユーザの現在位置から希望位置DP11、DP21、DP31それぞれまでの距離に基づいて、希望位置DP11、DP21、DP31それぞれに仮想バス停を設置した場合における待ち時間を予測算出する。
このような状態において、決定部134は、希望位置DP11、DP21、DP31のうち、待ち時間が最小となる位置を設置位置として決定する。例えば、決定部134は、希望位置DP11、DP21、DP31のうち、待ち時間が最小となる位置を設置位置として決定する。
これにより、第1の実施形態にかかる情報処理装置100は、悪天候下における仮想バス停での待ち時間をより短くすることができる。また、情報処理装置100は、希望位置を指定した各ユーザについて公平に待ち時間を短くすることができる。言い換えれば、情報処理装置100は、1人のユーザの待ち時間が極端に短くなり、別のユーザの待ち時間が極端に長くなるといった不公平が生じることを防止することができる。
〔4−2.目的地を考慮した位置決め〕
また、決定部134は、ユーザから目的地の指定が受け付けられた場合に、ユーザにより指定された目的地に基づいて、設置位置を決定する。かかる場合、決定部134は、移動体のうち、目的地に対応する移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。この点について、図2の例を用いて説明する。ここでは、説明を簡単にするために、ユーザU1が希望位置DP11を指定し、また、目的地「A駅」を指定したものとする。また、ユーザU2が希望位置DP21を指定し、また、目的地「A駅」を指定したものとする。
かかる場合、取得部132は、運行スケジュール記憶部122を参照し、基本路線が目的地「A駅」を通過する、あるいは、基本路線が目的地「A駅」付近(例えば、A駅から所定距離以内を通過している)であるオンデマンドバスB1を選択する。また、取得部132は、選択したオンデマンドバスB1の基本路線が希望位置DP11およびDP21から所定距離以内であるか否かを算出する。所定距離以内である場合には、算出部133は、図8で説明した流れで移動コストの総和を算出する。そして、決定部134は、算出された総和に基づいて、設置位置を決定する。また、指示部136は、オンデマンドバスB1に対して、ユーザU1およびU2を乗車させた後、目的地「A駅」に立ち寄るよう指示する。
なお、提示部135は、オンデマンドバスB1の基本路線が希望位置DP11およびDP21から所定距離以内でない場合には、対象のオンデマンドバスが存在しない旨各ユーザに提示してもよい。
これにより、第1の実施形態にかかる情報処理装置100は、ユーザの指示に応じて、仮想バス停を設置するとともに、ユーザを目的地へと送り届けることができる。この結果、情報処理装置100は、移動体を利用するユーザの利便性を高めることができる。
なお、情報処理装置100は、ユーザにより指定された目的地へ向かうオンデマンドバスが存在しない場合、かかる目的地へ向かう他の交通手段(例えば、鉄道)が存在するか否かを検索する。また、情報処理装置100は、かかる目的地へ向かう他の交通手段(例えば、鉄道)が存在し、その鉄道の駅のうちいずれかの駅に向かうオンデマンドバスの基本路線が希望位置から所定距離以内であれば、そのオンデマンドバスについて仮想バス停を設置してもよい。
〔4−3.時刻を考慮した位置決め〕
また、決定部134は、ユーザからユーザの出発予定時刻、または、目的地への到着希望時刻の指定が受け付けられた場合に、ユーザにより指定された出発予定時刻、または、到着希望時刻に基づいて、設置位置を決定する。例えば、決定部134は、ユーザの出発予定時刻から所定時間以内に移動体が到着可能な位置のうち、所定の位置(例えば、ユーザが希望する希望位置)を設置位置として決定する。あるいは、決定部134は、目的地へと到着希望時刻に間に合うように設置位置を決定する。この点について、図9の例を用いて説明する。図9は、第1の実施形態にかかる変形例における情報処理の一例を示す図である。なお、図9に示すMAP1は、図1および図2に示すものと同様である。
まず、ユーザU1が目的地「T大学」への到着希望時刻「10時」を指定したとする。また、受信部131は、このような情報設定を「9時」に受け付けたものとする(設定受付時刻:9時)。かかる場合、決定部134は、目的地「T大学」に時刻「10時」に到着可能なバスについて、設置位置を決定する(ステップS11)。ここでは、説明を簡単にするために、決定部134は、上述してきた例と同様に、オンデマンドバスB1について、希望位置DP11を設置位置として決定したものとする。
このような状態において、決定部134は、設置位置DP11を通過する迂回ルートRT20をオンデマンドバスB1が通過した場合、目的地「T大学」への到着予想時刻が「10時」を超えないか否かを判定する(ステップS12)。ここで、決定部134は、到着予想時刻が「10時」を超えると判定した場合、オンデマンドバスB1の次の運行スケジュールに基づいて設置位置を再決定する。
次に、提示部135は、ユーザU1の現在位置HP11から、設置位置となった希望位置DP11までの移動にユーザU1が要する所要時間T11を算出する(ステップS13)。また、提示部135は、オンデマンドバスB1の現在位置から希望位置DP11までの移動にオンデマンドバスB1が要する所要時間T12算出する(ステップS14)。
次に、提示部135は、所要時間T11と所要時間T12とに基づいて、希望位置DP11での待ち時間がより短くなるよう移動開始時刻を算出する(ステップS15)。そして、提示部135は、算出した移動開始時刻をユーザU1に提示する(ステップS16)。なお、ステップS13〜S15での算出処理は算出部133によって行われてもよい。
次に、ユーザU3が目的地「B駅」への到着希望時刻「9時45分」を指定したとする。また、受信部131は、このような情報設定を「9時25分」に受け付けたものとする(設定受付時刻:9時25分)。かかる場合、決定部134は、ユーザU1のために迂回ルートT20を迂回して走行するオンデマンドバスB1の運行ルート上に、目的地「B駅」が存在するか否かを判定する(ステップS21)。決定部134は、目的地「B駅」が存在すると判定した場合、オンデマンドバスB1が迂回ルートRT20、および、ユーザU2による希望位置DP21へと迂回する迂回ルートRT21を通過したと仮定し、ユーザU1による目的地「T大学」への到着予想時刻「10時」を超えないか否かを判定する(ステップS22)。決定部124は、到着予想時刻「10時」を超えないと判定した場合には、希望位置DP21も設置位置として決定する(ステップS23)。
次に、提示部135は、ユーザU3の現在位置HP31から、設置位置となった希望位置DP31までの移動にユーザU3が要する所要時間31を算出する(ステップS24)。また、提示部135は、オンデマンドバスB1の現在位置から希望位置DP31までの移動にオンデマンドバスB1が要する所要時間T32算出する(ステップS25)。
次に、提示部135は、所要時間T31と所要時間T32とに基づいて、希望位置DP31での待ち時間がより短くなるよう移動開始時刻を算出する(ステップS26)。そして、提示部135は、算出した移動開始時刻をユーザU3に提示する。なお、ステップS24〜S26での算出処理は算出部133によって行われてもよい。
このように、第1の実施形態にかかる情報処理装置100は、出発予定時刻、または、目的地への到着希望時刻の指定が受け付けられた場合に、出発予定時刻、または、到着希望時刻に基づいて、設置位置を決定する。また、情報処理装置100は、仮想バス停での待ち時間がより短くなるよう移動開始時刻をユーザに提示する。これにより、情報処理装置100は、よりユーザの希望を考慮したうえで仮想バス停を設置することができるため、移動体を利用するユーザの利便性を高めることができる。
〔4−4.混雑状況を考慮した情報提示〕
情報処理装置100は、ユーザから受け付けた出発予定時刻、または、到着希望時刻に基づき設置位置を決定した場合、例えば、通勤ラッシュ等により着座不可能な時間帯にオンデマンドバスに乗車させてしまう場合がある。このような場合、ユーザによっては着座することができないために身体的負担が大きくなる場合がある。したがって、情報処理装置100は、ユーザの属性情報(例えば、骨折している)に応じて、混雑を回避可能な時間帯でのオンデマンドバスへの乗車を案内する。
これにより、情報処理装置100は、移動体を利用するユーザの利便性を高めることができる。
〔5.効果〕
第1の実施形態にかかる情報処理装置100は、取得部132と、決定部134とを有する。取得部132は、ユーザの属性情報を取得する。決定部134は、取得部132により取得された属性情報に基づいて、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、複数のユーザから見てより公平な位置に仮想バス停を設置することができる。また、第1の実施形態にかかる情報処理装置100は、移動体を利用するユーザの利便性を高めることができる。
また、決定部134は、ユーザに関する位置情報に基づいて、設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、例えば、ユーザに指定された位置を示す位置情報に基づき設置位置を決定することができるため、ユーザの利便性を高めることができる。
また、決定部134は、ユーザから移動体への乗車予約が受け付けられた場合に、位置情報として、移動体への乗車を希望する位置を示す乗車希望位置情報であって当該ユーザが乗車予約の際に指定した乗車希望位置情報に基づいて、設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、乗車予約に対応することができるため、ユーザの利便性を高めることができる。
また、決定部134は、ユーザから、ユーザの現在位置への移動体の配車指示が受け付けられた場合に、位置情報として、当該現在位置を示す現在位置情報に基づいて、設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、即時呼びに対応することができるため、ユーザの利便性を高めることができる。
また、第1の実施形態にかかる情報処理装置100は、算出部133を有する。算出部133は、位置情報によって示される位置までのユーザの移動距離と、属性情報とに基づいて、ユーザが移動距離を移動することに要するコストである移動コストを算出する。また、決定部134は、算出部133により算出された移動コストに基づいて、設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、各ユーザについてより公平に設置位置を決定することができるとともに、移動するうえで身体的負担がより大きいユーザへの優先度が高められた位置を設置位置として決定することができる。
また、決定部134は、複数のユーザそれぞれの移動コストの総和が最小となるように設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、各ユーザについてより公平に設置位置を決定することができるとともに、移動するうえで身体的負担がより大きいユーザへの優先度が高められた位置を設置位置として決定することができる。
また、決定部134は、位置情報によって示される位置のうち、複数のユーザそれぞれの移動コストの総和が最小となる位置を設置位置として決定する。
これにより、第1の実施形態にかかる情報処理装置100は、各ユーザについてより公平に設置位置を決定することができるとともに、移動するうえで身体的負担がより大きいユーザへの優先度が高められた位置を設置位置として決定することができる。
また、決定部134は、移動コストに基づいて、予め決められている数の設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、仮想バス停を設置する数に制限がある中で、より公平に設置位置を決定することができる。
また、決定部134は、仮想乗車地点が設置された場合に当該仮想乗車地点が設置された設置位置において予測されるユーザの待ち時間に基づいて、仮想乗車地点を設置する設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、例えば、悪天候下における仮想バス停での待ち時間をより短くすることができるため、ユーザの利便性を高めることができる。
また、決定部134は、ユーザから目的地の指定が受け付けられた場合に、ユーザにより指定された目的地に基づいて、設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、ユーザの指示に応じて、仮想バス停を設置することができるとともに、ユーザを目的地へと送り届けることができる。
また、決定部134は、移動体のうち、目的地に対応する移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、ユーザの指示に応じて、仮想バス停を設置することができるとともに、ユーザを目的地へと送り届けることができる。
また、決定部134は、ユーザからユーザの出発予定時刻、または、目的地への到着希望時刻の指定が受け付けられた場合に、ユーザにより指定された出発予定時刻、または、到着希望時刻に基づいて、設置位置を決定する。
これにより、第1の実施形態にかかる情報処理装置100は、よりユーザの希望を考慮したうえで仮想バス停を設置することができるため、ユーザの利便性を高めることができる。
また、決定部134は、ユーザの出発予定時刻から所定時間以内に移動体が到着可能な位置のうち、所定の位置を前記設置位置として決定する。
これにより、第1の実施形態にかかる情報処理装置100は、ユーザの利便性を高めることができる。
また、取得部132は、ユーザの属性情報として、ユーザの年齢情報、性別情報、健康状態に関する情報、身体障害に関する情報、乳幼児の有無に関する情報を取得する。
これにより、第1の実施形態にかかる情報処理装置100は、ユーザの属性情報を効果的に反映した設置位置を決定することができる。
また、第1の実施形態にかかる情報処理装置100は、提示部135を有する。提示部135は、決定部134により決定された設置位置に関する情報をユーザに提示する。
これにより、第1の実施形態にかかる情報処理装置100は、例えば、設置位置へとユーザを効果的に誘導することができるため、ユーザの利便性を高めることができる。
(第2の実施形態)
〔1.情報処理の一例〕
次に、図1を用いて、第2の実施形態にかかる情報処理の一例を示す。第2の実施形態にかかる情報処理システムは、情報処理装置200と、端末装置10とを含む。付図示であるが図2の例では、各ユーザ(ユーザU1、U2、U3)がそれぞれ端末装置10を所持する。第2の実施形態にかかる情報処理装置200は、図1で説明した情報処理装置SVの一例である。例えば、情報処理装置200は、サーバ装置やクラウドシステム等、単数または複数の装置により実現され、移動通信網や無線LAN(Local Area Network)等のネットワークを介して、ユーザが使用する端末装置10と通信可能な情報処理装置である。
図1で説明した通り、運行効率の悪化状況を回避できるよう、第2の情報処理装置200は、仮想バス停を設置可能な位置である設置可能位置を特定し、特定した設置可能位置に基づいて、設置位置を決定する。
〔2.情報処理装置の構成〕
次に、図10を用いて、第2の実施形態にかかる情報処理装置200について説明する。図10は、第2の実施形態にかかる情報処理装置200の構成例を示す図である。図10に示すように、情報処理装置200は、通信部110と、記憶部120と、制御部230とを有する。
第2の実施形態にかかる情報処理装置200は、第1の実施形態で説明した情報処理装置100がさらに特定部237を有するものである。したがって、図3で説明した記憶部および各理部については説明を省略する。
(制御部230について)
制御部230は、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、情報処理装置200内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部230は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
図10に示すように、制御部230は、受信部131と、取得部132と、算出部133と、決定部134と、提示部135と、指示部136、特定部237とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部230の内部構成は、図10に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部230が有する各処理部の接続関係は、図10に示した接続関係に限られず、他の接続関係であってもよい。
(特定部237について)
特定部237は、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置可能な位置である設置可能位置を特定する。例えば、特定部237は、移動体の運行状況に関する情報である運行情報に基づいて、設置可能位置を特定する。
また、特定部237は、移動体に乗車するための乗車地点に基づく所定の地点以外の地点を設置可能位置として特定する。例えば、特定部237は、所定の地点として、移動体に乗車するための乗車地点から所定距離以内に含まれる道路を除く道路上の地点を設置可能位置として特定する。例えば、特定部237は、所定の地点として、移動体に乗車するための乗車地点を中心とする所定の領域以外の領域に含まれる地点を設置可能位置として特定する。
また、決定部134は、特定部237により特定された設置可能位置に基づいて、仮想乗車地点を設置する設置位置を決定する。
〔3.情報処理における作用の一例〕
以下、図11に示すフローチャートを用いて、特定部237が実行・実現する処理の内容について説明する。図11は、第2の実施形態にかかる情報処理の一例を示すフローチャートである。また、適宜、図1の例を用いることにする。
まず、特定部237は、仮想乗車位置(例えば、仮想バス停)を設置不可能な領域を示す情報を取得する(ステップS201)。例えば、情報処理装置200は、仮想乗車位置(例えば、仮想バス停)を設置不可能な領域を示す情報として、バス停(既存バス停、仮想バス停のどちらでもよい)が存在する位置(バス停位置)を中心として、半径どれだけの領域を仮想バス停を設置不可能な領域とするか、といった情報を予め所定の記憶部に所持しているものとする。ここでは、特定部237は、バス停位置を中心として、半径Rの円領域を仮想バス停を設置不可能な領域とする情報を取得したものとする。
特定部237は、取得した情報に基づき、設置可能位置を特定する(ステップS202)。例えば、特定部237は、図1の例では、既存バス停ST1が存在する位置「S−PT1」を中心とする半径Rの円領域、および、既存バス停ST2が存在する位置「S−PT2」を中心とする半径Rの円領域以外の領域を設置可能位置として特定する。
なお、特定部237は、図1の例では、既存バス停ST1が存在する位置「S−PT1」、および、既存バス停ST2が存在する位置「S−PT2」から所定距離以内に含まれる道路を除く道路上の地点を設置可能位置として特定してもよい。
そして、決定部134は、特定部237により特定された設置可能位置に基づいて、仮想乗車地点を設置する設置位置を決定する(ステップS203)。設置位置を決定する処理について、第1の実施形態で説明した通りであるが、第2の実施形態では、決定部134は、特定部237により特定された設置可能位置を対象として設置位置を決定する。
例えば、決定部134は、一旦、希望位置DP11を設置位置として決定した場合、希望位置DP11が設置可能位置以外に位置していた場合には、希望位置DP11からより近い位置であって設置可能位置に含まれる位置を設置位置として決定する。
〔4.変形例〕
上記第2の実施形態にかかる情報処理装置200は、上記第2の実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、情報処理装置200の他の実施形態について説明する。
〔4−1.動的変更〕
特定部237は、移動体の運行状況に関する情報である運行情報に基づいて、設置可能位置を特定する。例えば、特定部237は、運行状況に基づいて、設置可能位置を動的に変更する。
上記例の様に、バス停位置を中心として、半径Rの円領域を仮想バス停を設置不可能な領域とする旨定められているとする。このような状態において、特定部237は、例えば、現在運行中のオンデマンドバスの運行状況を取得する。そして、特定部237は、取得した運行状況により、オンデマンドバスの運行スケジュールに遅延が発生している場合には、半径Rの長さを予め定められている所定値より長くする。すなわち、特定部237は、円領域の広さを拡大し、拡大した後の円領域以外の領域を設置可能位置として決定する。
このように、特定部237は、オンデマンドバスの運行スケジュールに遅延が発生している場合には、設置不可能な領域を拡大することにより、設置可能位置を狭く変更する。設置可能な領域が狭くなることにより、情報処理装置200は、より限られた位置にしか仮想バス停を設置することができなくなるため、仮想バス停が増えすぎることにより、運行スケジュールにより遅延が発生してしまうことを防止することができる。
〔4−2.乗車予約による設置可能位置特定〕
また、特定237は、ユーザから移動体への乗車予約が受け付けられた場合には、運行情報として、これまでの運行履歴に基づいて、設置可能位置を特定する。例えば、ユーザU1から翌日の「10時」において希望位置DP11からの乗車予約が受け付けられたとする。かかる場合、現時点では、希望位置DP11付近では、翌日どのような運行状況の変化が起こるかは不明である。
したがって、情報処理装置200は、これまでの運行履歴に基づいて、翌日の「10時」において希望位置DP11付近での運行状況を予測する。情報処理装置200は、これまでの運行履歴に基づいて、希望位置DP11付近で渋滞が発生する可能性があると予測したとする。渋滞が発生する中、仮想バス停を設置させてしまった場合、運行スケジュールの遅延の元となる。したがって、特定部237は、既存バス停ST1における円領域(設置不可能な領域)を拡大することにより、設置可能位置を変更することで、希望位置DP11(およびその付近)が設置位置として決定されないよう制御する。
これにより、第2の実施形態にかかる情報処理装置200は、乗車予約された場合であっても、運行状況が考慮された設置可能位置を特定することができる。
〔4−3.即時呼びによる設置可能位置特定〕
また、特定部237は、ユーザから、ユーザの現在位置への移動体の配車指示(即時呼び)が受け付けられた場合に、運行情報として、現在の運行状況に基づいて、設置可能位置を特定する。例えば、ユーザU1から、「15分後」において希望位置DP11付近に配車する旨の即時呼びが受け付けられたとする。
例えば、現在、希望位置DP11付近で渋滞が発生しているとする。渋滞が発生する中、仮想バス停を設置させてしまった場合、運行スケジュールの遅延の元となる。したがって、特定部237は、既存バス停ST1における円領域(設置不可能な領域)を拡大することにより、設置可能位置を変更することで、希望位置DP11(およびその付近)が設置位置として決定されないよう制御する。
これにより、第2の実施形態にかかる情報処理装置200は、即時呼びされた場合であっても、運行状況が考慮された設置可能位置を特定することができる。
〔4−4.ユーザ属性を考慮した処理〕
また、特定部237は、ユーザの属性情報に基づいて、設置可能位置を特定する。例えば、第1の実施形態でも示したようにユーザU1は身体的負担の大きい属性情報として健康状態「妊婦」を有する。ここで、ユーザU1により指定された希望位置DP11が設置不可能な領域に含まれていたとする。かかる場合、決定部134は、例外として、設置不可能な領域に含まれる希望位置DP11を設置位置として決定する。
これにより、第2の実施形態にかかる情報処理装置200は、属性情報に基づいて、ユーザの負担にならないよう設置位置を決定することができる。
〔5.効果〕
第2の実施形態にかかる情報処理装置200は、特定部237と、決定部134とを有する。特定部237は、移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置可能な位置である設置可能位置を特定する。決定部134は、特定部237により特定された設置可能位置に基づいて、仮想乗車地点を設置する設置位置を決定する。
これにより、第2の実施形態にかかる情報処理装置200は、移動体の運行効率の低下や、移動体の運行に要する費用の増大を効果的に抑えることができる。
また、特定部237は、移動体の運行状況に関する情報である運行情報に基づいて、設置可能位置を特定する。
これにより、第2の実施形態にかかる情報処理装置200は、高精度に設置可能位置を特定することができる。
また、特定部237は、移動体に乗車するための乗車地点に基づく所定の地点以外の地点を設置可能位置として特定する。
これにより、第2の実施形態にかかる情報処理装置200は、例えば、ある乗車地点に対して近すぎる位置に仮想乗車地点が設置されることを防止することができるため、移動体の運行効率の低下や、移動体の運行に要する費用の増大を効果的に抑えることができる。
また、特定部237は、所定の地点として、移動体に乗車するための乗車地点から所定距離以内に含まれる道路を除く道路上の地点を設置可能位置として特定する。
これにより、第2の実施形態にかかる情報処理装置200は、例えば、ある乗車地点に対して近すぎる位置に仮想乗車地点が設置されることを防止することができるため、移動体の運行効率の低下や、移動体の運行に要する費用の増大を効果的に抑えることができる。
また、特定部237は、所定の地点として、移動体に乗車するための乗車地点を中心とする所定の領域以外の領域に含まれる地点を設置可能位置として特定する。
これにより、第2の実施形態にかかる情報処理装置200は、例えば、ある乗車地点に対して近すぎる位置に仮想乗車地点が設置されることを防止することができるため、移動体の運行効率の低下や、移動体の運行に要する費用の増大を効果的に抑えることができる。
また、特定部237は、運行状況に基づいて、設置可能位置を動的に変更する。
これにより、第2の実施形態にかかる情報処理装置200は、より限られた位置にしか仮想バス停を設置することができなくなるため、仮想バス停が増えすぎることにより、運行スケジュールにより遅延が発生してしまうことを防止することができる。
また、特定部237は、ユーザから移動体への乗車予約が受け付けられた場合には、運行情報として、これまでの運行履歴に基づいて、設置可能位置を特定する。
これにより、第2の実施形態にかかる情報処理装置200は、乗車予約された場合であっても、運行状況が考慮された設置可能位置を特定することができる。
また、特定部237は、ユーザから、ユーザの現在位置への移動体の配車指示が受け付けられた場合に、運行情報として、現在の運行状況に基づいて、設置可能位置を特定する。
これにより、第2の実施形態にかかる情報処理装置200は、即時呼びされた場合であっても、運行状況が考慮された設置可能位置を特定することができる。
(第3の実施形態)
〔1.情報処理の一例〕
次に、図1を用いて、第3の実施形態にかかる情報処理の一例を示す。第3の実施形態にかかる情報処理システムは、情報処理装置300と、端末装置10とを含む。付図示であるが図1の例では、各ユーザ(ユーザU1、U2、U3)がそれぞれ端末装置10を所持する。第3の実施形態にかかる情報処理装置300は、図1で説明した情報処理装置SVの一例である。例えば、情報処理装置300は、サーバ装置やクラウドシステム等、単数または複数の装置により実現され、移動通信網や無線LAN(Local Area Network)等のネットワークを介して、ユーザが使用する端末装置10と通信可能な情報処理装置である。
図1で説明した通り、運行事業主は、例えば、いずれの時間帯もコンスタントにオンデマンドバスが利用されることを望む。このようなことから、情報処理装置300は、オンデマンドバスに対する利用意欲を高められるよう、ユーザに様々なインセンティブを付与する。
〔2.情報処理装置の構成〕
次に、図12を用いて、第3の実施形態にかかる情報処理装置300について説明する。図12は、第3の実施形態にかかる情報処理装置300の構成例を示す図である。図12に示すように、情報処理装置200は、通信部110と、記憶部120と、制御部330とを有する。
第3の実施形態にかかる情報処理装置300は、第1の実施形態で説明した情報処理装置100がさらに取得部337と、判定部338と、付与部339とを有するものである。したがって、図3で説明した記憶部および各理部については説明を省略する。また、情報処理装置300は、第2の実施形態にかかる特定部237も有してよい。
(制御部330について)
制御部330は、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、情報処理装置300内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部330は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
図12に示すように、制御部330は、受信部131と、取得部132と、算出部133と、決定部134と、提示部135と、指示部136と、取得部337と、判定部338と、付与部339とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部330の内部構成は、図12に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部330が有する各処理部の接続関係は、図12に示した接続関係に限られず、他の接続関係であってもよい。
(取得部337について)
取得部337は、移動体を利用したユーザの利用状況を取得する。例えば、取得部337は、移動体であるオンデマンドバスの内部に設置された各種のセンサを介して、移動体を利用したユーザの利用状況を取得する。
(判定部338について)
判定部338は、取得部337により取得された利用状況に基づき、所定の時間帯、または、所定の場所において、ユーザが移動体を利用したか否かを判定する。
(付与部339について)
付与部339は、取得部337により取得された利用状況に応じて、ユーザに対して、所定のインセンティブを付与する。判定部338は、取得部337により取得された利用状況に基づき、所定の時間帯、または、所定の場所において、ユーザが移動体を利用したか否かを判定するものであるため、付与部339は、判定部338による判定結果に応じて、ユーザに対して、所定のインセンティブを付与する。
また、付与部339は、判定部338により、所定の時間帯において、ユーザが移動体を利用したと判定された場合には、所定のインセンティブとして、所定の時間帯に移動体を利用するユーザの数である利用量に応じたインセンティブを付与する。例えば、付与部339は、利用量に応じたインセンティブとして、ユーザが移動体を利用したことにより支払う利用料金を定められた利用料金より低く定める。
〔3.情報処理における作用の一例〕
以下、図13に示すフローチャートを用いて、取得部337、判定部338、付与部339が実行・実現する処理の内容について説明する。図13は、第3の実施形態にかかる情報処理の一例を示すフローチャートである。また、適宜、図1の例を用いることにする。
まず、取得部337は、移動体を利用したユーザの利用状況を取得する(ステップS301)。ここでは、図1(b)に示すように、ユーザU1〜U3により指定された情報や属性情報に基づいて、設置位置が決定され、決定された設置位置からオンデマンドバスB1に乗車することでオンデマンドバスB1が利用されたものとする。取得部337は、例えば、オンデマンドバスB1内の各種のセンサを介して、オンデマンドバスB1の利用状況を取得することができる。例えば、取得部337は、ユーザがいつ、どこから、どの行き先(目的地)を基本路線とするオンデマンドバスに乗車したかといった利用状況を取得することができる。
図1(b)の例では、取得部337は、利用状況として、ユーザU1が「14時台」のオンデマンドバスB1を利用したことを取得する。また、図1(b)の例では、取得部337は、利用状況として、ユーザU2が「8時台」のオンデマンドバスB1を利用したことを取得する。また、図1(b)の例では、取得部337は、利用状況として、ユーザU3が「10時台」のオンデマンドバスB1を利用したことを取得する。
次に、判定部338は、取得部339により取得された利用状況に基づき、所定の時間帯において、ユーザが移動体を利用したか否かを判定する(ステップS302)。ここでの所定の時間とは、例えば、通勤ラッシュ等によりオンデマンドバスが混雑することが予め判明している時間帯(例えば、8時台〜9時台)である。所定の時間とは、オンデマンドバスの利用者がほとんどおらずオンデマンドバスが閑散としていることが予め判明している時間帯(例えば、10時台、14時台)である。
判定部338は、所定の時間帯において、ユーザが移動体を利用していない場合(ステップS302;No)には、ステップS301に戻る。一方、判定部338は、所定の時間帯において、ユーザが移動体を利用したと判定した場合(ステップS302;Yes)には、付与部339へと処理を移行する。
付与部339は、所定の時間帯において、ユーザが移動体を利用したと判定された場合(ステップS302;Yes)には、当該所定の時間帯に移動体を利用するユーザの数である利用量に応じたインセンティブを付与する(ステップS303)。例えば、付与部339は、利用量に応じたインセンティブとして、ユーザが移動体を利用したことにより支払う利用料金を、定められた利用料金より低く定める。
ここで、「14時台」においてオンデマンドバスB1が利用される利用量が、オンデマンドバスB1における1日の平均利用量と比較して少ないことが判明しているとすると、付与部339は、利用量の少ない「14時台」にユーザU1がオンデマンドバスB1を利用してくれたことに伴い、ユーザU1にインセンティブを付与する。例えば、付与部339は、ユーザU1が本来支払うべき運賃(300円とする)よりも、運賃を安く(250円)する。
また、「10時台」においてオンデマンドバスB1が利用される利用量が、オンデマンドバスB1における1日の平均利用量と比較して少ないことが判明しているとすると、付与部339は、利用量の少ない「10時台」にユーザU3がオンデマンドバスB1を利用してくれたことに伴い、ユーザU3にインセンティブを付与する。例えば、付与部339は、ユーザU3が本来支払うべき運賃(300円とする)よりも、運賃を安く(280円)する。
一方、付与部339は、通勤ラッシュ等によりオンデマンドバスB1が利用される利用量)が、オンデマンドバスB1における1日の平均利用量より多い時間「8時台」にオンデマンドバスB1を利用したユーザU2にはインセンティブを付与しない。
〔4.変形例〕
上記第3の実施形態にかかる情報処理装置300は、上記第3の実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、情報処理装置300の他の実施形態について説明する。
〔4−1.インセンティブについて(1)〕
付与部339は、利用量に応じたインセンティブとして、ユーザが移動体を利用したことにより支払う利用料金を、当該ユーザが移動体を利用して移動した移動距離に応じて変更しない定額の値と定める。例えば、図1に示すオンデマンドバスB1は、移動距離に応じて運賃が増加する距離従量制であるものとする。
かかる場合、付与部339は、ユーザU1が利用量が少ない「14時台」にオンデマンドバスB1を利用してくれたことに伴い、ユーザU1の運賃を移動距離に応じて増加させず、所定の運賃と定める。例えば、付与部339は、ユーザU1の移動距離の場合、運賃は「400円」であるところを、ユーザU1の初乗り運賃「300円」のままとする。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定の時間帯に移動体を利用すれば運賃がお得であるといった意識付けを行うことができるため、その時間帯に効果的に移動体を利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
なお、付与部339は、例えば、通勤ラッシュ等で混雑する時間帯は、通常通りの距離従量制を採用し、通勤ラッシュ等で混雑する時間帯以外の時間帯であれば、いずれの時間帯でも、運賃を所定の運賃のままとする、といったインセンティブを付与してもよい。
〔4−2.インセンティブについて(2)〕
また、付与部339は、判定部338により、所定の時間帯において、ユーザが移動体を利用したと判定された場合には、所定のインセンティブとして、所定の時間帯に移動体を利用するユーザの数である利用量に応じたポイントを付与する。
上記例では、付与部339が、利用量に応じて運賃を安くする、といったインセンティブを付与する例を示した。しかし、付与部339は、利用量に応じたポイントを付与してもよい。例えば、付与部339は、ユーザU1が利用量が少ない「14時台」にオンデマンドバスB1を利用してくれたことに伴い、所定額分の電子ポイントを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定の時間帯に移動体を利用すれば買い物に利用できるポイントが付与されるといった意識付けを行うことができるため、その時間帯に効果的に移動体を利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
〔4−3.インセンティブについて(3)〕
これまでの例では、付与部339が、金銭に関するインセンティブを付与する例を示した。しかし、付与部339は、移動体の移動ルートに関するインセンティブを付与してもよい。具体的には、付与部339は、判定部338により、所定の時間帯において、ユーザが移動体を利用したと判定された場合には、所定のインセンティブとして、ユーザに応じて、移動体の移動ルートを制御する。例えば、付与部339は、所定のインセンティブとして、ユーザに指定された目的地により近付くよう移動体の移動ルートを制御する。
例えば、ユーザU1が利用量が少ない「14時台」にオンデマンドバスB1を利用したとする。また、ユーザU1は、情報処理装置300に対して、予め目的地「T大学」を指定していたものとする。また、「14時台」はオンデマンドバスB1の利用量が少ないことにより、オンデマンドバスB1は、運行ルートを比較的柔軟に変更することができる。具体的には、オンデマンドバスB1は、利用量が少ない「14時台」であれば、基本路線から外れた迂回ルートとして、どのような迂回ルートを選択するか自由度が高い。
このようなことから、付与部339は、ユーザU1に応じて、すなわちユーザU1の目的地「T大学」に応じて、オンデマンドバスB1の移動ルートを制御する。例えば、付与部339は、オンデマンドバスB1がユーザU1の目的地「T大学」を通過しない(基本路線に含まない)バスであったとしても、例えば、目的地「T大学」へ向かうようオンデマンドバスB1の移動ルートを変更する、といったインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定の時間帯では移動体は目的地の要望によく応えてくれるといった意識付けを行うことができるため、その時間帯に効果的に移動体を利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
〔4−4.インセンティブについて(4)〕
また、判定部338は、取得部337により取得された利用状況に基づき、ユーザが所定のルートを走行する移動体を利用したか否かを判定する。そして、付与部339は、判定部338によりユーザが所定のルートを走行する移動体を利用したと判定された場合には、当該ユーザに対して、所定のインセンティブを付与する。例えば、付与部339は、判定部338により、所定の地点を目的地とするルートのうち、当該目的地までの距離がより長いルートを走行する移動体をユーザが利用したと判定された場合に、ユーザに対して、所定のインセンティブを付与する。
ここで、イベント会場「ホールH」と、「C駅」との間をシャトル運行するオンデマンドバスとして、オンデマンドバスB2およびB3を例に挙げる。また、双方とも目的地(ホールH)および出発地(C駅)は共通しているものの、これらを繋ぐ運行ルートは異なるものとする。例えば、オンデマンドバスB3が走行する基本路線は、オンデマンドバスB2が走行する基本路線よりも長いものとする。言い換えれば、オンデマンドバスB3は、オンデマンドバスB2と比べて、より遠回りする運行ルートを走行する。
また、現在時刻「20時30分」であり、「ホールH」で行われたイベント終了し、オンデマンドバスB3より短時間で「C駅」に着くことができるオンデマンドバスB2は大混雑している一方で、オンデマンドバスB3は比較的空いているものとする。
このような状態において、取得部337は、オンデマンドバスB2およびB3から各ユーザの利用状況を取得する。また、判定部338は、取得部337により取得された利用状況に基づき、「20時台」においてどのユーザがオンデマンドバスB2に乗り、どのユーザがオンデマンドバスB3に乗ったかを判定する。ここで、判定部338は、例えば、50人のユーザがオンデマンドバスB2に乗り、ユーザU5およびU6の2人のユーザがオンデマンドバスB3に乗ったと判定したとする。
かかる場合、付与部339は、遠回りのオンデマンドバスB3を利用したユーザU5およびU6に所定のインセンティブを付与する。多くのユーザは、混雑していてもより早く「C駅」に到着できるオンデマンドバスB2を利用する傾向にあるが、その中でオンデマンドバスB3を利用してくれたことへのインセンティブとして、付与部339は、オンデマンドバスB3を利用したユーザU5およびU6に所定のインセンティブを付与する。また、このインセンティブには、オンデマンドバスB2の混雑解消に貢献したことへの意味合いも含まれる。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定のルートを走行する移動体を利用すればインセンティブが付与されるといった意識付けを行うことができるため、そのルートを走行する移動体を効果的に利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
なお、上記例では、提示部135が、オンデマンドバスB3に乗車した場合、所定のインセンティブを付与する(例えば、運賃を規定料金から安くする)旨、各ユーザに提示することにより、オンデマンドバスB3の利用を提案してもよい。
〔4−5.インセンティブについて(5)〕
また、付与部339は、ユーザが所定の目的地へと向かう移動体を利用した場合に、当該所定の目的地に関連するインセンティブを付与する。例えば、この目的地で、イベントVが開催される予定である場合、提示部135は、予めイベントVに関するイベント情報をユーザに提示する。
そして、判定部338は、このイベント情報が提示されたユーザが、イベントVへ向かうオンデマンドバスを利用したか否かを判定する。そして、付与部339は、イベントVへ向かうオンデマンドバスを利用したと判定されたユーザに対して、所定のインセンティブを付与する。例えば、付与部339は、イベントVへ向かうオンデマンドバスに利用可能なクーポン、イベントVが行われる会場付近の店舗で利用可能なクーポンをインセンティブとして付与する。
また、付与部339は、イベントVが行われる会場付近の店舗で利用可能なクーポンをインセンティブとして付与するのではなく、イベントVへ向かうオンデマンドバスを利用したうえで、かかる店舗でショッピングや食事を行ったユーザに対して、帰りの際のオンデマンドバスの運賃を規定料金より安くする、といったインセンティブを付与してもよい。
これにより、第3の実施形態にかかる情報処理装置300は、移動体の移動体の利用者を増やすことができるとともに、目的地に関連する事業の売上に貢献することができる。
〔4−6.インセンティブのための情報提示〕
提示部135は、インセンティブに関する情報を提示する。例えば、提示部135は、移動体を利用した場合に付与されるインセンティブに関する情報を提示する。一例として、変形例「4−1」の例を用いて説明すると、提示部135は、端末装置10に乗車案内アプリAPをインストールしているユーザに対して、どのような時間帯にオンデマンドバスを利用すればどのようなインセンティブが得られるか、といったインセンティブに関する情報を予め提示する。また、この例に限らず、提示部135は、移動体をどのように利用すれば、どのようなインセンティブが付与されるかを予め提示することができる。
これにより、第3の実施形態にかかる情報処理装置300は、インセンティブの付与対象となる行動を起こさせる動機付けを行うことができる。
〔5.効果〕
第3の実施形態にかかる情報処理装置300は、取得部337と、付与部339とを有する。取得部337は、移動体を利用したユーザの利用状況を取得する。付与部339は、取得部337により取得された利用状況に応じて、ユーザに対して、所定のインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、第3の実施形態にかかる情報処理装置300は、判定部338を有する。判定部338は、取得部337により取得された利用状況に基づき、所定の時間帯、または、所定の場所において、ユーザが移動体を利用したか否かを判定する。また、付与部339は、判定部338による判定結果に応じて、ユーザに対して、所定のインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、所定の時間帯、または、所定の場所に応じて、インセンティブを付与することができる。
また、付与部339は、判定部338により、所定の時間帯において、ユーザが移動体を利用したと判定された場合には、所定のインセンティブとして、所定の時間帯に移動体を利用するユーザの数である利用量に応じたインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、例えば、所定の時間帯での移動体の利用者が少ない場合、その所定の時間帯における移動体の利用者を効果的に増やすことができる。また、情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、利用量に応じたインセンティブとして、ユーザが移動体を利用したことにより支払う利用料金を、定められた利用料金より低く定める。
これにより、第3の実施形態にかかる情報処理装置300は、例えば、所定の時間帯での移動体の利用者が少ない場合、その所定の時間帯における移動体の利用者を効果的に増やすことができる。また、情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、利用量に応じたインセンティブとして、ユーザが移動体を利用したことにより支払う利用料金を、ユーザが移動体を利用して移動した移動距離に応じて変更しない定額の値と定める。
これにより、第3の実施形態にかかる情報処理装置300は、例えば、所定の時間帯での移動体の利用者が少ない場合、その所定の時間帯における移動体の利用者を効果的に増やすことができる。また、情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、判定部338により、所定の時間帯において、ユーザが移動体を利用したと判定された場合には、所定のインセンティブとして、所定の時間帯に移動体を利用するユーザの数である利用量に応じたポイントを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定の時間帯に移動体を利用すれば買い物に利用できるポイントが付与されるといった意識付けを行うことができるため、その時間帯に効果的に移動体を利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、判定部338により、所定の時間帯において、ユーザが移動体を利用したと判定された場合には、所定のインセンティブとして、ユーザに応じて、移動体の移動ルートを制御する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定の時間帯では移動体は目的地の要望によく応えてくれるといった意識付けを行うことができるため、その時間帯に効果的に移動体を利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、所定のインセンティブとして、ユーザに指定された目的地により近付くよう移動体の移動ルートを制御する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定の時間帯では移動体は目的地の要望によく応えてくれるといった意識付けを行うことができるため、その時間帯に効果的に移動体を利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、判定部338は、取得部337により取得された利用状況に基づき、ユーザが所定のルートを走行する移動体を利用したか否かを判定する。そして、付与部339は、判定部338によりユーザが所定のルートを走行する移動体を利用したと判定された場合には、当該ユーザに対して、所定のインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定のルートを走行する移動体を利用すればインセンティブが付与されるといった意識付けを行うことができるため、そのルートを走行する移動体を効果的に利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、判定部338により、所定の地点を目的地とするルートのうち、当該目的地までの距離がより長いルートを走行する移動体をユーザが利用したと判定された場合に、ユーザに対して、所定のインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、ユーザに対して、所定のルートを走行する移動体を利用すればインセンティブが付与されるといった意識付けを行うことができるため、そのルートを走行する移動体を効果的に利用させることができる。この結果、第3の実施形態にかかる情報処理装置300は、移動体が利用される利用状況を平滑化することができる。
また、付与部339は、ユーザが所定の目的地へと向かう移動体を利用した場合に、当該所定の目的地に関連するインセンティブを付与する。
これにより、第3の実施形態にかかる情報処理装置300は、移動体の移動体の利用者を増やすことができるとともに、目的地に関連する事業の売上に貢献することができる。
提示部135は、移動体を利用した場合に付与されるインセンティブに関する情報を提示する。
これにより、第3の実施形態にかかる情報処理装置300は、インセンティブの付与対象となる行動を起こさせる動機付けを行うことができる。
(第4の実施形態)
〔1.乗車意図判定処理の一例〕
上記各実施形態では、例えば、情報処理装置100、200および300が、ユーザの属性情報を取得し、取得した属性情報に基づいて、ユーザが移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する例を示した。しかし、情報処理装置100、200および300の機能を有する情報処理装置400は、設置位置を決定する前に、次のような乗車意図判定処理を行ってよい。具体的には、情報処理装置400は、移動体に乗車するための乗車地点を示す乗車位置情報と、ユーザの現在位置を示すユーザ位置情報との間での位置関係を取得する。そして、情報処理装置400は、取得した位置関係と、ユーザの行動を示す行動情報とに基づいて、ユーザが移動体に乗車する意図があるか否かを判定する。この点について、図14の例を用いて説明する。なお。情報処理装置400は、乗車意図判定装置とも言い換えることができる。
図14は、第4の実施形態にかかる乗車意図判定処理の一例を示す図である。第4の実施形態にかかる乗車意図判定システムは、乗車意図判定装置400と、端末装置10とを含む。第4の実施形態にかかる乗車意図判定処理は、図14に示す情報処理装置400によって行われる。例えば、情報処理装置400は、サーバ装置やクラウドシステム等、単数または複数の装置により実現され、移動通信網や無線LAN等のネットワークを介して、ユーザが使用する端末装置10と通信可能な情報処理装置である。
ここで、第4の実施形態にかかる情報処理装置400が以下に示す乗車意図判定処理を行うにあたっての前提について説明する。まず、本実施形態において情報処理装置400が対象とする移動体は「オンデマンドバス」であるものとする。第4の実施形態にかかるオンデマンドバスは、路線バスの一種であるが、ユーザがインターネット等の通信手段を用いて手続きを行った場合に、例えば、基本路線の外の迂回路線を経由して、例えば、仮想的に設置されたバス停留所へとユーザを迎えに行く。基本路線に存在する従来からの物理的なバス停留所(既存バス停)に対して、このように仮想的に設置されるバス停留所を「仮想バス停」とする。
情報処理装置400は、ユーザの属性情報、道路情報、交通状況等を加味して、任意の位置に仮想バス停を設置し、設置した仮想バス停へとオンデマンドバスを向かわせることができる。しかしながら、オンデマンドバスが基本路線から迂回して、仮想バス停へと向かったにも拘らず、本来乗車するはずのユーザがおらず、無駄足となってしまう場合がある。すなわち、オンデマンドバスの運行効率が悪くなる。このような状況を解決するためには、ユーザがオンデマンドバスに乗車する意図があるか否かを精度よく判定する必要がある。そして、ユーザがオンデマンドバスに乗車する意図がある場合に、ユーザが利用しやすい位置に「仮想バス停」を設置し、設置した位置へとユーザを誘導する必要がある。
以上のような前提を踏まえて、第4の実施形態にかかる情報処理装置400は、移動体に乗車するための乗車地点を示す乗車位置情報と、ユーザの現在位置を示すユーザ位置情報との間での位置関係を取得し、取得した位置関係と、ユーザの行動を示す行動情報とに基づいて、ユーザが移動体に乗車する意図があるか否かを判定する。
具体的には、情報処理装置400は、位置関係が所定の条件情報を満たす場合に、ユーザが移動体に乗車する意図があると判定する。また、情報処理装置400は、ユーザの行動を示す行動情報が所定の条件情報を満たす場合に、ユーザが移動体に乗車する意図があると判定する。上記2つの条件、すなわち位置関係に関する条件情報、および、行動情報に関する条件情報については後述する。また、移動体は、オンデマンドバスであるものとする。また、移動体に乗車するための乗車地点は、オンデマンドバスに乗車するための物理的なバス停留所、すなわち既存バス停であるものとする。また、乗車位置情報は、既存バス停が位置する位置情報(既存バス停位置)であるものとする。以下では、図14を用いて、乗車意図判定処理の一例について説明する。
まず、図1に示すMAP1について説明する。MAP1は、乗車案内アプリAPを利用するユーザU1の周辺地図を示す。MAP1において、既存バス停ST1が位置する位置情報(乗車位置情報の一例)は、「S−PT1」である。また、MAP1において、既存バス停ST2が位置する位置情報(乗車位置情報の一例)は、「S−PT2」である。また、MAP1において、乗車案内アプリAPを利用するユーザU1の現在位置は「U−HP11」である。また、MAP1において、オンデマンドバスB1の現在位置を示す位置情報は、「B−PT1」である。また、MAP1において、オンデマンドバスB1が走行する基本路線RT20(20系統の路線、と言い換えることもできる)は、点線で示される。
このような状態において、情報処理装置400は、ユーザU1が乗車案内アプリAPを起動したか否かを判定する。なお、ここでは、説明を簡単にするために、端末装置10は、乗車案内アプリAPを起動するようユーザU1から指示を受け付けた場合に、予めユーザU1にお気に入り登録されている既存バス停に関する情報を表示画面Dに表示するものとする。図14に示すように、端末装置10は、ユーザU1にお気に入り登録されている3つ既存バス停の名称(バス停ST1、バス停ST2、バス停ST3)と、この各バス停それぞれについて、オンデマンドバスB1が到着するまでの残り時間をリアルタイムでカウントダウン表示する。
なお、このような表示が可能となるのは、情報処理装置400によって次の処理が行われるためである。例えば、情報処理装置400は、端末装置10からの要求に応じて、お気に入り登録されている各既存バス停に停留するオンデマンドバスを判定し、判定したオンデマンドバスの現在位置情報をリアルタイムで随時取得する。そして、情報処理装置400は、オンデマンドバスの現在位置、既存バス停位置、および、オンデマンドバスの運行速度に基づき、残り時間を算出する。そして、情報処理装置400は、算出した残り時間をカウントダウン表示するよう端末装置10に返す。
次に、情報処理装置400は、乗車意図判定処理を行う(ステップS41)。情報処理装置400は、既存バス停位置と、ユーザU1の現在位置との位置関係が所定の条件情報(位置関係に関する条件情報)を満たすか否かを判定する。具体的には、情報処理装置400は、所定の条件情報として、既存バス停位置と、ユーザU1の現在位置との距離が所定距離以内であるか否かを判定する。また、本実施形態では、かかる所定距離を、ユーザU1の現在位置から既存バス停位置までの移動にユーザU1が要する時間がこの既存バス停位置にオンデマンドバスB1が到着するまでの時間より短い時間と予測される距離であるものとする。
例えば、情報処理装置400は、お気に入り登録された既存バス停ST1〜ST3の位置情報とユーザU1の現在位置情報とを取得することにより、既存バス停ST1〜ST3それぞれの位置情報とユーザU1の現在位置情報との位置関係を取得する。図1の例では、情報処理装置400は、既存バス停ST1〜ST3のうち、既存バス停ST1およびST2の位置情報とユーザU1の現在位置情報との位置関係が、上記位置関係に関する条件情報を満たすと判定したとする。
また、情報処理装置400は、ユーザU1の行動を示す行動情報が所定の条件情報(行動情報に関する条件情報)を満たすか否かを判定する。具体的には、情報処理装置400は、所定の条件情報として、位置関係に関する条件情報を満たすと判定された既存バス停ST1およびST2のうちいずれかの既存バス停にオンデマンドバスB1が到着するまでの時間を示す時間情報、すなわちカウントダウン表示をユーザU1が閲覧したか否かを判定する。また、情報処理装置400は、所定の条件情報として、カウントダウン表示をユーザU1が閲覧した状態で、ユーザU1が既存バス停ST1またはST2に向かって移動を開始したか否かを判定する。
例えば、情報処理装置400は、ユーザU1の現在位置情報をリアルタイムで随時取得し、ユーザU1の現在位置の変化を分析することにより、ユーザU1が移動を開始したか否か、移動を開始した場合には、どの方向に移動しているかを判定する。図14の例では、情報処理装置400は、ユーザU1が既存バス停ST1に向かって移動を開始したと判定したものとする。
さて、これまで説明してきた通り、情報処理装置400は、位置関係に関する条件情報、および、行動情報に関する条件情報の双方を満たす場合に、ユーザU1がオンデマンドバスB1に乗車する意図があると判定する。したがって、図14の例では、情報処理装置400は、ユーザU1がオンデマンドバスB1に乗車する意図があると判定する。
次に、情報処理装置400は、ユーザU1に対して乗車意図があると判定したことにより、仮想バス停を設置する設置位置を決定するための情報処理を行う(ステップS42)。かかる情報処理は、図1(a)および図2を用いて説明した情報処理に相当する。例えば、情報処理装置400は、ユーザU1の属性情報を取得し、取得した属性情報に基づいて、ユーザU1が移動体に乗車するための乗車地点であって仮想の乗車地点である仮想乗車地点を設置する設置位置を決定する。例えば、情報処理装置400は、ユーザの移動距離と、ユーザ属性情報とに基づいて、ユーザがその移動距離を移動することに要するコストである移動コストを算出する。そして、情報処理装置400は、算出した移動コストに基づいて、設置位置を決定する。図14の例では、情報処理装置400は、ユーザU1により指定された希望位置「DP11」を設置位置として決定した例を示す。
他の例としては、情報処理装置400は、ユーザU1の属性情報、ユーザU1の現在位置周辺(例えば、ユーザU1の現在位置を中心とする半径200m以内のエリア)における道路情報、ユーザU1の現在位置周辺における交通情報に基づいて、設置位置を決定してもよい。一例を示すと、ユーザU1は既存バス停ST1に向かって移動していることから、情報処理装置400は、ユーザU1の現在位置から仮想バス停位置までの距離が、ユーザU1の現在位置から既存バス停ST1の位置までの距離より短くなるよう仮想バス停位置を決定してもよい。
また、情報処理装置400は、設置位置を決定すると、決定した設置位置からオンデマンドバスB1に乗車可能であることをユーザU1に提示する(ステップS43)。例えば、情報処理装置400は、設置位置からオンデマンドバスB1に乗車可能であることを示す情報として、図14に示すように、「もっと近くから乗車できます」と表示されたボタンBT1を表示するよう端末装置10を制御する。また、不図示であるが、情報処理装置400は、オンデマンドバスB1に対して、設置位置として決定した希望位置「DP11」の位置するルートRT20へと迂回して走行するよう指示する。
さて、これまで説明してきたように、第4の実施形態にかかる情報処理装置400は、移動体に乗車するための乗車地点を示す乗車位置情報と、ユーザの現在位置を示すユーザ位置情報との間での位置関係を取得し、取得した位置関係と、ユーザの行動を示す行動情報とに基づいて、ユーザが移動体に乗車する意図があるか否かを判定する。
これにより、第4の実施形態にかかる情報処理装置400は、乗車意図のあるユーザを高精度に判定することができるため、例えば、迂回したにも拘らず、迂回先の地点にユーザがおらず無駄足になるといった状況を効果的に回避することができる。この結果、情報処理装置400は、ユーザを効率よく目的地へ運ぶことがきでる。
また、第4の実施形態にかかる情報処理装置400は、既存バス停位置よりも近い位置に仮想バス停を設置することができる場合があるため、バス停までの移動距離を短縮することができる。すなわち、情報処理装置400は、ユーザに対してオンデマンドバスを利用する利便性を高めることができる。
〔2.情報処理装置の構成〕
次に、図15を用いて、第4の実施形態にかかる情報処理装置400について説明する。図15は、第4の実施形態にかかる情報処理装置400の構成例を示す図である。図14に示すように、情報処理装置400は、通信部110と、記憶部120と、制御部430とを有する。
第4の実施形態にかかる情報処理装置400は、第1の実施形態で説明した情報処理装置100がさらに位置関係取得部437と、乗車意図判定部438とを有するものである。したがって、上記各実施形態と重複する処理部については説明を省略する。
(制御部430について)
制御部430は、CPUやMPU等によって、情報処理装置300内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部330は、例えば、ASICやFPGA等の集積回路により実現される。
図15に示すように、制御部430は、受信部131と、取得部132と、算出部133と、決定部134と、提示部135と、指示部136と、位置関係取得部437と、乗車意図判定部438とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部430の内部構成は、図15に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部430が有する各処理部の接続関係は、図15に示した接続関係に限られず、他の接続関係であってもよい。
(位置関係取得部437について)
位置関係取得部437は、移動体に乗車するための乗車地点を示す乗車位置情報と、ユーザの現在位置を示すユーザ位置情報との間での位置関係を取得する。また、位置関係取得部437は、移動体の現在位置を示す移動***置情報も取得してよい。また、位置関係取得部437は、取得した情報に基づいて、ユーザに提示するための情報を算出することもできる。図15の例を用いて説明すると、位置関係取得部437は、既存バス停ST1〜ST3それぞれにオンデマンドバスB1が到着するまでの残り時間を算出することができる。なお、位置関係取得部437による取得処理は、例えば、取得部132によって行われてもよい。
(乗車意図判定部438について)
乗車意図判定部438は、位置関係取得部437により取得された位置関係と、ユーザの行動を示す行動情報とに基づいて、ユーザが移動体に乗車する意図があるか否かを判定する。具体的には、乗車意図判定部438は、位置関係取得部437により取得された位置関係が所定の条件情報を満たす場合に、ユーザが前記移動体に乗車する意図があると判定する。
例えば、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点と前記ユーザの現在位置との距離が所定距離以内である場合に、ユーザが前記移動体に乗車する意図があると判定する。この点についてより詳細に説明すると、乗車意図判定部438は、所定距離として、ユーザの現在位置から乗車地点までの移動にユーザが要する時間が所定時間内と予測される距離以内である場合に、ユーザが移動体に乗車する意図があると判定する。また、この所定時間は、乗車地点に移動体が到着するまでの時間である。
また、乗車意図判定部438は、ユーザの行動を示す行動情報が所定の条件情報を満たす場合に、ユーザが移動体に乗車する意図があると判定する。具体的には、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点に関するコンテンツをユーザが閲覧した場合に、ユーザが移動体に乗車する意図があると判定する。
また、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点のうち、ユーザの現在位置との距離が所定距離以内の乗車地点に移動体が到着するまでの時間を示す時間情報をユーザが閲覧した場合に、ユーザが移動体に乗車する意図があると判定する。より具体的には、判定部133は、上記時間情報をユーザが閲覧した状態で、当該ユーザが移動体に乗車するための乗車地点に向かって移動を開始した場合に、当該ユーザが移動体に乗車する意図があると判定する。
〔3.乗車意図判定処理における作用の一例〕
以下、図16に示すフローチャートを用いて、各処理部(特に、位置関係取得部437、乗車意図判定部438)が実行・実現する処理の内容について説明する。図16は、第4の実施形態にかかる乗車意図判定処理の一例を示すフローチャートである。また、適宜、図14の例を用いることにする。
まず、受信部131は、各ユーザの端末装置10から、乗車案内アプリAPが起動された旨の情報を受信したか否かを判定する(ステップS101)。受信部131は、乗車案内アプリAPが起動された旨の情報を受信していない場合には(ステップS101;No)、受信するまで待機する。ここで、例えば、受信部131は、ユーザU1の端末装置10から、乗車案内アプリAPが起動された旨の情報を受信したものとする。
ここで、ユーザU1は、乗車案内アプリAP内において、既存バス停ST1、ST2およびST3(ST1〜ST3)をお気に入り登録しているものとする。位置関係取得部437は、受信部131によって乗車案内アプリAPが起動された旨の情報が受信された場合には(ステップS101;Yes)、既存バス停ST1〜ST3に停留するオンデマンドバスを判定し、判定したオンデマンドバスの現在位置情報をリアルタイムで随時取得する。そして、位置関係取得部437は、既存バス停ST1〜ST3停留すると判定したオンデマンドバスB1の現在位置、既存バス停ST1〜ST3それぞれの位置情報、および、オンデマンドバスB1の運行速度に基づき、既存バス停ST1〜ST3それぞれにオンデマンドバスB1が到着するまでの残り時間を算出する。
提示部136は、図14に示すように、既存バス停ST1〜ST3それぞれにオンデマンドバスB1が到着するまでの残り時間がカウントダウン表示されるよう制御されたコンテンツ(お気に入り画面)を端末装置10に配信する。
このような状態において、乗車意図判定部438は、乗車意図判定処理として、ユーザU1が定められた条件情報を満たすか否かを判定する。まず、位置関係取得部437は、オンデマンドバスB1に乗車するための乗車地点である既存バス停ST1〜ST3それぞれの位置情報(総称して、既存バス停位置とする)と、ユーザU1の現在位置情報との間での位置関係を取得する(ステップS102)。なお、位置関係取得部437が既存バス停位置の位置情報を取得できるよう、情報処理装置400は、自装置内の所定の記憶部に既存バス停位置の位置情報を記憶しておくことができる。
次に、乗車意図判定部438は、乗車意図判定処理として、ユーザU1が定められた条件情報を満たすか否かを判定する(ステップS103)。具体的には、乗車意図判定部438は、既存バス停位置と、ユーザU1の現在位置との位置関係が所定の条件情報(位置関係に関する条件情報)を満たすか否かを判定する。具体的には、乗車意図判定部438は、所定の条件情報として、既存バス停位置と、ユーザU1の現在位置との距離が所定距離以内であるか否かを判定する。より具体的には、乗車意図判定部438は、所定距離として、ユーザの現在位置から既存バス停位置までの移動にユーザU1が要する時間が所定時間内と予測される距離であるか否かを判定する。また、この所定時間は、例えば、既存バス停位置にオンデマンドバスB1が到着するまでの時間である。ここでは、乗車意図判定部438は、既存バス停ST1〜ST3のうち、既存バス停ST1およびST2の位置情報とユーザU1の現在位置情報との位置関係が、上記位置関係に関する条件情報を満たすと判定したとする。
また、乗車意図判定部438は、ユーザU1の行動を示す行動情報が所定の条件情報(行動情報に関する条件情報)を満たすか否かを判定する。具体的には、乗車意図判定部438は、所定の条件情報として、位置関係に関する条件情報を満たすと判定された既存バス停ST1およびST2のうちいずれかの既存バス停にオンデマンドバスB1が到着するまでの時間を示す時間情報、すなわちカウントダウン表示をユーザU1が閲覧したか否かを判定する。より具体的には、乗車意図判定部438は、所定の条件情報として、カウントダウン表示をユーザU1が閲覧した状態で、ユーザU1が既存バス停ST1またはST2に向かって移動を開始したか否かを判定する。ここでは、乗車意図判定部438は、ユーザU1が既存バス停ST1に向かって移動を開始したと判定したとする。
ここでの例では、乗車意図判定部438は、位置関係に関する条件情報、および、行動情報に関する条件情報の双方が満たされることにより、ユーザU1がオンデマンドバスB1に乗車する意図があると判定する。なお、乗車意図判定部438は、条件情報を満たさないと判定した場合には(ステップS103;No)、条件情報を満たすまで待機する。あるいは、乗車意図判定部438は、条件情報を満たさないと判定した場合には(ステップS103;No)、処理を終了してもよい。決定部134は、判定部133によりユーザU1がオンデマンドバスB1に乗車する意図があると判定されたことに応じて(ステップS103;Yes)、仮想バス停を設置する位置を決定するための情報処理(設置位置決定)を行う(ステップS104)。設置位置決定処理の詳細な処理手順については、図8で説明した通りであり、例えば、取得部132、算出部133および決定部134によって行われる一連の情報処理に相当する。ここでは、決定部134は、図14の例で説明したように、ユーザU1により指定された希望位置「DP11」を設置位置として決定したものとする。
かかる場合、提示部136は、決定部134により決定された設置位置「DP11」からオンデマンドバスB1に乗車可能であることをユーザU1に提示する(ステップS105)。例えば、提示部136は、設置位置「DP11」からオンデマンドバスB1に乗車可能であることを示す情報として、図14に示すように、「もっと近くから乗車できます」と表示されたボタンBT1を表示制御する。そして、提示部136は、表示制御されたボタンBT1を、図14に示すように、既存バス停ST1に関する情報と既存バス停ST2に関する情報との間に表示させる。
このような状態において、提示部136は、設置位置「DP11」に関する詳細な情報をユーザが希望したか否かを判定する(ステップS106)。言い換えると、提示部136は、ユーザU1がボタンBT1を押下したか否かを判定する。提示部136は、ボタンBT1が押下されないと判定した場合には(ステップS106;No)、処理を終了する。一方、提示部136は、ボタンBT1が押下されたと判定した場合には(ステップS106;Yes)、ユーザU1に対して、設置位置「DP11」から乗車する旨の意志表示を行わせるためのコンテンツ(コンテンツCとする)を配信する(ステップS107)。
例えば、ユーザU1は、コンテンツCを介して、情報処理装置400に対して、設置位置「DP11」から乗車する旨の意志があることを意思表示することができる。したがって、提示部136は、乗車の意志表示を受け付けたか否かを判定する(ステップS108)。提示部136は、意思表示を受け付けていないと判定した場合には(ステップS108;No)、処理を終了する。一方、提示部136は、意思表示を受け付けたと判定した場合には(ステップS108;Yes)、設置位置「DP11」に関する案内情報を提示する(ステップS109)。例えば、提示部136は、案内情報として、ユーザU1の現在位置「HP11」から希望位置「DP11」までの移動ルートGDを表示させる。
また、不図示であるが、決定部134は、意思表示が受け付けられた場合には、希望位置「DP11」に仮想バス停を設置する旨最終決定し、この位置に実際に仮想バス停を出現させる。また、決定部134により、このように仮想バス停が出現させられたことにより、情報処理装置400は、ユーザU1以外の他のユーザ(例えば、「乗車案内アプリAP」を端末装置10にインストールしている他のユーザ)からも位置「DP11」に仮想バス停が設置されていることや、かかる他のユーザからも位置「DP11」からの乗車希望を行えるよう制御する。
〔4.効果〕
第4の実施形態にかかる情報処理装置400は、位置関係取得部437と、乗車意図判定部438とを有する。位置関係取得部437は、移動体に乗車するための乗車地点を示す乗車位置情報と、ユーザの現在位置を示すユーザ位置情報との間での位置関係を取得する。乗車意図判定部438は、位置関係取得部437により取得された位置関係と、ユーザの行動を示す行動情報とに基づいて、ユーザが移動体に乗車する意図があるか否かを判定する。
これにより、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができるため、移動体の運行効率を高めることができる。
また、乗車意図判定部438は、位置関係取得部437により取得された位置関係が所定の条件情報を満たす場合に、ユーザが移動体に乗車する意図があると判定する。
これにより、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
また、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点とユーザの現在位置との距離が所定距離以内である場合に、ユーザが移動体に乗車する意図があると判定する。
例えば、ユーザが移動体の乗車地点付近に位置する場合、かかるユーザは移動体に乗車する可能性が高い。したがって、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
また、乗車意図判定部438は、所定距離として、ユーザの現在位置から乗車地点までの移動にユーザが要する時間が所定時間内と予測される距離以内である場合に、ユーザが移動体に乗車する意図があると判定する。
例えば、ユーザが移動体の乗車地点までの移動に要する時間が所定時間内と予測される距離に居る場合、かかるユーザは移動体に乗車する可能性が高い。したがって、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
また、乗車意図判定部438は、距離として、乗車地点に移動体が到着するまでの時間が所定時間内と予測される距離以内である場合に、ユーザが移動体に乗車する意図があると判定する。
例えば、乗車地点に移動体が到着するまでの時間よりも早い時間で、このバス停に到着可能な距離位置にユーザが居る場合、このユーザは、移動体に乗車する可能性が高い。したがって、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
また、乗車意図判定部438は、ユーザの行動を示す行動情報が所定の条件情報を満たす場合に、ユーザが移動体に乗車する意図があると判定する。
これにより、第4の実施形態にかかる情報処理装置400は、位置関係に関する条件情報に加えて、ユーザの行動情報に関する条件情報も考慮することで、乗車意図があるか否かを高より精度に判定することができる。
また、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点に関するコンテンツをユーザが閲覧した場合に、ユーザが移動体に乗車する意図があると判定する。
移動体に乗車するための乗車地点に関するコンテンツを閲覧するユーザは、移動体に乗車しようとしている可能性が高い。したがって、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
また、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点のうち、ユーザの現在位置との距離が所定距離以内の乗車地点に移動体が到着するまでの時間を示す時間情報をユーザが閲覧した場合に、ユーザが移動体に乗車する意図があると判定する。
乗車地点に移動体が到着するまでの時間を示す時間情報を閲覧するユーザは、移動体に乗車しようとしている可能性が高い。したがって、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
また、乗車意図判定部438は、所定の条件情報を満たす場合として、移動体に乗車するための乗車地点に向かってユーザが移動を開始した場合に、ユーザが移動体に乗車する意図があると判定する。
移動体に乗車するための乗車地点に向かって移動を開始したユーザは、移動体に乗車しようとしている可能性が高い。したがって、第4の実施形態にかかる情報処理装置400は、乗車意図があるか否かを高精度に判定することができる。
(その他)
〔1.移動体について〕
上記各実施形態では、移動体の一例としてオンデマンドバスを上げて説明した、しかし、移動体の形態は、オンデマンドバスに限定されない。例えば、移動体は、乗り合いタクシーであってもよい。また、移動体は、運転手が存在する有人の自動車であってもよいし、運転手が存在しない自動運転車であってもよい。
〔2.ハードウェア構成〕
また、上述してきた各実施形態にかかる情報処理装置100、200および300は、例えば図17に示すような構成のコンピュータ1000によって実現される。以下、情報処理装置100を例に挙げて説明する。図17は、情報処理装置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が第1の実施形態にかかる情報処理装置100として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部130の機能を実現する。また、HDD1400には、記憶部120内のデータが格納される。コンピュータ1000のCPU1100は、これらのプログラムを、記録媒体1800から読み取って実行するが、他の例として、他の装置から、通信網50を介してこれらのプログラムを取得してもよい。
また、例えば、コンピュータ1000が第2の実施形態にかかる情報処理装置200として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部230の機能を実現する。
〔3.その他〕
上記各実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上述してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
以上、本願の実施形態をいくつかの図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。