特開 2023-178552 情報処理システム及び情報処理方法、並びにコンピュータプログラム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023178552

(43)【公開日】2023-12-18

(54)【発明の名称】情報処理システム及び情報処理方法、並びにコンピュータプログラム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20231211BHJP

   G06Q 50/30 20120101ALI20231211BHJP

   G16Y 40/60 20200101ALI20231211BHJP

   G16Y 20/20 20200101ALI20231211BHJP

   G16Y 10/40 20200101ALI20231211BHJP

【ＦＩ】

G08G1/00 D

G06Q50/30

G16Y40/60

G16Y20/20

G16Y10/40

【審査請求】未請求

【請求項の数】19

【出願形態】ＯＬ

(21)【出願番号】P 2022091299

(22)【出願日】2022-06-06

(71)【出願人】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】100093241

【弁理士】

【氏名又は名称】宮田 正昭

(74)【代理人】

【識別番号】100101801

【弁理士】

【氏名又は名称】山田 英治

(74)【代理人】

【識別番号】100095496

【弁理士】

【氏名又は名称】佐々木 榮二

(74)【代理人】

【識別番号】100086531

【弁理士】

【氏名又は名称】澤田 俊夫

(74)【代理人】

【識別番号】110000763

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

(72)【発明者】

【氏名】高橋 一晃

(72)【発明者】

【氏名】小澤 萌樹

【テーマコード（参考）】

5H181

5L049

【Ｆターム（参考）】

5H181AA14

5H181BB04

5H181BB05

5H181BB13

5H181EE10

5H181FF01

5H181FF04

5H181FF10

5H181FF13

5H181FF22

5H181FF27

5H181FF33

5H181MA05

5H181MA13

5H181MA16

5H181MA18

5H181MC03

5H181MC24

5H181MC27

5L049CC42

(57)【要約】

【課題】ユーザのニーズに適うタクシーを探車するための処理を行う情報処理システムを提供する。
【解決手段】情報処理システムは、所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部を備える。前記条件変更部は、探車を開始して所定期間内に前記検索条件付きで前記探車部が車両を発見できないときに、前記検索条件の変更として、検索条件の除外、又は複数の検索条件のうち少なくとも一部の除外を行う。
【選択図】 図４

【特許請求の範囲】

【請求項1】

配車に関する注文を処理する情報処理システムであって、
所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部を備える、情報処理システム。

【請求項2】

前記条件変更部は、前記探車時間内で前記探車部が車両を発見できるように、前記検索条件の変更を行う、
請求項１に記載の情報処理システム。

【請求項3】

前記条件変更部は、探車を開始して所定期間内に前記検索条件付きで前記探車部が車両を発見できないときに、前記検索条件の変更を行い、
前記探車部は、探車を開始して所定期間経過後から前記探車時間の終了までの期間は、前記条件変更部により変更した後の検索条件に基づいて車両検索を継続する、
請求項１に記載の情報処理システム。

【請求項4】

前記条件変更部は、前記検索条件の変更として、検索条件の除外、又は複数の検索条件のうち少なくとも一部の除外を行う、
請求項１に記載の情報処理システム。

【請求項5】

前記検索条件は、前記注文に含まれる、
請求項１に記載の情報処理システム。

【請求項6】

前記検索条件は、希望車種、車両を配車する会社、車両の乗務員のうち少なくとも１つに関する条件を含む、
請求項１に記載の情報処理システム。

【請求項7】

前記検索条件は複数の条件を含み、且つ各条件の優先順位が指定されており、
前記条件変更部は、優先順位に基づいて、時間の経過に応じた前記検索条件の変更を行う、
請求項１に記載の情報処理システム。

【請求項8】

前記探車時間を設定する探車時間設定部をさらに備える、
請求項１に記載の情報処理システム。

【請求項9】

前記探車時間設定部は、配車方法、注文者の種別、注文者の指定、配車日時における天候、配車場所、配車場所の周囲のイベントの開催、又は前記所定圏内の空車台数（車両の検索し易さ）のうち少なくともいずれか１つに基づいて、前記探車時間を設定する、
請求項８に記載の情報処理システム。

【請求項10】

前記探車時間設定部は、注文者が指定する探車時間の長さに応じた課金を行う、
請求項９に記載の情報処理システム。

【請求項11】

車両検索の経過に関する情報又は車両検索の結果に関する情報のうち少なくとも一方を外部に通知する通知部をさらに備える、
請求項１に記載の情報処理システム。

【請求項12】

前記通知部は、前記探車部が車両検索中に、前記条件変更部が変更した前記検索条件に関する情報を通知する、
請求項１１に記載の情報処理システム。

【請求項13】

前記通知部は、配車することが決まった車両の情報とともに、前記条件変更部による前記検索条件の変更の有無又は変更した前記検索条件に関する情報を通知する、
請求項１１に記載の情報処理システム。

【請求項14】

前記通知部は、前記探車部が車両検索中に、前記所定圏内で前記検索条件に合致する車両に関する情報を通知する、
請求項１１に記載の情報処理システム。

【請求項15】

前記通知部は、前記探車部による探車失敗を、代替手段に関する情報を含めて通知する、
請求項１１に記載の情報処理システム。

【請求項16】

前記配車処理部は、前記探車部による車両検索を継続中に前記注文がキャンセルされたことに応じて、車両検索を終了させる、
請求項１に記載の情報処理システム。

【請求項17】

前記配車処理部は、前記注文に対する処理が完了したときに、探車の結果（成功又は失敗したか、注文がキャンセルされたか）、探車に適用した条件、探車に要した時間のうち少なくとも１つを含む履歴情報を保存する、
請求項１に記載の情報処理システム。

【請求項18】

配車に関する注文を処理する情報方法であって、
所定圏内で検索条件を満たす車両を検索する探車ステップと、時間の経過に応じて前記検索条件を変更する条件変更ステップを有し、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する、情報処理方法。

【請求項19】

所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部としてコンピュータが機能するように、コンピュータ可読形式で記述されたコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書で開示する技術（以下、「本開示」とする）は、タクシーの配車に関する注文を処理する情報処理システム及び情報処理方法、並びにコンピュータプログラムに関する。

【背景技術】

【0002】

無線技術と測位技術の向上及び普及に伴い、例えばタクシーの在庫管理や配車を効率的に行えるようになってきている。また、スマートフォンなどの情報端末上のタクシー配車アプリを利用したタクシーの注文も増えてきている。

【0003】

例えば、ユーザを輸送する車両の配車を依頼するユーザの端末から、前記車両の配車依頼と、前記ユーザの乗車位置とを取得する配車依頼取得部と、前記配車依頼取得部が前記配車依頼を取得した時刻である依頼時刻と、前記配車依頼を行ったユーザの識別情報と、前記乗車位置とを関連付けて依頼順情報として記憶部に記憶させる記憶制御部と、空車の車両と、当該空車の車両の位置とを検出する空車検出部と、前記空車検出部が前記空車の車両を検出すると、前記依頼順情報を参照し、前記乗車位置が前記空車の車両の位置から所定範囲内のユーザのうち、前記依頼時刻が最も早いユーザに対応する配車を前記空車の車両に指示する配車指示部を備える配車管理装置が提案されている（特許文献１を参照のこと）。また、車両（車種など）に関する条件を指定して、配車の対象となる車両の検索を行う配車システムが提案されている（特許文献２を参照のこと）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０２１－６９５７号公報

【特許文献2】特開２０１９－２１２１１８号公報

【発明の概要】

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

【0005】

本開示の目的は、ユーザのニーズに適うタクシーを探車するための処理を行う情報処理システム及び情報処理方法、並びにコンピュータプログラムを提供することにある。

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

【0006】

本開示は、上記課題を参酌してなされたものであり、その第１の側面は、配車に関する注文を処理する情報処理システムであって、
所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部を備える、情報処理システムである。

【0007】

但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。すなわち、複数の部品又は機能モジュールからなる１つの装置も、複数の装置の集合体も、「システム」に相当する。

【0008】

前記条件変更部は、前記探車時間内で前記探車部が車両を発見できるように、前記検索条件の変更を行う。具体的には、前記条件変更部は、前記検索条件の変更として、検索条件の除外、又は複数の検索条件のうち少なくとも一部の除外を行う。そして、前記探車部は、探車を開始して所定期間経過後から前記探車時間の終了までの期間は、前記条件変更部により変更した後の検索条件に基づいて車両検索を継続する。

【0009】

第１の側面に係る情報処理システムは、前記探車時間を設定する探車時間設定部をさらに備える。前記探車時間設定部は、配車方法、注文者の種別、注文者の指定、配車日時における天候、配車場所、配車場所の周囲のイベントの開催、又は前記所定圏内の空車台数（車両の検索し易さ）のうち少なくともいずれか１つに基づいて、前記探車時間を設定する。

【0010】

また、第１の側面に係る情報処理システムは、車両検索の経過に関する情報又は車両検索の結果に関する情報のうち少なくとも一方を外部に通知する通知部をさらに備える。前記通知部は、前記探車部が車両検索中に、前記条件変更部が変更した前記検索条件に関する情報を通知するようにしてもよい。前記通知部は、配車することが決まった車両の情報とともに、前記条件変更部による前記検索条件の変更の有無又は変更した前記検索条件に関する情報を通知するようにしてもよい。

