特許 7528844 情報処理装置、及び、情報処理方法

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

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

(11)【特許番号】

(24)【登録日】2024-07-29

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

(54)【発明の名称】情報処理装置、及び、情報処理方法

(51)【国際特許分類】

   G06Q 50/40 20240101AFI20240730BHJP

【ＦＩ】

G06Q50/40

【請求項の数】 18

(21)【出願番号】P 2021058246

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

(65)【公開番号】P2022154967

(43)【公開日】2022-10-13

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

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

前記通信部を通じて、前記第１の店舗へ、前記第１の車両についての前記点検又は前記整備の予約を行うことと、
前記第１のスケジュールについて、前記第１の店舗の周辺で発生が予測される前記配車サービスへの需要に変化がある場合に、前記第１の車両が、前記第１の店舗において前記点検又は前記整備を終えて、前記変化後の需要の発生が予測される場所に前記変化後の需要の発生が予測される日時に到着するように、前記通信部を通じて、前記第１の店舗へ、前記第１の車両についての前記点検又は前記整備の実施順の調整を依頼することと、
をさらに含む、
請求項１０から１５のいずれか一項に記載の情報処理方法。

【請求項17】

前記第１のスケジュールにおいて前記点検又は前記整備の終了予定日時が、前記変化後の前記需要の発生が予測される日時よりも第１の時間長以上前である場合には、前記通信部を通じて、前記第１の車両の前記点検又は前記整備の実施順についての優先度を下げる許可の通知を前記第１の店舗へ送信する、
請求項１６に記載の情報処理方法。

【請求項18】

前記第１のスケジュールにおいて前記点検又は前記整備の終了予定日時が、前記変化後の前記需要の発生が予測される日時以降である場合には、前記通信部を通じて、前記第１の車両の前記点検又は前記整備の実施順についての優先度を上げる指示を前記第１の店舗へ送信する、
請求項１６又は１７に記載の情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、情報処理装置、及び、情報処理方法に関する。

【背景技術】

【0002】

車両の点検或いは整備時に、当該車両における点検整備時の走行距離等を含む車両情報を受け付け、車両情報と、点検整備を実施するまでの走行距離や時間数等とから、点検整備実施予定日を算出して、ユーザに通知して入庫を促す技術が開示されている（例えば、特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００３－１８７０１１号公報

【発明の概要】

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

【0004】

開示の態様の一つは、配車サービスに使用される車両の点検又は整備によって配車サービスが行えない時間を短縮可能な情報処理装置、及び、情報処理方法を提供することを課題とする。

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

【0005】

本開示の態様の一つは、
配車サービスへの需要の発生が予測される第１の場所を取得することと、
前記配車サービスに用いられる第１の車両が、前記第１の場所の周辺に位置する、前記第１の車両の点検又は整備を実施可能な第１の店舗において前記点検又は前記整備を終えて前記第１の場所に前記配車サービスへの需要の発生が予測される日時に到着するように、前記第１の車両についての前記点検又は前記整備の第１のスケジュールを作成することと、
を実行する制御部、
を備える情報処理装置である。

【0006】

本開示の他の態様の一つは、
配車サービスへの需要の発生が予測される第１の場所を取得することと、
前記配車サービスに用いられる第１の車両が、前記第１の場所の周辺に位置する、前記第１の車両の点検又は整備を実施可能な第１の店舗において前記点検又は前記整備を終えて前記第１の場所に前記配車サービスへの需要の発生が予測される日時に到着するように、前記第１の車両についての前記点検又は前記整備の第１のスケジュールを作成することと、
を含む情報処理方法である。

【発明の効果】

【0007】

本開示によれば、配車サービスに使用される車両の点検又は整備によって配車サービスが行えない時間を短縮することができる。

【図面の簡単な説明】

【0008】

【図1】図１は、第１実施形態に係るメンテナンススケジューリングシステムのシステム構成の一例を示す図である。

【図2】図２は、センタサーバのハードウェア構成の一例を示す図である。

【図3】図３は、センタサーバ及び配車制御サーバの機能構成の一例を示す図である。

【図4】図４は、車両情報データベースに保持される情報の一例である。

【図5】図５は、店舗情報データベースに保持されている情報の一例である。

【図6】図６は、メンテナンスメニューテーブルの一例である。

【図7】図７は、配車予約情報データベースに保持される情報の一例である。

【図8】図８は、メンテナンススケジュール情報データベースに保持される情報の一例である。

【図9】図９は、センタサーバのメンテナンススケジュール作成処理のフローチャートの一例である。

