特許 7488215 予約受付システムおよび予約受付方法

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

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

(11)【特許番号】

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

(45)【発行日】2024-05-21

(54)【発明の名称】予約受付システムおよび予約受付方法

(51)【国際特許分類】

   G08G 1/00 20060101AFI20240514BHJP

   G06Q 10/02 20120101ALI20240514BHJP

   G06Q 50/40 20240101ALI20240514BHJP

【ＦＩ】

G08G1/00 D

G06Q10/02

G06Q50/40

【請求項の数】 6

(21)【出願番号】P 2021039515

(22)【出願日】2021-03-11

(65)【公開番号】P2022139229

(43)【公開日】2022-09-26

【審査請求日】2023-03-03

(73)【特許権者】

【識別番号】000003207

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

(73)【特許権者】

【識別番号】000003609

【氏名又は名称】株式会社豊田中央研究所

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(74)【代理人】

【識別番号】100109047

【弁理士】

【氏名又は名称】村田 雄祐

(74)【代理人】

【識別番号】100109081

【弁理士】

【氏名又は名称】三木 友由

(72)【発明者】

【氏名】柏倉 俊樹

(72)【発明者】

【氏名】志賀 孝広

(72)【発明者】

【氏名】西 智樹

(72)【発明者】

【氏名】大滝 啓介

(72)【発明者】

【氏名】大社 綾乃

【審査官】武内 俊之

(56)【参考文献】

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

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

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

Ｇ０８Ｇ １／００

Ｇ０６Ｑ １０／０２

Ｇ０６Ｑ ５０／４０

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

【請求項1】

移動体の利用を予約するユーザから、希望日時、出発地および目的地を含むリクエスト情報を取得する取得部と、
取得したリクエスト情報に対して予約が成立したか否かを示す予約結果を導出する導出処理部と、
導出した予約結果をユーザに通知する通知制御部と、を備え、
前記導出処理部は、取得されたリクエスト情報にもとづいて、成立、保留または不成立の予約結果を導出する導出部を有し、
前記導出部は、取得されたリクエスト情報に対して複数回に亘って予約結果を導出することが可能であり、初回はリクエスト情報に対して少なくとも成立または保留を示す予約結果を導出し、保留したリクエスト情報に対して所定期限までに成立または不成立の予約結果を導出し、
前記導出処理部は、予約結果を導出するための導出関数を保持するモデル保持部を有し、
前記モデル保持部は、過去のリクエスト情報をもとに学習して生成された前記導出関数であって、取得されたリクエスト情報をもとに成立可能性を示すスコアを導出する前記導出関数を保持し、
前記導出部は、取得されたリクエスト情報の成立可能性を示すスコアを前記導出関数によって導出し、導出したスコアが所定の閾値以上であれば予約が成立すると導出し、
所定の閾値は、リクエスト情報を取得した時刻から希望日時までの時間に応じて設定されることを特徴とする予約受付システム。

【請求項2】

前記導出部は、リクエスト情報に対して予約の成立可能性を示す情報を導出し、
前記通知制御部は、予約結果が保留である場合には、成立可能性を示す情報をユーザに通知することを特徴とする請求項１に記載の予約受付システム。

【請求項3】

前記取得部によって取得されるリクエスト情報には、期限情報が含まれ、
前記導出部は、期限情報に示す日にちまでに成立または不成立の予約結果を導出することを特徴とする請求項１または２に記載の予約受付システム。

【請求項4】

前記導出部は、所定期限前に所定の再評価条件が満たされた場合、保留中のリクエスト情報に対して予約結果を再度導出することを特徴とする請求項１から３のいずれかに記載の予約受付システム。

【請求項5】

前記導出部は、将来リクエストが発生すると予測されるリクエストの予測結果を導出し、導出されたリクエストの予測結果と前記取得部によって取得したリクエスト情報とにもとづいて、成立または不成立の予約結果を導出することを特徴とする請求項１から４のいずれかに記載の予約受付システム。

【請求項6】