【0011】

また、本開示の第２の側面は、配車に関する注文を処理する情報方法であって、
所定圏内で検索条件を満たす車両を検索する探車ステップと、時間の経過に応じて前記検索条件を変更する条件変更ステップを有し、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する、情報処理方法である。

【0012】

また、本開示の第３の側面は、
所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部としてコンピュータが機能するように、コンピュータ可読形式で記述されたコンピュータプログラムである。

【0013】

本開示の第３の側面に係るコンピュータプログラムは、コンピュータ上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータプログラムを定義したものである。換言すれば、本開示の第３の側面に係るコンピュータプログラムをコンピュータにインストールすることによって、コンピュータ上では協働的作用が発揮され、本開示の第１の側面に係る情報処理システムと同様の作用効果を得ることができる。

【発明の効果】

【0014】

本開示によれば、サービスの品質を担保しつつユーザのニーズに適うタクシーを探車するための処理を行う情報処理システム及び情報処理方法、並びにコンピュータプログラムを提供することができる。

【0015】

なお、本明細書に記載された効果は、あくまでも例示であり、本開示によりもたらされる効果はこれに限定されるものではない。また、本開示が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

【0016】

本開示のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

【図面の簡単な説明】

【0017】

【図1】図１は、本開示が適用される配車システム１００の概略的な構成例を示した図である。

【図2】図２は、ユーザ端末１０１の機能的構成を示した図である。

【図3】図３は、乗務員端末１０２の機能的構成を示した図である。

【図4】図４は、配車管理装置１０３の機能的な構成例を示した図である。

【図5】図５は、配車システム１００における即時配車時の概略的な処理シーケンスを示した図である。

【図6】図６は、配車システム１００における予約配車時の概略的な処理シーケンスを示した図である。

【図7】図７は、配車要求画面（タクシー配車アプリの起動画面）の構成例を示した図である。

【図8】図８は、配車要求画面（オプション設定時）の構成例を示した図である。

【図9】図９は、希望車種選択画面９００の構成例を示した図である。

【図10】図１０は、会社指定画面１０００の構成例を示した図である。

【図11】図１１は、乗務員指定画面１１００の構成例を示した図である。

【図12】図１２は、予約注文画面１２００（予約時間指定前）の構成例を示した図である。

【図13】図１３は、予約注文画面１２００の構成例（予約時間指定後）を示した図である。

【図14】図１４は、予約注文指示画面１４００の構成例を示した図である。

【図15】図１５は、ユーザ端末の画面遷移例を示した図である。

【図16】図１６は、基本配車管理サーバ４１０内の配車処理部４１１が実施する配車処理方法を模式的に示した図である。

【図17】図１７は、配車場所を中心とする所定圏内で見つかったタクシーを地図上で示した図である。

【図18】図１８は、所定圏内で見つかったタクシー（図１７を参照）を、指定されたオプション条件でフィルタリングした結果を示した図である。

【図19】図１９は、配車処理部４１１による予約配車の注文に対する配車処理動作の遷移を示した図である。

【図20】図２０は、配車システム１００における予約配車時の詳細な処理シーケンス例（前半部分）を示した図である。

【図21】図２１は、配車システム１００における予約配車時の詳細な処理シーケンス例（後半部分）を示した図である。

【図22】図２２は、情報処理装置２０００の構成例を示した図である。

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

【0018】

以下、図面を参照しながら本開示について、以下の順に従って説明する。

【0019】

Ａ．概要
Ｂ．システム構成
Ｂ－１．全体構成
Ｂ－２．ユーザ端末の構成
Ｂ－３．乗務員端末の構成
Ｂ－４．配車管理装置の構成
Ｃ．配車フロー
Ｃ－１．基本的な処理手順
Ｃ－２．ユーザ端末上での操作
Ｃ－２－１．即時配車の注文時のユーザ端末上での操作
Ｃ－２－２．予約配車の注文時のユーザ端末上での操作
Ｃ－２－３．ユーザ端末の画面遷移
Ｃ－３．探車ロジック
Ｃ－４．詳細な処理シーケンス
Ｄ．装置構成

【0020】

Ａ．概要
スマートフォンなどの携帯型の多機能情報端末の普及に伴い、タクシー配車アプリを介してタクシーの配車を注文するケースが増えてきている。ここで、タクシーの配車の注文は、ユーザがすぐにタクシーに乗車するための即時配車と、ユーザが指定した乗車時間にタクシーを配車する予約配車の２通りの方法で行われるものとする。そして、タクシーを配車依頼するユーザは、基本的には早く乗れる車両を見つけたい（又は、指定した時刻通りに配車してほしい）が、その他にも、荷物が多いのでワゴンタイプ（又は、スライドドア）の車両に乗りたい、乗車可能人数の多い車両に乗りたいといった車両に関する条件や、大事なお客様を送迎するので運転操作を信頼できる乗務員歴が長い（又は、高評価）の乗務員が良い、外国人を送迎するので英語を話せる乗務員が良いといった乗務員に関する条件が要望されることもある。

【0021】

タクシーを配車依頼する際の要望は一様ではなく、ユーザが置かれている状況などに応じてまちまちである。一方、タクシーの配車サービスを提供する配車システム側においても、各ユーザのさまざまな要望にすべて応えられるだけの在庫を抱えるのは負担が大きい。このため、ユーザがタクシーを配車依頼する際に指定するすべての条件を同時に満たす車両を探車することは難しい。

【0022】

そこで、本開示は、ユーザがタクシーを配車依頼する際に指定するすべての条件を同時に満たす車両を探車することは難しい場合であっても、なるべくユーザの要望に沿った形で探車することができる配車システムを実現している。

【0023】

Ｂ．システム構成
Ｂ－１．全体構成
図１には、本開示が適用される配車システム１００の概略的な構成例を示している。図１に示す配車システム１００は、タクシーを利用するユーザが操作するユーザ端末１０１と、タクシーの乗務員が操作する乗務員端末１０２と、配車管理装置１０３の３者で構成される。

【0024】

図１では簡素化のため、ユーザ端末１０１及び乗務員端末１０２をそれぞれ１台ずつしか描いていないが、実際には、タクシーを利用するユーザ数分のユーザ端末、並びに配車システム１００を通じてユーザに配車されるタクシーの台数分（又は乗務員の人数分）の乗務員端末が存在するものとする。ユーザ端末１０１は、具体的にはユーザが所持するスマートフォンなどの携帯型の多機能情報端末であり、このような情報端末にタクシー配車アプリをインストールしてユーザ端末１０１として動作することができる。また、乗務員端末１０２は、車両に搭載された専用端末、又は乗務員が所持するスマートフォンなどの携帯型の多機能情報端末であり、このような情報端末にドライバーズアプリをインストールして乗務員端末１０２として動作することができる。

【0025】

また、図１では簡素化のため、配車管理装置１０３を単一のブロックにまとめて描いているが、実際には物理的に独立した複数の装置の組み合わせにより１つの配車管理装置１０３が構成されてもよい。また、配車管理装置１０３は、複数のサーバ機能を統合して構成されてもよい。本実施形態では、配車管理装置１０３は、配車依頼を処理する「基本配車管理サーバ」、ユーザ端末１０１として動作する各スマートフォンのアカウント情報（メールアドレス及び電話番号など）を管理するとともにユーザ端末１０１（タクシー配車アプリ）からの配車依頼を受付処理する「端末対応サーバ」、ユーザ端末１０１からの予約注文を受け付けて、予約時刻の所定時間前（例えば、１０分前）になると配車依頼を発行する「予約管理サーバ」などを含んでいる。もちろん、配車管理装置１０３がさらにその他のサーバ機能を備えていてもよい。配車管理装置１０３に含まれるサーバ構成の詳細については後述に譲る。

【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】

配車管理装置１０３は、配車依頼元のユーザ端末１０１に対して、迎車中の乗務員端末１０２から取得した位置情報を含む注文情報更新通知を行う。ユーザ端末１０１側では、注文情報更新通知を受け取る度に、配車要求画面（例えば、画面内の地図上での迎車中のタクシーの表示位置）を更新する。

【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】

基本配車管理サーバ４１０は、乗務員端末１０２から配車応答を受信すると（ステップＳ６１３）、乗務員端末１０２に対して、お客様名やお客様住所などの迎車に必要な情報をさらに送信する（ステップＳ６１４）。乗務員端末１０２は、基本配車管理サーバ４１０から受信したお客様名やお客様住所などの情報を依頼情報画面に表示して、迎車に対応した処理を開始する（Ｓ６１５）。カーナビゲーションを利用する場合には、乗務員端末１０２は配車場所までのナビゲーションを開始する。

【0089】

また、基本配車管理サーバ４１０は、乗務員端末１０２から配車応答を受信すると（ステップＳ６１３）、端末対応サーバ４２０に対して、配車が確定したタクシーの情報を送信する（ステップＳ６１６）。そして、端末対応サーバ４２０は、基本配車管理サーバ４１０から受け取ったタクシーの情報を、さらにユーザ端末１０１に伝達する（ステップＳ６１７）。ユーザ端末１０１は、基本配車管理サーバ４１０から受信した配車が確定したタクシーの情報を画面に表示する（ステップＳ６１８）。

【0090】

