特許 7494695 情報処理装置、情報処理方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-27

(45)【発行日】2024-06-04

(54)【発明の名称】情報処理装置、情報処理方法、およびプログラム

(51)【国際特許分類】

   G06Q 50/47 20240101AFI20240528BHJP

【ＦＩ】

G06Q50/47

【請求項の数】 16

(21)【出願番号】P 2020174204

(22)【出願日】2020-10-15

(65)【公開番号】P2022065549

(43)【公開日】2022-04-27

【審査請求日】2022-08-24

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】長谷川 英男

【審査官】永野 一郎

(56)【参考文献】

【文献】特開２０１９－２００７１１（ＪＰ，Ａ）

【文献】特開２０１８－１４２２８９（ＪＰ，Ａ）

【文献】特開２０１８－０８１５５６（ＪＰ，Ａ）

【文献】特開２００４－１８４７５２（ＪＰ，Ａ）

【文献】特開２０１８－１６９５０４（ＪＰ，Ａ）

【文献】特開２０１２－２３４３７９（ＪＰ，Ａ）

【文献】特開２０１８－２０６２２５（ＪＰ，Ａ）

【文献】特開２０１４－２３８８３１（ＪＰ，Ａ）

【文献】特開２０１６－１２６４０５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

人の行動に関するデータである行動データを取得することと、
前記行動データに基づいて、所定の期間内に移動を開始することが推定され、車両による輸送サービスの利用を希望する可能性があるユーザを第一のユーザとして特定することと、
複数の前記第一のユーザの中から、前記輸送サービスの提供を提案する対象である複数の第二のユーザを選択することと、
前記複数の第二のユーザにそれぞれ関連付いた装置に対して、前記輸送サービスの提供を提案するメッセージを送信することと、
を実行する制御部を有し、
前記制御部は、前記第二のユーザが前記提案を受諾する確率である受諾確率に基づいて、前記選択される前記第二のユーザの上限人数を決定する、
情報処理装置。

【請求項2】

前記制御部は、前記輸送サービスを同時に提供できる能力を表す値と、前記受諾確率と、に基づいて、前記第二のユーザの上限人数を決定する、
請求項１に記載の情報処理装置。

【請求項3】

前記制御部は、前記第二のユーザの移動環境に関するデータである環境データを取得し、
前記環境データに基づいて、前記受諾確率を決定する、
請求項１または２に記載の情報処理装置。

【請求項4】

前記移動環境と、前記受諾確率とを関連付けたデータを記憶する記憶部をさらに有する、
請求項３に記載の情報処理装置。

【請求項5】

前記制御部は、所定の条件を満たすユーザを優先して前記選択を行う、
請求項１から４のいずれか１項に記載の情報処理装置。

【請求項6】

前記制御部は、前記複数の第一のユーザのそれぞれについて、前記第二のユーザとして
選択される優先度を決定する、
請求項１から５のいずれか１項に記載の情報処理装置。

【請求項7】

前記制御部は、各ユーザによる前記車両の利用履歴に基づいて前記優先度を決定する、
請求項６に記載の情報処理装置。

【請求項8】

前記制御部は、各ユーザに関連付いた荷物の量にさらに基づいて前記優先度を決定する、
請求項７に記載の情報処理装置。

【請求項9】

前記制御部は、前記優先度が所定の値よりも高い前記第一のユーザを、前記第二のユーザとして選択する、
請求項６から８のいずれか１項に記載の情報処理装置。

【請求項10】

コンピュータが実行する情報処理方法であって、
人の行動に関するデータである行動データを取得するステップと、
前記行動データに基づいて、所定の期間内に移動を開始することが推定され、車両による輸送サービスの利用を希望する可能性があるユーザを第一のユーザとして特定するステップと、
複数の前記第一のユーザの中から、前記輸送サービスの提供を提案する対象である複数の第二のユーザを選択するステップと、
前記複数の第二のユーザにそれぞれ関連付いた装置に対して、前記輸送サービスの提供を提案するメッセージを送信するステップと、
前記第二のユーザが前記提案を受諾する確率である受諾確率に基づいて、前記選択される前記第二のユーザの上限人数を決定するステップと、
を含む、情報処理方法。

【請求項11】

前記輸送サービスを同時に提供できる能力を表す値と、前記受諾確率と、に基づいて、前記第二のユーザの上限人数を決定する、
請求項１０に記載の情報処理方法。

【請求項12】

前記第二のユーザの移動環境に関するデータである環境データを取得し、前記環境データに基づいて、前記受諾確率を決定するステップをさらに含む、
請求項１０または１１に記載の情報処理方法。

【請求項13】

前記移動環境と、前記受諾確率とを関連付けたデータを取得するステップをさらに含む、
請求項１２に記載の情報処理方法。

【請求項14】

前記複数の第一のユーザのそれぞれについて、前記第二のユーザとして選択される優先度を決定するステップをさらに含む、
請求項１０から１３のいずれか１項に記載の情報処理方法。

