JP2024006455A - 情報処理装置および情報処理システム - Google Patents

Abstract

【課題】オンデマンドバスの利用者の利便性を高める。【解決手段】オンデマンド運行されるバスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記一人以上の第一の利用者に関連付いた一つ以上の利用者装置に送信する。【選択図】図１

Description

本開示は、オンデマンドバスに関する。

利用者からのリクエストに応じて運行されるオンデマンドバスが知られている。オンデマンドバスは、決められた場所に停留所を持っておらず、リクエストに基づいて、任意の地点において利用者を乗降させることができる。
これに関し、例えば、特許文献１には、事前に定められたエリアの中から、利用者に最も近い地点に乗降地点を設定するシステムが開示されている。

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

本開示は、オンデマンドバスの利用者の利便性を高めることを目的とする。

本開示の実施形態の一態様は、オンデマンド運行されるバスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記一人以上の第一の利用者に関連付いた一つ以上の利用者装置に送信することを実行する制御部を有する、情報処理装置である。

本開示の実施形態の一態様は、オンデマンド運行されるバスに乗車する利用者に関連付いた情報処理装置であって、前記バスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記バスの運行を管理するサーバ装置から受信することを実行する制御部を有する、情報処理装置である。

本開示の実施形態の一態様は、オンデマンド運行されるバスの運行を管理するサーバ装置と、前記バスに乗車する利用者に関連付いた利用者装置と、を含む情報処理システムであって、前記利用者装置は、前記バスへの乗車リクエストを前記サーバ装置に送信し、前記サーバ装置は、前記乗車リクエストに基づいて、第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を生成し、前記利用者情報を、前記一人以上の第一の利用者に関連付いた前記利用者装置に送信する、情報処理システムである。

また、他の態様として、上記の装置が実行する方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本開示によれば、オンデマンドバスの利用者の利便性を高めることができる。

第一の実施形態に係る交通システムの概要図。 利用者装置１００の構成要素を示した図。 利用者装置１００から送信される乗車リクエストの一例。 サーバ装置２００の構成要素を示した図。 利用者データ２０２Ｂの一例。 運行データ２０２Ｃの一例。 サーバ装置２００によって生成される乗車情報の一例。 利用者装置１００に提供される画面の一例。 車載装置３００の構成要素を示した図。 車両データの一例。 乗車予約を行う処理のシーケンス図。 到着済フラグを設定する処理のシーケンス図。 乗車情報を利用者装置に提供する処理のシーケンス図。 利用者装置１００に提供される画面の一例。 第二の実施形態に係る交通システムの概要図。 第二の実施形態で利用者装置１００に提供される画面の一例。 バス停の位置を変更する処理のシーケンス図。 車載装置３００が提供する画面の一例。

利用者からのリクエストに基づいて運行されるオンデマンドバスが知られている。斯様なシステムでは、決まった場所に停留所が設置されておらず、複数の利用者からのリクエストに基づいて、乗降地点が動的に設定されることがある。

しかし、バスを待つための設備が無い場所でバスを待つ場合、どのような属性を持つ人が集まってくるかが不明であり、利用者に不安感を与えてしまう場合がある。例えば、路上に集まっている人達が、バスの利用者であるのか、他の何らかの目的を持っているのかを判別することが難しい。
本開示に係る情報処理装置は、かかる問題を解決する。

本開示の第一の態様に係る情報処理装置は、オンデマンド運行されるバスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記一人以上の第一の利用者に関連付いた一つ以上の利用者装置に送信することを実行する制御部を有する。

第一の態様に係る情報処理装置は、典型的には、オンデマンドバスの運行を管理するサーバ装置である。
オンデマンドバスとは、利用者からのリクエストに応じて運行される乗合自動車である。本実施形態では、オンデマンドバスの乗降地点は、事前に定まっておらず、リクエストに応じて動的に設定される。
情報処理装置は、動的に設定された第一の地点からバスに乗車する予定である、一人以上の利用者（第一の利用者と称する）に関する情報である利用者情報を取得し、これを、第一の利用者に関連付いた一つ以上の利用者装置に送信する。
これにより、第一の地点からバスに乗車する複数の利用者は、自分の他にどのような人達が同じバスに乗車するかといった情報を得ることができる。
なお、以降の説明において、オンデマンドバスの乗降地点を「バス停」と称する。本実施形態では、バス停は仮想的に設置されるものであり、その位置はシステムによって動的に決定される。

