(57)【要約】【課題】同車種の車両を有するユーザ同士の交流のきっかけを提供できる情報提供装置を提供する。【解決手段】情報提供装置は、特定車種の車両を所有する複数のユーザを予め登録する登録部３０１と、登録部３０１に登録された一のユーザによる、特定車種の車両の入庫予定を受け付ける受付部３０２と、受付部３０２により入庫予定を受け付ける際、登録部３０１に登録された他のユーザから既に受け付けられた入庫予定を一のユーザに提供する提供部３０３と、を有する。【選択図】図４
2019117550.tif 000002
【特許請求の範囲】
【請求項１】
特定車種の車両を所有する複数のユーザを予め登録する登録部と、
前記登録部に登録された一のユーザによる、前記特定車種の車両の入庫予定を受け付ける受付部と、
前記受付部により前記入庫予定を受け付ける際、前記登録部に登録された他のユーザから既に受け付けられた前記入庫予定を前記一のユーザに提供する提供部と、
を有する情報提供装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報提供装置に関する。
【背景技術】
【０００２】
近年、種々のサービスが、インターネット等のネットワークを通じて提供されている。例えば、車両の整備予約をネットワークを介して受け付ける技術が知られている（例えば、特許文献１参照）。特許文献１記載の技術によれば、ユーザが、サーバにアクセスして予約状況を確認し、自身で予約できるので、ユーザを接客する必要がなく、予約作業が効率化される。
【０００３】
ところで、近年では、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）等のサービスも普及しており、共通の趣味を持った人同士が交流を図る機会が増えている。自動車等の車両には、個人の趣味が反映されることが多く、同車種の車両を有するユーザ（オーナ）同士が交流を図るという要望も見込まれる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−３０３５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１記載の技術では、単に車両の整備予約を取れるだけで、同車種の車両を有するユーザ同士の交流といった要望には応えられない。
【０００６】
本発明は、上記の点に鑑みてなされたものであり、同車種の車両を有するユーザ同士の交流のきっかけを提供できる情報提供装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る情報提供装置は、特定車種の車両を所有する複数のユーザを予め登録する登録部と、前記登録部に登録された一のユーザによる、前記特定車種の車両の入庫予定を受け付ける受付部と、前記受付部により入庫予定を受け付ける際、前記登録部に登録された他のユーザから既に受け付けられた入庫予定を前記一のユーザに提供する提供部と、を有する。
【発明の効果】
【０００８】
本発明によれば、一のユーザから受付部により入庫予定を受け付ける際に、他のユーザから既に受け付けられた入庫予定を提供するので、一のユーザは、登録済の入庫予定を参考にして、自分の入庫予定を入力できる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態に係る情報提供システムの概略構成を示す図である。
【図２】車載器のハードウェア構成を示すブロック図である。
【図３】サーバのハードウェア構成を示すブロック図である。
【図４】サーバの機能構成の例を示すブロック図である。
【図５】情報提供処理の流れを示すフローチャートである。
【図６】入庫予定を受け付ける際に示される画面の例を示す図である。
【図７】他のユーザの入庫予定がより詳細に示される画面の例を示す図である。
【図８】入庫予定の他のユーザの車両の仕様が示される画面の例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態の一例を、図面を参照しつつ説明する。なお、各図面において同一または等価な構成要素および部分には同一の参照符号を付与している。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。
【００１１】
図１は、本実施形態に係る情報提供システムの概略構成を示す図である。
【００１２】
情報提供システムは、車両１０に搭載された車載器２０、およびサーバ３０を有する。
【００１３】
車載器２０は、インターネットまたはイントラネット等のネットワークを介して、サーバ３０と相互通信が可能である。本実施形態では、車両１０のユーザが有するユーザ端末の一例として、車載器２０を説明する。ユーザ端末は、他にも、ユーザが携帯する携帯端末や、ユーザが所有するパソコン等であってもよい。
【００１４】
サーバ３０には、本実施形態の情報提供装置が適用される。サーバ３０は、車両１０の入庫を管理し、管理に際して、適宜、入庫予定を他の車両１０のユーザに提供する。サーバ３０は、例えば、自動車等の車両を販売するディーラまたは車両を整備する車両整備事業者に設置または使用される。本実施形態では、サーバ３０は、特に、車両１０の入庫を車種毎に管理する。
【００１５】
図２は、車載器のハードウェア構成を示すブロック図である。
【００１６】
図２に示すように、車載器２０は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２３、ストレージ２４、ディスプレイ２５、入力部２６および通信インタフェース（Ｉ／Ｆ）２７を有する。各構成は、バス２９を介して相互に通信可能に接続されている。ＣＰＵ２１は、ＥＣＵ（Ｅｎｇｉｎｅ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）と呼ばれることもある。
【００１７】
ＣＰＵ２１は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ２１は、ＲＯＭ２２またはストレージ２４からプログラムを読み出し、ＲＡＭ２３を作業領域としてプログラムを実行する。ＣＰＵ２１は、ＲＯＭ２２またはストレージ２４に記録されているプログラムにしたがって、上記各構成の制御および各種の演算処理を行う。
【００１８】
ＲＯＭ２２は、各種プログラムおよび各種データを格納する。ＲＡＭ２３は、作業領域として一時的にプログラムまたはデータを記憶する。ストレージ２４は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）により構成され、オペレーティングシステムを含む各種プログラム、および各種データを格納する。
【００１９】
ディスプレイ２５は、液晶ディスプレイ等の表示部を有し、車両１０のユーザに各種情報を表示する。入力部２６は、物理的なボタン（ハードキー）、ディスプレイ２５に表示されるソフトウェアボタン、音声入力装置の少なくとも一つを有し、ユーザからの各種入力を受け付ける。入力部２６がソフトウェアボタンを有する場合、ディスプレイ２５は、タッチパネルとして機能する。通信インタフェース（Ｉ／Ｆ）２７は、インターネット等のネットワークを介してサーバ３０および他の外部機器と通信するためのインタフェースであり、たとえば、イーサネット（登録商標）、ＦＤＤＩ、Ｗｉ−Ｆｉ（登録商標）等の規格が用いられる。
【００２０】
図３は、サーバのハードウェア構成を示すブロック図である。
【００２１】
図３に示すように、サーバ３０は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）３１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）３２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）３３、ストレージ３４、ディスプレイ３５、入力部３６および通信インタフェース（Ｉ／Ｆ）３７を有する。各構成は、バス３９を介して相互に通信可能に接続されている。
【００２２】
ＣＰＵ３１は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ３１は、ＲＯＭ３２またはストレージ３４からプログラムを読み出し、ＲＡＭ３３を作業領域としてプログラムを実行する。ＣＰＵ３１は、ＲＯＭ３２またはストレージ３４に記録されているプログラムにしたがって、上記各構成の制御および各種の演算処理を行う。本実施形態では、ＲＯＭ３２またはストレージ３４には、情報提供プログラムが格納されている。
【００２３】
ＲＯＭ３２は、各種プログラムおよび各種データを格納する。ＲＡＭ３３は、作業領域として一時的にプログラムまたはデータを記憶する。ストレージ３４は、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）により構成され、オペレーティングシステムを含む各種プログラム、および各種データを格納する。
【００２４】
ディスプレイ３５は、液晶ディスプレイ等の表示部を有し、サーバ３０のユーザに各種情報を表示する。入力部３６は、マウス、キーボード、ディスプレイ３５に表示されるソフトウェアボタン、音声入力装置の少なくとも一つを有し、ユーザからの各種入力を受け付ける。入力部３６がソフトウェアボタンを有する場合、ディスプレイ３５は、タッチパネルとして機能する。通信インタフェース（Ｉ／Ｆ）３７は、インターネット等のネットワークを介して車載器２０および他の外部機器と通信するためのインタフェースであり、たとえば、イーサネット（登録商標）、ＦＤＤＩ、Ｗｉ−Ｆｉ（登録商標）等の規格が用いられる。
【００２５】
サーバ３０の機能構成について説明する。
【００２６】
図４は、サーバの機能構成の例を示すブロック図である。
【００２７】
図４に示すように、サーバ３０は、機能構成として、登録部３０１、受付部３０２、提供部３０３、判断部３０４、計数部３０５および通知部３０６を有する。
【００２８】
登録部３０１は、特定車種の車両を所有する複数のユーザを予め登録する。サーバ３０は、登録部３０１として機能する場合、ストレージ３４に、同車種を所有するユーザのリスト（以下、同車種所有ユーザリストという）を設け、車種毎に車両を所有するユーザを登録する。車種とは、例えば、車両の名称または車両の型式により区別される。以下では、特定車種の一例として、ハチロク（８６）のユーザが登録部３０１に登録されている場合について説明する。ハチロクはあくまで一例であり、いかなる車種の車両１０であっても、本実施形態に適用できることは言うまでもない。また、ユーザの登録部３０１への登録は、例えば、ユーザがディーラにおいて、ハチロクを購入するタイミングで行なわれる。
【００２９】
受付部３０２は、登録部３０１に登録された一のユーザによる、特定車種の車両１０の入庫予定を受け付ける。サーバ３０は、受付部３０２として機能する場合、車載器２０と通信を行い、車載器２０に入庫予定の入力画面を表示させ、車載器２０の入力部２６における入力を促す。車載器２０においてユーザが入庫予定を入力すると、受付部３０２は入力に関するデータを受信し、ストレージ３４に格納する。
【００３０】
提供部３０３は、受付部３０２により入庫予定を受け付ける際、登録部３０１に登録された他のユーザから既に受け付けられた入庫予定を一のユーザに提供する。提供部３０３は、一のユーザが有する車載器２０（ユーザ端末）に他のユーザの入庫予定に関する情報を送信する。また、提供部３０３は、他のユーザの入庫予定と併せて、他のユーザが有する車両１０に搭載された車載器２０が有する車両情報を提供してもよい。サーバ３０は、提供部３０３として機能する場合、ストレージ３４に格納されている入庫予定を、入庫予定を入力しようとしているユーザの車載器２０に送信する。
【００３１】
判断部３０４は、受付部３０２により受け付けた一のユーザの入庫予定が、既に登録されている他のユーザの入庫予定と合致するか否かを判断する。サーバ３０は、判断部３０４として機能する場合、ストレージ３４に格納されている他のユーザの入庫予定のテーブルにおいて、今回受付部３０２により受け付けた入庫予定を照会し、合致するか否かをＣＰＵ３１により判断する。
【００３２】
計数部３０５は、判断部３０４により、他のユーザの入庫予定と、今回受付部３０２により受け付けた入庫予定とが合致しないと判断した回数をユーザ毎に計数する。サーバ３０は、計数部３０５として機能する場合、計数結果を、ストレージ３４に記憶する。
【００３３】
通知部３０６は、判断部３０４により合致すると判断した場合、他のユーザに対して、ハチロクが同じ入庫予定で入庫することを通知する。サーバ３０は、通知部３０６として機能する場合、既に入庫予定を登録しているユーザが有する車両１０の車載器２０に、同じハチロクを有する別のユーザの入庫予定が重なった旨を通知する。
【００３４】
次に、本実施形態の具体的な情報提供処理について説明する。
【００３５】
図５は、情報提供処理の流れを示すフローチャートである。情報提供処理は、ＣＰＵ３１が、ＲＯＭ３２またはストレージ３４から情報提供プログラムを読み込むことによって実行される。図６は、入庫予定を受け付ける際に示される画面の例を示す図である。図７は、他のユーザの入庫予定がより詳細に示される画面の例を示す図である。図８は、入庫予定の他のユーザの車両の仕様が示される画面の例を示す図である。
【００３６】
ＣＰＵ３１は、登録部３０１の同車種所有ユーザリストに登録しているユーザに検査案内および同車種の入庫予定を提供する（ステップＳ１０１）。検査案内は、例えば、車両１０の整備の案内、定期点検の案内、または車検の案内等である。案内は、登録されているユーザに順次提供される。以下では、登録されているユーザのうち、任意の一のユーザに検査案内が提供される場合を説明する。
【００３７】
ＣＰＵ３１は、ステップＳ１０１により検査案内を提供した一のユーザから、入庫予定を受け付けたか否かを判断する（ステップＳ１０２）。ここで、ＣＰＵ３１は、例えば、図６に示すような画面が一のユーザの車載器２０において表示されるように、車載器２０にデータを送信する。
【００３８】
図６においては、一のユーザは、カレンダを見ながら、どの日に何台、同車種の車両が入庫されるかを確認できる。例えば、ユーザが、車載器２０のタッチパネルまたはハードキーを操作して、気になる日を選択すると、図７または図８に示すような画面に遷移する。図７に示す画面においては、選択した日の前後数日の入庫予定の台数と、入庫予定の詳細な時間が示される。図７の画面において、一のユーザは、入庫時間を選択することにより、他のユーザと入庫の日にちだけでなく、時間も合わせられる。図７の画面において、日付を選択することにより、さらに、図８の画面に遷移してもよい。
【００３９】
図８に示す画面においては、一のユーザが選択した日に入庫を予定している他のユーザの車両１０の仕様が示される。一のユーザの車両１０の仕様も併せて表示されてもよい。各車両１０の仕様は、それぞれの入庫予定の入力の際に、各車両１０の車載器２０から抽出され、サーバ３０のストレージ３４に記憶される。ストレージ３４から読み出された情報が、図８に示す画面に表示される。
【００４０】
図５の説明に戻って、上記の画面を通じてまだ入庫予定を受け付けない場合（ステップＳ１０２：ＮＯ）、ＣＰＵ３１は、情報提供処理を終了する。あるいは、ＣＰＵ３１は、入庫予定を受け付けるまで待機してもよい。
【００４１】
入庫予定を受け付けた場合（ステップＳ１０２：ＹＥＳ）、ＣＰＵ３１は、受け付けた入庫予定が他のユーザの入庫予定と合致するか否か判断する（ステップＳ１０３）。ここで、他のユーザとは、今回入庫予定を受け付けた一のユーザよりも先に入庫予定を登録しているユーザである。既に登録されている他のユーザの入庫予定は、ストレージ３４に格納されている。
【００４２】
ステップＳ１０２で受け付けられた入庫予定が、他のユーザの入庫予定と合致する場合（ステップＳ１０３：ＹＥＳ）、ＣＰＵ３１は、通知部３０６として、他のユーザに対して、同じ日に同車種の車両が入庫される旨を通知する（ステップＳ１０４）。その後、ＣＰＵ３１は、空き日入力回数をリセットして（ステップＳ１０５）、情報提供処理を終了する。空き日とは、一のユーザの車両と同車種の他の車両について、入庫予定がない日のことである。次述するステップＳ１０６において、空き日を入庫予定とした累積回数を計数している。しかし、一度、一のユーザの入庫予定が他のユーザの入庫予定と同じになれば、累積回数がリセットされる。
【００４３】
ステップＳ１０２で受け付けられた入庫予定が、他のユーザの入庫予定と合致しない場合（ステップＳ１０３：ＮＯ）、ＣＰＵ３１は、計数部として、一のユーザが空き日を入庫予定とした累積回数を計数する（ステップＳ１０６）。
【００４４】
ＣＰＵ３１は、ステップＳ１０６において累計した回数が所定の回数以上か否か判断する（ステップＳ１０７）。所定の回数とは、任意に決定される回数であり、例えば、１回〜１０回の任意の回数である。累積回数が多いユーザは、同車種の車両を有する他のユーザとの交流を望んでいないと推測できる。当該推測のために、所定の回数が設定される。
【００４５】
累積回数が所定の回数以上でない場合（ステップＳ１０７：ＮＯ）、ＣＰＵ３１は、情報提供処理を終了する。
【００４６】
累積回数が所定の回数以上の場合（ステップＳ１０７：ＹＥＳ）、ＣＰＵ３１は、登録部３０１の同車種所有ユーザリストから、一のユーザを削除し（ステップＳ１０８）、情報提供処理を終了する。これにより、他のユーザとの交流を望まない蓋然性が高い一のユーザには、今後は同車種を所有する他のユーザに関する情報が提供されない。
【００４７】
本実施形態の情報提供システムによれば、次の効果が得られる。
【００４８】
受付部３０２により入庫予定を受け付ける際に、他のユーザから既に受け付けられた入庫予定を提供するので、一のユーザは、登録済の入庫予定を参考にして、自分の入庫予定を入力できる。一のユーザは、他のユーザと入庫予定を合わせることにより、同車種の車両を有する他のユーザとの交流の機会が得られる。
【００４９】
また、サーバ３０は、車載器２０等のユーザ端末に他のユーザの入庫状況に関する情報を送信するので、特定車種の車両を有するユーザだけに通知ができる。特に、車載器２０に通知すれば、特定車種の車両を有するユーザに確実に情報を送信でき、関係のない人に誤って情報が送信されることがない。
【００５０】
さらに、サーバ３０は、一のユーザが入庫予定を入力する際に、他のユーザの車載器２０が有する車両情報を提供する。したがって、一のユーザは、同車種であっても他のユーザが仕様をどのようにカスタマイズしているかまで確認でき、より深い趣味趣向の興味に従って、入庫予定を入力できる。
【００５１】
さらに、判断部３０４により、一のユーザが他のユーザの入庫予定に合わせて予約したか否かが分かる。すなわち、一のユーザが他のユーザと交流を図りたいか、そうでないかの目安が得られる。そして、所定の回数以上、他のユーザと入庫予定を合わせなかった場合、一のユーザが他のユーザとの交流を求めないとみなして、登録部からの登録を解除する。したがって、交流を求めないユーザに対する情報処理を低減し、システム全体としての情報処理量を低減できる。
【００５２】
また、サーバ３０が通知部３０６として、一のユーザが他のユーザと同じ入庫予定を入力した旨を、他のユーザに通知する。したがって、先に入庫予定を入力した他のユーザも、同車種の車両を所有する一のユーザが同じ入庫予定であることを知ることができる。
【００５３】
なお、上記説明では、サーバ３０が入庫予定の入力を受け付けるところまで説明した。入庫予定の当日が来ると、サーバ３０は、検査等の担当者に、同車種の複数のユーザが同日に来店することを知らせる。これにより、担当者は、同車種の車両を所有するユーザ同士の交流を様々な形態でアレンジできる。
【００５４】
また、上記説明では、一のユーザが初めて入庫予定を入力する際に、先に入庫予定を入力していた他のユーザの入庫予定を提供する点について説明した。しかし、一のユーザが一旦入庫予定を入力し、その後、入庫予定を変更する際に、その時点までに他のユーザが入力している入庫予定を一のユーザに提供してもよい。
【００５５】
（付記項１）
前記提供部は、前記一のユーザが有するユーザ端末に前記入庫予定に関する情報を送信する請求項１に記載の情報提供装置。
【００５６】
（付記項２）
前記ユーザ端末は、前記特定車種の車両に搭載された車載器である付記項１に記載の情報提供装置。
【００５７】
（付記項３）
前記提供部は、前記入庫予定と併せて、前記車載器が有する車両情報を提供する付記項２に記載の情報提供装置。
【００５８】
（付記項４）
前記受付部により受け付けた前記一のユーザの入庫予定が、前記他のユーザの入庫予定と合致するか否かを判断する判断部をさらに有する請求項１、付記項１〜３のいずれか一項に記載の情報提供装置。
【００５９】
（付記項５）
前記判断部により合致しないと判断した回数をユーザ毎に計数する計数部、をさらに有し、
前記登録部は、前記計数部により計数された累積回数が所定の回数以上となるユーザの登録を解除する付記項４に記載の情報提供装置。
【００６０】
（付記項６）
前記判断部により合致すると判断した場合、前記他のユーザに対して、前記特定車種の車両が同じ入庫予定で入庫することを通知する通知部をさらに有する付記項４または付記項５に記載の情報提供装置。
【００６１】
なお、上記各実施形態でＣＰＵがソフトウェア（プログラム）を読み込んで実行した情報提供処理を、ＣＰＵ以外の各種のプロセッサが実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）等の製造後に回路構成を変更可能なＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）、及びＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。また、情報提供処理を、これらの各種のプロセッサのうちの１つで実行してもよいし、同種又は異種の２つ以上のプロセッサの組み合わせ（例えば、複数のＦＰＧＡ、及びＣＰＵとＦＰＧＡとの組み合わせ等）で実行してもよい。また、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた電気回路である。
【００６２】
また、上記各実施形態では、情報提供処理のプログラムがＲＯＭ３２またはストレージ３４に予め記憶（インストール）されている態様を説明したが、これに限定されない。プログラムは、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＤＶＤ−ＲＯＭ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、及びＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）メモリ等の記録媒体に記録された形態で提供されてもよい。また、プログラムは、ネットワークを介して外部装置からダウンロードされる形態としてもよい。
【符号の説明】
【００６３】
１０   車両
２０   車載器
３０   サーバ
３０１ 登録部
３０２ 受付部
３０３ 提供部
３０４ 判断部
３０５ 計数部
３０６ 通知部
【図１】
2019117550.tif 000003
【図２】
2019117550.tif 000004
【図３】
2019117550.tif 000005
【図４】
2019117550.tif 000006
【図５】
2019117550.tif 000007
【図６】
2019117550.tif 000008
【図７】
2019117550.tif 000009
【図８】
2019117550.tif 000010