【請求項15】

前記優先度が所定の値よりも高い前記第一のユーザを、前記第二のユーザとして選択する、
請求項１４に記載の情報処理方法。

【請求項16】

請求項１０から１５のいずれか１項に記載の情報処理方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザの移動をサポートする技術に関する。

【背景技術】

【0002】

ユーザの依頼に応じて車両の配車を適時行うサービスがある。例えば、特許文献１には、簡略な操作でタクシーの配車を依頼することができるアプリケーションシステムが開示されている。

【0003】

一方、近い将来、オンデマンドで運行される自律走行車両によってユーザの移動をサポートするシステムが実現されることが予想される。さらに、ユーザが意思表示をする前に、当該ユーザが移動手段を必要とすることを推定し、自律的に配車の提案を行う技術が実用化されることが期待される。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１４－０２９５８０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

斯様なシステムにおいては、車両の稼働率が問題となる。例えば、ユーザから寄せられたリクエストに基づいて車両を配車する場合、稼働する車両の台数が予め分かる。一方、自律的に配車を提案する場合、これを受諾するかはユーザ次第であるため、状況によっては稼働しない車両が発生してしまう。

【0006】

本発明は、ユーザの元へ車両を自律的に派遣するシステムにおいて、車両の稼働率を向上させることを目的とする。

【課題を解決するための手段】

【0007】

本開示の第一の態様は、所定のサービスを受ける可能性がある複数の第一のユーザの中から、前記所定のサービスの提供を提案する対象である複数の第二のユーザを選択することと、前記複数の第二のユーザにそれぞれ関連付いた装置に対して、前記所定のサービスの提供を提案するメッセージを送信することと、を実行する制御部を有し、前記制御部は、前記第二のユーザが前記提案を受諾する確率である受諾確率に基づいて、前記選択される前記第二のユーザの上限人数を決定する、情報処理装置である。

【0008】

また、本開示の第二の態様は、所定のサービスを受ける可能性がある複数の第一のユーザの中から、前記所定のサービスの提供を提案する対象である複数の第二のユーザを選択するステップと、前記複数の第二のユーザにそれぞれ関連付いた装置に対して、前記所定のサービスの提供を提案するメッセージを送信するステップと、前記第二のユーザが前記提案を受諾する確率である受諾確率に基づいて、前記選択される前記第二のユーザの上限人数を決定するステップと、を含む、情報処理方法である。

【0009】

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

【発明の効果】

【0010】

本発明によれば、ユーザの元へ車両を自律的に派遣するシステムにおいて、車両の稼働
率を向上させることができる。

【図面の簡単な説明】

【0011】

【図1】配車システムの概要を説明する図。

【図2】配車システムの構成要素をより詳細に示した図。

【図3A】記憶部に記憶される端末位置データの例。

【図3B】記憶部に記憶される行動モデルの例。

【図3C】記憶部に記憶される確率データの例。

【図3D】記憶部に記憶される車両データの例。

【図4】制御部が有する機能モジュール間におけるデータフロー図。

【図5】問い合わせキューを説明する図。

【図6】第一の実施形態において制御部が行う処理のフローチャート。

【図7】第一の実施形態において制御部が行う処理のフローチャート。

【図8】第一の実施形態において制御部が行う処理のフローチャート。

【発明を実施するための形態】

【0012】

近い将来、ユーザに対して、自動運転車両による移動サービスの提供を自律的に提案する技術が実用化されることが期待される。

【0013】

斯様なシステムでは、車両の稼働率が問題になる。事業性を考慮すると、システムの管理下にある車両を同時に全て稼働させることが好ましい。しかし、全てのユーザが提案を受諾するとは限らないため、稼働しない車両が出てしまう場合がある。一方、これを見越して、稼働可能な台数よりも多くのユーザに対して提案を行うと、オーバーブッキングの問題が発生しうる。

【0014】

この問題を解決するためには、移動サービスの提供を提案するユーザの上限人数を適切に決定しなければならない。本実施形態に係る情報処理装置は、この問題を解決する。

【0015】

本開示の一態様に係る情報処理装置は、所定のサービスを受ける可能性がある複数の第一のユーザの中から、前記所定のサービスの提供を提案する対象である複数の第二のユーザを選択することと、前記複数の第二のユーザにそれぞれ関連付いた装置に対して、前記所定のサービスの提供を提案するメッセージを送信することと、を実行する制御部を有し、前記制御部は、前記第二のユーザが前記提案を受諾する確率である受諾確率に基づいて、前記選択される前記第二のユーザの上限人数を決定する。

【0016】

第一のユーザは、所定のサービスを受ける可能性があるユーザである。例えば、所定のサービスが、車両による輸送サービスであった場合、第一のユーザは、前記車両による移動を希望する可能性があるユーザとすることができる。
第二のユーザは、サービスの提供を打診する対象のユーザである。情報処理装置が有する制御部は、第二のユーザが当該サービスの提供を受諾する確率（受諾確率）に基づいて、第二のユーザの上限人数を決定する。なお、受諾確率は、複数の第二のユーザの平均値であってもよい。受諾確率を利用することで、稼働率を最大化することができる。