各ステップを予約受付システムで実行させる予約受付方法であって、
取得部が、移動体の利用を予約するユーザから要求される、希望日時、出発地および目的地を含むリクエスト情報を取得するステップと、
導出処理部が、取得したリクエスト情報に対して予約が成立したかを示す予約結果を、取得したリクエスト情報と導出関数とをもとに導出するステップと、
通知制御部が、導出した予約結果をユーザに通知するステップと、を含み、
前記導出するステップでは前記導出処理部が、取得したリクエスト情報に対して複数回に亘って実行可能であり、初回はリクエスト情報に対して少なくとも成立または保留を示す予約結果を導出し、保留したリクエスト情報に対して所定期限までに成立または不成立の予約結果を導出し、
前記導出処理部は、過去のリクエスト情報をもとに学習して生成された前記導出関数であって、取得されたリクエスト情報をもとに成立可能性を示すスコアを導出する前記導出関数を保持し、
前記導出処理部は、取得されたリクエスト情報の成立可能性を示すスコアを前記導出関数によって導出し、導出したスコアが所定の閾値以上であれば予約が成立すると導出し、
所定の閾値は、リクエスト情報を取得した時刻から希望日時までの時間に応じて設定されることを特徴とする予約受付方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザから移動体の運行の予約を受け付ける技術に関する。

【背景技術】

【0002】

特許文献１は、利用者の要求に対応して車両を運行するデマンド交通を運用するデマンド交通運用システムが開示されている。このデマンド交通運用システムは、希望出発時刻および希望到着時刻と、出発地および目的地とを含む乗客の旅程要求を受信し、規定時刻までに集約した旅程要求をもとにデマンド交通車両の配車計画を作成する。

【先行技術文献】

【特許文献】

【0003】

【文献】国際公開第２０１９／１０６７４５号

【発明の概要】

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

【0004】

特許文献１に開示される技術では、複数のユーザの旅程要求を規定時刻まで受け付けてから配車を計画するため、ユーザが旅程要求をしたタイミングでは規定時刻に達しておらず旅程要求の結果を得ることができない。一方でユーザそれぞれが旅程要求をしたタイミングで配車を計画した場合、後から受け付けた旅程要求が却下されやすくなり、旅程要求の成立数が大きく減るおそれがある。

【0005】

本発明の目的は、ユーザの使い易さを向上しつつ、リクエストの成立数が減ることを抑える技術を提供することにある。

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

【0006】

上記課題を解決するために、本発明のある態様の予約受付システムは、移動体の利用を予約するユーザから、希望日時、出発地および目的地を含むリクエスト情報を取得する取得部と、取得したリクエスト情報に対して予約が成立したか否かを示す予約結果を導出する導出処理部と、導出した予約結果をユーザに通知する通知制御部と、を備える。導出処理部は、取得されたリクエスト情報にもとづいて、成立、保留または不成立の予約結果を導出する導出部を有する。導出部は、取得されたリクエスト情報に対して複数回に亘って予約結果を導出することが可能であり、初回はリクエスト情報に対して少なくとも成立または保留を示す予約結果を導出し、保留したリクエスト情報に対して所定期限までに成立または不成立の予約結果を導出する。導出処理部は、予約結果を導出するための導出関数を保持するモデル保持部を有する。モデル保持部は、過去のリクエスト情報をもとに学習して生成された導出関数であって、取得されたリクエスト情報をもとに成立可能性を示すスコアを導出する導出関数を保持する。導出部は、取得されたリクエスト情報の成立可能性を示すスコアを導出関数によって導出し、導出したスコアが所定の閾値以上であれば予約が成立すると導出する。所定の閾値は、リクエスト情報を取得した時刻から希望日時までの時間に応じて設定される。

【0007】

