JP7088100B2 - 情報処理装置、情報処理方法およびプログラム - Google Patents

Description

本発明は、情報処理装置、この情報処理装置が実行する情報処理方法、およびプログラムに関する。

従来、荷物を各家庭などに配達する宅配サービスが普及していて、様々なアイデアが更に提案されている（例えば特許文献１参照）。

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

ところで、荷物の配達や荷物の集荷を無人の車両で行うことが提案されている。しかし、例えば配達先での受取人への荷物の引き渡しは、車両に乗車した作業員によって行われる。このような作業員については、人件費節減の観点で改善が望まれる。そこで、本発明の目的は、集配サービスに関して、荷物の集配のための車両等の移動体と、そのサービスの利用者との間での集配作業を好適に可能にすることにある。

本発明の一側面は、制御部を備える情報処理装置によって例示される。本制御部は、荷物の集配のために運行する移動体へ乗車希望のユーザの端末に対して、集配先で前記移動体と集配サービスの利用者との間での前記荷物の集配作業を担当可能であるかの問い合わせを行うことと、前記端末から前記移動体への乗車時に前記集配作業を担当可能であるという回答を受け付けたとき、前記集配作業を担当可能な前記乗車希望のユーザを前記移動体に乗車させる指令を前記移動体に送信することとを実行する。本発明の他の側面は、上記情報処理装置等の少なくとも１つのコンピュータが実行する情報処理方法によっても例示される。さらにまた、本発明の他の側面は、上記情報処理装置等の少なくとも１つのコンピュータに実行させるためのプログラムによっても例示される。

本情報処理装置によれば、集配サービスに関して、荷物の集配のための車両等の移動体と、そのサービスの利用者との間での集配作業を好適に行うことが可能になる。

本発明の第１実施形態に係るシステムの運用例の概念図である。 図１のシステムにおける、その構成を概略的に示したブロック図であり、特に自律走行車両の構成を示した図である。 図１のシステムにおける、その構成を概略的に示したブロック図であり、特にサーバ装置の構成を示した図である。 図１のシステムにおける、その構成を概略的に示したブロック図であり、特にユーザ装置の構成を示した図である。 図１のシステムにおける、サーバ装置の処理のフローチャートである。 図１のシステムにおける、サーバ装置と、集配サービスの利用者の端末と、乗車希望の第三者の端末との間での処理例を説明するための図である。 図１のシステムにおける、自律走行車両の処理のフローチャートである。 本発明の第２実施形態に係るシステムにおける、その構成を概略的に示したブロック図であり、特にサーバ装置の構成を示した図である。 第２実施形態に係るシステムにおける、サーバ装置の処理のフローチャートである。 第２実施形態に係るシステムにおける、サーバ装置と、集配サービスの利用者の端末と、乗車希望の第三者の端末との間での処理例を説明するための図である。

以下、図面を参照して、本発明の実施形態に係る情報処理装置、その情報処理装置での情報処理方法、およびプログラムについて説明する。まず、第１実施形態について説明する。

図１に、本発明の第１実施形態に係る集配システムＳを概念的に示す。集配システムＳは、自律走行車両１００と、サーバ装置２００とを備える。自律走行車両１００は荷物の集配のために運行する移動体の一例である。サーバ装置２００は、情報処理装置であり、ネットワークＮ上のコンピュータである。サーバ装置２００は、ネットワークＮを介して、自律走行車両１００の各々と通信可能に構成されていて、自律走行車両１００の情報処理装置とネットワークＮを介して連携する。なお、図１では、複数の自律走行車両１００（１００Ａ、１００Ｂ、・・・）のうち自律走行車両１００Ａのみを例示するが、これは自律走行車両１００の数等を限定するものではなく、それは幾つであってもよい。

集配システムＳは、集荷及び配達の少なくともいずれかを可能にするシステムであり、それら集荷と配達との両方を行うシステムであってもよい。集配システムＳは、１つ又は複数のセンタＣを備えることができる。センタＣは、自律走行車両１００に積載する荷物が製造されたり集められたりする場所であり得、また、自律走行車両１００を介して荷物が集められる場所であり得る。センタＣは、ここでは、ピザなどの飲食物などの製造場所であるが、宅配サービスの中継基地でもある。

図１では、センタＣに、自律走行車両１００Ａが待機している状態を表す。自律走行車両１００は、それぞれ、荷物を集めたり配ったりするために、集配先に走行することができる。集配システムＳでは、まず荷物を集荷するとき、自律走行車両１００は集荷先に向かって走行し、そこからそれの最寄りのセンタＣに荷物を一旦集める。そして、同じ又は異なる自律走行車両１００は、そのセンタＣから配達先の最寄りの別のセンタＣにその荷物を運ぶ。更に、同じ又は異なる自律走行車両１００は、その別のセンタＣから配達先まで荷物を運ぶ。

ここでは、サーバ装置２００は、センタＣ外に設けられている。サーバ装置２００は、センタＣに設けられてもよい。サーバ装置２００は、他のサーバ装置等ともネットワークＮを介して通信可能である。サーバ装置２００は、自律走行車両１００の各々と通信可能に構成されていることに加えて、ネットワークＮを介して、ユーザ装置３００とも通信可能に構成されている。

ユーザ装置３００はネットワークＮを介してサーバ装置２００と通信可能に構成されている。図１では、複数のユーザ装置３００（３００Ａ、・・・）のうちのユーザ装置３００Ａ、３００Ｘ、３００Ｙのみを例示しているが、これはユーザ装置の数等を限定するものではなく、それは幾つであってもよい。

自律走行車両１００は、Electric Vehicle（ＥＶ）パレットとも呼ばれる。自律走行車両１００は、自動運転及び無人運転可能な移動体であり、様々な寸法のものが存在する。例えば、少量の荷物の積載とたった１人の乗車のみが可能な小型のものから、大型のもの
まで、様々なサイズの自律走行車両１００が利用可能である。特に、本実施形態では、自律走行車両１００は、貨客混載を可能にする車両であり、荷物の輸送のみならず、人間の輸送つまり乗車をも可能にする。

自律走行車両１００は、それ自体の制御のための制御機能及び通信機能を有している。自律走行車両１００は、ネットワークＮ上のサーバ装置と連携して、自律走行車両１００単独で実行可能な処理に加えて、ネットワーク上のサーバ装置によって付加される機能及びサービスをユーザに提供することができる。なお、自律走行車両１００は、必ずしも無人車両である必要はない。例えば、営業要員や接客要員、保安要員などが搭乗してもよい。また、自律走行車両１００は、必ずしも完全なる自律走行が可能な車両でなくてもよい。例えば、状況に応じて人が運転ないし運転の補助を行う車両であってもよい。

さらに、自律走行車両１００は、ユーザ装置３００（３００Ａ、・・・）ともネットワークＮを介して通信可能に構成されている。ユーザ装置３００は、ユーザからの入力及びそれに準じる操作を受け付け、サーバ装置２００に対してのみならず、ネットワークＮを介して自律走行車両１００とも通信することができる。なお、ユーザ装置３００は、自律走行車両１００との間で直接的に送受信してもよい。

サーバ装置２００は、自律走行車両１００に対して運行を指令する装置である。例えば、サーバ装置２００は、どういった荷物を集配先に届けたり、或いは、そこから集めたりするのか、また、それはいつなのか、つまり集配についての運行指令を、自律走行車両１００に送信する。

