特開 2024-84131 情報処理装置

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

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

(11)【公開番号】P2024084131

(43)【公開日】2024-06-24

(54)【発明の名称】情報処理装置

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20240617BHJP

【ＦＩ】

G06Q50/10

【審査請求】未請求

【請求項の数】1

【出願形態】ＯＬ

(21)【出願番号】P 2023202440

(22)【出願日】2023-11-30

(31)【優先権主張番号】P 2022197690

(32)【優先日】2022-12-12

(33)【優先権主張国・地域又は機関】JP

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】517356254

【氏名又は名称】テクノ株式会社

(74)【代理人】

【識別番号】110002871

【氏名又は名称】弁理士法人坂本国際特許商標事務所

(72)【発明者】

【氏名】松尾 博充

(57)【要約】      （修正有）

【課題】様々な地図ソフトの情報を有効利用することを可能とする情報処理装置を提供する。
【解決手段】情報処理装置は、地図ソフトに含まれて関連付けられている店名、名称及び住所の情報を、情報処理システムの記憶手段に読込み記憶し、依頼側ユーザ端末が実行する迎え先、お帰り先、お気に入り又は今日の駐車場に係る入力情報処理を実行する際に、地図ソフトの情報を読み込んで関連付け、情報処理システムの記憶手段に記憶する。
【選択図】図１４Ｂ

【特許請求の範囲】

【請求項1】

地図ソフトに含まれ、関連付けられている店名、名称、及び住所の情報を、情報処理システムの記憶手段に読込み記憶する情報処理装置において、
依頼側ユーザ端末が実行する迎え先、お帰り先、お気に入り、又は今日の駐車場に係る入力情報処理を実行する際に、前記地図ソフトの情報を読み込み関連付け、前記情報処理システムの記憶手段に記憶することを特徴とする情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

飲酒等の理由で自動車の運転ができない者の代わりに運転を行う運転代行サービスの管理に用いられる運転代行管理システムが知られている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかしながら、上記のような従来技術は、様々な地図ソフトに含まれている情報を情報処理システムの記憶手段に取り込み記憶し有効利用することは実行されていない。

【0005】

そこで、本開示は、様々な地図ソフトに含まれている情報を情報処理システムの記憶手段に取り込み記憶し有効利用することを目的とする。

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

【0006】

１つの側面では、地図ソフトに含まれ、関連付けられている店名、名称、及び住所の情報を、情報処理システムの記憶手段に読込み記憶する情報処理装置において、依頼側ユーザ端末が実行する迎え先、お帰り先、お気に入り、又は今日の駐車場に係る入力情報処理を実行する際に、前記地図ソフトの情報を読み込み関連付け、前記情報処理システムの記憶手段に記憶することを特徴とする。

【発明の効果】

【0007】

本開示によれば、様々な地図ソフトに含まれている情報を情報処理システムの記憶手段に取り込み記憶し有効利用することが可能となる。

【図面の簡単な説明】

【0008】

【図1】一実施例による情報処理システムの全体構成の概略図である。

【図2】情報処理サーバのハードウェア構成の一例を示す図である。

【図3】依頼側ユーザからの入力に応じて依頼側ユーザ端末により実行される処理の概略的な流れを示すフローチャートである。

【図4】情報処理サーバにより実行される処理のうちの、登録に関する処理の概略的な流れを示すフローチャートである。

【図5】情報処理サーバにより実行される処理のうちの、運転代行依頼に関する処理の概略的な流れを示すフローチャートである。

【図6】運転代行依頼に係る依頼情報の管理方法の一例を示す表図である。

【図7】受任側ユーザからの入力に応じて受任側ユーザ端末により実行される処理の概略的な流れを示すフローチャートである。

【図8】情報処理サーバにより実行される処理のうちの、受任に関する処理の概略的な流れを示すフローチャートである。

【図9】運転代行依頼入力用の入力画面の一例を示す図である。

【図10】ユーザインターフェースの拡大図である。

【図11】駐車位置入力用の入力画面の一例を示す図である。