本発明の別の態様は、各ステップを予約受付システムで実行させる予約受付方法である。この方法は、 取得部が、移動体の利用を予約するユーザから要求される、希望日時、出発地および目的地を含むリクエスト情報を取得するステップと、導出処理部が、取得したリクエスト情報に対して予約が成立したかを示す予約結果を、取得したリクエスト情報と導出関数とをもとに導出するステップと、通知制御部が、導出した予約結果をユーザに通知するステップと、を含む。導出するステップでは導出処理部が、取得したリクエスト情報に対して複数回に亘って実行可能であり、初回はリクエスト情報に対して少なくとも成立または保留を示す予約結果を導出し、保留したリクエスト情報に対して所定期限までに成立または不成立の予約結果を導出する。導出処理部は、過去のリクエスト情報をもとに学習して生成された導出関数であって、取得されたリクエスト情報をもとに成立可能性を示すスコアを導出する導出関数を保持する。導出処理部は、取得されたリクエスト情報の成立可能性を示すスコアを導出関数によって導出し、導出したスコアが所定の閾値以上であれば予約が成立すると導出する。所定の閾値は、リクエスト情報を取得した時刻から希望日時までの時間に応じて設定される。

【発明の効果】

【0008】

本発明によれば、ユーザの使い易さを向上しつつ、リクエストの成立数が減ることを抑える技術を提供できる。

【図面の簡単な説明】

【0009】

【図1】実施例の予約受付システムの概要を示す図である。

【図2】実施例の予約受付システムの機能構成を示す図である。

【図3】図３（ａ）は、ユーザ端末装置から送信されるリクエスト情報を示し、図３（ｂ）は、車両管理装置から送信される車両情報を示す図である。

【図4】予約受付装置による予約結果の通知処理のフローチャートである。

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

【0010】

図１は、実施例の予約受付システム１の概要を示す。予約受付システム１は、予約受付装置１０、ユーザ端末装置１２、車両管理装置１４および車両１６を備える。予約受付システム１は、デマンド交通での運行の予約をユーザから受け付ける。デマンド交通では、予約受付装置１０が車両１６の利用を予約するユーザからリクエストを受け付けて、リクエストに応じて車両１６を運行してユーザやユーザの荷物を搬送する。図１に示すバスなどの車両１６には、ユーザ同士が乗り合うことが可能である。なお、図１では、移動体として車両１６を示すが、この態様に限られず、例えば、船舶や飛行機などの移動体であってもよい。

【0011】

ユーザ端末装置１２は、予約受付装置１０と通信可能である。ユーザは、ユーザ端末装置１２を用いて予約受付装置１０に車両１６の運行を要求する。ユーザ端末装置１２は、ユーザ毎に保持される携帯端末装置であってよく、車両１６の運行を要求するためのアプリケーションプログラムを保持している。ユーザ端末装置１２は、アプリケーションプログラムを実行して、予約受付装置１０にリクエスト情報を送信し、予約受付装置１０からリクエストの成立、保留または不成立を示す予約結果を受け取る。

【0012】

ユーザのリクエスト情報は、運行日の前日や運行時間の所定時間前などの所定の受付期限まで受け付けられる。デマンド交通では、ユーザのリクエスト情報に全て応えて運行することが望ましいが、運行可能な車両１６の台数には限りがあるため、ユーザのリクエスト情報の内容によっては、リクエストを不成立にすることがある。ユーザのリクエストは、予約受付装置１０によって、成立させるか不成立にするか最終的に決定される。予約受付装置１０は、成立させたリクエストに対応する運行計画を作成し、車両管理装置１４に送信する。

【0013】

ところで、予約受付装置１０がユーザのリクエストを受け付けたタイミングで、そのリクエストに対して成立可否を判定すると、早い者勝ちのシステムとなって、後から受け付けたリクエストが拒否されやすくなり、リクエストの成立数が大きく減少する。一方で、予約受付装置１０がユーザのリクエストを受付期限まで全て保留して、受付期限に成立可否の判定をすると、ユーザは予約が成立したかすぐには知ることができず、使い勝手がよくない。

【0014】

