JP2024059807A - 電気自動車に対する契約証明書の設置支援方法及び装置 - Google Patents

Abstract

【課題】電気自動車がローミング環境にあっても契約証明書の設置やアップデートが可能なようにすることで、ＰｎＣ方式の充電のための承認を正確かつ迅速に行う方法及び装置を提供する。【解決手段】充電サービス提供装置（ＣＳＰ）での実行に適する契約証明書の設置支援方法であって、ＥＶに対する契約証明書を生成するステップと、契約証明書をローミング契約が形成されている訪問ＣＳＰに伝送して、契約証明書がローミング状況で訪問ＣＳＰを介してＥＶに設置されるようにするステップと、を含む。ローミング状況におけるＥＶ証明書の設置要請やアップデート要請に備えて、ホームＣＳＰは、ＥＶに対する契約証明書をローミング契約関係にある全てのＣＳＰに事前に配布することで、ＥＶがローミング環境で証明書の設置要請やアップデート要請を行うときに直ちに設置できるようにする。【選択図】図１３

Description

本発明は、電気自動車の充電方法及びこのための装置に関する。特に、本発明は、ＰｎＣ（Ｐｌｕｇ－ａｎｄ－Ｃｈａｒｇｅ）方式の充電基盤構造でローミング環境に対応できるように電気自動車に公開鍵証明書を設置する方法及び装置に関する。

電気自動車（ＥＶ：Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ、「電気車」と略される場合もある）は、バッテリーの動力でモータを駆動して運行し、従来のガソリンエンジン自動車に比べて排気ガス及び騒音などのような大気汚染源が少なく、故障が少なく、寿命が長く、運転操作が簡単であるという長所がある。電気自動車充電システムは、商用電力配電網（ｐｏｗｅｒ ｇｒｉｄ）やエネルギー貯蔵装置の電力を用いて電気自動車に搭載されたバッテリーを充電するシステムと定義される。このような電気自動車充電システムは多様な形態で具現でき、例えば、ケーブルを用いた導電性充電システムや非接触方式のワイヤレス電力伝送システムを含んでもよい。

充電ステーションは、ＥＶに対して一定の承認過程を経た後に充電を開始するようになり、承認過程は充電基盤構造とＥＶの機能によって異なる。電気自動車充電に関する国際標準の１つであるＩＳＯ １５１１８－１は、２つの承認方法、すなわち、ＥＶに格納されている契約証明書を用いて承認と決済が自動で完了するＰｎＣ方式と、クレジットカード、デビットカード、現金、スマートフォンアプリのような外部識別手段（ＥＩＭ：Ｅｘｔｅｒｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｅａｎｓ）によって識別、承認、料金決済が行われる方式を規定している。ＰｎＣ方式とは、有線充電の場合は、ＥＶと充電ステーションとの間にプラグを差し込むだけでサービスの承認と充電が行われるプラグアンドチャージ（Ｐｌｕｇ－ａｎｄ－ｃｈａｒｇｅ）方式を指し、ワイヤレス充電の場合、充電ステーションの充電スポット上に駐車するだけでサービスの承認と充電が行われるパークアンドチャージ（Ｐａｒｋ－ａｎｄ－ｃｈａｒｇｅ）方式を指す。

ＥＶがＰｎＣサービスを利用するためには、ＥＶの所有者がＭＯ（Ｍｏｂｉｌｉｔｙ Ｏｐｅｒａｔｏｒ）とサービス利用契約を締結しなければならない。契約締結後は、最初の充電時にＥＶに契約証明書が設置され、その後は該当ＭＯに関連する充電ステーションでＰｎＣサービスを受けることができる。もし、ＥＶが契約関係のないＭＯに関連する充電ステーションでＰｎＣサービスを受けようとする場合、ローミングが発生する。ＥＶに有効な契約証明書が既に設置されていれば、ローミング環境でもＥＶの所有者は充電サービスの利用に大きな困難はない。

しかし、充電ステーションを訪問したＥＶに有効な契約証明書がない場合、ＰｎＣが作動しないこともある。このような状況は、例えばＥＶの出荷後に訪問した最初の充電ステーションがＥＶと契約関係のないＭＯのネットワークに属する充電ステーションである場合に発生し得る。また、ＥＶに設置された契約証明書が何らかの事情によって有効に動作しない場合は、契約証明書がアップデートされなければならないが、このようにアップデートが必要な状況でも上記のようにＰｎＣが作動しないことがある。このようにローミング環境で契約証明書の設置やアップデートが必要な状況が発生し得るが、従来はこれに対する対策が設けられていないと言える。よって、このようにＰｎＣが作動しない場合は、外部識別手段（ＥＩＭ）によって料金を決済しなければならず、ＥＶの運転手に不便さをもたらす。

一方、従来のＰｎＣによると、ＥＶが充電ステーションを介して充電ステーション運営者（ＣＳＯ：Ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ ｏｐｅｒａｔｏｒ）に提出した契約証明書チェーンをＣＳＯ又は充電サービス提供者（ＣＳＰ：Ｃｈａｒｇｅ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）が検証する。ところが、ＥＶには、契約証明書チェーンの最上位証明書であるＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）が設置されていないため（ＩＳＯ １５１１８－２０標準２０１８．７．２．基準）、ＥＶはローミング状況で訪問ＣＳＯに提出することができない。この場合、訪問ＣＳＯや訪問ＣＳＰもこのルート証明書を備えていないと、検証はホームＣＳＰ又は別途のクリアリングハウスでのみ可能であるため、承認遅延を引き起こす可能性がある。

本発明は、電気自動車がローミング環境にあっても契約証明書の設置やアップデートが可能なようにし、ＰｎＣ方式の充電のための承認が正確かつ迅速に行われるようにする方法と装置を提供する。

本発明の一側面によると、充電サービス提供装置（ＣＳＰ）における契約証明書の設置支援方法が提供される。
本発明の一態様による充電サービス提供装置における契約証明書の設置支援方法は、第１電気自動車（ＥＶ）に対する第１契約証明書を生成するステップと、前記第１契約証明書をローミング契約が形成されている第１外部充電サービス提供装置（ＣＳＰ）に伝送して、前記第１契約証明書がローミング状況で前記第１外部ＣＳＰを介して前記第１ＥＶに設置できるようにするステップ、を含むことを特徴とする。

前記第１外部ＣＳＰは、前記充電サービス提供装置とローミング契約が成立している全ての外部ＣＳＰを含んでもよい。

前記第１外部ＣＳＰは、全ての外部ＣＳＰを含んでもよい。

前記契約証明書の設置支援方法は、前記第１契約証明書を前記第１外部ＣＳＰに伝送してから所定の期間が経過するか、又は前記第１契約証明書が前記第１ＥＶに設置されると、前記第１外部ＣＳＰに設置待機解除要請を送信するステップをさらに含んでもよい。

前記第１契約証明書を前記第１外部ＣＳＰに伝送するステップは、前記第１契約証明書を含む契約証明書チェーンと、ｅＭＡＩＤ情報を含む証明書設置パッケージを形成するステップと、前記証明書設置パッケージを前記第１外部ＣＳＰに伝送するステップと、を含んでもよい。

前記証明書設置パッケージは、前記第１契約証明書に関連する証明書廃棄リストと、オンライン証明書状態プロトコル（ＯＣＳＰ）サーバの接続情報を含んでもよい。

前記契約証明書の設置支援方法は、第２ＥＶに対する第２契約証明書を第２外部ＣＳＰから受け入れ、証明書プロビジョニングサービス装置（ＣＰＳ）に伝達して格納させるステップと、前記第２ＥＶがサービスネットワークに進入したローミング状況で、前記第２ＥＶから契約証明書の設置要請が受信されると、前記ＣＰＳに格納された前記第２契約証明書が前記第２ＥＶに送信されるようにして前記第２ＥＶに設置されるようにするステップと、をさらに含んでもよい。

前記第２外部ＣＳＰは、前記充電サービス提供装置と前記ローミング契約が成立している全ての外部ＣＳＰのうちのいずれか１つであってもよい。

前記第２契約証明書が前記第２ＥＶに送信されるようにして前記第２ＥＶに設置されるようにするステップは、前記第２契約証明書が前記第２ＥＶに設置された後に、前記第２外部ＣＳＰに設置完了を通知するステップをさらに含んでもよい。

本発明の他の側面によると、ＰｎＣ方式による充電サービスに活用できる充電サービス提供装置が提供される。
本発明の一態様による充電サービス提供装置は、プロセッサと、前記プロセッサによって実行される少なくとも１つの命令を格納するメモリと、を含み、前記少なくとも１つの命令は、第１電気自動車（ＥＶ）に対する第１契約証明書を生成し、前記第１契約証明書を第１外部充電サービス提供装置（ＣＳＰ）に伝送して、前記第１外部ＣＳＰを介して前記第１契約証明書が前記第１ＥＶに設置されるようにする命令と、第２ＥＶに対する第２契約証明書を第２外部ＣＳＰから受け入れ、証明書プロビジョニングサービス装置（ＣＰＳ）に伝達して格納させるようにする命令と、前記第２ＥＶがサービスネットワークに進入したローミング状況で、前記第２ＥＶから契約証明書の設置要請が受信されると、前記ＣＰＳに格納された前記第２契約証明書が前記第２ＥＶに送信されるようにして前記第２ＥＶに設置されるようにする命令と、を含むことを特徴とする。

前記第１外部ＣＳＰは、前記充電サービス提供装置とローミング契約が成立している全ての外部ＣＳＰを含み、前記第２外部ＣＳＰは、前記充電サービス提供装置とローミング契約が成立している前記全ての外部ＣＳＰのうちのいずれか１つであってもよい。

前記第１外部ＣＳＰは、全ての外部ＣＳＰを含み、前記第２外部ＣＳＰが前記全ての外部ＣＳＰのうちのいずれか１つであってもよい。

前記第１契約証明書を前記第１外部ＣＳＰに伝送する命令は、前記第１契約証明書を前記第１外部ＣＳＰに伝送してから所定の期間が経過するか、又は前記第１契約証明書が前記第１ＥＶに設置されると、前記第１外部ＣＳＰに設置待機解除要請を送信する命令をさらに含んでもよい。

前記第２契約証明書が前記第２ＥＶに送信されるようにして前記第２ＥＶに設置されるようにする命令は、前記第２契約証明書が前記第２ＥＶに設置された後に、前記第２外部ＣＳＰに設置完了を通知する命令を含んでもよい。

前記第１契約証明書を前記第１外部ＣＳＰに伝送するステップは、前記第１契約証明書を含む契約証明書チェーンと、ｅＭＡＩＤ情報を含む証明書設置パッケージを形成するステップと、前記証明書設置パッケージを前記第１外部ＣＳＰに伝送するステップと、を含んでもよい。

前記証明書設置パッケージは、前記第１契約証明書に関連する証明書廃棄リストと、オンライン証明書状態プロトコル（ＯＣＳＰ）サーバの接続情報を含んでもよい。

本発明のまた他の側面によると、ローミング環境におけるＰｎＣ方式のＥＶ充電承認方法が提供される。
本発明の一態様によるローミング環境におけるＰｎＣ方式のＥＶ充電承認方法は、第１電気自動車（ＥＶ）に対する第１契約証明書を生成し、前記第１契約証明書を第１外部充電サービス提供装置（ＣＳＰ）に伝送して、前記第１外部ＣＳＰを介して前記第１契約証明書が前記第１ＥＶに設置できるようにするステップと、第２ＥＶに対する第２契約証明書を第２外部ＣＳＰから受け入れ、証明書プロビジョニングサービス装置（ＣＰＳ）に伝達して格納させるステップと、前記第２ＥＶがサービスネットワークに進入したローミング状況で、前記第２ＥＶから契約証明書の設置要請が受信されると、前記ＣＰＳに格納された前記第２契約証明書が前記第２ＥＶに送信されるようにして前記第２ＥＶに設置されるようにし、前記第２ＥＶが充電承認要請を行うと、前記第２ＥＶに前記第２契約証明書が設置された状態に基づいて承認を行うステップと、を含むことを特徴とする。

前記第２外部ＣＳＰは、前記充電サービス提供装置とローミング契約が成立している全ての外部ＣＳＰのうちのいずれか１つであってもよい。

前記第２契約証明書が前記第２ＥＶに送信されるようにして前記第２ＥＶに設置されるようにするステップは、前記第２契約証明書が前記第２ＥＶに設置された後に、前記第２外部ＣＳＰに設置完了を通知する命令を含んでもよい。

前記第２契約証明書を前記第２外部ＣＳＰから受け入れて格納するステップは、前記第２契約証明書を含む契約証明書チェーンとｅＭＡＩＤ情報を含む証明書設置パッケージを受け入れて格納するステップを含んでもよい。

本発明によれば、ＥＶ証明書の設置要請やアップデート要請に備えて、ホーム充電サービス提供者（ＣＳＰ）がＥＶに対する契約証明書を実質的に全てのＣＳＰに事前に配布することで、ＥＶがローミング環境で証明書の設置要請やアップデート要請を行っても、直ちに訪問ＣＳＰが契約証明書をＥＶに提供して設置できるようにする。よって、ローミング環境下でもＥＶに契約証明書チェーンの設置やアップデートが可能になり、ＥＶのＰｎＣ方式による充電が円滑になり、ＥＶ利用者の便宜性を向上させることができる。

また、契約証明書以外にも多様な証明書が訪問ＣＳＰ、訪問ＣＳＯ、及びこれらに関連するＣＳに設置され得るため、各エンティティの対応能力が向上し、電気自動車に対する承認過程に融通性が与えられるようになる。

本発明の一実施形態を適用できる電気自動車の有線充電方法を説明するための概念図である。 本発明の一実施形態を適用できる電気自動車に対するワイヤレス電力伝送を説明するための概念図である。 本発明の一実施形態によるＥＶ充電基盤構造のブロック図である。 本発明の一実施形態に適用される証明書の階層構造の一例を示す図である。 ＥＶに対するローミングサービスを説明するためにＰｎＣ充電基盤構造を構成するノードを例示的に示す図である。 ローミングが必要でない状況と必要な状況の例を示す図である。 ローミングが必要でない状況での契約による一般的なサービスの承認過程を示すフローチャートである。 直接ローミングが行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。 間接ローミングが行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。 即席直接ローミング（ｏｎ－ｔｈｅ－ｆｌｙ ｄｉｒｅｃｔ ｒｏａｍｉｎｇ）が行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。 即席間接ローミング（ｏｎ－ｔｈｅ－ｆｌｙ ｉｎｄｉｒｅｃｔ ｒｏａｍｉｎｇ）が行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。 本発明の一実施形態においてホームＣＳＰから直接ローミングを通じてＥＶに伝達して設置される契約証明書の伝達経路を示す図である。 図１２に示された証明書の伝達過程をより詳しく示すフローチャートである。 本発明の一実施形態において、ホームＣＳＰから間接ローミングを通じてＥＶに伝達して設置される契約証明書の伝達経路を示す図である。 図１４に示された証明書の伝達過程をより詳しく示すフローチャートである。 本発明の他の実施形態において、契約によるサービスの承認過程を示すフローチャートである。 本発明の一実施形態によるＣＳＰのブロック図である。

本発明は多様な変更を加えることができ、様々な実施形態を有することができるため、特定の実施形態を図面に例示して発明の詳細な説明で詳しく説明する。しかし、これは、本発明を特定の実施形態に限定するものでなく、本発明の思想及び技術範囲に含まれるあらゆる変更、均等物ないし代替物を含むものと理解されるべきである。各図面を説明するにあたって類似の参照符号を類似の構成要素に対して用いた。

第１、第２、Ａ、Ｂなどの用語は多様な構成要素の説明に使用されるが、各構成要素はこれらの用語によって限定されない。上記用語は、ある構成要素を他の構成要素から区別する目的だけで使用される。例えば、本発明の技術範囲を逸脱することなく、第１構成要素は第２構成要素として命名されることができ、同様に、第２構成要素も第１構成要素として命名されることができる。「及び／又は」という用語は、複数の関連した記載項目の組み合わせ又は複数の関連した記載項目のいずれかの項目を含む。

ある構成要素が他の構成要素に「連結されて」いるか、「接続されて」いると記載されたときには、他の構成要素に直接的に連結されているか又は接続されているが、中間に他の構成要素が存在し得る。一方、ある構成要素が他の構成要素に「直接連結されて」いるか「直接接続されて」いると記載されたときには、中間に他の構成要素が存在しない。