【0017】

また、前記制御部は、前記所定のサービスを同時に提供できる能力を表す値と、前記受諾確率と、に基づいて、前記第二のユーザの上限人数を決定することを特徴としてもよい。
例えば、受諾確率の逆数に、サービスを同時に提供できる能力を表す値を乗算することで、第二のユーザの上限人数を算出してもよい。例えば、輸送サービスの提供を打診されたユーザが、８０％の確率でこれを受諾し、同時に稼働可能な車両が１００台あった場合、最大１２５人に対して輸送サービスの提供を打診することができる。かかる方法による
と、サービスの稼働率を最大化することができる。

【0018】

また、前記制御部は、人の行動に関するデータである行動データを取得することと、前記行動データに基づいて、所定の期間内に移動を開始することが推定されるユーザを前記第一のユーザとして特定することと、をさらに実行することを特徴としてもよい。
行動データに基づいて、あるユーザに移動の予兆が見られることを判定することができる。これにより、例えば、所定の時間以内に移動を開始することが推定されるユーザに対して、輸送サービスの提供を打診するといったことが可能になる。

【0019】

また、前記制御部は、前記第二のユーザの移動環境に関するデータである環境データを取得し、前記環境データに基づいて、前記受諾確率を決定することを特徴としてもよい。
ユーザが提案を受諾する確率は、当該ユーザが置かれている環境（例えば、現在位置、天候、曜日、交通の状況、または時間帯など）に応じて変化しうる。よって、移動環境に関するデータに基づいて受諾確率を決定することで、より正確な推定を行うことが可能になる。
情報処理装置は、前記移動環境と、前記受諾確率とを関連付けたデータを記憶する記憶部をさらに有していてもよい。

【0020】

また、前記制御部は、所定の条件を満たすユーザを優先して前記選択を行うことを特徴としてもよい。
また、前記制御部は、前記複数の第一のユーザのそれぞれについて、前記第二のユーザとして選択される優先度を決定することを特徴としてもよい。
また、前記制御部は、前記優先度が所定の値よりも高い前記第一のユーザを、前記第二のユーザとして選択することを特徴としてもよい。

【0021】

第一のユーザのうち、どのユーザを第二のユーザとするかを、所定の条件によって判断してもよい。例えば、輸送サービスの利用が有益であるユーザであるほど、優先して当該サービスの提供を打診するようにしてもよい。

【0022】

また、前記制御部は、各ユーザによる前記車両の利用履歴に基づいて前記優先度を決定することを特徴としてもよい。
例えば、過去に車両を利用しているユーザほど、高い利用率が見込まれるため、優先度を高くすることができる。

【0023】

また、前記制御部は、各ユーザに関連付いた荷物の量にさらに基づいて前記優先度を決定することを特徴としてもよい。
例えば、ユーザが運んでいる荷物の量が多い場合、車両を派遣したほうが好ましい。ユーザが運んでいる荷物の量は、当該ユーザを撮像して得られた画像に基づいて判定してもよいし、当該ユーザによってなされた決済の履歴などに基づいて判定してもよい。

【0024】

以下、図面に基づいて、本開示の実施の形態を説明する。以下の実施形態の構成は例示であり、本開示は実施形態の構成に限定されない。

【0025】

（第一の実施形態）
第一の実施形態に係る配車システムの概要について、図１を参照しながら説明する。本実施形態に係る配車システムは、ユーザが所持する端末であるユーザ端末２００と、輸送サービスを提供する自律走行車両（以下、車両３００）と、当該車両３００を制御するサーバ装置１００と、を含んで構成される。

【0026】

ユーザ端末２００は、ユーザが所持する携帯端末である。ユーザ端末２００は、当該ユ
ーザの行動に関するデータを、サーバ装置１００に周期的に送信する。本実施形態では、ユーザ端末２００は、ユーザの行動に関するデータとして、自端末の位置を表すデータを送信する。

【0027】

車両３００は、ユーザを乗車させて走行可能な自律車両である。車両３００は、サーバ装置１００から送信された指令に従って無人走行することができる。また、車両３００は、経路の途中においてユーザを乗降させることができる。システムに含まれる車両３００は複数であってもよい。

【0028】

サーバ装置１００は、車両３００を制御する装置である。また、サーバ装置１００は、ユーザ端末２００から受信した位置情報に基づいて、ユーザが、所定の期間内において移動を開始することを推定し（換言すると、移動の予兆を検出し）、当該推定の結果に基づいて、ユーザに対して、車両３００による輸送サービスの提供を打診する。ユーザがこれを受諾すると、サーバ装置１００は、車両３００をユーザの元へ派遣させる。これにより、移動の足を必要とするユーザに対して、自律的に交通手段を提供することができる。