また、乗務員端末１０２は、配車場所に到着するまでの間、所定時間間隔（数秒～数十秒）で当該車両の位置情報を繰り返し基本配車管理サーバ４１０に伝達する（ステップＳ６１９）。基本配車管理サーバ４１０は、乗務員端末１０２から受信した車両の位置情報を端末対応サーバ４２０に伝達し（ステップＳ６２０）、端末対応サーバ４２０はさらに依頼元のユーザ端末１０１に伝達する（ステップＳ６２１）。そして、ユーザ端末１０１は、車両の位置情報を受信する度に、画面上で迎車中のタクシーの位置情報を更新する（ステップＳ６２２）。

【0091】

Ｃ－２．ユーザ端末上での操作
このＣ－２項では、ユーザ端末１０１上でのタクシーの配車を行う際の操作方法について説明する。本実施形態では、タクシー配車アプリを用いて、即時配車と予約配車の２種類の配車方法を利用できることを想定している。タクシー配車アプリが即時配車を行う場合の動作モードを「即時配車」モードとし、予約配車を行う場合の動作モードを「予約配車」モードとする。

【0092】

Ｃ－２－１．即時配車の注文時のユーザ端末上での操作
既に述べたように、ユーザ端末１０１上でタクシー配車アプリを起動すると、「即時配車」モードとなり、表示部２４０の画面に配車要求画面が表示される。ユーザは、基本的にはタッチパネルの操作によって、即時配車の注文を行うことができる。

【0093】

図７には、ユーザ端末１０１上でタクシー配車アプリを起動したとき（及び、「即時配車」モード下）の画面の構成例を示している。例えばユーザ端末１０１の待ち受け画面上でタクシー配車アプリのアイコン（図示しない）をタップすることで、タクシー配車アプリが起動する。図示の起動画面７００は、画面７００の上の約３分の２を占める地図領域７１０と、画面７００の下の約３分の１の残りの入力操作領域７２０で構成される。

【0094】

地図領域７１０は、位置検出部２６０で検出されるユーザ端末１０１の現在位置がほぼ中央となるように、デフォルトの縮尺で地図が表示される。また、地図領域７１０上には、ユーザ端末１０１の現在位置を示すピン７１１が表示される。地図領域７１０をスワイプ操作することで、地図の表示範囲を移動させることができる。また、地図領域７１０をピンチ操作することで、表示する地図の縮尺を連続的に変更することができる。地図の表示範囲を移動させた地図の縮尺を変更させても、地図領域７１０のほぼ中央のピン７１１は動かず、地図上でピン７１１が指す位置が、配車依頼したときのタクシーの配車場所となる。

【0095】

入力操作領域７２０は、タクシー配車アプリのモードに応じて構成が異なる。タクシー配車アプリのモードは、タクシーの即時配車を注文する「即時配車」モードと、指定した時間のタクシーの予約配車を予約する「予約配車」モードの２モードを含む。タクシー配車アプリの起動は「即時配車」モードに設定されており、図７に示す起動画面７００の入力操作領域７２０は「即時配車」モード時における構成、すなわち配車要求画面である。

【0096】

入力操作領域７２０の最下段のボタン配置領域７２６には、「いますぐ呼ぶ」ボタンと「予約」ボタンが配置されている。「いますぐ呼ぶ」ボタンをタップすると、タクシー配置アプリは「即時配車」モードに設定されるとともに、図７に示すような「即時配車」モード下の配車要求画面７００が表示される。また、「予約」ボタンをタップすると、タクシー配車アプリは「予約配車」モードに切り替わるとともに、配車要求画面も「予約配車」モード下の予約注文画面（後述）に遷移する。そして、「予約配車」モード下で「いますぐ呼ぶ」ボタンをタップすると、「即時配車」モードに復帰するとともに配車要求画面７００に遷移する。

【0097】

入力操作領域７２０は、上から順に、スライダー７２１、配車場所表示領域７２２、目的地表示領域７２３、運賃方式選択部７２４、支払方法設定部７２５が配置されている。

【0098】

スライダー７２１には、「スライドしてタクシーを呼ぶ」というメッセージが表示されている。スライダー７２１を左から右にスライド（スワイプ）させると、現在の入力操作領域７２０で指定されている内容で配車依頼（即時配車を注文）する処理が実行される。この場合、タクシー配車アプリは端末対応サーバ４２０に配車依頼を送信し、これによって、配車システム１００では図５に示したような即時配車時の処理手順が実施される。

【0099】

配車場所表示領域７２２には、配車場所の住所が表示される。上述したように、配車場所は地図領域７１０のほぼ中央のピン７１１が指す位置である。地図領域７１０のスワイプ操作などにより地図上でピン７１１の位置が移動すると、配車場所表示領域７２２に表示される配車場所の住所も更新される。また、配車場所表示領域７２２をタップすると、配車場所入力画面（図示しない）に切り替わる。配車場所入力画面では、住所や検索ワードで配車場所の住所を検索したり、地図を使って配車場所を入力したりすることができる。一度入力した配車場所をお気に入り登録して、次回以降の即時配車及び予約配車の注文時にはお気に入りの中から配車場所を選択することができる。配車場所入力画面上で「戻る」ボタン（図示しない）をタップすると、図７に示す配車要求画面７００に戻る。

【0100】

目的地表示領域７２３には、配車されるタクシーの目的地の住所が表示される。タクシー配車アプリの起動時は図７に示すように目的地は未指定であり、目的地を指定しないまま配車依頼を行うこともできる。目的地表示領域７２３をタップすると、目的地入力画面（図示しない）に切り替わる。目的地入力画面の構成は、上記の配車場所入力画面と同様であり、住所や検索ワードで目的地の住所を検索したり、地図を使って目的地を入力したりすることができる。一度入力した目的地をお気に入り登録して、次回以降の即時配車及び予約配車の注文時にはお気に入りの中から目的地を選択することができる。目的地入力画面上で「戻る」ボタン（図示しない）をタップすると、図７に示す配車要求画面７００に戻る。

【0101】

運賃方式選択部７２４をタップすると、運賃方式の選択画面（図示しない）に切り替わり、運賃方式を選択及び切り替えることができる。運賃方式として、例えば「メーター運賃」方式と「事前確認運賃」方式のいずれかを設定することができる。「事前確認運賃」方式を選択するには、目的地の指定が必須である。配車要求画面７００上の運賃方式選択部７２４には、現在選択されている「メーター運賃」方式が表示されている。

【0102】

支払方法設定部７２５をタップすると、支払方法の設定画面（図示しない）に切り替わり、運賃の支払いに使用するカードを指定したり、選択及び変更したりすることができる。配車要求画面７００上の支払方法設定画面７２５には、現在支払いに設定されているクレジットカードの情報が表示されている。運転方式の設定画面及び支払方法設定画面上で「戻る」ボタン（図示しない）をタップすると、図７に示す配車要求画面７００に戻る。

【0103】

本実施形態では、即時配車の注文時にオプション条件を指定することができる。入力操作領域７２０の上端付近のハンドル７２７を上にせり上げるようにスワイプ操作すると、図８に示すように入力操作領域７２０が上方に拡張して、運賃方式選択部７２４及び支払方法設定部７２５とボタン表示領域７２６の間に、オプション設定部８００が出現する。なお、ハンドル７２７を下方に押し戻すようにスワイプ操作すると、オプション設定部８００は退避して、図７に示した状態の配所要求画面に復帰する。

【0104】

オプション設定部８００には、条件を指定可能なオプションの項目数分の選択ボタンが配置され、いずれかの選択ボタンをタップすると、該当するオプション条件を選択するオプション選択画面に切り替わり、条件を設定及び変更することができる。どのようなオプション項目を指定可能にするかは、配車システム１００の運用次第であり、時間の経過によりオプション項目が変更されたり、オプション項目数が増減したりすることもある。本実施形態では車両、乗務員、及びタクシー会社の３種類のオプション項目の指定が可能であることを想定している。したがって、図８に示す例では、オプション設定部８００は、「希望車種」ボタン８０１、「会社指定」ボタン８０２、「乗務員指定」ボタン８０３の３つの選択ボタンを含んでいる。

【0105】

オプション設定部８００で「希望車種」ボタン８０１をタップすると、図９に示すような希望車種選択画面９００に切り替わる。希望車種選択画面９００には、選択可能な車種の一覧が表示され、希望する車種の行のチェックボックスをタップしてチェックを入れることによって、その車種を選択することができる。図９に示す例では、車種「トールタイプ」の１種類のみしか選択できないが、タクシー会社が３種類以上の車種を提供している場合には、希望車種選択画面９００で３種類以上の車種を選択できるように構成してもよい。また、各希望車種について「指定する」と「指定しない」の２択ではなく、希望車種の指定が「必須」、「できれば」、及び「指定しない」の３択にしてもよいし、他のオプション条件（会社、乗務員など）との優先順位をさらに指定できるようにしてもよい。そして、希望車種選択画面９００の最下段の「変更を確定」ボタンをタップすると、この画面で選択又は変更した内容が確定して、図７に示す配車要求画面７００に戻る。また、希望車種選択画面９００の最上段の「戻る」ボタンをタップすると、車種を変更しないまま図７に示す配車要求画面７００に戻る。

【0106】