本明細書で使用された用語は、単に特定の実施形態を説明するために使用されたものであって、本発明を限定しようとする意図ではない。単数の表現は、文脈上明白に異なって意味しない限り、複数の表現を含む。本明細書で、「含む」又は「有する」などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品又はこれらを組み合わせたものが存在することを指定しようとするものであって、１つ又はそれ以上の他の特徴や数字、段階、動作、構成要素、部品又はこれらを組み合わせたものなどの存在又は付加可能性をあらかじめ排除しない。

異なって定義されない限り、技術的又は科学的な用語を含んで本明細書で使用される全ての用語は、本発明が属する技術分野における通常の知識を有する者によって一般的に理解されるものと同一の意味を有している。一般的に使用される辞書に定義されているような用語は、関連技術の文脈上有する意味と一致する意味を有するものと解釈され、本明細書で明白に定義しない限り、理想的や過度に形式的な意味として解釈されない。

本明細書で使用される一部の用語を定義すると下記のとおりである。

「電気自動車（Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ、ＥＶ）」は、４９ ＣＦＲ（ｃｏｄｅ ｏｆ ｆｅｄｅｒａｌ ｒｅｇｕｌａｔｉｏｎｓ）５２３．３などで定義された自動車（ａｕｔｏｍｏｂｉｌｅ）を指す。電気自動車は、高速道路を利用可能であり、車両外部の電源供給源から再充電可能なバッテリーなどの車両搭載エネルギー貯蔵装置から供給される電気によって駆動される。電源供給源は、住居地や共用電気サービス又は車両搭載燃料を用いる発電機などを含んでもよい。電気自動車（ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ、ＥＶ）は、エレクトリックカー（ｅｌｅｃｔｒｉｃ ｃａｒ）、エレクトリックオートモバイル（ｅｌｅｃｔｒｉｃ ａｕｔｏｍｏｂｉｌｅ）、ＥＲＶ（ｅｌｅｃｔｒｉｃ ｒｏａｄ ｖｅｈｉｃｌｅ）、ＰＶ（ｐｌｕｇ－ｉｎ ｖｅｈｉｃｌｅ）、ｘＥＶ（ｐｌｕｇ－ｉｎ ｖｅｈｉｃｌｅ）などと称され、ｘＥＶは、ＢＥＶ（ｐｌｕｇ－ｉｎ ａｌｌ－ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ、又はｂａｔｔｅｒｙ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ）、ＰＥＶ（ｐｌｕｇ－ｉｎ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ）、ＨＥＶ（ｈｙｂｒｉｄ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ）、ＨＰＥＶ（ｈｙｂｒｉｄ ｐｌｕｇ－ｉｎ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ）、ＰＨＥＶ（ｐｌｕｇ－ｉｎ ｈｙｂｒｉｄ ｅｌｅｃｔｒｉｃ ｖｅｈｉｃｌｅ）などと呼称又は区分される。

「プラグイン電気自動車（Ｐｌｕｇ－ｉｎ Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ、ＰＥＶ）」は、電力グリッドに連結して車両搭載一次バッテリーを再充電する電気自動車を指す。

「ワイヤレス充電システム（ＷＣＳ：Ｗｉｒｅｌｅｓｓ ｐｏｗｅｒ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ）」は、ワイヤレス電力伝送とアラインメント及び通信を含むＧＡとＶＡとの間の制御のためのシステムを指す。

「ワイヤレス電力伝送（Ｗｉｒｅｌｅｓｓ ｐｏｗｅｒ ｔｒａｎｓｆｅｒ、ＷＰＴ）」は、ユーティリティ（Ｕｔｉｌｉｔｙ）やグリッド（Ｇｒｉｄ）などの交流（ＡＣ）電源供給ネットワークから電気自動車に、非接触手段により電気的な電力を伝送することを指す。

「ユーティリティ（Ｕｔｉｌｉｔｙ）」は、電気的なエネルギーを提供し、通常、顧客情報システム（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ、ＣＩＳ）、双方向検針インフラ（Ａｄｖａｎｃｅｄ Ｍｅｔｅｒｉｎｇ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、ＡＭＩ）、料金と収益（Ｒａｔｅｓ ａｎｄ Ｒｅｖｅｎｕｅ）システムなどを含むシステムの集合と称される。ユーティリティは価格表又は離散イベント（ｄｉｓｃｒｅｔｅ ｅｖｅｎｔｓ）を通じてプラグイン電気自動車がエネルギーを利用できるようにする。また、ユーティリティは、関税率、計測電力消費に対するインターバル及びプラグイン電気自動車に対する電気自動車プログラムの検証などに関する情報を提供する。

「スマート充電（Ｓｍａｒｔ ｃｈａｒｇｉｎｇ）」は、電力グリッドと通信しながらＥＶＳＥ及び／又はプラグイン電気自動車が車両の充電率又は放電率をグリッド容量又は使用コストの比率の時間に応じて最適化するシステムを指す。

「相互運用性（Ｉｎｔｅｒｏｐｅｒａｂｉｌｔｙ）」は、互いに相対的なシステムの成分が全体システムの目的とする動作を行うために共に作動可能な状態を指す。情報相互運用性（Ｉｎｆｏｒｍａｔｉｏｎ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）は、２つ以上のネットワーク、システム、デバイス、アプリケーション又は成分を、ユーザがほとんど又は全く不便なく安全かつ効果的に情報を共有して容易に使用可能な能力を指す。

「誘導充電システム（Ｉｎｄｕｃｔｉｖｅ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ）」は、２つのパートが緩く結合されたトランスフォーマーを通じて、電気供給ネットワークから電気自動車に正方向で電磁的にエネルギーを伝送するシステムを指す。本実施形態で誘導充電システムは、電気自動車充電システムに対応する。

「誘導結合（Ｉｎｄｕｃｔｉｖｅ ｃｏｕｐｌｉｎｇ）」は、２つのコイル間の磁気結合を指す。２つのコイルは、グラウンドアセンブリコイル（Ｇｒｏｕｎｄ ａｓｓｅｍｂｌｙ ｃｏｉｌ）と車両アセンブリコイル（Ｖｅｈｉｃｌｅ ａｓｓｅｍｂｌｙ ｃｏｉｌ）を指す。

「ＯＥＭ（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ）」は、電気自動車メーカーが運営するサーバであり、ＯＥＭルート証明書を発行する最上位証明機関（ＣＡ）を指す。

「モビリティ運営者（ＭＯ：Ｍｏｂｉｌｉｔｙ ｏｐｅｒａｔｏｒ）」は、ＥＶの運転手が充電ステーションでＥＶを充電できるようにＥＶの所有者と充電、承認、及び決済に関する契約関係を結んでいるサービス提供者を指す。

「充電ステーション（ＣＳ：Ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ）」は、１つ以上のＥＶ電力供給装置を備え、ＥＶに対する充電を実際に行う施設を指す。

「充電ステーション運営者（ＣＳＯ：Ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ ｏｐｅｒａｔｏｒ）」は、要請されたエネルギー伝送サービスを提供するために電気を管理するエンティティを指し、充電ポイント運営者（ＣＰＯ：Ｃｈａｒｇｅ ｐｏｉｎｔ ｏｐｅｒａｔｏｒ）と同一の概念の用語である。

「充電サービス提供者（ＣＳＰ：Ｃｈａｒｇｅ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）」は、ＥＶユーザのクレデンシャルを管理及び認証し、料金請求及びその他付加価置サービスを顧客に提供する役割をするエンティティを指し、ＭＯの特別なタイプに該当すると見られ、ＭＯと統合された形態で具現されてもよい。

「クリアリングハウス（ＣＨ：Ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）」は、ＭＯ、ＣＳＰ、及びＣＳＯの間の協力事項を処理するエンティティであり、特に２つの精算ないし精算当事者の間でＥＶ充電サービスローミングに対する承認、料金請求、精算手続きを円滑にさせる中間関与者の役割をしてもよい。

「ローミング（ｒｏａｍｉｎｇ）」は、ＥＶのユーザが１つのクレデンシャルと契約を用いることで、複数のモビリティネットワークに属する複数のＣＳＰ又はＣＳＯによって提供される充電サービスにアクセスできるようにする情報交換及び関連事項（ｐｒｏｖｉｓｉｏｎ）と体系（ｓｃｈｅｍｅ）を指す。

「クレデンシャル（ｃｒｅｄｅｎｔｉａｌ）」は、ＥＶ又はＥＶの所有者の個人情報を表す物理的又はデジタル資産であり、身元を検証するために用いる暗号学的情報であるパスワード、公開鍵暗号アルゴリズムで用いる公開鍵／個人鍵のペア、証明機関が発行する公開鍵証明書、信頼するルート証明機関に関する情報などを含んでもよい。

「証明書（Ｃｅｒｔｉｆｉｃａｔｅ）」は、デジタル署名によって公開鍵をＩＤとバインディングする電子文書を指す。

「サービスセッション」は、固有の識別子を有する一定のタイムフレームにおける、ある顧客に割り当てられた、充電地点における電気自動車充電に関するサービスの集合を指す。

「電子モビリティアカウント識別子（ｅＭＡＩＤ：ｅ－Ｍｏｂｉｌｉｔｙ Ａｃｃｏｕｎｔ Ｉｄｅｎｔｉｆｉｅｒ）」は、契約証明書をＥＶの所有者の決済アカウントに連結させるＥＶの固有識別子を指す。

以下、本発明の好ましい実施形態を図面を参照しながら詳しく説明する。

本発明を具現するための電気自動車充電システムにおいて、電気自動車（ＥＶ）は、充電ステーションに有線又は無線リンクを介して接続されて充電ステーションからエネルギーを供給され、供給されたエネルギーで、例えばバッテリーのようなエネルギー貯蔵装置を充電させる。図１及び図２は、有線と無線で電気自動車を充電する方法をそれぞれ示す。

図１は、本発明の一実施形態を適用できる電気自動車の有線充電方法を説明するための概念図である。電気自動車の有線充電は、電気自動車（１０、以下「ＥＶ」と称する）を充電ケーブル（３０）によって充電ステーションの電力供給回路に接続すること、例えば、充電ステーション（２０）のケーブルコネクタをＥＶ（１０）のジャックに接続することで行われる。

ここで、ＥＶ（１０）は、バッテリーのような充電可能なエネルギー貯蔵装置から供給される電力を、動力装置である電気モータのエネルギー源として供給する車両（ａｕｔｏｍｏｂｉｌｅ）と定義される。ＥＶ（１０）は、電気モータと一般的な内燃機関を共に有するハイブリッド自動車であってもよく、自動車（ａｕｔｏｍｏｂｉｌｅ）だけでなく、モータサイクル（ｍｏｔｏｃｙｃｌｅ）、カート（ｃａｒｔ）、スクータ（ｓｃｏｏｔｅｒ）、及び電気自転車（ｅｌｅｃｔｒｉｃ ｂｉｃｙｃｌｅ）であってもよい。

ＥＶ（１０）は、充電ケーブル（３０）のコネクタに接続されるプラグ接続口又はレセプタクルを含む。ＥＶ（１０）に備えられるプラグ接続口は、緩速充電を支援しても急速充電を支援してもよい。このとき、ＥＶ（１０）は、１つのプラグ接続口を介して緩速充電と急速充電を全て支援してもよく、それぞれが緩速充電と急速充電を支援する複数のプラグ接続口を含んでもよい。

本発明によるＥＶ（１０）は、緩速充電又は一般的な電力系統から供給される交流電力による充電を支援するために、オンボード充電器（Ｏｎ Ｂｏａｒｄ Ｃｈａｒｇｅｒ）を含んでもよい。オンボード充電器は、緩速充電時に外部から有線で供給される交流電力を昇圧し、直流電力に変換してＥＶ（１０）に内蔵されたバッテリーに供給する。一方、プラグ接続口に急速充電のための直流電力が供給される場合は、直流電力がオンボード充電器を経ることなくバッテリーに供給されて充電することができる。

一方、ＥＶ充電ケーブル（３０）は、充電コネクタ（３１）、コンセントソケット接続部（３３）、及びインケーブルコントロールボックス（ＩＣＣＢ；Ｉｎ－ｃａｂｌｅ ｃｏｎｔｒｏｌ ｂｏｘ）（３２）のうちの少なくとも１つを含んで構成される。充電コネクタ（３１）は、ＥＶ（１０）と電気的に連結される接続部であり、インケーブルコントロールボックス（３２）は、ＥＶ（１０）と通信してＥＶの状態情報を受信するか、又はＥＶ（１０）への電力充電を制御する。インケーブルコントロールボックス（３２）は、ＥＶ充電ケーブル（１０）に含まれるように示したが、ＥＶ充電ケーブル（１０）以外の位置、例えば、充電ステーションでＥＶ（１０）に電力を供給する電力供給回路（図示せず）に接続されるか、又は電力供給回路内に配置されてもよい。コンセントソケット接続部（３３）は、一般的なプラグやコードセットなどの電気接続機構として充電ステーションの充電装置に接続される。

一方、電力ソケット（４０）は、充電ステーションの充電装置と充電コネクタ（３１）との接続地点を意味する。ただし、本発明はこれに限定されるものではなく、電力ソケット（４０）がその他の位置に設置された充電装置と充電コネクタ（３１）との間の接続地点を意味してもよい。例えば、電力ソケット（４０）は、商業的な専門充電ステーション施設以外に、ＥＶ（１０）の所有者の自宅に付属する駐車場、ガソリンスタンドでＥＶの充電のために割り当てられた駐車区域、ショッピングセンターや職場の駐車区域などのような充電施設物に設置されたウォールジャック（ｗａｌｌ ｊａｃｋ）を意味する。

図２は、本発明の一実施形態を適用できる電気自動車に対するワイヤレス電力伝送を説明するための概念図である。

ＥＶに対するワイヤレス電力伝送（ＷＰＴ：ｗｉｒｅｌｅｓｓ ｐｏｗｅｒ ｔｒａｎｓｆｅｒ）は、供給ネットワークからの電気エネルギーを、ガルバニック接続を通じた電流の流れなしに、磁気共鳴状態で磁場を介して供給者側デバイスから消費者側デバイスに伝達するものと定義される。ワイヤレス電力伝送は、充電ステーション（ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ、１０）でＥＶ（１０）に電力を伝送してＥＶ（１０）を充電するのに活用される。

図２を参照すると、ワイヤレス電力伝送は、ＥＶ（１０）に無線で電力を伝送するために、ＥＶ（１０）の少なくとも１つの構成要素と充電ステーション（２０）によって行われる。

ＥＶ（１０）は、充電ステーション（２０）から無線で磁気エネルギーを受け入れるための受信コイルを備える受信パッド（１１）を含む。受信パッド（１１）にある受信コイルは、充電ステーション（２０）にある送信パッド（２１）の送信コイルから、例えば、磁気共鳴により磁気エネルギーを受け入れる。ＥＶ（１０）で受信した磁気エネルギーは誘導電流に変換され、誘導電流は、直流電流に整流された後にバッテリー（１２）を充電するようになる。

充電ステーション（２０）は、商用電力網（ｐｏｗｅｒ ｇｒｉｄ、５０）ないし電力バックボーンから電力を受け入れ、送信パッド（２１）を通じてＥＶ（１０）にエネルギーを供給する。送信パッド（２１）は送信コイルを備える。送信パッド（２１）にある送信コイルは磁束を発生し、磁気共鳴により増幅された磁気エネルギーをＥＶ（１０）に供給する。充電ステーション（２０）は、例えばＥＶ（１０）の所有者の自宅に付属する駐車場、ガソリンスタンドでＥＶの充電のための駐車区域、ショッピングセンターや業務用建物の駐車区域などのように多様な場所に位置し得る。

