ホーム > 特許ランキング > Ｆｕｔｕｒｅ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022153996
(43)【公開日】2022-10-13
(54)【発明の名称】電動車両管理システム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20221005BHJP
G06Q 30/06 20120101ALI20221005BHJP
【ＦＩ】
G06Q50/10
G06Q30/06 350
G06Q30/06 312
【審査請求】未請求
【請求項の数】3
【出願形態】ＯＬ
(21)【出願番号】P 2021056802
(22)【出願日】2021-03-30
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
２．ＺＩＧＢＥＥ
(71)【出願人】
【識別番号】520416071
【氏名又は名称】Ｆｕｔｕｒｅ株式会社
(74)【代理人】
【識別番号】100139114
【弁理士】
【氏名又は名称】田中 貞嗣
(74)【代理人】
【識別番号】100139103
【弁理士】
【氏名又は名称】小山 卓志
(74)【代理人】
【識別番号】100214260
【弁理士】
【氏名又は名称】相羽 昌孝
(74)【代理人】
【識別番号】100119220
【氏名又は名称】片寄 武彦
(72)【発明者】
【氏名】井原 慶子
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049BB53
5L049BB68
5L049CC11
(57)【要約】
【課題】交通のための決済に限定されることなく、サービス業も含めた幅広い決済に用いることが可能で、ユーザーの利便性が向上する電動車両管理システムを提供する。
【解決手段】本発明に係る電動車両管理システムは、ユーザーに対する電動車両のシェアサービスの提供を行うための管理を行う電動車両管理システムであって、電動車両をシェアしたユーザーに対する費用を算出する電動車両費用算出部（ステップＳ１６０１）と、電動車両を利用してユーザーによって提供されたサービスに対する対価を算出するサービス対価算出部（ステップＳ１６０２）と、電動車両の利用に伴いユーザーが受けたサービスに対する費用を算出するサービス費用算出部（ステップＳ１６０３）と、前記電動車両費用算出部で算出された費用と、前記サービス対価算出部で算出された対価と、前記サービス費用算出部で算出された費用と、を併せて決裁する決裁部（ステップＳ１６０５）と、を有することを特徴とする。
【選択図】 図２７
【解決手段】本発明に係る電動車両管理システムは、ユーザーに対する電動車両のシェアサービスの提供を行うための管理を行う電動車両管理システムであって、電動車両をシェアしたユーザーに対する費用を算出する電動車両費用算出部（ステップＳ１６０１）と、電動車両を利用してユーザーによって提供されたサービスに対する対価を算出するサービス対価算出部（ステップＳ１６０２）と、電動車両の利用に伴いユーザーが受けたサービスに対する費用を算出するサービス費用算出部（ステップＳ１６０３）と、前記電動車両費用算出部で算出された費用と、前記サービス対価算出部で算出された対価と、前記サービス費用算出部で算出された費用と、を併せて決裁する決裁部（ステップＳ１６０５）と、を有することを特徴とする。
【選択図】 図２７
【特許請求の範囲】
【請求項1】
ユーザーに対する電動車両のシェアサービスの提供を行うための管理を行う電動車両管理システムであって、
電動車両をシェアしたユーザーに対する費用を算出する電動車両費用算出部と、
電動車両を利用してユーザーによって提供されたサービスに対する対価を算出するサービス対価算出部と、
電動車両の利用に伴いユーザーが受けたサービスに対する費用を算出するサービス費用算出部と、
前記電動車両費用算出部で算出された費用と、前記サービス対価算出部で算出された対価と、前記サービス費用算出部で算出された費用と、を併せて決裁する決裁部と、を有することを特徴とする電動車両管理システム。
電動車両をシェアしたユーザーに対する費用を算出する電動車両費用算出部と、
電動車両を利用してユーザーによって提供されたサービスに対する対価を算出するサービス対価算出部と、
電動車両の利用に伴いユーザーが受けたサービスに対する費用を算出するサービス費用算出部と、
前記電動車両費用算出部で算出された費用と、前記サービス対価算出部で算出された対価と、前記サービス費用算出部で算出された費用と、を併せて決裁する決裁部と、を有することを特徴とする電動車両管理システム。
【請求項2】
電動車両をリロケートしたユーザーに対する対価を算出するリロケート対価算出部をさらに有し、
前記決裁部が、リロケート対価算出部で算出された対価も併せて決済することを特徴とする請求項１に記載の電動車両管理システム。
前記決裁部が、リロケート対価算出部で算出された対価も併せて決済することを特徴とする請求項１に記載の電動車両管理システム。
【請求項3】
前記サービスが、飲食業、小売業、宅配業、清掃業、警備業、金融・保険業、観光業、宿泊施設提供業、医療・福祉業のいずれかに属するもの又は行政サービスであることを特徴とする請求項１又は請求項２に記載の電動車両管理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、シェア利用される電動車両を管理するために用いられる電動車両管理システムに関する。
【背景技術】
【0002】
近年、ＭａａＳ（Ｍｏｂｉｌｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ）というキーワードが話題となる頻度が高い。その特徴は、個人所有の交通手段を用いずに、公共交通機関や、電動車両などのモビリティをシェアにより利用することで、シームレスな移動ができるようになること、そして、公共交通機関の利用やモビリティのシェアリングのための予約や支払いにＩＣＴを用いることで、ユーザーの利便性を大幅に高めることなどを挙げることができる。このようなＭａａＳによれば、都市部では、移動が効率化されることで交通渋滞や環境問題といった課題の解決に役立てることができる。また、地方では、交通弱者対策にもなり得る。
【0003】
Ｍａａｓにおけるモビリティのシェアリングシステムとしては、例えば、特許文献１（特表２０１９－５２５７１９号公報）に、電動車両とドッキングステーションとからなり、ドッキングステーションには、電動車両をドッキングステーションに解除可能に固定するコネクタと、電動車両の補給を行う充電ユニットと、備えた電動車両のシェアリングシステムが開示されている。
【特許文献1】特表２０１９－５２５７１９号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
これまで、例えば、特許文献１記載の電動車両のシェアリングの費用や、この電動車両のシェアリングとリンクさせた公共交通機関の利用の費用などを、トータル的にスマートフォン等を用いて決済する、ということは提案されていた。ところで、電動車両は移動の目的のみのために用いることに限定されるものではなく、移動が伴ったサービスの提供にも利用可能である。しかしながら、従来の概念では、電動車両のシェアリングの費用は、公共交通機関の利用の費用との組み合わせでの決済に限定されている、という課題があった。
【課題を解決するための手段】
【0005】
この発明は、上記のような課題を解決するものであって、本発明に係る電動車両管理システムは、ユーザーに対する電動車両のシェアサービスの提供を行うための管理を行う電動車両管理システムであって、電動車両をシェアしたユーザーに対する費用を算出する電動車両費用算出部と、電動車両を利用してユーザーによって提供されたサービスに対する対価を算出するサービス対価算出部と、電動車両の利用に伴いユーザーが受けたサービスに対する費用を算出するサービス費用算出部と、前記電動車両費用算出部で算出された費用と、前記サービス対価算出部で算出された対価と、前記サービス費用算出部で算出された費用と、を併せて決裁する決裁部と、を有することを特徴とする。
【0006】
また、本発明に係る電動車両管理システムは、電動車両をリロケートしたユーザーに対する対価を算出するリロケート対価算出部をさらに有し、前記決裁部が、リロケート対価算出部で算出された対価も併せて決済することを特徴とする。
【0007】
また、本発明に係る電動車両管理システムは、前記サービスが、飲食業、小売業、宅配業、清掃業、警備業、金融・保険業、観光業、宿泊施設提供業、医療・福祉業のいずれかに属するもの又は行政サービスであることを特徴とする。
【発明の効果】
【0008】
本発明に係る電動車両管理システムは、電動車両をシェアしたユーザーに対する費用と、電動車両を利用してユーザーによって提供されたサービスに対する対価と、電動車両の利用に伴いユーザーが受けたサービスに対する費用とを併せて決裁する決裁部を有しているので、このような本発明に係る電動車両管理システムによれば、交通のための決済に限定されることなく、サービス業も含めた幅広い決済に用いることが可能となり、ユーザーの利便性が向上する。
【図面の簡単な説明】
【0009】
【図1】本発明の実施形態に係る電動車両管理システム１の概要を模式的に説明する図である。
【図2】本発明の実施形態に係る電動車両管理システム１で用いられるユーザーの情報処理端末装置の一例であるスマートフォン１０のブロック図である。
【図3】スマートフォン１０のタッチパネル部３０に表示される電動車両管理システム１の画面例を示す図である。
【図4】本発明の実施形態に係る電動車両管理システム１におけるアカウント作成・完了通知処理のフロー例を示す図である。
【図5】アカウント作成時にユーザーデータベース１１０に登録されるデータ群の一例を示す図である。
【図6】ユーザーデータベース１１０のデータ構造例を示す図である。
【図7】本発明の実施形態に係る電動車両管理システム１の管理対象である電動車両２００を説明する図である。
【図8】本発明の実施形態に係る電動車両管理システム１のブレーキ制御部２２６の動作を説明する模式図である。
【図9】車両データベース１２０のデータ構造例を示す図である。
【図10】ユーザーの電動車両２００利用のシチュエーションの違いによる呼称の違いを示す図である。
【図11】電動車両２００が運用される地域のマップの一例を示す図である。
【図12】駐車スペースデータベース１３０のデータ構造例を示す図である。
【図13】本発明の実施形態に係る電動車両管理システム１における電動車両２００の予約から解錠までの処理のフロー例を示す図である。
【図14】本発明の実施形態に係る電動車両管理システム１における電動車両２００の移動終了後のシェア終了処理のフロー例を示す図である。
【図15】本発明の実施形態に係る電動車両管理システム１における電動車両２００の予約からシェア終了までの処理のフロー例を示す図である。
【図16】本発明の実施形態に係る電動車両管理システム１におけるリロケート要否判定処理のフローチャートを示す図である。
【図17】本発明の実施形態に係る電動車両管理システム１におけるリロケーター候補ユーザー選定処理のフローチャートを示す図である。
【図18】本発明の実施形態に係る電動車両管理システム１におけるリロケート先選定処理のフローチャートを示す図である。
【図19】本発明の実施形態に係る電動車両管理システム１における通知処理のフローチャートを示す図である。
【図20】スマートフォン１０のタッチパネル部３０における画面表示例を示す図である。
【図21】本発明の実施形態に係る電動車両管理システム１におけるリロケートのための電動車両２００の解錠の処理のフロー例を示す図である。
【図22】本発明の実施形態に係る電動車両管理システム１におけるリロケート終了後の処理のフロー例を示す図である。
【図23】サービス業者データベース１４０のデータ構造例を示す図である。
【図24】本発明の実施形態に係る電動車両管理システム１におけるリロケート兼配達案件選定処理のフローチャートを示す図である。
【図25】本発明の実施形態に係る電動車両管理システム１におけるリロケーター兼ランナー候補ユーザー選定処理のフローチャートを示す図である。
【図26】スマートフォン１０のタッチパネル部３０における画面表示例を示す図である。
【図27】本発明の実施形態に係る電動車両管理システム１における口座データ決済処理のフローチャートを示す図である。
【図28】スマートフォン１０のタッチパネル部３０における画面表示例を示す図である。
【発明を実施するための形態】
【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】
このような近接無線による指令を受けて、電動車両２００は、ブレーキ制御部２２６の動作を止めて、ロックが解錠される。
【0103】
以上のような処理で、ロックが解錠された電動車両２００は、シェアラーとしてのユーザーによってシェア利用される。引き続き、このユーザーによって、電動車両２００が返却される際の処理を説明する。
【0104】
ステップＳ４１４において、スマートフォン１０からサーバー１００に対して、シェア終了処理要求が発信されると、サーバー１００はこれを受けて、ステップＳ３２１において、Ｓ４２３において、対象車両に対する施錠指令の生成及び送信の依頼をスマートフォン１０に送信する。
【0105】
スマートフォン１０は、これを受け、ステップＳ４１５で、電動車両２００のブレーキ制御部２２６の動作を開始する施錠指令を生成し、これを、電動車両２００に対して、近接無線通信により送信する。
【0106】
これを受信した電動車両２００側では、ステップＳ４３２で、ブレーキ制御部２２６を動作させて、ロックをかけて、電動車両２００の走行を不能とする。
【0107】
続く、電動車両２００は、ＧＰＳ信号受信部２５２で取得した位置データと、残量データ取得部２５５で取得したバッテリー残量データを、近接無線通信部２５３からスマートフォン１０に送信する。これを受けたスマートフォン１０は、電動車両２００の位置データとバッテリー残量データとを、サーバー１００に送信する。このような処理ステップを有するため、サーバー１００は電動車両２００が返却された際の位置データとバッテリー残量データとを把握することが可能となる。ステップＳ４２４では、これら位置データとバッテリー残量データとに基づいて、車両データベース１２０の対象車両のデータを更新する。また、車両データベース１２０における状態データも、解錠から施錠に変更される。
【0108】
サーバー１００側では、ステップＳ４２４において、ユーザーデータベース１１０における、該当するユーザーのアカウントで、クレジットカードに対する課金処理を行うから、或いは、口座データのポイントから減算を行う決済処理を実行する。
【0109】
次に、サーバー１００は、ステップＳ４２６において、スマートフォン１０に対して、シェア終了処理が完了し、決済処理が完了した報告を送信する。このような報告には、ポイントの減算に伴う口座の残高なども含めることができる。ステップＳ４１７で、このような報告を受信したスマートフォン１０は、タッチパネル部３０で当該報告事項を表示する。
【0110】
以上、本発明に係る電動車両管理システム１は、電動車両２００で取得されるデータは、ユーザーのスマートフォン１０に近接無線通信部によって送信され、ユーザーのスマートフォン１０が、当該データを車両管理のためのサーバー１００に送信するように構成されており、このような本発明に係る電動車両管理システム１によれば、各々の電動車両にＬＴＥや５Ｇなどの無線データ通信手段を搭載する必要はなく、無線データ通信用のモジュールのコストや、通信費などのコストを削減できる。
【0111】
次に、電動車両２００が市中で遍在してしまったときの電動車両管理システム１の処理について説明する。このような処理においては、まず、電動車両管理システム１が管理している電動車両２００それぞれについて、リロケートが必要であるか否かが判定される処理が実行される。
【0112】
図１６は本発明の実施形態に係る電動車両管理システム１におけるリロケート要否判定処理のフローチャートを示す図である。
【0113】
図１６において、ステップＳ１０００でリロケート要否判定処理が開始されると、続いて、ステップＳ１００１に進み、（最初の車両ＩＤ）を変数にセットする。
【0114】
ステップＳ１００２では、車両データベース１２０から、変数にセットされた当該ＩＤの電動車両２００の位置データを取得する。
【0115】
ステップＳ１００３では、取得された当該位置データが要リロケートエリアデータの範囲内であるか否かが判定される。ここで、図１１を参照して、要リロケートエリアデータについて説明する。要リロケートエリアは、そのエリア内に電動車両２００が存在していたとしても、電動車両２００の利用があまり期待できないエリアであり、例えば、市中の外れのエリアなどを挙げることができる。要リロケートエリアデータは、このようなエリアを規定するデータであり、図１１では、斜線部分のエリアが該当する。
【0116】
ステップＳ１００３で、位置データが要リロケートエリアデータの範囲内であると、ステップＳ１００４に進み、当該車両は要リロケートと判定される。このステップで要リロケートと判定される電動車両２００は、図１１によれば、乗り捨て車両Ａや乗り捨て車両Ｂが該当する。
【0117】
ステップＳ１００３で、位置データが要リロケートエリアデータの範囲内ではないと、ステップＳ１００５に進み、当該車両はリロケート不要と判定される。図１１によれば、駐車スペースＡや駐車スペースＢに駐車している電動車両２００が該当する。
【0118】
ステップＳ１００６では、全ての車両ＩＤについて判定が完了したか否かが判定される。ステップＳ１００６の判定がＮＯであれば、ステップＳ１００７に進む。ステップＳ１００７では、変数を次の車両ＩＤに変更して、ステップＳ１００２に戻りループする。
【0119】
ステップＳ１００６の判定がＹＥＳであれば、ステップＳ１００８に進み、リロケート要否判定処理が終了する。
【0120】
上記のようなリロケート要否判定処理によって、リロケートが必要な電動車両２００が存在すると、続いて、リロケーターの候補となるユーザーの選定が行われる。
【0121】
図１７は本発明の実施形態に係る電動車両管理システム１におけるリロケーター候補ユーザー選定処理のフローチャートを示す図である。
【0122】
図１７において、ステップＳ１１００で、リロケーター候補ユーザー選定処理が開始されると、次のステップＳ１１０１では、要リロケートと判定された電動車両２００の車両位置データを車両データベース１２０から取得する。図において、左側がユーザーのスマートフォン１０による処理を示しており、中央がサーバー１００による処理を示しており、右側が電動車両２００による処理を示している。これらの間の処理はデータ通信を伴うものであり、データ通信は矢印によって図中に示される。
【0123】
続いて、ステップＳ１１０２において、リロケーター希望有りのユーザー位置データをユーザーデータベース１１０から取得する。
【0124】
ステップＳ１１０３では、取得したユーザー位置データが、車両位置データから所定範囲内であるか否かが判定される。ステップＳ１１０３の判定がＮＯであれば、リロケーター候補ユーザーは存在しないので、処理を終了する。なお、本フローチャートによる処理を、所定時間間隔毎（例えば、１０分程度毎）に実行することで、リロケーター候補ユーザーが後に選定されることは期待できる。
【0125】
一方、ステップＳ１１０３の判定がＹＥＳであれば、ステップＳ１１０４に進み、着目しているユーザーをリロケーター候補として選定し、ステップＳ１１０５に進み、リロケーター候補ユーザー選定処理を終了する。
【0126】
次に、リロケーターによって、要リロケートと判定された電動車両２００を、どの駐車スペースに移動してもらうかについての選定、すなわち、リロケート先の選定を行う処理について説明する。図１８は本発明の実施形態に係る電動車両管理システム１におけるリロケート先選定処理のフローチャートを示す図である。
【0127】
図１８において、ステップＳ１２００でリロケート先選定処理が開始されると、続くステップＳ１２０１においては、所定の変数に（最初の駐車スペースＩＤ）がセットされる。
【0128】
ステップＳ１２０２では、車両データベース１２０に記憶される車両位置データと、駐車スペースデータベース１３０の駐車スペース位置データとに基づいて、駐車スペース毎の駐車台数の計数を実行する。
【0129】
次に、ステップＳ１２０３においては、駐車スペースデータベース１３０に、予め記憶される台数閾値データを取得する。
【0130】
ステップＳ１２０４では、計数された駐車台数と台数閾値データを比較し、（駐車台数）≦（台数閾値データ）の関係であるか否かが判定される。
【0131】
ステップＳ１２０４の判定結果がＹＥＳである場合には、ステップＳ１２０５に進み、着目している駐車スペースをリロケート先の候補として判定する。一方、ステップＳ１２０４の判定結果がＮＯである場合には、ステップＳ１２０６に進み、着目している駐車スペースをリロケート先の候補として判定しない。
【0132】
ステップＳ１２０７では、全ての駐車スペースＩＤを判定済みであるかが判定される。ステップＳ１２０７の判定がＮＯであると、ステップＳ１２０９に進み、変数を次の駐車スペースＩＤとして、ステップＳ１２０２に戻る。
【0133】
ステップＳ１２０７の判定がＹＥＳであると、ステップＳ１２０８に進み、リロケート先の候補として判定した駐車スペースのうち、最も要リロケートと判定された電動車両２００に近いものを、移動先として選定し、ステップＳ１２１０に進み、リロケート先選定処理を終了する。
【0134】
以上のような一連の処理によって、要リロケートと判定された電動車両２００、リロケートを依頼する候補となるユーザー、リロケート先の駐車スペースが決定するので、次に、これらの情報をリロケーター候補ユーザーに通知する処理を実行する。
【0135】
図１９は本発明の実施形態に係る電動車両管理システム１における通知処理のフローチャートを示す図である。
【0136】
図１９において、ステップＳ１３００で通知処理が開始されると、続いて、ステップＳ１３０１ に進み、ユーザーデータベース１１０からリロケーター候補として選定されたユーザーのユーザーデータを取得し、ステップＳ１３０２で、ユーザーデータベース１１０において、当該ユーザーはプッシュデータ受信可否の項目で「プッシュデータ受信可」として登録されているか否かを判定する。
【0137】
ステップＳ１３０３においては、要リロケート車両の車両位置データ、リロケート先を示したプッシュ通知を作成する。ここで、要リロケート車両の車両位置データは、適宜マップ等が参照されて、住所表記に変換する。ステップＳ１３０４で、作成したプッシュ通知を送信して、ステップＳ１３０５で通知処理を終了する。
【0138】
図２０は上記のようなプッシュ通知を受信したユーザーのスマートフォン１０のタッチパネル部３０における画面表示例を示す図である。このようなプッシュ通知では、例えば、「○□町三丁目の乗り捨て車両を、９時までに△コンビニエンスストアの駐車スペースＡにリロケートして、リワードを獲得しませんか？リワードは、５００ポイントです。」などのメッセージが表示される。
【0139】
さて、上記のような通知を受信したユーザーは、リロケーターとしてリワードのポイントを獲得するかを判断するが、以下、この判断の結果、ユーザーがリロケーターを受諾した場合の処理の流れについて説明する。ここで、図１１のマップ中のユーザーＢが、乗り捨て車両Ａを、駐車スペースＡに移動する例に基づいて、説明する。
【0140】
図２１は本発明の実施形態に係る電動車両管理システム１におけるリロケートのための電動車両２００の解錠の処理のフロー例を示す図である。図において、左側がユーザーＢのスマートフォン１０による処理を示しており、中央がサーバー１００による処理を示しており、右側が電動車両２００による処理を示している。これらの間の処理はデータ通信を伴うものであり、データ通信は矢印によって図中に示される。
【0141】
サーバー１００が、先のようなメッセージのプッシュ通知を、リロケーター候補であるユーザーＢのスマートフォン１０に送信する。
【0142】
リロケーター候補であるユーザーＢは、ステップＳ５２１でリロケート受諾の旨をサーバー１００に送信すると共に、ステップＳ５１２で、スマートフォン１０によって、要リロケート車両のＱＲコードを撮像し、当該ＱＲコードで読み取られた情報をサーバー１００側に送信する。
【0143】
これを受信したサーバー１００は、ステップＳ５２２でユーザーデータベース１１０・車両データベース１２０を参照して、リロケーター候補のユーザーＩＤからのＱＲコードの送信であること、かつ、ＱＲコードで読み取られた情報が要リロケート車両のものであることを判定する。
【0144】
ステップＳ５２２の判定がＹＥＳであれば、要リロケート車両である電動車両２００のブレーキ制御部２２６の動作を止めて、ロックの解錠を行うように、解錠指令を電動車両２００に対して送信する。これを受けて、ステップＳ５３２で、電動車両２００のロックが解錠する。一方、ステップＳ５２２の判定がＮＯであれば、エラーである旨スマートフォン１０側に送信する。
【0145】
さて、上記のような処理を経て解錠された要リロケート車両を、スペースＡまで移動させたユーザーＢは、サーバー１００とデータ通信を行う。サーバー１００は、リロケートが予定通り完了したかを判定し、リロケートが予定通り完了したと判定すると、ユーザーＢの口座データにポイントを付与する。このようなリロケート終了後の処理について説明する。
【0146】
図２２は本発明の実施形態に係る電動車両管理システム１におけるリロケート終了後の処理のフロー例を示す図である。左側がユーザーＢのスマートフォン１０による処理を示しており、中央がサーバー１００による処理を示しており、右側が電動車両２００による処理を示している。これらの間の処理はデータ通信を伴うものであり、データ通信は矢印によって図中に示される。
【0147】
ステップＳ６１１で、ユーザーＢがスマートフォン１０からサーバー１００に対して、リロケート完了報告を送信すると、サーバー１００側では、ステップＳ６２１で、車両データベース１２０
を参照して、該当の電動車両２００の車両位置データを取得する。
を参照して、該当の電動車両２００の車両位置データを取得する。
【0148】
続いて、ステップＳ６２２では、取得した車両位置データが駐車スペースＡの駐車スペース位置データ内であるか否かを判定する。ステップＳ６２２の判定結果がＹＥＳであれば、ステップＳ６２３に進み、リロケートが完了したものと判定する。一方、ステップＳ６２２の判定結果がＮＯであれば、エラーである旨ユーザーＢのスマートフォン１０に送信する。
【0149】
サーバー１００は、ステップＳ６２３で電動車両２００のリロケートが完了したものと判定すると、ステップＳ６２４において、該当する電動車両２００に対して、施錠指令を送信する。
【0150】
これを受信した電動車両２００側では、ステップＳ６３１で、ブレーキ制御部２２６を動作させて、ロックをかけて、電動車両２００の走行を不能とする。特段の不調が検出されることがなければ、ステップＳ６３２で、サーバー１００に対して、施錠完了報告を送信する。
【0151】
このような施錠完了報告を受信したサーバー１００は、ステップＳ６２５において、ユーザーデータベース１１０における、該当するユーザーのアカウントの、クレジットカードに対して返金処理を行うか、或いは、口座データにポイントを付与する決済処理を実行する。
【0152】
次に、サーバー１００は、ステップＳ６２６において、ユーザーＢのスマートフォン１０に対して、リロケートが完了し、決済処理が完了した報告を送信する。このような報告には、ポイントの減算に伴う口座の残高なども含めることができる。ステップＳ６１２で、このような報告を受信したスマートフォン１０は、タッチパネル部３０で当該報告事項を表示する。
【0153】
ステップＳ６２７では、車両データベース１２０の状態データを、解錠から施錠に変更する更新を実行する。これにより、ユーザーＢによって、リロケートされた電動車両２００は、駐車スペースＡにおいて、再び予約の受付が可能な状態となる。
【0154】
以上のように、本発明に係る電動車両管理システム１は、リロケートが必要であると判定された電動車両２００を、ユーザーにリロケートしてもらう仕組みを有しており、このような本発明に係る電動車両管理システム１によれば、夜間に偏在した電動車両をステーションに再配置するような作業は不要となり、コストを大幅に抑制することができる。
【0155】
これまで、電動車両のシェアリングの費用や、この電動車両のシェアリングとリンクさせた公共交通機関の利用の費用などを、トータル的にスマートフォン等を用いて決済する、ということは提案されていた。
【0156】
ところで、電動車両は移動の目的のみのために用いることに限定されるものではなく、移動が伴ったサービスの提供にも利用可能である。しかしながら、従来の概念では、電動車両のシェアリングの費用は、公共交通機関の利用の費用との組み合わせでの決済に限定されている、という課題があった。
【0157】
そこで、本発明に係る電動車両管理システム１においては、電動車両２００のシェアのための費用と、それに関連したサービスの提供で発生する対価、或いは、電動車両２００のシェアに伴い受けたサービスに対する費用などをトータル的に決済する構成とされている。図１０で示したように、ユーザーは課金が発生するシェアラーとなると同時に、リワード・報酬が発生するランナーとなることができる。また、ユーザーはリワード・報酬が発生するリロケーターとなると同時に、さらにリワード・報酬が発生するランナーとなることもできる。本発明に係る電動車両管理システム１においては、これら電動車両２００の利用・リロケートと関連して発生する課金・リワード・報酬と、電動車両２００を利用して行ったサービス提供の対価・受けたサービスの費用とを、ユーザーデータベース１１０における各ユーザーの口座データで総合的に決済することで、ユーザーの利便性を図るものである。
【0158】
実施形態では、サービス業として飲食業であるレストランの配達を、電動車両２００を利用して行う例により説明するが、サービス業がこれに限定されるものではなく、サービス業には小売業、宅配業、観光業、金融・保険業、観光業、宿泊施設提供業、医療・福祉業なども含まれる。例えば、宅配業であれば、電動車両２００を利用して図書や新聞の配達を行う、というサービスを提供することができる。当該図書が、市町村が管理する図書館に帰属するような場合には、電動車両２００は行政サービスに関連して利用されるものともなり得る。
【0159】
また、例えば、電動車両２００を利用してゴミの回収や移送を行えば、これには清掃業に関連したサービスの対価が発生する。また、電動車両２００を利用して見回りなどを行えば、これには警備業に関連したサービスの対価が発生する。
【0160】
また、電動車両２００の利用に伴いユーザーが、サービスを受けることがあるが、このような受けたサービスに対する費用についても、電動車両２００のシェアの費用と共に、ユーザーデータベース１１０における各ユーザーの口座データで総合的に決済する。例えば、ユーザーは、ホテルに宿泊して、さらに電動車両２００を使って周辺の観光を行う、というシチュエーションがあり得る。このようなケースでは、宿泊施設提供業や観光業に関連した費用が、電動車両２００のシェアの費用と共に決済される。
【0161】
また、電動車両２００を使って病院に行き治療を受ければ、その治療代も、電動車両２００のシェアの費用と共に決済することができる。この場合、サービスは医療・福祉業に属するものとのある。
【0162】
以上のように、電動車両２００は様々のサービス業と関連して利用され得るので、電動車両２００のシェアのための費用と、それに関連したサービスの提供で発生する対価、或いは、電動車両２００のシェアに伴い受けたサービスに対する費用などを、各ユーザーの口座データで総合的に決済する。
【0163】
以下、図１１を参照して、ユーザーが、リロケーターと同時にランナーとなる場合に基づいて説明する。図１１に示すユーザーＣは、●○レストランで飲食物をピックアップして、乗り捨て車両Ｂで配達先に飲食物を配達し、その後、駐車スペースＡに乗り捨て車両Ｂを戻すとすると、このユーザーは「リロケーター兼ランナー」である。
【0164】
図２３は、サービス業者データベース１４０のデータ構造の一例を示すものである。サーバー１００には、これまで説明したデータベースに加え、サービス業者データベース１４０が記憶される。サービス業者データベース１４０の一つのデータセットには、サービス業者の名称である「サービス業者名」に係るデータ、サービス業者毎で固有の「サービス業者 ＩＤ」に係るデータ、サービス業者の所在に係る「サービス業者位置データ」、そのサービス業者が現在ランナーを募集しているか否かに係る「ランナー募集データ」、現在ランナーを募集している場合には、ランナーが配達する予定の住所に係る「配達先位置データ」を含めることができる。なお、これらのデータの中で、「ランナー募集データ」と「配達先位置データ」は、一つのサービス業者に対応して複数存在することがある。
【0165】
次に、どのような条件で、リロケート兼配達案件が選定されるかについて、図２４を参照して説明する。図２４は本発明の実施形態に係る電動車両管理システム１におけるリロケート兼配達案件選定処理のフローチャートを示す図である。
【0166】
図２４において、ステップＳ１４００で、リロケート兼配達案件選定処理が開始されると、続く、ステップＳ１４０１においては、リロケート先として判定された駐車スペースの駐車スペース位置データを駐車スペースデータベース１３０から取得する。ここで、リロケート先の駐車スペースを判定する処理については、先に説明したものが用いられる。
【0167】
続く、ステップＳ１４０２においては、サービス業者データベース１４０から配達先位置データを取得する。ステップＳ１４０３では、駐車スペース位置データと、配達先位置データとの間の距離が所定距離以下の組み合わせを選定し、リロケート兼配達案件とし、ステップＳ１４０４でリロケート兼配達案件選定処理を終了する。
【0168】
さて、以上のような処理でリロケート兼配達案件されると、続いては、「リロケーター兼ランナー」の候補となり得るユーザーを選定する処理が実行される。
【0169】
図２５は本発明の実施形態に係る電動車両管理システム１におけるリロケーター兼ランナー候補ユーザー選定処理のフローチャートを示す図である。
【0170】
図２５において、ステップＳ１５００で、リロケーター兼ランナー候補ユーザー選定処理が開始されると、続いて、ステップＳ１５０１に進み、要リロケートと判定された車両の車両位置データを車両データベース１２０から取得する。ここで、車両のリロケートの要否の判定はは、先に説明した処理を用いることができる。
【0171】
ステップＳ１５０２では、リロケーター・ランナー希望有りがアカウント情報として登録されているユーザーのユーザー位置データをユーザーデータベース１１０から取得する。
【0172】
ステップＳ１５０３では、リロケーター・ランナー希望有りがアカウント情報として登録されているユーザーのユーザー位置データをユーザーデータベース１１０から取得する。
【0173】
ステップＳ１５０４では、ユーザー位置データは、車両位置データから所定範囲内であるか否かについて判定する。ステップＳ１５０４の判定結果がＮＯであれば、ステップＳ１５０７に進み処理は終了となる。 一方、ステップＳ１５０４の判定結果がＹＥＳであれば、ステップステップＳ１５０５に進む。
【0174】
ステップＳ１５０５では、ユーザー位置データは、サービス業者位置データから所定範囲内であるか否かについて判定する。ステップＳ１５０５の判定結果がＮＯであれば、ステップＳ１５０７に進み処理は終了となる。 一方、ステップＳ１５０５の判定結果がＹＥＳであれば、ステップステップＳ１５０６に進む。
【0175】
ステップＳ１５０６では、当該ユーザーをリロケーター兼ランナー候補として選定し、ステップＳ１５０７に進み、リロケーター兼ランナー候補ユーザー選定処理を終了する。
【0176】
リロケーター兼ランナー候補ユーザーには、例えば、図２６に示すようなプッシュ通知がなされる。（プッシュ通知については、これまで説明した処理と同様に考えることができる。）
図２６は上記のようなプッシュ通知を受信したユーザーのスマートフォン１０のタッチパネル部３０における画面表示例を示す図である。このようなプッシュ通知では、例えば、「○□町四丁目の乗り捨て車両で、デリバリーとリロケートをこなして、リワードを獲得しませんか？
・ピックアップ ●○レストラン
・リロケート先 △コンビニエンスストア
リロケート：５００ポイント
デリバリー：５００ポイント
トータルで１０００ポイントを獲得できます。」などのメッセージが表示される。
図２６は上記のようなプッシュ通知を受信したユーザーのスマートフォン１０のタッチパネル部３０における画面表示例を示す図である。このようなプッシュ通知では、例えば、「○□町四丁目の乗り捨て車両で、デリバリーとリロケートをこなして、リワードを獲得しませんか？
・ピックアップ ●○レストラン
・リロケート先 △コンビニエンスストア
リロケート：５００ポイント
デリバリー：５００ポイント
トータルで１０００ポイントを獲得できます。」などのメッセージが表示される。
【0177】
このようなメッセージを受けて、リロケーター兼ランナーの作業を受諾したユーザーＣは、図１１に示すように、まず、乗り捨て車両Ｂのロックを解錠した上で、●○レストランで飲食物をピックアップし、まず、配達先に飲食物を配達する。続いて、乗り捨て車両Ｂを駐車スペースＡに移動し、リロケートを完了する。これらの作業に付随するサーバー１００との間の処理は、基本的に、これまで説明したものと同様のものを用いることができるが、一方、決済の処理については、電動車両２００のリロケートと、電動車両２００を利用して提供したサービス（デリバリーのサービス）の２つの報酬・リワードが発生するので、これらを勘案する必要がある。
【0178】
以下、上記のような決済の処理をより一般的にした処理について説明する。図２７は本発明の実施形態に係る電動車両管理システム１における口座データ決済処理のフローチャートを示す図である。
【0179】
図２７において、ステップＳ１６００で口座データ決済処理が開始されると、続いて、ステップＳ１６０１において、電動車両２００のシェアによる費用が発生した場合、その費用（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（電動車両費用算出部）として動作する。（実施例では、この処理による算出値は０ポイント）
次に、ステップＳ１６０２においては、電動車両２００の利用と共に、サービスによって対価が発生した場合、その対価（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（サービス対価算出部）として動作する。（実施例では、デリバリーの対価である５００ポイント）
次に、ステップＳ１６０３においては、電動車両２００の利用と共に、サービスを受けて費用が発生した場合、その費用（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（サービス費用算出部）として動作する。（実施例では、この処理による算出値は０ポイント）
次に、ステップＳ１６０４においては、電動車両２００のリロケートによって対価が発生した場合、その対価（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（リロケート対価算出部）として動作する。（実施例では、リロケートの対価である５００ポイント）
次に、ステップＳ１６０５においては、以上の各ステップで算出された費用、対価の全てを併せて決済を行い（実施例では、１０００ポイント）、ステップＳ１６０６で口座データ決済処理を終了する。
次に、ステップＳ１６０２においては、電動車両２００の利用と共に、サービスによって対価が発生した場合、その対価（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（サービス対価算出部）として動作する。（実施例では、デリバリーの対価である５００ポイント）
次に、ステップＳ１６０３においては、電動車両２００の利用と共に、サービスを受けて費用が発生した場合、その費用（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（サービス費用算出部）として動作する。（実施例では、この処理による算出値は０ポイント）
次に、ステップＳ１６０４においては、電動車両２００のリロケートによって対価が発生した場合、その対価（価値交換媒体の値）を算出する。このような処理が実行され電動車両管理システム１が（リロケート対価算出部）として動作する。（実施例では、リロケートの対価である５００ポイント）
次に、ステップＳ１６０５においては、以上の各ステップで算出された費用、対価の全てを併せて決済を行い（実施例では、１０００ポイント）、ステップＳ１６０６で口座データ決済処理を終了する。
【0180】
図２８は上記のような決済処理の報告を受信したユーザーのスマートフォン１０のタッチパネル部３０における画面表示例を示す図である。このような報告の通知では、例えば、リロケート（５００ｐｔｓ）＆デリバリー（５００ｐｔｓ）の総計の１０００ｐｔｓを、ユーザーの口座に計上した旨のメッセージが表示される。
【0181】
以上、本発明に係る電動車両管理システム１は、電動車両２００をシェアしたユーザーに対する費用と、電動車両２００を利用してユーザーによって提供されたサービスに対する対価と、電動車両２００の利用に伴いユーザーが受けたサービスに対する費用とを併せて決裁する決裁部を有しているので、このような本発明に係る電動車両管理システム１によれば、交通のための決済に限定されることなく、サービス業も含めた幅広い決済に用いることが可能となり、ユーザーの利便性が向上する。
【符号の説明】
【0182】
１・・・電動車両管理システム
１０・・・スマートフォン（情報処理端末装置）
１１・・・制御部
１５・・・記憶部
２０・・・通信部
２３・・・ＧＰＳ信号受信部（全地球測位システム信号受信部の一例）
２５・・・撮像部
３０・・・タッチパネル部
３１・・・入力部
３２・・・表示部
４０・・・メニュー
４１・・・検索キーワード入力欄
４２・・・バナー広告
５０・・・アイコン
１００・・・サーバー
１１０・・・ユーザーＤＢ（データベース）
１２０・・・車両ＤＢ（データベース）
１３０・・・駐車スペースＤＢ（データベース）
１４０・・・サービス業者ＤＢ（データベース）
２００・・・電動車両
２０１・・・車体フレーム
２０３・・・前輪
２０４・・・後輪
２０５・・・ステム
２０６・・・ハンドル
２０７・・・前照灯
２０８・・・ディスプレイ
２０９・・・シート
２１０・・・カウル
２１１・・・車両番号
２１２・・・ＱＲコード（登録商標）
２１３・・・バッテリー
２１５・・・グリップ
２１６・・・ブレーキレバー
２１７・・・支軸
２１８・・・ブレーキワイヤ
２１９・・・ドラム
２２０・・・カム
２２２・・・ブレーキシュー
２２３・・・支軸
２２４・・・ライニング（摩擦材）
２２５・・・スプリング
２２６・・・ブレーキ制御部
２３０・・・車両制御部
２３１・・・モーター
２３３・・・アクセルグリップセンサ
２５０・・・管理制御部
２５１・・・無線通信部
２５２・・・ＧＰＳ信号受信部（全地球測位システム信号受信部の一例）
２５３・・・近接無線通信部
２５５・・・残量データ取得部
２５６・・・スピーカー制御部
２５７・・・スピーカー
１０・・・スマートフォン（情報処理端末装置）
１１・・・制御部
１５・・・記憶部
２０・・・通信部
２３・・・ＧＰＳ信号受信部（全地球測位システム信号受信部の一例）
２５・・・撮像部
３０・・・タッチパネル部
３１・・・入力部
３２・・・表示部
４０・・・メニュー
４１・・・検索キーワード入力欄
４２・・・バナー広告
５０・・・アイコン
１００・・・サーバー
１１０・・・ユーザーＤＢ（データベース）
１２０・・・車両ＤＢ（データベース）
１３０・・・駐車スペースＤＢ（データベース）
１４０・・・サービス業者ＤＢ（データベース）
２００・・・電動車両
２０１・・・車体フレーム
２０３・・・前輪
２０４・・・後輪
２０５・・・ステム
２０６・・・ハンドル
２０７・・・前照灯
２０８・・・ディスプレイ
２０９・・・シート
２１０・・・カウル
２１１・・・車両番号
２１２・・・ＱＲコード（登録商標）
２１３・・・バッテリー
２１５・・・グリップ
２１６・・・ブレーキレバー
２１７・・・支軸
２１８・・・ブレーキワイヤ
２１９・・・ドラム
２２０・・・カム
２２２・・・ブレーキシュー
２２３・・・支軸
２２４・・・ライニング（摩擦材）
２２５・・・スプリング
２２６・・・ブレーキ制御部
２３０・・・車両制御部
２３１・・・モーター
２３３・・・アクセルグリップセンサ
２５０・・・管理制御部
２５１・・・無線通信部
２５２・・・ＧＰＳ信号受信部（全地球測位システム信号受信部の一例）
２５３・・・近接無線通信部
２５５・・・残量データ取得部
２５６・・・スピーカー制御部
２５７・・・スピーカー
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】