図１の集配システムＳにおける各構成要素について、以下、詳しく説明する。図２は、自律走行車両１００、サーバ装置２００、及び、ユーザ装置３００を含む集配システムＳの構成を概略的に示したブロック図であり、特に自律走行車両１００Ａの構成を示した図である。なお、図２では、自律走行車両１００の一例として自律走行車両１００Ａの構成を示す。他の自律走行車両１００Ｂ等は、自律走行車両１００Ａと同様の構成を備える。

図２の自律走行車両１００Ａは、情報処理装置１０２を備え、その機能を実質的に担う制御部１０４を有する。自律走行車両１００Ａは、サーバ装置２００から取得した運行指令に従って走行などをすることができる。具体的には、自律走行車両１００Ａは、ネットワークＮを介して取得した運行指令に基づいて、車両の周辺をセンシングしながら適切な方法で走行する。そして、この走行に際し、自律走行車両１００Ａは、運行指令に基づいて、荷物の集配と、各種ユーザの乗降に関する処理を実行する。

自律走行車両１００Ａは、さらに、センサ１０６、位置情報取得部１０８、駆動部１１０、通信部１１２、記憶部１１４を含んで構成される。自律走行車両１００Ａは、バッテリから供給される電力で動作する。

センサ１０６は、車両周辺のセンシングを行う手段であり、典型的にはステレオカメラ、レーザスキャナ、Light Detection and Ranging、Laser Imaging Detection and Ranging（ＬＩＤＡＲ）、レーダなどを含む。センサ１０６が取得した情報は、制御部１０４に送信される。センサ１０６は、自車両が自律走行を行うためのセンサを含む。センサ１０６は、自律走行車両１００Ａの車体に設けられたカメラを含んでもよい。例えば、センサ１０６は、Charged-Coupled Devices（ＣＣＤ）、Metal-Oxide-Semiconductor（ＭＯＳ）あるいはComplementary Metal-Oxide-Semiconductor（ＣＭＯＳ）等のイメージセンサを
用いた撮影装置を含むことができる。車体の複数の箇所に複数のカメラが設けられていてもよい。例えば、車体の前方、後方、左右側方にそれぞれカメラが設置されていてもよい。

位置情報取得部１０８は、車両の現在位置を取得する手段であり、典型的にはGlobal Positioning System（ＧＰＳ）受信器などを含む。位置情報取得部１０８が取得した情報
は、制御部１０４に送信される。衛星信号受信器としてのＧＰＳ受信器は、複数のＧＰＳ衛星からの信号を受信する。各ＧＰＳ衛星は、地球の周囲を周回する人工衛星である。衛星測位システムつまりNavigation Satellite System（ＮＳＳ）はＧＰＳに限られない。
種々の衛星測位システムからの信号に基づいて、位置情報が検出されてもよい。ＮＳＳは、全地球航法衛星システムに限定されず、準天頂衛星システム（Quasi-Zenith Satellite
System）を含み得、例えば、欧州の“ガリレオ”や、ＧＰＳと一体運用される日本国の
“みちびき”を含み得る。

制御部１０４は、センサ１０６、位置情報取得部１０８等から取得した情報に基づいて、自律走行車両１００Ａの制御を行うコンピュータである。制御部１０４は、サーバ装置２００からの運行指令を受けて、移動体である自律走行車両１００Ａの走行や、荷物の集配業務や、各種ユーザの乗降作業を制御する制御手段の一例である。

制御部１０４は、ＣＰＵと、主記憶部とを有し、プログラムにより情報処理を実行する。ＣＰＵはプロセッサともいう。制御部１０４の主記憶部は主記憶装置の一例である。制御部１０４におけるＣＰＵは、その主記憶部に実行可能に展開されたコンピュータプログラムを実行し、各種機能を提供する。制御部１０４における主記憶部は、ＣＰＵが実行するコンピュータプログラムやデータ等を記憶する。制御部１０４における主記憶部は、Dynamic Random Access Memory（ＤＲＡＭ）、Static Random Access Memory（ＳＲＡＭ）
、Read Only Memory（ＲＯＭ）等である。

制御部１０４は、記憶部１１４と接続されている。記憶部１１４は、所謂外部記憶部であり、制御部１０４の主記憶部を補助する記憶領域として使用され、制御部１０４のＣＰＵが実行するコンピュータプログラムやデータ等を記憶する。記憶部１１４は、ハードディスクドライブ、Solid State drive（ＳＳＤ）等である。

制御部１０４は、機能モジュールとして、情報取得部１０４１、計画生成部１０４２、環境検出部１０４３、タスク制御部１０４４を有している。各機能モジュールは、主記憶部や記憶部１１４に記憶されたプログラムを制御部１０４つまりそのうちのＣＰＵによって実行することで実現される。

情報取得部１０４１は、サーバ装置２００から運行指令の情報を取得する。運行指令は、集配情報と、それに関連付けられた乗車情報とを含む。集配情報は、集配に係る荷物及びその寸法、集配先、荷物の集配の予定時刻、集配ルート、及び／又はその集配ルートの通過予定時刻についての情報を含み得る。乗車情報は、ユーザの情報（例えばユーザＩＤ）、乗車場所及び／又は降車場所についての情報を含み得る。なお、情報取得部１０４１は、定期的に又は不定期に、自車両の情報を取得し、例えば積載する荷物の情報を取得し、記憶部１１４の自車両情報データベース１１４１に記憶させる。

計画生成部１０４２は、サーバ装置２００から取得した運行指令の情報に基づいて、自車両の運行計画を生成する。なお、計画生成部１０４２が生成した運行計画は、後述するタスク制御部１０４４へ送信される。本実施形態において、運行計画とは、自律走行車両１００Ａが走行するルートと、ルートの一部または全部において自律走行車両１００Ａが行うべき処理を規定したデータである。運行計画に含まれるデータの例として、例えば、以下のようなものが挙げられる。

（１）自車両が走行するルート又は経路を道路リンクの集合によって表したデータ
自車両が走行するルートは、例えば、記憶部１１４に記憶された地図データを参照し、運行指令に含まれる集配ルート情報をベースにしつつ、与えられた出発地と目的地に基づいて自動的に生成してもよい。また、ルートは、外部のサービスを利用して生成してもよい。

（２）ルート上の地点において自車両が行うべき処理を表したデータ
ルート上において自車両が行うべき処理には、例えば、「荷物の受け取り」、「荷物の受け渡し」、「ユーザの乗車」、「ユーザの降車」、「受領証や預り証を収受する」といったものがあるが、これらに限られない。

環境検出部１０４３は、センサ１０６が取得したデータに基づいて、車両周辺の環境を検出する。検出の対象は、例えば、車線の数や位置、自車両の周辺に存在する車両の数や位置、自車両の周辺に存在する障害物（例えば歩行者、自転車、構造物、建築物など）の数や位置、道路の構造、道路標識などであるが、これらに限られない。自律的な走行を行うために必要なものであれば、検出の対象はどのようなものであってもよい。また、環境検出部１０４３は、検出した物体をトラッキングしてもよい。例えば、１ステップ前に検出した物体の座標と、現在の物体の座標との差分から、当該物体の相対速度を求めてもよい。環境検出部１０４３が検出した、環境に関するデータ（以下、環境データ）は、後述するタスク制御部１０４４へ送信される。