充電ステーション（２０）は、有線／無線通信を通じて電力網（５０）を管理する電力基盤構造管理システム（ｐｏｗｅｒ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）又はインフラサーバと通信する。また、充電ステーション（２０）はＥＶ（１０）とも無線通信を行う。ここで、無線通信は、ＩＥＥＥ ８０２．１１規約に従うワイファイ（ＷｉＦｉ（登録商標））に基づいた無線ＬＡＮ（ＷＬＡＮ）を含んでもよく、低周波（ＬＦ：Ｌｏｗ ｆｒｅｑｕｅｎｃｙ）磁場信号及び／又は低出力磁場（ＬＰＥ：Ｌｏｗ Ｐｏｗｅｒ Ｅｘｃｉｔａｔｉｏｎ）信号を用いたＰ２ＰＳ通信をさらに含んでもよい。さらに、充電ステーション（２０）とＥＶ（１０）との間の無線通信は、ブルートゥース（登録商標）（Ｂｌｕｅｔｏｏｔｈ（登録商標））、ジグビー（ｚｉｇｂｅｅ（登録商標））、セルラ（ｃｅｌｌｕｌａｒ）など多様な通信方式の１つ以上を含んでもよい。

一方、電気自動車の充電のための通信標準文書であるＩＳＯ １５１１８によると、ＥＶ及びＥＶ充電ステーションは、メッセージを交換して全体充電プロセスを制御する。すなわち、車両側通信制御器（ＥＶＣＣ；Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）と電力供給側通信制御器（ＳＥＣＣ；Ｓｕｐｐｌｙ Ｅｑｕｉｐｍｅｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）との間に電気自動車の充電のための通信が無線ＬＡＮ（ＷＬＡＮ）を介して行われる。

通信過程でＥＶは、先ず充電ステーションが信頼し得る施設であるか否か確認するために、充電ステーションのアイデンティティを確認し、不正アクセスから通信を保護するために充電ステーションとセキュリティチャネルを設定する。このような目標は、ＩＥＴＦ ＲＦＣ ５２４６に定義の標準化された伝送階層セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）によって達成される。ＴＬＳセッションは、ＩＰ基盤の通信接続成立手続きの後にＴＬＳセッション設立手続きによって生成される。

図３は、本発明の一実施形態によるＥＶ充電基盤構造のブロック図である。

ＥＶ充電基盤構造は、ＥＶ（１０）に充電サービスを提供するためのものであり、電気自動車メーカー（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ）のサーバ（１００）、モビリティ運営者（ＭＯ：Ｍｏｂｉｌｉｔｙ ｏｐｅｒａｔｏｒ）（１１０）、証明書プロビジョニングサービス（ＣＰＳ：Ｃｅｒｔｉｆｉｃａｔｅ ｐｒｏｖｉｓｉｏｎｉｎｇ ｓｅｒｖｅｉｃｅ）（１２０）、契約証明書プール（ＣＣＰ：Ｃｏｎｔｒａｃｔ ｃｅｒｔｉｆｉｃａｔｅ ｐｏｏｌ）（１３０）、ビークル－ツー－グラウンド（Ｖ２Ｇ：Ｖｅｈｉｃｌｅ－ｔｏ－ｇｒｏｕｎｄ）サーバ（１５０）、充電ステーション（ＣＳ：Ｃｈａｒｇｉｎｇ Ｓｔａｔｉｏｎ（２００）、充電ステーション運営者（ＣＳＯ：Ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ ｏｐｅｒａｔｏｒ）（２１０）、充電サービス提供者（ＣＳＰ：Ｃｈａｒｇｅ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）（２２０）、及びクリアリングハウス（ＣＨ：Ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）（２３０）を含む。

ＥＶ（１００）は、ＥＶの所有者が所有する一般的な自動車を指し、充電ステーションで有線又は無線で充電可能である。ＥＶ（１００）には、固有の製造過程でＯＥＭプロビジョニング証明書が設置される。また、車両購入契約とＭＯ（１１０）の運営者との契約が完了すると、ＥＶ（１００）には契約証明書が設置され得る。さらに、ＥＶ（１００）には、ビークル－ツー－グラウンド（Ｖ２Ｇ）ルート証明書が設置されてもよい。

電気自動車メーカー（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ）のサーバ（１００、以下「ＯＥＭ」と略称する）は、ＯＥＭルート証明書を発行する最上位証明機関（ＣＡ）であり、その下位証明機関（ＯＥＭ ＳｕｂＣＡ １、ＯＥＭ ＳｕｂＣＡ ２）も運営、維持する。ＥＶ（１０）が製造されるとき、ＯＥＭ（１００）は、ＯＥＭ中間ＣＡ証明書（ＯＥＭ ＳｕｂＣＡ ２ ｃｅｒｔ．）を用いてＯＥＭプロビジョニング証明書を生成してＥＶ（１０）に設置する。

モビリティ運営者（ＭＯ：Ｍｏｂｉｌｉｔｙ ｏｐｅｒａｔｏｒ）（１１０）は、ＥＶの運転手が充電ステーションでＥＶを充電できるようにＥＶの所有者と充電、承認、及び決済に関する契約関係を結んでいるサービス提供者である。ＥＶが現在の充電ステーションで充電サービスを受けるためには、現在の充電ステーションがＭＯに属するか、又はローミングシナリオを支援しなければならない。ＭＯ（１１０）は、エネルギーを販売する電気供給者又は電気卸売業者によって運営されてもよい。ＭＯ（１１０）は、ＭＯルート証明書を発行する最上位証明機関（ＣＡ）としても機能する。ＭＯルート証明書とその下位ＣＡが生成するＭＯ中間ＣＡ証明書から構成されるＭＯ証明書チェーンは、契約証明書を生成するときに使用される。さらに、本発明によると、ＭＯ証明書チェーンは、ＥＶ（１０）に設置された契約証明書を非ローミング環境やローミング環境で検証するためにも用いられる。ＭＯは、「イーモビリティサービス供給者（ＥＭＳＰ：Ｅ－ｍｏｂｉｌｉｔｙ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）」とも称される。

証明書プロビジョニングサービス（ＣＰＳ：Ｃｅｒｔｉｆｉｃａｔｅ ｐｒｏｖｉｓｉｏｎｉｎｇ ｓｅｒｖｅｉｃｅ）（１２０）は、ＥＶに契約証明書が設置又はアップデートされる過程で、契約証明書チェーンと共に証明書の送受信に用いられる暗号化鍵などをＥＶのようなクライアントに提供する。ＣＰＳ（１２０）には、リーフプロビジョニング証明書（Ｌｅａｆ Ｐｒｏｖ ｃｅｒｔ．）とプロビジョニング中間ＣＡ証明書（Ｐｒｏｖ ＳｕｂＣＡ １ ｃｅｒｔ．，Ｐｒｏｖ ＳｕｂＣＡ ２ ｃｅｒｔ．）が取り付けられている。ＥＶ（１００）に契約証明書が設置又はアップデートされるとき、ＣＰＳ（１３０）は、契約証明書チェーンと共に各ＭＯの公開鍵、ディフィー－ヘルマン（ＤＨ）公開鍵、及びｅＭＡＩＤを提供するプロビジョニングサービスを供給することで、ＥＶがこれらを用いて契約証明書チェーンを検証し、契約証明書の完全性と信頼性を確認できるようにする。

契約証明書プール（ＣＣＰ：Ｃｏｎｔｒａｃｔ ｃｅｒｔｉｆｉｃａｔｅ ｐｏｏｌ）（１３０）は、ＥＶに契約証明書が設置又はアップデートされる過程で設置又はアップデートに対する応答メッセージを臨時に格納する。ＩＳＯ １５１１８標準で定めた設置及びアップデート制限時間が非常に短くて厳格な点を勘案して、応答メッセージはあらかじめＣＣＰ（１４０）に格納され、設置又はアップデートが完全に完了するまで維持される。契約証明書の設置又はアップデートが行われるＥＶが複数である可能性もあるため、応答メッセージは、参照番号が付された後にディレクトリの形態で保持される。

ビークル－ツー－グラウンド（Ｖ２Ｇ：Ｖｅｈｉｃｌｅ－ｔｏ－ｇｒｏｕｎｄ）サーバ（１５０、以下「Ｖ２Ｇ」と略称する）は、図示されたＥＶ充電基盤構造で公開鍵基盤構造（ＰＫＩ：Ｐｕｂｌｉｃ ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と関連して最上位証明機関として機能する。したがって、Ｖ２Ｇ（１５０）は、最上位信頼アンカーの役割を果たし、図３に示された全ての関与者（ａｃｔｏｒｓ）は、Ｖ２ＧルートＣＡを信頼し得る組織と見なされる。

充電ステーション（ＣＳ：Ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ）（２００）は、ＥＶ（１００）に対する充電を実際に行う。充電ステーション（２００）は、少なくとも１つの有線充電器及び／又はワイヤレス充電スポットを備えてもよい。充電ステーション（２００）は、商業的な専門充電施設に１つ以上設置されてもよい。また充電ステーション（２００）は、ＥＶの所有者の住宅に付属する駐車場、ガソリンスタンドでＥＶの充電のための駐車区域、ショッピングセンターや職場の駐車区域などのように多様な場所に位置してもよい。充電ステーション（２００）は、「充電ポイント」、「ＥＶ充電所」、「電気充電ポイント」、「充電ポイント」、「電子充電ステーション（ＥＣＳ）」、及び「ＥＶ側電力供給装置（ＥＶＳＥ）」と称されてもよい。

充電ステーション運営者（ＣＳＯ：Ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ ｏｐｅｒａｔｏｒ）（２１０）及び充電ポイント運営者（ＣＰＯ：Ｃｈａｒｇｅ ｐｏｉｎｔ ｏｐｅｒａｔｏｒ）は、充電ステーションの運営と、要請されたエネルギー伝送サービスを提供するために電気を管理する。ＣＳＯ（２１０）は、例えば、充電ステーションメーカー、充電所メーカー、又は電気供給者によって運営される。ＰＫＩに関連して、ＣＳＯ（２１０）は、各充電ステーションに対するＳＥＣＣリーフ証明書の生成に必要な下位証明機関（ＣＰＯ ＳｕｂＣＡ １、ＣＰＯ ＳｕｂＣＡ ２）を運営する。

充電サービス提供者（ＣＳＰ：Ｃｈａｒｇｅ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）（２２０）は、ＥＶユーザのクレデンシャルを管理及び認証し、料金請求及びその他付加価置サービスを顧客に提供する。ＣＳＰ（２２０）は、ＭＯ（１１０）の特別なタイプに該当すると見られ、ＭＯ（１１０）に統合された形態で具現されてもよい。ＣＳＰ（２２０）は、複数存在してもよく、各ＣＳＰ（２２０）は１つ以上のＣＳＯ（２１０）に連携されており、ＣＳＰ（２２０）と１つ以上のＣＳＯ（２１０）とは１つの充電ネットワークを構成する。ＥＶ（１１０）は、契約関係にあるＭＯ（１００）と連関しているＣＳＰ（２２０）に連携したＣＳＯ（２１０）では、ＰｎＣ方式で充電サービスを受けることができるが、他のＣＳＯ（２１０）で充電しようとする場合はローミングが必要である。各ＣＳＰ（２００）は、ローミングのために他のＣＳＰ又は他のネットワークにあるＣＳＯ（２１０）と情報を交換でき、またクリアリングハウス（２３０）とも情報を交換できる。

クリアリングハウス（ＣＨ：Ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）（２３０）は、ＭＯ及びＣＳＰ（２２０）の間の協力事項を処理する。すなわち、クリアリングハウス（ＣＨ）（２３０）は、２つの精算ないし清算当事者の間でＥＶ充電サービスローミングに対する承認、料金請求、精算手続きを円滑にさせる中間関与者の役割をしてもよい。ＥＶの運転手が、自身が契約関係を結んでいるＭＯ（１１０）のネットワークに属していない充電ステーションでＥＶを充電しようとする場合、ＣＨ（２３０）は、ＣＳＯ（２１０）又はＣＳＰ（２２０）によって連結されてローミングが行われるように支援する。ローミングが必要な状況でＣＨ（２３０）は、ＣＳＯ（２１０）又はＣＳＰ（２２０）がＭＯ（１１０）と契約を結び、承認及び請求データ（ＣＤＲ）をＭＯ（１１０）に伝達できるようにする。ＣＨ（２３０）は、「契約クリアリングハウス（ＣＣＨ：Ｃｏｎｔｒａｃｔ ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）」、「モビリティクリアリングハウス（ＭＣＨ：Ｍｏｂｉｌｉｔｙ ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）」、「ローミングプラットフォーム（ｒｏａｍｉｎｇ ｐｌａｔｆｏｒｍ）」、「イーモビリティクリアリングハウス（Ｅ－ＭＯＣＨ：Ｅ－ＭＯｂｉｌｉｔｙ ｃｌｅａｒｉｎｇ ｈｏｕｓｅ）」などと称されてもよい。

「充電ステーション運営者（ＣＳＯ）」、「証明書プロビジョニングサービス（ＣＰＳ）」、「モビリティ運営者（ＭＯ）」、「契約クリアリングハウス（ＣＣＨ）」、及び「Ｖ２Ｇ」は、人を指すか、人の組織を指すように思われ得るが、本明細書におけるこれらの表現は、ハードウェア、ソフトウェア、及び／又はこれらの組み合わせで具現され、可読性を高めるように短く、機能的に名称が付与されたものである。一実施形態において、これらのコンポネントは、ハードウェアとソフトウェアとの結合で具現され、インターネットのようなネットワークを介して他のデバイスのアクセスを許容するサーバ装置であってもよい。これらのコンポネントは、機能的に区分されたものであるため、これらのうち２つ以上が１つの物理的装置内に格納されて実行されてもよく、１つのプログラムで統合されてもよい。特に、単一のエンティティがＣＳＯとＣＳＰの役割を兼ねてもよく、他の単一のエンティティがＣＰＳとＣＣＰの役割を兼ねてもよい。一方、上記コンポネントのうちの１つ以上は、異なる外形及び名称を有するように再編成されてもよい。

一方、ＥＶ充電サービス及び関連基盤構造は、自動車、電力グリッド、エネルギー、輸送、通信、金融、電子製品など多様な産業分野が融合される分野であり、多様な観点で標準化作業が並行してきただけでなく、複数の国際標準化機構における標準化とは別に個別国単位の標準化も進行してきたため、類似の概念の用語が多い。特に、充電ステーション運営者（ＣＳＯ：ｃｈａｒｇｉｎｇ ｓｔａｔｉｏｎ ｏｐｅｒａｔｏｒ）は、充電ポイント運営者（ＣＰＯ：ｃｈａｒｇｅ ｐｏｉｎｔ ｏｐｅｒａｔｏｒ）と役割及び機能の面で共通点があり、一部の機能上の差異とニュアンスの差があり得るが、実質的に同一のエンティティを指す用語である。また、充電サービス運営者（ＣＳＰ：ｃｈａｒｇｉｎｇ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）は、モビリティ運営者（ＭＯ：ｍｏｂｉｌｉｔｙ ｏｐｅｒａｔｏｒ）と役割及び機能の側面で少なくとも部分的に共通点があり、混用されるか入れ替わって使用される用語である。本明細書の解釈おいては、このような現実の事情を勘案しなければならない。

図３に示す基盤構造では、ＰｎＣの作動に必要な基礎として公開鍵基盤構造（ＰＫＩ）が用いられる。ＰＫＩは、人と装置の身元確認、セキュア通信の活性化、リソースに対する制御されたアクセス保障のためのフレームワークを提供する。図４は、本発明の一実施形態に適用されるＰＫＩ－基盤証明書の階層構造の一例を示す図である。図示された証明書の階層構造はＩＳＯ １５１１８標準に準拠したものである。

図４を参照すると、ＯＥＭ（１００）は、ＯＥＭルート証明書（ＯＥＭ ＲｏｏｔＣＡ ｃｅｒｔ．）を発行する最上位証明機関（ＣＡ）として機能し、その下位証明機関（ＯＥＭ ＳｕｂＣＡ １、ＯＥＭ ＳｕｂＣＡ ２）も運営する。よって、ＯＥＭ（１００）は、ＯＥＭルート証明書（ＯＥＭ ＲｏｏｔＣＡ ｃｅｒｔ．）と共に、自身の個人鍵で署名してＯＥＭ中間ＣＡ証明書（ＯＥＭ ＳｕｂＣＡ １ ｃｅｒｔ． ｃｅｒｔ．，ＯＥＭ ＳｕｂＣＡ ２ ｃｅｒｔ．）を生成する。ＥＶが製造されるとき、ＯＥＭ（１００）の２次中間ＣＡ（ＯＥＭ ＳｕｂＣＡ ２）は、ＯＥＭの２次中間ＣＡ証明書（ＯＥＭ ＳｕｂＣＡ ２ ｃｅｒｔ．）に含まれた公開鍵と対をなす個人鍵を用いてＯＥＭプロビジョニング証明書（ＯＥＭ Ｐｒｏｖ ｃｅｒｔ．）を生成し、これをＥＶ（１０）に設置する。このＯＥＭプロビジョニング証明書（ＯＥＭ Ｐｒｏｖ ｃｅｒｔ．）は、ＥＶ（１０）に対する証明書の設置要請過程で要請メッセージの署名を確認するために使用され、ＥＶ（１０）の寿命にわたって車両を固有に識別できるようにする。