利用者情報は、第一の利用者のそれぞれの性別や年代に関する情報を少なくとも含んでもよい。また、利用者情報は、第一の利用者のそれぞれが、第一の地点に到着済みである
か否かを表す情報を少なくとも含んでもよい。
これにより、例えば、どのような属性の人達が乗車予約をしており、そのうちの何人が既にバス停に到着しているかを利用者に通知することができる。
このため、制御部は、利用者装置から位置情報を取得し、管理してもよい。

なお、「一人以上の第一の利用者に関する情報である利用者情報」とは、対象の地点からバスに乗車する利用者（第一の利用者）全員分の情報であってもよいし、その中の一部の利用者の情報のみを含んだものであってもよい。

また、制御部は、利用者装置から送信された変更リクエストに基づいて、バスの乗降地点を変更してもよい。例えば、乗降地点として（安全面等の理由で）ふさわしくない地点にバス停が設定されてしまうといったケースが生じうる。
斯様な場合、利用者からの申告に基づいて、乗降地点を、第一の地点から第二の地点に変更してもよい。第二の地点は、例えば、第一の地点から所定の範囲にある地点とすることができる。また、第二の地点は、所定の施設（例えば、店舗等）の近傍に設定されてもよい。これにより、人が多い場所の近くにバス停を再設定させることが可能になる。

乗降地点の再設定を行った場合、その旨を利用者装置、および、バスに搭載された端末に通知してもよい。これにより、利用者とバスの双方において、乗降地点が再設定されたことを共有することができる。

本開示の第二の態様に係る情報処理装置は、オンデマンド運行されるバスに乗車する利用者に関連付いた情報処理装置であって、前記バスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記バスの運行を管理するサーバ装置から受信することを実行する制御部を有する。

第二の態様に係る情報処理装置は、第一の態様に係る情報処理装置（サーバ装置）と通信可能な利用者装置である。

以下、本開示の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは開示の技術的範囲をそれらのみに限定する趣旨のものではない。

（第一の実施形態）
第一の実施形態に係る交通システムの概要について、図１を参照しながら説明する。本実施形態に係る交通システムは、車載装置３００が搭載された車両１０と、利用者装置１００と、サーバ装置２００とを含んで構成される。システムに含まれる車両１０（車載装置３００）は複数であってもよい。

車両１０は、車載装置３００を搭載したオンデマンドバスである。オンデマンドバスは、利用者からの乗車リクエストに応じて運行される乗合自動車である。車両１０は、乗務員が運転する車両であってもよいし、自律走行車両であってもよい。車載装置３００は、サーバ装置２００と無線通信可能に構成される。
以下、車両１０のことをオンデマンドバス、または、単にバスと称する。

オンデマンドバスへの乗車を希望する利用者は、利用者装置１００を介して、乗車リクエストをサーバ装置２００に送信する。乗車リクエストは、例えば、乗車希望地点、乗車希望時刻、降車希望地点などを含む。

これらの情報は、例えば、利用者装置１００にインストールされた、交通システムを利用するためのアプリケーションソフトウェアによって生成および送信されることができる。ただし、これらの情報は、必ずしも携帯端末を利用して生成されなくてもよい。例えば、ネットワークに接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、またはウェアラブルコンピュータ等）やパーソナルコンピュータを利用して生成されてもよい。

サーバ装置２００は、利用者装置１００から送信された乗車リクエストに基づいて、バスの運行計画を生成する。運行計画は、例えば、オンデマンドバスの運行経路、利用者を乗降させる地点、および、その時刻などを含む。

利用者を乗降させる地点は、サーバ装置２００が決定することができる。例えば、サーバ装置２００は、利用者が乗降を希望する地点と、バスが走行可能な道路に基づいて、当該利用者を乗降させる地点を決定する。また、複数の利用者が、互いに近隣にある複数の地点から乗車を希望し、同一方面への移動を希望している場合、サーバ装置２００は、当該複数の利用者をグループ化し、当該複数の利用者を単一の地点から乗車させてもよい。
サーバ装置２００は、利用者が乗降する地点を巡回する経路（およびそのスケジュール）を生成し、前述した運行計画を生成して、対象の車両（車載装置３００）に送信する。