タスク制御部１０４４は、計画生成部１０４２が生成した運行計画と、環境検出部１０４３が生成した環境データ、ならびに、位置情報取得部１０８が取得した自車両の位置情報に基づいて、移動体である自車両の運行つまり走行を制御する。例えば、所定のルートに沿って走行し、かつ、自車両を中心とする所定の安全領域内に障害物が進入しないように自車両を走行させる。車両を自律走行させる方法については、公知の方法を採用することができる。この自律走行車両１００Ａの走行の制御の実行は、上記集配情報及び乗車情報に基づいて行われる。また、タスク制御部１０４４は、計画生成部１０４２が生成した運行計画に基づいて、走行以外のタスクも実行する。タスクとしては、ユーザの乗降、受領証や預り証の発行等を例示できる。

駆動部１１０は、タスク制御部１０４４が生成した指令に基づいて、自律走行車両１００Ａを走行させる手段である。駆動部１１０は、例えば、車輪を駆動するためのモータやインバータ、ブレーキ、ステアリング機構、二次電池等を含んで構成される。

通信部１１２は、自律走行車両１００ＡをネットワークＮに接続するための通信手段を有する。本実施形態では、自律走行車両１００Ａは、ネットワークＮ経由で他の装置、例えばサーバ装置２００やユーザ装置３００と通信を行うことができる。なお、通信部１１２は、自車両である自律走行車両１００Ａが他の自律走行車両１００（１００Ｂ、・・・）と車々間通信を行うための通信手段をさらに有していてもよい。

次に、サーバ装置２００について説明する。サーバ装置２００は、ユーザ装置３００（３００Ａ、・・・）から荷物の集配要求を取得し、それに基づいて自律走行車両１００（１００Ａ、・・・）に対する運行指令を生成して送信する装置である。また、サーバ装置２００は、ユーザ装置３００から乗車要求を取得し、それに基づいて自律走行車両１００に対する運行指令を生成して送信する装置である。

サーバ装置２００は、情報処理装置であり、図３に示すように、通信部２０２、制御部２０４、記憶部２０６を有して構成される。通信部２０２は、通信部１１２と同様であり、サーバ装置２００をネットワークＮに接続するための通信機能を有する。そして、サーバ装置２００の通信部２０２は、ネットワークＮ経由で自律走行車両１００及びユーザ装
置３００と通信を行うための通信インタフェースである。制御部２０４は、制御部１０４と同様にＣＰＵと主記憶部とを有し、プログラムにより情報処理を実行する。もちろん、このＣＰＵもプロセッサであり、制御部２０４の主記憶部も主記憶装置の一例である。制御部２０４におけるＣＰＵは、その主記憶部に実行可能に展開されたコンピュータプログラムを実行し、各種機能を提供する。制御部２０４における主記憶部は、ＣＰＵが実行するコンピュータプログラムやデータ等を記憶する。制御部２０４における主記憶部は、ＤＲＡＭ、ＳＲＡＭ、ＲＯＭ等である。

制御部２０４は、記憶部２０６と接続されている。記憶部２０６は、外部記憶部であり、制御部２０４の主記憶部を補助する記憶領域として使用され、制御部２０４のＣＰＵが実行するコンピュータプログラムやデータ等を記憶する。記憶部２０６は、ハードディスクドライブ、ＳＳＤ等である。

制御部２０４は、サーバ装置２００の制御を司る手段である。制御部２０４は、図３に示すように、機能モジュールとして、情報取得部２０４１、車両管理部２０４２、集配管理部２０４３、乗車管理部２０４４、情報提供部２０４５を有している。また、集配管理部２０４３は、予定生成部１ａ、作業確認部１ｂ及び指令生成部１ｃを有している。更に、乗車管理部２０４４は、予定通知部２ａ、作業問合せ部２ｂ、乗車処理部２ｃ及び関連付け部２ｄを有している。これらの各機能モジュールは、主記憶部や記憶部２０６に記憶されたプログラムを制御部２０４のＣＰＵによって実行することで実現される。

情報取得部２０４１は、自律走行車両１００やユーザ装置３００から各種情報、例えば集配サービスの利用者のユーザ装置３００から集配要求を取得する。そして、取得した情報を、集配管理部２０４３、乗車管理部２０４４に送信する。また、情報取得部２０４１は、自律走行車両１００から位置情報や、自車両情報データベース１１４１の情報などを定期的に取得し、車両管理部２０４２に送信する。

車両管理部２０４２は、管理下にある複数の自律走行車両１００の情報を管理する。具体的には、所定の周期ごとに、複数の自律走行車両１００から、自律走行車両１００に関するデータ等の情報を情報取得部２０４１を介して受信し、記憶部２０６の車両情報データベース２０６１に記憶させる。自律走行車両１００に関する情報として、位置情報と車両情報を用いる。車両情報は、例えば、自律走行車両１００の識別子、用途・種別、待機地点（車庫や営業所）に関する情報、扉タイプ、車体サイズ、荷室サイズ、積載量、満充電時における走行可能距離、現時点における走行可能距離、現在のステータスなどである。ただし、車両情報はこれら以外であってもよい。なお、現在のステータスは、集配に係る荷物の積載状況、集配状況を示す情報を含み、例えば、積載している荷物の大きさや個数、荷物を集配先で降ろしたのか載せたのか、などの情報を含む。

集配管理部２０４３は、情報取得部２０４１が取得した情報に基づいて集配の予定を生成して前述の集配情報を含む運行指令を生成する。この予定の生成は、集配ルートやその通過予定時刻といった集配のスケジュールの情報（以下、スケジュール情報）の作成を含む。この集配ルートなどの生成のために、予定生成部１ａは記憶部２０６の地図情報データベース２０６２を参照する。さらに、その予定の生成は、荷物の集配に適した車両を決定することを含む。例えば、集配に係る荷物の大きさ、集配先の所在地、集配予定日時に基づいて、車両が決定されるとよい。この決定に際して、予定生成部１ａは、車両情報データベース２０６１を検索する。また、作業確認部１ｂは、集配サービスの利用者の端末であるユーザ装置３００に、集配先における自律走行車両と利用者との間での荷物の集配に関する作業（以下、集配作業）をその利用者以外の人が担当することを望むのか否かを確認するために、問い合わせる。そして、指令生成部１ｃは、予定生成部１ａが生成した上記スケジュール情報を含む集配情報と、乗車管理部２０４４の関連付け部２ｄがそれに
関連付けた後述の乗車希望者の情報を含む乗車情報とに基づいて、運行指令を生成する。

乗車管理部２０４４は、集配管理部２０４３の予定生成部１ａが生成したスケジュール情報の集配において、その集配に係る自律走行車両へ乗車希望のユーザを募り、その乗車希望のユーザに上記集配作業を担当可能にする。乗車管理部２０４４の予定通知部２ａは、集配に係る移動体としての自律走行車両へ乗車希望のユーザを募る。このため、予定通知部２ａは、集配管理部２０４３の予定生成部１ａが生成したスケジュール情報を所定のサイトに公開したり登録ユーザの端末であるユーザ装置３００に通知したりする。この公開及び通知は、いずれか一方のみであってもよく、両方であってもよい。登録ユーザのユーザ装置３００への送信のため、記憶部２０６のユーザ情報データベース２０６３が参照される。所定のサイトは、登録ユーザのみが閲覧可能であるとよいが、閲覧制限を設けないようにしてもよい。また、乗車管理部２０４４の作業問合せ部２ｂは、その自律走行車両へ乗車希望のユーザがいたときに、その乗車希望のユーザの端末に対して、集配先で自律走行車両と利用者との間での荷物の集配作業を担当可能であるかの問い合わせを行う。乗車処理部２ｃは、乗車希望のユーザの乗車を確定してよいか否かの判定、例えばそのユーザの乗車希望場所や降車希望場所は所定の条件を満たすのか否かの判定などを行い、乗車希望のユーザの乗車要求を処理して、受け付ける。そして、乗車処理部２ｃで乗車希望のユーザの乗車要求が受け付けされたとき、関連付け部２ｄは、この乗車要求の乗車情報を集配管理部２０４３の指令生成部１ｃに送り、集配情報に関連付ける。乗車情報は、乗車希望のユーザの乗車希望場所、降車希望場所を含む。乗車情報は、集配作業を担当可能であるのか否かの情報も含む。