【0029】

ここで、移動の予兆を示したユーザが複数いる場合、そのうちの何名に輸送サービスの提供を打診するかが問題となる。例えば、打診を辞退するユーザが一定数いる場合、利用可能な車両の台数よりも多くのユーザに対して打診を行ったほうが、車両の稼働率が向上する。一方で、打診を行うユーザの数を増やしすぎると、オーバーブッキングの問題が発生しうる。すなわち、ユーザが輸送サービスの提供を希望しているのに、車両を割り当てることができないといった事態が起こりうる。
これに対処するため、本実施形態では、サーバ装置１００が、輸送サービスの提供を打診するユーザの上限人数を、状況に応じてリアルタイムで決定する。

【0030】

なお、本実施形態では、サーバ装置１００が、所定の商業施設内にいるユーザが帰宅する予兆を検出し、予測される出発時刻（帰宅を開始する時刻）に合わせて、当該ユーザに対して車両３００を派遣する形態を例示する。

【0031】

図２は、本実施形態に係る配車システムの構成要素をより詳細に示した図である。
まず、ユーザ端末２００について説明する。
ユーザ端末２００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、またはウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ端末２００は、制御部２０１、記憶部２０２、通信部２０３、入出力部２０４、および近距離通信部２０５を含んで構成される。

【0032】

制御部２０１は、ユーザ端末２００が行う制御を司る演算装置である。制御部２０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができ
る。
制御部２０１は、位置データ取得部２０１１と、位置データ送信部２０１２の２つの機能モジュールを有して構成される。これらの機能モジュールは、後述する記憶部２０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

【0033】

位置データ取得部２０１１は、自端末の位置に関するデータ（以下、位置データ）を取得する。位置データは、例えば、緯度と経度で表されてもよいが、本実施形態では、対象の商業施設内における位置を表すデータであるものとする。
例えば、複数のビーコンが商業施設内に設置されている場合、位置データ取得部２０１１は、後述する近距離通信部２０５を介してビーコンと通信し、その識別子を取得することができる。この場合、ビーコンの識別子が、自端末の位置に関するデータとなる。これ
により、ユーザが、施設内のどの場所（例えば、どの店舗）にいるのかをシステムが把握することができる。

【0034】

位置データ送信部２０１２は、位置データ取得部２０１１によって取得された位置データを、サーバ装置１００に周期的に送信する。

【0035】

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

【0036】

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

【0037】

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

【0038】

近距離通信部２０５は、施設内に設置されたビーコンとの間で近距離無線通信を行うためのインタフェースである。近距離通信部２０５は、所定の無線通信規格を用いて、近距離（数メートル程度）における通信を行う。
本実施形態では、近距離通信部２０５は、Ｂｌｕｅｔｏｏｔｈ（登録商標）ＬｏｗＥｎｅｒｇｙ規格（以下、ＢＬＥ）によるデータ通信を行う。なお、本実施形態ではＢＬＥを例示するが、他の無線通信規格も利用可能である。例えば、ＮＦＣ（Near Field Communication）、ＵＷＢ（Ultra Wideband）、Ｗｉ－Ｆｉ（登録商標）などを利用することもできる。

【0039】

次に、サーバ装置１００について説明する。
サーバ装置１００は、ユーザが取りうる典型的な行動を表すモデル（以下、行動モデル）を記憶し、ユーザ端末２００から受信した位置データに基づいて、当該ユーザ端末２００を所持するユーザに、帰宅の予兆が見られるか否かを判定する。
さらに、サーバ装置１００は、帰宅の予兆を示したユーザを対象として、車両３００による輸送サービスの提供是非に関する問い合わせを行う。この際、サーバ装置１００は、車両の運用効率を最大化するため、問い合わせを行うユーザの最大人数を適宜決定する。
具体的な方法については後述する。

【0040】

サーバ装置１００は、汎用のコンピュータにより構成することができる。すなわち、サーバ装置１００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコ
ンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを主記憶装置の作業領域にロードして実行し、プログラムの実行を通じて各構成部等が制御されることによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

【0041】

制御部１０１は、サーバ装置１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部１０１は、推定部１０１１、キューサイズ決定部１０１２、提案部１０１３、および運行指令部１０１４の４つの機能モジュールを有して構成される。各機能モジュールは、記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

【0042】

推定部１０１１は、ユーザ端末２００から位置データを取得し、取得した位置データに基づいて、ユーザに帰宅の予兆が見られることを判定する。当該判定は、後述する記憶部１０２に記憶された位置データ、および、各ユーザに対応する行動モデル（いずれも後述）を利用して行うことができる。推定部１０１１は、帰宅の予兆が検出されたユーザがいる場合に、当該ユーザの移動に関する情報（以下、移動データ）を、キュー（以下、問い合わせキュー）に格納する。装置は、問い合わせキューに格納された移動データに基づいて、輸送サービスの提供の是非をユーザに問い合わせる（打診する）。