車載装置３００は、サーバ装置２００から運行計画を受信する。バスが有人車両である場合、当該運行計画が乗務員に提供される。バスが無人車両である場合、当該運行計画は、バスに搭載された、自律走行を制御する装置に送信される。

本実施形態に係る交通システムにおいては、複数の利用者装置１００、サーバ装置２００、および、車載装置３００が、ネットワークによって相互に接続される。ネットワークには、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークは、携帯電話等の電話通信網、Ｗｉ－Ｆｉ（登録商標）等の無線通信網を含んでもよい。

システムを構成する各要素について説明する。
図２は、利用者装置１００のシステム構成を示した図である。
利用者装置１００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、またはウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。利用者装置１００は、制御部１０１、記憶部１０２、通信部１０３、入出力部１０４、および位置情報取得部１０５を含んで構成される。

制御部１０１は、利用者装置１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができ
る。
制御部１０１は、リクエスト部１０１１と、案内部１０１２の二種類の機能モジュールを有して構成される。各機能モジュールは、後述する記憶部１０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

リクエスト部１０１１は、装置の利用者から、オンデマンドバスの乗車予約を行うために必要な情報を取得し、乗車リクエストをサーバ装置２００に送信する。具体的には、後述する入出力部１０４を介して、利用者の識別子、乗車希望地点、乗車希望時刻、降車希望地点などを取得する。取得された情報は、乗車リクエストとしてサーバ装置２００へ送信される。図３は、リクエスト部１０１１によって生成された乗車リクエストの一例である。また、リクエスト部１０１１は、サーバ装置２００と対話することで、乗車予約を確
定させる処理を行う。

案内部１０１２は、乗車予約が確定した後で、サーバ装置２００から、乗車に関する情報（以下、乗車情報）を取得し、利用者に提供する。乗車情報とは、サーバ装置２００が決定した乗車地点や、バスの到着時刻等を利用者に案内するための情報である。さらに、乗車情報には、同一のバス停から同じバスに乗車する複数の利用者に関する情報が含まれる。これについては後述する。

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やハード
ディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリ、あるいは、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）のようなディスク記録媒体である。

通信部１０３は、利用者装置１００をネットワークに接続するための無線通信インタフェースである。通信部１０３は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ等の移動体通信サービスを介して、ネットワークへのアクセスを提供する。
入出力部１０４は、装置の利用者が行った入力操作を受け付け、情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

次に、サーバ装置２００の構成について説明する。
サーバ装置２００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。なお、サーバ装置２０は、単一のコンピュータで構成されてもよいし、互いに連携する複数台のコンピュータによって構成されてもよい。

図４は、サーバ装置２００のシステム構成を示した図である。サーバ装置２００は、制御部２０１、記憶部２０２、および通信部２０３を含んで構成される。

制御部２０１は、サーバ装置２００が行う制御を司る演算装置である。制御部２０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部２０１は、リクエスト取得部２０１１、運行管理部２０１２、および、情報提供部２０１３の三種類の機能モジュールを有して構成される。各機能モジュールは、補助記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

リクエスト取得部２０１１は、利用者装置１００から送信された乗車リクエストを取得し、リクエストデータ２０２Ａとして、記憶部２０２に一時的に記憶させる。取得および記憶された乗車リクエストは、運行管理部２０１２によって利用される。
運行管理部２０１２は、複数の利用者装置１００から収集した複数の乗車リクエストに基づいて、バスの運行計画を生成する。運行計画は、バスの運行経路、運行スケジュール、乗車させる利用者についての情報などを含む。バスの運行経路および運行スケジュールは、複数の乗車リクエストに含まれる利用者の希望に基づいて生成される。

情報提供部２０１３は、バスに乗車予定である利用者に対して、乗車に関する情報（乗車情報）を提供する。具体的には、利用者装置１００からのリクエストに応じて、生成した運行計画に基づいて、乗車地点、到着時刻などを案内する情報を生成し、利用者装置１００に提供する。さらに、情報提供部２０１３は、同一のバス停から同じバスに乗車する複数の利用者（「同乗者」とも称する）に関する情報を生成し、利用者装置１００に提供する。

記憶部２０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部２０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部２０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。
記憶部２０２には、リクエストデータ２０２Ａ、利用者データ２０２Ｂ、および運行データ２０２Ｃが記憶される。