情報提供部２０４５は、集配管理部２０４３の指令生成部１ｃが生成した運行指令の情報を、予定生成部１ａが決めた自律走行車両１００に提供する。この運行指令の情報は、前述の集配情報、前述の乗車情報を含む。

次に、ユーザ装置３００について説明する。ユーザ装置３００は、ユーザの端末であり、例えば、携帯端末、スマートフォン、パーソナルコンピュータ等である。一例としての図４のユーザ装置３００Ａは、通信部３０２と、制御部３０４と、記憶部３０６とを有する。ユーザ装置３００Ａの通信部３０２及び記憶部３０６は、サーバ装置２００の通信部２０２及び記憶部２０６のそれぞれと同様である。さらに、ユーザ装置３００Ａは、表示部３０８と、操作部３１０とを有する。表示部３０８は、例えば、液晶ディスプレイ、エレクトロルミネッセンスパネル等である。操作部３１０は、例えば、キーボード、ポインティングデバイス等であってもよい。より具体的には、本実施形態では、操作部３１０はタッチパネルを含み、実質的に表示部３０８と一体化されている。

制御部３０４は、サーバ装置２００の制御部２０４と同様に、ＣＰＵと主記憶部とを有する。制御部３０４のＣＰＵは、記憶部３０６に記憶されたアプリケーションプログラム（以下、アプリケーション）３０６１を実行する。アプリケーション３０６１は、ウェブブラウザあるいはサーバ装置２００から通知される情報にアクセスするためのアプリケーションプログラムである。アプリケーション３０６１は、ＧＵＩを有し、ユーザによる入力、例えば、アクセスを受け付け、ネットワークＮを介してサーバ装置２００に送信する。ユーザ装置３００を介して、集配サービスの利用者は、集配要求や乗車要求を入力し、サーバ装置２００に送ることができる。

なお、図２、図３及び図４では、自律走行車両１００とサーバ装置２００とユーザ装置３００が同一のネットワークＮで接続されている。ただし、この接続は複数のネットワークで実現されてもよい。例えば、自律走行車両１００とサーバ装置２００とを接続するネットワークと、サーバ装置２００とユーザ装置３００とを接続するネットワークとが異なるネットワークであってもよい。

上記構成を有する集配システムＳにおける処理について、図５から図７に基づいて説明する。まず、図５に基づいて、サーバ装置２００における処理について説明する。なお、以下では、ユーザＵが集配サービスの利用者であり、その端末装置がユーザ装置３００Ａであり、このユーザＵの荷物の集配のために用いられる自律走行車両１００は自律走行車両１００Ａである。また、以下では、ユーザＵが集配サービスを望むものは、例えば、ピザの配達である。ただし、集配サービスは、家庭、あるいは企業その他の組織への荷物の配達あるいは集荷等、他のサービスであってもよい。以下では、集配とは、集荷および配達のすくなくとも一方を含むものとする。

集配サービスの利用者であるユーザＵからの集配要求がユーザ装置３００Ａから送信されると、サーバ装置２００の制御部２０４における集配管理部２０４３の予定生成部１ａは、それを取得する（ステップＳ５０１で肯定判定）。ここの集配要求には、例えば集配に係る荷物の種類や大きさ、集配予定時刻が含まれている。例えば、集配要求は、ピザを１枚、今日の１８時３０分に届けて欲しいという内容の情報を含む。ここで、集配要求に、作業情報が含まれているか否かが判定される（ステップＳ５０３）。作業情報は、集配先での利用者であるユーザＵと自律走行車両との間の集配作業を誰かに担当してもらいたいと望むのか否かについての情報である。作業情報が集配要求に含まれていないとき（ステップＳ５０３で否定判定）、サーバ装置２００の制御部２０４における集配管理部２０４３の作業確認部１ｂは、ユーザＵのユーザ装置３００Ａに、その集配作業を望むのかの問い合わせを行う（ステップＳ５０５）。

サーバ装置２００の制御部２０４における集配管理部２０４３の予定生成部１ａは、集配要求を受け付けたので、そのスケジュール情報を生成する。このスケジュール情報は、所定のプログラムに従って生成され、集配ルート、その通過予定時刻、集配先での集配予定時刻、などを含む。そして、このとき、予定生成部１ａは、集配に係る移動体として自律走行車両１００Ａを決定する。予定生成部１ａが集配要求を受け付けると、乗車管理部２０４４の予定通知部２ａは、例えば集配予定時刻の所定時間前に、自律走行車両１００Ａへ乗車希望のユーザを募るため、集配のスケジュール情報を登録ユーザの端末に通知する（ステップＳ５０７）。図１の場合、ユーザＸのユーザ装置３００Ｘ及びユーザＹのユーザ装置３００Ｙにスケジュール情報が通知される。更に、予定通知部２ａは、自律走行車両１００Ａへ乗車希望のユーザを募るため、集配のスケジュール情報を所定のサイトに公開する（ステップＳ５０７）。ここでは。登録ユーザのみアクセス可能なサイトにそれは公開される。

その結果、あるユーザＸのユーザ装置３００Ｘから返信として乗車希望の要求を受け付けたとき（ステップＳ５０９で肯定判定）、乗車管理部２０４４の作業問合せ部２ｂは、ユーザＵから集配作業を望む回答があったか否かを判定する（ステップＳ５１１）。ユーザＵから集配作業の要望があったとき（ステップＳ５１１で肯定判定）、作業問合せ部２ｂは、ユーザＸの端末であるユーザ装置３００Ｘに、自律走行車両に乗車したとき、集配作業を担当可能であるのか否かを問い合わせる（ステップＳ５１３）。一方、ユーザＵのユーザ装置３００Ａから集配作業は不要との回答を受け付けたとき（ステップＳ５１１で否定判定）、集配作業を担当可能であるかの問い合わせを行うことが回避される（停止される）（ステップＳ５１３）。そして、このとき、ユーザＵにインセンティブが付与される（ステップＳ５１４）。インセンティブとしては、例えば、集配料金の値引きがある。なお、ここでは、このときの問合せ停止及びインセンティブ付与は作業問合せ部２ｂにより実行される。