また、オプション設定部８００で「会社指定」ボタン８０２をタップすると、図１０に示すような会社指定画面１０００に切り替わる。図１０に示す例では、配車システム１００で使用可能な各タクシー会社の社名と、ロゴマーク（図１０では図示を省略）と、スイッチからなるリストが表示され、各タクシー会社の行の右端のスイッチをオン側にスライドさせることで該当するタクシー会社を選択肢に含めることができる。タクシー会社を「指定する」と「指定しない」の２択ではなく、タクシー会社の指定が「必須」、「できれば」、及び「指定しない」の３択にしてもよいし、他のオプション条件（希望車種、乗務員など）との優先順位をさらに指定できるようにしてもよい。そして、会社指定画面１０００の最下段の「変更を確定」ボタンをタップすると、この画面で選択又は変更した内容が確定して、図７に示す配車要求画面７００に戻る。また、会社指定画面１０００の最上段の「戻る」ボタンをタップすると、タクシー会社を変更しないまま図７に示す配車要求画面７００に戻る。

【0107】

また、オプション設定部８００で「乗務員指定」ボタン８０３をタップすると、図１１に示すように乗務員指定画面１１００に切り替わる。図１１に示す例では、優良乗務員を指定するか否かの２者が表示されており、希望する方の行のチェックボックスをタップしてチェックを入れることによって、優良乗務員を指定しないか指定するかのいずれかを選択することができる。そして、乗務員指定画面１１００の最下段の「変更を確定」ボタンをタップすると、この画面で選択又は変更した内容が確定して、図７に示す配車要求画面７００に戻る。また、乗務員指定画面１１００の最上段の「戻る」ボタンをタップすると、乗務員指定を変更しないまま図７に示す配車要求画面７００に戻る。

【0108】

なお、図１１に示す例では、優良乗務員を指定するか否かの２択であるが、配車システム１００の運用次第で、英語（又はその他の言語）が堪能であるか、性別や年齢といった属性情報など、選択項目を増やしてもよい。また、乗務員の喫煙の有無や車内での喫煙の有無を、乗務員指定画面で指定できるようにしてしてもよい。なお、乗務員の「優良」の定義は特に限定されないが、例えば乗務員歴が長く熟練していることや顧客のアンケート結果など、配車システム１００や個々のタクシー会社の独自の基準で決めてもよい。また、優良乗務員を「指定する」と「指定しない」の２択ではなく、優良乗務員の指定が「必須」、「できれば」、及び「指定しない」の３択にしてもよいし、他のオプション条件（希望車種、会社など）との優先順位をさらに指定できるようにしてもよい。乗務員の選択項目を増やした場合も同様に、各選択項目について「必須」、「できれば」、及び「指定しない」の３択にしてもよい。

【0109】

ユーザがユーザ端末１０１の画面上のオプション設定部８００を介してオプション条件を指定した場合には、指定したオプション条件に合致する車両のみを地図領域に表示したり（例えば、図１８を参照のこと）、指定したオプション条件に合致する車両の台数を表示したりするようにしてもよい。

【0110】

Ｃ－２－２．予約配車の注文時のユーザ端末上での操作
上記Ｃ－２－１項でも説明したように、起動画面である配車要求画面７００中の入力操作領域７２０の最下段のボタン配置領域７２６で、「予約」ボタンをタップすると、タクシー配車アプリは「予約配車」モードに切り替わるとともに、配車要求画面も「予約配車」モード下の予約注文画面に遷移する。

【0111】

図１２には、「予約配車」モード下の予約注文画面の構成例を示している。図示の予約注文画面１２００は、画面１２００の上の約３分の２を占める地図領域１２１０と、画面１２００の下の約３分の１の残りの入力操作領域１２２０で構成される。地図領域１２１０の構成及び動作は、配車要求画面７００の地図領域７１０と同様であり、ここでは説明を省略する。

【0112】

「予約配車」モードにおける入力操作領域１２２０の最下段のボタン配置領域１２２４には、「いますぐ呼ぶ」ボタンと「予約」ボタンが配置されている。この「予約配車」モード下で「いますぐ呼ぶ」ボタンをタップすると、「即時配車」モードに復帰するとともに配車要求画面７００に遷移する。

【0113】

入力操作領域１２２０は、上から順に、メッセージ表示部１２２１、配車場所表示領域１２２２、予約時間指定領域１２２３が配置されている。

【0114】

メッセージ表示部１２２１には、ユーザに予約時間の設定を促す「乗車日時を指定してください」というメッセージが表示されている。また、メッセージ表示部１２２１には、「次へ」ボタンが配置されている。乗車日時を指定していない状態では、「次へ」ボタンは不活性化（グレー表示）され、ボタンをタップすることができない。この入力操作領域１２２０上で乗車日時が指定されると、「次へ」ボタンは活性化（通常表示）され、タップするとさらに予約注文指示画面（後述）に遷移する。

【0115】

配車場所表示領域１２２２の構成及び動作は、配車要求画面７００の配車場所表示領域７２２と同様であり、ここでは説明を省略する。予約時間指定領域１２２３は、現在時刻から２５分後、３０分後、３５分後、４０分後、４５分後など５分刻みの注文枠で乗車日時を選択できる複数（図示の例では５個）の乗車日時選択ボタンと、乗車日時を自由に指定できる「日時を指定」ボタンが配置されている。例えば予約管理サーバ４３０から返された注文枠の情報に基づいて、各乗車日時選択ボタンが表示される。いずれかの乗車日時選択ボタンをタップすると、そのボタンに表示されている日時が予約時間に指定される。また、「日時を指定」ボタンをタップすると、日付ピッカーがポップアップ表示されて、リストをスクロールすることで、広範囲で且つ細かい粒度で乗車日時を指定することができる。日付ピッカーは、日付、時間、又は日付と時間を同時に選択させるためのコントロールであるが、当業界で周知なのでここでは図示を省略する。乗車日時の指定可能範囲（すなわち、何日先又は何か月先まで予約を受け付けるか）は、タクシーの配車に関わる事業の運用次第である。例えば、事前にサブスクライブした会員ユーザに対しては、一般ユーザよりも長い期間で予約を受け付けるなど、ユーザの差別化を図ってもよい。

【0116】

そして、入力操作領域１２２０上で乗車日時が指定されると、上述したようにメッセージ表示部１２２１内の「次へ」ボタンは活性化（通常表示）される。図１３には、予約時間指定領域１２２３内の乗車日時選択ボタン「１７：２５ ２５分後」をタップして選択して、メッセージ表示部１２２１内の「次へ」ボタンが活性化された様子を示している。この状態で「次へ」ボタンをタップすると、さらに予約注文指示画面に遷移する。

【0117】

図１４には、予約注文指示画面の構成例を示している。図示の予約注文指示画面１４００は、図７に示した配車要求画面７００と共通する部分が多い。予約注文指示画面１４００は、画面１４００の上の約３分の２を占める地図領域１４１０と、画面１４００の下の約３分の１の残りの入力操作領域１４２０で構成される。地図領域１４１０の構成及び動作は、配車要求画面７００の地図領域７１０と同様であり、ここでは説明を省略する。

【0118】

入力操作領域１４２０は、上から順に、スライダー１４２１、配車場所表示領域１４２２、目的地表示領域１４２３、運賃方式選択部１４２４、支払方法設定部１４２５、ボタン配置領域１４２６が配置されている。配車場所表示領域１４２２、目的地表示領域１４２３、運賃方式選択部１４２４、支払方法設定部１４２５、及びボタン配置領域１４２６の構成及び動作は、配車要求画面７００の各対応部分と同様であり、ここでは説明を省略する。

【0119】

本実施形態では、即時配車の注文時と同様に予約配車の注文時においても、オプション条件を指定することができる。入力操作領域１４２０の上端付近のハンドル１４２７を上にせり上げるようにスワイプ操作すると、入力操作領域１４２０が上方に拡張してオプション設定部が出現し、１又は複数のオプション条件を指定することができる。オプション設定部の構成及び動作は、上記で図８を参照しながら説明した通りであり、ここではオプション設定部の図示と説明を省略する。

【0120】

スライダー１４２１には、「スライドして注文する」というメッセージが表示されている。スライダー１４２１を左から右にスライド（スワイプ）させると、図１２に示した予約注文画面１２００で指定した乗車日時、支払方法、及び指定したオプション条件で、予約配車を注文する処理が実行される。この場合、タクシー配車アプリは予約管理サーバ４３０に予約注文を送信し、これによって、配車システム１００では図６に示したような予約配車時の処理手順が実施される。他方、地図領域１４１０内の戻るボタン１４１１をタップすると、図１２に示した予約値注文画面１２００に戻り、改めて乗車日時の指定を行うことができる。

【0121】

Ｃ－２－３．ユーザ端末の画面遷移
上記Ｃ－２－１項及びＣ－２－２項では、ユーザ端末１０１上でタクシー配車アプリを利用して即時配車及び予約配車の注文を行うときの画面操作についてそれぞれ説明した。このＣ－２－３項では、上記Ｃ－２－１項及びＣ－２－２項のまとめとして、図１５に示す画面遷移図を参照しながら、タクシー配車アプリを実行中のユーザ端末１０１の画面遷移について説明する。

【0122】

例えばユーザ端末１０１の待ち受け画面上でタクシー配車アプリのアイコンをタップすると、タクシー配車アプリは「即時配車」モードで起動して、表示部２４０の画面には図７に示す配車要求画面が表示される。