【図12】登録済の駐車位置を利用して運転代行依頼を生成する際の、依頼側ユーザが行うアクションを示す概略的なフローチャートである。

【図13】駐車位置が登録済である場合のトップ画面の一例を示す図である。

【図14A】検索ワードから名称を住所に関連付けることを説明する説明図（その１）である。

【図14B】検索ワードから名称を住所に関連付けることを説明する説明図（その２）である。

【図14C】検索ワードから名称を住所に関連付けることを説明する説明図（その３）である。

【図15A】タップから名称を住所に関連付けることを説明する説明図（その１）である。

【図15B】タップから名称を住所に関連付けることを説明する説明図（その２）である。

【図16A】お気に入り、今日の駐車場から名称を住所に関連付けることを説明する説明図（その１）である。

【図16B】お気に入り、今日の駐車場から名称を住所に関連付けることを説明する説明図（その２）である。

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

【0009】

以下、添付図面を参照しながら各実施例について詳細に説明する。

【0010】

本明細書において、用語「対応付け」とは、直接的な対応付けのみならず、間接的な対応付けをも含む。例えば、要素Ａに要素Ｂが対応付けられている状態は、要素Ａに要素Ｂが対応付けられている状態のみならず、要素Ａに要素Ｃが対応付けられかつ要素Ｃに要素Ｂが対応付けられている状態をも含む概念である。これは、同様の用語「紐付け」についても同様である。

【0011】

図１は、一実施例による情報処理システム１の全体構成の概略図である。

【0012】

情報処理システム１は、情報処理サーバ１００を含む。

【0013】

情報処理サーバ１００は、ネットワーク４を介して各ユーザ端末２１、３１と通信可能である。すなわち、ユーザ端末２１、３１及び情報処理サーバ１００は、ネットワーク４を介して接続される。

【0014】

以下では、依頼側ユーザとは、運転代行サービスを受ける側のユーザを指し、受任側ユーザとは、運転代行を行う側のユーザを指す。そして、ユーザ端末２１は、依頼側ユーザにより利用される端末であり、「依頼側ユーザ端末２１」とも称する。また、ユーザ端末３１は、受任側ユーザにより利用される端末であり、以下、「受任側ユーザ端末３１」とも称する。なお、依頼側ユーザと受任側ユーザとは、その時点で依頼側か受任側かを表す形式的な用語であり、従って、ある時点で依頼側であるユーザが、他の時点で受任側になる場合もありうる。

【0015】

ネットワーク４は、インターネット、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、無線通信網、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでもよい。なお、ネットワーク４の一部又は全部は、Ｐ２Ｐネットワークにより実現されてもよい。

【0016】

ユーザ端末２１、３１は、それぞれ、例えばスマートフォンや携帯電話であるが、ウェアラブル端末（例えばスマートウォッチ、リング等）、タブレット端末、ラップトップ端末、デスクトップ端末等であってもよい。

【0017】

ユーザ端末２１、３１は、それぞれ、処理装置２３、３３、表示部２４、３４、入力装置２５、３５、及びＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機２６、３６を備える。処理装置２３、３３は、マイクロコンピュータのようなコンピュータであってよい。表示部２４、３４は、液晶ディスプレイや、有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等であってよい。入力装置２５、３５は、タッチパネル等であってよい。ＧＰＳ受信機２６、３６は、ＧＰＳ衛星からの衛星信号に基づいて、端末位置情報を生成してよい。

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

１ 情報処理システム（情報処理装置）
４ ネットワーク
２１ 依頼側ユーザ端末（情報処理装置）
２３ 処理装置
２４ 表示部
２５ 入力装置
２６ ＧＰＳ受信機
３１ 受任側ユーザ端末
１００ 情報処理サーバ
１０１ 制御部
１０２ 主記憶部
１０３ 補助記憶部
１０４ ドライブ装置
１０５ 記録媒体
１０６ ネットワークＩ／Ｆ部
１０７ 入力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14A】

【図14B】

【図14C】

【図15A】

【図15B】

【図16A】

【図16B】