WO2019082482A1 - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

実施形態に係る情報処理装置は、電気自動車のバッテリを充電する給電ステーションを予約する。情報処理装置は、バッテリ残量を示す第１情報、目的地に関する第２情報、及び経路に関する第３情報を受信する受信部と、第２情報と第３情報とに基づいて目的地に至るまでの推奨経路を検索する第１検索部と、給電ステーションを検索する第２検索部と、第１情報と推奨経路とに基づいて目的地に至るまでの間にバッテリの充電が必要か否かを判断する第１判断部と、バッテリの充電が必要と判断された場合、給電ステーションを、ユーザからの命令を待つことなく予約する予約部とを具備する。

Description

情報処理装置、情報処理方法、及び情報処理プログラム

　実施形態は、情報処理装置、情報処理方法、及び情報処理プログラムに関する。

　近年、電気自動車が普及してきている。更なる普及には、電気自動車のバッテリを充電する給電ステーションの環境整備が求められている。

特開２００３－２６２５２５号公報

　効率的に充電予約可能な情報処理装置、情報処理方法、及び情報処理プログラムを提供する。

　本実施形態の情報処理装置は、電気自動車のバッテリを充電する給電ステーションを予約するための情報処理装置である。情報処理装置は、受信部と、第１検索部と、第２検索部と、第１判断部と、予約部とを備える。受信部は、電気自動車のバッテリ残量を示す第１情報、目的地に関する第２情報、及び目的地に至るまでの経路に関する第３情報を受信する。第１検索部は、少なくとも第２情報と第３情報とに基づいて、目的地に至るまでの推奨経路を検索する。第２検索部は、目的地までの間にある給電ステーションを検索する。第１判断部は、第１情報と、検索された推奨経路とに基づいて、目的地に至るまでの間にバッテリの充電が必要か否かを判断する。予約部は、第１判断部においてバッテリの充電が必要と判断された場合、第２検索部において検索されたいずれかの給電ステーションを、ユーザからの命令を待つことなく予約する。

図１は、第１実施形態に係る電気自動車充電予約システムの概念図。 図２は、第１実施形態に係る電気自動車充電予約システムのブロック図。 図３は、第１実施形態に係る電気自動車のブロック図。 図４は、第１実施形態に係るスマートフォンのブロック図。 図５は、第１実施形態に係るサーバのブロック図。 図６Ａは、第１実施形態に係るサーバのブロック図。 図６Ｂは、第１実施形態に係るサーバのプロセッサの機能ブロック図。 図７は、第１実施形態に係るサーバのブロック図。 図８は、第１実施形態に係る給電ステーションの予約方法を示すフローチャート。 図９は、第１実施形態に係るルート探索方法を示すフローチャート。 図１０は、第１実施形態に係るスマートフォンまたはカーナビゲーションシステムの画面を示す模式図。 図１１は、第１実施形態に係るスマートフォンまたはカーナビゲーションシステムの画面を示す模式図。 図１２は、第１実施形態に係るスマートフォンまたはカーナビゲーションシステムの画面を示す模式図。 図１３は、第１実施形態に係るスマートフォンの画面を示す模式図。 図１４は、第１実施形態に係るスマートフォンの画面を示す模式図。 図１５は、第１実施形態に係るスマートフォンの画面を示す模式図。 図１６は、第１実施形態に係るスマートフォンの画面を示す模式図。 図１７は、第１実施形態に係るスマートフォンの画面を示す模式図。 図１８は、第２実施形態に係る給電ステーションの予約方法を示すフローチャート。 図１９Ａは、第３実施形態に係るサーバの機能ブロック図。 図１９Ｂは、第３実施形態の第１例に係る給電ステーションの予約方法を示すフローチャート。 図２０は、第３実施形態の第１例に係る電気自動車の予約状況を示す画面の模式図。 図２１は、第３実施形態の第１例に係る電気自動車の予約状況を示す画面の模式図。 図２２は、第３実施形態の第２例に係る給電ステーションの予約方法を示すフローチャート。 図２３は、第３実施形態の第２例に係る電気自動車の予約状況を示す画面の模式図。 図２４は、第３実施形態の第２例に係る電気自動車の予約状況を示す画面の模式図。 図２５は、第３実施形態の第２例に係る電気自動車の予約状況を示す画面の模式図。 図２６は、第４実施形態に係る電気自動車充電予約システムのブロック図。 図２７は、第４実施形態に係るスマートフォンのブロック図。 図２８は、第４実施形態に係る給電ステーションの予約方法を示すフローチャート。 図２９は、第５実施形態に係る電気自動車充電予約システムの概念図。 図３０は、第５実施形態に係る電気自動車充電予約システムのブロック図。 図３１は、第５実施形態に係るカーナビゲーションシステムのブロック図。 図３２は、第５実施形態に係る給電ステーションの予約方法を示すフローチャート。 図３３は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図３４は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図３５は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図３６は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図３７は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図３８は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図３９は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図４０は、第５実施形態に係るカーナビゲーションシステムの画面を示す模式図。 図４１は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４２は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４３は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４４は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４５は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４６は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４７は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４８は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図４９は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図５０は、第５実施形態に係るスマートフォン及びカーナビゲーションシステムの画面を示す模式図。 図５１は、第６実施形態に係る電気自動車充電予約システムのブロック図。 図５２は、第６実施形態に係るカーナビゲーションシステムのブロック図。 図５３は、第６実施形態に係る給電ステーションの予約方法を示すフローチャート。 図５４は、第６実施形態に係る電気自動車充電予約システムのブロック図。 図５５は、第６実施形態に係るカーナビゲーションシステムのブロック図。 図５６は、第６実施形態に係る給電ステーションの予約方法を示すフローチャート。 図５７は、第１乃至第６実施形態の変形例に係る電気自動車充電予約システムのブロック図。 図５８は、第１乃至第６実施形態の変形例に係る電気自動車及び給電ステーションのブロック図。 図５９は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６０は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６１は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６２は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６３は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６４は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６５は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。 図６６は、第１乃至第６実施形態の変形例に係るカーナビゲーションシステムの画面を示す模式図。

実施形態

　以下、図面を参照して実施形態について説明する。なお、以下の説明において、同一の機能及び構成を有する構成要素については、共通する参照符号を付す。

　１．第１実施形態　
　第１実施形態に係る情報処理装置、情報処理方法、及び情報処理プログラムについて説明する。本実施形態は、電気自動車の給電ステーションの予約システムに関するものである。

　１．１　構成について　
　１．１．１　全体構成について　
　図１は、本実施形態に係る予約システムの構成例を示している。図示するように予約システム１は、電気自動車１００、携帯情報端末２００、並びにサーバ３００、４００、及び５００を備えている。以下では、携帯情報端末がスマートフォン２００である場合を例に説明するが、携帯電話、タブレットＰＣ、ノートＰＣなどの携帯可能な情報通信端末であれば良い。スマートフォン２００は、例えば無線通信により、ネットワーク６００を介して、サーバ３００、４００、及び５００と通信可能である。

　電気自動車１００もまた無線通信機能を有し、ネットワーク６００を介して、サーバ３００、４００、及び５００と通信可能である。

　サーバ３００、４００、及び５００は、電気自動車１００やスマートフォン２００からの要求に応じて種々の演算を行い、様々な情報を電気自動車１００及びスマートフォン２００に提供する。

　図２は、図１に示す予約システム１のブロック図である。図示するように、スマートフォン２００は、ユーザから各種設定情報を受け付け、受け付けた情報（ユーザ設定情報）をサーバ４００へ送信する。またスマートフォン２００は、サーバ４００から推奨ルートに関する情報を受信する。

　電気自動車１００は、サーバ４００からのリクエストに従って、バッテリ残量に関する情報をサーバ４００へ送信する。

　サーバ３００は、道路の渋滞情報を保持する。そしてサーバ３００は、サーバ４００からのリクエストに従って、渋滞情報を送信する。渋滞情報は、現在の渋滞情報だけでなく、今後予測される渋滞予測情報や、事故情報、また災害などによる交通止め情報など、あらゆる交通情報を含み、サーバ４００へ提供される。更に渋滞情報は、交通情報のみならず、例えば山道や高速道路など、バッテリ１１０の消費速度に影響にある例えば道路情報を含んでも良い。

　サーバ５００は、電気自動車の給電ステーションに関する情報を保持する。この情報には、複数の場所に設けられた給電ステーションの位置情報などを示す給電ステーション情報と、各給電ステーション情報における予約状況を示す予約情報を含む。そしてサーバ５００は、サーバ４００からのリクエストに従って給電ステーション情報及び予約情報を送信し、またサーバ４００からの給電ステーションの予約を受け付ける。そして予約を受け付けた際には、サーバ５００は予約情報を更新し、予約完了情報をサーバ４００へ送信する。なお、図面ではその紙面の都合上、「給電ステーション」を「給電ｓｔ」と表記する場合がある。

　サーバ４００は、電気自動車１００の情報を管理する。すなわちサーバ４００は、スマートフォン２００からのユーザ設定情報、電気自動車１００からのバッテリ残量情報、サーバ３００からの渋滞情報、及びサーバ５００からの給電ステーション情報に従って、ユーザの目的地への推奨ルートを算出し、推奨ルート情報をスマートフォン２００へ送信する。またサーバ４００は、推奨ルート内においてバッテリ１１０の充電が必要か否かを予測し、必要と予測される場合には、サーバ５００に対して給電ステーションの仮予約及び本予約を行う。

　なお、サーバ３００は公的な機関が提供するものであっても良いし、これに対してサーバ５００は給電ステーションを運営する事業者が提供し、サーバ４００は本予約システムを運営する事業者が提供するものであっても良い。しかし、サーバ３００、４００、５００の提供者はこれらに限らず、種々の事業者や個人が提供して良い。

　次に、上記電気自動車１００、スマートフォン２００、並びにサーバ３００、４００、及び５００について説明する。

　１．１．２　電気自動車１００の構成　
　まず、上記電気自動車１００の構成について図３を用いて説明する。図３は、電気自動車の１００の、特に予約システムに関する部分の構成例を示すブロック図である。図示するように電気自動車１００は、バッテリ１１０、バッテリ監視ユニット１２０、制御部１３０、及び通信部１４０を備えている。

　バッテリ１１０は、電気自動車１００を駆動するためのものである。

　バッテリ監視ユニット（例えばバッテリ監視回路）１２０は、バッテリ１１０の残量を監視する。バッテリ残量の監視は、時間的に連続的に行われても良いし、あるいは一定時間毎に行われても良い。またバッテリ監視ユニット１２０は、バッテリ１１０の例えば充電回数をカウントする。なぜなら、バッテリ１１０は充電を繰り返す度に劣化する。従ってバッテリ監視ユニット１２０は、バッテリ１１０の例えば充電回数をカウントすることにより、バッテリ残量だけでなく、バッテリ１１０の劣化度合いも監視する。

　通信部１４０は、無線通信によりサーバ４００との間で情報を送受信可能な、例えば通信用回路である。例えば通信部１４０は、サーバ４００からバッテリ残量情報リクエストを受信する。すると通信部１４０は、制御部１３０から受信したバッテリ残量情報をサーバ４００へ送信する。バッテリ残量情報は、バッテリ１１０の残量だけでなく、上述したバッテリ１１０の劣化度合いに関する情報を含んでも良い。劣化度合いに関する情報を送信することで、サーバ４００は、将来におけるバッテリ１１０の消費予測をより精密に行うことができる。

　制御部１３０は、電気自動車１００における予約システムに関する処理を制御する。制御部１３０は、例えば制御回路を含む、あるいは制御回路からなる、例えばＣＰＵなどのプロセッサ１３１（以下で登場するプロセッサ２３１、３３１、４３１、５３１、７３１も同様である）、ＲＯＭ１３２、ＲＡＭ１３３、及び入出力回路１３４を備えている。ＲＯＭ１３２は、プロセッサ１３１によって実行されるプログラムや必要なデータを保持する。ＲＡＭ１３３は、プロセッサ１３１の作業領域として機能する。入出力回路１３４は、通信部１４０との間の情報の送受信を司る。プロセッサ１３１は、ＲＯＭ１３２内のプログラムを実行することにより、予約システムに関する処理を実行する。例えば、入出力回路１３４を介してバッテリ残量情報のリクエストを受信すると、プロセッサ１３１は、バッテリ監視ユニット１２０に対して、現在のバッテリ１１０の残量情報を要求する。これに応答して、バッテリ監視ユニット１２０は、バッテリ残量情報をプロセッサ１３１へ送信する。そしてプロセッサ１３１は、バッテリ残量情報を、通信部１４０へ送信する。なおプロセッサ１３１は、現在のバッテリ残量だけでなく、サーバ４００からのリクエストに応じて、例えば数時間後、または数日後のバッテリ残量の予測値をサーバ４００へ送信しても良い。この際には、例えばＲＯＭ１３２やＲＡＭ１３３に保持された、現在のバッテリの消耗度や、過去におけるバッテリの消費率を用いてプロセッサ１３１が計算する。以下では、「バッテリ残量情報」なる文言には、これらの情報も含まれるものとする。