ＭＯ（１１０）は、ＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を発行する最上位証明機関（ＣＡ）としても機能する。ＭＯ（１１０）は、１次下位ＣＡ（ＭＯ ＳｕｂＣＡ １）のＩＤと公開鍵に自身の署名を追加して１次中間ＣＡ証明書（ＭＯ ＳｕｂＣＡ １ ｃｅｒｔ．）を生成する。ＭＯの１次下位ＣＡ（ＭＯ ＳｕｂＣＡ １）は、２次下位ＣＡ（ＭＯ ＳｕｂＣＡ ２）のＩＤと公開鍵に自身の署名を追加して２次中間ＣＡ証明書（ＭＯ ＳｕｂＣＡ ２ ｃｅｒｔ．）を生成する。ＥＶの出荷時にＭＯ（１１０）の運営者とＥＶの所有者との間で締結される契約に基づいて、ＭＯ（１１０）の２次中間ＣＡ（ＭＯ ＳｕｂＣＡ ２）は、ＭＯの２次中間ＣＡ証明書（ＭＯ ＳｕｂＣＡ ２ ｃｅｒｔ．）に含まれた公開鍵と対をなす個人鍵を用いて契約証明書（Ｃｏｎｔｒａｃｔ Ｃｅｒｔｉｆｉｃａｔｅ）を生成し、これを、例えばＥＶ（１０）が最初に訪問するＣＳ（２００）を通じてＥＶ（１０）に設置する。契約証明書は、電子モビリティアカウント識別子（ｅＭＡＩＤ：ｅ－Ｍｏｂｉｌｉｔｙ Ａｃｃｏｕｎｔ Ｉｄｅｎｔｉｆｉｅｒ）という固有識別子を通じてＥＶの所有者の決済アカウントに連結される。

図示されたように、ＯＥＭプロビジョニング証明書（ＯＥＭ Ｐｒｏｖ ｃｅｒｔ．）と契約証明書（Ｃｏｎｔｒａｃｔ Ｃｅｒｔｉｆｉｃａｔｅ）とは、ＯＥＭ（１００）とＭＯ（１１０）とが独自に生成したルート証明書（ＯＥＭ ＲｏｏｔＣＡ ｃｅｒｔ．，ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）にそれぞれ基づいて生成され、グローバルルート証明書（Ｖ２Ｇ ＲｏｏｔＣＡ ｃｅｒｔ．）に基づいて生成され、他の関与者（ａｃｔｏｒｓ）が使用する証明書とは独立している。しかし、図３に鎖線で示されたように、ＯＥＭ（１００）とＭＯ（１１０）のルート証明書（ＯＥＭ ＲｏｏｔＣＡ ｃｅｒｔ．，ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）の代わりに、Ｖ２Ｇルート証明書（Ｖ２Ｇ ＲｏｏｔＣＡ ｃｅｒｔ．）を用いて、ＯＥＭプロビジョニング証明書（ＯＥＭ Ｐｒｏｖ ｃｅｒｔ．）と契約証明書（Ｃｏｎｔｒａｃｔ Ｃｅｒｔｉｆｉｃａｔｅ）とを生成することは可能である。

Ｖ２Ｇ（１５０）は、少なくとも２つの系列の証明書、すなわち、ＣＳＯ（２１０、上述したように「ＣＰＯ」と類似語である）及びＣＳ（２００）のための証明書系列と、プロビジョニングサービスのための証明書系列とを生成できるようにする。

先ず、Ｖ２Ｇ（１５０）は、ＣＰＯの１次下位ＣＡ（ＣＰＯ ＳｕｂＣＡ １）のＩＤと公開鍵に自身の署名を追加して１次中間ＣＡ証明書（ＣＰＯ ＳｕｂＣＡ １ ｃｅｒｔ．）を生成する。ＣＰＯの１次下位ＣＡ（ＭＯ ＳｕｂＣＡ １）は、ＣＰＯの２次下位（ＣＰＯ ＳｕｂＣＡ ２）のＩＤと公開鍵に自身の署名を追加して２次中間ＣＡ証明書（ＣＰＯ ＳｕｂＣＡ ２ ｃｅｒｔ．）を生成する。ＣＰＯの２次中間ＣＡ（ＣＰＯ ＳｕｂＣＡ ２）は、ＣＰＯの２次中間ＣＡ証明書（ＣＰＯ ＳｕｂＣＡ ２ ｃｅｒｔ．）に含まれた公開鍵と対をなす個人鍵を用いてＳＥＣＣリーフ証明書（ＳＥＣＣ Ｌｅａｆ Ｃｅｒｔｉｆｉｃａｔｅ）を生成し、これをＣＳ（２００）に伝送して設置できるようにする。このＳＥＣＣリーフ証明書（ＳＥＣＣ Ｌｅａｆ Ｃｅｒｔｉｆｉｃａｔｅ）は、ＥＶ（１０）が偽の充電ステーションでなく実際の充電ステーションと通信しているかを確認するために、ＴＬＳ通信設定中にＥＶ（１０）により使用される。この証明書は、ＣＳ（２００）だけでなくＣＳＯ（２１０）のバックエンド内部にも格納される。

Ｖ２Ｇ（１５０）は、プロビジョニングの１次下位ＣＡ（Ｐｒｏｖ ＳｕｂＣＡ １）のＩＤと公開鍵に自身の署名を追加して１次中間ＣＡ証明書（Ｐｒｏｖ ＳｕｂＣＡ １ ｃｅｒｔ．）を生成する。プロビジョニングの１次下位ＣＡ（Ｐｒｏｖ ＳｕｂＣＡ １）は、プロビジョニングの２次下位（Ｐｒｏｖ ＳｕｂＣＡ ２）のＩＤと公開鍵に自身の署名を追加して２次中間ＣＡ証明書（Ｐｒｏｖ ＳｕｂＣＡ ２ ｃｅｒｔ．）を生成する。プロビジョニングの２次中間ＣＡ（ＣＰＯ ＳｕｂＣＡ ２）は、プロビジョニングの２次中間ＣＡ証明書（Ｐｒｏｖ ＳｕｂＣＡ ２ ｃｅｒｔ．）に含まれた公開鍵と対をなす個人鍵を用いてリーフプロビジョニング証明書（Ｌｅａｆ Ｐｒｏｖ Ｃｅｒｔｉｆｉｃａｔｅ）を生成し、これを証明書プロビジョニングサービス（ＣＰＳ、１２０）に伝送して設置できるようにする。

一方、各ルートＣＡ（Ｖ２Ｇ ＲｏｏｔＣＡ、ＭＯ ＲｏｏｔＣＡ、ＯＥＭ ＲｏｏｔＣＡ）は、ＯＣＳＰ証明書を発行して提供するため、諸般のクライアントがオンライン証明書状態プロトコル（ＯＣＳＰ：Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）によって、ＯＣＳＰサーバに接続して証明書の有効性に関する失効／未失効の状態情報を要請し、照会結果を受信できるようにする。図面には簡単に表示するためにＯＣＳＰ証明書がＣＰＯの下位ＣＡ（ＣＰＯ ＳｕｂＣＡ １、ＣＰＯ ＳｕｂＣＡ ２）に対してのみ利用可能なように示されているが、全てのルートＣＡ（Ｖ２Ｇ ＲｏｏｔＣＡ、ＭＯ ＲｏｏｔＣＡ、ＯＥＭ ＲｏｏｔＣＡ）が自身のルート証明書系列の証明書に対して有効性を照会できるようにＯＣＳＰ証明書を発行して提供することができる。

本発明の実施形態では、一般に利用可能な３つの方法で証明書を確認及び検証する。第一に、証明書の受信者が証明書にある署名値を証明書にある公開鍵で復号化してハッシュを復元し、復元されたハッシュが証明書に含まれているハッシュと同一であるか否かを比較することで、証明書の完全性を確認する。第二に、証明書の受信者が証明書チェーンでルート証明書からリーフ証明書に至るまで、順に各証明書の所有者情報をその下位ＣＡの発行者情報と比較することで、各証明書の完全性と信頼性とを検証する。第三に、証明書の受信者が該当証明書に対するルートＣＡから受信した証明書廃棄リスト（ＣＲＬ：Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）を通じて廃棄有無を確認するか、又はルートＣＡに連携したＯＣＳＰサーバに証明書状態を照会して確認することで、有効性を検証する。

図５は、ＥＶに対するローミングサービスを説明するためにＰｎＣ充電基盤構造を構成するノードを例示的に示す図である。図示された例において、第１ＥＶ（ＥＶ１）は、第１ＣＳＰ（ＣＳＰ１）と契約関係にあり、第１ＣＳＰ（ＣＳＰ１）のネットワークに属する第１ＣＳＯ（ＣＳＯ１）に接続された第１ＣＳ（ＣＳ１）の電気自動車電力供給装置（ＥＶＳＥ：ＥＶ Ｓｕｐｐｌｙ Ｅｑｕｉｐｍｅｎｔ）で充電サービスを利用できる。また、第２ＥＶ（ＥＶ２）は、第２ＣＳＰ（ＣＳＰ２）と契約関係にあり、第２ＣＳＰ（ＣＳＰ２）のネットワークに属する第２ＣＳＯ（ＣＳＯ２）に接続された第２ＣＳ（ＣＳ２）の電気自動車電力供給装置（ＥＶＳＥ：ＥＶ Ｓｕｐｐｌｙ Ｅｑｕｉｐｍｅｎｔ）で充電サービスを利用できる。すなわち、第１ＥＶ（ＥＶ１）と第２ＥＶ（ＥＶ２）とは、それぞれのホームＣＳＯ（ＣＳＯ１、ＣＳＯ２）に接続されたＣＳで特に障害なく充電を行うことができる。ところで、第１ＥＶ（ＥＶ１）が第２ＣＳＯ（ＣＳＯ２）の管轄下にある第２ＣＳ（ＣＳ２）を訪問するか、又は第２ＥＶ（ＥＶ２）が第１ＣＳＯ（ＣＳＯ１）が管理する第１ＣＳ（ＣＳ１）を訪問する場合は、ローミング環境が構成され、特にこのような環境で、後述のようにＥＶに証明書を設置又は更新しなければならない状況も発生し得るようになる。

図６は、ローミングが必要でない状況と必要な状況の例を示す図である。

ＰｎＣの承認のための基盤構造において、ＥＶは、充電ステーション（ＣＳ）及び電気自動車電力供給装置（ＥＶＳＥ）に接続するだけで、自動で承認、充電、及び決済が行われる。このようなＰｎＣ方式の承認が適用されるためには、ＥＶの所有者がＭＯ及びＣＳＰとサービス利用契約を締結しなければならない。契約締結後に、ＥＶには契約証明書が設置され、この契約証明書に基づいて本人認証と充電承認及び決済が行われる。よって、ＥＶの所有者はＥＶと契約関係にあるＭＯ及びＣＳＰのネットワークに属するＣＳＯが管理するＣＳに訪問して、プラグを接続させるか、又はワイヤレス充電スポットの上に駐車するだけで、ＥＶが契約証明書を自動で提示し、承認及び充電サービスを受けることができるようになる。

ＥＶ充電基盤構造内には複数のＭＯ及びＣＳＰが存在してもよく、各ＭＯ及びＣＳＰは、ＰｎＣの許容可否の観点から独立したネットワークを構成するようになる。各ＥＶは、自身が契約関係にあるＭＯ及びＣＳＰが属するネットワークではＰｎＣサービスを自由に利用可能であるが、他のネットワークではＰｎＣサービスが制限的であるか利用不可であり得る。例えば、図５において、ＥＶが第１ＣＳＰ（ＣＳＰ_Ａ）と契約関係にある場合、ＥＶは、第１ＣＳＰ（ＣＳＰ_Ａ）が属するネットワークで、第１ＣＳＰ（ＣＳＰ_Ａ）に関連するＣＳＯ_Ａが管理するＥＶＳＥでＰｎＣサービスを利用できる。

これに対して、ＥＶが第２ＣＳＰ（ＣＳＰ_Ｘ）と契約関係にある場合、ＥＶは、契約関係にない第１ＣＳＰ（ＣＳＰ_Ａ）が属するネットワークでは、例えば第１ＣＳＰ（ＣＳＰ_Ａ）に関連するＣＳＯ_Ａが管理するＥＶＳＥでは、ＰｎＣサービスを正常に受けにくいことがある。ところが、もし訪問ＣＳＰ（例えばＣＳＰ_Ａ）とホームＣＳＰ（例えば、ＣＳＰ_Ｘ）との間にローミング契約関係が形成されていると、訪問ＣＳＯ（ＣＳＯ_Ａ）は、ＥＶから承認要請があるとき、ホームＣＳＰ（ＣＳＰ_Ａ）にアクセスしてＥＶに対するＰｎＣサービスがなされるようにする。また、もし訪問ＣＳＰ（ＣＳＰ_Ａ）とホームＣＳＰ（ＣＳＯ_Ｘ）との間にクリアリングハウスを介する間接ローミング契約関係が形成されていると、訪問ＣＳＯ（ＣＳＯ_Ａ）は、ＥＶから承認要請があるとき、クリアリングハウスの支援下でＥＶに対するＰｎＣサービスがなされるようにしてもよい。

図７ないし図１１を参照して一般的な承認過程を具体的に説明する。

図７は、ローミングが必要でない状況での契約による一般的なサービスの承認過程を示すフローチャートである。

図示された例において、ＣＳの供給装置通信制御器（ＳＥＣＣ）は、乱数を自身の個人鍵で暗号化してチャレンジ（ＧｅｎＣｈａｌｌｅｎｇｅ）を生成し、生成されたチャレンジをＥＶの電気自動車通信制御器（ＥＶＣＣ）に伝送する（第６００ステップ）。ＣＳは、少なくともＥＶから後続のメッセージを受信するまでは上記チャレンジ値を保管する。チャレンジを受信すると、ＥＶは、このチャレンジをＣＳ公開鍵で復号化し、事前に定められた規則に従って選択される数字を含む承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）を自身の個人鍵で暗号化して、チャレンジに対する応答としてＣＳに返信する（第６０２ステップ）。このとき、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）にはＥＶの契約証明書チェーンが含まれる。

ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）に含まれた署名値をＥＶの公開鍵で復号化してハッシュを復元し、復元されたハッシュを承認要請メッセージに含まれたハッシュと比較することで、承認要請メッセージの署名値を確認する（第６０４ステップ）。このとき、ＣＳは、承認要請メッセージに含まれた応答値がチャレンジに対応するかを追加的に判断してもよい。

次いで、ＣＳは、ＥＶから受信した契約証明書チェーンをＣＳＯに伝達する（第６０６ステップ）。ＣＳＯは、契約証明書チェーンを検証する（第６０８ステップ）。契約証明書チェーンの検証は、上記で説明したように証明書チェーンでルート証明書からリーフ証明書に至るまで、順に各証明書の所有者情報をその下位ＣＡの発行者情報と比較することで行われ、これによって各証明書の完全性と信頼性とを検証する。

その後、ＣＳＯは、契約証明書チェーンをＣＳＰに伝達する（第６１０ステップ）。ＣＳＰは、契約証明書チェーンにある各証明書に対して、証明書廃棄リスト（ＣＲＬ）を用いるか、又はＯＣＳＰサーバに照会することで、証明書の失効有無を確認する（第６１２ステップ）。確認結果によって、ＣＳＰは、契約すなわち取引を承認する承認メッセージをＣＳに送信する（第６１４ステップ）。承認メッセージを受けると、ＣＳは、承認結果メッセージ（Ａｕｔｈｏｒｉｚａｔ’Ｒｅｓ）をＥＶに送信する（第６１６ステップ）。