【図10】図１０は、センタサーバの目的地決定処理のフローチャートの一例である。

【図11】図１１は、センタサーバのスケジュール管理処理のフローチャートの一例である。

【図12】図１２は、第２実施形態に係るメンテナンススケジューリングシステムのシステム構成の一例を示す図である。

【図13】図１３は、第３実施形態に係るメンテナンススケジューリングシステムのシステム構成の一例を示す図である。

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

【0009】

タクシー及びライドシェア等の配車サービスに用いられる車両は、例えば、点検又は整備等によって車両の稼働時間が削られると、その分、営業機会を損失することになる。一方、車両の点検及び整備は、安全な走行のために必要なものである。配車サービスの運転手は、車両の点検又は整備による営業機会損失の時間を短く抑えたいという要望がある。ここで、車両の点検又は整備の予約の開始時刻までは、配車サービスの運転手の裁量によって営業機会の損失を抑えることが可能であるが、車両の点検又は整備後は未来のことであるため、運転手の裁量では営業機会の損失を抑えることは困難である。

【0010】

本開示の態様の一つは、配車サービスに用いられる車両の点検又は整備後の営業機会の損失を抑えるために、情報処理装置が以下のように構成される。具体的には、当該情報処理装置は、配車サービスへの需要の発生が予測される第１の場所を取得することと、配車サービスに用いられる第１の車両が、第１の場所の周辺に位置する、第１の車両の点検又は整備を実施可能な第１の店舗において点検又は整備を終えて第１の場所に配車サービスへの需要の発生が予測される日時に到着するように、第１の車両についての点検又は整備の第１のスケジュールを作成することと、を実行する制御部を備える。

【0011】

情報処理装置は、例えば、サーバ等のコンピュータである。制御部は、例えば、コンピュータに備えられるプロセッサである。第１の車両は、配車サービスに用いられる車両である。第１の車両は、運転手によって運転される自動車であってもよいし、無人で自動走行可能な自動車であってもよい。配車サービスへの需要の発生が予測される場所には、例えば、配車サービスの予約の乗車場所、集客を伴うイベントの開催地、事故及び悪天候時の鉄道の駅、及び、配車サービスの過去の予約履歴に基づいて需要の発生が予測される場所等がある。第１の車両の点検又は整備を実施可能な第１の店舗とは、例えば、第１の車両の点検又は整備のメニューに対応する設備又は整備士等が配置されている店舗である。

【0012】

本開示の態様の一つによれば、配車サービスに対する需要の発生が予測される場所の周辺に位置する第１の店舗において、第１の車両の点検又は整備が実施される。また、第１の車両の点検又は整備のスケジュールは、第１の車両が、第１の店舗において点検又は整備を終えて、配車サービスに対する需要の発生が予測される日時に、当該需要の発生が予測される第１の場所に到着するように、作成される。これによって、第１の車両は、第１
の店舗における点検又は整備の終了後、第１の場所へ向かうことによって、配車サービスの乗客を捕まえる可能性が高くなり、より早く配車サービスを再開することができる。

【0013】

本開示の態様の一つにおいて、制御部は、配車サービスへの需要の発生が予測される複数の場所のそれぞれについて、需要の大きさを示す値の予測値を取得し、当該複数の場所のうち、予測値が最も大きい場所を第１の場所として決定し、第１の場所の周辺に、第１の車両の点検又は整備を実施可能な店舗が複数存在する場合には、当該複数の店舗のうち、第１の場所に最も近い店舗を第１の店舗として決定するようにしてもよい。配車サービスへの需要の大きさを示す値の予測値は、例えば、需要の種類と、配車サービスを要求するユーザ数、又は、配車サービスが要求される車両数等と、に基づいて求められる値である。本開示の態様の一つによれば、第１の店舗における点検又は整備終了後に、第１の車両が配車サービスへの需要の大きさを示す予測値が最も大きい第１の場所へ向かうことによって、乗客を捕まえる可能性をより高めることができる。

【0014】

本開示の態様の一つにおいて、制御部は、配車サービスへの需要の発生が予測される場所を複数取得し、且つ、複数の場所の周辺に第１の車両の点検又は整備を実施可能な店舗が複数存在する場合には、互いの距離が最も近い場所と店舗とを、それぞれ、第１の場所と第１の店舗に決定するようにしてもよい。本開示の態様の一つによれば、第１の車両は、第１の店舗における点検又は整備の終了後、より早く配車サービスへの需要の発生が予測される場所へ到着することができ、営業損失の時間をより短く抑えることができる。