　１．１．３　スマートフォン２００の構成　
　次に、上記スマートフォン２００の構成について図４を用いて説明する。図４はスマートフォン２００の構成例を示すブロック図である。図示するようにスマートフォン２００は、表示部２１０、ユーザ入力部２２０、制御部２３０、及び通信部２４０を備えている。

　表示部２１０は、ユーザに対して種々の情報を提示し、例えば液晶ディスプレイなどである。

　ユーザ入力部２２０は、ユーザからの種々の情報や命令の入力（これをユーザ設定情報と呼ぶ）を受け付ける。例えば、表示部２１０がタッチパネル型の表示装置であって、表示部２１０とユーザ入力部２２０とが一体となっていても良い。

　通信部２４０は、無線通信によりサーバ４００との間で情報を送受信する。例えば通信部２４０は、サーバ４００に対して、ユーザ入力部２２０で受け付けたユーザ設定情報をサーバ４００へ送信し、またサーバ４００から推奨ルート情報を受信する。

　制御部２３０は、スマートフォン２００全体の処理を制御する。制御部２３０は、ＣＰＵなどのプロセッサ２３１、ＲＯＭ２３２、ＲＡＭ２３３、及び入出力回路２３４を備えている。ＲＯＭ２３２は、プロセッサ２３１によって実行されるプログラムや必要なデータを保持する。ＲＡＭ２３３は、プロセッサ２３１の作業領域として機能する。入出力回路２３４は、通信部２４０との間の情報の送受信を司る。プロセッサ２３１は、ＲＯＭ２３２内のプログラムを実行することにより、予約システムに関する処理を含む、スマートフォン２００の持つ種々の機能を実現する。例えばプロセッサ２３１は、ユーザ入力部２２０で受け付けたユーザ設定情報を例えばＲＡＭ２３３に保持させる。ユーザ設定情報の具体例は、例えば電気自動車１００を運転する日時、目的地、または優先順位に関する情報などである。優先順位とは、目的地へのルート探索において、高速道路を使うか否か、またバッテリ１１０の充電ルールなどである。充電ルールとは、バッテリ１１０に許す最低残量や、給電ステーションにおいて許容できる待ち時間などのうち、どれを優先するか、といった情報である。

　１．１．４　サーバ３００の構成　
　次に、上記サーバ３００の構成について図５を用いて説明する。図５はサーバ３００の構成例を示すブロック図である。図示するようにサーバ３００は、制御部３３０及び通信部３４０を備えている。

　通信部３４０は、無線通信によりサーバ４００との間で情報を送受信する。例えば通信部３４０は、サーバ４００から渋滞情報リクエストを受信する。すると通信部３４０は、制御部３３０から受信した渋滞情報をサーバ４００へ送信する。

　制御部３３０は、渋滞情報をリアルタイムに保持する。すなわち制御部３３０は、ＣＰＵなどのプロセッサ３３１、ＲＯＭ３３２、ＲＡＭ３３３、及び入出力回路３３４を備えている。ＲＯＭ３３２は、プロセッサ３３１によって実行されるプログラムや必要なデータを保持する。ＲＡＭ３３３は、プロセッサ３３１の作業領域として機能すると共に、渋滞情報３３５を保持する。渋滞情報３３５は、現在の渋滞の状況だけでなく、過去の渋滞情報を含んでいても良い。これにより、将来の渋滞予測が可能となる。前述の通り、本明細書において「渋滞情報」は、渋滞に関する情報だけでなく、事故情報や、現在及び将来の交通止め情報など、種々の交通情報を含む。入出力回路３３４は、通信部３４０との間の情報の送受信を司る。プロセッサ３３１は、ＲＯＭ３３２内のプログラムを実行することにより、予約システムに関する処理を実行する。例えば、入出力回路３３４を介して渋滞情報３３５のリクエストを受信すると、プロセッサ３３１は、ＲＡＭ３３３から読み出した渋滞情報３３５を、通信部３４０を介してサーバ４００へ送信する。更にプロセッサ３３１は、現在日時に応じた渋滞予測を行い、得られた渋滞予測情報をサーバ４００へ送信しても良い。

　１．１．５　サーバ４００の構成　
　次に、上記サーバ４００の構成について図６Ａを用いて説明する。図６Ａはサーバ４００の構成例を示すブロック図である。図示するようにサーバ４００は、制御部４３０及び通信部４４０を備えている。

　通信部４４０は、無線通信により電気自動車１００、スマートフォン２００、サーバ３００、及びサーバ５００との間で情報を送受信する。なお、サーバ３００及び５００との間は有線での通信であっても良いし、またはサーバ３００、４００、及び５００のいずれか２つまたは全てが１つのサーバによって実現されても良い。そして通信部４４０は、電気自動車１００に対してバッテリ残量情報のリクエストを送信し、サーバ３００に対して渋滞情報のリクエストを送信し、サーバ５００に対して、後述する給電ステーション情報のリクエスト、予約情報のリクエスト、及び予約のリクエストを送信し、スマートフォン２００に対して推奨ルート情報を送信する。更に通信部４４０は、電気自動車１００からバッテリ残量情報を受信し、スマートフォン２００からユーザ設定情報を受信し、サーバ３００から渋滞情報を受信し、サーバ５００から、給電ステーション情報、予約情報、及び予約完了情報を受信する。

　制御部４３０は、ＣＰＵなどのプロセッサ４３１、ＲＯＭ４３２、ＲＡＭ４３３、及び入出力回路４３４を備えている。ＲＯＭ４３２は、プロセッサ３３１によって実行されるプログラムや必要なデータを保持する。ＲＡＭ４３３は、プロセッサ４３１の作業領域として機能すると共に、通信部４４０で受信したユーザ設定情報４３６、バッテリ残量情報４３７、渋滞情報３３５、給電ステーション情報５３５、及び予約情報５３６を保持する。更にＲＡＭ４３３は、ルート検索プログラム４３５及び地図情報４３８を保持する。入出力回路４３４は、通信部４４０との間の情報の送受信を司る。プロセッサ４３１は、上記情報４３６、４３７、４３８、３３５、５３５、及び５３６を用いてルート検索プログラム４３５を実行することで、ユーザに最適と思われる推奨ルートを算出する。例えばプロセッサ４３１は、地図情報４３８上における出発地と目的地を把握し、両者を結ぶルートのうち、渋滞情報３３５に基づく速達性、バッテリ残量情報４３７、給電ステーション情報５３５、及び予約情報５３６に基づく給電ステーション予約容易性、並びにユーザ設定情報４３６に基づくユーザ指向性に基づいて、推奨ルートを算出する。このようにして算出された推奨ルート情報が、スマートフォン２００に送信される。また、必要に応じてサーバ５００に対して給電ステーションの予約命令を発行する。本実施形態における給電ステーションの予約には、仮予約と本予約とが含まれる。例えば本例では、仮予約は、一定の期限まで本予約をしないとキャンセルされる予約であり、ユーザの承認無しに行うことが可能である。他方で本予約は確定した予約であり、キャンセルされない限り有効であり、ユーザの承認に基づいて行われる。もちろん、予約の形態はこれに限られず、例えば下記の記載における「予約」は全て本予約である場合であっても良い。また、仮予約は、一定の期限までユーザによる本予約が承認も否認もされない場合には、自動的に本予約に変更される場合であっても良い。但し、以下では先に述べたように、下記のように定義する。　
　・仮予約：一定の期限まで本予約をしないとキャンセルされる。ユーザの承認無しに行うことが可能。キャンセル要求によってキャンセルすることも可能。　
　・本予約：確定した予約。キャンセルするには、キャンセル要求を改めて出す必要がある。本予約を行うためには、ユーザの承認が必要。　
　なお、仮予約と本予約とを区別しない場合には、単に「予約」と呼ぶことがある。

　図６Ｂは、ルート検索プログラム４３５を実行した際におけるプロセッサ４３１（または制御部４３０全体）の機能ブロック図である。図６Ｂに示すようにプロセッサ４３１は、プログラム４３５を実行することにより、受信部４５０、第１検索部４５１、第２検索部４５２、第１判断部４５３、予約部４５４、及び第２判断部４５５として機能する。

　受信部４５０は、通信部４４０を介して、バッテリ１１０の残量を示す第１情報（バッテリ残量情報４３７）を電気自動車１００から受信し、目的地に関する第２情報（ユーザ設定情報４３６）をスマートフォン２００から受信し、更に目的地に至るまでの経路に関する第３情報（渋滞情報３３５）を受信する。受信部４５０は、サーバ５００から、給電ステーション情報５３５、予約情報５３６、及び予約完了情報を受信しても良い。

　第１検索部４５１は、少なくとも第２情報４３６と第３情報３３５とに基づいて、目的地に至るまでの推奨経路を検索する。第２検索部４５２は、第３情報３３５と、給電ステーション情報５３５及び予約情報５３６とに基づいて、目的地までの間にあり、予約可能な給電ステーションを検索する。

　第１判断部４５３は、第１情報４３７と、第１検索部４５１によって探索された推奨経路とに基づいて、目的地に至るまでの間にバッテリ１１０の充電が必要か否かを判断する。そして予約部４５４は、第１判断部においてバッテリ１１０の充電が必要と判断された場合、第２検索部４５２において検索されたいずれかの給電ステーションを、ユーザからの命令を待つことなく仮予約する。

　なお、第２判断部４５５は、その詳細については第２実施形態で説明するが、少なくとも第３情報３３５に基づいて、予約部４５４において行った仮予約の通りに電気自動車１００が給電ステーションに到着できるか否かを判断する。この判断は、第３情報３３５だけでなく、更に第１情報４３７に基づいても良い。そして予約部４５４は、仮予約の通りに給電ステーションに到着できないと第２判断部４５５が判断した場合、当該予約をキャンセルして、次に推奨されるいずれかの給電ステーションを、ユーザからの命令を待つことなく仮予約する。

　１．１．６　サーバ５００の構成　
　次に、上記サーバ５００の構成について図７を用いて説明する。図７はサーバ５００の構成例を示すブロック図である。図示するようにサーバ５００は、制御部５３０及び通信部５４０を備えている。

　通信部５４０は、無線通信によりサーバ４００との間で情報を送受信する。例えば通信部５４０は、サーバ４００から、給電ステーション情報のリクエスト、予約情報のリクエスト、及び仮予約または本予約のリクエストを受信する。また通信部５４０は、制御部５３０から受信した給電ステーション情報、予約情報、及び予約完了情報をサーバ４００へ送信する。

　制御部５３０は、給電ステーションに関する情報をリアルタイムに保持する。すなわち制御部５３０は、ＣＰＵなどのプロセッサ５３１、ＲＯＭ５３２、ＲＡＭ５３３、及び入出力回路５３４を備えている。ＲＯＭ５３２は、プロセッサ５３１によって実行されるプログラムや必要なデータを保持する。ＲＡＭ５３３は、プロセッサ５３１の作業領域として機能すると共に、給電ステーション情報５３５及び予約情報５３６を保持する。給電ステーション情報５３５は、給電ステーションの位置や、同時に給電可能な自動車台数、給電に要する時間などの情報を含む。また予約情報５３６は、給電ステーションの現在の予約状況を含む。これらの情報は、例えば通信部５４０が給電ステーションから受信され、ＲＡＭ５３３に記憶される。入出力回路５３４は、通信部５４０との間の情報の送受信を司る。プロセッサ５３１は、ＲＯＭ５３２内のプログラムを実行することにより、予約システムに関する処理を実行する。例えば、入出力回路５３４を介して給電ステーション情報及び予約情報のリクエストを受信すると、プロセッサ５３１は、ＲＡＭ５３３から読み出した給電ステーション情報５３５及び予約情報５３６を、通信部５４０を介してサーバ４００へ送信する。更にプロセッサ５３１は、サーバ４００から仮予約リクエストを受信すると、予約情報５３６を参照して、予約が可能か否かを判断し、予約可能な場合には仮予約を登録し、その旨を予約完了情報としてサーバ４００へ送信する。そして、この予約情報は、通信部５４０により、対応する給電ステーションに送信される。また、予約できない場合にも、その旨をサーバ４００へ送信する。この際、予約可能な時間帯に関する情報を送信しても良い。また、サーバ４００から本予約のリクエストを受信した場合も同様である。なお仮予約は、例えば予約時間になってもユーザが給電ステーションに到着しない、または到着する見込みがないことが明らかになった時点で、例えばサーバ４００の命令によってプロセッサ５３１がキャンセルしても良い。