ところで、このような承認過程において、ＥＶに契約証明書チェーンの最上位証明書であるＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）が設置されていないため（ＩＳＯ １５１１８－２０標準２０１８．７．２．基準）、ＥＶが第６０２ステップで契約証明書チェーンをＣＳに送信するとき、リーフ証明書である契約証明書そのものと中間ＣＡ証明書（ＭＯ ＳｕｂＣＡ １ ｃｅｒｔ．，ＭＯ ＳｕｂＣＡ ２ ｃｅｒｔ．）のみが含まれ、ＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）は除外される。これによって、第６０８ステップで証明書チェーンをＣＳから受信したＣＳＯもＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）なしで契約証明書チェーンを検証するようになり、ＣＳＯがＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を別に確保していない限り、証明書の検証が不完全となる可能性がある。ＣＳＯが保有しているＣＳＰルート証明書（ＣＳＰ ＲｏｏｔＣＡ ｃｅｒｔ．）では、ＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）に代わることができないことは勿論である。また、ＣＳＰがＣＳＰルートＣＡに連携したＣＲＬやＯＣＳＰサーバ以外に、ＭＯルートＣＡに連携したＣＲＬやＯＣＳＰサーバにアクセスできるか否かは断言できないため、第６１２ステップにおける証明書の失効有無の確認も不完全な可能性がある。

図８は、直接ローミングが行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。図示された例において、ＣＳを管理する訪問ＣＳＯは、ＥＶと契約を結んでいるホームＣＳＰのネットワークに属してはいないが、訪問ＣＳＰとホームＣＳＰとの間にローミング契約関係が形成されていると仮定する。

このような場合にも、第６００ステップないし第６０４ステップは、図７と同様に行われ得る。すなわち、ＣＳは、チャレンジをＥＶに伝送し（第６００ステップ）、これに応答して、ＥＶは承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）をＣＳに送信する（第６０２ステップ）。また、ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）の署名値を確認する（第６０６ステップ）。

次いで、ＣＳは、ＥＶから受信した契約証明書チェーンを訪問ＣＳＯに伝達する（第６２６ステップ）。訪問ＣＳＯは、契約証明書チェーンを検証する（第６２８ステップ）。このとき、訪問ＣＳＯは、ｅＭＡＩＤを通じてホームＣＳＰにアクセスする経路を知っている可能性もある。これによって、訪問ＣＳＯは、ホームＣＳＰを確認して契約証明書チェーンをホームＣＳＰに伝達する（第６３０ステップ）。ホームＣＳＰは、契約証明書チェーンにある各証明書に対して、証明書廃棄リスト（ＣＲＬ）を用いるか、又はＯＣＳＰサーバに照会することで、証明書の失効有無を確認する（第６３２ステップ）。確認結果によって、ホームＣＳＰは、契約、すなわち取引を承認する承認メッセージをＣＳに送信する（第６３４ステップ）。承認メッセージを受けると、ＣＳは、承認結果メッセージをＥＶに送信する（第６３６ステップ）。

ところが、この場合にも、第６２８ステップで訪問ＣＳＯがＭＯルート証明書なしに契約証明書チェーンを検証するようになり、訪問ＣＳＯが、ＣＳＰルート証明書（ＣＳＰ ＲｏｏｔＣＡ ｃｅｒｔ．）とは別にＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を確保していない限り、証明書の検証が不完全な可能性がある。また、ホームＣＳＰがＣＳＰルートＣＡに連携したＣＲＬやＯＣＳＰサーバ以外に、ＭＯルートＣＡに連携したＣＲＬやＯＣＳＰサーバにアクセスできるか否かは断言できないため、第６３２ステップにおける各証明書に対する失効有無の確認も不完全な可能性がある。

図９は、間接ローミングが行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。図示された例において、ＣＳを管理する訪問ＣＳＯは、ＥＶと契約を結んでいるホームＣＳＰのネットワークに属してはいないが、訪問ＣＳＰとホームＣＳＰとの間にクリアリングハウスを介する間接ローミング契約関係が形成されていると仮定する。

このような場合にも、第６００ステップないし第６０４ステップは、図７及び図８と同様に行われ得る。すなわち、ＣＳは、チャレンジをＥＶに伝送し（第６００ステップ）、これに応答して、ＥＶは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）をＣＳに送信する（第６０２ステップ）。また、ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）に含まれた署名値を確認する（第６０６ステップ）。次いで、ＣＳは、ＥＶから受信した契約証明書チェーンを訪問ＣＳＯに伝達する（第６４６ステップ）。

訪問ＣＳＯは、ＥＶと契約を結んでいるホームＣＳＰと直接的な契約関係がないため、訪問ＣＳＯが保有しているｅＭＡＩＤなどの情報ではホームＣＳＰを把握することができない。しかし、訪問ＣＳＯは、クリアリングハウスと契約関係にあるため、クリアリングハウスがホームＣＳＰを把握できるか、またどんなクリアリングハウスがホームＣＳＰを把握できるかを確認する（第６４８ステップ）。クリアリングハウスが少なくとも１つのホームＣＳＰを把握していることを確認した後（第６５０ステップ）、訪問ＣＳＯは、契約証明書チェーンを該当クリアリングハウスに伝達する（第６５２ステップ）。クリアリングハウスは、契約証明書チェーンを検証した後（第６５４ステップ）、契約証明書チェーンをホームＣＳＰに伝達する（第６５６ステップ）。ホームＣＳＰは、契約証明書チェーンにある各証明書に対して、証明書廃棄リスト（ＣＲＬ）を用いるか、又はＯＣＳＰサーバに照会することで、証明書の失効有無を確認する（第６５７ステップ）。確認結果によって、ホームＣＳＰは、契約すなわち取引を承認する承認メッセージをＣＳに送信する（第６５８ステップ）。承認メッセージを受けると、ＣＳは、承認結果メッセージをＥＶに送信する（第６５９ステップ）。

この場合にも、第６５４ステップでクリアリングハウスがＣＳＰルート証明書（ＣＳＰ ＲｏｏｔＣＡ ｃｅｒｔ．）とは別にＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を確保していない限り、証明書の検証が不完全な可能性がある。また、ホームＣＳＰがＣＳＰルートＣＡに連携したＣＲＬやＯＣＳＰサーバ以外に、ＭＯルートＣＡに連携したＣＲＬやＯＣＳＰサーバにアクセスできるか否かは断言できないため、第６５７ステップにおける各証明書に対する失効有無の確認も不完全な可能性がある。

図１０は、即席（ｏｎ－ｔｈｅ－ｆｌｙ）直接ローミングが行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。図示された例において、ＣＳを管理する訪問ＣＳＯは、ＥＶと契約を結んでいるホームＣＳＰのネットワークに属してはいないが、訪問ＣＳＯがホームＣＳＰと即席ローミング契約（ｏｎ－ｔｈｅ－ｆｌｙ ｄｉｒｅｃｔ ｒｏａｍｉｎｇ）を締結することができると仮定する。

このような場合にも、第６００ステップないし第６０４ステップは、図７及び図８と同様に行われ得る。すなわち、ＣＳは、チャレンジをＥＶに伝送する（第６００ステップ）、これに応答して、ＥＶは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）をＣＳに送信する（第６０２ステップ）。また、ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）に含まれた署名値を確認する（第６０６ステップ）。ＣＳは、ＥＶから受信した契約証明書を訪問ＣＳＯに伝達する（第６６６ステップ）。

次いで、訪問ＣＳＯは、ホームＣＳＰと即席ローミング契約を締結する（第６６８ステップ）。次いで、訪問ＣＳＯは、契約証明書チェーンを検証する（第６７０ステップ）。訪問ＣＳＯは、ｅＭＡＩＤを通じてホームＣＳＰにアクセスする経路が分かる。これによって、訪問ＣＳＯは、契約証明書チェーンをホームＣＳＰに伝達する（第６７２ステップ）。ホームＣＳＰは、契約証明書チェーンにある各証明書に対して、証明書廃棄リスト（ＣＲＬ）を用いるか、又はＯＣＳＰサーバに照会することで、証明書の失効有無を確認する（第６７４ステップ）。確認結果によって、ホームＣＳＰは、契約すなわち取引を承認する承認メッセージをＣＳに送信する（第６７６ステップ）。承認メッセージを受けると、ＣＳは、承認結果メッセージをＥＶに送信する（第６７８ステップ）。

この場合にも、第６７０ステップで訪問ＣＳＯがＣＳＰルート証明書（ＣＳＰ ＲｏｏｔＣＡ ｃｅｒｔ．）とは別にＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を確保していない限り、証明書の検証が不完全な可能性がある。また、ホームＣＳＰがＣＳＰルートＣＡに連携したＣＲＬやＯＣＳＰサーバ以外に、ＭＯルートＣＡに連携したＣＲＬやＯＣＳＰサーバにアクセスできるか否かは断言できないため、第６７４ステップにおける各証明書に対する失効有無の確認も不完全な可能性がある。

図１１は、即席間接ローミング（ｏｎ－ｔｈｅ－ｆｌｙ ｉｎｄｉｒｅｃｔ ｒｏａｍｉｎｇ）が行われる状況での契約による一般的なサービスの承認過程を示すフローチャートである。図示された例において、ＣＳを管理する訪問ＣＳＯは、ＥＶと契約を結んでいるホームＣＳＰのネットワークに属するものではなく、訪問ＣＳＰとホームＣＳＰとの間にクリアリングハウスを介する間接ローミング契約関係が形成されているものでもない。よって、訪問ＣＳＯは、ホームＣＳＰを知らないだけでなく、ホームＣＳＰと契約関係にあるクリアリングハウスも知らない。しかし、訪問ＣＳＯがクリアリングハウスに対してホームＣＳＰとオンラインで契約を締結することを要請できると仮定する。

このような場合にも、第６００ステップないし第６０４ステップは、図７及び図９と同様に行われ得る。すなわち、ＣＳは、チャレンジをＥＶに伝送し（第６００ステップ）、これに応答して、ＥＶは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）をＣＳに送信する（第６０２ステップ）。また、ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）に含まれた署名値を確認する（第６０６ステップ）。次いで、ＣＳは、ＥＶから受信した契約証明書を訪問ＣＳＯに伝達する（第６８６ステップ）。

上記で仮定したように、訪問ＣＳＯは、ＥＶと契約を結んでいるホームＣＳＰと直接的な契約関係がないため、訪問ＣＳＯが保有しているｅＭＡＩＤなどの情報ではホームＣＳＰを把握することができない。さらに、訪問ＣＳＯは、ホームＣＳＰと既に契約関係にあるクリアリングハウスを識別しようと試みるが失敗する（第６８８ステップ）。このような場合、訪問ＣＳＯは、クリアリングハウスにホームＣＳＰを確認してホームＣＳＰと契約を締結することを要請する（第６９０ステップ）。ここで契約とは、ＥＶに対する単発性の電力充電及び決済代行を内容とするものであってもよい。クリアリングハウスとホームＣＳＰとの間に契約が締結されると（第６９２ステップ）、クリアリングハウスは、契約証明書チェーンを検証した後（第６９４ステップ）、契約証明書チェーンをホームＣＳＰに伝達する（第６９６ステップ）。ホームＣＳＰは、契約証明書チェーンにある各証明書に対して、証明書廃棄リスト（ＣＲＬ）を用いるか、又はＯＣＳＰサーバに照会することで、証明書の失効有無を確認する（第６９７ステップ）。確認結果によって、ホームＣＳＰは、契約すなわち取引を承認する承認メッセージをＣＳに送信する（第６９８ステップ）。承認メッセージを受けると、ＣＳは、承認結果メッセージをＥＶに送信する（第６９９ステップ）。

この場合にも、第６９４ステップでクリアリングハウスがＣＳＰルート証明書（ＣＳＰ ＲｏｏｔＣＡ ｃｅｒｔ．）とは別にＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を確保していない限り、証明書の検証が不完全な可能性がある。また、ホームＣＳＰがＣＳＰルートＣＡに連携したＣＲＬやＯＣＳＰサーバ以外に、ＭＯルートＣＡに連携したＣＲＬやＯＣＳＰサーバにアクセスできるか否かは断言できないため、第６９７ステップにおける各証明書に対する失効有無の確認も不完全な可能性がある。

一方、上述したように、ＩＳＯ １５１１８標準によると、ＣＳＰはＭＯの下位証明機関（ＭＯ Ｓｕｂ ＣＡ）としてＥＶに対する契約証明書を発行する。すなわち、ＥＶが出荷時からその内部に格納されているＯＥＭプロビジョニング証明書をＣＳＯに提示すると、ＣＳＯは契約証明書を発行してＥＶに伝達するようになる。契約証明書は、ＥＶに格納された状態でＰｎＣ充電ごとにＣＳに提示され、ＣＳ又は他の補助関与者（ｓｅｃｏｎｄａｒｙ ａｃｔｏｒ）がＥＶの契約を識別できるようにする。

ところが、ＥＶにこのような契約証明書が設置されていない状態で、ＥＶが充電ステーション（ＣＳ）に訪問してＰｎＣ充電を要求する状況が発生し得る。一例として、ＥＶユーザは、最初の充電時に出荷当時ＥＶに設置されているＯＥＭプロビジョニング証明書をＣＳＰ又はＭＯに伝達して契約証明書を発行されなければならないが、ＥＶが最初の充電のために訪問したＣＳがホームＣＳＰのネットワークに属していない訪問ＣＳＯに関連する充電ステーションである場合が挙げられる。このような場合、ローミング条件で契約証明書がＥＶに設置されなければならない状況が発生する。このような状況は、ＥＶの売買による名義変更の直後又はＥＶのメモリ障害の直後にも発生し得る。さらに、ローミング状況でＥＶに設置されなければならない証明書としては、契約証明書に限らず他の証明書であってもよい。Ｖ２Ｇ通信インターフェースのうちネットワーク層及びアプリケーション層上のプロトコル要件を規定しているＩＳＯ １５１１８標準や、ＥＶ充電ローミングサービスのための情報交換事項を規定するＩＥＣ ６３１１９－１標準は、これに対して何も規定していない。

本発明の一実施形態によると、各ＥＶと契約関係にある各ＣＳＰは、ＥＶがいかなるローミング状況でも、契約証明書やその他必要な証明書又はデータを受信して設置又はアップデートできるようにする。以下、本発明の一実施形態によって、ＥＶに証明書を設置又はアップデートする方法について説明する。

図１２は、本発明の一実施形態において、ホームＣＳＰから直接ローミングを通じてＥＶに伝達して設置される契約証明書の伝達経路を示す。

本実施形態において、ホームＣＰＳ（ＣＰＳＨ）に格納されている契約証明書をＥＶに設置するか、又はＥＶにある既存の証明書をこの証明書にアップデートしなければならないと仮定する。現在ＥＶは、訪問ＣＳＰ（ＣＳＰＶ）のネットワークに属する訪問ＣＳＯ（ＣＳＯＶ）に接続されたＣＳを訪問した状態である。しかし、もしホームＣＳＰ（ＣＳＰＨ）と訪問ＣＳＰ（ＣＳＰＶ）とがローミング契約関係にある場合、ＥＶは、直接ローミングによってホームＣＰＳ（ＣＰＳＨ）に格納されている契約証明書を設置するか、又は既存の証明書をこの証明書にアップデートできるようになる。

図１３は、図１２に示された証明書の伝達過程をより詳しく示すフローチャートである。

先ず、ＥＶの所有者とホームＣＳＰの運営者とは充電サービス契約を締結する（第７００ステップ）。契約締結後に、ホームＣＳＰは、ＥＶに対する契約証明書を生成する（第７０２ステップ）。生成された証明書は、ＥＶの公開鍵と、公開鍵のハッシュと、ハッシュをＭＯルートＣＡの中間ＣＡ（ＭＯ Ｓｕｂ １又はＭＯ Ｓｕｂ ２）の個人鍵で暗号化した署名値などを含む。生成された証明書は、該当ホームＣＳＰとローミング契約が締結されている全ての訪問ＣＳＰに配布されてもよい（第７０４ステップ～第７０８ステップ）。