リクエストデータ２０２Ａは、図３に例示したような、複数の利用者装置１００から受信した乗車リクエストの集合である。
利用者データ２０２Ｂは、システムに登録している複数の利用者に関するデータである。図５は、利用者データ２０２Ｂの一例である。図示したように、利用者データ２０２Ｂには、利用者の識別子（利用者ＩＤ）、個人情報、決済に関する情報などが含まれる。なお、個人情報とは、性別、年齢（年代）など、同乗者に公開を許可した情報である。

運行データ２０２Ｃは、複数の乗車リクエストに基づいて運行管理部２０１２が生成した、バスの運行計画の集合である。
図６は、運行データ２０２Ｃの一例である。図示したように、運行データ２０２Ｃには、運行を一意に識別する識別子（運行ＩＤ）、車両の識別子（車両ＩＤ）、バスが経由する地点、その通過時刻、乗車する利用者に関する情報（利用者情報）などが含まれる。利用者情報には、利用者の識別子、乗車予約の識別子、乗車地点、降車地点などが含まれる。到着済フラグについては後述する。

通信部２０３は、サーバ装置２００をネットワークに接続するための通信インタフェースである。通信部２０３は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。

ここで、情報提供部２０１３が提供する機能について、より詳しく説明する。
サーバ装置２００は、利用者装置１００から要求があった場合に、乗車情報を生成し、利用者装置１００に送信する。
図７は、情報提供部２０１３が利用者装置１００に提供する乗車情報の一例である。本例では、乗車情報には、乗車地点、乗車時刻、降車地点が含まれている。さらに、乗車情報には、同一のバス停から同じバスに乗車する利用者に関する情報（同乗者情報）が含まれる。同乗者情報には、同一のバス停から同じバスに乗車する利用者（同乗者）の人数、年齢、性別などが含まれる。同乗者情報には、同乗者のステータス情報（例えば、当該同乗者が目的のバス停に到着しているか否かを示す情報）が含まれていてもよい。
なお、同乗者情報は、同一のバス停から同じバスに乗車する利用者全員分の情報であってもよいし、その中の一部の利用者の情報のみを含んだもの（例えば、乗車情報を要求した利用者の情報を除いたもの）であってもよい。
乗車情報は、運行データ２０２Ｃ、および、利用者データ２０２Ｂを検索して得られた情報に基づいて生成することができる。
図８は、図７に例示した乗車情報に基づいて利用者装置１００が生成した画面の一例である。斯様な情報を利用者に提供することにより、バスを待つ利用者に対して安心感を与えることができる。

次に、車載装置３００の構成について説明する。
車載装置３００は、オンデマンドバスに搭載されたコンピュータである。車載装置３００は、サーバ装置２００と通信することで、運行に関する情報のやり取りを行う。
車載装置３００は、バスの乗員または乗客に情報を提供する装置を兼ねていてもよい。例えば、車載装置３００は、乗客に対して案内を行う機器（以下、運行関連機器）であってもよい。運行関連機器として、例えば、バスが有する行先表示機や放送装置を制御する機器が挙げられる。
また、車載装置３００は、車両プラットフォームが有する電子制御ユニット（ＥＣＵ）であってもよい。また、車載装置３００は、通信機能を有するデータコミュニケーションモジュール（ＤＣＭ）であってもよい。
車載装置３００は、外部ネットワークと無線通信を行う機能を有する。車載装置３００は、外部ネットワークと通信することで、交通情報や道路地図データなどをダウンロードする機能を有していてもよい。

車載装置３００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

図９は、バス（車両１０）に搭載される、車載装置３００の構成要素を詳細に示した図である。
車載装置３００は、制御部３０１、記憶部３０２、通信部３０３、および、入出力部３０４を有して構成される。

制御部３０１は、所定のプログラムを実行することで、車載装置３００の各種機能を実現する演算ユニットである。制御部３０１は、例えば、ＣＰＵ等によって実現されてもよい。制御部３０１は、記憶されたプログラムをＣＰＵによって実行することでその機能を実現してもよい。

制御部３０１は、所定のタイミングで、バスの運行および自車両に関するデータ（以下、車両データ）を取得ないし生成し、サーバ装置２００に送信する。
車両データは、例えば、経路情報（予定された運行経路）、位置情報（現在の走行位置）、車両情報などを含む。