　１．２　動作について　
　次に、本実施形態に係る電気自動車の給電ステーションの予約システム１の動作について説明する。

　１．２．１　動作の全体の流れについて　
　まず、予約システムの全体の流れについて、図８を用いて説明する。図８は、ユーザが電気自動車１００に乗車してから、あるいは電気自動車１００に乗車することを決定した際（乗車自体は翌日などであってもよい）の、スマートフォン２００、サーバ４００（サーバ３００及び５００の動作も含む）、及び電気自動車１００の、給電ステーションの予約に関する動作を示すフローチャートである。なお、以下におけるサーバ４００の処理は、プロセッサ４３１がプログラム４３５を実行することにより、主として制御部４３０によって実現される。

　図示するように、まずスマートフォン２００は、ユーザからのユーザ設定情報を受け付ける（ステップＳ１０）。すなわちスマートフォン２００は、ユーザによる日時登録や、行程（目的地・経由地）登録、及び優先順位設定を受け付ける。優先順位の具体例は、先にも説明したが、例えばルート探索において、高速道路などの有料道路を使うか否かに加えて、充電ポリシーに関する情報も含む。これには例えば以下のような情報が含まれる。すなわち、　
　・バッテリ１１０の残量が例えば２０％を切らないように給電を行う。　
　・経路に近い給電ステーションが混雑している場合には、最終的に早く目的地に到着できるのであれば、遠回りしても遠くの給電ステーションを予約する。　
　・逆に、ある程度待っても、無駄にバッテリを消費しないよう、最寄りの給電ステーションを選択する。　
　などである。

　スマートフォン２００は、これらの情報４３６をサーバ４００に送信し、サーバ４００は、受信した情報４３６をＲＡＭ４３３に保持する。そしてサーバ４００（第１検索部４５１）は、ルート探索を開始する（ステップＳ１１）。すなわち、例えば電気自動車１００やスマートフォン２００のＧＰＳ機能、あるいはユーザによって入力された情報により、ユーザ（電気自動車１００）の現在位置を取得すると共に、電気自動車１００からバッテリ残量情報４３７を取得する（ステップＳ１２、Ｓ１３）。引き続きサーバ４００は、サーバ３００から渋滞情報３３５を取得し（ステップＳ１４）、更にサーバ５００から給電ステーション情報５３５と予約情報５３６を取得する（ステップＳ１４、Ｓ１５）。

　そしてサーバ４００（第１判断部４５３）は、充電の必要性を判断する（ステップＳ１６）。この判断は、プロセッサ４３１が、ステップＳ１１～Ｓ１４で得た情報に基づいて行う。すなわち、目的地までの距離と交通状況を鑑みた際に、現在のバッテリの充電状態で目的地にたどり着けるか否か、またたどり着けるとしても、ユーザの充電ポリシーを鑑みた際に、充電を行うべきか否か、などに基づいて決定する。引き続きプロセッサ４３１は、ステップＳ１６の結果に基づき、目的地までの推奨ルートを決定する（ステップＳ１７）。そしてプロセッサ４３１は、ステップＳ１６において充電が必要だと判断した場合には、ステップＳ１７で決定されたルート内における給電ステーションを検索する（第２検索部４５２）と共に、検索された給電ステーションのうち、最も推奨される給電ステーションを、サーバ５００に対して仮予約する（予約部４５４、ステップＳ１８）。この際、プロセッサ４３１（第２検索部４５２）は、サーバ５００から受信した給電ステーション情報５３５と予約情報５３６とに基づいて、推奨される給電ステーションを決定する。すなわち、現在のバッテリ残量が極めて少ない場合には、予約情報５３６において待ち時間が長くなっても、最寄りの給電ステーションを仮予約する。他方で、バッテリ残量に余裕がある場合には、例えば現在地から遠い距離であっても、待ち時間の少ない、あるいは充電に要する時間が短くて済む給電ステーションを仮予約する、などである。または、移動距離は長くなるが、混雑の程度が最も低く、その結果として目的地に最も早く到着できる給電ステーションを仮予約する、などであっても良い。そしてサーバ４００は、推奨ルート情報をスマートフォン２００に送信する。

　スマートフォン２００は、受信した推奨ルートを表示部２１０に表示する（ステップＳ１９）。この際、表示部２１０は、仮予約された給電ステーションに関する情報も表示する。そしてスマートフォン２００は、サーバ４００による給電ステーションの仮予約の承認または否認をユーザ入力部２２０においてユーザから受け付けると（ステップＳ２１）、その旨をサーバ４００へ送信する。承認されなかった場合（ステップＳ２０、ＮＯ）、サーバ４００のプロセッサ４３１はステップＳ１６～Ｓ１８の処理を繰り返す。すなわちサーバ４００は、次の推奨ルートを計算し、必要があれば給電ステーションの仮予約を行う。

　なお、ステップＳ１６～Ｓ１８の処理を繰り返した結果、ユーザに否認されたルートが再度検索される場合があり得る。従ってサーバ４００のプロセッサ４３１は、ユーザに否認されたルートにフラグを立てるなどすることにより、否認されたルートが再提案されないようにしても良い。更に／または、サーバ４００のプロセッサ４３１は、ユーザに否認されたルートと共に、新たに検索されたルートに優先順位を付けても良い。この優先順位は、サーバ４００がユーザに推奨する順番を示す。優先順位を付ける場合、例えば図８のフローチャートにおいて、ステップＳ１６～Ｓ１８を複数回繰り返すことで、ステップＳ１９でユーザに複数のルートを優先順位と共に提示しても良い。

　また、ステップＳ１０からユーザからの承認（ステップＳ２０）を得るまでにタイムラグがある場合には、具体的には、推奨ルートを提示してからある閾値に相当する期間が経っても承認されない場合には、サーバ４００はステップＳ１２及びＳ１４の処理を行い、更にステップＳ１６～Ｓ１８の処理を行って、推奨するルートを更新しても良い。

　承認された場合（ステップＳ２１）、プロセッサ４３１は、ステップＳ１０で受信したユーザ設定情報に、更に決定された推奨ルート及び給電ステーション情報を登録する（ステップＳ２１）。更にサーバ４００のプロセッサ４３１（予約部４５４）は、サーバ５００に対して、ステップＳ１８で行った仮予約を本予約に変更する（ステップＳ２２）。この仮予約及び本予約に関する情報は、例えばサーバ５００の予約情報５３６に登録される。そして、本登録が完了すると、サーバ４００は、確定ルート情報をスマートフォン２００に送信し、スマートフォン２００は受信した確定ルートを表示部２１０に表示する（ステップＳ２３）。

　図９は、サーバ４００におけるルート探索の基本的な考え方を示しており、特にバッテリ１１０の充電の必要性の有無に応じた処理のフローチャートである。図９に示す処理は、図６Ｂにおける例えば第１検索部４５１、第２検索部４５２、及び第１判断部４５３によって実行される。

　図示するように、ユーザ設定情報において目的地が設定されており（ステップＳ３０、ＹＥＳ）、更にバッテリ１１０の充電が必要とプロセッサ４３１が判断すれば（ステップＳ３１、ＹＥＳ）、プロセッサ４３１は、いずれかの給電ステーションを経由して目的地に到達するルートを探索する（ステップＳ３２）。この際には、前述の通り給電ステーションへの仮予約も行われる（予約部４５４）。他方、ステップＳ３１においてバッテリ１１０の充電は不要と判断されれば（ステップＳ３１、ＮＯ）、プロセッサ４３１は目的地へのルートを探索するが、その際に給電ステーションを経由するか否かは考慮しない（ステップＳ３３）。

　なお、ステップＳ３１及びＳ３４における充電の必要性の判断は、例えばプロセッサ４３１ではなくユーザが行う場合であっても良い。より具体的には、例えばスマートフォン２００は、ユーザからの充電の必要性についての情報を受け付け、その旨の情報をサーバ４００へ送信する。するとサーバ４００は、受信した情報に従って、ステップＳ３２、Ｓ３３、Ｓ３５、またはＳ３６の処理を実行する。

　ステップＳ３０において目的地が設定されておらず（ステップＳ３０、ＮＯ）、更にバッテリ１１０の充電が必要と判断されれば（ステップＳ３４、ＹＥＳ）、プロセッサ４３１は、最も推奨される給電ステーションへのルートを探索する（ステップＳ３５）。この際にも、給電ステーションへの仮予約が行われる。この場合に最も推奨される給電ステーションとは、例えば現在位置から最も近い給電ステーション、または現在位置からの最寄りではないが、待ち時間の少ない給電ステーションなど、である。目的地が設定されておらず（ステップＳ３０、ＮＯ）、更にバッテリ１１０の充電も不要であれば（ステップＳ３４、ＮＯ）、プロセッサ４３１はルート探索を行わない（ステップＳ３６）。

　１．２．２　動作の具体例について　
　次に、上記図８で説明した動作の具体例について説明する。図１０は、電気自動車の例えばインストルメンタルパネル（カーナビゲーションシステムの表示画面（ホーム画面）であっても良い）の表示画面の一例である。もちろん、バッテリ残量情報４３７を受信できるのであれば、スマートフォン２００の表示部２１０が図１０のような画面を表示しても良い。図示するように、表示画面には、現在のバッテリ１１０の充電量が表示されている。図１０の例であると、バッテリ１１０の充電量は３４％であり、完全充電状態の約１／３ほどしか残量がないことを示している。

　図１１及び図１２は、スマートフォン２００の表示部２１０における表示画面の一例であり、図８におけるステップＳ１０の様子を示している。図１１及び図１２は、例えば本例で説明する予約システム１のアプリを起動することによって、表示される。予約システムのアプリは、例えばＲＡＭ１３３などに保持されたプログラムをプロセッサ２３１が実行することにより実現される。

　アプリが実行されると、例えば図１１に示すように、表示部２１０はカレンダーを表示し、電気自動車１００の乗車日のユーザからの入力を受け付ける。図１２は、往路設定の受け付け画面の一例を示す。図１２の例であると、出発時刻や目的地などを設定できる。これらの情報が入力されると、その情報はユーザ設定情報４３６としてサーバ４００に送信される。

　なお、スマートフォン２００にダウンロードされたアプリには、事前にユーザによって特定の電気自動車１００または複数の電気自動車１００が登録される。そして、乗車の日程と、充電のタイミングのスケジュールが、複数のアプリ使用者によって共有されても良い。この一例については、第３実施形態で説明する。

　図１３は、図８におけるステップＳ１９で説明した、推奨ルートの表示されたスマートフォン２００の表示部２１０の表示例を示す。図１３の例であると、川崎が出発地で、目的地は鎌倉に設定されている。そして、図中において太線で示したのが推奨ルートである。更にサーバ４００は、川崎から最も近い給電ステーション（Station A）を推奨し、ユーザの承認を待つこと無く、１６：５５に仮予約を入れている。この仮予約は、サーバ４００が推奨ルートを算出する過程でサーバ４００が行う。但し、この時点では仮予約であるので、スマートフォン２００は本予約してよいか否かの入力をユーザに促す。