【0123】

配車要求画面において、配車場所表示領域をタップすると、配車場所入力画面に遷移して、住所や検索ワードで配車場所の住所を検索したり、地図を使って配車場所を入力したりすることができる。また、配車要求画面において、目的地表示領域をタップすると、目的地入力画面に遷移して、住所や検索ワードで目的地の住所を検索したり、地図を使って目的地を入力したりすることができる。また、配車要求画面において、運賃方式選択部をタップすると、運賃方式の選択画面に遷移して、運賃方式を設定することができる。また、配車要求画面において、支払方法設定部をタップすると、支払方法の設定画面に遷移して、支払いに使用するクレジットカードや、電子マネー、コード決済などを指定することができる。これら配車場所入力画面、目的地入力画面、運賃方式設定画面、及び支払方法設定画面の各々において、「戻る」ボタンをタップすると、元の配車要求画面に遷移する。

【0124】

配車要求画面において、入力操作領域の上端付近のハンドルを上にせり上げるようにスワイプ操作すると、図８に示すようにオプション設定部が出現する。また、このハンドルを下方に押し戻すようにスワイプ操作すると、オプション設定部は退避して、元の配車要求画面に戻る。

【0125】

オプション設定部内の「希望車種」ボタンをタップすると、図９に示す希望車種選択画面に遷移して、配車を希望する車種を選択することができる。また、オプション設定部内の「会社指定」ボタンをタップすると、図１０に示す会社指定画面に遷移して、タクシーを配車するタクシー会社を指定することができる。また、オプション設定部内の「乗務員指定」ボタンをタップすると、図１１に示す乗務員指定画面に遷移して、タクシーの乗務員が「優良」に限るか否かを指定することができる。これら希望車種指定画面、会社指定画面、及び乗務員指定画面の各々において、「変更を確定」ボタンをタップすると書く画面で選択又は変更した内容が確定し、「戻る」ボタンをタップすると、元の配車要求画面に遷移する。

【0126】

配車要求画面内の入力操作領域の最上段のスライダーには「スライドしてタクシーを呼ぶ」というメッセージが表示されている。スライダーを左から右にスライド（スワイプ）させると、現在の入力操作領域で指定されている配車場所及びオプション条件の内容で配車依頼（即時配車を注文）する処理が実行される。この場合、タクシー配車アプリは端末対応サーバ４２０に配車依頼を送信し、これによって、配車システム１００では図５に示したような即時配車時の処理手順が実施される。

【0127】

配車要求画面において最下段の「予約ボタン」をタップすると、タクシー配車アプリは「予約配車」モードに切り替わるとともに、図１２に示す予約注文画面に遷移する。また、予約注文画面において最下段の「いますぐ呼ぶ」ボタンをタップすると、タクシー配車アプリは「即時配車」モードに復帰するとともに、配車要求画面に遷移する。

【0128】

予約注文画面内の入力操作領域は、予約したい乗車日時を指定する予約時間指定領域を含む。予約時間指定領域は、予約管理サーバ４３０から与えられた注文枠にそれぞれ対応する各乗車日時候補を指定するための複数の乗車日時選択ボタンと、「日時を指定」ボタンが配置されている。いずれかの乗車日時選択ボタンをタップすることで、該当する乗車日時を予約時間に指定することができる。また、「日時を指定」ボタンをタップすると、日付ピッカーが出現して広範囲で且つ細かい粒度で乗車日時を指定することができる。

【0129】

予約注文画面内の入力操作領域で予約時間を指定すると、図１３に示すように、入力操作領域の最上段のメッセージ表示領域中の「次へ」ボタンが活性化される。そして、この「次へ」ボタンをタップすると、図１４に示す予約注文指示画面に遷移する。また、予約注文指示画面で戻るボタンをタップすると、図１２に示す予約値注文画面に戻り、改めて乗車日時の指定を行うことができる。

【0130】

予約注文指示画面は、配車要求画面と画面構成が類似する。予約注文指示画面内の入力操作領域は配車場所表示領域、目的地表示領域、運賃方式選択部、支払方法設定部を含む。そして、配車要求画面の場合と同様に、予約注文指示画面から、配車場所入力画面、目的地入力画面、運賃方式の選択画面、及び支払方法の設定画面に遷移して、それぞれの遷移先の画面上で配車場所、目的地、運賃方式、支払方法を指定し、選択し、又は変更することができる。

【0131】

また、予約注文指示画面も、配車要求画面と同様に、入力操作領域の上端付近のハンドルを上下にスワイプ操作させることで、オプション設定部を出現及び退避させることができる。そして、配車要求画面の場合と同様に、オプション設定部は、「希望車種」ボタン、「会社指定」ボタン、「乗務員指定」ボタンをタップすることで、希望車種選択画面、会社指定画面、及び乗務員指定画面にそれぞれ遷移してオプション条件を設定及び変更することができる。

【0132】

予約注文指示画面の入力操作領域の最上段のスライダーには「スライドして注文」というメッセージが表示されている。スライダーを左から右にスライド（スワイプ）させると、予約注文画面及び予約注文指示画面で指定されている予約時間、配車場所及びオプション条件の内容で予約配車を注文する処理が実行される。この場合、タクシー配車アプリは予約管理サーバ４３０に予約注文を送信し、これによって、配車システム１００では図６に示したような予約配車時の処理手順が実施される。

【0133】

Ｃ－３．探車ロジック
このＣ－３項では、基本配車管理サーバ４１０において配車処理に適用される探車ロジックについて説明する。

【0134】

図１６には、基本配車管理サーバ４１０内の配車処理部４１１が実施する配車処理方法を模式的に示している。配車処理部４１１は、即時配車の注文（配車依頼）に対し、基本的な車両探索、所定時間内（例えば２分以内）に迎車が可能な車両として、配車場所を中心とする所定圏内（半径２ｋｍ以内など）にいる車両を探索する。

【0135】

また、配車処理部４１１は、所定圏内で車両探索して見つかった車両に対して、配車依頼に指定されているオプション条件でフィルタリングを行う。上記では、オプション条件の具体例として車両（車種）、乗務員、及びタクシー会社を挙げたが、図１６では抽象化してオプション指定１～３として示している。図示のように、各オプション条件について、「必須」、「できれば」、及び「オフ」の３通りを指定することができる。「必須」が指定されたオプション条件については、必ずその条件を満たすように車両探索を行わなければならない。一方、「できれば」が指定されたオプション条件については、探索しても見つからない場合にはその条件を満たさないことが許容される（言い換えれば、条件を解除して、車両探索を優先する）。

【0136】

なお、複数のオプション条件の間で優先順位をさらに指定できるようにしてもよい。例えば、「できれば」が指定された複数の条件のうち一部しか満たさない車両が複数見つかった場合には、より優先順位の高いオプション条件を満たす車両を選択するようにしてもよい。

【0137】

ユーザは、基本的には早く乗れる車両を見つけたい（又は、指定した時刻通りに迎車してほしい）が、オプション条件を指定することによって、状況毎に異なるニーズになるべく沿った形で探車できるようになる。例えば、荷物が多いのでワゴンタイプ（又は、スライドドア）の車両に乗りたい、乗車可能人数の多い車両に乗りたいといった車両に関する条件や、大事なお客様を送迎するので運転操作を信頼できるベテラン（又は、高評価）の乗務員の車両を手配したい、外国人を送迎するので英語を話せる乗務員の車両を手配したい、といった個別のユーザのニーズに対応することが可能になる。

【0138】

反面、オプション条件を指定することによって、車両が見つかり難くなるという問題がある。図１７には、配車場所を中心とする所定圏内で見つかったタクシーを地図上で示している。また、図１８には、所定圏内で見つかったタクシーを、指定されたオプション条件でフィルタリングした結果を示している。図１７と図１８を比較すると、フィルタリングによって配車可能なタクシーの台数が減少することが分かる。ユーザがユーザ端末１０１の画面上のオプション設定部８００を介してオプション条件を指定した場合には、同画面において、指定したオプション条件に合致する車両のみを地図領域に表示したり、指定したオプション条件に合致する車両の台数を表示したりするようにしてもよい。

【0139】

オプション条件を付けて探車することにより、よりユーザのニーズに沿ったタクシーを配車することが可能になり、サービスの品質が向上する。しかしながら、図１７と図１８を比較して分かるように、配車候補となるタクシーの台数は減少するため、いずれかの車両を配車できるものの、いずれの車両もオプション条件を満たさないという理由で、ユーザが予約した乗車日時になってもタクシーが配車されないという事態が発生し得る。ユーザが事前に予約したにもかかわらず、指定した乗車日時に一台のタクシーも配車されないとなると、サービスは劣悪であると言われても仕方がない。したがって、サービスの最低限の品質を担保するためには、探車失敗という事態を極力回避すべきである。すなわち、ユーザが予約した乗車日時が到来すると、オプション条件を満たすか否かにかかわらず、いずれかの車両を配車することが強く望まれる。

【0140】

そこで、配車処理部４１１は、探車時間をより長くとって、オプション条件を満たすタクシーを探索するようにしてもよい。通常の配車依頼であれば、１～２分程度で依頼元のユーザを配車可能な範囲で探車する。これに対し、５分以上、例えば１０分間探車することによって、より多くの台数の配車候補のタクシーを探索することができる。