そして、乗車管理部２０４４の乗車処理部２ｃは、乗車希望のユーザＸの乗車要求が乗車の所定の条件を満たすか否かを判定する（ステップＳ５１５）。所定の条件として、ユ
ーザＵの集配ルートの所定範囲内にユーザＸの乗車希望場所や降車希望場所があることなどが規定されている。また、所定の条件として、ユーザＵへの集配サービス時の自律走行車両１００Ａの空きスペースに基づいて定められる乗車定員内であるか否かなどが規定されている。なお、ステップＳ５０７で登録ユーザの端末に通知されたり所定のサイトに公開されたりする集配のスケジュール情報には、乗車希望のユーザを募る情報として空き定員に関する情報が含まれてもよい。例えば、乗車定員は３名であり、そのうちの１名は集配作業を担当するユーザの枠であるとする。そして、集配作業を担当しない２名のユーザの乗車が確定していて、ユーザＸが集配作業を担当可能でない場合、乗車処理部２ｃは、ユーザＸの乗車要求は所定の条件を満たさないと判定する。また、例えば、すでに集配作業を担当するユーザの枠（例えば、１名）に、すでに集配作業を担当する１名のユーザＸ０の乗車が確定していて、さらにユーザＸに集配作業の要望がある場合、乗車処理部２ｃは、ユーザＸの乗車要求が所定の条件を満たさないと判定する（ステップＳ５１５で否定判定）。ただし、乗車処理部２ｃは、ユーザＸの集配作業の要望が充足されることが乗車の必須条件か否かを確認し、集配作業が乗車の必須条件ではない場合に、ユーザＸが集配作業を担当しないユーザであるとして処理すればよい。このように、集配作業を要望するユーザＸの数を制限することで、集配作業をしない通常のユーザがより多く乗車できる。乗車処理部２ｃが作業の可否を問わないで無条件でユーザを乗車させるようにすれば、２人目以降の乗車希望者を募り易くなるため、空きスペースを有効活用できるようになる。ただし、集配作業を担当するユーザの枠が１名に限定される訳ではない。以上のような処理によれば、乗車処理部２ｃは、集配に係る自律走行車両１００での乗車希望のユーザが集配先で集配作業をすることによる集配先ユーザへのサービスの向上と空きスペースを有効活用することとのバランスをとることが可能になる。このとき、ユーザＸの乗車は不可との通知がユーザＸのユーザ装置３００Ｘに送信される（ステップＳ５１７）。一方で、未だ集配作業を担当するユーザの枠が空いているときには、乗車処理部２ｃは、ユーザＸのユーザ装置３００Ｘから集配作業を担当可能であるとの回答を受け付ける。そして、ユーザＸの乗車要求が所定の条件のうち他の条件を満たすとき（ステップＳ５１５で肯定判定）、乗車処理部２ｃは、ユーザＸの乗車を確定してその旨の通知をユーザＸのユーザ装置３００Ｘに送信する（ステップＳ５１９）。なお、このとき、乗車処理部２ｃは、集配作業を引き受けたユーザＸにインセンティブを付与する。インセンティブとしては、例えば、ユーザＸの運賃割引やユーザＸが集配サービスを利用するときに使用可能なその費用の割引がある。

そして、自律走行車両１００Ａへのユーザの乗車確定人数が定員に達したとき、乗車処理部２ｃは満員と判定する（ステップＳ５２１で肯定判定）。一方で、定員に空きがあるとき（ステップＳ５２１で否定判定）、ステップＳ５０７に戻る。なお、このとき、通知されたり公開されたりするスケジュール情報には、その時点での空き定員が含まれるとよい。

自律走行車両１００Ａの定員に空きがあっても、集配予定時刻の所定時間前になっても、乗車希望のユーザがいないとき（ステップＳ５０９で否定判定）、ユーザＵから集配作業の要望があったか否かが判定される（ステップＳ５２３）。ユーザＵから集配作業の要望がなかったとき（ステップＳ５２３で否定判定）、ステップＳ５２９へ進む。一方、ユーザＵから集配作業の要望があったとき（ステップＳ５２３で肯定判定）、乗車希望であって集配作業を担当可能なユーザは未確定であるのか否かが判定される（ステップＳ５２５）。乗車希望であって集配作業を担当可能なユーザが未確定であるとき（ステップＳ５２５で肯定判定）、乗車処理部２ｃは、ユーザＵの集配サービスにおいて集配作業は無しとの通知を、ユーザＵのユーザ装置３００Ａに送信する。

そして、乗車管理部２０４４の関連付け部２ｄは、乗車希望のユーザの乗車情報を集配管理部２０４３に送り、集配情報に関連付ける（ステップＳ５２９）。これにより、集配
管理部２０４３の指令生成部１ｃは、集配情報と乗車情報とを含む運行指令を生成する（ステップＳ５３１）。制御部２０４の情報提供部２０４５は、運行指令の情報を、自律走行車両１００Ａに提供するつまり送信する（ステップＳ５３３）。例えば、サーバ装置２００の制御部２０４は、ユーザ装置３００Ｘから自律走行車両１００Ａへの乗車時に集配作業を担当可能であるという回答を受け付けた場合を想定する。このとき、制御部２０４は、集配作業を担当可能な乗車希望のユーザＸを自律走行車両１００Ａに乗車させるという乗車情報を関連付けて、運行指令を自律走行車両１００Ａに送信する。

図５に基づいて説明したサーバ装置２００の処理について、更に、図６に基づいて説明する。図６は、中央の欄にサーバ装置２００の処理を示し、その左側の欄に集配サービスの利用者であるユーザＵのユーザ装置３００Ａでの処理を示し、その右側の欄に乗車希望のユーザＸのユーザ装置３００Ｘでの処理を示す。また、同図中上側から下側に向けて時間が経過するようにそれらを表す。なお、図６の処理は、自律走行車両１００Ａの乗車定員が１名であるときについての処理例である。

ユーザＵがユーザ装置３００Ａを介して集配要求を申し込む送信を行うと（ステップＳ６０１）、サーバ装置２００はその集配要求を受信して受け付ける（ステップＳ６０３、ステップＳ５０１に対応）。集配要求に作業情報が無いとき、サーバ装置２００は、集配作業を望むのか否かの問い合わせをユーザ装置３００Ａに対して送信する（ステップＳ６０５）。これを受信したユーザ装置３００Ａは集配作業を希望するとの回答をサーバ装置２００に送信する（ステップＳ６０７）。

集配要求を受け付けたサーバ装置２００は、ユーザＵの集配に係る自律走行車両１００Ａへの乗車希望を募るための通知を、登録ユーザの端末に送信する（ステップＳ６０９、ステップＳ５０７に対応）。ここでは、送信先の端末は、図１に示すユーザＸのユーザ装置３００Ｘ及びユーザＹのユーザ装置３００Ｙである。この通知には上記スケジュール情報が含まれる。ここでは、スケジュール情報に、図１のセンタＣから集配先Ｐ１までのルートＲが集配ルートとして、集配予定時刻と共に含まれる。ユーザＸは、自己の都合に合わせて自律走行車両１００Ａへの乗車を検討することができる。ユーザＸがその集配予定時刻頃、例えば図１に示すユーザＸの家である第１ポイントＰ２から第２ポイントＰ３に移動することを考えていたとする。すると、ユーザＸは、ユーザ装置３００Ｘを介して自律走行車両１００Ａへの乗車希望を要求する返信を行う（ステップＳ６１１）。このときの乗車要求は、乗車希望場所としてのバス停ＢＳ１と、降車希望場所としてのバス停ＢＳ２を含むが、集配作業に関しての情報を含まない。ここで、ユーザＵの集配作業の回答（ステップＳ６０７）が集配作業を希望するものであったとき、サーバ装置２００は集配作業を担当可能であるのか否かの問い合わせをユーザ装置３００Ｘに対して行う（ステップＳ６１３）。これに対して、ユーザＸがその集配作業を担当可能である場合、担当可能との回答の返信を、そうでない場合には担当不可能との回答の返信を行う（ステップＳ６１５、ステップＳ５１３に対応）。一方、ユーザＵの集配作業の回答（ステップＳ６０７）が集配作業を希望しないもの、あるいは、集配不要であったとき、集配作業を削減できるので、その削減に対するインセンティブをユーザＵに与える（ステップＳ６１７、ステップＳ５１４に対応）。インセンティブとしては、例えば、集配料金の値引きがある。