　ユーザがStation A以外の給電ステーションを希望する場合には、図１４に示すように、例えば表示部２１０に表示された「もっと見る」なるアイコンを選択する。このアイコンが選択されると、図１５に示すようにスマートフォン２００は、サーバ４００によって得られたその他の推奨ルートを表示する。図示するように、第２推奨ルートは、Station Aよりも遠い給電ステーション（Station B）を推奨する。図１５では、Station Bの仮予約がなされていないが、サーバ４００はこの時点でStation Bについての仮予約を行っても良い。また、図１５に示すように、Station Bについての「もっと見る」なるアイコンが選択されると、予約可能な時間帯が表示される。この情報は、サーバ４００がサーバ５００から受信した、Station Bに関する予約情報５３６に基づいて表示される。この時間帯のうち、例えば１８：５０という時間帯の選択をユーザから受け付けたとする。すると、スマートフォン２００は、この情報をサーバ４００に送信し、必要に応じてサーバ５００に対して仮予約を行う。引き続きスマートフォン２００は、本予約してよいか否かの入力をユーザに促す。図１６の例であると、「ＹＥＳ」アイコンが選択されることで、サーバ４００はサーバ５００に対して、Station Bの１８：５０の本予約を行う。

　図１７は、ユーザが第３推奨ルートを選択した場合を示す。第３推奨ルートは給電ステーションでの充電を行わない。よって、この場合には、いずれの給電ステーションも予約されない。

　以上のように、サーバ４００は、ユーザ設定情報などに基づいて複数の推奨ルートを推奨順に提示すると共に、給電ステーションの仮予約を行い、選択された推奨ルートに基づき本予約を行う。

　１．３　本実施形態に係る効果　
　本実施形態によれば、電気自動車の効率的な充電予約が可能となる。本効果につき、以下説明する。

　近年、電気自動車が急速に普及しているが、更なる普及のためには、バッテリに対するユーザの不安を払拭する必要がある。その一方で、渋滞予測などの精度向上により、ナビゲーションシステムにおいて目的地への到着時刻予測の精度も向上している。

　そこで本実施形態では、渋滞予測などに基づくルート検索に加えて、バッテリ１１０の残量（残量情報４３７）、給電ステーションに関する情報（給電ステーション情報５３５、予約情報５３６）、及びユーザの希望（ユーザ設定情報４３６）に基づいて、検索されたルートにおいて推奨される給電ステーションを、ユーザによる要求を待つこと無く、サーバ４００が自発的に仮予約する。そして、サーバ４００による提案をユーザが受け付けた際には、サーバ４００は給電ステーションを本予約する。

　本構成によれば、サーバ４００が、バッテリ切れが起こらないよう最適な給電タイミングでの給電ステーションの仮予約を行ったルートをユーザに提案する。そのため、バッテリ切れに対するユーザの不安を緩和し、またバッテリ切れを考慮してユーザが給電ステーションの場所を探索し予約するなどの煩雑さを解消し、給電ステーションの効率的な予約が可能となる。

　２．第２実施形態　
　次に、第２実施形態に係る情報処理装置、情報処理方法、及び情報処理プログラムについて説明する。本実施形態は、上記第１実施形態において、給電ステーションの本予約後に、予約時間に給電ステーションにたどり着けないことが判明した際の処理に関するものである。以下では、第１実施形態と異なる点についてのみ説明する。

　２．１　動作について　
　図１８は、電気自動車１００走行中におけるスマートフォン２００、サーバ４００（サーバ３００及び５００の動作も含む）、及び電気自動車１００の、給電ステーション予約に関する動作を示すフローチャートである。なお、以下におけるサーバ４００の処理は、図８で説明した通り、プロセッサ４３１がプログラム４３５を実行することにより、主として制御部４３０によって実行される。

　図示するように、サーバ４００は、例えば一定期間毎にサーバ３００から渋滞情報３３５を取得する（ステップＳ３０）。その際、取得した渋滞情報３３５において、予想以上に長い渋滞の発生、または事故発生による通行止めなどが生じていることが判明したとする。するとサーバ４００（第２判断部４５５）は、速やかに電気自動車１００から現在のバッテリ残量情報４３７を取得し（ステップＳ３１）、ユーザによって承認された現在の推奨ルートにおいて、予約時刻に給電ステーションに到着できるか否かを判断する（ステップＳ３２）。

　到着できる場合には（ステップＳ３２、ＮＯ）、サーバ４００は特に推奨ルートの変更などは行わず、そのまま、当初の給電ステーションの本予約（未だ仮予約の場合であっても良い）を維持する。他方で、到着できないと判断した場合には（ステップＳ３２、ＹＥＳ）、サーバ４００（予約部４５４）は、給電ステーションの本予約（または仮予約）をキャンセルする（ステップＳ３３）。すなわち、サーバ４００はサーバ５００に対して給電ステーションの予約キャンセルのリクエストを送信する。するとサーバ５００は、当該リクエストに従って、予約情報５３６における当該予約をキャンセルする。

　その後、サーバ４００は、第１実施形態と同様に、ステップＳ３０で得られた渋滞情報３３５に基づき、新たなルートを探索し（ステップＳ１１）、得られたルートにおいて推奨される給電ステーションを仮予約する（ステップＳ１５）。そして、第１実施形態で説明したように、ステップＳ１６～Ｓ２３の処理が実行される。

　２．２　本実施形態に係る効果　
　本実施形態によれば、想定外の渋滞や事故が生じた場合には、サーバ４００が現在の推奨ルートで問題ないか否かを判断し、問題がある場合にはそれまでの給電ステーションの予約をキャンセルする。更に、新たなルートを探索すると共に、必要があれば最適な給電ステーションを新たに仮予約し、ユーザに提示する。

　従って、予想外の事態が発生した場合であっても、電気自動車１００におけるバッテリ切れに対するユーザの不安を緩和し、更に実際にバッテリ切れにならないよう最適なルート算出と給電ステーションの予約を行うことで、電気自動車１００の運行安定性を向上できる。

　上記は、気候（風、降雨、積雪など）や、電気自動車１００の重量（乗車人数や積み荷の重さ）の影響についても同様である。すなわち、これらの要素によっても、バッテリ１１０の消費率は変化する。よってサーバ４００は、渋滞や事故だけでなく、これらの要素をも鑑みて、現在の推奨ルートで問題ないか否かを判断しても良い。

　なお、予約を変更する具体例については、後述する第５実施形態で説明するので、そちらを参照されたい。

　３．第３実施形態　
　次に、第３実施形態に係る情報処理装置、情報処理方法、及び情報処理プログラムについて説明する。本実施形態は、上記第１及び第２実施形態において、電気自動車１００の乗車予定日を予めサーバ４００に登録し、この登録状況に応じてサーバ４００がユーザのリクエストを受けることなく自発的に給電ステーションの予約をするものである。以下では、第１及び第２実施形態と異なる点についてのみ説明する。

　３．１　構成について　
　本実施形態に係るサーバ４００の構成は、第１実施形態で説明した図６Ａの通りであり、例えばＲＡＭ４３３は、更にスケジューリングプログラムを保持する（これは、ルート検索プログラム４３５の一部であっても良い）。このスケジューリングプログラムが実行されることで、サーバ４００は以下に説明する機能を実行する。

　図１９Ａは、スケジューリングプログラムを実行した際におけるプロセッサ４３１（または制御部４３０全体）の機能ブロック図である。図１９Ａに示すようにプロセッサ４３１は、スケジューリングプログラムを実行することにより、登録部４６０、第３判断部４６１、予約部４５４、第１検索部４５１、及び第２検索部４５２として機能する。

　登録部４６０は、電気自動車１００の乗車予約を管理する。すなわち登録部４６０は、乗車スケジュールデータベースを作成する。作成されたデータベースは、例えばＲＡＭ４３３に保持される。そして登録部４６０は、ユーザからの第１乗車予約入力を受け付けることにより、第１乗車予約に関する第１乗車予定期間を示す第１情報、及び乗車時におけるバッテリ１１０の残量を示す第２情報４３７を登録する。第２情報４３７は、電気自動車１００から与えられる。第３判断部４６１は、第２情報４３７に基づき、第１乗車予定期間内においてバッテリ１１０の充電が必要か否かを判断する。これは、例えば第１乗車予定期間において予想されるバッテリの消費量を算出し、この消費量と第２情報４３７とを比較することなどによって判断される。予約部４５４は、第３判断部４６１においてバッテリ１１０の充電が必要と判断された場合、いずれかの給電ステーションを、ユーザからの命令を待つことなく仮予約（本予約まで行う場合であっても良い）する。予約部４５４は、例えば給電ステーション情報５３５及び予約情報５３６に基づいて、いずれかの給電ステーションを仮予約する。

　また、登録部４６０が第１乗車予約における目的地に関する第３情報（例えばユーザ設定情報４３６）を登録する場合、図６Ａで説明したように、第１検索部４５１は目的地に至るまでの推奨経路を検索し、第２検索部４５２は目的地までの間にある給電ステーションを検索する。そして、第３判断部４６１において、推奨経路を走行した場合にバッテリ１１０の充電が必要と判断された場合、予約部４５４は、第２検索部４５２で検索されたいずれかの給電ステーションを、ユーザからの命令を待つことなく仮予約する（同じく、本予約まで行っても良い）。

　３．２　動作について　
　以下では、目的地を登録する場合としない場合の２つの例について説明する。

　＜第１の例＞　
　第１の例は目的地を登録しない場合である。図１９Ｂは、本実施形態に係る予約システムのフローチャートであり、事前の乗車日登録と給電ステーションの予約方法の第１の例について示している。なお、以下におけるサーバ４００の処理は、プロセッサ４３１がスケジューリングプログラムを実行することにより、主として制御部４３０によって実現される。そしてユーザは、本実施形態に係る登録が完了した後に、実際に第１及び第２実施形態で説明したように電気自動車１００に乗車する。

　図示するように、スマートフォン２００は、第１実施形態で説明した予約システムのアプリを起動する。そしてスマートフォン２００は、ユーザによる乗車日時入力を受け付ける（ステップＳ４０）。

　するとサーバ４００（登録部４６０）は、ＲＡＭ４３３において乗車スケジュールデータベースを生成し、このデータベースに乗車日時を登録する（ステップＳ４１）。この際、サーバ４００は、現在のバッテリ残量情報を電気自動車１００から受信し、プロセッサ４３１は、登録されたユーザの乗車によるバッテリ消費を計算すると共に、バッテリ残量をデータベースに登録する（ステップＳ４２）。そして、バッテリ１１０の充電が必要であるとプロセッサ４３１（第３判断部４６１）が判断すれば、いずれかの給電ステーション（例えば自宅から最寄りの給電ステーション）を仮予約する（予約部４５４、ステップＳ４４）。そしてプロセッサ４３１（第３判断部４６１、登録部４６０）は、ステップＳ４４で仮予約された給電ステーションでバッテリ１１０が充電されたと仮定して、バッテリ残量を計算し、その結果をデータベースに登録する（ステップＳ４５）。

　以上の様子を図２０に示す。図２０は、乗車スケジュールデータベースの概念図である。本データベース情報をサーバ４００がスマートフォン２００に送信することで、ユーザはスマートフォン２００の表示部２１０において図２０のような表示を閲覧できる。

　図２０の例であると、５／２４（水）の７：３０から１０：３０までの期間、及び１８：００から２１：００までの期間に乗車の予定が登録される。そして、５／２４の最初の乗車の７：３０の時点で、バッテリ残量は５４％である。そこでプロセッサ４３１は、例えばバッテリ残量と、走行予定期間と、平均バッテリ消費量などの情報に基づき、バッテリ１１０を充電した場合としない場合とでの、乗車終了時刻の１０：３０におけるバッテリ残量を予測する。その結果、バッテリ残量が例えばユーザにより設定された閾値を下回ると判断し、例えば出発地（例えば自宅）近辺における給電ステーションを、例えば出発時の９：００に仮予約する。給電ステーションの予約は、星印で示されている。そして、給電ステーションでバッテリ１１０がほぼ１００％まで充電されたと仮定して、プロセッサ４３１はその後のバッテリ残量を計算する。図２０の例では、５／２４の最初の乗車が完了した時点でのバッテリ残量は８６％であり、２回目の乗車完了時でもバッテリ残量は６１％であり、この日はそれ以上のバッテリ充電は不要となる。

　図１９Ｂに戻って説明を続ける。ステップＳ４１において乗車日が登録されて、更にステップＳ４４で新たに給電ステーションが仮予約された場合、既になされていた仮予約が不要になる場合がある。この場合（ステップＳ４６、ＹＥＳ）には、プロセッサ４３１（第３判断部４６１）はサーバ５００に対して当該仮予約のキャンセルを通知する（ステップＳ４７）。この様子を図２１に示す。図２１は、図２０と同様に乗車スケジュールデータベースの概念図である。