実施例の予約受付装置１０は、ユーザのリクエストに対する予約結果を、リクエストを受け付けたタイミングと、受付期限に達したタイミングとの少なくとも２段階で回答可能とする。例えば、予約受付装置１０は、ユーザのリクエストを受け取った直後に、そのリクエストに対して成立、保留または不成立を示す予約結果を通知し、保留した場合には所定の受付期限までに成立または不成立を示す予約結果を通知する。このように多段階で予約結果を通知することにより、使い易さを向上し、ユーザエクスペリエンスを向上できる。

【0015】

車両管理装置１４は、車両１６の運行を管理する。車両管理装置１４は、予約受付装置１０と車両１６の車載装置と通信可能であり、車両１６の位置情報を含む車両情報を車両１６から受け取り、予約受付装置１０に送信する。また、車両管理装置１４は、予約受付装置１０から運行計画を受け取り、車両１６が運行計画に沿って走行するように管理する。車両１６は自動運転可能であってもよい。

【0016】

図２は、実施例の予約受付システム１の機能構成を示す。図２において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

【0017】

予約受付装置１０は、通信部２０、取得部２２、導出処理部２４、リクエスト保持部２６および通知制御部２８を備える。通信部２０は、ユーザ端末装置１２および車両管理装置１４と通信可能であり、情報を送受する。

【0018】

取得部２２は、通信部２０を介して、ユーザ端末装置１２からリクエスト情報を取得し、車両管理装置１４から車両情報を取得する。ここで、リクエスト情報および車両情報について図３を参照して説明する。

【0019】

図３（ａ）は、ユーザ端末装置１２から送信されるリクエスト情報を示し、図３（ｂ）は、車両管理装置１４から送信される車両情報を示す。リクエスト情報は、ユーザＩＤ、出発地情報、目的地情報、希望日時情報および期限情報を含む。

【0020】

出発地情報および目的地情報は、予め設定された停留所の位置情報であってよく、緯度または経度で示す位置情報であってよい。つまり、デマンド交通の車両１６は、予め設定された停留所間の移動をするものであってよく、ユーザが希望する任意の位置に移動するものであってよい。希望日時情報は、出発時刻、出発時間帯、到着時刻または到着時間帯のいずれかを指定するものであってよい。

【0021】

期限情報は、ユーザが希望するリクエスト回答期限を示すもので、リクエストが成立または不成立したかを示す予約結果を受け取る期限を示す。ユーザは、自身で設定した期限情報までにリクエストが成立したか示す予約結果を受け取ることが可能である。また、ユーザがリクエスト回答期限を設定しない場合、自動的に標準のリクエスト回答期限に設定される。なお、リクエスト情報には、乗車人数が含まれてよく、１回のリクエストで複数人の乗車を要求できてよい。

【0022】

図３（ｂ）に示すように、車両情報は、車両ＩＤ、位置情報、座席情報および運行予定情報を含む。車両の位置情報は、車両１６の車載装置から車両管理装置１４に送信される。車両１６の座席情報には、乗車可能な座席ＩＤに、その座席ＩＤを予約したユーザＩＤが関連付けて保持される。つまり、座席情報は、座席毎にユーザによって予約された情報を含む。これにより、予約が埋まっていない残席の情報を取得部２２が取得できる。運行予定情報は、予約受付装置１０等によって、すでに決定されている車両１６の運行予定の情報である。

【0023】

図２に戻る。導出処理部２４は、取得したリクエスト情報に対して予約が成立したか否かを示す予約結果を導出する。この「否か」は、保留または不成立を含む。導出処理部２４は、モデル保持部３０および導出部３２を有する。

【0024】

モデル保持部３０は、過去のリクエスト情報をもとに生成された、予約結果を導出するための導出関数Ｆ１を保持する。導出関数Ｆ１は、あるユーザのリクエスト情報を入力すると、そのリクエスト情報の成立可能性を例えば０パーセントから１００パーセントのスコアで出力する。

【0025】