図１０は車両データの一例である。車両データには、車両ＩＤ、日時情報、経路情報、位置情報、および、車両情報の各フィールドが含まれる。車両ＩＤフィールドには、車両を一意に識別する識別子が格納される。日時情報フィールドには、車両データが生成された日時が格納される。
経路情報フィールドには、バスの運行経路に関する情報が格納される。
位置情報フィールドには、バスが現在走行中である区間が格納される。位置情報は、例えば、緯度および経度によって表されてもよいし、バス停の識別子によって表されてもよい。位置情報は、例えば、「バス停Ｘ１からＸ２の間を走行中」といった情報であってもよい。
位置情報は、例えば、バス（車両１０）が有するＧＰＳモジュールを介して取得してもよいし、前述した運行関連機器から取得してもよい。例えば、運行関連機器から取得したデータに基づいて、走行中である区間を判定してもよい。
車両情報フィールドには、オンデマンドバスの車両に関する情報が格納される。車両に関する情報は、例えば、バスのタイプ（ノンステップバス等）や、バスが有する設備（車椅子用スペース、車椅子用スロープ等）に関する情報であってもよい。

記憶部３０２は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部３０２には、制御部３０１にて実行される各種プログラム、当該プログラムが利用するデータ等が記憶される。

通信部３０３は、無線通信を行うためのアンテナと通信モジュールを含む。アンテナは、無線信号の入出力を行うアンテナ素子である。本実施形態では、アンテナは、移動体通信（例えば、３Ｇ、ＬＴＥ、５Ｇ等の移動体通信）に適合したものである。なお、アンテナは、複数の物理的なアンテナを含んで構成されてもよい。例えば、マイクロ波やミリ波などの高周波帯の電波を利用した移動体通信を行う場合、通信の安定化を図るため、複数のアンテナを分散して配置してもよい。通信モジュールは、移動体通信を行うためのモジュールである。

入出力部３０４は、入力された操作を受け付け、情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

なお、図２、図４、および図９に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

次に、各装置が実行する処理について説明する。
図１１は、利用者装置１００とサーバ装置２００がインタラクションを行い、乗車予約を受け付ける処理のシーケンス図である。図示した処理は、利用者の操作に基づいて開始される。

まず、ステップＳ１１で、利用者装置１００（リクエスト部１０１１）が、乗車リクエストを生成する。本ステップでは、所定のインタフェースを介して、乗車希望地点、降車希望地点、乗車希望時刻などを利用者に入力させる。リクエスト部１０１１は、生成した乗車リクエストをサーバ装置２００（リクエスト取得部２０１１）に送信する。

サーバ装置２００によって取得された乗車リクエストは、サーバ装置２００において、所定のトリガが発生するまで蓄積される。トリガは、周期的（例えば、１０分おき等）に発生させてもよいし、定められた時刻に発生させてもよい。
所定のトリガが発生すると、ステップＳ１２の処理が開始される。

ステップＳ１２では、運行管理部２０１２が、所定のルールに従い、複数の乗車リクエストに基づいて、利用者が乗降する地点と、その時刻を決定し、これらを含んだ運行計画
を生成する。運行計画が生成されると、運行管理部２０１２は、乗車情報を生成して利用者装置１００に送信し、リクエスト部１０１１がこれを出力する（ステップＳ１３）。乗車情報は、乗車に関する案内を行うための情報であって、図７を参照して説明したように、乗車地点、乗車時刻、降車地点、および、同乗者に関する情報を含む。これにより利用者は、乗車予約が成立したことを確認することができる。

図１２は、利用者装置１００が、サーバ装置２００に位置情報を送信する処理のシーケンス図である。
本実施形態では、バスが到着するまで所定の時間（例えば、３０分）を下回ると、利用者装置１００が、サーバ装置２００に対して位置情報の送信を周期的に開始する。また、サーバ装置２００は、複数の利用者装置１００から位置情報を収集し、対応する利用者が目的のバス停に到着済みであるか否かを判定する。

ステップＳ２１では、案内部１０１２が、乗車までの時間が所定値を下回っているか否かを判定する。乗車までの時間が所定値（例えば、３０分）を下回っている場合、処理はステップＳ２２へ遷移し、案内部１０１２が、位置情報取得部１０５を介して、装置の位置情報を取得する。取得された位置情報はサーバ装置２００へ送信される。