　図示するように、図２０に示す乗車予定が登録され、５／２４に給電ステーションが仮予約された後、５／２３（火）の１２：３０から１３：３０までの期間、及び１５：３０から１６：３０までの期間に乗車予定が登録され、更に５／２３の２回目の乗車後（例えば自宅に帰宅した際）に、自宅近辺における給電ステーションが仮予約されたと仮定する。すると、図２０の場合と異なり、５／２４の１回目の乗車開始時点でのバッテリ残量は９６％となり、５／２４はバッテリ１１０の充電が不要となる。そこでプロセッサ４３１は、５／２４における給電ステーションの仮予約をキャンセルする。

　なお、上記説明では予約部４５４における予約が仮予約である場合を例に説明した。しかし、いずれかは本予約とされていても良い。すなわちスマートフォン２００は、例えば給電ステーションを自動で仮予約した後、ユーザに対して本予約の承認を促す。そして、ユーザからの承認を受信した際には、仮予約を本予約に切り替える。従って、本予約に切り替えた後にステップＳ４７の処理を行う際には、キャンセルされる予約は本予約であるし、本予約に切り替える前であれば、キャンセルされる予約は仮予約である。ユーザからの本予約の承認を受信するタイミングは、電気自動車１００の乗車前であっても良いし、乗車後の走行中であっても良い。また、ステップＳ４４において予約部４５４は、仮予約ではなく本予約を行っても良い。

　＜第２の例＞　
　第２の例は、乗車日時と共に目的地を登録する場合である。図２２は、本例に係る予約システムのフローチャートであり、第１の例で説明した図１９Ｂに対応する。

　図示するようにスマートフォン２００は、第１実施形態で説明した予約システムのアプリを起動する。そしてスマートフォン２００は、ユーザによる乗車日時入力を受け付ける（ステップＳ５０）。引き続きスマートフォン２００は、ユーザによる目的地入力を受け付ける（ステップＳ５１）
　すると、サーバ４００（登録部４６０）は、ＲＡＭ４３３において乗車スケジュールデータベースを生成し、このデータベースに乗車日時を登録する（ステップＳ５２）。また、サーバ４００のプロセッサ４３１（第１検索部４５１）は、目的地までのルート検索を行い（ステップＳ５３）、更に検索されたルート内における給電ステーションを検索する（第２検索部４５２、ステップＳ５４）。そして、これらの給電ステーションにおいてバッテリ１１０を充電したケースやしないケースでのバッテリ残量を計算し（ステップＳ５５）、給電ステーションの推奨予約をデータベースに登録する（ステップＳ５６）。プロセッサ４３１は、例えばこの時点で、推奨した給電ステーションを仮予約または本予約する。

　以上の様子を図２３に示す。図２３は、乗車スケジュールデータベースの概念図であり、第１の例で説明した図２０及び図２１に対応し、ユーザはスマートフォン２００の表示部２１０において図２３のような表示を閲覧できる。

　図２３の例であると、下記の曜日に乗車予定が登録されている。すなわち、　
　・月曜日：１２：００～１９：００
　・火曜日：７：３０～２４：００
　・水曜日：１５：００～２２：００
　・木曜日：１２：００～１９：００
プロセッサ４３１は、これらの４つの乗車予定につきルート検索を行い、ルート近辺にある給電ステーションを星印で表示する。星印は、大きいものほど検索されたルートに近く、経路の無駄が少ない給電ステーションを示し、白抜きの星印が、プロセッサ４３１の推奨する給電ステーションである。図２３の例であると、月曜日の１４時頃に給電ステーションを予約することが推奨されている。予約部４５４は、この時点で推奨する給電ステーションを仮予約しても良い。

　またプロセッサ４３１は、データベースにおいて、直近の乗車予定（図２３では月曜日）につき、目的地への到着予定時刻と、到着した時点で予測されるバッテリ残量を表示する。図２３の例であると、月曜日の到着予定時刻は１９：００であり、バッテリ１１０の充電を行わなかった場合、予想残量はα％である。これに対してポイントＡ（これは１４時で推奨されている給電ステーション）で充電した場合の予想残量はβ％であり、ポイントＢ（これは１８時に走行中と予測される位置にある給電ステーション）で充電した場合の予想残量はγ％であることが示されている。

　図２２に戻って説明を続ける。図２３のデータベースを参照して、スマートフォン２００がユーザからの予約選択を受け付けると（ステップＳ５７）、サーバ４００のプロセッサ４３１（予約部４５４）は、ユーザによって選択された給電ステーションを本予約する（ステップＳ５８）。そして、この本予約に基づいて、必要であればバッテリ残量を再計算し（ステップＳ５９）、次の推奨予約をデータベースに表示させる（第３判断部４６１、登録部４６０、ステップＳ６０）。この様子を図２４に示す。図２４は、図２３と同様に乗車スケジュールデータベースの概念図である。

　図示するように、図２３で推奨された月曜日の１４：００の予約がユーザによって選択されると、プロセッサ４３１はサーバ５００に対して本予約をリクエストする。図２４の例では、本予約された給電ステーションは、丸で囲った白抜き星印で示される。そしてプロセッサ４３１は、次の推奨予約を計算して、データベースに登録する。図２４の例であると、金曜日の１４時頃に給電ステーションを予約することが推奨されている。

　なお、上記説明ではステップＳ５８における予約部４５４での予約が本予約である場合を例に説明した。なぜなら、ステップＳ５７でユーザによる承認をすでに受信しているからである。しかし予約部４５４は、例えばステップＳ５６の段階で、推奨する給電ステーションを仮予約し、ステップＳ５７で承認を受信した際に仮予約を本予約に切り替える場合であっても良い。あるいは、ステップＳ５８では予約部４５４は仮予約を行い、改めてユーザからの承認を受信した際に仮予約を本予約に切り替えても良い。なぜなら、本実施形態に係る乗車日登録は、実際に乗車するよりも前に行われることもあり得るからである。特にカーシェアリングシステムなどに適用される場合には、乗車の数日または数週間前に乗車日登録がなされることが想定される。従って、このような場合には、登録時の予約は仮予約に留め、実際の乗車日当日またはその数日前を期限として、ユーザからの本予約の入力を待っても良い。もちろん、第１の例と同様に、ユーザから本予約の承認を受信するタイミングは、電気自動車１００の乗車前であっても良いし、乗車後の走行中であっても良い。

　３．３　本実施形態に係る効果　
　本実施形態によれば、乗車予定をデータベースに登録し、その乗車予定に従ってサーバ４００が推奨給電ステーションを提案する。従って、給電ステーションの予約についてのユーザの煩雑さを緩和できる。また、数日間の乗車予定に基づいて最適な給電タイミングを決定することができ、効率的な充電スケジュールを立てることができる。

　なお、上記の例では、ユーザが電気自動車１００に頻繁に乗車する場合を例に説明した。しかし、例えば休日しか利用しないユーザや、長期間にわたって乗車しないユーザの場合、バッテリの自然放電を考慮することが望ましい。すなわち、ある乗車から次の乗車までの間が、ある一定の閾値期間を超える場合には、いずれかのタイミングで電気自動車１００を起動させ、その際にサーバ４００へ再度バッテリ残量情報を送信し、ステップＳ５６～Ｓ６０の処理を再度行っても良い。

　なお、図２３及び図２４の例では、月曜日の１４時に充電することが推奨される場合を例に説明した。しかし、図２３及び図２４の例では、火曜日の走行時間が非常に長い。従って、バッテリ残量に余裕を持たせたるならば、月曜日ではなく火曜日に充電した方が良いかもしれない。そのような場合には、図２５に示すように、月曜日ではなく、火曜日の長距離走行中にある給電ステーションを推奨してもよい。例えば、図２３の推奨をユーザが承認しなかった場合には、図２５の推奨を提示するようにしてもよい。または、ユーザ設定情報４３６における優先順位情報に基づいて、図２３ではなく図２５を推奨しても良い。

　４．第４実施形態　
　次に、第４実施形態に係る情報処理装置、情報処理方法、及び情報処理プログラムについて説明する。本実施形態は、上記第１乃至第３実施形態において、サーバ４００を廃し、サーバ４００の機能をスマートフォン２００に持たせたものである。以下では、第１乃至第３実施形態と異なる点についてのみ説明する。

　４．１　構成について　
　図２６は、本実施形態に係る予約システム１のブロック図であり、第１実施形態で説明した図２に対応するものである。

　図示するように、本例が第１実施形態で説明した図２と異なる点は、第１実施形態においてサーバ４００が行っていた下記処理を、スマートフォン２００が行う点である。すなわち、
　・サーバ３００からの渋滞情報を取得　
　・サーバ５００からの給電ステーション情報、予約情報、及び予約完了情報の取得　
　・給電ステーションの予約　
　・電気自動車１００からのバッテリ残量情報の取得　
　・推奨ルート計算。

　図２７は、本実施形態に係るスマートフォン２００のブロック図である。図示するように、本例に係る構成は、第１実施形態で説明した図４において、サーバ４００としての機能を実現するため、例えばＲＡＭ２３３が、図６Ａで説明したサーバ４００のＲＡＭ４３３内の種々のデータ及びルート検索プログラム４３５を保持する。このプログラム４３５及び地図情報４３８は、サーバ３００または５００から無線通信回線または有線通信回線によってスマートフォン２００にダウンロードされ、またはその他のサーバ（例えば、第１実施形態で説明した予約システムを運営する事業者のサーバ）からダウンロードされても良い。もちろん、スマートフォン２００がユーザに販売される時点において、既にプログラム４３５がＲＡＭ２３３に保持されている場合であっても良い。

　そして、プロセッサ２３１がプログラム４３５を実行することにより、プロセッサ２３１（または制御部２３０全体）は、第１実施形態における図６Ｂで説明したように、受信部４５０、第１検索部４５１、第２検索部４５２、第１判断部４５３、予約部４５４、及び第２判断部４５５として機能する。

　図２７に示すように、スマートフォン２００は、バッテリ１１０の残量情報のリクエストを電気自動車１００へ送信し、渋滞情報のリクエストをサーバ３００へ送信し、給電ステーション情報及び予約情報のリクエストをサーバ５００へ送信する。そしてスマートフォン２００は、バッテリ残量情報を電気自動車１００から受信し、渋滞情報をサーバ３００から受信し、給電ステーション情報、予約情報、及び予約完了情報をサーバ５００から受信し、これらをＲＡＭ２３３に保持する。

　４．２　動作について　
　図２８は、本実施形態に係る電気自動車の給電ステーションの予約システムの動作を示すフローチャートであり、第１実施形態で説明した図８に対応する。

　図示するように、本実施形態が第１実施形態で説明した図８と異なる点は、ステップＳ１０～Ｓ１３及びＳ１４～Ｓ２３の全てがスマートフォン２００で実行される点である。当然ながら、各ステップにおける各種の判断、演算、及び命令発行などは、スマートフォン２００のプロセッサ２３１が主体となって行われる。図９の判断も同様である。

　第２及び第３実施形態で説明した動作も同様であり、図示は省略するが、図１８、図１９Ｂ、及び図２２におけるサーバ４００の処理は、スマートフォン２００で実行される。

　４．３　本実施形態に係る効果　
　本実施形態によれば、サーバ４００が不要となり、予約システム１のコストを低減できる。また、ユーザにとっては、処理のたびにサーバへアクセスする必要がなく、自身の保有するスマートフォン２００で処理を完結できるので、スマートフォン２００の通信量を抑制し、予約システム１の使い勝手を向上できる。

　なお本実施形態では、第１実施形態に係る処理をスマートフォン２００が主体となって実行する場合を例に説明した。これは、第２実施形態の場合も同様である。すなわちスマートフォン２００は、第２実施形態で説明したスケジューリングプログラムをいずれかのサーバからダウンロードする。そしてスマートフォン２００のプロセッサ２３１がスケジューリングプログラムを実行することで、プロセッサ２３１（または制御部２３０全体）が、第２実施形態で説明した図１９Ａに示すように機能する。この場合、図１９Ｂで説明したステップＳ４０～Ｓ４７の処理はスマートフォン２００によって実行され、給電ステーションの予約や予約のキャンセル処理もスマートフォン２００からサーバ５００に直接行われる。