導出関数Ｆ１は、過去のリクエスト情報をもとに生成されるため、あるユーザのリクエスト情報が、過去に成立したリクエスト情報の多くに類似しているほど、成立可能性が高いと出力する。導出関数Ｆ１は、例えば決定木、ランダムフォレスト、ロジスティック回帰、サポートベクターマシン、ｋ近傍法、サポートベクター回帰、ＤＮＮ（Deep Neural Network）、ＬＳＴＭ（Long short-term memory）やニューラルネットワークの手法を用いた学習モデルであって、過去のリクエスト情報を教師データとして機械学習をして生成される。これにより過去のリクエスト情報から学習した経験的な判断が実行できる。また、導出関数Ｆ１は、ルールベースで作成され、あるユーザのリクエスト情報と同じ走行経路で搬送できる他のリクエスト情報が多いほど成立可能性が高いと導出してもよく、あるユーザのリクエスト情報と同じ走行経路で搬送できる他のリクエスト情報が所定数以上である場合に成立すると導出してもよい。また、導出関数Ｆ１は、学習モデルとルールベースとの組み合わせであってよく、例えば、学習モデルに、予約成立回数が少ないユーザが成立しやすくなるルールを組み合わせて生成されてもよい。

【0026】

導出関数Ｆ１の学習において、リクエスト成立数を最大化することを目的としてよいが、リクエスト成立数を最大化することを目的に限定しなくてよい。例えば、ユーザの総乗車距離、利用料金、事業者利益などを最大化することを目的としてよく、それらの組み合わせを目的としてよい。

【0027】

導出関数Ｆ１が、天候、曜日や交通状況によって成立可能性を判断できるように、導出関数Ｆ１の機械学習には、過去の経験として、リクエスト情報だけなく、リクエスト情報に関連付けられた天候情報、曜日情報、交通情報なども入力されてよい。

【0028】

導出関数Ｆ１は、取得部２２によって取得されたリクエスト情報に対して、成立可能性を示すスコアを導出するものであってよく、成立、保留または不成立の３つに分類するものであってよい。また、導出関数は、リクエスト情報に対して、成立、高確率保留、低確率保留または不成立の４つに分類するものであってよい。

【0029】

導出関数Ｆ１には、あるユーザのリクエスト情報を入力するだけでなく、他のユーザのリクエスト情報と、車両情報とを合わせて入力して、予約結果を導出する。車両情報を用いることで、ユーザが乗車可能な残りの席数をもとに予約結果を導出できる。導出関数Ｆ１は、所定期間毎に、蓄積したリクエスト情報およびその予約結果をもとに学習して更新されてよい。

【0030】

導出部３２は、取得されたリクエスト情報と導出関数Ｆ１とにもとづいて予約結果を導出する。導出部３２は、あるユーザのリクエスト情報を導出関数Ｆ１に入力し、導出関数Ｆ１によって導出したスコアが所定の閾値以上である場合に、予約結果が成立すると導出する。

【0031】

所定の閾値は、あるリクエスト情報の希望日時から現在日時までの時間に応じて設定されてよく、例えば、あるリクエスト情報の希望日時から現在日時までの時間が短いほど低くなるように設定されてよい。また、所定の閾値は、あるリクエスト情報の希望日時から現在日時までの時間が、その時間よりも長い場合と比べて、低くなるように設定されてよい。例えば、導出部３２は、希望日時の１週間前には所定の閾値を９５パーセントに設定し、希望日時の２日前には所定の閾値を７０パーセントに設定してよい。つまり、導出部３２は、希望日時の１週間前には成立可能性が９５パーセント以上である場合に、リクエストが成立すると導出し、希望日時の２日前には成立可能性が７０パーセント以上である場合に、リクエストが成立すると導出する。このように、所定の閾値は、希望日時に近づくと低くなるように設定されてよい。これにより、運行時刻に近づくにつれてリクエストが成立しやすくなるように設定できる。なお、所定の閾値は予め設定された固定値であってもよい。

【0032】