ユーザＸのユーザ装置３００Ｘから乗車要求があり、集配作業に関する回答があったとき、乗車要求の条件が所定の条件を満たすか否かの判定が行われる（ステップＳ６１９、ステップＳ５１５に対応）。そして、その結果、ユーザＸの自律走行車両１００Ａへの乗車が確定したとき、サーバ装置２００はユーザ装置３００Ｘに乗車確定の旨の通知を行うと共に、集配作業に対するインセンティブをユーザＸに付与する（ステップＳ６２１、ステップＳ５１９に対応）。

ここで、例えば、ユーザＵの集配作業の回答（ステップＳ６０７）が集配作業を希望するものであって、ユーザＸがその集配作業を担当可能である場合（ステップＳ６１５、ステップＳ５１３に対応）を想定する。この場合、乗車管理部２０４４の乗車処理部２ｃは、ユーザＸの乗車要求が所定の条件を満たすかを判定する。この乗車要求は、集配ルートＲ上のバス停ＢＳ１から、同集配ルートＲ上のバス停ＢＳ２までである。そして、バス停ＢＳ２は集配先Ｐ１から所定距離範囲内であり、集配先Ｐ１からセンタＣに戻る自律走行車両の帰路上にある。そこで、この場合、乗車管理部２０４４の乗車処理部２ｃは、乗車要求の条件が所定の条件を満たす、と判断することができる（ステップＳ５１５で肯定判定）。

乗車が確定したとき、集配情報への乗車情報の関連付け処理（ステップＳ６２３、ステップＳ５２９に対応）、運行指令の生成処理（ステップＳ６２５、ステップＳ５３１に対応）及びその提供処理（ステップＳ６２７、ステップＳ５３３に対応）が行われる。

運行指令を受信した自律走行車両１００Ａの情報処理装置１０２の処理について、図７のフローチャートに基づいて説明する。自律走行車両１００Ａの制御部１０４の情報取得部１０４１は、サーバ装置２００からの運行指令の情報を取得する（ステップＳ７０１）。そして、制御部１０４の計画生成部１０４２は、運行指令に基づいて、とくにそのうちの集配情報と乗車情報とに基づいて運行計画を生成する（ステップＳ７０３）。計画生成部１０４２は、基本的には、集配情報と乗車情報とに基づいて運行計画を生成するが、当日の道路の状況、例えば通行止め情報などを考慮して運行計画を生成する。例えば、次の運行計画が生成される。集配ルートＲに沿って集配先Ｐ１に走行する自律走行車両１００Ａは、途中のバス停ＢＳ１でユーザＸを乗車させ、ユーザＸに集配先Ｐ１で集配作業を担わせ、その後、帰路のバス停ＢＳ２でユーザＸを降車させる、という運行計画である。そして、通過予定時間に配慮しつつ、自律走行車両１００Ａの制御部１０４のタスク制御部１０４４は運行計画に基づいて運行する（ステップＳ７０５）。なお、この運行により、自律走行車両１００Ａは、ユーザＵにピザを届けるに際して、ユーザＸを集配作業の作業員として、つまりピザの配達員とすることができる。

なお、ピザの配達の場合を例に説明したが、例えば荷物の集荷の場合も同様である。荷物の集荷の場合、ユーザＵは荷物を受け渡すユーザになる。このときも、自律走行車両１００Ａは集配先に移動する間に、ユーザＸをその途中で乗車させて、集配先でユーザＸがユーザＵから荷物を受け取り自律走行車両に運ぶことができる。

以上、上記実施形態によれば、集配に係る自律走行車両へ乗車希望のユーザを募り、そのユーザに集配先での集配作業を担当させることができる。このように、集配サービスに関して、荷物の集配のための自律走行車両と、そのサービスの利用者との間での集配作業が好適に可能になる。

また、上記実施形態によれば、飲食物であるピサの配達の場合、利用者たるユーザＵは自律走行車両にピザを取りに行くのではなく、ユーザＸからつまり人から、ピザを受け取ることができる。これは、ユーザＵにピザという食べ物をより美味しく感じさせるのに役立つ。

更に、上記実施形態によれば、自律走行車両の定員のうち、１人だけが集配作業を担当可能なユーザに割り当てられる。したがって、その１人分を除いて、自律走行車両は、地域の共有の交通機関となることができる。

次に、本発明の第２実施形態を説明する。以下では、本第２実施形態に係る集配システムにおける、上記第１実施形態に係る集配システムＳとの相違点について、主として説明
する。既に説明した構成要素に対応する構成要素には、同様に同じ符号を付して、重複説明を省略する。

上記第１実施形態の集配システムＳでは、集配のスケジュール情報を所定のサイトに公開したり、登録ユーザの端末に通知したりして、自律走行車両へ乗車希望のユーザを募った。本第２実施形態では、予め乗車希望のユーザを募っておき、その中から集配に係る自律走行車両へ乗車希望のユーザを特定するために、集配のスケジュール情報と所定の条件を満たす移動スケジュールの登録ユーザを抽出することが実行される。以下では、まずは、本第２実施形態におけるシステムでのサーバ装置２００について図８に基づいて説明する。

情報処理装置であるサーバ装置２００は、第１実施形態のサーバ装置２００と比べて、制御部２０４の構成の点で相違する。制御部２０４は、図８に示すように、機能モジュールとして、前述の情報取得部２０４１、車両管理部２０４２、集配管理部２０４３、乗車管理部２０４４及び情報提供部２０４５を有しているが、その乗車管理部２０４４の構成に相違点を有する。乗車管理部２０４４は、ユーザ管理部２ｅ、マッチング部２ｆに加えて、前述の作業問合せ部２ｂ、乗車処理部２ｃ及び関連付け部２ｄを有している。マッチング部２ｆは、受付部２ｇ及び抽出部２ｈを有している。これらの各機能モジュールは、主記憶部や記憶部２０６に記憶されたプログラムを制御部２０４のＣＰＵによって実行することで実現される。

制御部２０４の乗車管理部２０４４のユーザ管理部２ｅは、情報取得部２０４１を介して、登録ユーザの端末であるユーザ装置３００から移動スケジュールを受け付ける。移動スケジュールは、予定移動時刻と、予定移動ルートとを含む。この受け付けた移動スケジュールは、記憶部２０６のユーザ情報データベース２０６３に、検索可能に記憶される。なお、移動スケジュールからそれに関連付けられた登録ユーザの情報（例えばユーザＩＤ）を取得可能に、ユーザ情報データベース２０６３は構築されている。なお、ユーザ管理部２ｅが受け付ける登録ユーザの移動スケジュールは、マッチング部２ｆでのマッチング処理に供されるべく提供されるものである。したがって、移動スケジュールが受け付けられて記憶されている登録ユーザは、自律走行車両へ乗車希望のユーザである。

マッチング部２ｆは、集配サービスの利用者であるユーザＵのユーザ装置３００Ａから集配要求があったときにその集配のスケジュール情報を受け付け、そのスケジュール情報と所定の条件を満たす移動スケジュールの登録ユーザを抽出する。ユーザ装置３００Ａから集配要求があったとき、集配管理部２０４３の予定生成部１ａはスケジュール情報を生成する。このスケジュール情報を、乗車管理部２０４４のマッチング部２ｆの受付部２ｇは受け付ける。受け付けた集配のスケジュール情報は、集配ルートと、集配予定時刻と、その集配ルートでの通過予定時刻とを含む。乗車管理部２０４４のマッチング部２ｆの抽出部２ｈは、集配スケジュールと所定の条件を満たす、登録ユーザの移動スケジュールを抽出し、その移動スケジュールの登録ユーザを集配に係る自律走行車両へ乗車希望のユーザと特定する。なお、この特定した乗車希望のユーザへの集配作業の問い合わせは前述の作業問合せ部２ｂにより行われる。