例示的な実施形態において、第７００ステップないし第７０８ステップは、ＥＶがＣＳを通じて訪問ＥＳＯに証明書設置要請メッセージ（ＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｑ）又は証明書アップデート要請メッセージ（ＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｑ）を送信する前に先制的に行われてもよい。すなわち、ＥＶが訪問ＣＳＰに証明書の設置又はアップデートを要請すると、これを支援するように、ホームＣＳＰは、契約関係にある全ての訪問ＣＳＰに証明書設置パッケージを事前に配布して、訪問ＣＳＰが自身のＣＰＳにこれを格納できるようにする。このとき、追って即席ローミング（ｏｎ－ｔｈｅ－ｆｌｙ ｒｏａｍｉｎｇ）が形成される可能性を勘案して、現在の契約関係の有無にかかわらず全てのＣＳＰに証明書設置パッケージを事前に配布してもよい。証明書設置パッケージは、契約証明書チェーンと、ｅＭＡＩＤアカウント情報とを含み、証明書廃棄リスト（ＣＲＬ）とＯＣＳＰサーバの接続情報をさらに含んでもよい。ＣＳＰ間の証明書パッケージの伝達は、直接行われてもよく、後述のようにクリアリングハウスを介して行われてもよい。

より具体的に説明すると、第７０４ステップでホームＣＳＰが契約証明書を生成すると、該当証明書パッケージを含む証明書設置応答メッセージ（ＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｓ）又は証明書アップデート応答メッセージ（ＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｓ）がホームＣＳＰと契約関係にある全ての訪問ＣＳＰにセキュリティチャネルを通じて配布される。このとき、各ホームＣＳＰは、契約証明書チェーンを検証し、契約証明書チェーンの失効状態を確認し、ｅＭＡＩＤアカウント状態を確認し、契約がサービスに対して承認可能なものであるかを確認する。確認の結果、契約証明書チェーンと、ｅＭＡＩＤアカウント、及び契約内容に何らの問題がないと、ホームＣＳＰは、証明書パッケージを直接ローミング契約がある全ての訪問ＣＳＰに配布するか、又は証明書配布契約を結んでいるクリアリングハウスに配布してもよく、両方に配布してもよい。この配布プロセスのために、ホームＣＳＰは、直接ローミング契約がある訪問ＣＳＰが１つ以上あれば、そのような訪問ＣＳＰリストを備えてもよい。また、ホームＣＳＰは、証明書の設置のためのローミング契約があるクリアリングハウスが１つ以上あれば、そのようなクリアリングハウスのリストを備えてもよい。証明書パッケージの配布のための通信は、ローミングエンドポイントを超えて行われてもよい。一方、証明書設置パッケージを受けると、訪問ＣＳＰは、自身のユーザに対する証明書を発行する場合と同一の手続きを通じて該当パッケージを自身のＣＰＳに配布する。

その後、ＥＶが証明書の設置又はアップデートを要請すると、訪問ＣＳＯは、訪問ＣＰＳから証明書設置パッケージを持ってきてＥＶに伝達する。このときの設置又はアップデートプロセスは、非ローミング状況とローミング状況との間に差異がなくてもよい。図１３の第７２０ステップないし第７３４ステップはこの過程を示す。

具体的に、第７２０ステップにおいて、ＥＶは、ＣＳに対して証明書の設置又はアップデート要請メッセージ（Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｑ）を送信する。証明書設置要請メッセージの場合、ＥＶは、ＩＳＯ １５１１８標準に準拠した通信によって充電ステーション（ＣＳ）にＯＥＭプロビジョニング証明書チェーンを送信する。一方、証明書更新要請メッセージには契約証明書チェーンが含まれてもよい。証明書の設置又はアップデート要請メッセージ（Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｑ）を受信すると、ＣＳは、要請メッセージにあるメッセージ署名値を確認する（第７２２ステップ）。このとき、ＣＳは、要請メッセージに含まれた署名値を公開鍵で復号化してハッシュを復元した後、復元されたハッシュを要請メッセージに含まれているハッシュと比較することで、メッセージ署名値を確認する。

次いでＣＳは、受信された証明書チェーンを検証する（第７２４ステップ）。証明書の設置のためのＯＥＭプロビジョニング証明書の場合、プロビジョニング証明書チェーンでＯＥＭルート証明書（ＯＥＭ ＲｏｏｔＣＡ ｃｅｒｔ．）からリーフ証明書であるプロビジョニング証明書（ＯＥＭ Ｐｒｏｖ ｃｅｒｔ．）に至るまで、順に各証明書の所有者情報をその下位ＣＡの発行者情報と比較することで行われ、これによって各証明書の完全性と信頼性とを検証する。証明書のアップデートのための契約証明書の場合、契約証明書チェーンでＭＯルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）からリーフ証明書である契約証明書（Ｃｏｎｔｒａｃｔ ｃｅｒｔ．）に至るまで、順に各証明書の所有者情報をその下位ＣＡの発行者情報と比較することで行われ、これによって各証明書の完全性と信頼性とを検証する。次いでＣＳは、証明書の設置又はアップデート要請メッセージ（Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｑ）を訪問ＣＳＯに伝達する（第７２６ステップ）。

訪問ＣＳＯは、ＯＥＭプロビジョニング証明書チェーン又は契約証明書チェーンにある各証明書の失効有無を確認する（第７２８ステップ）。証明書の未失効状態、すなわち有効性は、ＯＥＭルートＣＡから受信した証明書廃棄リスト（ＣＲＬ）又はＭＯルートＣＡから受信した証明書廃棄リストを通じて確認してもよく、ＯＥＭルートＣＡ又はＭＯルートＣＡに連携したＯＣＳＰサーバに証明書状態を要請し、照会結果を受信した後に確認してもよい。

次いで、訪問ＣＰＳは、第７０８ステップで格納された新しい契約証明書チェーンをＭＯルートＣＡ証明書に基づいて検証する（第７３０ステップ）。また訪問ＣＰＳは、新しい契約証明書チェーンにある各証明書の失効有無を確認する（第７３２ステップ）。証明書の未失効状態、すなわち有効性は、ＭＯルートＣＡから受信した証明書廃棄リスト（ＣＲＬ）を通じて確認してもよく、ＭＯルートＣＡに連携したＯＣＳＰサーバに証明書状態を要請し、照会結果を受信して確認してもよい。

一般に、ＩＳＯ １５１１８標準に準拠したＥＶがＣＳとＴＬＳ連結を試みるとき、ＣＳは、ＣＳの証明書チェーンにある全ての証明書が有効であること、すなわち取り消されていないことを証明する必要がある。このために、本発明の一実施形態によると、ＣＳは、ＣＳＯ ＰＫＩのＯＣＳＰ応答者からのＯＣＳＰ応答を取得するために、ＣＳＭＳに周期的にかつＯＣＳＰ応答を有効に維持するために十分に頻繁に要請する。ＣＳは、１つの証明書チェーンに対して１つのＯＣＳＰ応答を格納する。

各証明書に対して、ＣＳは、既存のＯＣＳＰ応答が満了する直前ごとにＯＣＳＰ応答をアップデートすることを決定し、ＣＳＭＳにＯＣＳＰ検索を要請する。ＯＣＳＰ検索の要請には、ＯＣＳＰ要請メッセージと、証明書発行者の固有名称（ＤＮ：Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ）と、証明書の一連番号とが含まれてもよい。各要請に対して、ＣＳＭＳは、発行者のＤＮ及び一連番号で証明書データベースを照会してＯＣＳＰ応答ＵＲＬを検索する。ＵＲＬが見つからない場合、ＣＳＭＳは他の方法でＵＲＬ検索を試みる。最上のＵＲＬがない場合、ＣＳＭＳは応答にエラーを表示する。ＯＣＳＰ応答を成功的に検索すると、ＣＳＭＳは、ＯＣＳＰ応答メッセージリストをＣＳに返信する。検索のうち１つでも失敗すると、ＣＳＭＳは、失敗したＯＣＳＰクエリとその理由を表示する。ＣＳは、受信されたＯＣＳＰ応答を格納すると共に、ＯＣＳＰステープリングを通じてＴＬＳ連結中にＥＶに送信する。各エラーに対しては、エラータイプによって、ＣＳが検索を再試行するか、それとも維持状態を入力するかを決定する。

このようにＣＳの証明書状態に関する情報を最新状態で維持するために、ＣＳＭＳは、充電ステーションと自身が用いる証明書を格納するための証明書データベースを保持する。また、ＣＳは、証明書チェーンに対する有効なＯＣＳＰ応答セットを常に保持する。ＣＳは、常に有効な状態で維持できる程度に、頻繁にＣＳＭＳにＯＣＳＰ応答を要請することが好ましい。

第７３０ステップで新しい契約証明書チェーンが検証され、第７３２ステップで新しい契約証明書チェーン内にある各証明書の有効性に問題がないと、訪問ＣＰＳは、新しい契約証明書パッケージを含んで証明書の設置／更新応答（すなわち、Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｓメッセージ）をＣＳに送信する（第７３４ステップ）。ＣＳは、新しい契約証明書パッケージを再度ＥＶに送信し、ＥＶで新しい証明書が設置又は更新できるようになる（第７３６ステップ）。

一方、第７０４ステップ～第７０８ステップで事実上ほとんど全てのＣＳＰに配布された契約証明書は、配布後に一定の期間が経過するか、又は該当ＥＶに契約証明書の設置が完了した後は、個人情報保護データの格納負担を軽減するために各ＣＳＰから削除されてもよい。このために、該当ＥＶに契約証明書の設置が完了した後は、ホームＣＳＰが契約証明書が配布された全てのＣＳＰ及びクリアリングハウスに契約証明書の設置完了を通知することが好ましい。

先ず、ＥＶの所有者とホームＣＳＰの運営者とは充電サービス契約を締結する（第７００ステップ）。契約締結後に、ホームＣＳＰは、ＥＶに対する契約証明書を生成する（第７０２ステップ）。生成された証明書は、ＥＶの公開鍵と、公開鍵のハッシュと、ハッシュをＭＯルートＣＡの中間ＣＡ（ＭＯ Ｓｕｂ １又はＭＯ Ｓｕｂ ２）の個人鍵で暗号化した署名値などを含む。生成された証明書は、該当ホームＣＳＰとローミング契約が締結されている全ての訪問ＣＳＰに配布される（第７０４ステップ～第７０８ステップ）。

このようにＣＳは、第７３４ステップで訪問ＣＰＳから受信したデータ、例えば契約証明書パッケージを第７３６ステップでＥＶに伝送するが、ＣＳが受信した全ての証明書データがＥＶに伝送されるわけではない。すなわち、ＣＳは、自身の必要に応じて証明書を受け入れて設置するか、又は既存に格納されていた証明書を更新してもよい。例えば、ＣＳは、ＥＶと充電ステーション管理システム（ＣＳＭＳ：Ｃｈａｒｇｉｎｇ Ｓｔａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）を認証するのに用いるルートＣＡ証明書及び関連メタデータと、ＥＶに対して自身を認証するのに用いるクロス証明書をＣＳＭＳから取得してもよい。言い換えると、ＣＳは、セキュリティ動作のために一部のルートＣＡ証明書（ルートＣＡ用として発行されたもの。しかし、必ず自己署名されている必要はない）と関連メタデータを自身によって格納する必要がある。証明書のメタデータには、ＳＨＡ１ハッシュ（ＴＬＳ用）と発行者のＤＮ／一連番号（証明書設置用）が含まれてもよい。

ＣＳが自身の必要に応じて受信して格納又は更新する証明書の例を挙げると、下記のとおりである。ＣＳは、ＣＳＭＳとセキュリティチャネルを設定する間にＣＳＭＳを認証するために、ＣＳＭＳの証明書チェーンのルートＣＡ証明書（すなわち、ＣＳＭＳルートＣＡ証明書）が必要であるが、これは、一般にＣＳのＶ２ＧルートＣＡと同一であると見なされる。また、ＩＳＯ １５１１８標準に準拠したＥＶがＰｎＣ方式で承認を受けることを選択し、契約証明書チェーンを検証することがＣＳの役割であれば、ＣＳはＥＭＳＰのルートＣＡ証明書を有する必要がある。さらに、契約証明書の設置又はアップデートの場合、設置されたＯＥＭプロビジョニング証明書チェーン又はアップデートされた契約証明書チェーンを検証することがＣＳの役割であれば、ＣＳはＯＥＭルートＣＡ証明書又はＥＭＳＰルートＣＡ証明書が必要な場合がある。

さらに、ＣＳＯが該当ＣＳＯのＶ２ＧルートＣＡ以外のＶ２ＧルートＣＡのみ信頼するＥＶに対するサービスを許容するためにクロス証明を支援する場合は、ＣＳはＥＶが信頼するＶ２ＧルートＣＡで発行したクロス証明書を必要とすることがある。一方、ＥＶがＣＳＯのＶ２ＧルートＣＡ（ＴＬＳ用）又はＣＰＳのＶ２ＧルートＣＡ証明書を信頼し得るかを確認するためには、ＣＳは使用可能な信頼アンカーのメタデータを知る必要がある。信頼アンカーには、ＣＳのＶ２ＧルートＣＡ（マイグレーションのための新しいルートＣＡを含む）及びクロス証明Ｖ２ＧルートＣＡが含まれる。他方、ＣＳは、ファームウエア２進数コードの完全性を確認するのに用いられるＣＳ構成品メーカーのルートＣＡ証明書を必要とする。また、ＣＳのＶ２ＧルートＣＡマイグレーションの場合、ＣＳＯがＲＦＣ ４２１０に定義されたマイグレーション方法を利用すると選択すると、マイグレーション期間中にＣＳは２つのクロス証明書のうちの１つを保有することが必要な場合がある。

ここで、ＯｌｄＷｉｔｈＮｅｗ証明書とＮｅｗＷｉｔｈＯｌｄ証明書が存在する。ＯｌｄＷｉｔｈＮｅｗ証明書とは、以前ルートＣＡに対して新しいルートＣＡで署名したクロス証明書を指し、以前証明書チェーンを有するＣＳは、新しいルートＣＡを信頼するＥＶのためにこれを必要とする。ＮｅｗＷｉｔｈＯｌｄ証明書とは、新しいルートＣＡに対して以前ルートＣＡで署名したクロス証明書を指し、新しい証明書チェーンを有するＣＳは、以前ルートＣＡを信頼するＥＶのためにこれを必要とする。

ＣＳが自身の必要に応じて証明書を受信して格納又は更新させるプロセスの一実施形態は、ＣＳＭＳによってトリガーされる。すなわち、ＣＳに設置しなければならないＣＡ証明書及びメタデータのいずれかに対するアップデートがＣＳＭＳにある場合、ＣＳＭＳは１つ以上のＣＳにアップデートリストを送り、各アップデートデータは、「アップデート＝（タイプ、証明書、メタデータ）」のフォーマットでなっている。例えば、ＣＳＯのＶ２ＧルートＣＡの場合、各アップデートデータは、（Ｖ２ＧルートＣＡ、＜Ｖ２ＧルートＣＡ証明書＞）のフォーマットでなっていてもよい。ＥＭＳＰルートＣＡ証明書の場合、（ＥＭＳＰルートＣＡ、＜ＥＭＳＰＲｏｏＣＡ証明書＞、－）のフォーマットでなっていてもよい。ＯＥＭルートＣＡ証明書の場合、（ＯＥＭルートＣＡ、＜ＯＥＭＲｏｏＣＡ証明書＞、－）のフォーマットでなっていてもよい。クロス証明書の場合、（ＣｒｏｓｓＣｅｒｔ、＜クロス証明書＞、－）のフォーマットでなっていてもよい。クロス証明Ｖ２ＧルートＣＡ証明書の場合、（ＣｒｏｓｓルートＣＡ、－、＜メタデータ＞）のフォーマットでなっていてもよい。マイグレーションのためのＯｌｄＷｉｔｈＮｅｗクロス証明書の場合、（ＯｌｄＷｉｔｈＮｅｗ、＜ＯｌｄＷｉｔｈＮｅｗ証明書＞、－）のフォーマットでなっていてもよく、マイグレーションのためのＮｅｗＷｉｔｈＯｌｄクロス証明書の場合、（ＮｅｗＷｉｔｈＯｌｄ、＜ＮｅｗＷｉｔｈＯｌｄ証明書＞、－）のフォーマットでなっていてもよい。

上記のような証明書の場合、ＣＳＭＳからアップデートを受信すると、ＣＳは、過度な遅延なく受信した証明書又はメタデータを設置し、アップデートタイムスタンプをアップデートする。