【0015】

本開示の態様の一つにおいて、制御部は、配車サービスへの需要の発生が予測される場所を複数取得し、且つ、複数の場所の周辺に第１の車両の点検又は整備を実施可能な店舗が複数存在する場合には、複数の場所のうちの一つの場所と複数の店舗のうちの一つの店舗とのすべての組み合わせについて、所定の地点から当該一つの店舗への移動にかかる第１の時間長と、当該一つの店舗において点検又は整備にかかる第２時間長と、当該一つの店舗から当該一つの場所までの移動にかかる第３の時間長と、の合計時間長が最も小さくなる組み合わせに含まれる、場所と店舗とを、それぞれ、第１の場所と第１の店舗に決定するようにしてもよい。本開示の態様の一つによれば、第１の車両は、所定の地点から第１の店舗へ移動し、第１の店舗において点検又は整備を受け、第１の店舗から第１の場所へ移動する合計時間長が短くなるので、営業損失の時間をより短く抑えることができる。

【0016】

本開示の態様の一つにおいて、第１の店舗へ、第１の車両についての点検又は整備の予約を行うことと、第１のスケジュールについて、第１の店舗の周辺で発生が予測される配車サービスへの需要に変化がある場合に、第１の車両が、第１の店舗において点検又は整備を終えて、変化後の需要の発生が予測される場所に変化後の需要の発生が予測される日時に到着するように、第１の店舗へ、第１の車両についての点検又は整備の実施順の調整を依頼することと、をさらに実行するようにしてもよい。例えば、制御部は、第１のスケジュールにおいて点検又は整備の終了予定日時が、変化後の需要の発生が予測される日時よりも第１の時間長以上前である場合には、第１の車両の点検又は整備の実施順についての優先度を下げる許可の通知を第１の店舗へ送信するようにしてもよい。例えば、制御部は、第１のスケジュールにおいて点検又は整備の終了予定日時が、変化後の需要の発生が予測される日時以降である場合には、第１の車両の点検又は整備の実施順についての優先度を上げる指示を第１の店舗へ送信するようにしてもよい。

【0017】

本開示の態様の一つによれば、予測される配車サービスへの需要の変化に応じて、第１の車両の点検又は整備を実施する第１の店舗では、車両の点検又は整備の実施順を変更することができるようになる。これによって、例えば、第１の車両の点検又は整備の終了予定日時と変化後の需要の発生が予測される日時との間に十分に余裕がある場合には、第１の店舗では、第１の車両の点検又は整備の優先度を下げて、第１の車両の点検又は整備の
前に、第１の車両よりも優先度の高い他の車両の点検又は整備を実行することができる。これによって、第１の店舗では、空き時間が短くなるように車両の点検又は整備を実施することができる。反対に、例えば、第１の車両の点検又は整備の終了予定日時が変化後の需要の発生が予測される日時以降の日時となる場合には、第１の車両の点検又は整備の優先度を上げることによって、第１の店舗における第１の車両の点検又は整備の実施順が早まる。これによって、第１の車両が、変化後の需要の発生が予測される日時に、変化後の需要の発生が予測される場所に到着することができ、第１の車両が配車サービスの営業機会を損失することを抑制することができる。

【0018】

本開示の他の態様の一つとして、情報処理装置が上記処理を実行する情報処理方法として特定することも可能である。すなわち、当該情報処理方法は、配車サービスへの需要の発生が予測される第１の場所を取得することと、配車サービスに用いられる第１の車両が、第１の場所の周辺に位置する、第１の車両の点検又は整備を実施可能な第１の店舗において点検又は整備を終えて第１の場所に配車サービスへの需要の発生が予測される日時に到着するように、第１の車両についての点検又は整備の第１のスケジュールを作成することと、を含む。

【0019】

また、本開示の他の態様として、コンピュータに上述の情報処理方法の処理を実行させるためのプログラム、及び、当該プログラムを記憶した非一時的なコンピュータ読み取り可能な記録媒体としても特定することができる。

【0020】

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

【0021】

＜第１実施形態＞
図１は、第１実施形態に係るメンテナンススケジューリングシステム１００のシステム構成の一例を示す図である。メンテナンススケジューリングシステム１００は、車両の点検又は整備のスケジューリングを行うシステムである。第１実施形態では、メンテナンススケジューリングシステム１００は、配車サービスに利用されている車両を対象としてサービスを提供するものとする。

【0022】