【0043】

キューサイズ決定部１０１２は、輸送サービスの提供打診をユーザが受諾する確率（以下、受諾確率）に基づいて、問い合わせキューのサイズを調整する。問い合わせキューのサイズは、輸送サービスの提供の是非を同時に問い合わせるユーザの人数を表す。すなわち、受諾確率が低い場合、キューサイズ決定部１０１２は、問い合わせキューのサイズを大きくし、より多くのユーザに対して問い合わせを行えるようにする。反対に、受諾確率が高い場合、キューサイズ決定部１０１２は、問い合わせキューのサイズを小さくし、問い合わせを行うユーザの人数を絞る。

【0044】

提案部１０１３は、問い合わせキューに格納されている移動データに基づいて、車両３００による輸送サービスの提供をユーザに打診する。ユーザが、車両３００に乗車する旨の意思を示した場合、当該ユーザに対応する移動データが、後述する運行指令部１０１４へ送信される。

【0045】

運行指令部１０１４は、受信した移動データに基づいて、ユーザを輸送するための指令（運行指令）を生成し、対象の車両へ送信する。運行指令には、走行経路、ユーザを乗降させる地点、乗降させるユーザの識別子などに関する情報が含まれる。
さらに、運行指令部１０１４は、システムに含まれる車両３００を管理する機能を有する。運行指令部１０１４は、システムに含まれる複数の車両３００と周期的に通信を行うことで、各車両の現在位置や状態、現在実行中であるタスク、占有時間などを取得し、これらのデータを車両データとして記憶する。記憶された車両データを参照することで、特定のユーザに対して派遣する車両を決定することができる。

【0046】

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

【0047】

記憶部１０２は、ユーザ端末２００から周期的に収集した位置データを、端末位置デー
タ１０２Ａとして記憶する。図３Ａは、端末位置データの例である。図示したように、端末位置データは、ユーザの識別子（ユーザＩＤ）、位置情報（店舗ＩＤ）、日付、曜日、および、時刻といった情報を含む。

【0048】

また、記憶部１０２は、ユーザごとの行動モデル（行動モデル１０２Ｂ）を記憶する。本実施形態における行動モデルとは、ユーザが帰宅を開始するまでに取りうる行動を、位置の遷移によって定義したモデルである。
例えば、図３Ｂに示したように、商業施設内における、来店から退店までの典型的な行動は、ユーザごとに異なりうる。例えば、パターンＡに示したような行動パターンを取るユーザがおり、当該ユーザが食料品売場に移動した場合、帰宅が近いことが推定できる。また、パターンＢに示したような行動パターンを取るユーザがおり、当該ユーザが日用品売場に移動した場合、帰宅が近いことが推定できる。本実施形態では、行動モデルは、このように、ユーザが帰宅を開始するタイミングを推定するための情報を記憶する。ユーザに対応する行動モデルは、記憶部１０２に事前に記憶される。行動モデル１０２Ｂは、例えば、ユーザが所持しているユーザ端末２００から取得した位置データの履歴に基づいて生成することができる。

【0049】

また、記憶部１０２は、輸送サービスの提供を打診されたユーザが、これを受諾する確率（受諾確率）を算出するためのデータ（確率データ１０２Ｃ）を記憶する。
確率データ１０２Ｃは、例えば、ユーザが置かれている環境（以下、移動環境）ごとに受諾確率を記述したテーブルとすることができる。図３Ｃは、確率データ１０２Ｃの例である。本例では、施設ＩＤ（対象の商業施設の識別子）、天候、時間帯ごとに、受諾確率が関連付けられている。本例の場合、対象の商業施設、天候、時間帯をキーとして、受諾確率を得ることができる。
なお、本例では、移動環境を示す要素として、場所、天候、および時間帯を例示したが、他の要素を用いてもよい。
また、確率データ１０２Ｃは、ユーザの移動環境に関するデータを入力、受諾確率を出力とする機械学習モデル等であってもよい。
受諾確率の利用方法については後述する。

【0050】

また、記憶部１０２は、複数の車両３００を管理するためのデータ（車両データ１０２Ｄ）を記憶する。図３Ｄは、車両データの例である。車両データは、システムが管理する車両３００の識別子と、その位置情報、運行状態、または、占有時間帯などが記述されたデータである。なお、車両データは、これ以外の情報を含んでもよい。例えば、車両３００の用途・種別、待機地点（車庫や営業所）に関する情報、車体サイズ、積載量（定員）、満充電時における走行可能距離、現時点における走行可能距離、経由地、走行経路、ないし、目的地等などに関する情報を含んでもよい。
車両データ１０２Ｄは、車両３００から送信された情報（以下、車両情報）に基づいて周期的に更新される。

【0051】

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

【0052】

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

【0053】

次に、制御部１０１が行う処理について、モジュール間で送受信されるデータを示した図である図４を参照しながら説明する。