　５．第５実施形態　
　次に、第５実施形態に係る情報処理装置、情報処理方法、及び情報処理プログラムについて説明する。本実施形態は、上記第１乃至第３実施形態において更にカーナビゲーションシステムを有し、スマートフォン２００の表示部２１０の機能の一部をカーナビゲーションシステムに持たせたものである。以下では、第１乃至第３実施形態と異なる点についてのみ説明する。

　５．１　構成について　
　図２９は、本実施形態に係る予約システム１の構成例を示している。図示するように、本例に係る予約システム１は、第１実施形態で説明した図１において、電気自動車１００内に設けられたカーナビゲーションシステム７００を更に備えている。

　図３０は、図２９に示す予約システム１のブロック図である。図示するように、本例に係る予約システム１は、第１実施形態で説明した図２において、スマートフォン２００が確定ルート情報をカーナビゲーションシステム７００に送信し、カーナビゲーションシステム７００が確定ルート情報を表示する。

　図３１は、カーナビゲーションシステム７００の構成例を示すブロック図である。図示するようにカーナビゲーションシステム７００は、表示部７１０、ユーザ入力部７２０、制御部７３０、及び通信部７４０を備えている。

　表示部７１０は、ルートナビゲーションなど、ユーザに対して種々の情報を提示し、例えば液晶ディスプレイなどである。

　ユーザ入力部７２０は、ユーザからの種々のカーナビゲーションシステムの機能に関する命令入力を受け付ける。例えば、表示部７１０がタッチパネル型の表示装置であって、表示部７１０とユーザ入力部７２０とが一体となっていても良い。

　通信部７４０は、無線通信によりスマートフォン２００との間で情報を送受信する。例えば通信部７４０は、スマートフォン２００から確定ルート情報を受信する。

　制御部７３０は、カーナビゲーションシステム７００全体の処理を制御する。制御部７３０は、ＣＰＵなどのプロセッサ７３１、ＲＯＭ７３２、ＲＡＭ７３３、及び入出力回路７３４を備えている。ＲＯＭ７３２は、プロセッサ７３１によって実行されるプログラムや必要なデータを保持する。ＲＡＭ７３３は、プロセッサ７３１の作業領域として機能する。入出力回路７３４は、通信部７４０との間の情報の送受信を司る。プロセッサ７３１は、例えばＲＯＭ７３２内のプログラムを実行することにより、ルートナビゲーションを行う。すなわちプロセッサ７３１は、通信部７４０で受信された確定ルート情報に基づいて確定ルートを表示部７１０に表示させ、更に例えば図示せぬＧＰＳ情報に基づいて電気自動車１００の位置を把握して、ルートナビゲーションを行う。

　５．２　動作について　
　次に、本実施形態に係る電気自動車の給電ステーションの予約システム１の動作について説明する。図３２は、ユーザが電気自動車１００に乗車してから、あるいは電気自動車１００に乗車することを決定した際（乗車自体は翌日などであってもよい）の、スマートフォン２００、サーバ４００（サーバ３００及び５００の動作も含む）、カーナビゲーションシステム７００、及び電気自動車１００の、給電ステーション予約に関する動作を示すフローチャートであり、第１実施形態で説明した図８に対応する。

　図示するように、本実施形態に係る予約システム１の動作が第１実施形態で説明した図８と異なる点は、確定ルートがカーナビゲーションシステム７００の表示部７１０に表示される点のみである。なお、確定ルートは、カーナビゲーションシステム７００の表示部７１０に表示されてスマートフォン２００の表示部２１０には表示されない場合であっても良いし、両者に表示される場合であっても良い。また、確定ルートがカーナビゲーションシステム７００とスマートフォン２００の両方に表示される場合であっても、表示内容が異なっていても良い。すなわち、例えばスマートフォン２００は出発地から目的地までを示す広域地図を表示すると共に、推奨する１つまたは複数の給電ステーションを表示し、カーナビゲーションシステム７００は、運転者に対するナビゲーションを第一の目的として、例えば現在走行中の狭い範囲の地図を三次元的に表示しても良い。

　また、カーナビゲーションシステム７００の表示部７１０の方が、スマートフォン２００の表示部２１０よりも表示面積の方が大きいことが一般的である。従って、スマートフォン２００が担っていた機能の一部、例えば給電ステーションに関する情報の表示、ユーザに対する情報入力を促す表示、及びユーザからの入力の受け付けの一部を、カーナビゲーションシステム７００が代替しても良い。情報を表示する場合には、必要なデータをスマートフォン２００またはサーバ４００から受信すれば良く、ユーザからの入力を受け付ける場合には、受け付けた内容をスマートフォン２００またはサーバ４００に送信すれば良い。

　次に、動作時における表示画面の変化の具体例として、２つのケースを例に説明する。

　＜第１の例＞　
　まず、第１の例について、図３３乃至図４０を用いて説明する。図３３乃至図４０は、カーナビゲーションシステム７００の表示部７１０の表示画面の模式図である。本例では、スマートフォン２００またはサーバ４００からのデータに基づき、情報表示及びユーザ入力の受け付けのほとんどをカーナビゲーションシステム７００が担う。つまり、図３１で説明したカーナビゲーションシステム７００のユーザ入力部７２０は、図４で説明したスマートフォン２００のユーザ入力部２２０の機能の少なくとも一部を有する。

　図３３は、カーナビゲーションシステム７００の表示部７１０のナビゲーション開始前の表示画面を示す。第１実施形態で説明した図１０と同様にバッテリ１１０の残量が表示されている（図３３の例であると５４％）。第１実施形態と異なる点は、表示部７１０に「スケジュール」なるアイコンが表示される点である。この「スケジュール」アイコンが選択されることで、ルートナビゲーションが開始されると共に、第１乃至第３実施形態で説明した予約システム１が実行される。

　図３４は、図３３においてユーザからの「スケジュール」アイコンの選択を受け付けた際の表示画面を示す。図示するように、第１実施形態で説明した図１２と同様に、ユーザ設定情報を受け付ける画面に変化する。すなわち、カーナビゲーションシステム７００が、図３２のステップＳ１０の動作を実行する。引き続き、図３５に示すようにカーナビゲーションシステム７００は、ユーザからの目的地の入力を受け付ける。本例であると、「鎌倉」が目的地である。引き続き、図３６に示すようにカーナビゲーションシステム７００は、帰路設定情報の入力を受け付ける。図３４乃至図３６で受け付けた情報は、例えばスマートフォン２００を介してサーバ４００へ送信され、または直接サーバ４００へ送信される。

　すると、サーバ４００はルート探索（図３２のステップＳ１１～Ｓ１７）を行い、その結果を例えばスマートフォン２００を介してカーナビゲーションシステム７００に送信する。そしてカーナビゲーションシステム７００の表示部７１０は、図３７に示すように、受信したルートを地図上に表示する。図３７は、一例として以下の場合を示している。　
　・往路　
　　・出発地＝松戸（自宅）、出発時刻＝未定　
　　・目的地＝鎌倉、到着時刻＝１０：３０　
　・帰路　
　　・出発地＝鎌倉、出発時刻＝１８：００　
　　・目的地＝松戸（自宅）、到着時刻＝未定　
そして「給電予約」の表示がハイライトされ、サーバ４００は推奨ルートにおけるいずれかの給電ステーションを仮予約する（図３２のステップＳ１８）。その結果を示しているのが図３８である。

　図示するようにサーバ４００は、推奨ルート付近に位置する複数の給電ステーションを、例えば星印で表示する。図３８の例であると、星印が大きいほど推奨度が高い。そして図３８では、第１推奨は東京都心の品川付近であり、第２推奨は埼玉県の戸田付近であり、第３推奨は東京都の町田付近である。この時点で、サーバ４００は第１推奨の給電ステーションを仮予約する（ステップＳ１８）。

　次に、ユーザが第１推奨の給電ステーションを選択（例えば表示部７１０がタッチパネルであり、且つ図３８に示すような画面を表示している際に、ユーザが第１推奨の給電ステーションの表示部分にタッチする）すると、図３９に示すように、カーナビゲーションシステム７００の表示部７１０は、第１推奨の給電ステーション（Station A）に関する詳細情報を表示する。この表示処理は、例えばサーバ４００または５００から給電ステーション情報５３５及び予約情報５３６を受信することによって可能である。現在、サーバ４００により時刻８：５０に仮予約がされている。その他に、予約可能な時間が表示され、ユーザの選択に従って、サーバ４００は第１推奨の給電ステーションを本予約する（図３２のステップＳ２２）。

　その後の最終的な画面が図４０である。図示するように、給電ステーションの予約が完了したことで、サーバ４００は、渋滞予測などに従い、この給電ステーションの予約に間に合うよう、往路における出発地（自宅）の出発時刻（図４０の例では７：２０）と、帰路における目的地（自宅）の到着時刻（図４０の例では２１：１０）を算出し、その結果を確定ルートとして、カーナビゲーションシステム７００の表示部７１０に表示させる（図３２のステップＳ７０）。そしてカーナビゲーションシステム７００は、確定ルートに従ってルートナビゲーションを開始する。

　＜第２の例＞　
　次に、第２の例について図４１乃至図５０を用いて説明する。第２の例は、第２実施形態で説明したように、当初仮予約した給電ステーションに予約時刻にたどり着けないと予想される場合、及び推奨された給電ステーションをユーザが望まない場合の動作に関するものである。従って第２の例では、図４１乃至図５０と共に、図１８も用いつつ、以下説明する。図４１乃至図５０において、左側の縦長の表示はスマートフォン２００の表示部２１０の表示画面を模式的に示し、右側の横長の表示はカーナビゲーションシステム７００の表示部７１０の表示画面を模式的に示している。

　本例では、スマートフォン２００の表示部２１０は推奨ルート全体と共に、給電ステーションに関する情報を表示する。これに対してカーナビゲーションシステム７００の表示部７１０は、主に現在走行中のルートをナビゲートすると共に、ユーザによる給電ステーションの予約選択入力を受け付ける。

　図４１は、鎌倉を目的地として川崎付近を走行中の様子を示している。この時点では、川崎よりも鎌倉に近い給電ステーション（Station B）が１６：５５に予約されている。しかし、サーバ３００から受信した渋滞情報３３５によれば、現在地からStation Bまでの間に渋滞が発生し、ユーザ（電気自動車１００）は１６：５５までにStation Bにたどり着けないと、サーバ４００が判断したとする（図１８のステップＳ３２、ＹＥＳ）。するとサーバ４００は、サーバ５００に対して、Station Bの予約のキャンセルを命令する（図１８のステップＳ３３）。そしてサーバ４００は、渋滞を考慮に入れて最適な給電ステーションを再度探索する（図１８のステップＳ１１～Ｓ１７）。その結果の表示例が図４２である。

　図示するように、サーバ４００は、川崎に近い給電ステーション（Station A）を第１推奨として提案し、更にStation Aにつき１６：４０の仮予約を入れる（図１８のステップＳ１８）。その旨の情報が、カーナビゲーションシステム７００の表示部７１０にも表示され、表示部７１０は、本予約して良いかのユーザ入力を促す画面を表示する。

　ユーザが上記仮予約を望まない場合、例えば図４３に示すようにユーザは、表示部７１０に表示された「もっと見る」なるアイコンを選択する。すると、表示部７１０の表示画面は図４４に変化し、各給電ステーションについての詳細を表示する。すなわち、サーバ４００はスマートフォン２００を介してカーナビゲーションシステム７００に対して、複数の推奨ルートについての情報を送信し、カーナビゲーションシステム７００は、受信した情報に基づいて、推奨される給電ステーションの情報を表示部７１０に表示する。図４４での例は、第１乃至第３推奨として、Station A、Station B、及びStation Cが表示部７１０に表示されている。更に表示部７１０は、ユーザの要求に従い、第１推奨であるStation Aについての予約可能時間帯を表示している。これらの情報も、サーバ４００から送信された給電ステーション情報５３５及び予約情報５３６から得られる。そしてユーザが、Station Aにつき、１８：５０の時間帯を選択すると、表示部７１０の表示画面は図４５のように切り替わる。この画面において、ユーザが「ＹＥＳ」アイコンを選択すれば（図１８のステップＳ２０、ＹＥＳ）、その情報はカーナビゲーションシステム７００からスマートフォン２００を介してサーバ４００へ送信され、サーバ４００はStation Aにつき１８：５０の本予約をサーバ５００に対して命令する（図１８のステップＳ２２）。図４６は、その後のナビゲーション画面である。スマートフォン２００の表示部２１０では、本予約されたStation Aが強調表示されている。