【0141】

また、配車処理部４１１は、予約注文された配車依頼に対しては、指定された乗車日時からより長い時間前から、例えば１０分前から探車を開始して、より多くの台数の配車候補のタクシーを探索する。また、配車処理部４１１は、与えられた探車時間の前半ではオプション条件を課して探車するが、オプション条件を満たす車両を発見できなかった場合には、探車時間の後半ではオプション条件を解除して探車して、探車失敗という事態を極力回避し、最低限のサービス品質を保証するように努める。

【0142】

図１９には、配車処理部４１１による予約配車の注文に対する配車処理動作の遷移を模式的に示している。ここでは、与えられた探車時間を最大１０分とする。

【0143】

配車処理部４１１は、与えられた探車時間１０分のうち前半５分間では、オプション条件を課して探車する。配車処理部４１１において探車中に、ユーザ端末１０１側では、探車に課したオプション条件を画面表示するようにしてもよい。そして、配車処理部４１１は、所定圏内でオプション条件を満たす車両を発見できたなら、配車処理部４１１は、端末対応サーバ４２０経由で注文元のユーザ端末１０１に配車するタクシーの車両情報などを通知して、配車処理を終了する。

【0144】

一方、探車時間１０分のうち前半の５分間でオプション条件を満たす車両を発見できなかった場合には、配車処理部４１１は、探車時間の後半５分間では、オプション条件を解除して改めて所定圏内で探車を開始する。ユーザが注文時の複数のオプション条件を指定している場合には、探車時間の後半５分間で、すべてのオプション条件を解除するのではなく、一部のオプション条件のみを解除するようにしてもよい。ユーザがオプション条件毎に優先順位を指定している場合には、優先順位に従って複数のオプション条件を段階的に解除していくようにしてもよい。

【0145】

なお、配車処理部４１１は、探車中に、端末対応サーバ４２０経由で注文元のユーザ端末１０１に、オプション条件を解除することや解除したオプション条件を通知するようにしてもよい。この場合、ユーザ端末１０１は、探車中に、注文時に指定したオプション条件が解除されたことや解除されたオプション条件（又は、適用されているオプション条件）を画面に表示して、ユーザに提示するようにしてもよい。

【0146】

また、配車処理部４１１は、探車に成功し、配車が確定したタクシーの情報を通知する際には、探車時に適用したオプション条件やオプションを解除して探車されたタクシーであることなどの情報を含めて通知し、ユーザ端末１０１は探車時に適用したオプション条件やオプションを解除して探車されたタクシーであることなどの情報を併せて提示するようにしてもよい。

【0147】

後半５分間でも所定圏内で配車可能な車両を発見できなかった場合には、配車処理部４１１は、探車失敗として配車処理を終了する。また、配車処理部４１１は、端末対応サーバ４２０経由で注文元のユーザ端末１０１に、探車に失敗したこと（又は、残りの探車時間ではオプション条件を外して探車すること）を通知する。探車失敗通知は、失敗した注文に対する代替手段に関する情報を含んでいてもよい。また、ユーザ端末１０１は、「いますぐ呼ぶ」ボタンをタップして「即時配車」モード（配車依頼）に切り替えるか、又はコールセンターに直接電話してタクシーを注文するといった、代替手段をユーザに提示するようにしてもよい。

【0148】

最大の探車時間が長い場合には、ユーザは探索時間が満了するまで待ちきれない場合がある。例えば、ユーザ端末１０１には配車の通知が届かないが、目の前を空車のタクシーが何台も通過している場合や、辛抱できず他のタクシー配車サービスを利用したくなった場合、タクシーの利用自体を諦めた場合などである。このような場合のために、タクシー配車アプリ及び配車システム１００は注文のキャンセル機能を備えていてもよい。注文がキャンセルされると、配車処理部４１１は、該当する探車処理をキャンセルする。なお、キャンセル機能が乱用又は悪用されるのを防止するために、キャンセル料などのペナルティを課す、キャンセル機能の利用をプレミアム会員のみに限定するといった対策を講じるようにしてもよい。

【0149】

配車処理部４１１は、探車に成功又は失敗したときなど、配車依頼の処理が完了したときに、探車の結果（成功又は失敗したか、注文がキャンセルされたか）、探車に適用したオプション条件、探車に要した時間などの履歴情報を履歴情報管理部４１４に保存する。

【0150】

ここで、探車時間についても説明しておく。上記では、最大の探車時間を１０分間として説明したが、最大の探車時間は、配車システム１００又は基本配車管理サーバ４１０において設定される固定値であってもよいし、変更可能な可変値であってもよい。

【0151】

配車処理部４１１は、例えば、配車方法（即時配車か予約配車かなど）や依頼元ユーザの種別（一般会員かプレミアム会員か）によって異なる最大の探車時間を割り当てるようにしてもよい。また、配車処理部４１１は、配車日時における天候、配車場所、配車場所の周囲のイベントの開催、探車する圏内の空車台数（タクシーのつかまり易さ）に応じて、動的及び適応的に最大の探車時間を調整するようにしてもよい。

【0152】

また、ユーザが会員登録時や注文時に最大の探車時間を指定できるようにしてもよい。長い探車時間を指定する場合には、課金制にしてもよい。例えば、２分間までは無料とし、２分間より長い最大探車時間を指定する場合には、○分毎の×円追加など従量課金制にしてもよい。

【0153】

Ｃ－４．詳細な処理シーケンス
上記Ｃ－１項では、図６を参照しながら、予約配車時の概略的な処理シーケンスについて説明した。このＣ－４項では、上記Ｃ－３項で説明した探車ロジック（探車時間の後半ではオプション条件を外して探車するロジック）を採用した場合の、詳細な処理シーケンスについて、図２０及び図２１を参照しながら説明する。

【0154】

ユーザ端末１０１上でタクシー配車アプリが「予約配車」モードに遷移すると、予約管理サーバ４３０に対して注文枠を要求する（ステップＳ２００１）。これに対し、予約管理サーバ４３０は、ユーザ端末１０１に、予約可能な範囲で注文可能な枠数を返却する（ステップＳ２００２）。注文枠は、予約可能な範囲（例えば１週間先まで）で、所定時間間隔（例えば５分刻み）で設定される。そして、ユーザ端末１０１は、直近の所定個数（図１２に示した例では５個）の各注文枠に対応する乗車日時選択ボタンと「日時を指定」ボタンを配置した予約注文画面を表示する（ステップＳ２００３）。

【0155】

ユーザは、ユーザ端末１０１に画面表示された予約注文画面上で、乗車日時を指定し（ステップＳ２００４）、さらに必要に応じて希望車種選択（ステップＳ２００５）、配車するタクシー会社の指定（ステップＳ２００６）、乗務員指定（ステップＳ２００７）などのオプション条件を指定する。そして、乗車日時を指定後に予約注文指示画面（図１３を参照）に遷移して、予約注文を指示する（ステップＳ２００８）。

【0156】

予約管理サーバ４３０は、ユーザ端末１０１から予約注文を受信すると、予約リストに登録するとともに（ステップＳ２００９）、ユーザ端末１０１に予約結果を返す（ステップＳ２０１０）。そして、ユーザ端末１０１は、予約管理サーバ４３０から受け取った予約結果を画面に表示して、予約注文を完了する。

【0157】

図２０中のステップＳ２００１～Ｓ２０１０は、図６に示した処理シーケンス上のステップＳ６０１～Ｓ６０４に対応する。

【0158】

予約管理サーバ４３０は、予約リスト中の予約注文が予約時刻から所定時間前（例えば１０分前）になると、注文元のユーザ端末１０１に代って、端末対応サーバ４２０に対して配車依頼を発行する（ステップＳ２０１２）。端末対応サーバ４２０は、予約管理サーバ４３０から配車依頼を受信すると、受付処理して、注文元のユーザ又はユーザ端末１０１のアカウント情報の認証や、受信した配車依頼の情報の注文情報蓄積部４２３への格納などの処理を行う。そして、端末対応サーバ４２０は、基本配車管理サーバ４１０に対して配車依頼を送信する（ステップＳ２０１３）。図２０中のステップＳ２０１１～Ｓ２０１３は、図６に示した処理シーケンス上のステップＳ６０５～Ｓ６０７に対応する。

【0159】

基本配車管理サーバ４１０は、端末対応サーバ４２０から配車依頼を受信すると、受付処理して、例えば履歴情報管理部４１４に注文情報を格納する。そして、基本配車管理サーバ４１０は、配車処理部４１１は、受け取った配車依頼に対して、配車場所から所定圏内（半径２ｋｍ以内など）で、空車の車両を探車する（ステップＳ２０１４）。また、受け取った配車依頼に、車両や乗務員、タクシー会社などに関する条件が指定されている場合には、基本配車管理サーバ４１０は、指定された条件でさらにフィルタリングして探車する。そして、基本配車管理サーバ４１０は、配車場所から所定圏内で条件に合致する車両に対して配車指示を送信する（ステップＳ２０１５）。その際、基本配車管理サーバ４１０は、配車場所から所定圏内で条件に合致する車両に対し一斉に配車指示を送信するようにしてもよいし、配車場所から近い順に配車指示を送信するようにしてもよい。