ＣＳが自身の必要に応じて証明書を受信して格納又は更新させるプロセスの他の実施形態は、ＣＳＭＳによってトリガーされる。すなわち、ＣＳがＣＡ証明書の変更事項を、例えば周期的にアップデートすることを決定するとき、ＣＳは、一定の情報をＣＳＭＳに送信することで、ＣＡ証明書のアップデートを要請する。このとき、ＣＳからＣＳＭＳに送信される情報の例としては、最後に成功したアップデートのタイムスタンプ、現在ＣＳにあるＣＡ証明書の発行者のＤＮ／一連番号リストを含む。アップデート要請を受信すると、ＣＳＭＳは、表示されたタイムスタンプの後にアップデート／追加されたＣＡ証明書／メタデータを送信する。ＣＳＭＳで応答を受信すると、ＣＳはＣＡ証明書とメタデータを安全に格納する。

ＣＳＭＳがＣＡ証明書データベースをアップデートすると、ＣＳＭＳは、関連ＣＳにアップデート又は最終のアップデート後のアップデートパッケージの設置を要請しなければならない。要請を受けると、ＣＳは、受信されたＣＡ証明書のアップデートを設置してタイムスタンプをアップデート時間で設定する。ＣＳＯの政策によって、ＣＳは、周期的にＣＳＭＳに最終アップデートのタイムスタンプを提供してＣＡ証明書のアップデートを要請する。また、要請を受けると、ＣＳＭＳは、要請に含まれたタイムスタンプの後に変更された全てのＣＡ証明書のアップデートを送信する。ＣＳＭＳは、ＣＡ証明書のアップデートを送信するとき、証明書の類型、証明書、及びメタデータのリストを送信し、これらのうちメタデータのみがクロス証明Ｖ２ＧルートＣＡ証明書をクロス証明するために送信される。

一方、ＣＳは、安全な（ｓｅｃｕｒｅ）動作のために複数のＣＡ証明書及び関連情報を保有する必要がある。例えば、ＩＳＯ １５１１８標準に準拠したＥＶがＰｎＣ方式で承認を受けることを選択すると、ＣＳは、契約証明書チェーンを有効化するために、ＥＭＳＰのルートＣＡ証明書が必要な場合がある。また、契約証明書の設置のために、ＣＳは、ＯＥＭ又はＥＭＰＳのルートＣＡ証明書が必要な場合もある。ＣＳＭＳとセキュリティチャネルを設定するとき、ＣＳは、ＣＳＭＳのルートＣＡ証明書が必要であり、この証明書は一般にＶ２ＧルートＣＡである。さらに、互いに異なるＶ２Ｇ運営者間のより良好な相互運用性のために、ＣＳは、他のＶ２Ｇ運営者が発行したクロス証明書を保持する必要がある。また、ＣＳは、ＥＶがＣＳＯに安全に接続できるかを決定するために、各トラストアンカーのメタデータ（例えば、ハッシュ、ＤＮ、及び一連番号）を保持する必要がある。

ＣＳが安全な（ｓｅｃｕｒｅ）動作のために複数のＣＡ証明書及び関連情報をアップデートするプロセスの一実施形態は、ＣＳによってトリガーされてもよい。もしＣＳがＣＡ証明書インベントリの変更事項をアップデートすることを決定した場合、ＣＳは、全てのＣＡ証明書のアップデートをＣＳＭＳに要請する。このとき、要請には、最後に成功したアップデート要請のタイムスタンプと、ＣＳにあるＣＡ証明書の発行者のＤＮ／一連番号リストが含まれてもよい。要請を受けると、ＣＳＭＳは、ＣＡ証明書のアップデートのタイムスタンプを確認し、要請にあるタイムスタンプの後にアップデートされた証明書のデータのみをＣＳに送信する。このような方式でＣＳに送信される証明書には、ＣＳＭＳのＶ２ＧルートＣＡ証明書及びメタデータ、ＣＳのＶ２ＧルートＣＡメタデータ、（必要に応じて）契約されたＥＭＳＰのルートＣＡ証明書、（必要に応じて）ＯＥＭのルートＣＡ証明書、ＣＳのＶ２ＧルートＣＡに発行されたクロス証明書及びメタデータ、クロス証明書のＶ２ＧルートＣＡメタデータ、及びルートマイグレーションクロス証明書が含まれてもよい。ＣＳＭＳから応答を受けると、ＣＳは受信されるＣＡ証明書を安全に格納する。

ＣＳが安全な動作のために複数のＣＡ証明書及び関連情報をアップデートするプロセスの他の実施形態は、ＣＳＭＳによってトリガーされてもよい。もしＣＳに設置しなければならないＣＡ証明書のいずれかに対するアップデートがＣＳＭＳにある場合、ＣＳＭＳは、全て又は一部のＣＳに対してアップデートする証明書の類型と、一定の類型の証明書データリストを送信することで、ＣＡ証明書のアップデートを要請する。アップデートする証明書の類型は、例えばＣＳＭＳのＶ２ＧルートＣＡ（ルートマイグレーション用）、ＣＳのＶ２ＧルートＣＡ（ルートマイグレーション用）、ＥＭＳＰのルートＣＡ、ＯＥＭのルートＣＡ、ＣＳのＶ２ＧルートＣＡに発行されたクロス証明書、クロス証明書のＶ２ＧルートＣＡ、ルートマイグレーションクロス証明書が挙げられる。ＣＳＭＳから要請を受けると、ＣＳは、受信された証明書データを過度な遅延なく設置してアップデートタイムスタンプをアップデートする。

上記のような証明書アップデート過程において、ＣＳＭＳは、アップデート／時間タグ付きＣＡ証明書データ（証明書、ＤＮ、一連番号、ハッシュ）に対するデータベースを保持してもよい。またＥＶとＣＳは、ＰｎＣ識別方法でＩＳＯ１５１１８を通じて通信する。一方、ＣＰＳ／ＣＣＰは、証明書チェーン（設置用ＯＥＭプロビジョニング証明書チェーン及びアップデート用契約証明書チェーン）を検証し、設置のためのＯＥＭプロビジョニング証明書チェーン及びアップデートのための契約証明書チェーンにある各証明書の失効有無を確認する。

一方、アップデートのための証明書を受信すると、ＣＳは、ＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｑ及びＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｑメッセージの署名を確認する。次いで、ＣＳはデータ、すなわちＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｑ又はＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｑメッセージ（ありのまま）、ＰＣＩＤ（設置用）又はｅＭＡＩＤ（アップデート用）、メッセージのＩＳＯ １５１１８ スキーマバージョン、（ＩＳＯ１５１１８制限時間による）検索（ｒｅｔｒｉｅｖａｌ）期限、ＥＶが信頼するＶ２ＧルートＣＡ証明書リストをＣＳＭＳに送信する。上記データを受信すると、ＣＳＭＳは、補助関与者に契約証明書を要請し、受信された情報をＣＳに再度伝達する。複数の契約証明書が受信されると、ＣＳＭＳは、受信完了をＣＳに表示することが好ましい。契約証明書が受信されていない場合、ＣＳＭＳはＣＳにエラーメッセージ（例えば「ＮＯ＿ＣＯＮＴＲＡＣＴ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＦＯＵＮＤ」）を表示する。ＩＳＯ１５１１８－２標準に準拠した場合、ＣＳは、ＣＳＭＳから受信したＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｓ又はＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｓ ＳｅｓｓｉｏｎＩＤが満たされた状態でＥＶに伝達する。一方、ＩＳＯ １５１１８－２０標準に準拠した場合、ＣＳは、受信された各ＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｓを修正するか、又はＣＳＭＳで受信した各情報に対してＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｓメッセージを生成して、メッセージがＳｅｓｓｉｏｎＩＤ、ＥＶＳＥＰｒｏｃｅｓｓｉｎｇ、ＲｅｍａｉｎｉｎｇＣｅｒｔｓ、ＥＶＳＥＳｔａｔｕｓ及びＲｅｓｐｏｎｓｅＣｏｄｅ要素に正しい値を含めるようにする。

図１４は、本発明の一実施形態において、ホームＣＳＰから間接ローミングを通じてＥＶに伝達して設置される契約証明書の伝達経路を示す図である。

本実施形態において、ホームＣＰＳに格納されている契約証明書をＥＶに設置するか、又はＥＶにある既存の証明書をこの証明書にアップデートしなければならないと仮定する。現在ＥＶは、訪問ＣＳＰのネットワークに属する訪問ＣＳＯに接続されたＣＳを訪問した状態である。しかし、もしホームＣＳＰと訪問ＣＳＰとがクリアリングハウスを介する間接ローミング契約関係にある場合、ＥＶは、クリアリングハウスを経由する間接ローミングによってホームＣＰＳに格納されている契約証明書を設置するか、又は既存の証明書をこの証明書にアップデートできるようになる。

図１５は、図１４に示された証明書の伝達過程をより詳しく示すフローチャートである。図１５に示す実施形態は、証明書を先制的にＣＳＰに格納しておく過程で、訪問ＣＳＰとホームＣＳＰとが直接通信するのでなく、クリアリングハウスを介して通信する点で異なる。

先ず、ＥＶの所有者とホームＣＳＰの運営者とは充電サービス契約を締結する（第８００ステップ）。契約締結後に、ホームＣＳＰは、ＥＶに対する契約証明書を生成する（第８０２ステップ）。生成された証明書は、ＥＶの公開鍵と、公開鍵のハッシュと、ハッシュをＭＯルートＣＡの中間ＣＡ（ＭＯ Ｓｕｂ １又はＭＯ Ｓｕｂ ２）の個人鍵で暗号化した署名値などを含む。生成された証明書は、該当ホームＣＳＰとローミング契約が締結されている全ての訪問ＣＳＰに配布されてもよい（第８０４ステップ～第８０８ステップ）。

例示的な実施形態において、第８００ステップないし第８０８ステップは、ＥＶがＣＳを通じて訪問ＥＳＯに証明書設置要請メッセージ（ＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｑ）又は証明書アップデート要請メッセージ（ＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｑ）を送信する前に先制的に行われてもよい。すなわち、ＥＶが訪問ＣＳＰに証明書の設置又はアップデートを要請すると、これを支援できるように、ホームＣＳＰは、契約関係にある全ての訪問ＣＳＰに証明書設置パッケージを事前に配布して、訪問ＣＳＰが自身のＣＰＳにこれを格納できるようにする。このとき、追って即席ローミング（ｏｎ－ｔｈｅ－ｆｌｙ ｒｏａｍｉｎｇ）が形成される可能性を勘案して、現在の契約関係の有無にかかわらず、全てのＣＳＰに証明書設置パッケージを事前に配布してもよい。証明書設置パッケージは、契約証明書チェーンと、ｅＭＡＩＤアカウント情報を含み、証明書廃棄リスト（ＣＲＬ）とＯＣＳＰサーバの接続情報をさらに含んでもよい。ＣＳＰ間の証明書パッケージの伝達は直接行われてもよく、後述のようにクリアリングハウスを介して行われてもよい。

より具体的に説明すると、第８０４ステップでホームＣＳＰが契約証明書を生成すると、該当証明書パッケージを含む証明書設置応答メッセージ（ＣｅｒｔｉｆｉｃａｔｅＩｎｓｔａｌｌａｔｉｏｎＲｅｓ）又は証明書アップデート応答メッセージ（ＣｅｒｔｉｆｉｃａｔｅＵｐｄａｔｅＲｅｓ）が、ホームＣＳＰと契約関係にある全ての訪問ＣＳＰにセキュリティチャネルを通じて配布される。このとき、ホームＣＳＰ又はクリアリングハウスは、契約証明書チェーンを検証し、契約証明書チェーンの失効状態を確認し、ｅＭＡＩＤアカウント状態を確認し、契約がサービスに対して承認可能なものであるかを確認する。確認の結果、契約証明書チェーン、ｅＭＡＩＤアカウント、及び契約内容に何らの問題がないと、証明書パッケージが全ての訪問ＣＳＰに配布される。配布が完了すると、ホームＣＳＰは、証明書チェーンの状態コードと、アカウント及び権限に対する結果コードとをクリアリングハウスに送信する。この配布プロセスのために、ホームＣＳＰは、直接ローミング契約がある訪問ＣＳＰが１つ以上あれば、そのような訪問ＣＳＰのリストを備える。また、ホームＣＳＰは、証明書の設置のためのローミング契約があるクリアリングハウスが１つ以上あれば、そのようなクリアリングハウスのリストを備える。証明書パッケージの配布のための通信は、ローミングエンドポイントを超えて行われてもよい。一方、証明書設置パッケージを受けると、訪問ＣＳＰは、自身のユーザに対する証明書を発行する場合と同一の手続きを通じて、該当パッケージを自身のＣＰＳに配布する。

その後、ＥＶが証明書の設置又はアップデートを要請すると、訪問ＣＳＯは、訪問ＣＰＳから証明書設置パッケージを持ってきてＥＶに伝達する。この際の設置又はアップデートプロセスは、非ローミング状況とローミング状況との間に差異がなくてもよい。図１４の第８２０ステップないし第８３６ステップはこの過程を示す。

具体的に、第８２０ステップにおいて、ＥＶは、ＣＳに対して証明書の設置又はアップデート要請メッセージ（Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｑ）を送信する。証明書設置要請メッセージの場合、ＥＶは、ＩＳＯ １５１１８標準に準拠した通信によって充電ステーション（ＣＳ）にＯＥＭプロビジョニング証明書チェーンを送信する。一方、証明書更新要請メッセージには契約証明書チェーンが含まれてもよい。証明書の設置又はアップデート要請メッセージ（Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｑ）を受信すると、ＣＳは、要請メッセージにあるメッセージ署名値を確認する（第８２２ステップ）。このとき、ＣＳは、要請メッセージに含まれた署名値を公開鍵で復号化してハッシュを復元した後、復元されたハッシュを要請メッセージに含まれているハッシュと比較することで、メッセージ署名値を確認する。

その後、ＣＳは、受信された証明書チェーンを検証する（第８２４ステップ）。すなわち、証明書の設置の場合、ＯＥＭプロビジョニング証明書チェーンを上述の方式で検証し、証明書のアップデートの場合、契約証明書チェーンを検証する。次いで、ＣＳは、証明書の設置又はアップデート要請メッセージ（Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｑ）を訪問ＣＳＯに伝達する（第８２６ステップ）。また、訪問ＣＳＯは、上述の方式でＯＥＭプロビジョニング証明書チェーン又は契約証明書チェーンにある各証明書の失効有無を確認する（第８２８ステップ）。

訪問ＣＰＳは、第８０８ステップで格納された新しい契約証明書チェーンをＭＯルートＣＡ証明書に基づいて検証する（第８３０ステップ）。また訪問ＣＰＳは、新しい契約証明書チェーンにある各証明書の失効有無を確認する（第８３２ステップ）。証明書の未失効状態、すなわち有効性は、ＭＯルートＣＡから受信した証明書廃棄リスト（ＣＲＬ）を通じて確認してもよく、ＭＯルートＣＡに連携したＯＣＳＰサーバに証明書状態を要請し、照会結果を受信して確認してもよい。

確認の結果、新しい契約証明書チェーンが検証され、新しい契約証明書チェーン内にある各証明書の有効性に問題がない場合、訪問ＣＰＳは、新しい契約証明書パッケージを含んで証明書の設置／更新応答（すなわち、Ｃｅｒｔ｛Ｉｎｓ／Ｕｐｄ｝Ｒｅｓメッセージ）をＣＳに送信する（第８３４ステップ）。ＣＳは、新しい契約証明書パッケージを再度ＥＶに送信し、ＥＶで新しい証明書が設置又は更新される（第８３６ステップ）。

このように、ＣＳは、第８３４ステップで訪問ＣＰＳから受信したデータ、例えば契約証明書パッケージを第８３６ステップでＥＶに伝送するが、ＣＳが受信した全ての証明書データがＥＶに伝送されるわけではない。すなわち、ＣＳは、自身の必要に応じて証明書を受け入れて設置するか、または既存の格納されていた証明書を更新してもよい。また、ＣＳは、安全な動作のために複数のＣＡ証明書及び関連情報を保有する必要があり、複数のＣＡ証明書及び関連情報をアップデートしてもよい。本実施形態において、ＣＳが、自身が必要な証明書を設置又は更新するプロセスは、図１３に関する説明と類似するため、これに対する詳しい説明は省略する。