ステップＳ２３では、サーバ装置２００（情報提供部２０１３）が、取得した位置情報に基づいて、該当する利用者がバス停に到着済みであるか否かを判定する。図６の符号６０１で示したように、運行データ２０２Ｃは、各利用者について、バス停に到着済みであるか否かを示すフラグ（到着済フラグ）を持っている。情報提供部２０１３は、判定の結果を、当該到着済フラグに反映させる。
サーバ装置２００は、到着済フラグを参照することで、任意の利用者に対して、「同じバスに乗車する他の利用者がバス停に到着しているか」を案内することが可能になる。

乗車予約が成立した後、利用者装置１００は、任意のタイミングで乗車情報を確認することができる。図１３は、利用者装置１００からの求めに応じて、サーバ装置２００が乗車情報を提供する処理のシーケンス図である。
ステップＳ３１では、案内部１０１２が、乗車情報の送信をサーバ装置２００に要求する。本ステップでは、乗車予約の識別子（予約ＩＤ）が、利用者装置１００からサーバ装置２００に送信され、サーバ装置２００（情報提供部２０１３）が、これに基づいて乗車予約を特定し、乗車情報を生成する。

サーバ装置２００は、ステップＳ３２で、対象の利用者が乗車する予定のバスの運行に関する情報（例えば、乗車地点、乗車時刻など）を取得する。当該情報は、予約ＩＤをキーとして運行データ２０２Ｃを検索することで抽出することができる。
また、ステップＳ３３で、同乗者に関する情報を取得する。ある利用者と同時にバスに乗車する利用者（同乗者）に関する情報は、運行データ２０２Ｃおよび利用者データ２０２Ｂを検索することで抽出することができる。ここでは、同乗者の人数、性別、年代に関する情報が抽出される。

ステップＳ３４では、同乗者について到着済フラグが設定されているか否かを判定する。同乗者について到着済フラグが設定されていない場合、処理はステップＳ３５へ遷移し、同乗者の到着状況を含まない乗車情報を生成する。同乗者について到着済フラグが設定されている場合、処理はステップＳ３６へ遷移し、同乗者の到着状況を含んだ乗車情報を生成する。
生成された乗車情報は利用者装置１００に送信され、ステップＳ３７において出力される。図８は、同乗者の到着状況を含まない乗車情報に基づいて生成された画面の例であり、図１４は、同乗者の到着状況を含んだ乗車情報に基づいて生成された画面の例である。
これにより、予約を行った利用者は、自分と同時にどのような人達がバスに乗車するかを認識できるようになる。また、図１４に例示したように、自分と同時にバスに乗車する人達が、既にバス停に到着しているか否かを認識できるようになる。

以上説明したように、第一の実施形態に係る交通システムでは、動的に設定されるバス停からバスに乗車する利用者に関する情報をサーバ装置２００が管理し、利用者装置１００からの求めに応じて、これを利用者に提供する。かかる構成によると、バスに乗車する利用者は、どのような属性を持つ人達が自分と一緒にバスに乗車するか、および、同乗者が既にバス停に到着しているか否かを認識できるようになる。また、バス停の付近にいる人達が、バスの利用者であるか否かを認識できるようになり、路上で待機する際の不安を軽減することができる。

（第二の実施形態）
第一の実施形態では、利用者がバスに乗降する地点をサーバ装置２００が決定した。しかし、国や地域によっては、セキュリティ等の面から、指定された地点でバスを待ち続けることが適当ではないケースがありうる。
第二の実施形態は、かかるケースを想定し、利用者からのリクエストに基づいて、バスに乗降する地点を事後的に変更可能な実施形態である。

図１５は、第二の実施形態にかかる交通システムの概要を説明する図である。
第二の実施形態では、予約を確定させた後で、利用者装置１００が、バス停の位置を変更するリクエスト（変更リクエスト）をサーバ装置２００に送信することができる。サーバ装置２００は、変更リクエストを受信すると、所定の手順に従ってバス停の位置を変更し、変更後のバス停の位置を、利用者装置１００と車載装置３００の双方に送信する。

第二の実施形態では、案内部１０１２が、変更リクエストを送信するためのユーザインタフェースを出力可能に構成される。図１６は、案内部１０１２によって出力される画面の一例である。当該画面は、例えば、バスの到着時刻まで所定の時間を下回った場合に表示可能になる。

