(57)【要約】      （修正有）【課題】車両の画像を容易に撮影できる撮影方法を提供する。【解決手段】車両の撮影方法は、撮影対象とする車両の選択を受け付けるステップと、車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された車両の撮影を補助するためのガイド線を抽出するステップと、撮影装置１のモニタに表示されるライブビュー画像に、ガイド線を重畳表示するステップと、ユーザからの指示を受けて、車両の撮影を行うステップと、を含む。【選択図】図４
2020194481.tif 000002
【特許請求の範囲】
【請求項１】
車両の撮影方法であって、
撮影対象とする車両（３）の選択を受け付けるステップと、
車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された前記車両に関連付けられたガイド線を抽出するステップと、
撮影装置（１）のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、
ユーザからの指示を受けて前記車両の撮影を行うステップと、
を含む車両の撮影方法。
【請求項２】
請求項１記載の車両の撮影方法であって、
前記ガイド線は、前記車両の輪郭と、前記車両の外部から観取できる部品の輪郭のうちいずれか一方または両方により構成される、
車両の撮影方法。
【請求項３】
請求項１または２記載の車両の撮影方法であって、
ユーザが撮影した画像が前記車両のガイド線に沿っているかを確認するステップと、
前記ガイド線に沿った撮影がなされているかを通知するステップとをさらに備える、
車両の撮影方法。
【請求項４】
請求項１から３のうちいずれか１項記載の車両の撮影方法であって、
予定された全撮影方向のうちの各方向について、撮影装置１には少なくとも前記ガイド線か過去画像のうちのいずれかまたは両方がサムネイル表示されており、
ユーザがサムネイルのうちの１つを選択すると、そのサムネイルに表示された特定の撮影方向からの撮影を補助するガイド線を表示する、
車両の撮影方法。
【請求項５】
ユーザが請求項１ないし３のうちいずれか１項に記載の車両の撮影方法を用いて車両を撮影するステップと、
前記ユーザが撮影した前記車両の画像から損傷部分を検出するステップと、
記憶部から車両の過去の撮影画像を読み出すステップと、
前記過去の撮影画像とユーザが撮影した画像とを比較して、前記車両に新たな損傷部分がないかを検出するステップと、
前記車両の画像において過去の損傷部分をマーカで示すと共に、前記新たな損傷部分が検出された場合には、前記新たな損傷部分を、過去の損傷部分とは異なるマーカで示すステップと、
を備える車両の点検支援方法。
【請求項６】
ユーザに車両を貸し出すステップと、
ユーザが車両を返却する際に、車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された前記車両に関連付けられたガイド線を抽出するステップと、
撮影装置のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、
ユーザが撮影した画像が前記車両のガイド線に沿っているかを確認するステップと、
ユーザが撮影した画像がガイド線に沿って正しく撮影されている場合に、車両の返却を受け付けるステップと、
を備える車両の貸出方法。
【請求項７】
請求項６記載の車両の貸出方法であって、
ユーザに車両を貸し出す際に、車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された前記車両に関連付けられたガイド線を抽出するステップと、
撮影装置のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、
ユーザが撮影した画像が前記車両のガイド線に沿っているかを確認するステップと、
ユーザが撮影した画像がガイド線に沿って正しく撮影をした場合に、車両の貸出しを受け付けるステップと、
を備える車両の貸出方法。
【請求項８】
請求項６または７記載の車両の貸出方法であって、
ユーザが撮影した前記車両の画像と、前記画像の撮影時に保存された位置情報及び時間情報とを関連付けてサーバ（２）に保存するステップをさらに含む、
車両の貸出方法。
【請求項９】
物品の撮影方法であって、
撮影対象とする物品の選択を受け付けるステップと、
物品の撮影を補助するためのガイド線を物品に関連付けて保持するデータベースから、選択された前記物品に関連付けられたガイド線を抽出するステップと、
撮影装置（１）のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、
ユーザからの指示を受けて前記物品の撮影を行うステップと、
を含む物品の撮影方法。
【請求項１０】
コンピュータに、
撮影対象とする車両（３）の選択を受け付けるステップと、
車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された前記車両に関連付けられたガイド線を抽出するステップと、
撮影装置（１）のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、
ユーザからの指示を受けて前記車両の撮影を行うステップと、
を実行させる車両の撮影プログラム。
【請求項１１】
データベースを有する記憶部と、
電磁的な通信を行う通信部と、
画像処理を行う制御部と、
を備え、
前記記憶部の前記データベースには、車両の車種および年式と、それに対応する車両の撮影を補助するためのガイド線が保存されており、
前記通信部は、前記ガイド線を電磁的に提供して撮影された画像データを受信し、
前記制御部は、前記撮影された画像データから、前記所定の物体が前記ガイド線に沿って撮影されているか否かを判断する、
車両管理サーバ（２）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両の撮影方法、車両の点検支援方法、車両の貸出方法、車両撮影プログラムおよび車両管理サーバに関する。
【背景技術】
【０００２】
情報通信技術の発達により、個人が保有する遊休資産やスキルの貸し借りを仲介するサービスが発達している。また、レンタカーのように企業の保有動産を個人が借り受ける業態においても、カーシェアリングのように貸し借りに係員の立ち合いがない、安価なサービスが生まれてきている。
【０００３】
特許文献１では、顧客に対する貸与条件や傷や汚れの確認を、書面を自動発行してユーザにチェックさせることで行い、チェックを認識して車両の鍵を自動貸出して、返却時間に応じて精算する、車両貸出システムが提案されている。これにより、車両の無人貸出が実現できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−１３０５１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
カーシェアリングサービスにおいて車両は貸出中に損傷することがあるが、自走可能であればそのまま返却できる。また、ユーザは必ずしも車両の損傷を申告するとは限らない。上記文献記載の方法では、書面に記載されていない車両の傷についてはユーザが判断することなく貸出が行われる。すなわち、複数のユーザが車両を利用し、誰からも申告がないにもかかわらず車両に損傷が見つかった場合、車両を損傷させたユーザを特定できないので、損傷の修復費用は運営会社が負担することになる。
【課題を解決するための手段】
【０００６】
本発明は上記課題を解決するために以下の技術的手段を採用する。特許請求の範囲及びこの項に記載した括弧内の符号は、ひとつの態様として後述する実施の形態に記載の具体的手段との対応関係を示す一例であって、本発明の技術的範囲を限定するものではない。
【０００７】
本発明に係る車両の撮影方法は、撮影対象とする車両（３）の選択を受け付けるステップと、車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された前記車両に関連付けられたガイド線を抽出するステップと、撮影装置（１）のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、ユーザからの指示を受けて前記車両の撮影を行うステップとを含む。
【０００８】
この方法により、ライブビュー画像に表示されるガイド線に沿って車両を撮影することを促すことで、同じ方向から撮影した車両の画像が得られる。
【０００９】
また、本発明に係る車両の撮影プログラムは、コンピュータに、撮影対象とする車両（３）の選択を受け付けるステップと、車両の撮影を補助するためのガイド線を車両に関連付けて保持するデータベースから、選択された前記車両に関連付けられたガイド線を抽出するステップと、撮影装置（１）のモニタに表示されるライブビュー画像に、前記ガイド線を重畳表示するステップと、ユーザからの指示を受けて前記車両の撮影を行うステップとを実行させる。
【００１０】
本発明に係る車両管理サーバ（２）は、データベースを有する記憶部と、電磁的な通信を行う通信部と、画像処理を行う制御部とを備え、前記記憶部の前記データベースには、車両の車種および年式と、それに対応する車両の撮影を補助するためのガイド線が保存されており、前記通信部は、前記ガイド線を電磁的に提供して撮影された画像データを受信し、前記制御部は、前記撮影された画像データから、前記所定の物体が前記ガイド線に沿って撮影されている否かを判断する。
【発明の効果】
【００１１】
本発明によれば、ライブビュー画像に表示されるガイド線に沿って車両を撮影することを促すことで、同じ方向から撮影した車両の画像が得られる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態であるカーシェアリングシステムのブロック図である。
【図２】車種テーブルの例を示す図である。
【図３】ライブビュー画面に重畳表示されるガイド線を示した図である。
【図４】撮影処理のフロー図である。
【図５】各車両テーブルの例を示す図である。
【図６】使用履歴テーブルの例を示す図である。
【図７】車両予約時のアプリケーション動作画面を示す図である。
【図８】アプリケーションの貸出画面・返却画面を示した図である。
【図９】貸出処理のフロー図である。
【図１０】返却処理のフロー図である。
【発明を実施するための形態】
【００１３】
以下、添付図面を参照しながら本実施形態について説明する。なお、以下に説明する実施の形態は、本発明を実施する場合の一例を示すものであって、本発明を以下に説明する具体的構成に限定するものではない。本発明の実施にあたっては、実施の形態に応じた具体的構成が適宜採用されてよい。
【００１４】
図１は、本発明の実施形態であるカーシェアリングシステムのブロック図である。
本実施形態のカーシェアリングシステム１００は、ユーザが保有する携帯端末１と、カーシェアリングシステム運営者が管理するサーバ２と、車両３と、貸出・返却端末４とを備える。
【００１５】
携帯端末１は、ユーザが携帯可能な情報端末であり、一例としてはユーザが所有するスマートフォンであって、特許請求の範囲の記載における撮影装置を含む。携帯端末１は、制御部１１と、記憶部１２と、カメラ１３と、表示部１４と、通信部１５と、位置センサ１６を備える。制御部１１は、携帯端末１を制御する機能を有する。記憶部１２は、携帯端末１の動作に必要なプログラムやデータを格納する記憶装置であり、一般的には半導体メモリが用いられるが、磁気記憶装置等であってもよい。また、起動中のプログラムは図示しない揮発性メモリである一時記憶装置上で動作する。
【００１６】
カメラ１３は、携帯端末１に内蔵されており、主として可視光により周囲の情報を記録するセンサである。表示部１４は、ユーザに対して通知を行う画面であり、タッチパネルである場合には操作部を兼ねる。なお、携帯端末１に別途図示しない操作部が備えられていてもよい。通信部１５は、携帯通信網や無線ＬＡＮなどに接続して他の機器とネットワーク通信を行う機能を備える。位置センサ１６は、携帯端末１の位置を検出するセンサである。位置センサ１６はＧＰＳセンサである。また無線ＬＡＮの電波などから端末の位置を推定するものであってもよい。
【００１７】
携帯端末１の記憶部１２には、アプリケーション１２１が記憶されている。本実施形態では、アプリケーション１２１は、一例としては、携帯端末１のオペレーティングシステムを提供する企業が運営するアプリケーションマーケットを経由して、カーシェアリングサービス事業者により携帯端末１に配布される。なお、携帯端末１のブラウザ上で動作するＷｅｂアプリケーションにより同様のサービスを提供する形態としてもよい。アプリケーション１２１は、携帯端末１の通信部を制御してサーバ２と通信を行う機能を有している。
【００１８】
サーバ２は、カーシェアリングサービス事業者が設置するサーバであって、携帯端末１と通信を行ってカーシェアリングサービスを実現する。サーバ２は、実体としてデータセンタに配置されていてもよいし、クラウドサービス上に仮想的に構築されていてもよい。
【００１９】
サーバ２は、制御部２１と、通信部２２と、記憶部２３を備える。制御部２１は、サーバ２の機能を統括し、携帯端末１との通信結果と記憶部２３上の情報から、ユーザに対してカーシェアリングサービスの提供可否を決定する。通信部２２は、ネットワークを経由して、携帯端末１との通信を行う。記憶部２３には、カーシェアリングサービスを実現するためのデータベースが構築されている。
【００２０】
図２は、記憶部２３に記憶されたデータベースの一つである車種テーブルの例を示す図である。車種テーブルＴ１には、グレードと車種と年式の情報が保存されている。車種と年式によって車両（の外形）が特定される。グレードは車種に対応する情報である。車種テーブルＴ１には、車種と年式に対応して、車体を右前、左前、右後ろ、左後ろから斜めに撮影するための計４種類の標準的なガイド線が保存されている。
【００２１】
図３は、アプリケーション上で表示されるガイド線を示した図である。ガイド線は、ガイド線を車両の輪郭または車両の外部から看守される部品の輪郭に合わせて車両を撮影することで、車体をくまなくカメラに収めることができるように作成された線である。例えば、図３では車両３の輪郭とヘッドライトの輪郭とを含んでガイド線が構成されている。このガイド線の情報は、車両を貸与するに際してユーザの携帯端末１に送信される情報である。ガイド線は、ユーザによる所定角度からの車両撮影を補助するために、カメラを使用中の携帯端末１のライブビュー画像に重畳表示される。このように、車両３の輪郭と特徴的部分を含むガイド線を重畳表示することにより、ユーザはより簡単に適切な方向から車両３を撮影することができる。また、同じ方向から撮影した画像が得られるので、サーバ２側での画像解析も容易になる。
【００２２】
車両３は、カーシェアリングサービスにおいてユーザに貸出される車両である。車両３の車種や登録番号、状態はサーバ２のデータベースで管理されている。貸出・返却端末４は、車両の保管場所付近に設置される端末であって、サーバ２の制御を受けて車両３の貸出・返却についての書面処理や車両の貸出・返却を管理する。なお、アプリケーション１２１に契約機能を設け、車両３にサーバ２との通信機能を搭載することにより、本端末が不要な形態とすることもできる。
【００２３】
図４は、撮影処理のフロー図である。
サーバ２の制御部は、データベースの車種テーブルＴ１から、車種及び年式に対応するガイド線を読み出して、携帯端末１に送信し（Ｓ１０１）、携帯端末１は当該情報を受信する。携帯端末の画面には撮影方向選択画面が表示され、ユーザはこれから撮影する撮影方向を決定する（Ｓ１０２）。ユーザが撮影方向を選択すると、カメラモードが起動して、ライブビュー画像にガイド線が重畳表示されるので、ユーザはなるべくガイド線に合うように車両３を撮影する（Ｓ１０３）。撮影した方向と画像は、サーバ２に送信される。サーバ２は、送られてきた画像について画像解析を行う（Ｓ１０４）。サーバ２は、当該画像がガイド線に従って正しい方向から車両を撮影したものか否かを判定し、条件を満たしていない場合には、携帯端末１に再撮影指示を送信する（Ｓ１０５でＮＯ）。条件を満たしている場合（Ｓ１０５でＹＥＳ）、その方向から撮影した画像を受理したことを携帯端末１に通知して（Ｓ１０７）、その画像を記憶部２３に備えられたデータベースに使用履歴データとして保存する（Ｓ１０９）。
【００２４】
携帯端末１が再撮影指示を受信した場合（Ｓ１０６でＹＥＳ）、携帯端末１の画面上には再撮影が必要な旨が表示され、ユーザは再度同一方向からガイド線に沿って撮影を行う（Ｓ１０６）。携帯端末１が再撮影指示を受信せず（Ｓ１０６でＮＯ）、代わりに受理通知を受信した場合には、その方向からの撮影は終了し、まだ予め定められた全てのガイド線に沿って撮影が完了していなければ（Ｓ１０８でＮＯ）、ユーザはまだ撮影していない撮影方向を選択して、同様に撮影を行う。全ての撮影方向からの撮影が完了したら（Ｓ１０８でＹＥＳ）、撮影プロセスは終了する（ＥＮＤ）。
【００２５】
この撮影方法を用いて、カーシェアリングサービスを実現するために、一例として更に図５、図６に示すテーブルが用意される。
【００２６】
図５は、各車両テーブルの例を示す表である。
各車両テーブルＴ２は、カーシェアリングサービスが管理している実際の車両それぞれに管理番号を付して管理するテーブルである。各車両テーブルＴ２には車両ごとの整備状況・予約状況が格納される。また、サービス投入時・または最終修理点検時に事業者により撮影された車両の４方向からのマスタ画像も格納されている。
【００２７】
図６は、使用履歴テーブルの例を示す表である。
使用履歴テーブルＴ３は、各車両テーブルＴ２で管理番号を付された各車両の使用履歴を管理するテーブルである。使用履歴テーブルＴ３は、その車両を使用した顧客コード、現在のステータス（貸出・返却）、そのステータスが発生した時刻、各ステータス発生時にユーザが撮影した各方向からの画像データを保持する。そしてそれらの各画像データに、画像解析により新たな損傷が発見された場合、その損傷情報が格納される。なお使用履歴テーブルＴ３にはメンテナンス時に撮影された画像が記録されていてもよい。
【００２８】
図７は、車両予約時のアプリケーション１２１の動作画面を示す図である。
アプリケーション１２１はカーシェアリングサービスを利用するための会員情報を保持しており、使用申込の際に会員情報をサーバ２に提供する。ユーザはアプリケーション１２１上で、使用地域やクラスの大まかな検索を行い、候補提示された具体的な車両と保管場所の中から、貸出を申し込みたい車両と保管場所とを選択するが、アプリケーション１２１はその間サーバ２と通信を行い、サーバ２は、車種テーブルおよび各車両テーブルＴ２を参照し、条件に適合する具体的な車両候補を携帯端末１に都度送信する。携帯端末１が受信した候補車両の情報は、アプリケーション１２１に表示されて、ユーザは候補となる車両のスペックや点検履歴を閲覧できる。候補車両のうちの特定の車両を選択した際には、右画面が表示され、ユーザは車両のより詳細な情報を確認できる。このようにしてユーザは、借りたい車両を事前に選択して予約を行い、予約が成立したら指定時間に車両保管場所に行く。サーバ２は、予約が成立したら、各車両テーブルＴ２の内容を更新する。
【００２９】
図８は、車両貸出時と車両返却時のアプリケーション１２１の画面を表す。
ユーザが車両保管場所に到着し、車両３の貸出の申込を行うと、アプリケーション１２１はサーバ２から車両３に関連するデータの提供を受けて、ユーザに提示する。車両画像は、通常は直近にその車両を利用した別のユーザが撮影した画像であるが、点検直後やサービス投入直後である場合には、サービス提供事業者側が撮影した画像である場合もある。提示画面は例えば図８左側になる。当該画面には、車両保管場所や利用時間、車種や登録番号などの他、車両３を両ヘッドライト側・両テールランプ側から斜めに撮影した、合計４枚の画像がサムネイル表示されている。既に車両に損傷がある場合、その損傷の位置はマーカで強調表示される。図８の例では、破線で囲まれた左上の画像に、既に損傷があることが表示されている。ユーザは、情報を確認し、問題がなければ次の手続きに進む。なお、ユーザは車両保管場所に到着する前に予めこれらの情報をダウンロードして、事前に確認を済ませておいてもよい。
【００３０】
ユーザは、車両３の利用を開始する際、サーバ２からダウンロードした車両のガイド線に沿って、携帯端末１のカメラを用いて４方向から車両３を撮影することを求められる。ユーザが図８左図の特定の方向からの過去画像のサムネイルのうちの１つを選択すると、その方向を指定したガイド線がカメラのライブビュー画像に重畳表示されるので、ユーザはガイド線に従って撮影を行う。
【００３１】
撮影の基本的な流れは、図４のフローで説明した通りである。なお、画像がガイド線に適合しているかどうかは、サーバ２に送信する前にアプリケーション１２１自体が画像処理により判断してもよい。これにより携帯端末１とサーバ２との通信回数を減らすことができる。
【００３２】
アプリケーション１２１は、携帯端末１のカメラ機能のライブビュー画像を監視し、ライブビュー画像に表示される車両３が、サーバ２が処理を行える程度にガイド線に適合したときにガイド線の色を変化させたり、携帯端末１から通知音を発生させたりしてユーザに撮影を促してもよい。また、アプリケーション１２１はライブビュー映像に表示される車両３がガイド線に重なったタイミングで自動的に撮影を行ってもよい。
【００３３】
サーバ２は、画像処理により、車体についた新たな損傷を検出して、その位置と内容を損傷情報としてデータベースの使用履歴テーブルＴ３に仮に格納する。なお、サーバ２は損傷と汚れを分けて判定してもよい。なお、アプリケーション１２１によって撮影されて、サーバ２に送信される画像データのメタデータには、位置センサ１６が取得している撮影場所に関する情報と、撮影時刻に関する情報が含まれている。これらの情報も、車体の損傷情報と関連付けられてサーバ２のデータベースの使用履歴テーブルＴ３に仮に格納される。
【００３４】
特定方向からの撮影が終わり、サーバにより画像が受理されると、当該サムネイルに表示されている特定の撮影方向からの過去画像が、ユーザが撮影した画像に変化する。ユーザは、全てのサムネイルが自分の撮影した画像に切り替わるまで、撮影操作を行う。このようにしてユーザは、直感的に全ての方向からの撮影操作を行っていくことができる。なお、本実施形態ではサムネイルには過去画像が表示されているが、初期状態ではガイド線のみからなるサムネイルを表示することとしてもよい。
【００３５】
４方向からの正しい撮影データがサーバに送られ、ユーザによる車内確認の結果問題がなければ、ユーザはアプリケーション１２１上で貸出リクエスト操作を実行可能になる。貸出リクエストがあると、サーバ２から指示を受けた貸出・返却端末４により、またはサーバ２が車両３に直接解錠指示を送信することにより車両が解錠されて、ユーザは車両３を利用可能になる。車両が解錠されると、サーバ２はデータベースの使用履歴テーブルＴ３における車両３のステータスを貸出中とし、ステータス発生時刻を解錠が行われた時刻とし、仮に格納されたデータを新しいレコードとして確定させる。なお、ユーザが使用中の車両３の施錠・解錠は、専用の会員カードで行われてもよいし、アプリケーション１２１と車両３との通信により行われてもよい。
【００３６】
ユーザが車両３を返却する際も、ガイド線に沿って４方向から車両３を撮影することが求められる。各画像の具体的な撮影手順は車両貸出時と同様である。サーバ２はデータベースの使用履歴テーブルＴ３に仮に新しいレコードを作成して画像を保存しながら、車両貸出時に撮影された画像と、返却時に撮影された画像とを、画像処理により比較する。比較の結果問題がなければ、サーバ２から指示を受けた貸出・返却端末４により、またはサーバ２が車両３に直接施錠指示を送信することにより車両が施錠されて利用終了となり、利用時間に応じた精算処理が行われる。このように、ユーザは車両貸出時と車両返却時の２回撮影を行うので、もしその間に車両３に損傷が発生していれば、当該ユーザによる使用中に損傷が発生したことが明確になる。
【００３７】
サーバ２が画像処理によりユーザが申告していない汚損を発見した場合、サーバ２は携帯端末１に対して画像処理結果と損傷の疑いがある旨の信号を送信する。アプリケーション１２１には汚損が疑われる画像と疑わしい部分を抽出してマーカで示した警告画面が表示され、返却受付ができなくなる。図８右図で言うと、左下の一点鎖線表示部分である。汚損が単なる汚れであれば、ユーザは汚れを取り除いて再度撮影データを送信することができ、問題が解決されれば確認は終了する。
【００３８】
返却処理が完了し車両が施錠されたら、サーバ２の制御部はデータベースの使用履歴テーブルＴ３における車両３のステータスを返却済みとし、ステータス発生時刻を施錠が行われた時刻とし、仮に格納されたデータを新しいレコードとして確定させる。この段階で車両使用時間も、貸出時と返却時のステータス発生時間の差分として確定するので、必要に応じて精算が可能である。精算が完了したら、サーバ２の制御部はデータベースの各車両テーブルＴ２の予約状況を更新する。
【００３９】
ユーザが使用中に車両を損傷させた場合、ユーザはその場で公的機関やオペレータに連絡をして事故処理を行うのが原則である。もしユーザが事故処理を行わず、返却時に画像のいずれかに損傷が見つかった場合には、ユーザは適切な事故処理を行うまで返却を認められない。これにより、ユーザから確実にノンオペレーションチャージ等の手数料を請求することができるし、カーシェアリング業者からの保険会社への保険金請求も容易になる。アプリケーション１２１で撮影される画像のメタデータには撮影場所や撮影時間が記録され、これらもサーバ２に保存されるので、車両を損傷させたユーザが画像を改竄して、あたかも借りる前から車体に損傷があったかのように装うことや、まだ損傷が映っていない古い画像を送信して返却を試みるなどの不正行為を防ぐことができる。
【００４０】
図９は、貸出処理のフロー図である。
カーシェアリングサービスを利用する際、ユーザは、携帯端末１上のアプリケーション１２１を使用して条件を入力し、サーバ２に対して、利用できる車両の一覧を要求する（Ｓ２０１）。要求には、車のクラスや使用予定時間が含まれる。サーバ２は、データベースから、ユーザから指定された条件に適合する車両３を検索し、候補となる車両３の情報を、携帯端末１に対して送信する（Ｓ２０２）。車両３の情報には、車両スペック・検査履歴などが含まれる。ユーザが要求する場合、サーバ２は当該車両の更に別の情報を送信してもよい。ユーザは、これらの情報を参照し、気に入らない場合には、別の車両はないか問い合わせることができる。ユーザは、借りたい車両３が決定した場合、車両利用申込をする（Ｓ２０３）。この車両利用申込プロセスが、特許請求の範囲記載の車両の選択を受け付けるステップに該当する。予約時間になったら、ユーザは車両保管場所に向かう。
【００４１】
ユーザが車両３を借りるために車両保管場所に到着した際、サーバ２は携帯端末１に対して更に詳細な情報を送信する（Ｓ２０４）。送信される情報には、契約条項や撮影ガイド枠・四方からの過去画像・傷履歴などが含まれ、既に存在する車両の損傷も、マーカにより明瞭に表示されている。なお、ユーザが車両保管場所に到着する前に、事前にこれらの情報の提供を受けて確認をしておくこともできる。これらの情報についてユーザが承諾をすると（Ｓ２０５）、ユーザによる撮影手続きに進む。
【００４２】
撮影手続きでは、ユーザは携帯端末１上のアプリケーション１２１を使用して、４方向から車両の撮影を行う。予めサーバ２からガイド線が送信されているので、これに従って順次撮影を行う（Ｓ２０６）。具体的な撮影処理の流れは図４のフローで説明した通りである。
【００４３】
サーバ２は、車両３に既についている傷を解析して（Ｓ２０７）、画像をデータベースに登録し、点検結果を更新し、携帯端末１に送信する（Ｓ２０８）。アプリケーション１２１上では、撮影した画像に登録済みの損傷が重畳表示され、ユーザが確認することができる。この処理は、ユーザが車両３を撮影し、各面からの画像がサーバ２に送信され、サーバ２の結果登録が、全４面について完了するまで継続する（Ｓ２１０でＮＯ）。
【００４４】
最終的に４方向からの画像の撮影と送信が終了し、ユーザが解析された車両３の損傷を承諾したら（Ｓ２１０でＹＥＳ）、ユーザはアプリケーション１２１で解錠リクエストを行う（Ｓ２１１）。解錠リクエストを受けたサーバ２は、解錠処理を行う（Ｓ２１２）。これにより、ユーザは車両３の利用を開始する（Ｓ２１３）。
【００４５】
図１０は、返却処理のフロー図である。
ユーザは車両３を所定の返却場所に駐車させ、携帯端末１のアプリケーション１２１上で返却申込を行う（Ｓ３０１）。
【００４６】
ユーザは、車両３を借りるときと同様に、アプリケーション１２１に表示されるガイド線に合わせて、車両３を４方向から撮影する（Ｓ３０２）。この際、アプリケーション１２１によって表示される過去画像は、ユーザが車両を借りる際に自ら撮影した画像なので、携帯端末１に残っていれば、これをそのまま表示することとしてよい。また、ガイド線についても、ユーザが車両を借りる際に既に取得したものをそのまま利用することができる。勿論、これらのデータが既に携帯端末１に残っていない場合には、サーバ２から再度受信することとしてもよい。
【００４７】
撮影されたデータは貸出処理と同様にサーバ２に送信され、サーバ２は画像解析を行う（Ｓ３０３）。サーバ２が、画像解析の結果、貸出処理時よりも損傷疑いの箇所が増加していると判定した場合、携帯端末１に対して、損傷が疑われる部位と、画像を受理できないため再撮影が必要である旨の情報を送信する（Ｓ３０４でＹＥＳ）。アプリケーション１２１には、画像のどこに損傷が疑われるのかがマーカを付して視覚的に表示される（Ｓ３０５）。
【００４８】
ユーザがもし本当に車両を損傷させていた場合、フローには示していないが、ユーザはオペレータや公的機関に報告を行うなどの必要な処理をしなければならない。損傷疑いの箇所が単なる照明の写り込みや汚れであって問題ないものであればユーザは必要な処置をした後、再度ガイド枠に合わせて同じ方向から撮影を行ってサーバ２に画像データを再送信することができる（Ｓ３０５でＹＥＳ）。サーバ２は再撮影された画像データを解析し（Ｓ３０３）、問題が解消されていれば（Ｓ３０４でＮＯ）点検結果として受理し、受理したことを携帯端末１に送信する（Ｓ３０６）。また、画像解析の結果そもそも傷が検出されなかったため再撮影指示がなかった場合（Ｓ３０４でＮＯおよび、Ｓ３０５でＮＯ）も、同様である。この処理は、ユーザが車両３を撮影し、各面からの画像がサーバ２に送信され、サーバ２の結果登録が、全４面について完了するまで継続する（Ｓ３０８でＮＯ）。
【００４９】
最終的に４枚の画像の撮影と送信が終了し、サーバが全ての画像を受理した場合（Ｓ３０８でＹＥＳ）、ユーザはアプリケーション１２１上で点検完了の登録を行う（Ｓ３０９）。当該登録はサーバ２に送信され、サーバ２は車両３の施錠処理を行う（Ｓ３１０）。これにより、ユーザの車両利用は終了し（Ｓ３１１）、実利用時間に応じた精算が行われる（Ｓ３１２）。
【００５０】
アプリケーション１２１、サーバ２の画像解析アルゴリズムは既知のものを用いることができる。また、アプリケーション１２１は被写体がガイド枠に合っているか否かを判断できれば良いので、簡易なアルゴリズムを使用してよい。本実施の形態では、車両３が利用・返却される毎にサーバ２に画像が蓄積されるので、人工知能を併用して、解析精度を向上させていくことができる。例えば、アルゴリズムが一旦損傷と判断したものが、ユーザの処理により再撮影時に消えた場合、それは単なる汚れであったと言える。そのようなものは次回からは損傷とは扱わずに、再撮影を要求する対象から外すことができる。
【００５１】
本実施形態では、ユーザは車両を利用開始する際と返却する際に必ず４方向から車両の画像を撮影し、画像はサーバ２によって解析される。また、画像には、画像を撮影した際に同時に保存される位置情報と時刻情報がメタデータ（例えば、Ｅｘｉｆデータ）として付加されているため、偽装は困難である。毎回スタッフによる確認を受けなくても、車両を誰が傷付けたのかを判断でき、その場で損傷に応じた手数料を的確に請求できる。よって、複数のユーザが利用した後、車両に誰からも申告のない損傷が発見され、サービス運営者が不当な損失を被ることがない。
【００５２】
本実施形態では、車両３が利用される毎に、貸出時・返却時の４方向からの画像の他、ユーザの属性や、車両に損傷が発生した時刻、場所、損傷個所、損傷種別などの多くのデータがサーバ２に集積される。この情報は、自動車保険会社や修理工場に提供され、迅速な保険処理や修理の効率化にも寄与する。このデータを使用して、サービスの画像処理精度向上に役立てることができるのは勿論、自動車保険会社はこのデータを保険商品開発に役立てることができる。また、修理工場は、損傷が発生しやすい箇所の部品を予め準備しておくことができる。更に、車両メーカーは、このデータにより損傷発生状況を把握できるので、例えばパーツを変更したり運転支援を充実させることにより、より損傷が発生しにくい車両開発をすることができる。
【００５３】
以上、具体例を参照しつつ本実施形態について説明した。しかし、本開示はこれらの具体例に限定されるものではない。これらの具体例に、当業者が適宜設計変更を加えたものも、本開示の特徴を備えている限り、本開示の範囲に包含される。前述した本具体例が備える各要素およびその配置、条件、形状などは、例示したものに限定されるわけではなく適宜変更することができる。前述した各具体例が備える各要素は、技術的な矛盾が生じない限り、適宜組み合わせを変えることができる。
【００５４】
本実施形態ではユーザが車両を借りる際４方向からの画像撮影を必須としたが、ユーザが携帯装置１で閲覧した過去画像と実車を目視で比較して新たな傷がないと認める場合には、ユーザの責任において貸出時の４方向からの撮影を省略可能としてもよい。これにより、ユーザは撮影手続を行うことなくすぐに車両３の貸出を受けることができる。
【００５５】
また、本実施形態では、車両３に対応するガイド線はサーバ２のデータベースに格納されていたが、ガイド線は車種と年式の数だけあればよいため、予めアプリケーション１２１の記憶領域に構成されるデータベースに格納しておき、使用の際に指定の車種・年式に対応したガイド線を呼び出すこととしてもよい。
【００５６】
更に、本実施形態では取り扱うのは４方向からの画像としたが、保管場所に制約があって、撮影に十分なスペースが取れない場合には、画像撮影方向は必ずしも４方向に限定されない。保管場所の制約に合わせ、車両の外観について判断可能な必要十分な画像を取得できる数の、その車両特有のガイド線を生成してサーバ２のデータベース上に登録し、利用を申請したユーザに対して撮影を要求してもよい。保管場所に特有の効率的な撮影方向がある場合には、その方向から撮影した車両の輪郭を、その車両独自のガイド線として採用してもよい。
【００５７】
加えて、貸し出されるものは、車両以外の物であってもよい。ネットワーク経由で、スタッフを介さず個人の遊休資産を貸し借り可能なサービスは多い。その際遊休資産等が損傷し、借り主から申告がないために誰が損傷させたのか明確でない場合、結局貸主が損失を被らざるを得ず、サービスの利便性が損なわれることがあるのは上記実施形態と同様だからである。
【００５８】
例えば、本方法を民泊に適用すれば、サーバは室内用のガイド線を保持し、ゲストは入室の際と退去の際にガイド線に沿って室内の画像を撮影してサーバに送信する。このようにすれば、退去時にホストによる確認を要さずとも、ゲストが発生させた施設の汚損はシステムにより認識できるので、補償が必要になる場合も的確に請求することができる。また、装飾・バック類のレンタルについても、この手法を使用することで、損傷の責任所在を明確にできる。
【００５９】
上記実施形態では、汚損が発見された場合サーバは再撮影を要求したが、貸し出されるものによっては、汚れであっても損傷としてよいものもある。そのようなものについては、即座に損傷として取り扱ってよい。また、貸し出されるものが車両であって、汚損が単なる汚れであると断定できる場合でも、洗車措置または手数料をユーザに要求することとしてもよい。
【符号の説明】
【００６０】
１：携帯端末、２：サーバ、３：車両、４：貸出・返却端末
【図１】
2020194481.tif 000003
【図２】
2020194481.tif 000004
【図３】
2020194481.tif 000005
【図４】
2020194481.tif 000006
【図５】
2020194481.tif 000007
【図６】
2020194481.tif 000008
【図７】
2020194481.tif 000009
【図８】
2020194481.tif 000010
【図９】
2020194481.tif 000011
【図１０】
2020194481.tif 000012