メンテナンススケジューリングシステム１００は、センタサーバ１、配車制御サーバ２、店舗サーバ３、及び、車載器５を含む。店舗サーバ３及び車載器５は、複数含まれるが、図１では、それぞれ１台ずつ抽出されて示されている。配車制御サーバ２も複数含まれてもよいが、第１実施形態では、１台のみ含まれるものとする。センタサーバ１、配車制御サーバ２、店舗サーバ３、及び、車載器５は、ネットワークＮ１に接続しており、ネットワークＮ１を通じて互いに通信可能である。

【0023】

センタサーバ１は、例えば、車両５０の製造業者のサーバであり、車両５０に搭載されている車載器５から車両５０の走行状態を示す情報を定期的に受信することで、車両５０の走行状態を監視している。車両の走行状態を示す情報を、以下、走行状態情報と称する。走行状態情報には、例えば、車両５０の、識別情報、位置情報、走行距離、及び、各部品の状態を示す情報等が含まれている。部品の状態を示す情報は、例えば、部品の摩耗の程度を示す情報、及び、故障しているか否かを示す情報等が含まれる。

【0024】

店舗サーバ３は、車両５０の製造業者のディーラ、又は、製造業者と業務提携している自動車点検整備業者等の店舗のサーバである。以下、店舗と称する場合には、車両の点検又は整備を行う店舗を示すこととする。

【0025】

センタサーバ１は、各店舗に設置されている店舗サーバ３と通信を行い、各店舗におけ
る設備及び点検又は整備のスケジュール情報を把握している。配車制御サーバ２は、配車サービスを提供する業者のサーバである。配車制御サーバ２は、配車サービスの運転手として登録しているユーザのユーザ端末４と通信を行い、配車の要求が発生した場合に当該ユーザ端末４へ指定された乗客の乗車場所への移動指示を送信する。

【0026】

点検又は整備のために車両が店舗へ入ることは、入庫、と称される。入庫には、例えば、所定のタイミングで実施される定期入庫と、異常の発生に応じて実施される緊急入庫とがある。第１実施形態では、センタサーバ１は、車載器５からの走行状態情報に基づいて、車両５０の定期入庫又は緊急入庫の実施を判定する。以降、点検及び整備をまとめて、メンテナンスと称する。

【0027】

センタサーバ１は、車両５０の定期入庫又は緊急入庫の実施を判定すると、メンテナンス予定日時を走行状態情報に基づいて取得する。センタサーバ１は、所定範囲内に存在する店舗の中から、車両５０のメンテナンスを実施可能な店舗を抽出する。店舗の抽出範囲は、例えば、所定の地点から所定の距離の範囲、又は、予め定義されたエリアのうちの出発地点と同じエリア等である。また、メンテナンスを実施可能な店舗とは、車両５０の設備及び性能に応じたメンテナンスの設備や整備士を備えており、且つ、メンテナンス予定日時にスケジュールが空いている店舗である。

【0028】

次に、センタサーバ１は、車両５０のメンテナンス予定日時以降に、所定範囲内の配車サービスに対する需要の発生が予測される場所を取得する。当該需要の発生が予測される場所の抽出範囲は、例えば、先に抽出された店舗から所定の範囲であってもよいし、店舗の抽出範囲と同じであってもよいし、店舗の抽出範囲を含んだより広い範囲に設定されてもよい。配車サービスに対する需要には、例えば、配車サービスの予約があること、集客して行われるイベントがあること、又は、悪天候や工事等がある。配車サービスに対する需要のある地点には、例えば、配車サービスの予約の乗客の乗車場所、イベントの開催場所、又は、公共交通機関の駅等がある。配車サービスに対する需要が高いとは、例えば、配車サービスへの需要の大きさを示す値の予測値が所定値以上であることである。配車サービスへの需要を示す値は、例えば、需要の種類と、配車サービスを要求するユーザ数、又は、入ササービスが要求される車両数と、に基づいて取得される。ただし、配車サービスへの需要を示す値は、これらに限定されない。以降、配車サービスへの需要を示す値の予測値は、需要の予測値、と称される。

【0029】

