(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023005511
(43)【公開日】2023-01-18
(54)【発明の名称】情報処理装置、情報処理方法、および、プログラム
(51)【国際特許分類】
G06Q 10/20 20230101AFI20230111BHJP
【FI】
G06Q10/00 300
【審査請求】未請求
【請求項の数】20
【出願形態】OL
(21)【出願番号】P 2021107485
(22)【出願日】2021-06-29
(71)【出願人】
【識別番号】000003207
【氏名又は名称】トヨタ自動車株式会社
(71)【出願人】
【識別番号】520123032
【氏名又は名称】株式会社KINTO
(74)【代理人】
【識別番号】110002860
【氏名又は名称】弁理士法人秀和特許事務所
(72)【発明者】
【氏名】利根 優太
(72)【発明者】
【氏名】飯 潔倫
(72)【発明者】
【氏名】田中 唯之
(72)【発明者】
【氏名】石塚 真規
(72)【発明者】
【氏名】矢野 佑一郎
(72)【発明者】
【氏名】天野 成章
(72)【発明者】
【氏名】前田 優介
(72)【発明者】
【氏名】矢崎 圭
(72)【発明者】
【氏名】濱田 優
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC15
(57)【要約】
【課題】車両に対する作業を効率化する。
【解決手段】情報処理装置が、第一の車両に対して実施する作業の内容を表す作業情報を取得し、実施可能な作業の内容を、複数の拠点のそれぞれと関連付けた第一のデータに基づいて、前記作業情報が示す作業が実施可能な第一の拠点を決定する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
第一の車両に対して実施する作業の内容を示す作業情報を取得することと、
実施可能な作業の内容を、複数の拠点のそれぞれと関連付けた第一のデータに基づいて、前記作業情報が示す作業が実施可能な第一の拠点を決定することと、
を実行する制御部を有する、情報処理装置。
【請求項2】
前記制御部は、前記作業情報を含むリクエストを取得した場合に、前記第一のデータから、前記第一の車両に対して指定された作業が可能な前記第一の拠点を抽出する、
請求項1に記載の情報処理装置。
【請求項3】
前記リクエストは、前記第一の車両を特定するための車両情報をさらに含む、
請求項2に記載の情報処理装置。
【請求項4】
前記第一のデータは、所定の属性を持つ車両について実施可能な作業の内容を、複数の拠点のそれぞれと関連付けたデータであり、
前記制御部は、前記車両情報をさらに用いて、前記第一のデータから前記第一の拠点を抽出する、
請求項3に記載の情報処理装置。
【請求項5】
前記車両情報は、前記第一の車両のモデルおよび年式に関するデータを含む、
請求項4に記載の情報処理装置。
【請求項6】
前記制御部は、前記第一の車両に現に装備されている装備品に関する情報をさらに取得し、
前記装備品に基づいて、前記第一の車両に対して指定された作業が可能か否かをさらに判定する、
請求項3から5のいずれか1項に記載の情報処理装置。
【請求項7】
前記制御部は、前記装備品の有無と、前記複数の拠点における作業の実施可否とを関連付けた第二のデータに基づいて、前記判定を行う、
請求項6に記載の情報処理装置。
【請求項8】
前記作業情報が示す作業の内容は、車両コンポーネントの追加または交換を含む、
請求項1から7のいずれか1項に記載の情報処理装置。
【請求項9】
前記作業情報が示す作業の内容が、安全装備の追加である場合に、
前記制御部は、前記第一の車両のメーカーと関連のある前記第一の拠点を決定する、
請求項1から8のいずれか1項に記載の情報処理装置。
【請求項10】
前記制御部は、前記第一の車両の受け渡しを行う第二の拠点をさらに決定する、
請求項1から9のいずれか1項に記載の情報処理装置。
【請求項11】
前記第二の拠点は、前記第一の車両の販売拠点を含む、
請求項10に記載の情報処理装置。
【請求項12】
前記制御部は、前記第一の拠点と前記第二の拠点との間の、前記第一の車両の回送コストを考慮して、前記第一の拠点と前記第二の拠点の組み合わせを決定する、
請求項11に記載の情報処理装置。
【請求項13】
前記第一の車両に対して実施する作業が可能な前記第一の拠点が複数ある場合に、
前記制御部は、対象の作業にかかるコストを、前記第一の拠点ごとに算出する、
請求項1から12のいずれか1項に記載の情報処理装置。
【請求項14】
前記制御部は、前記決定した第一の拠点を予約する予約データを生成する、
請求項1から13のいずれか1項に記載の情報処理装置。
【請求項15】
前記予約データは、前記第一の拠点に関する情報、対象車両に関する情報、および、前記作業の内容を含む、
請求項14に記載の情報処理装置。
【請求項16】
第一の車両に対して実施する作業の内容を示す作業情報を取得するステップと、
実施可能な作業の内容を、複数の拠点のそれぞれと関連付けた第一のデータに基づいて、前記作業情報が示す作業が実施可能な第一の拠点を決定するステップと、
を含む、情報処理方法。
【請求項17】
前記第一の車両の車両情報と、前記作業情報と、を含むリクエストを取得した場合に、前記第一のデータから、前記第一の車両に対して指定された作業が可能な前記第一の拠点を抽出する、
請求項16に記載の情報処理方法。
【請求項18】
前記第一のデータは、所定の属性を持つ車両について実施可能な作業の内容を、複数の拠点のそれぞれと関連付けたデータであり、
前記リクエストに含まれる前記車両情報をさらに用いて、前記第一のデータから前記第一の拠点を抽出する、
請求項17に記載の情報処理方法。
【請求項19】
前記車両情報は、前記第一の車両のモデルおよび年式に関するデータを含む、
請求項18に記載の情報処理方法。
【請求項20】
請求項16から19のいずれか1項に記載の情報処理方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、車両の整備に関する。
【背景技術】
【0002】
自動車のメンテナンスをサポートするためのシステムが知られている。これに関連する発明として、例えば、特許文献1には、車両の点検整備を行う担当者を適切に割り当てる予約点検システムに関する発明が開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
本開示は、車両に対する作業を効率化することを目的とする。
【課題を解決するための手段】
【0005】
本開示の第一の態様は、第一の車両に対して実施する作業の内容を示す作業情報を取得することと、実施可能な作業の内容を、複数の拠点のそれぞれと関連付けた第一のデータに基づいて、前記作業情報が示す作業が実施可能な第一の拠点を決定することと、を実行する制御部を有する、情報処理装置である。
【0006】
また、本開示の第二の態様は、第一の車両に対して実施する作業の内容を示す作業情報を取得するステップと、実施可能な作業の内容を、複数の拠点のそれぞれと関連付けた第一のデータに基づいて、前記作業情報が示す作業が実施可能な第一の拠点を決定するステップと、を含む、情報処理方法である。
【0007】
また、本開示の他の態様は、上記の情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体である。
【発明の効果】
【0008】
本開示によれば、車両に対する作業を効率化することができる。
【図面の簡単な説明】
【0009】
【
図2】予約サーバ、拠点サーバ、およびユーザ端末の構成を説明する図。
【
図3B】予約サーバに記憶される空き状況データの例。
【
図3C】予約サーバに記憶される装備品データの例。
【
図8】ユーザ端末によって生成される入庫リクエストの例。
【
図9】ステップS23において実行される処理のフローチャート。
【
図10】ユーザ端末に送信される整備拠点のリストの例。
【
図11】予約サーバによって生成される予約データの例。
【
図12】第二の実施形態における予約サーバの構成を説明する図。
【
図14】第二の実施形態における装備品データの例。
【
図15】第二の実施形態におけるステップS23の処理フローチャート。
【
図17】第三の実施形態におけるステップS23の処理フローチャート。
【
図18】第三の実施形態におけるコストデータの例。
【
図19】第三の実施形態においてユーザ端末に送信される整備拠点のリストの例。
【発明を実施するための形態】
【0010】
近年の車両機能の向上に伴い、車両が有する設備や機能を事後的にアップグレードできるシステムが検討されている。例えば、新車購入時に装備されていなかった安全装備を事後的に追加することが可能になりつつある。
【0011】
一方、アップグレード対象のコンポーネントによっては、作業を行える拠点が限定されてしまうことがある。例えば、車両の走行システムに深く関連するコンポーネントは、メーカーが認証した工場でしか扱いが許可されないといったことがあり得る。
すなわち、対象のコンポーネントによっては、作業が可能な拠点とそうでない拠点が混在することによる混乱が生じてしまうおそれがある。
本開示に係る情報処理装置は、かかる問題を解決する。
【0012】
本開示の第一の態様に係る情報処理装置は、第一の車両に対して実施する作業の内容を示す作業情報を取得することと、実施可能な作業の内容を、複数の拠点のそれぞれと関連付けた第一のデータに基づいて、前記作業情報が示す作業が実施可能な第一の拠点を決定することと、を実行する制御部を有することを特徴とする。
【0013】
第一の車両に対して行われる作業には、メンテナンス作業のほか、コンポーネントの交換、追加、アップグレード、取り外し作業などが含まれる。なお、対象のコンポーネントには、ハードウェアだけでなく、ソフトウェアも含まれる。
作業情報は、作業の具体的な内容を表す情報である。作業情報には、例えば、作業の種別や、対象のコンポーネントを特定する情報等が含まれていてもよい。作業の種別として、例えば、点検、消耗品の交換、ソフトウェアのインストール、アンインストール、アップグレード、ハードウェアの取り付け、取り外し等が例示できる。
作業情報は、車両に対する作業をリクエストする情報とともに、外部装置から送信されてもよい。
【0014】
第一のデータは、複数の拠点のそれぞれにおいて実施が可能な作業の内容を表すデータである。制御部は、作業情報と、第一のデータに基づいて、第一の車両に対して指定された作業を行うことができる拠点を決定する。
かかる構成によると、複数の拠点の中から、希望する作業を行うことができる拠点を迅速に決定することができる。
【0015】
以下、本開示の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは開示の技術的範囲をそれらのみに限定する趣旨のものではない。
【0016】
(第一の実施形態)
第一の実施形態に係る予約システムの概要について、
図1を参照しながら説明する。
本実施形態に係る予約システムは、複数の整備拠点を管理する予約サーバ100と、各
整備拠点に対応する一つ以上の拠点サーバ200と、一つ以上のユーザ端末300と、を含んで構成される。
【0017】
整備拠点とは、車両に対して所定の作業を行うことができる拠点(整備工場など)である。本実施形態において、所定の作業とは、車両が有するコンポーネントを追加、交換、またはアップグレードする作業を含む。コンポーネントは、ハードウェアコンポーネントであってもよいし、ソフトウェアコンポーネントであってもよい。また、ハードウェアコンポーネントは、車載機器であってもよいし、車室設備であってもよい。
本明細書では、作業対象のコンポーネントを「装備品」と称する。
【0018】
車載機器の一例として、例えば、車両の電子制御ユニットなどが挙げられる。車載機器を追加またはアップグレードすることで、車両に新たな機能を付加することができる。例えば、車両に先進安全システム(衝突被害軽減ブレーキ、誤発進抑制制御装置、車間距離制御装置、車線逸脱抑制装置、後側方接近車両注意喚起装置、または、前照灯自動切替装置など)を追加することができる。
また、車室設備の一例として、例えば、シート、サンルーフ、バックミラーなどが挙げられる。車室設備を追加またはアップグレードすることで、車両に新たな価値を付加することができる。車室設備のアップグレードとして、例えば、本革シートへの交換、電動シートへの交換、ステアリングヒーターの追加、シートヒーターの追加、デジタルミラーへの交換などが例示できる。
【0019】
予約サーバ100は、複数の整備拠点を管理する装置である。予約サーバ100は、ユーザ端末300から送信されたリクエスト(以下、作業リクエスト)に基づいて、所定の車両に対して作業を行うための予約を行う。予約サーバ100は、整備拠点ごとに、実施可能な作業の内容を管理しており、作業リクエストによって要求された作業の内容に基づいて、車両を入庫させる整備拠点を決定することができる。予約サーバ100が生成した予約に関するデータ(以下、予約データ)は、拠点サーバ200とユーザ端末300に送信される。
【0020】
拠点サーバ200は、車両に対して作業を行う整備拠点に関連付いたサーバ装置である。整備拠点とは、例えば、車両の製造工場、整備工場、カーディーラーなどである。拠点サーバ200は、予約サーバ100からの指示に基づいて、車両の受け入れを行い、当該車両に対する作業を実施する。
【0021】
ユーザ端末300は、ユーザに関連付いたコンピュータである。ユーザは、ユーザ端末300を介して予約サーバ100にアクセスし、作業を予約することができる。なお、ユーザ端末300は、車両のオーナーが所持しているコンピュータであってもよいし、事業者の店舗(例えば、自動車販売店等)に設置されたコンピュータであってもよい。
【0022】
図2は、本実施形態に係る予約システムに含まれる、予約サーバ100、拠点サーバ200、およびユーザ端末300の構成要素をより詳細に示した図である。ここではまず、ユーザ端末300について説明する。
ユーザ端末300は、例えば、パーソナルコンピュータ、スマートフォン、携帯電話、タブレットコンピュータ、個人情報端末といったコンピュータである。ユーザ端末300は、制御部301、記憶部302、通信部303、および入出力部304を含んで構成される。
【0023】
制御部301は、ユーザ端末300が行う制御を司る演算装置である。制御部301は、CPU(Central Processing Unit)などの演算処理装置によって実現することができ
る。
制御部301は、予約サーバ100にアクセスしてインタラクションを行う機能を実行する。当該機能は、ユーザ端末300で動作するウェブブラウザや、専用のアプリケーションソフトウェアによって実現されてもよい。
【0024】
記憶部302は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部301によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部301において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部301で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部301によって実行されることで、以降に説明する処理が行われる。
【0025】
主記憶装置は、RAM(Random Access Memory)やROM(Read Only Memory)を含んでもよい。また、補助記憶装置は、EPROM(Erasable Programmable ROM)やハード
ディスクドライブ(HDD、Hard Disk Drive)を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。
【0026】
通信部303は、ユーザ端末300をネットワークに接続するための無線通信インタフェースである。通信部303は、例えば、無線LANや3G、LTE、5G等の移動体通信サービスを介して、予約サーバ100と通信可能に構成される。
入出力部304は、ユーザが行った入力操作を受け付け、ユーザに対して情報を提示するユニットである。入出力部304は、例えば、一つのタッチパネルディスプレイからなる。入出力部304は、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成されてもよい。
【0027】
次に、予約サーバ100について説明する。
予約サーバ100は、複数の整備拠点を管理するためのデータベースを管理しており、ユーザ端末300から作業リクエストが送信された場合に、指定された作業が可能な整備拠点を選択し、予約データを生成する。
また、予約サーバ100は、拠点サーバ200から送信されたデータに基づいて、データベースの更新を行うこともできる。
【0028】
本実施形態では、予約サーバ100は、拠点サーバ200およびユーザ端末300とのインタラクションを行うためのWebサーバを実行可能に構成されてもよい。この場合、例えば、拠点サーバ200およびユーザ端末300が、ブラウザを用いてWebサービスにアクセスすることで、情報の入出力を行うことができる。なお、予約サーバ100は、Webサーバ以外の手段によってサービスを提供してもよい。例えば、拠点サーバ200やユーザ端末300にインストールされた専用のアプリケーションソフトウェアと所定のプロトコルによって対話するサービスを予約サーバ100において実行してもよい。
【0029】
予約サーバ100は、汎用のコンピュータにより構成することができる。すなわち、予約サーバ100は、CPUやGPU等のプロセッサ、RAMやROM等の主記憶装置、EPROM、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム(OS)、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを主記憶装置の作業領域にロードして実行し、プログラムの実行を通じて各構成部等が制御されることによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はASICやFPGAのようなハードウェア回路によって実現されてもよい。
【0030】
予約サーバ100は、制御部101、記憶部102、および、通信部103を有して構成される。
制御部101は、予約サーバ100が行う制御を司る演算装置である。制御部101は、CPUなどの演算処理装置によって実現することができる。
制御部101は、予約部1011、および、データ更新部1012の2つの機能モジュールを有して構成される。各機能モジュールは、記憶されたプログラムをCPUによって実行することで実現してもよい。
【0031】
予約部1011は、ユーザ端末300から受信した作業リクエストに基づいて、車両に対して作業を行う整備拠点の予約を行う。具体的には、作業リクエストに含まれる作業情報に基づいてデータベースを検索し、指定された作業が行える整備拠点を選択する処理と、選択した整備拠点を予約するためのデータ(予約データ)を生成する処理と、を実行する。
【0032】
本実施形態では、予約部1011は、データベースに記憶された以下のデータを参照し、作業を行う整備拠点を決定する。
(1)拠点データ
拠点データは、管理下にある整備拠点のそれぞれに固有なデータである。拠点データには、整備拠点ごとに可能な作業の内容が定義されている。
(2)空き状況データ
空き状況データは、予約の空き状況を整備拠点ごとに記憶するデータである。
(3)装備品データ
装備品データは、装備品の販売価格、取り付け工賃、作業所要時間などを記憶するデータである。
これらのデータは、それぞれ、拠点データ102A、空き状況データ102B、装備品データ102Cとして、記憶部102に記憶される。
【0033】
データ更新部1012は、拠点サーバ200から受信したデータに基づいて、上記の三種類のデータを更新する。
【0034】
記憶部102は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部101によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部101において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。
【0035】
また、記憶部102は、前述した拠点データ102A、空き状況データ102B、装備品データ102Cを記憶する。
【0036】
拠点データ102Aは、管理下にある整備拠点のそれぞれに固有なデータである。
図3Aは、拠点データ102Aの一例である。図示したように、拠点データ102Aは、複数の整備拠点の識別子および位置情報を含む。また、拠点データ102Aは、整備拠点ごとに、車両モデルおよび装備品の組み合わせ、当該組み合わせに対する作業の実施可否を記憶する。例えば、図示した例では、整備拠点「F001」において、車両モデル「M001」と装備品「E001」の組み合わせに対する作業が行える旨と、車両モデル「M001」と装備品「E002」の組み合わせに対する作業が行えない旨が定義されている。
拠点データ102Aを参照することで、所定の車両モデルに対して所定の装備品を施工できる整備拠点を検索することができる。
なお、本明細書において、車両モデルとは、車種、年式、グレード別に定義される。
【0037】
空き状況データ102Bは、整備拠点において予約の空きがある日時を表したデータである。空き状況データ102Bを参照することで、作業が可能な日時を特定することができる。
図3(B)に、空き状況データ102Bの例を示す。
空き状況データ102Bには、整備拠点および日付ごとの、空き状況に関するデータが記憶される。空き状況に関するデータは、例えば、設備(ピット)や整備担当者ごとのタイムテーブルなどを含んでいてもよい。空き状況に関する情報は、例えば、整備拠点の係員によって、拠点サーバ200を介して随時送信され、更新される。
【0038】
装備品データ102Cは、車両に装着可能な装備品に関するデータである。
図3Cに、装備品データ102Cの例を示す。装備品データ102Cには、車両モデルと装備品の組み合わせ、装備品の販売価格、時間工賃、取り付け所要時間、取り外し所要時間などに関するデータが記憶される。装備品データ102Cを参照することで、作業にかかる金額や、作業の所要時間を取得することができる。
【0039】
前述した各データは、プロセッサによって実行されるデータベース管理システム(DBMS)のプログラムが、記憶装置に記憶されるデータを管理することで構築されてもよい。この場合、各データは、例えばリレーショナルデータベースとすることができる。
【0040】
通信部103は、予約サーバ100をネットワークに接続するための通信インタフェースである。通信部103は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信インタフェースを含んで構成される。
【0041】
次に、拠点サーバ200について説明する。
拠点サーバ200は、車両に対して作業を行う整備拠点に設置された装置である。拠点サーバ200は、予約サーバ100から送信された予約データを取得する。また、拠点サーバ200は、作業に関するデータ(例えば、装備品ごとの作業の可否に関するデータや、予約の空き状況に関するデータ等)を予約サーバ100に送信する。
【0042】
拠点サーバ200は、予約サーバ100と同様に、汎用のコンピュータにより構成することができる。すなわち、拠点サーバ200は、CPUやGPU等のプロセッサ、RAMやROM等の主記憶装置、EPROM、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。
【0043】
拠点サーバ200は、制御部201、記憶部202、通信部203、および、入出力部204を有して構成される。
制御部201は、拠点サーバ200が行う制御を司る演算装置である。制御部201は、CPUなどの演算処理装置によって実現することができる。
制御部201は、予約受付部2011、および、データ送信部2012の2つの機能モジュールを有して構成される。各機能モジュールは、記憶されたプログラムをCPUによって実行することで実現してもよい。
【0044】
予約受付部2011は、予約サーバ100から予約データを受信し、整備拠点の係員に提供する。
【0045】
データ送信部2012は、整備拠点の係員によって行われた入力に基づいて、以下の情報を取得し、予約サーバ100に送信する。
(1)車両モデルおよび装備品ごとの作業の実施可否を表す情報(第一情報)
(2)予約の空き状況を表す情報(第二情報)
(3)装備品ごとの価格および工賃を表す情報(第三情報)
第一情報によって、予約サーバ100が有する拠点データ102Aが更新される。同様に、第二情報によって、空き状況データ102Bが更新される。また、第三情報によって、装備品データ102Cが更新される。以下、第一ないし第三情報を、拠点情報と総称する。
【0046】
記憶部202は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部201によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部201において実行されるプログラムや、当該制御プログラムが利用するデータ(前述した拠点情報を含む)が記憶される装置である。
【0047】
通信部203は、拠点サーバ200をネットワークに接続するための通信インタフェースである。通信部203は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信インタフェースを含んで構成される。
入出力部204は、ユーザが行った入力操作を受け付け、ユーザに対して情報を提示するユニットである。入出力部204は、例えば、外部ディスプレイとのインタフェース、キーボード、マウス等を含んでもよい。
【0048】
なお、
図2に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。
【0049】
次に、予約システムに含まれる各装置が実行する処理の詳細を説明する。
各装置が実行する処理は、拠点サーバ200が拠点情報を予約サーバ100に送信し、予約サーバ100が有するデータベースを更新するフェーズと、ユーザ端末300から送信されたリクエストに基づいて整備拠点を予約するフェーズに大別される。前者を第一のフェーズ、後者を第二のフェーズと称する。
【0050】
図4は、第一のフェーズにおいて実行される処理を示したフローである。
図4に示した処理は、拠点サーバ200を操作する係員の要求によって開始される。
【0051】
まず、ステップS11で、拠点サーバ200(データ送信部2012)が、拠点情報を生成する。拠点情報は、例えば、以下の三種類の画面を介して取得することができる。
(1)車両モデルおよび装備品ごとの作業の実施可否を入力する第一の画面
(2)予約の空き状況を入力する第二の画面
(3)装備品の価格および工賃を入力する第三の画面
第一の画面を介して第一情報を、第二の画面を介して第二情報を、第三の画面を介して第三情報をそれぞれ取得することができる。
図5は、これらの情報を入力する画面の例である。なお、本実施形態では、拠点情報に、第一情報、第二情報、および、第三情報を含ませるが、拠点情報は、必ずしも上記の三種類の情報を全て含んでいる必要はない。拠点情報は、例えば、例示した三種類の情報のうちの少なくとも一つを含んでいればよい。
【0052】
ステップS12では、データ送信部2012が、入力された情報に基づいて生成された拠点情報を予約サーバ100へ送信する。
ステップS13では、予約サーバ100(データ更新部1012)が、受信した拠点情報に基づいて、データベースの更新を行う。具体的には、拠点情報に、装備品の取り扱いに関する情報(第一情報)が含まれる場合、データ更新部1012は、拠点データ102Aを更新する。拠点情報に、予約の空き状況に関する情報(第二情報)が含まれる場合、データ更新部1012は、空き状況データ102Bを更新する。また、拠点情報に、装備
品の価格および工賃に関する情報(第三情報)が含まれる場合、データ更新部1012は、装備品データ102Cを更新する。
【0053】
なお、本例では、整備拠点からの申告に基づいて拠点データ102Aを更新したが、装備品の取り扱いの可否はシステム管理者によって設定されてもよい。例えば、先進安全システムなど、安全に係る装備品などについては、車両メーカーと関連のある整備拠点、または、当該車両メーカーが認証した整備拠点においてのみ取り扱いを許可することもできる。この場合、拠点サーバ200からの第一情報の送信を制限してもよい。
【0054】
次に、第二のフェーズで行われる処理について説明する。
図6は、第二のフェーズにおいて実行される処理を示したフローである。
図6に示した処理は、ユーザ端末300の操作によって開始される。
【0055】
まず、ステップS21で、制御部301が、作業を行う対象の車両(以下、対象車両)の車両モデルを特定するための情報(以下、車両情報)、および、作業の内容を指定するための情報(以下、作業情報)を取得する。
車両情報は、車両の形式、年式、グレード等を特定するための情報であって、例えば、VIN(Vehicle Identification Number)や、車台番号、フレームナンバーなどを用い
ることができる。
作業情報は、作業の種別、および、対象の装備品を指定する情報である。作業の種別として、以下のようなものが挙げられる。
・ハードウェアの取り付け(購入)
・ハードウェアの取り付け(持ち込み)
・ハードウェアの交換(購入)
・ハードウェアの交換(持ち込み)
・ハードウェアの取り外し
・ソフトウェアのインストール
・ソフトウェアのアンインストール
・ソフトウェアのアップグレード
図7(A)は、車両情報および作業情報を取得するユーザインタフェース画面の例である。
【0056】
次に、ステップS22で、作業の希望エリア、および、入庫を希望する日時の指定を取得する。
図7(B)は、エリアおよび日時を指定するユーザインタフェース画面の例である。ここでは、エリアとして、予め分割された複数のエリアのうちのいずれかを指定する。なお、時刻は、時間帯によって指定してもよい。
【0057】
これらの情報の取得が完了すると、制御部301が入庫リクエストを生成し、予約サーバ100へ送信する。
図8は、入庫リクエストの一例である。図示したように、入庫リクエストには、車両情報、作業情報、入庫希望日時、希望エリアに関する情報などが含まれる。入庫リクエストは、予約部1011によって受信される。
【0058】
次に、ステップS23で、予約部1011が、取得した入庫リクエストに基づいて、作業を行う整備拠点と、入庫日時を決定する。
図9は、ステップS23で予約サーバ100(予約部1011)が実行する処理を詳細に説明するフローチャートである。
【0059】
まず、ステップS231で、拠点データ102Aを参照し、希望エリアに含まれる複数の整備拠点のリストを取得する。
次に、ステップS232で、取得したリストの中に、指定された作業を実施可能な整備
拠点があるか否かを判定する。具体的には、入庫リクエストに含まれる車両情報から車両モデルを特定し、入庫リクエストに含まれる作業情報から、作業の種別および装備品を特定する。そして、車両モデルと装備品の組み合わせに対して、作業が可能な整備拠点をリストから検索する。
ここで、作業が実施可能な整備拠点が存在する場合、処理はステップS233へ遷移する。作業が実施可能な整備拠点が無い場合、処理はステップS235へ遷移する。
【0060】
なお、車両情報に、車両モデルを直接識別する情報が含まれていない場合、他のデータソースを利用することで、車両モデルを特定してもよい。例えば、車両情報がVINである場合、VINと車両モデルとを紐付けた外部データベース等にアクセスし、車両モデルを特定してもよい。
【0061】
ステップS233では、空き状況データ102Bを参照し、特定した整備拠点における予約の空きを確認する。ここで、入庫リクエストに含まれる入庫希望日時を満たす時間枠があった場合、処理はステップS234へ遷移する。入庫希望日時を満たす時間枠が無い場合、処理はステップS235へ遷移する。
【0062】
ステップS234では、車両の入庫が可能な整備拠点のリストをユーザ端末300に送信し、いずれかの整備拠点を選択させる。当該リストには、整備拠点の名称、場所、入庫可能な日時などが含まれていてもよい。
図10は、ユーザ端末300において提示されるリストの例である。また、作業が終了する時刻が既知である場合、車両が出庫可能な日時を同時に提示してもよい。
なお、整備拠点によって工賃や装備品の販売価格が異なる場合、価格や工賃に関する情報を装備品データ102Cから抽出し、本ステップで提示してもよい。この場合、トータルの価格を整備拠点ごとに提示してもよい。
さらに、金額(装備品の販売価格、工賃、トータルの金額など)に関する条件をユーザ端末300から事前に取得し、条件に適合する整備拠点のみをリスト化してもよい。
【0063】
ステップS234において、作業を行う整備拠点が選択された場合、処理はステップS24へ遷移し、予約サーバ100が、予約データを生成する。
図11は、生成される予約データの例である。予約データには、車両の識別子、車両モデル、ユーザの識別子、整備拠点、入庫日時、作業の種別、装備品に関する情報などが含まれる。
生成された予約データは、拠点サーバ200へ送信され、予約受付部2011によって処理される。また、予約データは、同時にユーザ端末300へ送信される。これにより、予約が完了した旨をユーザに通知することができる。
【0064】
処理がステップS235へ遷移した場合、ユーザ端末300に対して、リクエストを満たす整備拠点が存在しない旨を通知し、再度の入力を促す。この場合、処理はステップS21へ遷移し、ユーザによる入力が再度行われる。
【0065】
以上説明したように、第一の実施形態に係る予約システムでは、予約サーバ100が、複数の整備拠点について、施工が可能な装備品についての情報を管理するデータベースを記憶しており、当該データベースに基づいて、作業予約の受け付けを行う。これにより、ユーザは、予約サーバ100にアクセスするだけで、作業が可能な拠点を検索するとともに、作業予約を行うことが可能になる。
【0066】
(第二の実施形態)
車両に装着する装備品によっては、既存の装備品と競合するものが存在する。例えば、対象車両に、車両メーカー以外のサードパーティが提供している電子制御ユニットが装着されている場合、新たに追加される装備品との競合が発生し、正しく動作しなくなるおそ
れがある。第二の実施形態は、これに対応するため、対象車両が有している既存の装備品に基づいて、作業の可否を判定する実施形態である。
【0067】
第二の実施形態では、予約サーバ100が、対象車両が現に有している装備品に関する情報を取得し、当該情報に基づいて、作業の可否を判定する。対象車両が現に有している装備品に関する情報として、例えば、以下のようなものがある。
(1)新車購入時にオプションとして装着された装備品に関する情報
(2)整備拠点において過去に装着された装備品に関する情報
第二の実施形態では、予約サーバ100が、車両ごとのこれらの装備品に関するデータを保持し、作業リクエストを受けた場合に、作業の可否について判定を行う。
【0068】
図12は、第二の実施形態における予約サーバ100の概要図である。図示したように、第二の実施形態では、予約サーバ100が、車両データ102Dをさらに記憶する。車両データ102Dは、車両に対して装備品の追加や取り外し等を行った履歴を表すデータである。
図13は、車両データ102Dの例である。図示したように、車両データ102Dは、車両の識別子、車両モデル、作業を行った日時、作業を行った整備拠点、作業の種別、装備品に関する情報などを含む。予約サーバ100は、車両データ102Dを参照することで、対象車両が現在有している装備品を判定することができる。
【0069】
車両データ102Dは、拠点サーバ200から送信された情報に基づいて、データ更新部1012が更新してもよい。例えば、所定の車両に対して、リクエストされた作業が完了した場合、拠点サーバ200が、作業の内容および装備品に関する情報(以下、作業実施情報)を予約サーバ100に送信し、予約サーバ100(データ更新部1012)が、作業実施情報に基づいて車両データ102Dを更新してもよい。
なお、作業実施情報は、必ずしも拠点サーバ200から送信されなくてもよい。例えば、新車購入時にオプションとして装備品を装着した場合、車両の製造工場が作業実施情報を生成し、予約サーバ100に送信してもよい。また、車両のオーナーが自ら装備品の追加等を行った場合、ユーザ端末300が作業実施情報を生成し、予約サーバ100に送信してもよい。
【0070】
さらに、第二の実施形態では、予約サーバ100が、装備品同士の競合に関する情報を保持している。
図14は、第二の実施形態における装備品データ102Cの例である。図示したように、第二の実施形態における装備品データ102Cは、競合する装備品についての情報が格納されるフィールド(符号1401)を有している。
図示した例では、車両モデル「M001」に、装備品「E101」が現に装着されている場合、新たな装備品「E001」と競合する旨が示されている。
【0071】
競合とは、装備品が物理的に追加できないこと、正常な動作が期待できなくなること、安全が担保できなくなること等を含む。競合が発生した場合、予約部1011は、対象車両に対する作業が行えない旨の判定を行う。
【0072】
図15は、第二の実施形態において予約サーバ100が実行する処理のフローチャートである。第二の実施形態では、ステップS230において、予約部1011が、競合する装備品の有無を判定する。具体的には、まず、作業リクエストに含まれる作業情報と、装備品データ102Cに基づいて、競合する装備品があるかを判定する。そして、車両データ102Dを参照し、競合する装備品が対象車両に装備されているかを判定する。ここで、競合する装備品が対象車両に装備されている場合、処理はステップS230Aへ遷移する。競合する装備品が対象車両に装備されていない場合、処理はステップS231へ遷移する。
【0073】
ステップS230Aでは、予約部1011が、ユーザ端末300に対して、作業が行えない旨を通知する。
【0074】
第二の実施形態によると、対象車両が現に有する装備品に基づいて、新たな装備品の追加可否を判定することが可能になる。
【0075】
なお、
図14の例では、競合する装備品を識別子ごとに指定したが、競合する装備品は、メーカー等によって指定してもよい。例えば、車両メーカーが採用している純正品とは異なるメーカー(サードパーティ)製の装備品や、車両メーカーによって認証されていない装備品が装着されていた場合に、競合が発生するものと判定してもよい。このため、車両データ102Dに、装備品のメーカーや、認証の有無に関するデータを含ませてもよい。
【0076】
また、本実施形態では、車両データ102Dを予約サーバ100に記憶させたが、車両が有する装備品に関するデータは、外部装置が提供してもよい。例えば、予約サーバ100が、外部装置から対象車両のメンテナンス記録を取得し、当該メンテナンス記録に基づいて、対象車両が現に有する装備品を判定してもよい。
また、対象車両が有する装備品に関するデータは、作業リクエストに含まれていてもよい。
また、本実施形態では、競合が発生する場合に、作業が行えない旨の判定を行ったが、所定の条件下(例えば、保証の対象外となることをユーザが同意した場合など)で、作業の予約を受け付けるようにしてもよい。
【0077】
(第三の実施形態)
第一および第二の実施形態では、ユーザは、予約サーバ100が決定した整備拠点に車両を持ち込む必要がある。一方、整備拠点の中には、直接の来客を想定していないものがある。これに対応するため、第三の実施形態では、自動車販売店などの、顧客対応が可能な拠点において車両を預かり、預かった車両の回送を行う。
【0078】
第三の実施形態では、予約サーバ100が、整備拠点を決定するとともに、対象車両を預かる窓口となる拠点(以下、窓口拠点)を決定する。窓口拠点は、例えば、自動車販売店などの、車両を販売する店舗であってもよいし、当該車両に対する作業を行わない整備工場などであってもよい。
第三の実施形態では、車両に対する作業を行う事業者が、窓口拠点において車両を預かり、作業を行う整備拠点まで当該車両を回送する。これにより、エンドユーザは、遠方にある整備拠点まで往復せずとも、サービスを受けることが可能になる。
【0079】
図16は、第三の実施形態における拠点データ102Aの例である。図示したように、第三の実施形態では、複数の拠点に種別が関連付いている。図示した例において、整備拠点は、車両に対する作業を行う拠点である。また、販売拠点は、車両の販売を行う拠点である。なお、車両の受け渡しが可能な拠点であれば、他の拠点を定義してもよい。例えば、無人で車両の受け渡しを行う駐車場などを拠点にしてもよい。
【0080】
図17は、第三の実施形態において予約サーバ100が実行する処理のフローチャートである。第一の実施形態と同様の処理については、点線で示し、詳細な説明は省略する。
まず、ステップS230Bにおいて、予約部1011が、作業リクエストによって指定されたエリア内にある全ての拠点(整備拠点、販売拠点、または他の拠点)を取得する。
次に、ステップS230Cにおいて、予約部1011が、所定のコスト内で往復が可能な、窓口拠点と整備拠点のペアを決定する。
【0081】
本実施形態では、記憶部102に、拠点間の移動コストに関するデータ(コストデータ)が記憶される。
図18は、コストデータの一例である。コストデータは、窓口拠点と整備拠点の間を移動する際に発生するコストを記録したデータである。コストとして、例えば、所要時間、距離、金銭的コストを例示することができる。
本ステップでは、所定のコスト内(例えば、1時間以内)で車両の往復が可能な拠点のペアを一つ以上生成する。
【0082】
また、予約部1011は、ステップS232およびS233の処理をペアごとに実行し、利用可能な窓口拠点と整備拠点のペアを生成する。
ステップS234Aでは、窓口拠点と整備拠点のペアを含むリストをユーザ端末300に送信し、いずれかのペアを選択させる。
図19は、当該リストの例である。
なお、当該リストを、エンドユーザではなく、サービスを行う事業者に属する係員等に提供する場合、コストに関する情報を同時に出力してもよい。これにより、よりコストの低い拠点のペアを選択することが可能になる。
【0083】
以上説明したように、第三の実施形態では、車両を預かる窓口拠点を、整備拠点とは別に決定する。これにより、ユーザの利便性を向上させることができる。さらに、窓口拠点と整備拠点のペアが、所定のコスト条件を満たすように生成される。これにより、コストと利便性を両立させることができる。
【0084】
なお、第三の実施形態では、窓口拠点と整備拠点のペアを決定したが、決定された整備拠点が、直接の顧客対応を行っていない場合に限って窓口拠点を追加で決定するようにしてもよい。
また、第三の実施形態では、車両の移動コストに基づいて窓口拠点と整備拠点のペアを決定したが、その他のコストを加味し、トータルでのコストに基づいて、窓口拠点と整備拠点のペアを決定するようにしてもよい。
【0085】
(変形例)
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
【0086】
また、1つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、1つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成(サーバ構成)によって実現するかは柔軟に変更可能である。
【0087】
本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する1つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク(フロッピー(登録商標)ディスク、ハードディスクドライブ(HDD)等)、光ディスク(CD-ROM、DVDディスク・ブルーレイディスク等)など任意のタイプのディスク、読み込み専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。
【符号の説明】
【0088】
100・・・予約サーバ
101,201,301・・・制御部
102,202,302・・・記憶部
103,203,303・・・通信部
200・・・拠点サーバ
300・・・ユーザ端末
204,304・・・入出力部