また、所定の閾値は、ユーザのプロファイル情報をもとに設定されてよい。例えば、導出部３２は、不成立頻度が高いユーザのリクエスト情報に対して、所定の閾値を基準値より低くして設定してもよい。

【0033】

導出部３２は、取得部２２によって取得されたリクエスト情報に対して複数回に亘って予約結果を導出することが可能である。導出部３２は、リクエスト情報が初回で成立しない場合に保留または不成立の予約結果を導出し、２回目以降は保留されたリクエスト情報に対して所定期限までに成立または不成立の予約結果を導出する。また、導出部３２は、リクエスト情報が初回で成立しない場合に保留の予約結果のみを導出してもよい。つまり、リクエスト情報に対して初回は少なくとも成立または保留を示す予約結果が導出され、所定期限までに成立または不成立の予約結果が導出される。

【0034】

これにより、ユーザは、予約のリクエストをした場合、初回は予約の少なくとも成立または保留を知ることができるため予約結果を早く認識できる。また、過去のリクエスト情報をもとに生成したモデルをもとに予約結果が判断されるため、適切な予約結果を導出することが可能である。一方、予約受付装置１０は、ユーザのリクエスト情報を一時的に保留することで、他のリクエスト情報を待ってから判定でき、相乗りを多くして成立数を増やすことができる。

【0035】

導出部３２は、期限情報に示す日にちまでに成立または不成立の予約結果を導出する。これにより、ユーザが成立または不成立を示す期限を自由に設定して、保留されている状態を変更できる。そのため、早めに結果を知りたいユーザや、受付期限まで待っても乗りたいユーザなどに合わせて、使い勝手の良い利用が可能となる。

【0036】

導出部３２は、リクエストの受付期限に達すると、保留中のリクエスト情報に対して成立および不成立のいずれかを導出し、最終的な予約結果を導出して保留中のリクエスト情報を無くす。導出部３２は、受付期限に達して最終的な予約結果を導出する場合、導出関数Ｆ１に加えてさらなるルールを用いてよい。例えば、保留中のリクエスト情報のうち、出発地および目的地が共通するリクエスト情報を優先的に成立させるルールが、最終的な予約結果を導出する際に追加されてよい。

【0037】

導出部３２は、所定の再評価条件が満たされた場合に、保留中のリクエスト情報に対して導出関数Ｆ１をもとに予約結果を導出してよい。つまり、再評価条件が満たされた場合には、保留中のリクエスト情報が再評価され、成立するか保留されるか判定される。再評価条件は、例えば、他のリクエストが成立したこと、車両管理装置１４が新たな車両の運行を追加したこと、再評価時刻に達したことの少なくともいずれかの条件を含む。他のリクエストが成立した場合、導出部３２は他のリクエスト情報に対応する車両に相乗り可能な保留中のリクエスト情報がないか再評価する。また、新たな車両の運行が追加された場合、導出部３２はその車両に乗車する保留中のリクエスト情報がないか再評価する。また、導出部３２は毎日１３時などの再評価時刻に保留中のリクエスト情報を再評価する。例えば、所定の閾値が運行時刻に近づくほど低くなる場合、再評価時刻に達するたびに、リクエストの成立可能性が高まる。このように、導出部３２は、受付期限に達する前であっても再評価条件を満たせば、保留中のリクエスト情報に対して予約結果を再度導出する。これにより、受付期限前にリクエストが成立する確率を高めることができる。

【0038】

リクエスト保持部２６は、保留中のリクエスト情報および成立したリクエスト情報を保持する。これにより、導出部３２が保留中のリクエスト情報に対して予約結果を再度導出できる。また、導出部３２が、新たに取得されたリクエスト情報が、成立したリクエスト情報に対応する車両に相乗り可能であるか導出できる。

【0039】

通知制御部２８は、導出部３２によって導出した予約結果をユーザに通知することを制御し、通信部２０を介して予約結果をユーザ端末装置１２に送信する。ユーザ端末装置１２は、予約受付装置１０から受け取った予約結果を出力する。また、通知制御部２８は、成立したリクエスト情報を運行計画として車両管理装置１４に送る。車両管理装置１４は、成立したリクエスト情報を運行情報として上書きして、車両情報を更新する。