図１３と図１５において、訪問ＣＳＰとホームＣＳＰとは役割が互いに入れ替わってもよい点を留意しなければならない。さらに、あるＣＳＰが他のＣＳＰに対しては訪問ＣＳＰとして作用すると共に、また他のＣＳＰに対してはホームＣＳＰとして作用できるという点を考慮しなければならない。

図１６は、本発明の一実施形態において、契約によるサービスの承認過程を示すフローチャートである。

先ず、ＰｎＣ方法を通じてサービスに対する承認を受けようとするＥＶは、訪問ＣＳに承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）を送信する（第９００ステップ）。このとき、ＥＶは、ＩＳＯ １５１１８標準に準拠した通信によって契約証明書チェーンを充電ステーション（ＣＳ）に送信する。ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）に含まれた署名値をＥＶの公開鍵で復号化してハッシュを復元し、復元されたハッシュを承認要請メッセージに含まれたハッシュと比較することで、ＥＶの署名を確認する（第９０２ステップ）。

次いで、ＣＳは、承認要請メッセージ（ＡｕｔｈｏｒｉｚａｔｉｏｎＲｅｑ）に含まれた契約証明書チェーンとｅＭＡＩＤとを訪問ＣＳＯに伝達する（第９０４ステップ）。訪問ＣＳＯは、ＥＶと契約関係にあるＣＳＰが、自身が属しているネットワークの内部にあるか外部にあるかを判断する。また、訪問ＣＳＯは、ローミング支援を受けるために、ホームＣＳＰ又はクリアリングハウスに直接連絡する方法を確認する。次いで、訪問ＣＳＯは、ホームＣＳＰ又はクリアリングハウスに、ＥＶに関する情報を含む承認要請を送信する（第９０６ステップ）。ＥＶに関する情報は、ｅＭＡＩＤと、契約証明書チェーンとが含まれ、ＥＶの承認のためのサービスの説明がさらに含まれてもよい。もし第９０６ステップで訪問ＣＳＯが送信したＥＶに関する情報の目的地がクリアリングハウスである場合、クリアリングハウスは、ＥＶに関する情報を該当ホームＣＳＰに伝達する。

次いで、ホームＣＳＰは、事前に確保しているＭＯルートＣＡ証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）を含めて完全な契約証明書チェーンを確認し、契約証明書チェーンを検証する（第７０８ステップ）。契約証明書チェーンの検証は、ルート証明書（ＭＯ ＲｏｏｔＣＡ ｃｅｒｔ．）から中間ＣＡ証明書（ＭＯ ＳｕｂＣＡ １ ｃｅｒｔ、ＭＯ ＳｕｂＣＡ ２ ｃｅｒｔ）を経てリーフ証明書である契約証明書（Ｃｏｎｔｒａｃｔ Ｃｅｒｔｉｆｉｃａｔｅ）に至るまで、順に各証明書の所有者情報をその下位ＣＡの発行者情報と比較することで、各証明書の完全性と信頼性とを検証する。また、ホームＣＳＰは、契約証明書チェーンにある各証明書の失効有無を確認する（第９１０ステップ）。証明書の未失効状態、すなわち有効性は、ＭＯルートＣＡから受信した証明書廃棄リスト（ＣＲＬ）を通じて確認してもよく、ＭＯルートＣＡに連携したＯＣＳＰサーバに証明書状態を照会することで確認してもよい。さらに、ホームＣＳＰは、ｅＭＡＩＤアカウントの状態と、要請したサービスが契約上承認可能なものであるか否かに対してもさらに確認する（第９１２ステップ）。

確認結果によって、ホームＣＳＰは、契約証明書チェーンの状態を示す状態コードと、ＥＶアカウント及び権限に関する結果コードとを訪問ＣＳＯに返信する（第９１４ステップ）。状態コードは、例えば「問題なし（ＯＫ）」、「期限切れ（Ｅｘｐｉｒｅｄ）」、「キャンセル済み（Ｒｅｖｏｋｅｄ）」、「有効でない証明書チェーン（Ｉｎｖａｌｉｄ＿ｃｈａｉｎ）」、「不明なエラー（Ｕｎｋｏｗｎ＿ｅｒｒｏｒ）」のいずれかである。前記結果コードは、例えば「問題なし（ＯＫ）」、「存在しない契約（ＮＯ＿ＣＯＮＴＲＡＣＴ）」、「期限切れ契約（ＣＯＮＴＲＡＣＴ＿ＴＥＲＭＩＮＡＴＥＤ）」、「保留契約（ＣＯＮＴＲＡＣＴ＿ＳＵＳＰＥＮＤＥＤ）」、「未承認（ＮＯＴ＿ＡＵＴＨＯＲＩＺＥＤ）」、「不明なエラー（Ｕｎｋｏｗｎ＿ｅｒｒｏｒ）」のいずれかである。

訪問ＣＳＯは、認証結果をＣＳに通知し、ＣＳは、ＩＳＯ １５１１８標準に準拠した通信を通じて認証結果を再度ＥＶに通知する（第９１６ステップ、第９１８ステップ）。

このように、ＥＶと契約関係にあるＣＳＰが訪問ＣＳＯと直接ローミング契約関係にあるか、又はクリアリングハウスを介する間接ローミング契約関係にある場合、訪問ＣＳＯは、ホームＣＳＰと直接ＥＶの認証に必要な情報を交換するか、又はクリアリングハウスを経由して情報交換を行うことで、承認プロセスを行う。

一方、図１６は、本発明の一実施形態を例示しており、この実施形態は多様に変形されてもよい。例えば、変形された実施形態においては、メッセージ署名ステップ（第９０２ステップ）が、ＣＳでなく訪問ＣＳＯによって実行される。また、契約証明書チェーン検証ステップ（第９０８ステップ）は、ホームＣＳＰでなく訪問ＣＳＯ又はＣＳによって実行される。その他、図１６に示された実施形態は、ローミング状況によって図７ないし図１１に示されたように、各ステップの実行主体が変更されてもよい。

図１７は、本発明の一実施形態による充電サービス提供者（ＣＳＰ）（２２０）のブロック図である。本発明の一実施形態によるＣＳＰ（２２０）は、少なくとも１つのプロセッサ（１０２０）、メモリ（１０４０）、及び格納装置（１０６０）を含む。

プロセッサ（１０２０）は、メモリ（１０４０）及び／又は格納装置（１０６０）に格納されたプログラム命令を実行する。プロセッサ（１０２０）は、少なくとも１つの中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）やグラフィック処理装置（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）によって具現され、その他本発明による方法を行うことができるその他プロセッサであってもよい。

メモリ（１０４０）は、例えばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）のような揮発性メモリと、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような不揮発性メモリとを含んでもよい。メモリ（１０４０）は、格納装置（１０６０）に格納されたプログラム命令をロードして、プロセッサ（１０２０）に提供する。

格納装置（１０６０）は、プログラム命令とデータの格納に適した記録媒体であり、例えば、ハードディスク、フロッピーディスク（登録商標）、及び磁気テープのような磁気媒体（Ｍａｇｎｅｔｉｃ Ｍｅｄｉａ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｋ）のような光記録媒体（Ｏｐｔｉｃａｌ Ｍｅｄｉａ）、フロプティカルディスク（Ｆｌｏｐｔｉｃａｌ Ｄｉｓｋ）のような磁気－光媒体（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ Ｍｅｄｉａ）、フラッシュメモリやＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、又はこれらに基づいて製作されるＳＳＤのような半導体メモリを含んでもよい。

格納装置（１０６０）はプログラム命令を格納する。特に、プログラム命令は、本発明による証明書の設置支援のためのプログラム命令を含む。証明書の設置支援のためのプログラム命令は、第１ＥＶに対する第１契約証明書を生成し、第１契約証明書を第１外部ＣＳＰに伝送して、第１外部ＣＳＰを介して第１契約証明書が第１ＥＶに設置されるようにする命令と、第２ＥＶに対する第２契約証明書を第２外部ＣＳＰから受け入れ、ＣＰＳに伝達して格納させるようにする命令、及び第２ＥＶがサービスネットワークに進入したローミング状況で、第２ＥＶから契約証明書の設置要請が受信されると、ＣＰＳに格納された第２契約証明書が第２ＥＶに送信されるようにして第２ＥＶに設置されるようにする命令を含む。さらに、ワイヤレス電力伝送のためのプログラム命令は、図１２に示されたプロセスを具現するのに必要な命令の少なくとも一部を含む。このようなプログラム命令は、プロセッサ（１０２０）の制御によってメモリ（１０４０）にロードされた状態で、プロセッサ（１０２０）によって実行されることで、本発明による方法を具現する。

上述したように、本発明の実施形態による装置と方法は、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なプログラム又はコードとして具現される。コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取られるデータが格納されるあらゆる種類の記録装置を含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークで連結されたコンピュータシステムに分散され、分散方式によりコンピュータで読み取り可能なプログラム又はコードが格納されて実行されてもよい。

コンピュータで読み取り可能な記録媒体は、ＲＯＭ、ＲＡＭ、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）などのように、プログラム命令を格納して行うように特に構成されたハードウェア装置を含んでもよい。プログラム命令は、コンパイラ（ｃｏｍｐｉｌｅｒ）によって作われるもののような機械語コードだけでなく、インタプリタ（ｉｎｔｅｒｐｒｅｔｅｒ）などを用いてコンピュータによって実行できる高級言語コードを含んでもよい。

本発明の一部の側面は装置の文脈から説明したが、それは対応する方法による説明を示すこともでき、ここでブロック又は装置は、方法ステップ又は方法ステップの特徴に対応する。同様に、方法の文脈から説明された側面は、さらに対応するブロック又はアイテム又は対応する装置の特徴として示すことができる。方法ステップの一部又は全部は、例えば、マイクロプロセッサ、プログラム可能なコンピュータ又は電子回路のようなハードウェア装置によって（又は用いて）行われる。いくつかの実施形態において、最も重要な方法ステップの１つ以上は、このような装置によって行われてもよい。

実施形態において、プログラム可能なロジック装置（例えば、フィールドプログラマブルゲートアレイ）が、本明細書で説明された方法の機能の一部又は全部を行うために使用されてもよい。実施形態において、フィールドプログラマブルゲートアレイは、本明細書で説明された方法のいずれかを行うためのマイクロプロセッサと共に動作してもよい。一般に、方法は、あるハードウェア装置によって行われることが好ましい。

以上で、本発明の好ましい実施形態を参照して説明してきたが、該当技術分野の熟練した当業者であれば、本発明の思想及び技術範囲から逸脱しない範囲内で本発明を多様に修正及び変更可能なことを理解することができるであろう。

１０ 電気自動車（ＥＶ）
１１ 受信パッド
１２ バッテリー
２０ 充電ステーション
２１ 送信パッド
３０ 充電ケーブル
３１ 充電コネクタ
３２ インケーブルコントロールボックス
３３ コンセントソケット接続部
４０ 電力ソケット
５０ （商用）電力網
１０２０ プロセッサ
１０４０ メモリ
１０６０ 格納装置

Claims (13)

1. 充電サービス提供者（ＣＳＰ）が、前記ＣＳＰと契約関係にある第１電気自動車（ＥＶ）に対する第１契約証明関連情報を提供するステップと、
   前記ＣＳＰが、前記第１契約証明関連情報を前記ＣＳＰと直接又は間接的にローミング契約が形成されている第１訪問充電ステーション運営者（ＣＳＯ）に伝達されるように前記第１訪問ＣＳＯと連結された第１外部ＣＳＰに伝送するステップと、
   前記第１訪問ＣＳＯが、前記第１ＥＶがサービスネットワークに進入した状況で前記第１ＥＶから第１訪問契約証明関連情報を含む充電承認要請を受信するステップと、
   前記第１訪問ＣＳＯが、前記第１訪問契約証明関連情報を検証するステップと、
   を含むことを特徴とする電気自動車契約の識別方法。
2. 前記第１訪問ＣＳＯが、前記第１訪問契約証明関連情報に基づいて前記第１ＥＶと契約関係にある前記ＣＳＰを認識するステップをさらに含むことを特徴とする請求項１に記載の電気自動車契約の識別方法。
3. 前記第１外部ＣＳＰが、前記第１ＥＶと契約関係がなく前記ＣＳＰとはローミング契約関係にある全ての外部ＣＳＰを含むことを特徴とする請求項１に記載の電気自動車契約の識別方法。
4. 前記第１訪問ＣＳＯが、前記第１ＥＶが前記サービスネットワークに進入した状況で、前記第１契約証明関連情報に含まれる第１契約証明書が前記第１ＥＶに設置されるか、又はアップデートされるように前記第１契約証明書を前記第１ＥＶに伝送するステップをさらに含むことを特徴とする請求項１に記載の電気自動車契約の識別方法。
5. 前記第１契約証明関連情報を前記第１外部ＣＳＰに伝送するステップが、
   前記第１契約証明関連情報に含まれる第１契約証明書を含む契約証明書チェーンと、ｅＭＡＩＤ情報とを含む証明書設置パッケージを形成するステップと、
   前記証明書設置パッケージを前記第１外部ＣＳＰに伝送するステップと、
   を含むことを特徴とする請求項１に記載の電気自動車契約の識別方法。
6. 前記証明書設置パッケージが、前記第１契約証明書に関連する証明書廃棄リストと、オンライン証明書状態プロトコル（ＯＣＳＰ）サーバの接続情報を含むことを特徴とする請求項５に記載の電気自動車契約の識別方法。
7. プロセッサと、
   前記プロセッサによって実行される少なくとも１つの命令を格納するメモリと、を含み、
   前記プロセッサは、前記少なくとも１つの命令によって、
   自身と契約関係にある第１電気自動車（ＥＶ）に対する第１契約証明関連情報を提供し、自身とローミング契約が形成されている第１外部充電サービス提供者（ＣＳＰ）を経由して前記第１契約証明関連情報が前記第１ＥＶが進入したネットワーク上の第１訪問充電ステーション運営者（ＣＳＯ）に伝達されることができるように前記第１契約証明関連情報を第１外部ＣＳＰに伝送し、
   自身と契約関係のない第２ＥＶに対する第２契約証明関連情報を第２外部ＣＳＰから受け入れることを特徴とする充電サービス提供者（ＣＳＰ）装置。
8. 前記第１外部ＣＳＰが、自身とローミング契約が成立している全ての外部ＣＳＰを含み、
   前記第２外部ＣＳＰが、自身とローミング契約が成立している前記全ての外部ＣＳＰのうちのいずれか１つであることを特徴とする請求項７に記載の充電サービス提供者（ＣＳＰ）装置。
9. 前記第１外部ＣＳＰは、前記第１ＥＶと契約関係がなく、
   前記第２外部ＣＳＰは、前記第２ＥＶと契約関係にあることを特徴とする請求項７に記載の充電サービス提供者（ＣＳＰ）装置。
10. 前記第１契約証明関連情報を前記第１外部ＣＳＰに伝送する時、
    前記第１契約証明関連情報を前記第１外部ＣＳＰに伝送してから所定の期間が経過するか、又は前記第１契約証明関連情報が前記第１ＥＶに設置されると、前記第１外部ＣＳＰに設置待機解除要請を送信することを特徴とする請求項７に記載の充電サービス提供者（ＣＳＰ）装置。
11. 前記第２契約証明関連情報が証明書プロビジョニングサービス装置（ＣＰＳ）に格納されるように前記ＣＰＳに伝達し、
    前記第２契約証明関連情報が前記ＣＰＳまたは充電ステーション（ＣＳ）によって前記第２ＥＶに設置された後に、前記第２外部ＣＳＰに設置完了を通知することを特徴とする請求項７に記載の充電サービス提供者（ＣＳＰ）装置。
12. 前記第１契約証明関連情報を前記第１外部ＣＳＰに伝送する場合に、
    第１契約証明書を含む契約証明書チェーンと、ｅＭＡＩＤ情報とを含む証明書設置パッケージを形成し、
    前記証明書設置パッケージを前記第１外部ＣＳＰに伝送することを特徴とする請求項７に記載の充電サービス提供者（ＣＳＰ）装置。
13. 前記証明書設置パッケージが、前記第１契約証明書に関連する証明書廃棄リストと、オンライン証明書状態プロトコル（ＯＣＳＰ）サーバの接続情報を含むことを特徴とする請求項１２に記載の充電サービス提供者（ＣＳＰ）装置。

Images