【0160】

ドライバーズアプリを起動している乗務員端末１０２の画面には、配車依頼に関する情報を提示するための依頼情報画面が表示されている。乗務員端末１０２は、基本配車管理サーバ４１０から配車指示を受信すると、配車指示があったことを依頼情報画面上で通知する（ステップＳ２０１６）。また、車両を運転中の乗務員が気づき易くするために、鳴動により配車指示を通知するようにしてもよい。乗務員は、依頼情報画面上で配車指示の内容を確認して、配車可能であれば、依頼情報画面上で了解ボタンを押すなどして、配車応答する（ステップＳ２０１７）。

【0161】

基本配車管理サーバ４１０は、乗務員端末１０２からの配車応答を待機する（ステップＳ２０１８）。そして、乗務員端末１０２から配車応答を受け取ることができた場合には（ステップＳ２０１８のＹｅｓ）、乗務員端末１０２に対して、お客様名やお客様住所などの迎車に必要な情報をさらに送信する（ステップＳ２０１９）。乗務員端末１０２は、基本配車管理サーバ４１０から受信したお客様名やお客様住所などの情報を依頼情報画面に表示して、迎車に対応した処理を開始する（Ｓ２０２０）。カーナビゲーションを利用する場合には、乗務員端末１０２は配車場所までのナビゲーションを開始する。

【0162】

また、基本配車管理サーバ４１０は、乗務員端末１０２から配車応答を受信すると（ステップ２０１８のＹｅｓ）、端末対応サーバ４２０に対して、配車が確定したタクシーの情報、例えば車両情報（会社名、無線番号、ナンバープレート、車種、車色など）や乗務員の情報（名前や簡単なプロフィール、サムネイル画像など）を送信する（ステップＳ２０２１）。そして、端末対応サーバ４２０は、基本配車管理サーバ４１０から受け取ったタクシーの情報を、さらにユーザ端末１０１に伝達する（ステップＳ２０２２）。ユーザ端末１０１は、基本配車管理サーバ４１０から受信した配車が確定したタクシーの情報を画面に表示する（ステップＳ２０２３）。

【0163】

基本配車管理サーバ４１０は、ステップＳ２０２１において、探車時に適用したオプション条件やオプションを解除して探車されたタクシーであることなどの情報を含めて通知するようにしてもよい。この場合、ユーザ端末１０１は、ステップＳ２０２３において、探車時に適用したオプション条件やオプションを解除して探車されたタクシーであることなどの情報を併せて画面に表示するようにしてもよい。

【0164】

乗務員端末１０２は、迎車中すなわち配車場所に到着するまでの間は、迎車に対応した処理として、所定時間間隔（数秒～数十秒）で当該車両の位置情報を繰り返し基本配車管理サーバ４１０に伝達する（ステップＳ２０２４）。基本配車管理サーバ４１０は、乗務員端末１０２から受信した車両の位置情報を端末対応サーバ４２０に伝達し（ステップＳ２０２５）、端末対応サーバ４２０はさらに依頼元のユーザ端末１０１に伝達する（ステップＳ２０２６）。そして、ユーザ端末１０１は、車両の位置情報を受信する度に、画面上で迎車中のタクシーの位置情報を更新する（ステップＳ２０２７）。

【0165】

基本配車管理サーバ４１０は、最大の探車時間（例えば１０分間）が経過するまで、乗務員端末１０２からの配車応答を待機する（ステップＳ２０１８）。このとき、最大の探車時間のうち所定時間（例えば、前半の５分間）が経過するまでは（ステップＳ２０２８のＮｏ）、配車依頼で指定されたオプション条件を課したまま、探車を継続する。

【0166】

そして、基本配車管理サーバ４１０は、配車応答が得られないまま（ステップＳ２０１８のＮｏ）、オプション条件を課して探車を継続して、所定時間（例えば、前半の５分間）が経過すると（ステップＳ２０２８のＹｅｓ）、探車時間が終了するまでの期間（すなわち、探車時間の後半の５分間）は（ステップＳ２０２９のＮｏ）、オプション条件を外して（ステップＳ２０３０）、探車を継続する。このとき、基本配車管理サーバ４１０は、オプション条件を外して探車することを、端末対応サーバ４２０経由で、予約注文元のユーザ端末１０１に通知するようにしてもよい。また、ユーザ端末１０１は、基本配車管理サーバ４１０からの通知に基づいて、探車中に適用されているオプション条件の情報を画面に表示するようにしてもよい。

【0167】

その後、配車応答が得られないまま（ステップＳ２０１８のＮｏ）、探車時間が終了してしまうと（ステップＳ２０２９のＹｅｓ）、予約注文に対し、探車に失敗したという結果になる。この場合、基本配車管理サーバ４１０は、端末対応サーバ４２０に対して探車失敗通知を送信する（ステップＳ２０３１）。そして、端末対応サーバ４２０は、基本配車管理サーバ４１０から受け取った探車失敗通知を、さらにユーザ端末１０１に伝達する（ステップＳ２０３２）。ユーザ端末１０１は、探車失敗通知を画面に表示する（ステップＳ２０３３）。探車失敗通知は、予約配車の代替手段に関する情報を含んでいてもよい。また、ユーザ端末１０１は、「いますぐ呼ぶ」ボタンをタップして「即時配車」モード（配車依頼）に切り替えるか、又はコールセンターに直接電話してタクシーを注文するといった、代替手段をユーザに提示するようにしてもよい。

【0168】

なお、基本配車管理サーバ４１０において探車を継続している最中、すなわち探車時間が終了する前に、注文元のユーザ端末１０１から予約注文のキャンセルを受け取ることもある。この場合、基本配車管理サーバ４１０は、探車時間内に探車に失敗したときと同様に、探車失敗の通知を行うようにしてもよい。

【0169】

また、基本配車管理サーバ４１０は、探車に成功又は失敗したときなど、予約配車の注文に対する処理が完了したときに、探車の結果（成功又は失敗したか、注文がキャンセルされたか）、探車に適用したオプション条件、探車に要した時間などの履歴情報を履歴情報管理部４１４に保存する。

【0170】

図２１中のステップＳ２０１４～Ｓ２０３３は、図６に示した処理シーケンス上のステップＳ６０９～Ｓ６２２に対応する。特に、図６中のステップＳ６０９の基本配車管理サーバ４１０における「探車」処理は、図２１中のステップＳ２０１４～Ｓ２０１８、及びＳ２０２８～Ｓ２０３１に対応する。

【0171】

Ｄ．装置構成
図２２には、配車管理装置１０３に適用される情報処理装置２０００の構成例を示している。情報処理装置２０００は、基本配車管理サーバ４１０、端末対応サーバ４２０、予約管理サーバ４３０のサーバ機能毎に１台の情報処理装置２０００を適用するようにしてもよい。あるいは、１台の情報処理装置２０００が２以上のサーバ機能を実現するようにすることもできる。あるいは、１台の情報処理装置２０００が１つのサーバ機能のうちの１つの機能モジュール（例えば、基本配車管理サーバ４１０内の配所処理部４１１）を実現するようにしてもよい。

【0172】

図２２に示す情報処理装置２０００は、ＣＰＵ２００１と、ＲＯＭ２００２と、ＲＡＭ２００３と、ホストバス２００４と、ブリッジ２００５と、拡張バス２００６と、インターフェース部２００７と、入力部２００８と、出力部２００９と、ストレージ部２０１０と、ドライブ２０１１と、通信部２０１３を含んでいる。

【0173】

ＣＰＵ２００１は、演算処理装置及び制御装置として機能し、各種プログラムに従って情報処理装置２０００の動作全般を制御する。ＲＯＭ２００２は、ＣＰＵ２００１が使用するプログラム（基本入出力システムなど）や演算パラメータを不揮発的に格納している。ＲＡＭ２００３は、ＣＰＵ２００１の実行において使用するプログラムをロードしたり、プログラム実行において適宜変化する作業データなどのパラメータを一時的に格納したりするのに使用される。ＲＡＭ２００３にロードしてＣＰＵ２００１において実行するプログラムは、例えば各種アプリケーションプログラムやＯＳなどである。

【0174】

ＣＰＵ２００１とＲＯＭ２００２とＲＡＭ２００３は、ＣＰＵバスなどから構成されるホストバス２００４により相互に接続されている。そして、ＣＰＵ２００１は、ＲＯＭ２００２及びＲＡＭ２００３の協働的な動作により、ＯＳが提供する実行環境下で各種アプリケーションプログラムを実行して、さまざまな機能やサービスを実現することができる。また、アプリケーションプログラムには、基本配車管理サーバ４１０、端末対応サーバ４２０、予約管理サーバ４３０のうちいずれかのサーバ機能を実現するサーバアプリケーション、又はサーバ機能の一部を実現するアプリケーションが含まれるものとする。

【0175】

ホストバス２００４は、ブリッジ２００５を介して拡張バス２００６に接続されている。拡張バス２００６は、例えばＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス又はＰＣＩ Ｅｘｐｒｅｓｓであり、ブリッジ２００５はＰＣＩ規格に基づく。但し、情報処理装置２０００がホストバス２００４、ブリッジ２００５及び拡張バス２００６によって回路コンポーネントを分離される構成する必要はなく、単一のバス（図示しない）によってほぼすべての回路コンポーネントが相互接続される実装であってもよい。

