(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024072407
(43)【公開日】2024-05-28
(54)【発明の名称】情報処理装置及びプログラム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20240521BHJP
【FI】
G06Q50/10
【審査請求】未請求
【請求項の数】8
【出願形態】OL
(21)【出願番号】P 2022183188
(22)【出願日】2022-11-16
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
(71)【出願人】
【識別番号】517356254
【氏名又は名称】テクノ株式会社
(74)【代理人】
【識別番号】110002871
【氏名又は名称】弁理士法人坂本国際特許商標事務所
(72)【発明者】
【氏名】松尾 博充
【テーマコード(参考)】
5L049
5L050
【Fターム(参考)】
5L049CC11
5L050CC11
(57)【要約】
【課題】運転代行に利用する車両情報を、低減されたユーザ負荷で依頼先に伝達する。
【解決手段】入力画面の出力状態におけるユーザ入力に基づいて、運転代行に利用しうる2台以上の車両に関する車両情報を事前登録可能とし、かつ、2台以上の車両に係る車両情報が登録されている場合に、ユーザにより生成可能な運転代行依頼に、2台以上の車両のうちから、ユーザにより選択された一の車両に係る車両情報を対応付ける、情報処理装置が開示される。
【選択図】
図10
【特許請求の範囲】
【請求項1】
入力画面の出力状態におけるユーザ入力に基づいて、運転代行に利用しうる2台以上の車両に関する車両情報を事前登録可能とし、かつ、2台以上の車両に係る車両情報が登録されている場合に、ユーザにより生成可能な運転代行依頼に、2台以上の車両のうちから、ユーザにより選択された一の車両に係る車両情報を対応付ける、情報処理装置。
【請求項2】
アプリケーションが実装され、
ユーザによる前記一の車両の選択は、前記アプリケーションの起動状態におけるトップ画面において入力可能である、請求項1に記載の情報処理装置。
【請求項3】
前記入力画面は、選択入力ボタンを含み、
前記選択入力ボタンは、2台以上の車両のうちの、選択状態にある車両を識別可能とする強調表示を含み、
前記強調表示は、前記アプリケーションの起動時において、前回選択された車両を選択状態とし、その後のユーザからの変更指示入力に基づいて、選択状態にある車両の変更が可能とされる、請求項2に記載の情報処理装置。
【請求項4】
2台以上の車両のそれぞれに係る車両情報は、それぞれ異なる詳細情報を含むことが可能である、請求項2に記載の情報処理装置。
【請求項5】
前記詳細情報は、画像データを含む、請求項4に記載の情報処理装置。
【請求項6】
前記詳細情報は、更に、色、ナンバー、車種、名称、トランスミッションの種別、ステアリングホイールの位置が左右のいずれであるかを表すハンドル情報、車検情報、サイズ、及び属性のうちの、少なくともいずれか1つを含む、請求項5に記載の情報処理装置。
【請求項7】
前記トップ画面は、前記詳細情報の編集又は登録を可能とする下位画面への遷移ボタンを含む、請求項4に記載の情報処理装置。
【請求項8】
入力画面を出力する画面出力処理と、
入力画面の出力状態におけるユーザ入力に基づいて、運転代行に利用しうる車両情報を登録する車両登録処理と、
入力画面の出力状態におけるユーザからの依頼入力に基づいて、運転代行依頼を生成する依頼生成処理とを含む各種処理を、コンピュータにより実行させ、
前記車両登録処理による車両情報の登録は、2台以上の車両に関して可能であり、
前記画面出力処理は、2台以上の車両に係る車両情報が登録されている場合に、2台以上の車両のうちから、今回利用する一の車両をユーザに選択可能とする選択入力ボタンを、入力画面上に出力することを含み、
前記依頼生成処理は、前記選択入力ボタンを介して今回の利用車両が選択された場合、前記運転代行依頼に、登録された車両情報のうちの、選択された車両に係る車両情報を対応付ける、コンピュータにより実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理装置及びプログラムに関する。
【背景技術】
【0002】
飲酒等の理由で自動車の運転ができない者の代わりに運転を行うサービスとして知られている運転代行の管理に用いられる運転代行管理システムが知られている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記のような従来技術は、運転代行を依頼するユーザが、依頼先(例えば当該依頼を受任しうるユーザ)に対して、運転代行に利用する車両情報を、低減された負荷で伝達することが難しい。特に、運転代行に利用する車両は、毎回同じであるとは限らず、ユーザ情報として固定的に登録すると、変更時の手間がかかり、却ってユーザ負担が増す。
【0005】
そこで、本開示は、運転代行に利用する車両情報を、低減されたユーザ負荷で依頼先に伝達可能とすることを目的とする。
【課題を解決するための手段】
【0006】
1つの側面では、入力画面の出力状態におけるユーザ入力に基づいて、運転代行に利用しうる2台以上の車両に関する車両情報を事前登録可能とし、かつ、2台以上の車両に係る車両情報が登録されている場合に、ユーザにより生成可能な運転代行依頼に、2台以上の車両のうちから、ユーザにより選択された一の車両に係る車両情報を対応付ける、情報処理装置が開示される。
【発明の効果】
【0007】
本開示によれば、運転代行に利用する車両情報を、低減されたユーザ負荷で依頼先に伝達することが可能となる。
【図面の簡単な説明】
【0008】
【
図1】一実施例による情報処理システムの全体構成の概略図である。
【
図2】情報処理サーバのハードウェア構成の一例を示す図である。
【
図3】依頼側ユーザからの入力に応じて依頼側ユーザ端末により実行される処理の概略的な流れを示すフローチャートである。
【
図4】情報処理サーバにより実行される処理のうちの、登録に関する処理の概略的な流れを示すフローチャートである。
【
図5】情報処理サーバにより実行される処理のうちの、運転代行依頼に関する処理の概略的な流れを示すフローチャートである。
【
図6】運転代行依頼に係る依頼情報の管理方法の一例を示す表図である。
【
図7】受任側ユーザからの入力に応じて受任側ユーザ端末により実行される処理の概略的な流れを示すフローチャートである。
【
図8】情報処理サーバにより実行される処理のうちの、受任に関する処理の概略的な流れを示すフローチャートである。
【
図9】運転代行依頼入力用の入力画面の一例を示す図である。
【
図10】車両登録用の入力画面の一例を示す図である。
【発明を実施するための形態】
【0009】
以下、添付図面を参照しながら各実施例について詳細に説明する。
【0010】
本明細書において、用語「対応付け」とは、直接的な対応付けのみならず、間接的な対応付けをも含む。例えば、要素Aに要素Bが対応付けられている状態は、要素Aに要素Bが対応付けられている状態のみならず、要素Aに要素Cが対応付けられかつ要素Cに要素Bが対応付けられている状態をも含む概念である。これは、同様の用語「紐付け」についても同様である。
【0011】
図1は、一実施例による情報処理システム1の全体構成の概略図である。
【0012】
情報処理システム1は、情報処理サーバ100を含む。
【0013】
情報処理サーバ100は、ネットワーク4を介して各ユーザ端末21、31と通信可能である。すなわち、ユーザ端末21、31及び情報処理サーバ100は、ネットワーク4を介して接続される。
【0014】
以下では、依頼側ユーザとは、運転代行サービスを受ける側のユーザを指し、受任側ユーザとは、運転代行を行う側のユーザを指す。そして、ユーザ端末21は、依頼側ユーザにより利用される端末であり、「依頼側ユーザ端末21」とも称する。また、ユーザ端末31は、受任側ユーザにより利用される端末であり、以下、「受任側ユーザ端末31」とも称する。なお、依頼側ユーザと受任側ユーザとは、その時点で依頼側か受任側かを表す形式的な用語であり、従って、ある時点で依頼側であるユーザが、他の時点で受任側になる場合もありうる。
【0015】
ネットワーク4は、インターネット、WAN(Wide Area Network)、無線通信網、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでもよい。なお、ネットワーク4の一部又は全部は、P2Pネットワークにより実現されてもよい。
【0016】
ユーザ端末21、31は、それぞれ、例えばスマートフォンや携帯電話であるが、ウェアラブル端末(例えばスマートウォッチ、リング等)、タブレット端末、ラップトップ端末、デスクトップ端末等であってもよい。
【0017】
ユーザ端末21、31は、それぞれ、処理装置23、33、表示部24、34、入力装置25、35、及びGPS(Global Positioning System)受信機26、36を備える。処理装置23、33は、マイクロコンピュータのようなコンピュータであってよい。表示部24、34は、液晶ディスプレイや、有機EL(Electro-Luminescence)ディスプレイ等であってよい。入力装置25、35は、タッチパネル等であってよい。GPS受信機26、36は、GPS衛星からの衛星信号に基づいて、端末位置情報を生成してよい。
【0018】
情報処理サーバ100は、サーバの形態であり、例えばサーバコンピュータにより形成される。情報処理サーバ100は、複数のサーバコンピュータにより実現されてもよい。例えば、情報処理サーバ100は、互いに異なる場所に配置された複数のサーバコンピュータが協動することで実現されてもよい。また、情報処理サーバ100は、Webサーバを含んでよい。この場合、後述するユーザ端末21、31の機能の一部は、Webサーバから受領したHTML文書やそれに付随する各種プログラム(Javascript)をブラウザが処理することによって実現されてもよい。
【0019】
図2は、情報処理サーバ100のハードウェア構成の一例を示す図である。
【0020】
図2に示す例では、情報処理サーバ100は、制御部101、主記憶部102、補助記憶部103、ドライブ装置104、ネットワークI/F部106、及び入力部107を含む。
【0021】
制御部101は、主記憶部102や補助記憶部103に記憶されたプログラムを実行する演算装置であり、入力部107や記憶装置からデータを受け取り、演算、加工した上で、記憶装置などに出力する。
【0022】
主記憶部102は、ROM(Read Only Memory)やRAM(Random Access Memory)などである。主記憶部102は、制御部101が実行する基本ソフトウェアであるOS(Operating System)やアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。
【0023】
補助記憶部103は、HDD(Hard Disk Drive)やSSD(Solid State Drive)などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。
【0024】
ドライブ装置104は、記録媒体105、例えばフレキシブルディスクからプログラムを読み出し、記憶装置にインストールする。
【0025】
記録媒体105は、所定のプログラムを格納する。この記録媒体105に格納されたプログラムは、ドライブ装置104を介して情報処理サーバ100にインストールされる。インストールされた所定のプログラムは、情報処理サーバ100により実行可能となる。
【0026】
ネットワークI/F部106は、ネットワーク4を介して接続された通信機能を有する周辺機器やユーザ端末21、31等と情報処理サーバ100とのインターフェースである。
【0027】
入力部107は、カーソルキー、数字入力及び各種機能キー等を備えたキーボード、マウスやタッチパッド等を有する。
【0028】
なお、
図2に示す例において、以下で説明する各種処理等は、プログラムを情報処理サーバ100に実行させることで実現することができる。また、プログラムを記録媒体105に記録し、このプログラムが記録された記録媒体105を情報処理サーバ100に読み取らせて、以下で説明する各種処理等を実現させることも可能である。なお、記録媒体105は、様々なタイプの記録媒体を用いることができる。例えば、記録媒体105は、CD(Compact Disc)-ROM、フレキシブルディスク、光磁気ディスク等のように情報を光学的、電気的あるいは磁気的に記録する記録媒体、ROM、フラッシュメモリ等のように情報を電気的に記録する半導体メモリ等であってよい。
【0029】
なお、ユーザ端末21(ユーザ端末31も同様)のハードウェア構成自体は、表示部24と、GPS受信機26を備える以外は、情報処理サーバ100のハードウェア構成と同様であってよい。ただし、情報処理サーバ100については、表示部を有してもよい。
【0030】
次に、
図3以降を参照して、情報処理システム1におけるユーザ端末21、31及び情報処理サーバ100の動作について説明する。なお、以下の説明において、ユーザ端末21、31の機能の一部は、情報処理サーバ100により実現されてもよいし、情報処理サーバ100の機能の一部又は全部は、ユーザ端末21、31により実現されてもよい。
【0031】
図3は、依頼側ユーザからの入力に応じて依頼側ユーザ端末21により実行される処理の概略的な流れを示すフローチャートである。
【0032】
依頼側ユーザ端末21は、依頼側ユーザからのダウンロード指示に応答して、専用のアプリケーション(以下、単に「運転代行依頼アプリ」とも称する)をダウンロードする(ステップS30)。なお、上述したように運転代行依頼アプリは、いわゆるネイティブアプリケーションであってもよいし、WEBアプリケーションであってもよい。なお、依頼側ユーザ端末21には、別に、地図アプリケーション(例えば、GoogleMaps(登録商標))が実装されてよい。この場合、運転代行依頼アプリは、地図アプリケーションと連携して、以下で説明する各種機能を実現してもよい。
【0033】
なお、以下の説明において、運転代行依頼アプリの立ち上げ状態とは、運転代行依頼アプリの起動状態であって、ユーザからの入力が可能な状態を指す。従って、運転代行依頼アプリの立ち上げ状態とは、マルチタスク画面等において、バックグラウンドで運転代行依頼アプリが起動している状態とは異なる。
【0034】
ついで、依頼側ユーザ端末21は、運転代行依頼アプリの立ち上げ状態(起動状態)において、依頼側ユーザからの各種入力に基づいて、ユーザ登録用のユーザ情報を生成する(ステップS31)。ユーザ登録は、例えば、依頼側ユーザの電話番号や住所(例えば自宅住所)、支払い方法、メールアドレス、パスワード等の登録を含んでよい。ユーザ登録用のユーザ情報は、情報処理サーバ100に送信されてよい。この場合、情報処理サーバ100は、ユーザIDを発行し、ユーザIDに、ユーザ登録用のユーザ情報を紐付けてよい。このようにして、ユーザ登録用のユーザ情報は、ユーザIDに紐付けられた状態で情報処理サーバ100において記憶(管理)されてよい。
【0035】
なお、一旦、ユーザ登録が行われると、以後、依頼側ユーザは、ユーザIDとパスワードの入力等に基づいて、運転代行依頼アプリの立ち上げ状態を実現可能であってよい。
【0036】
ついで、依頼側ユーザ端末21は、運転代行依頼アプリの立ち上げ状態(起動状態)において、依頼側ユーザからの各種入力に基づいて、登録用の車両情報を生成する(ステップS32)。登録用の車両情報は、情報処理サーバ100に送信されてよい。この場合、情報処理サーバ100は、対応するユーザIDに、登録用の車両情報を紐付けてよい。このようにして、登録用の車両情報は、ユーザIDに紐付けられた状態で情報処理サーバ100において記憶(管理)されてよい。なお、車両情報の登録は、ユーザ情報の登録と同様、変更がない限り、一度だけ実行されるだけでよい。また、車両情報の登録は、ユーザに応じて実行可能な処理であり、省略されてもよい。
【0037】
このようにして依頼側ユーザは、運転代行に利用する自身の車両に係る車両情報を登録できる。これにより、受任側ユーザが車両を見つけやすくなり、待ち合わせがスムーズとなり、利便性が向上する。
【0038】
ついで、依頼側ユーザ端末21は、運転代行依頼アプリの立ち上げ状態において、依頼側ユーザからの駐車位置の登録入力に基づいて、駐車位置登録用の駐車位置情報を生成する(ステップS33)。例えば、駐車位置登録用の駐車位置情報の生成は、例えば、駐車位置入力用の入力画面の出力状態において、依頼側ユーザからの駐車位置の登録入力に基づいて実現されてもよい。
【0039】
駐車位置登録用の駐車位置情報は、GPS受信機26による受信機位置情報を利用して生成されてもよい。駐車位置登録用の駐車位置情報の好ましい生成方法は後述する。駐車位置登録用の駐車位置情報は、情報処理サーバ100に送信されてよい。この場合、駐車位置の登録状態は、情報処理サーバ100において、ユーザID(又は後述する依頼ID)に紐付けられる態様で記憶(管理)されてよい。あるいは、駐車位置登録用の駐車位置情報は、依頼側ユーザ端末21内で記憶(管理)されてもよい。
【0040】
登録に係る駐車位置は、依頼側ユーザが運転代行で利用する車両の駐車位置である。典型的には、登録に係る駐車位置は、依頼側ユーザと受任側ユーザとの間の待ち合わせ場所となり、そこで両者が落ち合うことで、運転代行が開始される。なお、場合によっては、依頼側ユーザと受任側ユーザは、異なる待ち合わせ場所で待ち合わせしてから、登録に係る駐車位置に向かってもよい。
【0041】
ついで、依頼側ユーザ端末21は、運転代行依頼アプリの立ち上げ状態において、依頼側ユーザからの依頼確定入力に基づいて、運転代行依頼を生成(確定)する(ステップS34)。例えば、運転代行依頼の生成は、例えば、駐車位置入力用の入力画面の出力状態において、依頼側ユーザからの依頼確定入力に基づいて実現されてもよい。この場合、依頼側ユーザは、駐車位置の登録から、画面遷移を伴うことなく、運転代行依頼を生成でき、利便性が向上する。
【0042】
運転代行依頼は、ステップS33で生成した駐車位置登録用の駐車位置情報に紐付けられる。例えば、駐車位置登録用の駐車位置情報が、依頼側ユーザ端末21内で記憶(管理)される場合、運転代行依頼は、駐車位置登録用の駐車位置情報とともに、情報処理サーバ100に送信されてもよい。あるいは、駐車位置登録用の駐車位置情報が、情報処理サーバ100内で記憶(管理)される場合、運転代行依頼は、ユーザIDとともに情報処理サーバ100に送信されてよい。この場合、情報処理サーバ100は、ユーザIDを介して、運転代行依頼を登録済の駐車位置情報に紐付けることができる。
【0043】
運転代行依頼は、帰り先の情報を含んでよい。この場合、帰り先は、自宅住所(ユーザ情報)以外である場合だけ、依頼側ユーザにより指定されてもよい。
【0044】
依頼側ユーザは、依頼側ユーザ端末21を介して、このようにして運転代行依頼を生成することで、後述する受任側ユーザによる運転代行サービスを受けることができる(ステップS35)。
【0045】
図4は、情報処理サーバ100により実行される処理のうちの、登録に関する処理の概略的な流れを示すフローチャートである。
【0046】
情報処理サーバ100は、上述したように依頼側ユーザ端末21で生成されるユーザ登録用のユーザ情報を受信すると(ステップS40)、受信したユーザ情報を登録する(ステップS41)。すなわち、ユーザ登録を実現する。
【0047】
また、情報処理サーバ100は、上述したように依頼側ユーザ端末21で生成される駐車位置登録用の駐車位置情報を受信すると(ステップS42)、受信した駐車位置情報を、ユーザIDに対応付けて登録(一時的に保持)する(ステップS43)。すなわち、駐車位置の登録を実現する。なお、駐車位置は、運転代行依頼ごとに変化しうるため、所定消去条件が満たされると、消去(無効化)されてもよい。所定消去条件は、登録時間が一定時間経過した場合や、対応する運転代行サービスが終了した場合等に、満たされてよい。
【0048】
図5は、情報処理サーバ100により実行される処理のうちの、運転代行依頼に関する処理の概略的な流れを示すフローチャートである。
図6は、運転代行依頼に係る依頼情報の管理方法の一例を示す表図である。
図6において、「***」は、なんらかの情報が格納されている状態を示し、「・・・」は、同様の情報の格納の繰り返し状態を示す。
【0049】
情報処理サーバ100は、依頼側ユーザ端末21から送信される運転代行依頼を受信すると(ステップS50)、依頼IDを発行する(ステップS51)。そして、情報処理サーバ100は、今回の運転代行依頼に係る駐車位置を特定し、依頼IDに駐車位置を紐付ける(ステップS52)。今回の運転代行依頼に係る駐車位置(すなわち特定対象の駐車位置)は、登録された駐車位置情報(
図4のステップS43参照)に対応してよい。ついで、情報処理サーバ100は、
図6に示すような依頼情報を生成(更新)する(ステップS53)とともに、新たに生成した依頼情報を含む依頼情報データに基づいて、受任用表示画面の出力用データを更新する(ステップS54)。受任用表示画面は、受任側ユーザが閲覧可能な画面であり、受任側ユーザが各種依頼のうちから所望の依頼を受任できるようなユーザインターフェースを含んでよい。
【0050】
なお、依頼情報は、運転代行依頼の履歴や現況を管理するための情報であってよい。
図6に示す例では、各依頼IDに、依頼詳細情報、駐車位置、依頼側ユーザ情報、及び受任状況が対応付けられている。この場合、依頼詳細情報は、依頼内容の詳細のうちの、駐車位置以外の情報(例えば、依頼日時、希望待ち合わせ日時、帰り先、連絡電話番号等)を含んでよい。駐車位置は、上述したとおり、登録された駐車位置情報であってよい。依頼側ユーザ情報は、依頼側ユーザのユーザIDであってよい。また、受任状況は、運転代行依頼に対して受任側ユーザにより受任があったか否かの情報(すなわち受任待ち状態か否かの情報)を含んでよい。
【0051】
図7は、受任側ユーザからの入力に応じて受任側ユーザ端末31により実行される処理の概略的な流れを示すフローチャートである。
【0052】
受任側ユーザ端末31は、受任側ユーザからのダウンロード指示に応答して、専用のアプリケーション(以下、単に「運転代行受任アプリ」とも称する)をダウンロードする(ステップS70)。なお、上述したように運転代行受任アプリは、いわゆるネイティブアプリケーションであってもよいし、WEBアプリケーションであってもよい。なお、受任側ユーザ端末31には、別に、地図アプリケーション(例えば、GoogleMaps(登録商標))が実装されてよい。この場合、運転代行受任アプリは、地図アプリケーションと連携して、以下で説明する各種機能を実現してもよい。
【0053】
ついで、受任側ユーザ端末31は、運転代行受任アプリの立ち上げ状態(起動状態)において、受任側ユーザからの各種入力に基づいて、ユーザ登録用のユーザ情報を生成する(ステップS71)。ユーザ登録は、例えば、受任側ユーザの電話番号や、メールアドレス、パスワード等の登録を含んでよい。ユーザ登録用のユーザ情報は、情報処理サーバ100に送信されてよい。この場合、情報処理サーバ100は、ユーザIDを発行し、ユーザIDに、ユーザ登録用のユーザ情報を紐付けてよい。このようにして、ユーザ登録用のユーザ情報は、ユーザIDに紐付けられた状態で情報処理サーバ100において記憶(管理)されてよい。
【0054】
なお、一旦、ユーザ登録が行われると、以後、受任側ユーザは、ユーザIDとパスワードの入力等に基づいて、運転代行受任アプリの立ち上げ状態(受任用表示画面の出力状態)を実現可能であってよい。
【0055】
ついで、受任側ユーザ端末31は、端末位置情報に基づいて、受任用表示画面を出力する(ステップS72)。受任用表示画面は、未受任状態の運転代行依頼(すなわち受任側ユーザによる受任が可能な運転代行依頼)に係る情報を含む。端末位置情報は、GPS受信機26による受信機位置情報を利用して生成されてもよい。例えば、受任用表示画面は、端末位置情報の位置を中心とした地図表示を含んでよい。
【0056】
ついで、受任側ユーザ端末31は、受任用表示画面の出力状態において、受任側ユーザからの受任入力に基づいて、運転代行依頼に対する受任情報を生成(確定)する(ステップS73)。複数の運転代行依頼が競合している場合、受任入力は、いずれか1つの運転代行依頼(選択された一の運転代行依頼)に紐付けられてよい。
【0057】
受任側ユーザは、受任側ユーザ端末31を介して、このようにして運転代行依頼に対して受任情報を生成することで、上述した依頼側ユーザに対して運転代行サービスを提供できる(ステップS74)。
【0058】
図8は、情報処理サーバ100により実行される処理のうちの、受任に関する処理の概略的な流れを示すフローチャートである。
【0059】
情報処理サーバ100は、上述したように受任側ユーザ端末31で生成される受任情報を受信すると(ステップS80)、受信した受任情報に基づいて、依頼情報を更新する(ステップS81)。例えば
図6に示す依頼情報の場合、対応する運転代行依頼に係る受任状況が、“受任済”を表すように更新されてよい。
【0060】
ついで、情報処理サーバ100は、駐車位置(待ち合わせ場所)での落ち合いに対する支援処理を実行する(ステップS82)。例えば、情報処理サーバ100は、依頼側ユーザに係る依頼側ユーザ端末21に対しては、受任した受任側ユーザの位置情報や到着予定時間、相手側の電話番号等を案内(通知)してよい。また、情報処理サーバ100は、受任側ユーザに係る受任側ユーザ端末31に対しては、待ち合わせ場所(運転代行依頼に係る駐車位置)までの経路案内や車両情報の案内、相手側の電話番号等を実行してもよい。なお、相手側の電話番号は、操作すると、発呼するようなスイッチの形態であってよい。
【0061】
ついで、情報処理サーバ100は、運転代行サービス開始を検出すると(ステップS83)、運転代行サービスを支援する(ステップS84)。運転代行サービス開始は、例えば受任側ユーザからの開始入力に応じて受任側ユーザ端末31から情報処理サーバ100に通知されてもよい。また、運転代行サービスの支援は、例えば、依頼側ユーザによる登録ユーザ(例えば家族)への現在位置情報の通知や、帰り先までの経路案内等により実現されてもよい。なお、運転代行サービスの支援のうちの、帰り先までの経路案内は、受任側ユーザ端末31において自律的に実現されてもよい。そして、情報処理サーバ100は、運転代行サービスが終了すると(すなわち帰り先に到達すると)、サービス完了情報を記憶して(ステップS85)、今回の運転代行依頼及び受任に対する処理を終了する。なお、サービス完了情報は、到着時間や明細(料金)などの情報を含んでよい。
【0062】
次に、
図9以降を参照して、依頼側ユーザ端末21における処理及び出力画面について説明する。
【0063】
図9は、運転代行依頼入力用の入力画面SC1の一例を示す図である。運転代行依頼入力用の入力画面SC1は、依頼側ユーザ端末21の表示部24に出力されてよい。
【0064】
運転代行依頼入力用の入力画面SC1は、好ましくは、運転代行依頼アプリの起動状態におけるトップ画面である。
【0065】
図9に示す例では、運転代行依頼入力用の入力画面SC1は、上側の地図表示G2と、下側にユーザインターフェースG3とを含む。地図表示G2は、好ましくは、ユーザインターフェースG3よりも広い範囲に表示されてもよい。地図表示G2には、駐車位置を登録するための支援表示G7が表示される。支援表示G7は、駐車位置又はその候補に対応する位置を、地図表示G2に表す表示である。
図9に示す例では、支援表示G7は、位置表示G70と、マーク表示G71とを含み、位置表示G70は、例えば、初期的には、地図表示G2において、依頼側ユーザ端末21の現在位置(端末位置情報)に位置付けられる。マーク表示G71は、位置表示G70を見立たせるための表示である。なお、
図9では、「あと2分でお迎え」といった表示であって、現時点で運転代行依頼を生成した場合のお迎え時間の目安を示す表示が、支援表示G7に含められてもよい。また、地図表示G2上には、現時点で運転代行依頼を生成した場合に当該運転代行依頼を受任しうる受任側ユーザの位置表示G50が車両の図柄形態で出力されてもよい。
【0066】
ユーザインターフェースG3は、登録用インターフェース部G31と、メインインターフェース部G32とを含む。
【0067】
登録用インターフェース部G31は、タッチスイッチの形態で、スイッチSW61、及びスイッチSW62を含む。スイッチSW61は、迎え先を入力するためのインターフェースであり、スイッチSW61は、端末位置情報に応じた現在位置に対応する現在の候補(駐車位置の候補)を示す文字(表記)を含んでよい。この場合、依頼側ユーザは、現在の候補で問題なければ、スイッチSW62にスライドして、運転代行依頼を確定させることも可能である。スイッチSW62は、運転代行依頼を確定させる際にスライド操作されるスイッチである。すなわち、スイッチSW62が操作されると、上述した依頼確定入力が生成されることになる。
【0068】
メインインターフェース部G32は、4つのメインスイッチSW320、SW321、SW322、及びSW323を含む。メインスイッチSW320は、「すぐ呼ぶ」と表記されたスイッチであり、運転代行依頼を確定させるためのスイッチSW62を呼び出すためのスイッチである。メインスイッチSW321は、「あとで呼ぶ」と表記されたスイッチであり、現時点よりも有意に遅い時刻に運転代行依頼(予約)を確定させるためのスイッチである。メインスイッチSW320、SW321は、駐車位置が登録されている状態でアクティブ化(操作可能な状態)とされてもよい。メインスイッチSW322は、「今日の駐車場」と表記されたスイッチであり、駐車位置を登録するためのスイッチである。駐車位置を事前に登録することで、後でメインスイッチSW320により運転代行依頼を確定させる際に、駐車位置を入力する手間を省くことができ、依頼側ユーザにとって利便性が向上する。メインスイッチSW323は、いわゆるハンバーガーボタンであり、各種詳細設定用のボタンであってよい。
【0069】
図10は、車両登録用の入力画面SC1-1の一例を示す図である。
【0070】
車両登録用の入力画面SC1-1は、トップ画面の一形態であり、
図9に示す運転代行依頼入力用の入力画面SC1におけるユーザインターフェースG3を上側に拡大させる操作により形成可能である。なお、ユーザインターフェースG3の拡大状態は、表示G46付近を下側にフリックすることで、解除可能とされてよい。
【0071】
具体的には、車両登録用の入力画面SC1-1は、追加登録用のユーザインターフェース部G33を追加的に含む。なお、車両登録用の入力画面SC1-1においては、追加登録用のユーザインターフェース部G33の表示領域の面積分だけ、地図表示G2の領域が減っているが、地図表示G2上の支援表示G7等は依然として容易に視認可能な状態である。
【0072】
追加登録用のユーザインターフェース部G33は、各種スイッチSW40,SW41、SW42,SW43、及びS44を含み、これらのうち、スイッチSW41が、車両登録用のスイッチである。なお、スイッチSW40は、帰り先を登録するための入力部であり、スイッチSW42は、依頼側ユーザが希望する受任側ユーザの属性を指定する入力部である。なお、依頼側ユーザが希望する受任側ユーザの属性は、喫煙の有無、性別、事故歴の有無、安全運転への指向性等を含んでよい。また、スイッチSW43は、支払い方法を指定するための入力部であり、スイッチSW44は、クーポンを入力するための入力部である。なお、追加登録用のユーザインターフェース部G33は、料金の目安を示す画像部G45を含む。
【0073】
スイッチSW41は、選択入力ボタンの形式であり、事前登録された複数台の車両から、今回の運転代行で利用する車両を選択可能なボタンである。なお、事前登録可能な台数の上限は、任意であるが、本実施例では、一例として3台である。以下では、事前登録された車両を、「登録車両」とも称する。
【0074】
図10に示す例では、依頼側ユーザは、3台のうちの、2台が登録済みであり、当該2台の車両名は“車両A”、及び“車両B”である。スイッチSW41では、3つの選択入力ボタンのうちの、選択されている一の選択入力ボタンを、他の選択入力ボタンに対して強調されてよい。
図10に示す例では、“車両B”に係る選択入力ボタンが強調表示(ハイライト表示)されており、“車両B”が選択状態であることがわかる。選択状態の車両は、対応する他の選択入力ボタンを操作することで変更可能とされる。初期的に選択状態となる車両は、前回の利用時に選択された車両とされてもよい。この場合、連続的に同じ車両を利用する傾向にあるユーザにとっては、毎回選択し直す手間が不要となり、利便性が向上する。
【0075】
なお、
図10に示す例では、3台目の車両は登録されていない。この場合、依頼側ユーザは、3台目の車両に係る選択入力ボタンを選択状態とすることで、今回の運転代行に利用する車両が、登録車両以外であることを通知(受任側ユーザに伝達)することとしてもよい。なお、依頼側ユーザは、選択状態である選択入力ボタンをタップすることで、非選択状態に変化させることが可能とされてもよい。すなわち、依頼側ユーザは、すべての選択入力ボタンを非選択状態に変化させることが可能とされてもよい。これにより今回の運転代行に利用する車両が、登録車両以外であることを通知(受任側ユーザに伝達)することとしてもよい。
【0076】
スイッチSW41の周辺には、好ましくは、車編集用画面SC2への遷移スイッチSW431(遷移ボタンの一例)が配置される。遷移スイッチSW431は、下層(すなわち下位画面)への遷移を想起できる矢印の形態の表記を含んでよい。この場合、依頼側ユーザは、スイッチSW41の選択入力ボタンに係る車両名の表記(例えば“車両A”、及び“車両B”)を見て、登録車両の変更や追加を行いたいと思った場合に、直感的に遷移スイッチSW431を操作して、車編集用画面SC2へ遷移できる。なお、下位画面への遷移は、フリック操作等により実現可能とされてもよい。
【0077】
本実施例では、2台以上の登録車両のそれぞれに係る車両情報は、それぞれ異なる詳細情報を含むことが可能である。
【0078】
詳細情報は、任意であるが、例えば車両の色、ナンバー、車種、名称、トランスミッションの種別、ステアリングホイールの位置が左右のいずれであるかを表すハンドル情報、車検情報、サイズ、及び属性のうちの、少なくともいずれか1つを含む。なお、名称は、車両の通称や略称等を含んでよい。サイズは、運転のしやすさを示す態様で、大型、中型、小型等の粒度で細分化されてもよいし、排気量の情報を含んでもよい。また、属性は、セダン、スポーツ、SUV(Sports Utility Vehicle)、電動、ハイブリッド車等を表してよい。
【0079】
特に本実施例では、詳細情報は、車両の画像データを含むことができる。この場合、受任側ユーザが車両の各種情報(色やサイズ感)を容易に把握できるので、円滑な待ち合わせを促進できる。
【0080】
図11は、車編集用画面SC2の一例を示す図である。車編集用画面SC2は、各登録車両に対応付け可能な詳細情報を編集又は登録(生成)するための画面である。
【0081】
図11に示す例では、車編集用画面SC2は、詳細情報に係る各種情報を入力するためスイッチSW4310~SW4319を含む。
【0082】
スイッチSW4310は、どの登録車両の詳細を入力するかを選択するための選択ボタン形式のスイッチである。この場合、スイッチSW4310は、3つの車両のいずれかを選択可能とする。
【0083】
スイッチSW4311は、車両の画像データを入力するための入力部であり、その場で依頼側ユーザ端末21のカメラで撮像した画像や、依頼側ユーザ端末21内に記憶されている画像が選択可能とされてよい。なお、登録可能な画像データは、車両が写っている限り任意であるが、例えばナンバープレートが撮像されている画像を含んでよい。この場合、ナンバープレートから画像認識される番号等に基づいて、後述する詳細情報の一部が自動的に入力されてもよい。
【0084】
スイッチSW4312は、車両のナンバー、すなわち自動車登録番号(ナンバープレートに記載された番号)を登録するための入力部である。
【0085】
スイッチSW4313は、車両の車種を登録するための入力部であり、スイッチSW4314は、車両の名称を登録するための入力部である。車両の名称は、依頼側ユーザ用の名称であってよく、自身にとってわかりやすい名称が登録されてよい。
【0086】
スイッチSW4315は、車両の色(外装の塗装色)を登録するための入力部である。車両の色は、
図11に示すように、実際のカラー表示を選択して指定可能とされてもよい。また、車両の色の登録は、メタリックの有無や、ツートンカラー等の登録を含んでよい。
【0087】
スイッチSW4316は、トランスミッションの種別(マニュアルかオートマチックか)を登録するためのボタンであり、選択ボタン形式であってよい。
【0088】
スイッチSW4317は、ハンドル(ステアリングホイール)の左右位置を登録するためのボタンであり、選択ボタン形式であってよい。
【0089】
スイッチSW4318は、登録ボタンとして機能する。例えば、車両1について詳細情報を生成及び編集する場合は、依頼側ユーザは、スイッチSW4310により車両1の選択状態を形成した上で、スイッチSW4311からスイッチSW4317を、車両1に対応した情報にセットする。そして、最後にスイッチSW4318を操作することで、車両1に係る詳細情報を生成及び更新できる。
【0090】
スイッチSW4319は、詳細情報を削除するためのスイッチであり、登録車両の削除が可能である。例えば、車両1の詳細情報を削除したい場合、依頼側ユーザは、スイッチSW4310により車両1の選択状態を形成した上で、スイッチSW4319を操作すればよい。
【0091】
このようにして依頼側ユーザが登録車両の詳細情報を生成又は更新すると、戻るスイッチSW432を操作することで、
図10に示した車両登録用の入力画面SC1-1に戻ることができる。
【0092】
依頼側ユーザは、車両登録用の入力画面SC1-1において、選択した車両情報等について問題なければ、スイッチSW62を操作して、当該車両情報に紐付けられた運転代行依頼を生成できる。
【0093】
このようにして、本実施例によれば、運転代行に利用する車両情報を、低減されたユーザ負荷で依頼先に伝達可能となる。
【0094】
また、本実施例によれば、事前に複数の車両を登録可能であるので、複数の車両のうちから運転代行に利用する車両が都度変化しうる依頼側ユーザは、毎回、車両情報を入れ直す必要がなくなり、ユーザ負担を効果的に低減できる。
【0095】
例えば、1台だけ登録が可能な比較構成では、運転代行で利用する車両が変わった場合に、登録車両と、運転代行で利用する車両との間に齟齬が生じる。従って、このような齟齬が修正されないまま、運転代行依頼が生成されると、依頼側ユーザと受任側ユーザとが互いに異なる車両情報に基づいて、待ち合わせすることになり、円滑な待ち合わせが難しくなる。
【0096】
これに対して、本実施例によれば、かかる比較構成において生じる問題を解消できる。すなわち、運転代行で利用する車両が変わった場合には、依頼側ユーザが、変化後の登録車両を選択した上で、運転代行依頼を生成できるので、選択された登録車両と、運転代行で利用する車両との間に齟齬が生じる可能性を低減できる。
【0097】
また、本実施例によれば、登録車両ごとに詳細情報を登録できるので、詳細情報に基づいて、待ち合わせの円滑化を図ることができる。すなわち、受任側ユーザは、詳細情報を頼りに、待ち合わせ場所(駐車位置にある車両)を容易に特定できる。特に、詳細情報に車両の画像データが含まれる場合、受任側ユーザは、視覚的に、待ち合わせ場所(駐車位置にある車両)を容易に特定できる。
【0098】
また、本実施例によれば、運転代行依頼が、車両情報に対応付けられて生成されるので、受任側ユーザは、車両情報を閲覧して、受任の可否を判断できる。例えば、複数の運転代行依頼が競合する場合、受任側ユーザは、所望の車両情報に対応付けられる運転代行依頼を選択することも可能である。特に車両情報が詳細情報を含む場合、受任側ユーザは、詳細情報を受任の際の判断材料として有効に利用することも可能である。
【0099】
以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせることも可能である。
【0100】
例えば、本実施例において、詳細情報が車検情報を含む場合、車検切れの有無が定期的又は不定期的(例えば運転代行依頼入力用の入力画面SC1の出力時)にチェックされてもよい。そして、車検切れの場合、車検切れの登録車両は選択不能とされてもよい。また、車検切れが迫っている場合に、その旨のアラートを出力(通知)してもよい。
【符号の説明】
【0101】
1 情報処理システム(情報処理装置)
4 ネットワーク
21 依頼側ユーザ端末(情報処理装置)
23 処理装置
24 表示部
25 入力装置
26 GPS受信機
31 受任側ユーザ端末
100 情報処理サーバ
101 制御部
102 主記憶部
103 補助記憶部
104 ドライブ装置
105 記録媒体
106 ネットワークI/F部
107 入力部