　図４７は、図４４の画面においてユーザが例えばStation Cを選んだ場合の様子を示す。Station Cは、現在の推奨ルートから離れているので、図４７のスマートフォン２００の表示部２１０に示されるように、Station Cを経由する際に変更となるルートが破線で表示される。これは、例えば図１８のステップＳ１１の処理で得られたルートである。そして図４８においてStation Cが本予約されると、スマートフォン２００の表示部２１０の表示は図４９に切り替わり、Station Cを経由するルートが強調表示され、このルートに従って以後、カーナビゲーションシステム７００はナビゲートする。

　図５０は、走行中にバッテリ１１０の残量が一定値よりも消費された場合の表示画面を示す。前述の通り、サーバ４００またはスマートフォン２００は、一定期間毎、あるいはリアルタイムでバッテリ１１０の残量を監視する（図１８のステップＳ３１）。その結果、バッテリ残量が低下した際には、サーバ４００は、その緊急度に応じて給電ステーションの仮予約を推奨する画面をカーナビゲーションシステム７００の表示部７１０に表示させる。図５０の例であると、Station Bの代わりにStation Aの仮予約の提案と共に、「緊急度」も同時に表示される。緊急度１は最も緊急性が高く、電気自動車１００がすぐにでも走行不能になる状態であることを示す。緊急度５は最も緊急性が低く、しばらく充電が不要であることを示す。

　５．３　本実施形態に係る効果　
　本実施形態によれば、カーナビゲーションシステム７００がスマートフォン２００の機能の一部を担うことができる。

　６．第６実施形態　
　次に、第６実施形態に係る情報処理装置、情報処理方法、及び情報処理プログラムについて説明する。本実施形態は、上記第５実施形態において、カーナビゲーションシステム７００がスマートフォン２００の機能を実行するものである。以下では２つの例を用いて、上記第１乃至第５実施形態と異なる点についてのみ説明する。

　６．１　第１の例　
　まず第１の例について説明する。図５１は、本例に係る予約システム１のブロック図であり、図５２はカーナビゲーションシステム７００のブロック図である。

　図示するように、本例に係る予約システム１は、第５実施形態で説明した図３０においてスマートフォン２００を廃し、スマートフォン２００が担っていた機能をカーナビゲーションシステム７００が実現するものである。従って、カーナビゲーションシステム７００は、ユーザ入力部７２０からユーザ設定情報４３６の入力を受け付け、これをサーバ４００へ送信する。また、通信部７４０はサーバ４００から推奨ルート情報を受信し、これを表示部７１０に表示する。

　図５３は、本実施形態に係る予約システム１の動作を示すフローチャートであり、第５実施形態で説明した図３２及び第１実施形態で説明した図８に対応する。図示するように本例であると、第１実施形態で説明したステップＳ１０、Ｓ１９、Ｓ２０、及びＳ２３の処理がカーナビゲーションシステム７００において行われる。その他は、第１実施形態及び第５実施形態で説明した通りである。

　６．２　第２の例　
　次に第２の例について説明する。図５４は、本例に係る予約システム１のブロック図であり、図５５はカーナビゲーションシステム７００のブロック図である。

　図示するように、本例に係る予約システム１は、上記第１の例で説明した図５１においてサーバ４００を廃し、サーバ４００が担っていた機能をカーナビゲーションシステム７００が実現するものである。あるいは、第４実施形態で説明した図２６に示す構成において、スマートフォン２００をカーナビゲーションシステム７００に置き換えたものと言うこともできる。従って図５５に示すカーナビゲーションシステム７００は、図２７で説明したスマートフォン２００と同様に、図３１に示す構成において、図６Ａで説明したサーバ４００のＲＡＭ４３３内の種々のデータ及びルート検索プログラム４３５を例えばＲＡＭ７３３に保持する。これにより、カーナビゲーションシステム７００は、サーバ４００としての機能を実現する。より具体的には、カーナビゲーションシステム７００は、第４実施形態で説明したように、サーバ４００が行っていた下記処理を行う。すなわち、
　・サーバ３００からの渋滞情報を取得　
　・サーバ５００からの給電ステーション情報、予約情報、及び予約完了情報の取得　
　・給電ステーションの予約　
　・電気自動車１００からのバッテリ残量情報の取得　
　・推奨ルート計算。

　なお、ルート検索プログラム４３５を実行した際における、カーナビゲーションシステム７００のプロセッサ７３１（または制御部７３０全体）の機能ブロック図は、第１実施形態で説明した図６Ｂに示す通りである。すなわちプロセッサ７３１は、プログラム４３５を実行することにより、受信部４５０、第１検索部４５１、第２検索部４５２、第１判断部４５３、予約部４５４、及び第２判断部４５５として機能する。

　なお、本例においてもプログラム４３５及び地図情報４３８は、サーバ３００または５００、またはその他のサーバ（例えば、本実施形態で説明する予約システムを運営する事業者のサーバ）から無線通信回線または有線通信回線によってカーナビゲーションシステム７００にダウンロードされても良いし、カーナビゲーションシステム７００がユーザに販売される時点において、既にプログラム４３５がＲＡＭ７３３に保持されている場合であっても良い。あるいは、例えばＣＤ－ＲＯＭやＤＶＤなどの情報記録媒体によってカーナビゲーションシステム７００のＲＡＭ７３３に提供されても良い。

　図５６は、本実施形態に係る予約システム１の動作を示すフローチャートであり、第５実施形態で説明した図３２及び第４実施形態で説明した図２８に対応する。図示するように本例であると、第１実施形態で説明したステップＳ１０～Ｓ１２、及びステップＳ１４～Ｓ２３の処理がカーナビゲーションシステム７００において行われる。その他は、第１実施形態及び第４実施形態で説明した通りである。言い換えれば、図２８において、スマートフォン２００の処理の全てをカーナビゲーションシステム７００が実行するものと言うことができる。

　６．３　本実施形態に係る効果　
　以上のように、カーナビゲーションシステム７００がサーバ４００またはサーバ３００及び５００と通信することで、スマートフォンを用いなくても予約システム１が実現できる。本実施形態は、例えば電気自動車１００に乗車中に予約システム１にアクセスする場合において特に使い勝手が良い。

　なお、本実施形態では、上記第１実施形態で説明した処理をカーナビゲーションシステム７００が主体となって行う場合を例に説明したが、カーナビゲーションシステム７００は第２実施形態で説明した処理を行っても良い。

　もちろん、カーナビゲーションシステム７００は、第３実施形態で説明した処理を主体となって行っても良い。この際には、カーナビゲーションシステム７００のＲＡＭ７３３が、更にスケジューリングプログラムを保持する。このスケジューリングプログラムが実行されることで、カーナビゲーションシステム７００のプロセッサ４３１（または制御部７３０全体）は、図１９Ａに示す機能を実現する。そして、図２０乃至図２５に示すダイアグラムは、例えばカーナビゲーションシステム７００の表示部７１０に表示される。スケジューリングプログラムもまた、いずれかのサーバからダウンロードされても良いし、ユーザに販売される時点でＲＡＭ７３３に保持されていても良い。

　７．変形例など　
　以上のように、上記実施形態に係る情報処理装置は、電気自動車のバッテリを充電する給電ステーションを予約するための情報処理装置である。情報処理装置（200,400,または700）は、電気自動車のバッテリ残量を示す第１情報(437 in 図6A)、目的地に関する第２情報(436 in 図6A)、及び目的地に至るまでの経路に関する第３情報(渋滞情報335 in 図6A)を受信する受信部(450 in 図6B)と、少なくとも第２情報(目的地436 in 図6A)と第３情報(渋滞335 in 図6A)とに基づいて、目的地に至るまでの推奨経路を検索する第１検索部(451 in 図6B)と、目的地までの間にある給電ステーションを検索する第２検索部(452 in 図6B)と、第１情報(437 in 図6A)と、検索された推奨経路とに基づいて、目的地に至るまでの間にバッテリの充電が必要か否かを判断する第１判断部(453 in 図6B)と、第１判断部においてバッテリの充電が必要と判断された場合(S16 in 図8)、第２検索部において検索されたいずれかの給電ステーションを、ユーザからの命令を待つことなく予約(S18 in 図8)する予約部(454 in 図6B)とを備える。

　本構成によれば、情報処理装置がバッテリ残量などに応じて適切な給電ステーションを予約する。従って、効率的に給電ステーションの予約が可能となる。更に、電気自動車に乗車中のユーザはバッテリ残量を気にする必要がなく、ユーザに対して安心感を与えることができる。

　なお、上記実施形態は一例に過ぎず、種々の変形が可能である。図５７は、給電ステーション８００の保持する情報の一例を示す。図示するように、給電ステーション８００（station 1, station 2）はそれぞれ、下記の情報を保持する。　
　・ＩＤ：給電ステーション固有の識別番号　
　・待ち台数：現在の待ち台数　
　・料金：充電料金　
　・位置：給電ステーションが設置された位置座標　
　・予約リスト：現在の予約状況。

　情報処理装置（スマートフォン２００、サーバ４００、またはカーナビゲーションシステム７００）は、設定されたルート付近に設けられた給電ステーション８００から、これらの情報を給電ステーション情報５３５及び予約情報５３６として受信する。そして、現在の状況及び状況予測（例えば渋滞など）、並びにユーザ設定情報４３６に基づいて、推奨する給電ステーション８００を決定し、決定された給電ステーション８００に対して予約を要求する（図５７の例ではStation 1）。走行中にユーザが最寄りの給電ステーション８００を知りたい場合には、例えばスマートフォン２００やカーナビゲーションシステム７００に設けられた給電ステーション探索ボタンを押す。すると、スマートフォン２００やカーナビゲーションシステム７００の例えば通信部７４０は、給電ステーション８００からのビーコンを受信して、図５７の例であると、２つの給電ステーション（Station 1, Station 2）の存在を認識し、これらに対して給電ステーション情報５３５及び予約情報５３６を要求できる。複数の給電ステーションが存在する場合、情報処理装置は、各給電ステーションに割り当てられたＩＤによって、各ステーションを識別できる。

　図５８は、電気自動車１００及び給電ステーション８００のブロック図であり、特にこれらが保持する情報について示している。図５８に示す電気自動車１００は、乗車中のユーザが保持するスマートフォン２００及び電気自動車に取り付けられたカーナビゲーションシステム７００を含む。

　まず、図示するように給電ステーション８００は、図５７で説明した情報（位置、待ち台数、料金、ＩＤ、予約時刻と予約状況など）を保持する。そして、給電ステーション８００の有する通信機能により、これらの情報を電気自動車１００へ送信可能である。なお、給電ステーション８００は、スマートフォン２００と同様にユーザ入力を受け付ける機能及び表示部を備えていても良い。そして、これらの機能により、給電ステーション８００が、ユーザからの次回の充電予約を受け付けても良い。すなわち、充電予約はスマートフォン（またはカーナビゲーションシステム）だけでなく、給電ステーション８００においてなされても良い。

　次に電気自動車１００について説明する。図示するように電気自動車１００は、センサによって車の位置情報、目的位置、現在時刻、及びバッテリ残量に関する情報を得る。また、サーバから最新の地図データを受信する。更に電気自動車１００は、給電ステーションから位置、待ち台数、料金、ＩＤ、予約時刻、及び予約状況に関する情報を取得する。そしてこれらの情報から、電気自動車１００の演算部（プロセッサ）が、現在地と給電ステーションとの間の距離と所要時間を計算し、更に給電ステーションから目的地までの距離と所要時間を計算する。この結果、給電ステーション到着時刻、予約可能時刻、帰宅時のバッテリ残量、及び帰宅予定時刻が算出され、これらに加えて待ち台数、料金、及びＩＤが表示部に表示される。そして電気自動車１００は、推奨する給電ステーションのいずれかを仮予約する。