【0040】

導出部３２は、導出関数Ｆ１によって予約の成立可能性を導出し、通知制御部２８は、予約結果が保留である場合には、成立可能性を示す情報をユーザ端末装置１２に送って、成立可能性を示す情報をユーザ端末装置１２からユーザに通知させる。ユーザ端末装置１２によってユーザに通知される成立可能性を示す情報は、パーセント表示であってよく、段階表示であってもよい。例えば、ユーザ端末装置１２は、成立可能性を「高」、「中」、「低」の３段階で表示し、３段階のそれぞれに対応する文字、色、音、振動および／または絵柄で表示する。これにより、ユーザは保留時の成立可能性を知ることができる。

【0041】

通知制御部２８は、ユーザのリクエスト情報が保留された場合に、成立可能性が高まる時間帯にずらすことを通知してよい。成立可能性が高まる時間帯は、過去のリクエスト情報をもとに生成された導出関数Ｆ１をもとに導出部３２が導出する。

【0042】

モデル保持部３０は、導出関数Ｆ１とは別の導出関数Ｆ２を保持してよく、導出部３２は、導出関数Ｆ２を用いて予約結果を導出してよい。別の導出関数Ｆ２は、過去のリクエスト情報をもとに、将来リクエストが発生すると予測されるリクエストの予測結果を導出する。リクエストの予測結果には、日時、目的地、出発地を定めたリクエストの予測受付数が定められる。例えば、導出関数Ｆ２は、過去のリクエスト成立数および不成立数、過去のリクエストの日時や環境情報などをもとに学習して生成される。環境情報には、リクエスト希望日時の天候、目的地および出発地周辺での大規模イベントの有無などが含まれる。これによって、リクエストの需要を予測でき、将来的にリクエストが集中する時間帯および経路を導出できる。

【0043】

導出部３２は、導出関数Ｆ２によって導出されたリクエストの予測結果と、実際に取得したリクエスト情報とにもとづいて、成立または不成立の予約結果を導出する。例えば、ユーザが早めにリクエストを申し込んでも、導出部３２は、そのリクエストの時間帯に別の経路のリクエストが集中すると予測した場合には、不成立と判断する可能性が高くなる。なお、導出部３２は、リクエスト成立数を最大化することを目的として予約結果を導出してよいが、それ以外の目的、例えば総走行距離の最大化などの目的で予約結果を導出してもよい。

【0044】

また、導出部３２は、導出関数Ｆ２によって導出されたリクエストの予測結果と実際に取得したリクエスト情報とにもとづいて成立または不成立の予約結果を導出する処理を、導出関数Ｆ２のパラメータを変更して複数回繰り返して予約成立可能性を算出し、予約成立可能性が所定値以上である場合にリクエストが成立すると導出してよい。例えば、導出部３２は、導出関数Ｆ２によって導出されたリクエストの予測結果と、実際に取得したリクエスト情報とにもとづいて、成立または不成立の予約結果を導出する処理をパラメータを変えつつ１０回繰り返して、１０回のうち８回以上成立すれば、リクエストが成立すると導出する。また、導出部３２は、導出した予約成立可能性の数値によっては、リクエストを保留すると判断してよい。導出部３２は、導出関数Ｆ１と導出関数Ｆ２を用いてリクエストの予約結果を導出してもよい。例えば、導出部３２は、導出関数Ｆ２によって導出されたリクエストの予想結果を、導出関数Ｆ１への入力データの１つに用いてよい。

【0045】

図４は、予約受付装置１０による予約結果の通知処理のフローチャートである。取得部２２は、通信部２０を介して、ユーザ端末装置１２からリクエスト情報を取得し（Ｓ１０）、車両管理装置１４から車両情報を取得する（Ｓ１２）。

【0046】