図１７は、バス停の位置を変更する処理のフローチャートである。図示した処理は、利用者が、バス停の位置変更をリクエストするボタン１６０１を押下した場合に開始される。
利用者が、バス停の位置変更をリクエストするボタンを押下すると（ステップＳ４１）、当該リクエストがサーバ装置２００に送信され、運行管理部２０１２が、バス停の位置を変更する処理を実行する（ステップＳ４２）。

バス停の位置変更は、以下の手順によって行われる。
（１）変更前の位置を中心とする所定の範囲を特定する
所定の範囲は、例えば、徒歩による移動が可能な範囲とすることができる。
（２）所定の範囲内にある施設を選択する
例えば、人が集まる施設など、路上に比べて安全性の高い施設を抽出する。複数の施設が抽出された場合、人の多さや規模に基づいて、その中の一つを選択してもよい。
（３）選択された施設の近傍に変更後のバス停を設定する
抽出した施設の近傍（例えば、正面入口から３０ｍ以内）に、変更後のバス停を設定する。

バス停の位置が変更された場合、その旨を通知するデータが、サーバ装置２００から利用者装置１００に送信される（ステップＳ４３Ａ）。また、同様のデータが、サーバ装置２００から車載装置３００に送信される（ステップＳ４３Ｂ）。
なお、本実施形態では、変更後のバス停の位置をサーバ装置２００が自動的に選択する例を挙げたが、候補が複数ある場合、それらの位置を利用者装置１００に送信し、利用者に選択させるようにしてもよい。

車載装置３００が有する制御部３０１は、サーバ装置２００から送信された通知を受信し、「変更後のバス停の位置」を、入出力部３０４を介してバスの乗務員に報知する。報知は、視覚的に行ってもよいし、音声等によって行ってもよい。入出力部３０４は、情報の出力を行うユニットであり、例えば、表示装置や音声出力装置などを含む。運行関連機器がバスに搭載されている場合、入出力部３０４は、当該機器と連携し、画像や音声等の出力を行ってもよい。

図１８は、運行関連機器によって出力される画面の一例である。運行関連機器は、例えば、運転席の近傍に設置されたモニタ装置を含んで構成される。当該モニタ装置には、通常、運行に関する情報（現在時刻、経由するバス停、到着予定時刻など）が出力される。
本例では、対象の乗客が乗車予定であるバス停（Ｘ３）に対応する領域に、バス停の位置が変更された旨の表示が出力される。制御部３０１は、変更後のバス停の位置を示す詳細な地図を出力してもよい。これにより、バスの乗務員は、バスを停車させるべき地点を認識することができる。

なお、本実施形態では、利用者の要求によってバス停の位置を変更する例を挙げたが、サーバ装置２００が、バス停の位置変更を自発的に提案してもよい。例えば、「同乗者がいない場合」、「人通りが少ない地点が乗車地点である場合」、「乗車時刻が夜間である場合」といった所定の条件を満たしている場合、乗車予約を行う際に、サーバ装置２００が、バス停の位置変更を提案してもよい。
また、所定の条件を満たしていない場合であっても、周辺に防犯性の高い施設等が存在する場合、当該施設の近傍にバス停を設定する旨の提案を行ってもよい。

また、同一のバス停から乗車する他の同乗者がいる場合、当該同乗者が所持する利用者装置とインタラクションを行った結果に基づいて、バス停の位置変更を行うか否かを決定してもよい。また、バス停の位置変更は、同一のバス停から乗車する他の同乗者がいない場合に限って行えるようにしてもよい。

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、同乗者に関する情報として性別や年代を例示したが、外見から認識可能な情報であれば、これ以外の情報を利用してもよい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコ
ンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１０・・・車両
１００・・利用者装置
２００・・・サーバ装置
３００・・・車載装置
１０１，２０１，３０１・・・制御部
１０２，２０２，３０２・・・記憶部
１０３，２０３，３０３・・・通信部
１０４，３０４・・・入出力部
１０５・・・位置情報取得部

Claims (20)

1. オンデマンド運行されるバスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記一人以上の第一の利用者に関連付いた一つ以上の利用者装置に送信すること
   を実行する制御部を有する、情報処理装置。
2. 前記利用者情報は、前記一人以上の第一の利用者のそれぞれの性別に関する情報を少なくとも含む、
   請求項１に記載の情報処理装置。
3. 前記利用者情報は、前記一人以上の第一の利用者のそれぞれが前記第一の地点に到着済みであるか否かを表す情報を少なくとも含む、
   請求項１に記載の情報処理装置。