【0054】

推定部１０１１は、複数のユーザ端末２００から位置データを受信し、受信した位置データを、端末位置データ１０２Ａとして記憶部１０２に蓄積する。また、推定部１０１１は、蓄積された位置データと、記憶部１０２に記憶された行動モデルを比較することで、ユーザに帰宅の予兆が見られることを判定する。例えば、位置の変化が、行動モデルに規定されたパターンと一致した場合、近い将来においてユーザが帰宅を開始すると推定することができる。

【0055】

推定部１０１１は、近い将来においてユーザが帰宅を開始すると判定した場合に、移動データを生成する。移動データは、車両３００がピックアップするユーザの識別子、当該ユーザをピックアップする地点および時刻、当該ユーザが降車する地点などを含むデータである。
例えば、推定部１０１１が、３０分後にユーザが帰宅を開始すると判定した場合に、商業施設のエントランスにおいて当該ユーザを３０分後にピックアップする旨の移動データを生成する。生成された移動データは、図５に示したような問い合わせキューに追加される。
なお、推定部１０１１が、ユーザが推定通りに移動（帰宅）を開始する確度（以下、移動確度）を判定可能な場合、当該移動確度が所定値を超えた場合に、移動データを生成するようにしてもよい。

【0056】

一方、キューサイズ決定部１０１２は、推定部１０１１の処理とは独立して、問い合わせキューのサイズをリアルタイムで変更する。問い合わせキューのサイズは、前述した受諾確率に基づいて決定することができる。例えば、現在利用できる車両が１００台あり、受諾確率が５０％であった場合、最大２００人のユーザに対して配車を打診することができる。
受諾確率は、前述した移動環境に大きく依存する。例えば、天候が悪い場合、天候が良い場合と比較して受諾確率が上昇する。

【0057】

キューサイズ決定部１０１２は、ユーザの移動環境に関するデータ（環境データ）と、記憶された確率データに基づいて、受諾確率ｐを算出する。なお、環境データは、装置の外部から取得することができる。
確率データがテーブルまたはデータベースである場合、キューサイズ決定部１０１２は、環境データに含まれる複数の項目をキーとして、受諾確率を検索してもよい。
また、確率データが機械学習モデルである場合、キューサイズ決定部１０１２は、環境データに含まれる複数の項目を特徴量に変換して当該モデルに入力し、出力された受諾確率を取得してもよい。

【0058】

さらに、キューサイズ決定部１０１２は、車両データ１０２Ｄを参照し、現在利用可能な車両３００の台数ｖを取得する。そして、受諾確率の逆数に、車両３００の台数を乗じた値を求め、問い合わせを送信可能な最大人数ｎとする。ｎは、問い合わせキューのサイズとなる。
ｎ＝ｖ×（１／ｐ）・・・式（１）
例えば、利用可能な車両３００の台数が１００台、移動環境に基づいて算出された受諾確率が６７％であった場合、ｎ＝１５０となる。この場合、１５０人ぶんの移動データが問い合わせキューに格納可能（換言すると、同時に１５０人に問い合わせが送信可能）となる。

【0059】

提案部１０１３は、所定の周期ごとに、問い合わせキューに格納された移動データを取得し、対応するユーザ端末２００に対して問い合わせを送信する。ユーザからの応答があった場合や、問い合わせがタイムアウトした場合、当該ユーザに対応する移動データは、
問い合わせキューから削除される。打診を受諾したユーザがいた場合、対応する移動データが、運行指令部１０１４へ送信される。

【0060】

運行指令部１０１４は、取得した移動データに基づいて、ユーザに割り当てる車両３００を決定する。ユーザに割り当てる車両は、車両データ１０２Ｄを参照することで決定することができる。そして、決定した車両に対して、運行指令を送信する。
運行指令には、ユーザを特定するための情報、ユーザをピックアップする時刻（配車時刻）、ユーザを乗車させる地点（配車地点）、ユーザを降車させる地点（例えば、ユーザの自宅）などが含まれる。
運行指令を受信した車両３００は、当該運行指令に従って走行し、ユーザを輸送する。

【0061】

さらに運行指令部１０１４は、複数の車両３００を管理する処理を行う。すなわち、複数の車両３００と周期的に通信して、各車両の状態に関する情報（車両情報）を収集し、車両データ１０２Ｄを更新する処理である。

【0062】

図６～図８は、サーバ装置１００が行う処理を示したフローチャートである。
なお、運行指令部１０１４が車両情報を収集し、車両データ１０２Ｄを更新する処理は、図示した処理とは独立して並列に実行されるものとする。

【0063】

図６に示したフローチャートは、推定部１０１１が、ユーザ端末２００から位置データを受信し、蓄積する処理を表したものである。
まず、ステップＳ１１で、ユーザ端末２００から位置データを受信し、端末位置データ１０２Ａとして記憶部１０２に蓄積する。