サーバ装置２００の制御部２０４による処理について、図９のフローチャートに基づいて説明する。なお、図９のフローチャートは、自律走行車両１００Ａの乗車定員が１名であり、この乗車定員は集配作業を行うユーザに割り振られている場合についての処理例である。

集配サービスを望むユーザＵからの集配要求がユーザ装置３００Ａから送信されると、サーバ装置２００の制御部２０４における集配管理部２０４３の予定生成部１ａは、それ
を取得する（ステップＳ９０１で肯定判定）。ここで、集配要求に、集配作業の情報が含まれているか否かが判定される（ステップＳ９０３）。集配作業の情報が集配要求に含まれていないとき、サーバ装置２００の制御部２０４における集配管理部２０４３の作業確認部１ｂは、ユーザＵのユーザ装置３００Ａに、その集配作業を望むか否かを問い合わせる（ステップＳ９０５）。

サーバ装置２００の制御部２０４における集配管理部２０４３の予定生成部１ａは、集配要求を受け付けたので、その予定のスケジュール情報を生成する。そして、このとき、予定生成部１ａは、集配に係る移動体として自律走行車両１００Ａを決定する。

一方で、サーバ装置２００のユーザ管理部２ｅは、登録ユーザのうち、集配に係る自律走行車両１００に乗車希望のユーザが使用するユーザ装置３００が送信した移動スケジュールを、情報取得部２０４１を介して受け付ける。この移動スケジュールは、前述のように、予定移動時刻と、予定移動ルートとを含む。ユーザ管理部２ｅは、この移動スケジュールを検索可能に、記憶部２０６のユーザ情報データベース２０６３に記憶する。

このように登録ユーザの移動スケジュールが記憶されている状態で、乗車管理部２０４４の作業問合せ部２ｂは、集配作業を望むか否かを問い合わせた結果（ステップＳ９０５）、ユーザＵから集配作業の要望があったか否かを判定する（ステップＳ９０７）。ユーザＵから集配作業の要望があるとき（ステップＳ９０７で肯定判定）、作業問合せ部２ｂは、予定生成部１ａで生成した集配のスケジュール情報をマッチング部２ｆに送信させる。マッチング部２ｆの受付部２ｇは、予定生成部１ａが送信したそのスケジュール情報を受け付ける。そして、マッチング部２ｆの抽出部２ｈは、マッチング処理を行う（ステップＳ９０９）。このマッチング処理を所定のプログラムに従って実行することで、マッチング部２ｆの抽出部２ｈは、集配のスケジュール情報と所定の条件を満たす移動スケジュールを抽出する。移動スケジュールは登録ユーザと関連付けられてユーザ情報データベース２０６３に記憶されているので、移動スケジュールを抽出することでそれに関連付けられた登録ユーザも抽出される。ここでは、上記ユーザＸが登録ユーザとして抽出されたとして、以下説明する。

マッチング処理の結果、登録ユーザＸを抽出できたとき（ステップＳ９１１で肯定判定）、乗車管理部２０４４の作業問合せ部２ｂは、抽出した登録ユーザＸの端末であるユーザ装置３００Ｘに集配作業を担当可能であるかを問い合わせる（ステップＳ９１３）。サーバ装置２００の制御部２０４の乗車管理部２０４４における作業問合せ部２ｂは、このユーザ装置３００Ｘからの集配作業に関する回答を受け付けることができる（ステップＳ９１５）。このときの回答は、ユーザＸの乗車条件も含む。登録ユーザの移動スケジュールは変更の可能性があるからである。

乗車管理部２０４４の乗車処理部２ｃは、乗車希望のユーザＸの乗車要求が乗車の所定の条件を満たすか否かを判定する（ステップＳ９１７）。所定の条件として、ユーザＵの集配ルートの所定範囲内にユーザＸの乗車希望場所や降車希望場所があることなどが規定されている。

そして、ユーザＸの乗車要求が所定の条件を満たすとき（ステップＳ９１７で肯定判定）、ユーザＸの乗車が確定し、ユーザＸにインセンティブが付与される（ステップＳ９１９）。例えば、これにより、自律走行車両１００Ａへの乗車料金が、集配作業料金分減額される、例えば無料にされる。こうして乗車が確定したユーザの乗車情報は、集配情報に関連付けられる（ステップＳ９２１）。これは、第１実施形態において既に説明した通りである。

一方、ユーザＸの乗車要求が所定の条件を満たさないとき（ステップＳ９１７で否定判定）、上記マッチング処理（ステップＳ９０９）が繰り返される。しかし、その結果、ユーザを抽出できないとき（ステップＳ９１１で否定判定）、集配作業を担当可能なユーザがいないので、集配作業無しとの通知がユーザ装置３００Ａに送信される（ステップＳ９２３）。なお、ステップＳ９１１で否定判定されて集配作業無しとの通知を受けたユーザＵは、集配自体をキャンセルすることも可能である。

また、ユーザＵから集配作業は不要であるという回答があったときも（ステップＳ９０７で否定判定）、集配作業無しとの通知がユーザ装置３００Ａに送信される（ステップＳ９２３）。そして、集配作業無しとの通知のとき、ユーザＵにインセンティブが付与される（ステップＳ９２３）。そして、この集配作業は不要であるという回答を受け付けたとき（ステップＳ９０７で否定判定）図９から明らかなように、ユーザＸのユーザ装置３００Ｘに集配作業を担当可能であるかの問い合わせを行うことは停止される。

そして、乗車情報が関連付けられた或いは関連付けられていない集配作業の情報に基づいて、運行指令の生成及びその提供が行われる（ステップＳ９２５、Ｓ９２７）。これは、第１実施形態の図５におけるステップＳ５３１及びＳ５３３と同じである。

図９に基づいて説明したサーバ装置２００の処理について、更に、図１０に基づいて説明する。図１０は、第１実施形態における図６に相当する図である。なお、図１０の処理は、自律走行車両１００Ａの乗車定員が１名であるときについての処理例である。

集配とは関係のない登録ユーザのユーザ装置３００から移動スケジュールの登録がなされると（ステップＳ１００１）、サーバ装置２００のユーザ管理部２ｅはそれを受け付けて記憶する（ステップＳ１００３）。

一方、ユーザＵがユーザ装置３００Ａを介して集配要求を申し込む送信を行うと（ステップＳ１００５）、サーバ装置２００はその集配要求を受信して受け付ける（ステップＳ１００７、ステップＳ９０１に対応）。集配要求に作業要求が無いとき、サーバ装置２００は、集配作業を望むのか否かの問い合わせをユーザ装置３００Ａに対して送信する（ステップＳ１００９、ステップＳ９０５に対応）。これを受信して、ここでは、ユーザ装置３００ＡはユーザＵの集配作業の回答をサーバ装置２００に送信する（ステップＳ１０１１）。この回答で、集配作業が不要のとき、集配作業分のインセンティブがユーザＵに付与される（ステップＳ１０１５、ステップＳ９２３に対応）。