4. 前記制御部は、前記一つ以上の利用者装置から位置情報を取得し、前記位置情報に基づいて、前記一人以上の第一の利用者のそれぞれが前記第一の地点に到着済みであるかを判定する、
   請求項３に記載の情報処理装置。
5. 前記制御部は、前記利用者装置から送信された変更リクエストに基づいて、前記バスの乗降地点を、前記第一の地点から、前記第一の地点から所定の範囲内にある第二の地点に変更する、
   請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記制御部は、前記第二の地点に関する情報を、前記利用者装置に送信する、
   請求項５に記載の情報処理装置。
7. 前記制御部は、前記第二の地点に関する情報を、前記利用者装置および前記バスに関連付いた移動端末に送信する、
   請求項５に記載の情報処理装置。
8. 前記制御部は、前記第二の地点を、所定の施設の近傍に設定する、
   請求項５に記載の情報処理装置。
9. 前記制御部は、前記第一の地点の近傍に所定の施設がある場合に、前記第二の地点を、前記所定の施設の近傍に設定することを提案する、
   請求項５に記載の情報処理装置。
10. オンデマンド運行されるバスに乗車する利用者に関連付いた情報処理装置であって、
    前記バスの乗降地点として設定された第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を、前記バスの運行を管理するサーバ装置から受信すること
    を実行する制御部を有する、情報処理装置。
11. 前記制御部は、前記利用者の属性情報を含む乗車リクエストを前記サーバ装置に送信し、前記乗車リクエストに基づいて設定された前記第一の地点に関する情報と、前記利用者情報と、を前記サーバ装置から取得する、
    請求項１０に記載の情報処理装置。
12. 前記属性情報は、性別に関する情報を少なくとも含み、
    前記利用者情報は、前記一人以上の第一の利用者のそれぞれの性別に関する情報を含む、
    請求項１１に記載の情報処理装置。
13. 前記制御部は、前記サーバ装置に位置情報を送信し、
    前記サーバ装置から、前記一人以上の第一の利用者のそれぞれが前記第一の地点に到着済みであるか否かを表す情報を少なくとも含む前記利用者情報を受信する、
    請求項１０に記載の情報処理装置。
14. 前記一人以上の第一の利用者のそれぞれが前記第一の地点に到着済みであるかは、複数の前記位置情報に基づいて、前記サーバ装置によって判定されたものである、
    請求項１３に記載の情報処理装置。
15. 前記制御部は、前記利用者からの要求に基づいて、前記バスの乗降地点を、前記第一の地点から、前記第一の地点から所定の範囲内にある第二の地点に変更する変更リクエストを前記サーバ装置に送信する、
    請求項１０から１４のいずれか１項に記載の情報処理装置。
16. 前記制御部は、前記サーバ装置によって決定された前記第二の地点に関する情報を、前記サーバ装置から受信する、
    請求項１５に記載の情報処理装置。
17. オンデマンド運行されるバスの運行を管理するサーバ装置と、
    前記バスに乗車する利用者に関連付いた利用者装置と、
    を含む情報処理システムであって、
    前記利用者装置は、
    前記バスへの乗車リクエストを前記サーバ装置に送信し、
    前記サーバ装置は、
    前記乗車リクエストに基づいて、第一の地点から前記バスに乗車する予定である、一人以上の第一の利用者に関する情報である利用者情報を生成し、
    前記利用者情報を、前記一人以上の第一の利用者に関連付いた前記利用者装置に送信する、
    情報処理システム。
18. 前記乗車リクエストは、前記利用者の属性情報を含み、
    前記サーバ装置は、前記属性情報に基づいて前記利用者情報を生成する、
    請求項１７に記載の情報処理システム。
19. 前記利用者装置は、前記サーバ装置に位置情報をさらに送信し、
    前記サーバ装置は、一つ以上の前記利用者装置から受信した前記位置情報に基づいて、前記一人以上の第一の利用者のそれぞれが前記第一の地点に到着済みであるかを判定する、
    請求項１７に記載の情報処理システム。
20. 前記サーバ装置は、前記一人以上の第一の利用者のそれぞれが前記第一の地点に到着済みであるか否かを表す情報を少なくとも含む前記利用者情報を、前記一つ以上の前記利用者装置に送信する、
    請求項１９に記載の情報処理システム。

Images