【0064】

次に、ステップＳ１２で、蓄積された位置データの集合と、ユーザに対応する行動モデルとを照合し、帰宅の予兆を示しているユーザがいるか否かを判定する。例えば、位置の推移と、行動モデルに定義された行動パターンとの一致度が閾値を上回っている場合、帰宅の予兆が見られると判定することができる。パターンが合致した場合（ステップＳ１３－Ｙｅｓ）、処理はステップＳ１４へ遷移する。パターンが合致しない場合（ステップＳ１３－Ｎｏ）、処理はステップＳ１１へ戻る。

【0065】

ステップＳ１４では、推定部１０１１が、該当するユーザに対応する移動データを生成し、当該移動データを問い合わせキューに追加する。

【0066】

ここで、問い合わせキューに空きが無く、移動データを追加できない場合、以下に示した方法のいずれかによってこれを処理してもよい。
（方法Ａ）対象の移動データをキューに追加しない
（方法Ｂ）キューに追加された時刻が最も古い他の移動データをキューから削除する
（方法Ｃ）移動データに対する優先度を決定し、より低い優先度を持つ他の移動データをキューから削除する

【0067】

移動データに対する優先度は、例えば、以下のような基準によって決定することができる。
（１）過去における、ユーザによる輸送サービスの利用回数または利用頻度を示す値に基づいて優先度を決定する
例えば、輸送サービスの利用履歴を示す情報を記憶部１０２に記憶させ、過去の所定の期間における利用回数または利用頻度を示す値を優先度とする。
（２）輸送サービスの提供打診に対してユーザが応答した回数または頻度を示す値
例えば、過去の所定の期間において、輸送サービスの提供を打診されたユーザがこれに応答した回数、打診を受諾した回数、応答までのラウンドトリップ時間などを示す情報を
記憶部１０２に記憶させ、これらを示す値を優先度とする。
（３）ユーザの移動確度を示す値
例えば、推定部１０１１が、ユーザに対応する移動確度を判定可能な場合、当該移動確度を示す値を優先度とする。
優先度が高くなると、問い合わせキューに格納される確率が上がるため、輸送サービスの提供を打診する対象のユーザとして選ばれやすくなる。
なお、優先度として、これら以外の値を用いてもよい。

【0068】

さらに、ユーザの状態に応じて、優先度を補正してもよい。例えば、ユーザが運搬している荷物が多いほど優先度を高くし、あるいは、ユーザと一緒に行動している人（家族など）の数が多いほど優先度を高くしてもよい。ユーザが運搬している荷物の量は、ユーザをセンシングした結果に基づいて判定してもよいし、当該ユーザに関連付いた決済情報などに基づいて判定してもよい。また、ユーザと一緒に行動している人の数は、往路における交通手段を介して取得してもよい。例えば、往路においてユーザが輸送サービスを利用した場合、その際の乗車人数などに基づいて、当該ユーザと一緒に行動している人の数を判定することができる。

【0069】

図７に示したフローチャートは、キューサイズ決定部１０１２が、問い合わせキューのサイズを調整する処理を表したものである。前述したように、図７に示した処理は、図６に示した処理とは独立して、所定の周期で（例えば、１５分おきに）実行される。

【0070】

まず、ステップＳ２１で、記憶部１０２に記憶された確率データ１０２Ｃおよび車両データ１０２Ｄを取得する。
次に、ステップＳ２２で、環境データを取得し、当該環境データと確率データ１０２Ｃに基づいて受諾確率を決定する。例えば、図３Ｃの例の場合、対象の商業施設、天候、および時間帯に基づいて、受諾確率を得ることができる。確率データ１０２Ｃが機械学習モデルである場合、移動条件を特徴量に変換したものを入力とし、出力された受諾確率を取得する。

【0071】

次に、ステップＳ２３で、決定した受諾確率と、利用可能な車両の台数に基づいて、式（１）によって、問い合わせキューのサイズを変更する。利用可能な車両の台数は、車両データ１０２Ｄを参照することで取得できる。
ここで、問い合わせキューのサイズを変更することで、データ量が超過する場合（ステップＳ２４－Ｙｅｓ）、処理はステップＳ２５へ遷移し、削除対象の移動データを決定する。削除対象となったユーザについては、輸送サービスの提供は打診されない。削除対象は、例えば、前述した（方法Ａ）～（方法Ｃ）のいずれかによって決定することができる。問い合わせキューのサイズを変更してもデータ量が超過しない場合（ステップＳ２４－Ｎｏ）、処理は終了する。

【0072】

図８は、問い合わせキューに含まれるユーザに対して、提案部１０１３が、輸送サービスの提供を打診する処理のフローチャートである。図８に示した処理は、所定の周期で実行される。

【0073】

まず、ステップＳ３１で、問い合わせキューに含まれる全ての移動データを処理し、対応するユーザが所持するユーザ端末２００に対して、輸送サービスの提供を打診するメッセージを送信する。
次に、ステップＳ３２で、一定時間（例えば、５分）以内に応答が無かったユーザに対応する移動データをキューから削除する。