集配要求を受け付けたサーバ装置２００は、ユーザＵの集配に係る自律走行車両１００Ａへ乗車希望のユーザを特定するために、上記マッチング処理を行う（ステップＳ１０１７、ステップＳ９０９に対応）。そして、ユーザＵの集配作業の回答（ステップＳ１０１１）が集配作業を希望するものであった場合、マッチングを実行する（Ｓ１０１７）。マッチング処理の結果、特定したユーザＸのユーザ装置３００Ｘに集配作業を担当可能であるのか否かの問い合わせを行う（ステップＳ１０１９、ステップＳ９１３に対応）。これに対して、ユーザＸがその集配作業を担当可能である場合、担当可能との回答の返信を、そうでない場合には担当不可能との回答の返信を行う（ステップＳ１０２１）。

ユーザＸから乗車要求があり、集配作業に関する回答があったとき、乗車要求の条件が所定の条件を満たすか否かの判定が行われる（ステップＳ１０２３、ステップＳ９１７に対応）。そして、その結果、ユーザＸの自律走行車両１００Ａへの乗車が確定したとき、サーバ装置２００はユーザ装置３００Ｘに乗車確定の旨の通知を行うと共に、集配作業に対するインセンティブをユーザＸに付与する（ステップＳ１０２５、ステップＳ９１９に対応）。

乗車が確定したとき、集配情報への乗車情報の関連付け処理（ステップＳ１０２７、ステップＳ９２１に対応）、運行指令の生成処理（ステップＳ１０２９、ステップＳ９２５に対応）及びその提供処理（ステップＳ１０３１、ステップＳ９２７に対応）が行われる。

運行指令を受けた自律走行車両１００Ａの処理については、第１実施形態において図７に基づいて説明した通りである。

以上説明したように、本第２実施形態においても、集配に係る自律走行車両へ乗車希望のユーザに集配先での集配作業を担当させることができる。このように、集配サービスに関して、荷物の集配のための自律走行車両と、そのサービスの利用者との間での集配作業が好適に可能になる。

また、本第２実施形態によれば、集配に係る自律走行車両へ乗車希望の登録ユーザの移動スケジュールを受け付けておき、集配要求があったときに上記マッチング処理を行うことで、乗車希望のユーザをより迅速に特定することができる。そして、そのような登録ユーザに集配作業を担当可能であるか否かを問い合わせることで、集配作業の作業員を確保する度合いをより好適に高めることができる。

なお、第２実施形態において、集配作業を担当可能なユーザを定めることができないとき、第１実施形態で説明したように、スケジュール情報を通知又は公開して、乗車希望のユーザを募ってもよい。そして、乗車希望のユーザに、集配作業を担当可能であるか否かを問い合わせるようにしてもよい。

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

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

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

Ｓ 集配システム
１００、１００Ａ 自律走行車両
１０２ 情報処理装置
１０４ 制御部
１０６ センサ
１０８ 位置情報取得部
１１０ 駆動部
１１２ 通信部
１１４ 記憶部
２００ サーバ装置
２０２ 通信部
２０４ 制御部
２０６ 記憶部
２０４１ 情報取得部
２０４２ 車両管理部
２０４３ 集配管理部
２０４４ 乗車管理部
２０４５ 情報提供部
３００、３００Ａ、３００Ｘ、３００Ｙ ユーザ装置
３０２ 通信部
３０４ 制御部
３０６ 記憶部

Claims (13)

1. 荷物の集配のために運行する移動体へ乗車希望のユーザの端末に対して、集配先で前記移動体と集配サービスの利用者との間での前記荷物の集配作業を担当可能であるかの問い合わせを行うことと、
   前記端末から前記移動体への乗車時に前記集配作業を担当可能であるという回答を受け付けたとき、前記集配作業を担当可能な前記乗車希望のユーザを前記移動体に乗車させる指令を前記移動体に送信することと
   を実行する制御部を備える、情報処理装置。
2. 前記制御部は、
   前記移動体へ乗車希望のユーザを募るため、前記集配のスケジュール情報を所定のサイトに公開する又は登録ユーザの端末に通知することと、
   前記所定のサイト又は前記登録ユーザの端末を介してユーザからの乗車希望を受け付けることと
   を実行する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記移動体へ乗車希望のユーザを特定するために、前記集配のスケジュール情報と所定の条件を満たす移動スケジュールの登録ユーザとを抽出すること
   を実行する、
   請求項１に記載の情報処理装置。
4. 前記制御部は、
   前記利用者の端末から前記集配作業は不要であるという回答を受け付けたとき、前記集配作業を担当可能であるかの問い合わせを行うことを停止させること
   を更に実行する、
   請求項１から３のいずれか一項に記載の情報処理装置。
5. 前記制御部は、前記利用者の前記端末から前記集配作業は不要であるという前記回答を受け付けたとき、前記利用者にインセンティブを付与することを更に実行する、
   請求項４に記載の情報処理装置。
6. 前記制御部は、前記集配作業を引き受けた前記ユーザにインセンティブを付与することを更に実行する、
   請求項１から５のいずれか一項に記載の情報処理装置。
7. 少なくとも１つのコンピュータが、
   荷物の集配のために運行する移動体へ乗車希望のユーザの端末に対して、集配先で前記移動体と集配サービスの利用者との間での前記荷物の集配作業を担当可能であるかの問い合わせを行うことと、
   前記端末から前記移動体への乗車時に前記集配作業を担当可能であるという回答を受け付けたとき、前記集配作業を担当可能な前記乗車希望のユーザを前記移動体に乗車させる指令を前記移動体に送信することと
   を実行する、情報処理方法。
8. 前記少なくとも１つのコンピュータが、
   前記移動体へ乗車希望のユーザを募るため、前記集配のスケジュール情報を所定のサイトに公開する又は登録ユーザの端末に通知することと、
   前記所定のサイト又は前記登録ユーザの端末を介してユーザからの乗車希望を受け付けることと
   を実行する、
   請求項７に記載の情報処理方法。
9. 前記少なくとも１つのコンピュータが、
   前記移動体へ乗車希望のユーザを特定するために、前記集配のスケジュール情報と所定の条件を満たす移動スケジュールの登録ユーザを抽出すること
   を実行する、
   請求項７に記載の情報処理方法。
10. 前記少なくとも１つのコンピュータが、
    前記利用者の端末に前記集配作業を望むのかの問い合わせを行うことと、
    前記利用者の前記端末から前記集配作業は不要であるという回答を受け付けたとき、前記集配作業を担当可能であるかの問い合わせを行うことを停止させることと
    を更に実行する、
    請求項７から９のいずれか一項に記載の情報処理方法。
11. 前記少なくとも１つのコンピュータが、前記利用者の前記端末から前記集配作業は不要であるという前記回答を受け付けたとき、前記利用者にインセンティブを付与することを更に実行する、
    請求項１０に記載の情報処理方法。
12. 前記少なくとも１つのコンピュータが、前記集配作業を引き受けた前記ユーザにインセンティブを付与することを更に実行する、
    請求項７から１１のいずれか一項に記載の情報処理方法。
13. 少なくとも１つのコンピュータに、
    荷物の集配のために運行する移動体へ乗車希望のユーザの端末に対して、集配先で前記移動体と集配サービスの利用者との間での前記荷物の集配作業を担当可能であるかの問い合わせを行うことと、
    前記端末から前記移動体への乗車時に前記集配作業を担当可能であるという回答を受け付けたとき、前記集配作業を担当可能な前記乗車希望のユーザを前記移動体に乗車させる指令を前記移動体に送信することと
    を実行させるための
    プログラム。
    
    

Images