導出部３２は、取得部２２によって取得されたリクエスト情報および車両情報を導出関数Ｆ１に入力してスコアを導出し、リクエスト情報を評価する（Ｓ１４）。導出関数Ｆ１によって導出されたリクエスト情報の初回のスコアが所定の閾値以上の高スコアである場合（Ｓ１６のＹ）、導出部３２は、そのリクエストが成立していると判定し、通知制御部２８は、リクエスト情報を送信したユーザ端末装置１２にリクエストが成立したことを示す情報を通知する（Ｓ１８）。これにより、受付期限前にリクエスト成立を通知できる。

【0047】

導出関数Ｆ１によって導出されたリクエスト情報の初回のスコアが所定の閾値以上の高スコアでない場合（Ｓ１６のＮ）、導出部３２は、そのリクエスト情報が保留であると判定し、通知制御部２８は、リクエスト情報を送信したユーザ端末装置１２にリクエストが保留されたことを示す情報を通知する（Ｓ２０）。導出部３２は、再評価条件が満たされるか判定する（Ｓ２２）。

【0048】

再評価条件が満たされた場合（Ｓ２２のＹ）、導出部３２は、保留中のリクエスト情報に対して導出関数Ｆ１をもとに予約結果を導出し、再評価する（Ｓ２４）。再評価された保留中のリクエスト情報が所定の閾値以上の高スコアである場合（Ｓ２６のＹ）、導出部３２は、そのリクエストが成立していると判定し、通知制御部２８は、リクエスト情報を送信したユーザ端末装置１２にリクエストが成立したことを示す情報を通知する（Ｓ２８）。これにより、受付期限前にリクエスト成立を通知できる。なお、Ｓ２６でスコアを判定する所定の閾値は、Ｓ１６でスコアを判定する所定の閾値よりも低くてよい。再評価された保留中のリクエスト情報が所定の閾値以上の高スコアでない場合（Ｓ２６のＮ）、保留中のリクエスト情報は受付期限に達するまで再評価条件を満たすか判定される（Ｓ２２）。

【0049】

再評価条件を満たさない場合（Ｓ２２のＮ）、導出部３２は、保留中のリクエスト情報が評価期限（受付期限）を満たすか判定する（Ｓ３０）。評価期限は、再評価を終了する期限で、受付期限に相当する。保留中のリクエスト情報が評価期限を満たさない場合（Ｓ３０のＮ）、受付期限を満たすまで再評価条件を満たすか判定される（Ｓ２２）。

【0050】

保留中のリクエスト情報が評価期限を満たす場合（Ｓ３０のＹ）、導出部３２は、保留中のリクエスト情報に対して最終的な予約結果を導出して運行計画を作成する（Ｓ３２）。なお、導出部３２は、運行計画を作成後に、その運行計画に同乗可能なユーザのリクエストを成立すると判定してよい。保留中のリクエスト情報が最終的な予約結果において成立条件を満たす場合（Ｓ３４のＹ）、通知制御部２８は、リクエスト情報を送信したユーザ端末装置１２にリクエストが成立したことを示す情報を通知する（Ｓ３６）。成立条件は、導出部３２によって最終的な予約結果が成立であると判定されれば満たされる。

【0051】

保留中のリクエスト情報が最終的な予約結果において成立条件を満たさない場合（Ｓ３４のＮ）、通知制御部２８は、リクエスト情報を送信したユーザ端末装置１２にリクエストが不成立であることを示す情報を通知する（Ｓ３８）。このように、保留中のリクエスト情報は受付期限に達すれば成立および不成立の結論が出される。

【0052】

なお実施例はあくまでも例示であり、各構成要素の組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【符号の説明】

【0053】

１ 予約受付システム、 １０ 予約受付装置、 １２ ユーザ端末装置、 １４ 車両管理装置、 １６ 車両、 ２０ 通信部、 ２２ 取得部、 ２４ 導出処理部、 ２６ リクエスト保持部、 ２８ 通知制御部、 ３０ モデル保持部、 ３２ 導出部。

【図1】

【図2】

【図3】

【図4】