【0074】

次に、ステップＳ３３で、いずれかのユーザから応答があったか否かを判定する。応答
があった場合、ステップＳ３４で、当該ユーザに対する配車方針（配車を行うか、行わないか）を決定する。応答が無かった場合、処理はステップＳ３５へ遷移する。

【0075】

ステップＳ３５では、問い合わせを行った全てのユーザに対して配車方針が決定されたか否かを判定する。本ステップで否定判定となった場合、処理はステップＳ３２へ戻る。
問い合わせを行った全てのユーザに対して配車方針が決定された場合、処理はステップＳ３６へ遷移し、配車を希望するユーザに対応する移動データを、運行指令部１０１４に引き渡す。

【0076】

運行指令部１０１４は、取得した移動データに基づいて、車両３００の割り当てを行い、各車両に対する運行指令を生成する。運行指令は、対応する車両３００へそれぞれ送信され、運行が開始される。

【0077】

以上説明したように、第一の実施形態に係るサーバ装置１００は、ユーザ端末２００から受信した情報に基づいて、ユーザが移動（帰宅）を開始する予兆を検出し、自律的に、移動サービスの提供を打診する。また、打診を行うユーザの数を、受諾確率に基づいて動的に調整する。これにより、車両の稼働率を最大化することが可能になる。

【0078】

（第二の実施形態）
第一の実施形態では、移動の予兆を示した全てのユーザに対応する移動データを問い合わせキューに追加したが、所定の条件を満たすユーザに対応する移動データのみを問い合わせキューに追加するようにしてもよい。所定の条件として、例えば、輸送サービスの利用実績、同行者の人数、または、ユーザが運んでいる荷物の量などを利用することができる。

【0079】

また、第一の実施形態の（方法Ｃ）で示したように、ユーザごとに優先度を決定し、優先度が閾値を満たすユーザに対応する移動データのみを問い合わせキューに追加するようにしてもよい。優先度は、例えば、輸送サービスの利用実績に基づいて決定してもよいし、同行者の人数や、ユーザが運んでいる荷物の量、または、移動確度に基づいて決定してもよい。

【0080】

さらに、優先度の閾値は、車両の運行状況等に基づいて動的に変更してもよい。
例えば、移動の予兆を示すユーザが少なく、車両の稼働率が上がらない場合、優先度の閾値を下げることで、より多くのユーザをキューに取り込むことができる。反対に、移動の予兆を示すユーザが多く、車両の稼働率が１００％に近い状態が続いている場合、優先度の閾値を上げることで、輸送サービスの利用がより有益であるユーザに対して優先的に車両を割り当てることができる。

【0081】

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

【0082】

また、実施形態の説明では、商業施設に滞在しているユーザが帰宅する予兆を検出したが、ユーザが移動を開始することを推定できれば、ユーザの滞在先は商業施設に限定されず、また、対象の行動も帰宅に限定されない。例えば、自宅にいるユーザの行動に基づいて、当該ユーザが外出する予兆を検出してもよい。

【0083】

さらに、実施形態の説明では、サーバ装置１００が、所定の商業施設を管轄する例を挙
げたが、サーバ装置１００が管轄するのは施設単位である必要はない。例えば、サーバ装置１００が、所定のエリアに派遣可能な車両を管理し、当該エリア内にいるユーザについて移動の予兆を判定してもよい。この場合、エリア内に位置するユーザ端末２００から発信された情報に基づいて、対応するユーザが近い将来において移動を開始する（例えば、帰宅を開始する）ことを判定してもよい。
所定のエリアは、メッシュによって分割されたものであってもよいし、行政区画などによって定義されたものであってもよい。

【0084】

また、サーバ装置１００が管轄するエリアは複数あってもよい。この場合、利用可能な車両の台数と、打診を行うユーザの上限人数とを、エリアごとに取得し、前述した方法で配車の打診を行ってもよい。なお、確率データ１０２Ｃをエリアごとに定義してもよい。

【0085】

さらに、実施形態の説明では、位置情報に基づいて、対応するユーザが移動を開始することを推定したが、これ以外のデータを利用してもよい。例えば、ユーザの所持するユーザ端末２００から送信された、位置情報以外の情報（例えば、電子決済に関する情報、メッセージ、電子メールなど）、または、当該ユーザをセンシングして得られたデータに基づいて、近い将来において当該ユーザが移動を開始することを判定してもよい。

【0086】

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

【0087】

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

【符号の説明】

【0088】

１００・・・サーバ装置
１０１，２０１・・・制御部
１０２，２０２・・・記憶部
１０３，２０３・・・通信部
２００・・・ユーザ端末
２０４・・・入出力部
２０５・・・近距離通信部
３００・・・車両

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図3D】

【図4】

【図5】

【図6】

【図7】

【図8】