　また、上記実施形態では給電ステーションの予約の具体例につき、幾つかの例を挙げて説明したが、他にも種々の使用方法が考えられる。この点につき、図５９乃至図６６を用いて説明する。図５９乃至図６６は、スマートフォン２００またはカーナビゲーションシステム７００の表示画面例の模式図である。図５９は、目的地を自宅に指定した場合であり、新橋方面から、木場の自宅までのルートが強調表示されている。この画面の左下に表示されている「最寄給電ステーション」なる表示をユーザが選択すると、図６０に示すように、自宅に向かうルート付近にある給電ステーションＡ、Ｂが検索結果として表示される。給電ステーションＡへのルートは実線で示され、給電ステーションＢへのルートは破線で示されている。また、情報処理装置により、給電ステーションＡ及びＢのそれぞれを選択した際の、ステーション到着時刻、帰宅予定時刻、及び帰宅時の電池残量が算出されて、表示部に表示される。更に、各給電ステーションＡ及びＢから受信した待ち台数、最速給電開始時刻、及び予約可能時刻も、表示部に表示される。

　そして、ユーザの充電ポリシーが、自宅までのルートより遠くても、自宅到着時刻を優先する場合には、図６１に示すように、情報処理装置は、給電ステーションＡの第１推奨（１８：４０）仮予約または本予約する。

　図６２は、ユーザの充電ポリシーが、帰宅時におけるバッテリの残量を優先する場合を示している。図示するように、給電ステーションＡを選択した際のバッテリ残量は９５％であり、給電ステーションＢを選択した際は９８％である。従って情報処理装置は、給電ステーションＢの第１推奨１（１９：４０）を仮予約または本予約する。

　図６３は、ユーザの充電ポリシーが、帰宅時におけるバッテリの残量を優先すると共に、待ち時間を使って用事を済ます等の理由で、最も早い時刻の給電予約は行わない場合を示している。図示するように情報処理装置は、給電ステーションＢの第２推奨（２０：１０）を仮予約または本予約する。図６３の充電ポリシーの場合、ユーザが待ち時間の設定を自由に行えることが好ましい。この場合、図６４に示すように、「もっと見る」なるアイコンを選択することで、第１乃至第３推奨以外に充電可能な時間帯が表示される。

　図６５は、ユーザが食事のために寄り道する場合を示している。図示するように、画面左下の「寄り道」なるアイコンを選択することで、ルート付近でお薦めの飲食店が表示される。そのいずれかをユーザが選択すると、電気自動車１００は、それまでの予約をキャンセルして、自動的に遅い時間の予約を取り直す。例えば、当初は図６２のように１９：４０に給電ステーションＢが予約されていたとすると、電気自動車１００はこの予約をキャンセルし、図６５に示すように、給電ステーションＢの２０：１０の予約を取り直す。また、この予約変更に伴い、給電ステーション到着時刻、及び帰宅予定時刻が再計算される。なお、飲食店などの情報は、例えば無線通信によりネットワーク６００を介していずれかのサーバから情報処理装置にダウンロードされても良い。

　図６６は、当初は図６１に示すように給電ステーションＡが１８：５０に予約されていた場合であって、給電ステーションＡへのルートが事故などにより通行止めになった場合を示している。この場合、電気自動車１００は、給電ステーションＡの予約をキャンセルし、現時点での最も推奨できる給電ステーションを仮予約または本予約する。図６６の例であると、電気自動車１００は、給電ステーションＢの１９：４０を仮予約または本予約する。

　また、上記第２実施形態では、当初の予約の時刻に給電ステーションに間に合わない場合を例に説明した。しかし、当初の予約の時刻よりも早い時刻に給電ステーションに到着する場合にも、上記第２実施形態は適用できる。すなわち、例えば渋滞情報や渋滞予測と異なり、予測以上に早い時刻に給電ステーションに到着すると情報処理装置（第２判断部）が判断した場合、予約部が現在の予約をキャンセルし、当初の予約よりも早い時刻を仮予約または本予約しても良い。この場合、情報処理装置は、表示部に例えば「予約を切り替えますか？」といったメッセージを表示し、ユーザによる承認を促しても良い。

　また、現在の予約では、給電ステーションでの待ち時間が発生する場合に、他者による、より良い時刻の予約のキャンセルが発生した場合、情報処理装置は、その旨を予約情報としてサーバ５００から受信し、現在の予約を、キャンセルされて空いた時刻に自動的に繰り上げても良い。この場合も、繰り上げた予約は仮予約とし、本予約して良いか否かの承認をユーザに求めても良い。

　更に情報処理装置は、ユーザによる予約の割り込みリクエストを受け付けても良い。例えば既に予約済みの時間帯に別のユーザが予約したいと考えた際に、情報処理装置は割り込みリクエストを受け付ける。そして情報処理装置は、例えば予約情報の一部として、当該時間帯に予約しているユーザに対して、割り込みリクエストが発生していることを通知する。当該ユーザが割り込みリクエストを承認した場合には、情報処理装置は、その旨をサーバ５００へ送信し、予約の切り替えを命令する。この場合には、例えば予約を譲ったユーザに対して次回の充電料金の割引を行ったり、または割り込んだユーザに対しては割増料金を適用するようにしたりしても良い。

　以上のように情報処理装置は、ユーザの希望に従って、その都度、最適と予想される給電ステーションを自動的に予約する。従って、ユーザは給電ステーションの予約の煩雑さから解放され、また突発的な事情が発生した場合であっても、給電ステーションの予約を考慮する必要がない。その結果、電気自動車の使い勝手が格段に向上する。

　なお、上記実施形態で説明した種々の機能は、ハードウェアで実装されてもよいし、ソフトウェアとハードウェアの組み合わせで実装されてもよい。ソフトウェアで実装される場合、その機能は、１つまたはそれ以上の命令またはコード（プログラム）として、コンピュータ読み取り可能な記憶媒体に記憶され、または当該記憶媒体によって伝送され得る。このような記録媒体としては、コンピュータまたはプロセッサによりアクセスできればよく、特に限定されない。一例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）（ＵＳＢメモリやメモリカードを含む）、ＣＤ－ＲＯＭ等の光ディスク、ハードディスク等の磁気ディスク等を用いることができる。また、無線または有線の電気通信回線によって伝送され得る。各種のデータについても同様である。

　本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

Claims (13)

1. 　電気自動車のバッテリを充電する給電ステーションを予約するための情報処理装置であって、
   　前記電気自動車のバッテリ残量を示す第１情報、目的地に関する第２情報、及び目的地に至るまでの経路に関する第３情報を受信する受信部と、
   　少なくとも前記第２情報と前記第３情報とに基づいて、前記目的地に至るまでの推奨経路を検索する第１検索部と、
   　前記目的地までの間にある前記給電ステーションを検索する第２検索部と、
   　前記第１情報と、前記検索された推奨経路とに基づいて、前記目的地に至るまでの間に前記バッテリの充電が必要か否かを判断する第１判断部と、
   　前記第１判断部において前記バッテリの充電が必要と判断された場合、前記第２検索部において検索されたいずれかの前記給電ステーションを、ユーザからの命令を待つことなく予約する予約部と
   　を具備する情報処理装置。
2. 　前記第３情報に基づいて、前記予約の通りに前記給電ステーションに到着できるか否かを判断する第２判断部を更に備え、
   　前記予約部は、前記第２判断部が、前記予約の通りに前記給電ステーションに到着できないと判断した場合、当該予約をキャンセルして、次に推奨されるいずれかの前記給電ステーションを、前記ユーザからの命令を待つことなく予約する、請求項１記載の情報処理装置。
3. 　前記第３情報は、前記目的地に至る複数の経路における現在の渋滞情報、及び／または予測される渋滞情報である、請求項１または２記載の情報処理装置。
4. 　電気自動車のバッテリを充電する給電ステーションを予約するための情報処理装置であって、
   　前記電気自動車の第１乗車予約に関する第１乗車予定期間を示す第１情報、及び乗車時におけるバッテリ残量を示す第２情報を登録する登録部と、
   　前記第２情報に基づき、前記第１乗車予定期間内において前記バッテリの充電が必要か否かを判断する第１判断部と、
   　前記第１判断部において前記バッテリの充電が必要と判断された場合、いずれかの前記給電ステーションを、ユーザからの命令を待つことなく予約する予約部と
   　を具備する情報処理装置。
5. 　前記登録部は、前記第１乗車予約における目的地に関する第３情報を登録し、
   　前記情報処理装置は、前記目的地に至るまでの推奨経路を検索する第１検索部と、
   　前記目的地までの間にある前記給電ステーションを検索する第２検索部と
   　を更に備え、前記第１判断部において、前記推奨経路を走行した場合に前記バッテリの充電が必要と判断された場合、前記予約部は、前記第２検索部において検索されたいずれかの前記給電ステーションを、ユーザからの命令を待つことなく予約する、請求項４記載の情報処理装置。
6. 　前記第１乗車予約よりも前の時刻における第２乗車予約を登録し、
   　前記第１判断部が、前記第２乗車予約における第２乗車予定期間内において前記バッテリの充電が必要であり、前記第１乗車予定期間内における前記バッテリの充電が必要でないと判断した場合、前記予約部は、前記第１乗車予約においてした前記給電ステーションの予約をキャンセルする、請求項４または５記載の情報処理装置。
7. 　前記予約部による、前記ユーザからの命令を待つこと無くした予約は仮予約であり、
   　前記仮予約の後、前記ユーザからの承認を受け付けた際に前記予約部は前記仮予約を本予約に切り替える、請求項１または４記載の情報処理装置。
8. 　電気自動車のバッテリを充電する給電ステーションを予約するための情報処理装置であって、
   　目的地までのルートを探索すると共に、前記ルートにおけるいずれかの前記給電ステーションを予約する制御部と、
   　前記ルートを表示する表示部と
   　を具備し、前記表示部は、
   　前記探索された目的地に至るルートにおいて候補となる複数の給電ステーションと、前記複数の給電ステーションのうちの第１推奨給電ステーションを表示し、
   　更に、前記第１推奨給電ステーションにつき仮予約済みであることと、該仮予約を本予約に切り替えることの承認を促す旨とを表示し、
   　前記承認を受信した場合に、前記仮予約が本予約に切り替えられた前記第１推奨給電ステーションと共に前記ルートを表示する、情報処理装置。
9. 　前記制御部が、前記電気自動車が、前記予約の通りに前記第１推奨給電ステーションに到着できないと判断した場合、前記表示部は、
   　前記第１推奨給電ステーションと異なる第２推奨給電ステーションにつき仮予約済みであることと、該仮予約を本予約に切り替えることの承認を促す旨とを表示する、請求項８記載の情報処理装置。
10. 　前記表示部は、前記第１推奨給電ステーションと異なる第２推奨給電ステーションを更に表示し、
    　前記第１推奨給電ステーションの否認と前記第２推奨給電ステーションの選択を受け付けた際に、前記表示部は、前記第２推奨給電ステーションを経由して前記目的地に至るルートを表示する、請求項８記載の情報処理装置。
11. 　前記表示部は、前記第１推奨給電ステーションを表示すると共に、該第１推奨給電ステーションにおいて予約可能な時刻を更に表示可能である、請求項８乃至１０いずれか１項記載の情報処理装置。
12. 　電気自動車のバッテリを充電する給電ステーションを予約するための情報処理方法であって、
    　前記電気自動車のバッテリ残量を示す第１情報、目的地に関する第２情報、及び目的地に至るまでの経路に関する第３情報を受信することと、
    　少なくとも前記第２情報と前記第３情報とに基づいて、前記目的地に至るまでの推奨経路を検索することと、
    　前記目的地までの間にある前記給電ステーションを検索することと、
    　前記第１情報と、前記検索された推奨経路とに基づいて、前記目的地に至るまでの間に前記バッテリの充電が必要か否かを判断することと、
    　前記バッテリの充電が必要と判断された場合、前記検索されたいずれかの前記給電ステーションを、ユーザからの命令を待つことなく予約することと
    　を具備する情報処理方法。
13. 　電気自動車のバッテリを充電する給電ステーションを予約するための情報処理プログラムであって、プロセッサによって実行されることにより、前記プロセッサに対して、
    　前記電気自動車のバッテリ残量を示す第１情報、目的地に関する第２情報、及び目的地に至るまでの経路に関する第３情報を受信させ、
    　少なくとも前記第２情報と前記第３情報とに基づいて、前記目的地に至るまでの推奨経路を検索させ、
    　前記目的地までの間にある前記給電ステーションを検索させ、
    　前記第１情報と、前記検索された推奨経路とに基づいて、前記目的地に至るまでの間に前記バッテリの充電が必要か否かを判断させ、
    　前記バッテリの充電が必要と判断された場合、前記検索されたいずれかの前記給電ステーションを、ユーザからの命令を待つことなく予約させる、情報処理プログラム。

Images