【0176】

インターフェース部２００７は、拡張バス２００６の規格に則って、入力部２００８、出力部２００９、ストレージ部２０１０、ドライブ２０１１、及び通信部２０１３といった周辺装置を接続する。但し、図２２に示す周辺装置がすべて必須であるとは限らず、また図示しない周辺装置を情報処理装置２０００がさらに含んでもよい。また、周辺装置は情報処理装置２０００の本体に内蔵されていてもよいし、一部の周辺装置は情報処理装置２０００本体に外付け接続されていてもよい。

【0177】

入力部２００８は、ユーザからの入力に基づいて入力信号を生成し、ＣＰＵ２００１に出力する入力制御回路などから構成される。情報処理装置２０００がパーソナルコンピュータの場合、入力部２００８は、キーボードやマウス、タッチパネルを含んでもよく、さらにカメラやマイクを含んでもよい。また、出力部２００９は、例えば、液晶ディスプレイ（ＬＣＤ）装置、有機ＥＬディスプレイ装置、及びＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）などの表示装置や、プリンタ、スピーカなどを含む。

【0178】

ストレージ部２０１０は、ＣＰＵ２００１で実行されるプログラム（アプリケーション、ＯＳなど）や各種データなどのファイルを格納する。ストレージ部２０１０が格納するデータとして、ニューラルネットワークのトレーニングのための通常の音声及びささやき声のコーパス（前述）を含んでもよい。ストレージ部２０１０は、例えば、ＳＳＤやＨＤＤなどの大容量記憶装置で構成されるが、外付けの記憶装置を含んでもよい。

【0179】

リムーバブル記憶媒体２０１２は、例えばｍｉｃｒｏＳＤカードのようなカートリッジ式で構成される記憶媒体である。ドライブ２０１１は、装填したリムーバブル記憶媒体１１３に対して読み出し及び書き込み動作を行う。ドライブ２０１１は、リムーバブル記録媒体２０１２から読み出したデータをＲＡＭ２００３やストレージ部２０１０に出力したり、ＲＡＭ２００３やストレージ部２０１０上のデータをリムーバブル記録媒体２０１２に書き込んだりする。

【0180】

通信部２０１３は、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）や４Ｇや５Ｇなどのセルラー通信網などの無線通信を行うデバイスである。また、通信部２０１３は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やＨＤＭＩ（登録商標）（Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）などの端子を備え、スキャナやプリンタなどのＵＳＢデバイスやディスプレイなどとのＨＤＭＩ（登録商標）通信を行う機能をさらに備えていてもよい。

【産業上の利用可能性】

【0181】

以上、特定の実施形態を参照しながら、本開示について詳細に説明してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

【0182】

本明細書では、本開示をタクシーの配車管理に適用した実施形態を中心に説明してきたが、本開示の要旨はこれに限定されるものではない。本開示は、カーシェア又はレンタカー、引越や軽貨物の運送業者における配車管理にも同様に適用することができる。また、本開示は、車両以外のさまざまな物品及び商品の在庫管理にも適用することができる。

【0183】

要するに、例示という形態により本開示について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本開示の要旨を判断するためには、特許請求の範囲を参酌すべきである。

【0184】

なお、本開示は、以下のような構成をとることも可能である。

【0185】

（１）配車に関する注文を処理する情報処理システムであって、
所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部を備える、情報処理システム。

【0186】

（２）前記条件変更部は、前記探車時間内で前記探車部が車両を発見できるように、前記検索条件の変更を行う、
上記（１）に記載の情報処理システム。

【0187】

（３）前記条件変更部は、探車を開始して所定期間内に前記検索条件付きで前記探車部が車両を発見できないときに、前記検索条件の変更を行い、
前記探車部は、探車を開始して所定期間経過後から前記探車時間の終了までの期間は、前記条件変更部により変更した後の検索条件に基づいて車両検索を継続する、
上記（１）又は（２）のいずれかに記載の情報処理システム。

【0188】

（４）前記条件変更部は、前記検索条件の変更として、検索条件の除外、又は複数の検索条件のうち少なくとも一部の除外を行う、
上記（１）乃至（３）のいずれか１つに記載の情報処理システム。

【0189】

（５）前記検索条件は、前記注文に含まれる、
上記（１）乃至（４）のいずれか１つに記載の情報処理システム。

【0190】

（６）前記検索条件は、希望車種、車両を配車する会社、車両の乗務員のうち少なくとも１つに関する条件を含む、
上記（１）乃至（５）のいずれか１つの記載の情報処理システム。

【0191】

（７）前記検索条件は複数の条件を含み、且つ各条件の優先順位が指定されており、
前記条件変更部は、優先順位に基づいて、時間の経過に応じた前記検索条件の変更を行う、
上記（１）乃至（６）のいずれか１つに記載の情報処理システム。

【0192】

（８）前記探車時間を設定する探車時間設定部をさらに備える、
上記（１）乃至（７）のいずれか１つに記載の情報処理システム。

【0193】

（９）前記探車時間設定部は、配車方法、注文者の種別、注文者の指定、配車日時における天候、配車場所、配車場所の周囲のイベントの開催、又は前記所定圏内の空車台数（車両の検索し易さ）のうち少なくともいずれか１つに基づいて、前記探車時間を設定する、
上記（８）に記載の情報処理システム。

【0194】

（１０）前記探車時間設定部は、注文者が指定する探車時間の長さに応じた課金を行う、
上記（９）に記載の情報処理システム。

【0195】

（１１）車両検索の経過に関する情報又は車両検索の結果に関する情報のうち少なくとも一方を外部に通知する通知部をさらに備える、
上記（１）乃至（１０）のいずれか１つに記載の情報処理システム。

【0196】

（１２）前記通知部は、前記探車部が車両検索中に、前記条件変更部が変更した前記検索条件に関する情報を通知する、
上記（１１）に記載の情報処理システム。

【0197】

（１３）前記通知部は、配車することが決まった車両の情報とともに、前記条件変更部による前記検索条件の変更の有無又は変更した前記検索条件に関する情報を通知する、
上記（１１）又は（１２）のいずれか１つに記載の情報処理システム。

【0198】

（１４）前記通知部は、前記探車部が車両検索中に、前記所定圏内で前記検索条件に合致する車両に関する情報を通知する、
上記（１１）乃至（１３）のいずれか１つに記載の情報処理システム。

【0199】

（１５）前記通知部は、前記探車部による探車失敗を、代替手段に関する情報を含めて通知する、
上記（１１）乃至（１４）のいずれか１つに記載の情報処理システム。

【0200】

（１６）前記配車処理部は、前記探車部による車両検索を継続中に前記注文がキャンセルされたことに応じて、車両検索を終了させる、
上記（１）乃至（１５）のいずれか１つに記載の情報処理システム。

【0201】

（１７）前記配車処理部は、前記注文に対する処理が完了したときに、探車の結果（成功又は失敗したか、注文がキャンセルされたか）、探車に適用した条件、探車に要した時間のうち少なくとも１つを含む履歴情報を保存する、
上記（１）乃至（１６）のいずれか１つに記載の情報処理システム。

【0202】

（１８）配車に関する注文を処理する情報方法であって、
所定圏内で検索条件を満たす車両を検索する探車ステップと、時間の経過に応じて前記検索条件を変更する条件変更ステップを有し、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する、情報処理方法。

【0203】

（１９）所定圏内で検索条件を満たす車両を検索する探車部と、時間の経過に応じて前記検索条件を変更する条件変更部を含み、所定の探車時間内で時間の経過に応じて変更した検索条件で車両の検索を継続する配車処理部としてコンピュータが機能するように、コンピュータ可読形式で記述されたコンピュータプログラム。

【符号の説明】

【0204】

１００…配車システム、１０１…ユーザ端末、１０２…乗務員端末
１０３…配車管理装置
２１０…通信部、２２０…記憶部、２３０…制御部
２３１…配車要求部、２３２…通知取得部、２３３…表示制御部
２４０…表示部、２５０…操作部、２６０…位置検出部
３１０…通信部、３２０…記憶部、３３０…制御部
３３１…情報取得部、３３２…表示制御部
３４０…表示部、３５０…操作部、３６０…位置検出部
４１０…基本配車管理サーバ、４１１…配車処理部
４１２…変更通知処理部、４１３…決済処理部
４１４…履歴情報管理部、４１５…マスタ登録情報管理部
４２０…端末対応サーバ、４２１…配車依頼処理部
４２２…アカウント管理部、４２３…注文情報蓄積部
４２４…アカウント情報蓄積部
４３０…予約管理サーバ、４３１…注文受付処理部
４３２…配車依頼発行部、４３３…予約注文情報蓄積部
４４０…決済代行システム、４４１…決済処理部
４４２…決済情報蓄積部、４４３…管理画面（コンソール）
４５０…運行管理システム、４５１…管理画面（コンソール）
２０００…情報処理装置、２００１…ＣＰＵ、２００２…ＲＯＭ
２００３…ＲＡＭ、２００４…ホストバス、２００５…ブリッジ
２００６…拡張バス、２００７…インターフェース部
２００８…入力部、、２００９…出力部、２０１０…ストレージ部
２０１１…ドライブ、２０１２…リムーバブル記録媒体
２０１３…通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】