センタサーバ１は、所定範囲内の配車サービスに対する需要の発生が予測される場所の中から、需要の予測値及び店舗との距離等に基づいて、車両５０のメンテナンスのスケジュールの目的地と車両５０のメンテナンスを実施する店舗とを決定する。第１実施形態では、センタサーバ１は、配車サービスに対する需要が最も大きい場所を目的地ｙとし、当該目的地に最も近い店舗ｘを車両５０のメンテナンスを実施する店舗として、目的地ｙにおいて配車サービスへの需要が高まる日時に間に合うように、当該店舗ｘへ車両５０のメンテナンスを予約する。また、センタサーバ１は、当該車両５０について店舗ｘにおいてメンテナンスを受け、その後目的地ｙへ向かう内容のスケジュールを作成し、配車制御サーバ２を通じて車両５０の運転手のユーザ端末４へ当該スケジュールを通知する。車両５０は、「第１の車両」の一例である。車両５０のメンテナンスのスケジュールの目的地は、「第１の場所」の一例である。車両５０のメンテナンスを実施する店舗は、「第１の店舗」の一例である。

【0030】

第１実施形態によれば、センタサーバ１は、車両５０のメンテナンスのスケジュールを、目的地ｙにおいて配車サービスの需要が高まる時刻に間に合うように、店舗ｘでメンテナンスを受けるスケジュールを作成する。これによって、配車サービスに使用される車両５０は、メンテナンス後により早く配車サービスの乗客を捕まえる可能性が高くなり、車
両のメンテナンスによる営業機会の損失を低減することができる。

【0031】

図２は、センタサーバ１のハードウェア構成の一例を示す図である。センタサーバ１は、例えば、サーバ等の専用のコンピュータ、又は、ＰＣ（Personal Computer）等の汎用のコンピュータである。センタサーバ１は、ハードウェア構成として、ＣＰＵ（Central Processing Unit）１０１、メモリ１０２、外部記憶装置１０３、入力部１０４、出力部
１０５、及び、通信部１０６を有する。メモリ１０２および外部記憶装置１０３は、コンピュータで読み取り可能な記録媒体である。

【0032】

外部記憶装置１０３は、様々なプログラムや、各プログラムの実行に際してＣＰＵ １０１が使用するデータを格納する。外部記憶装置１０３は、例えば、ＥＰＲＯＭ（Erasable Programmable ROM）やハードディスクドライブ（Hard Disk Drive）である。外部記憶装置１０３に保持されるプログラムには、例えば、オペレーティングシステム（ＯＳ）、メンテナンススケジューリングシステム１００の制御プログラム、その他様々なアプリケーションプログラムを保持する。

【0033】

メモリ１０２は、ＣＰＵ １０１に、外部記憶装置１０３に格納されているプログラムをロードする記憶領域および作業領域を提供したり、バッファとして用いられたりする記憶装置である。メモリ１０２は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random
Access Memory）のような半導体メモリを含む。

【0034】

ＣＰＵ １０１は、外部記憶装置１０３に保持されたＯＳや様々なアプリケーションプログラムをメモリ１０２にロードして実行することによって、様々な処理を実行する。ＣＰＵ １０１は、１つに限られず、複数備えられてもよい。ＣＰＵ １０１は、「制御部」の一例である。

【0035】

入力部１０４は、例えば、キーボード、又は、マウス等のポインティングデバイス等の入力装置である。入力部１０４から入力された信号は、ＣＰＵ １０１へ出力される。出力部１０５は、ディスプレイ、及び、プリンタ等の出力装置である。出力部１０５は、ＣＰＵ １０１からの信号の入力に応じて情報を出力する。なお、入力部１０４及び出力部１０５は、それぞれ、音声の入力装置及び出力装置であってもよい。

【0036】

通信部１０６は、ネットワークとの情報の入出力を行うインタフェースである。通信部１０６は、有線のネットワークと接続するインタフェースであってもよいし、無線のネットワークと接続するインタフェースであってもよい。通信部１０６は、例えば、ＮＩＣ（Network Interface Card）や無線回路等である。なお、センタサーバ１のハードウェア構成は、図２に示されるものに限定されない。なお、配車制御サーバ２もセンタサーバ１と同様に、ＣＰＵ、メモリ、外部記憶装置、入力部、出力部、及び、通信部を備えたハードウェア構成である。

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

１・・センタサーバ
２・・配車制御サーバ
３・・店舗サーバ
４・・ユーザ端末
５・・車載器
１１・・制御部
１２・・位置推定部
１３・・車両通信部
１４・・サーバ通信部
１５・・車両情報データベース
１６・・店舗情報データベース
１７・・配車予約情報データベース
１８・・メンテナンススケジュール情報データベース
２１・・配車予約情報データベース
２２・・ユーザ情報データベース
５０・・車両
１００・・メンテナンススケジューリングシステム
１０１・・ＣＰＵ
１０２・・メモリ
１０３・・外部記憶装置
１０４・・入力部
１０５・・出力部
１０６・・通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】