(57)【要約】  デバイスの事業者に変更があった場合にも、デバイス設置後の更新を行うことなく、事業者を特定する。  情報処理装置は、受信部および特定部を備える。受信部は、周囲環境を測定するセンシングデバイス（ＩｏＴデバイス）から、仮想事業者を宛先とするセンシング情報を受信する。特定部は、記憶部に問い合わせてセンシング情報に対応する実事業者の実事業者識別情報を特定する。記憶部は、仮想事業者を識別する仮想事業者識別情報と、実事業者を識別する実事業者識別情報とを、関連付けて記憶する。
2019142428.tif 000002
【特許請求の範囲】
【請求項１】
周囲環境を測定するセンシングデバイスから仮想事業者を宛先とするセンシング情報を受信する受信部と、
前記仮想事業者を識別する仮想事業者識別情報と実事業者を識別する実事業者識別情報とを関連付けて記憶する記憶部に問い合わせて前記センシング情報に対応する前記実事業者識別情報を特定する特定部と
を具備する情報処理装置。
【請求項２】
前記特定部は、前記特定された実事業者識別情報に基づいて前記センシング情報を送信する
請求項１記載の情報処理装置。
【請求項３】
前記センシングデバイスに固有の鍵情報を用いて前記仮想事業者を認証する認証部をさらに具備し、
前記受信部は、前記センシング情報とともに前記鍵情報を受信し、
前記特定部は、前記認証部における認証に成功した場合に前記特定された実事業者識別情報に基づいて前記センシング情報を送信する
請求項１記載の情報処理装置。
【請求項４】
前記特定部は、前記センシングデバイスに対して前記特定された実事業者識別情報を送信する
請求項１記載の情報処理装置。
【請求項５】
前記センシングデバイスに固有の鍵情報を用いて前記仮想事業者を認証する認証部をさらに具備し、
前記受信部は、前記鍵情報を受信し、
前記特定部は、前記認証部における認証に成功した場合に前記センシングデバイスに対して前記特定された実事業者識別情報および認証成功情報を送信し、
前記認証部は、前記センシングデバイスから前記センシング情報とともに前記認証成功情報を受け取るとそのセンシング情報を認証する
請求項１記載の情報処理装置。
【請求項６】
前記実事業者識別情報は、前記実事業者のＵＲＬアドレスである
請求項１記載の情報処理装置。
【請求項７】
前記記憶部において前記仮想事業者識別情報に関連付けて記憶される前記実事業者識別情報を変更して、他の実事業者を識別する他事業者識別情報に切り替える切替部をさらに具備する請求項１記載の情報処理装置。
【請求項８】
前記切替部は、前記他事業者からの要求に応じて前記他事業者識別情報への切替えを行う
請求項７記載の情報処理装置。
【請求項９】
前記切替部は、前記実事業者および前記他事業者の協調に従って前記他事業者識別情報への切替えを行う
請求項７記載の情報処理装置。
【請求項１０】
前記切替部は、前記記憶部において前記仮想事業者識別情報に関連付けて記憶される前記実事業者識別情報を変更して、無効化状態に切り替える
請求項７記載の情報処理装置。
【請求項１１】
前記記憶部をさらに具備する請求項１記載の情報処理装置。
【請求項１２】
周囲環境を測定するセンシングデバイスから仮想事業者を宛先とするセンシング情報を受信する受信手順と、
前記仮想事業者を識別する仮想事業者識別情報と実事業者を識別する実事業者識別情報とを関連付けて記憶する記憶部に問い合わせて前記センシング情報に対応する前記実事業者識別情報を特定する特定手順と
を具備する情報処理装置の処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置に関する。詳しくは、デバイスからの情報の送信先を決定する情報処理装置およびその処理方法に関する。
【背景技術】
【０００２】
ＩｏＴ（Internet of Things）時代の到来により、無線通信機能を備えたＩｏＴデバイスが急速に普及している。ＩｏＴデバイスの中には、設置場所によっては回収が困難なものや、回収コストに見合わないものが想定される。場合によっては、デバイスを回収せずに、別事業者に譲渡するようなケースがあり得る。ＩｏＴデバイスが事業者の認証機能を有する場合、譲渡先の事業者を認識するようにデバイスを更新する必要があるが、デバイス認証の多くはセキュリティの特性上、製造時に埋め込まれた証明書などに依るところが大きく、設置後に更新することが難しい。そこで、電子証明書の複数種類を一括管理して、指定された電子証明書により認証を行う装置が提案されている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−０２０５３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述の従来技術では、一括管理される複数種類の電子証明書から指定して認証を行うことができる。しかしながら、予め想定される電子証明書を全て登録しておくには保存領域の容量が増大するおそれがあり、また、設置前に想定していなかった事業者に譲渡するような場合には対応できないという問題がある。【０００５】
本技術はこのような状況に鑑みて生み出されたものであり、デバイスの事業者に変更があった場合にも、デバイス設置後の更新を行うことなく、事業者を特定することを目的とする。
【課題を解決するための手段】
【０００６】
本技術は、上述の問題点を解消するためになされたものであり、その第１の側面は、周囲環境を測定するセンシングデバイスから仮想事業者を宛先とするセンシング情報を受信する受信部と、上記仮想事業者を識別する仮想事業者識別情報と実事業者を識別する実事業者識別情報とを関連付けて記憶する記憶部に問い合わせて上記センシング情報に対応する上記実事業者識別情報を特定する特定部とを具備する情報処理装置およびその処理方法である。これにより、センシングデバイスを更新することなく、仮想事業者から実事業者を特定するという作用をもたらす。【０００７】
また、この第１の側面において、上記特定部は、上記特定された実事業者識別情報に基づいて上記センシング情報を送信するようにしてもよい。これにより、実事業者に対する送信を仲介するという作用をもたらす。【０００８】
また、この第１の側面において、上記センシングデバイスに固有の鍵情報を用いて上記仮想事業者を認証する認証部をさらに具備し、上記受信部は、上記センシング情報とともに上記鍵情報を受信し、上記特定部は、上記認証部における認証に成功した場合に上記特定された実事業者識別情報に基づいて上記センシング情報を送信するようにしてもよい。これにより、認証成功時に実事業者に対する送信を仲介するという作用をもたらす。【０００９】
また、この第１の側面において、上記特定部は、上記センシングデバイスに対して上記特定された実事業者識別情報を送信するようにしてもよい。これにより、実事業者に対する送信に必要な情報を提供するという作用をもたらす。【００１０】
また、この第１の側面において、上記センシングデバイスに固有の鍵情報を用いて上記仮想事業者を認証する認証部をさらに具備し、上記受信部は、上記鍵情報を受信し、上記特定部は、上記認証部における認証に成功した場合に上記センシングデバイスに対して上記特定された実事業者識別情報および認証成功情報を送信し、上記認証部は、上記センシングデバイスから上記センシング情報とともに上記認証成功情報を受け取るとそのセンシング情報を認証するようにしてもよい。これにより、認証成功時に、実事業者に対する送信に必要な情報を提供するという作用をもたらす。【００１１】
また、この第１の側面において、上記実事業者識別情報は、上記実事業者のＵＲＬアドレスであってもよい。これにより、実事業者の運用するサーバ等にアクセスするという作用をもたらす。【００１２】
また、この第１の側面において、上記記憶部において上記仮想事業者識別情報に関連付けて記憶される上記実事業者識別情報を変更して、他の実事業者を識別する他事業者識別情報に切り替える切替部をさらに具備してもよい。これにより、センシングデバイスを更新することなく、事業者を切り替えるという作用をもたらす。【００１３】
また、この第１の側面において、上記切替部は、上記他事業者からの要求に応じて上記他事業者識別情報への切替えを行うようにしてもよい。これにより、譲渡先の事業者からの要求に応じて事業者を切り替えるという作用をもたらす。【００１４】
また、この第１の側面において、上記切替部は、上記実事業者および上記他事業者の協調に従って上記他事業者識別情報への切替えを行うようにしてもよい。これにより、譲渡当事者の協調に従って事業者を切り替えるという作用をもたらす。【００１５】
また、この第１の側面において、上記切替部は、上記記憶部において上記仮想事業者識別情報に関連付けて記憶される上記実事業者識別情報を変更して、無効化状態に切り替えるようにしてもよい。これにより、センシングデバイスを更新することなく、無効化するという作用をもたらす。【００１６】
また、この第１の側面において、情報処理装置が上記記憶部をさらに具備してもよい。これにより、事業者識別情報を一括管理するという作用をもたらす。
【発明の効果】
【００１７】
本技術によれば、デバイスの事業者に変更があった場合にも、デバイス設置後の更新を行うことなく、事業者を特定することができるという優れた効果を奏し得る。なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１８】
【図１】本技術の実施の形態におけるトラストプロキシサーバモデルによるシステムの全体構成の一例を示す図である。
【図２】本技術の実施の形態におけるトラストプロキシサーバ２００の第１の構成例を示す図である。
【図３】本技術の実施の形態におけるトラストプロキシサーバ２００の第２の構成例を示す図である。
【図４】本技術の実施の形態における運用前の処理の流れの一例を示すシーケンス図である。
【図５】本技術の実施の形態における運用時の処理の流れの一例を示すシーケンス図である。
【図６】本技術の実施の形態における譲渡に伴う処理の流れの第１の例を示すシーケンス図である。
【図７】本技術の実施の形態における譲渡に伴う処理の流れの第２の例を示すシーケンス図である。
【図８】本技術の実施の形態における譲渡に伴う処理の流れの第３の例を示すシーケンス図である。
【図９】本技術の実施の形態において仮想事業者Ｘのバインディング先が事業者Ａから事業者Ｂに変更された状態の一例を示す図である。
【図１０】本技術の実施の形態におけるトラストクライアントサーバモデルによるシステムの全体構成の一例を示す図である。
【図１１】本技術の実施の形態におけるデバイス製造の流れの第１の例を示す図である。
【図１２】本技術の実施の形態におけるデバイス製造の流れの第２の例を示す図である。
【図１３】本技術の実施の形態においてデバイス１００から送信されるメッセージの一例を示す図である。
【図１４】本技術の実施の形態におけるデバイス１００の紐付け無効化の一例を示す図である。
【図１５】本技術の実施の形態におけるデバイス１００の仮想事業者Ｘへの紐付けを回収業者Ｃに変更する場合の例を示す図である。
【発明を実施するための形態】
【００１９】
以下、本技術を実施するための形態（以下、実施の形態と称する）について説明する。説明は以下の順序により行う。
１．システム構成（トラストプロキシサーバモデル）
２．動作
３．変形例（トラストクライアントサーバモデル）
４．デバイスの製造
５．デバイスのリボーク
６．デバイスの回収
【００２０】
＜１．システム構成＞
［全体構成］
図１は、本技術の実施の形態におけるトラストプロキシサーバモデルによるシステムの全体構成の一例を示す図である。
【００２１】
このシステムでは、デバイス１００から送信された情報を利用して事業を行う事業者Ａを想定する。一方、デバイス１００におけるデバイス鍵ペアの管理主体として、事業者Ａとは異なる第三者であるトラスト事業者を想定する。このシステムでは、デバイス１００と、トラストプロキシサーバ２００と、事業者情報データベース３００と、事業者Ａサーバ５００とを備える。
【００２２】
デバイス１００は、周囲環境を測定してセンシング情報を無線通信により送信するセンシングデバイス（ＩｏＴデバイス）である。１つ以上のデバイス１００が設置され、そのセンシング情報は、最終的には事業者Ａが受け取る。ただし、このデバイス１００が保持するデバイス鍵ペア１１０は、事業者Ａの鍵ではなく、バーチャルな仮想事業者Ｘの鍵である。すなわち、デバイス固有鍵の公開鍵証明書の主体者（Ｓｕｂｊｅｃｔ）欄には仮想事業者Ｘを識別する情報が含まれる。この仮想事業者Ｘのデバイス鍵ペア１１０は、セキュアストレージに書き込まれ、トラスト事業者によって管理される。したがって、事業者Ａは、デバイス鍵ペア１１０にアクセスすることはできない。
【００２３】
事業者情報データベース３００は、仮想事業者Ｘと事業者Ａとを紐付ける情報を記憶するデータベースである。具体的には、この事業者情報データベース３００は、デバイス１００の公開鍵証明書の主体者（Ｓｕｂｊｅｃｔ）欄の仮想事業者Ｘを識別する仮想事業者識別情報と、事業者Ａを識別する事業者Ａ識別情報とを関連付けて記憶する。これにより、デバイス証明書が事業者Ａにバインドされることになる。なお、事業者情報データベース３００は、特許請求の範囲に記載の記憶部の一例である。
【００２４】
トラストプロキシサーバ２００は、トラスト事業者によって管理されるプロキシサーバである。このトラストプロキシサーバ２００は、デバイス固有鍵の公開鍵証明書を検証するための公開鍵セットとして、ＣＡ／ルート証明書２３０を記憶する。このＣＡ／ルート証明書２３０は、ＰＫＩ（Public Key Infrastructure）の３段のトラストチェーンを想定して、中間局とルートの２段のＣＡ（Certification Authority：認証局）証明書を記憶する。
【００２５】
デバイス１００は、センシング情報を送信する際に、デバイス鍵ペア１１０の秘密鍵を利用して署名を計算し、その署名値をデバイス鍵ペア１１０の公開鍵と一緒に送付する。トラストプロキシサーバ２００は、送られてきた公開鍵をＣＡ／ルート証明書２３０によって検証し、仮想事業者Ｘのデバイスのものであることを確認する。また、検証済みの公開鍵を利用して署名を検証し、改ざんされていないことを確認する。これらを確認した後、トラストプロキシサーバ２００は、事業者情報データベース３００に問い合わせて、センシング情報に対応する実際の事業者Ａの事業者Ａ識別情報を特定する。この例では、トラストプロキシサーバ２００は、事業者Ａが運用する事業者Ａサーバ５００のＵＲＬ（Uniform Resource Locator）アドレスを取得して、事業者Ａサーバ５００にセンシング情報を送信する。なお、トラストプロキシサーバ２００は、特許請求の範囲に記載の情報処理装置の一例である。
【００２６】
事業者Ａサーバ５００は、事業者Ａが運用するサーバである。この事業者Ａサーバ５００は、センシング情報を受信して、ビジネスロジック５１０によりセンシング結果のデータを蓄積し、分析するなどの処理を行う。
【００２７】
［トラストプロキシサーバ］
図２は、本技術の実施の形態におけるトラストプロキシサーバ２００の第１の構成例を示す図である。
【００２８】
このトラストプロキシサーバ２００は、受信部２１０と、認証部２２０と、ＣＡ／ルート証明書２３０と、特定部２４０と、切替部２６０とを備える。
【００２９】
受信部２１０は、デバイス１００からのメッセージを受信するものである。このデバイス１００からのメッセージには、センシング情報、デバイス鍵ペア１１０の秘密鍵を利用した署名、および、デバイス鍵ペア１１０の公開鍵が含まれる。これらのメッセージは、認証部２２０に供給される。
【００３０】
認証部２２０は、デバイス１００からのメッセージを認証するものである。すなわち、認証部２２０は、デバイス１００から送られてきた公開鍵をＣＡ／ルート証明書２３０によって検証し、仮想事業者Ｘのデバイスのものであることを確認する。また、認証部２２０は、検証済みの公開鍵を利用して署名を検証し、改ざんされていないことを確認する。これらが確認されると、認証部２２０は、その旨を特定部２４０に伝える。
【００３１】
特定部２４０は、センシング情報に対応する実際の事業者Ａの事業者Ａ識別情報を特定するものである。この特定部２４０は、認証部２２０から仮想事業者Ｘの仮想事業者識別情報を受け取り、これを用いて事業者情報データベース３００に問合せを行う。事業者情報データベース３００は、仮想事業者Ｘの仮想事業者識別情報に関連付けて記憶される事業者Ａ識別情報を特定部２４０に供給する。これにより、特定部２４０は、事業者Ａの事業者Ａ識別情報を特定することができる。
【００３２】
このトラストプロキシサーバ２００においては、事業者Ａ識別情報を特定した特定部２４０は、事業者Ａが運用する事業者Ａサーバ５００のＵＲＬアドレスを取得して、事業者Ａサーバ５００にセンシング情報を送信する。なお、後述のトラストサーバ２０１においても基本的な構造は同様であるが、その場合の特定部２４０は、事業者Ａ識別情報をデバイス１００に送信する。
【００３３】
切替部２６０は、事業者を切り替えるものである。すなわち、この切替部２６０は、事業者情報データベース３００において仮想事業者Ｘの仮想事業者識別情報に関連付けて記憶される事業者識別情報を変更する。これにより、紐付けられる事業者を切り替えることができる。
【００３４】
図３は、本技術の実施の形態におけるトラストプロキシサーバ２００の第２の構成例を示す図である。
【００３５】
上述のトラストプロキシサーバ２００の第１の構成例では、トラストプロキシサーバ２００の外部に事業者情報データベース３００が配置されていたが、この第２の構成例では、トラストプロキシサーバ２００の内部のメモリ等に、事業者情報データベース３００を記憶するように構成される。それ以外の点については、上述の第１の構成例と同様である。
【００３６】
＜２．動作＞
［運用前］
図４は、本技術の実施の形態における運用前の処理の流れの一例を示すシーケンス図である。
【００３７】
デバイス１００を用いた事業を行う事業者Ａ１０は、トラスト事業者２０に対してデバイス製造依頼を行う（７１１）。このデバイス製造依頼に応じて、トラスト事業者２０は、仮想事業者Ｘを生成する（７１２）。すなわち、主体者（Ｓｕｂｊｅｃｔ）欄に仮想事業者Ｘを識別する情報を含む公開鍵証明書を作成する。また、トラスト事業者２０は、デバイス１００を認証するためのＣＡ／ルート証明書を生成する（７１３）。
【００３８】
そして、トラスト事業者２０は、トラストプロキシサーバ２００に対して、デバイス１００を利用するためのプロビジョニングを行う（７１４）。すなわち、トラスト事業者２０は、仮想事業者Ｘに事業者Ａを紐付けるように整備を行うとともに、生成したＣＡ／ルート証明書をＣＡ／ルート証明書２３０として記憶させる。
【００３９】
そして、トラスト事業者２０は、デバイス鍵ペアを生成して（７１５）、デバイス鍵ペア１１０としてデバイス１００に書込みを行う（７１６）。この作業（７１５、７１６）は、デバイス１００の個数分、繰り返し行われる。
【００４０】
これらの処理が完了すると、トラスト事業者２０は事業者Ａ１０にデバイス製造の完了を報告する（７１７）。
【００４１】
［運用時］
図５は、本技術の実施の形態における運用時の処理の流れの一例を示すシーケンス図である。
【００４２】
設置されたデバイス１００は、所定の頻度によりメッセージを送信する（７２１）。このメッセージには、センシング情報、デバイス鍵ペア１１０の秘密鍵を利用した署名、および、デバイス鍵ペア１１０の公開鍵が含まれる。
【００４３】
デバイス１００からのメッセージを受信したトラストプロキシサーバ２００は、認証を行う（７２２）。すなわち、デバイス１００から送られてきた公開鍵をＣＡ／ルート証明書２３０によって検証し、仮想事業者Ｘのデバイスのものであることを確認する。また、検証済みの公開鍵を利用して署名を検証し、改ざんされていないことを確認する。
【００４４】
これらが確認されると、トラストプロキシサーバ２００は、仮想事業者Ｘのバインディングを解決する（７２３）。すなわち、トラストプロキシサーバ２００は、事業者情報データベース３００に問い合わせて、センシング情報に対応する実際の事業者Ａの事業者Ａ識別情報を特定する。
【００４５】
事業者Ａ識別情報を特定したトラストプロキシサーバ２００は、事業者Ａ識別情報に基づいてセンシング情報を送信する（７２４）。例えば、事業者Ａ識別情報が事業者Ａサーバ５００のＵＲＬアドレスであれば、そのＵＲＬアドレスを用いて事業者Ａサーバ５００にセンシング情報を送信する。
【００４６】
その後、事業者Ａサーバ５００のビジネスロジック５１０において処理が行われる。その際、必要に応じてデバイス１００に対してレスポンスが返却される場合がある。例えば、ビジネスロジック５１０において推論エンジンによる認識処理が行われた際、デバイス１００に認識結果を知らせる場合が考えられる。また、デバイス１００からセンシング情報が送信される頻度を調整するために、事業者Ａサーバ５００からレスポンスにより指示する場合が考えられる。
【００４７】
［譲渡］
図６は、本技術の実施の形態における譲渡に伴う処理の流れの第１の例を示すシーケンス図である。この第１の例は、事業者間の契約に基づいて、トラスト事業者２０が事業者切替えを行う例である。
【００４８】
事業者Ａ１０と事業者Ｂ１１との間で、事業者Ａ１０から事業者Ｂ１１への事業の譲渡契約が結ばれ（７３１）、事業者Ｂ１１とトラスト事業者２０との間で、トラスト事業に関する委託契約が結ばれたもの（７３２）と想定する。この契約に従って、トラスト事業者２０は、事業者Ａ１０から事業者Ｂ１１への事業者切替えの操作を行う（７３３）。これにより、トラストプロキシサーバ２００における仮想事業者Ｘのバインディング先が、事業者Ａ１０から事業者Ｂ１１に変更される（７３４）。なお、実際には、事業者情報データベース３００において仮想事業者Ｘの仮想事業者識別情報に関連付けて記憶される情報が、切替部２６０によって、事業者Ａ識別情報から事業者Ｂ識別情報に変更される。
【００４９】
図７は、本技術の実施の形態における譲渡に伴う処理の流れの第２の例を示すシーケンス図である。この第２の例は、事業者間の契約に基づいて、事業者Ｂ１１が事業者切替えを要求する例である。
【００５０】
事業者Ａ１０と事業者Ｂ１１との間の事業者Ａ１０から事業者Ｂ１１への事業の譲渡契約（７４１）、および、事業者Ｂ１１とトラスト事業者２０との間のトラスト事業に関する委託契約（７４２）を前提とする点については、上述の第１の例と同様である。
【００５１】
事業者Ｂ１１は、事業者切替えのための認証トークンをトラスト事業者２０に要求する（７４３）。トラスト事業者２０は、事業者Ｂ１１を認証し、契約情報の確認を行う（７４４）。その結果、問題がなければ事業者の切替えを許可し、認証トークンの生成をトラストプロキシサーバ２００に要求する（７４５）。
【００５２】
認証トークンの生成要求に応じて、トラストプロキシサーバ２００は認証トークンを生成する（７４６）。トラスト事業者２０は、生成された認証トークンを事業者Ｂ１１に送信する（７４７）。
【００５３】
認証トークンを受け取った事業者Ｂ１１は、事業者Ｂ１１に切り替えるための事業者切替要求を認証トークンとともにトラストプロキシサーバ２００に送信する（７４８）。この事業者切替要求を受け取ったトラストプロキシサーバ２００は、事業者Ｂ１１からの認証トークンを確認して、問題がなければ仮想事業者Ｘのバインディング先を事業者Ｂ１１に変更する（７４９）。
【００５４】
図８は、本技術の実施の形態における譲渡に伴う処理の流れの第３の例を示すシーケンス図である。この第３の例は、事業者間の契約に基づいて、事業者Ａ１０および事業者Ｂ１１が協調して事業者切替えを行う例である。
【００５５】
事業者Ａ１０と事業者Ｂ１１との間の事業者Ａ１０から事業者Ｂ１１への事業の譲渡契約（７５１）、および、事業者Ｂ１１とトラスト事業者２０との間のトラスト事業に関する委託契約（７５２）を前提とする点については、上述の第１の例と同様である。ただし、事業者Ａ１０と事業者Ｂ１１との間で認証情報を予め共有しておく必要がある（７５１）。
【００５６】
事業者Ｂ１１は、事業者切替えの準備を事業者Ａ１０に要求する（７５３）。これに応じて、事業者Ａ１０は事業者Ｂ１１の認証を行う（７５４）。そして、認証に成功すると、事業者Ａ１０は事業者切替の認証トークンをトラスト事業者２０に要求する（７５５）。トラスト事業者２０は、事業者Ａ１０を認証し、契約情報の確認を行う（７５６）。その結果、問題がなければ事業者の切替えを許可し、認証トークンの生成をトラストプロキシサーバ２００に要求する（７５７）。
【００５７】
認証トークンの生成要求に応じて、トラストプロキシサーバ２００は認証トークンを生成する（７５８）。トラスト事業者２０は、生成された認証トークンを事業者Ａ１０に送信する（７５９）。
【００５８】
認証トークンを受け取った事業者Ａ１０は、事業者Ｂ１１に切り替えるための事業者切替準備要求を認証トークンとともにトラストプロキシサーバ２００に送信する（７６１）。この事業者切替準備要求を受け取ったトラストプロキシサーバ２００は、事業者Ａ１０からの認証トークンを確認して（７６２）、問題がなければ仮想事業者Ｘのバインディング先を事業者Ｂ１１に変更する許可を与える（７６３）。この許可を受け取った事業者Ａ１０は、事業者Ｂ１１に事業者切替準備が完了した旨を報告する（７６４）。
【００５９】
その後さらに、上述の第２の例における７４３乃至７４９の処理が行われ、これにより仮想事業者Ｘのバインディング先が事業者Ａ１０から事業者Ｂ１１に変更される。
【００６０】
図９は、本技術の実施の形態において仮想事業者Ｘのバインディング先が事業者Ａから事業者Ｂに変更された状態の一例を示す図である。
【００６１】
上述の一連のシーケンスにより、事業者情報データベース３００における仮想事業者Ｘの仮想事業者識別情報に関連付けて記憶される情報が、事業者Ａ識別情報から事業者Ｂ識別情報に変更された場合を想定する。それまではデバイス１００から送信されたセンシング情報は事業者Ａサーバ５００に送信されていたが、事業者切替えが行われた後は事業者Ｂサーバ６００に送信されるようになり、事業者Ｂのビジネスロジック６１０が行われる。すなわち、譲渡に伴いデバイス１００を更新することなく、譲渡後の事業者Ｂの事業者Ｂサーバ６００にセンシング情報を送信することができる。
【００６２】
＜３．変形例＞
上述の実施の形態では、トラストプロキシサーバを想定したトラストプロキシサーバモデルを採用していた。これに対し、この変形例では、トラスト事業者が提供するトラストクライアントおよびトラストサーバを利用して、デバイスが事業者サーバに接続する、トラストクライアントサーバモデルを採用する。
【００６３】
［トラストクライアントサーバモデル］
図１０は、本技術の実施の形態におけるトラストクライアントサーバモデルによるシステムの全体構成の一例を示す図である。
【００６４】
このシステムでは、デバイス１００と、トラストサーバ２０１と、事業者情報データベース３００と、デバイス情報データベース４００と、事業者Ａサーバ５００とを備える。
【００６５】
デバイス１００は、上述の実施の形態と同様に、センシング情報を無線通信により送信する。ただし、この変形例では、デバイス１００は、トラストクライアント１２０を備える。このトラストクライアント１２０は、トラストサーバ２０１から認証トークンおよび事業者Ａ識別情報を受けることにより、事業者Ａサーバ５００にアクセスするものである。
【００６６】
トラストサーバ２０１は、トラストクライアント１２０からの要求に応じて、認証トークンおよび事業者Ａ識別情報を送信するものである。なお、トラストサーバ２０１は、特許請求の範囲に記載の情報処理装置の一例である。
【００６７】
デバイス情報データベース４００は、トラストサーバ２０１によって生成された認証トークンを、デバイス１００のデバイス識別子に関連付けて記憶するデータベースである。
【００６８】
［動作］
このトラストクライアントサーバモデルにおいて、まず、トラストクライアント１２０は、トラストサーバ２０１に対して、デバイス１００の認証を要求する。これにより、トラストサーバ２０１は、デバイス１００を認証し、認証に成功すると、事業者情報データベース３００に問い合わせて、仮想事業者Ｘに紐づく実際の事業者Ａの事業者Ａ識別情報を特定する。そして、トラストサーバ２０１は、サーバ間認証のための認証トークンを生成する。この生成された認証トークンは、デバイス情報データベース４００において、デバイス１００のデバイス識別子に関連付けて記憶される。そして、トラストサーバ２０１は、これら事業者Ａ識別情報および認証トークンをトラストクライアント１２０に返却する。
【００６９】
トラストクライアント１２０は、事業者Ａ識別情報に基づいて、メッセージを認証トークンとともに送信する。すなわち、事業者Ａ識別情報が事業者Ａサーバ５００のＵＲＬアドレスであれば、そのＵＲＬアドレスを用いて事業者Ａサーバ５００にメッセージを送信する。
【００７０】
メッセージを受信した事業者Ａサーバ５００は、受信した認証トークンをトラストサーバ２０１に送信する。これに応じて、トラストサーバ２０１は認証されたデバイス１００からのメッセージであることを確認すると、デバイス情報データベース４００において、その認証トークンに関連付けて記憶されるデバイス識別子を事業者Ａサーバ５００に送信する。これにより、事業者Ａサーバ５００は、そのメッセージがデバイス１００から正しく送信されたものであることを確認する。すなわち、なりすましを防止し、また、認証トークンの期限切れを管理して、リスクを低減することができる。なお、認証トークンは、特許請求の範囲に記載の認証成功情報の一例である。
【００７１】
＜４．デバイスの製造＞
上述の実施の形態では、トラスト事業者がデバイスを製造することを想定していた。ただし、デバイス鍵ペアの生成とデバイスの製造は必ずしも同一の事業者が行わなくてもよい。以下では、デバイス製造の態様について説明する。
【００７２】
図１１は、本技術の実施の形態におけるデバイス製造の流れの第１の例を示す図である。
【００７３】
この例では、トラスト事業者がデバイス製造事業とトラスト事業の両者を行う場合を想定する。この場合、トラスト事業者以外の者がデバイス鍵ペアを取得することはないため、セキュリティを安全に管理することができる。
【００７４】
まず、事業者Ａ１０は、デバイス１００の製造をトラスト事業者２０に依頼する。このとき、デバイス１００が最終的に接続する事業者Ａサーバ５００のＵＲＬアドレスを同時に登録してもよい。
【００７５】
事業者Ａ１０からのデバイス製造依頼に応じて、トラスト事業者２０は、仮想事業者Ｘを作成する（８２１）。そして、トラスト事業者２０は、デバイス１００のデバイス鍵ペアを生成して（８２２）、デバイス１００にデバイス鍵ペア１１０として書き込む（８２３）。
【００７６】
そして、トラスト事業者２０は、トラストプロキシサーバ２００に対して、デバイス１００を利用するためのプロビジョニングを行う（８２４）。すなわち、トラスト事業者２０は、仮想事業者Ｘに事業者Ａを紐付けるように整備を行うとともに、ＣＡ／ルート証明書を生成してＣＡ／ルート証明書２３０として記憶させる。なお、これらの処理は、上述のトラストサーバ２０１の場合も同様である。
【００７７】
このようにして製造されたデバイス１００は、事業者Ａ１０に提供される。
【００７８】
図１２は、本技術の実施の形態におけるデバイス製造の流れの第２の例を示す図である。
【００７９】
この例では、トラスト事業者はデバイス鍵ペアの作成までを行い、デバイス製造事業は事業者Ａが行う場合を想定する。この場合、事業者Ａがデバイス鍵ペアを取得するため、他の事業者に譲渡が行われた後にもそのデバイス鍵ペアが利用されるおそれがある。そのため、トラスト事業者が事業者Ａにデバイス鍵ペアを供給する際には、それを難読化する必要がある。
【００８０】
まず、事業者Ａ１０は、デバイス鍵の生成をトラスト事業者２０に依頼する（８１１）。
【００８１】
事業者Ａ１０からのデバイス製造依頼に応じて、トラスト事業者２０は、仮想事業者Ｘを作成する（８２１）。また、トラスト事業者２０は、デバイス１００のデバイス鍵ペアを生成する（８２２）。そして、トラスト事業者２０は、作成した秘密鍵を難読化するとともに署名計算のためのライブラリを作成する（８２５）。ここで、難読化された秘密鍵は、この署名計算ライブラリによって、署名計算のみに利用することができる。その結果、公開鍵と難読化された秘密鍵とからなるデバイス鍵ペアおよび署名計算ライブラリは、事業者Ａ１０に供給される。
【００８２】
また、トラスト事業者２０は、上述の第１の例と同様に、トラストプロキシサーバ２００に対して、デバイス１００を利用するためのプロビジョニングを行う（８２４）。
【００８３】
事業者Ａ１０は、トラスト事業者２０から供給されたデバイス鍵ペアおよび署名計算ライブラリを用いてデバイス１００を製造する（８１６）。これらデバイス鍵ペアおよび署名計算ライブラリは、デバイス１００の運用時において以下のように利用される。
【００８４】
図１３は、本技術の実施の形態においてデバイス１００から送信されるメッセージの一例を示す図である。
【００８５】
デバイス１００は、デバイス鍵ペア１１０として、デバイス秘密鍵１１１およびデバイス公開鍵１１３を記憶する。また、デバイス１００は、署名計算ライブラリ１１５を備える。このとき、デバイス秘密鍵１１１は、難読化された状態でデバイス１００に記憶されるため、事業者Ａは元データを復元することができない。したがって、事業者Ｂにデバイス１００が譲渡された後に、事業者Ａが事業者Ｂになりすますことを防止することができる。
【００８６】
デバイス１００は、センシング情報をデータ８１として含むメッセージ８０を生成する（８１７）。このとき、署名計算ライブラリ１１５によって署名８２を生成してメッセージ８０に署名する。また、デバイス公開鍵１１３をデバイス公開鍵８３としてメッセージ８０に同梱する。
【００８７】
このようにして送信されたメッセージ８０について、トラストプロキシサーバ２００はデバイス１００の認証を行う（８２９）。
【００８８】
＜５．デバイスのリボーク＞
上述の実施の形態では、デバイス１００が事業者Ａから事業者Ｂに譲渡される場合を想定していたが、譲渡先が存在せずに事業者Ａが事業から撤退する場合なども起こり得る。ここでは、デバイス１００に対する仮想事業者Ｘへの紐付けを無効化（リボーク）する場合について説明する。
【００８９】
図１４は、本技術の実施の形態におけるデバイス１００の紐付け無効化の一例を示す図である。
【００９０】
事業者情報データベース３００において、仮想事業者Ｘの仮想事業者識別情報に関連付けて記憶される事業者識別情報を、Ｒｅｖｏｋｅｄフラグなどの無効状態を示す情報に変更することにより、紐付けられる事業者を削除することができる。また、証明書失効リスト（ＣＲＬ：Certificate Revocation List）を発行することにより無効化してもよく、また、両者を併用してもよい。
【００９１】
証明書失効リストを用いてリボークを行う場合には、ＴＬＳ（Transport Layer Security）などの証明書検証のレイヤで拒否することができる。この場合、通常であれば事業者Ａサーバ５００への転送は行われない。
【００９２】
一方、より上位レイヤの事業者バインディングによりリボークを行う場合、すなわち、トラストプロキシサーバ２００に委ねずに事業者Ａの判断でリボークを行う場合には、リボークされている状態でビジネスロジック５１０を実行することも可能である。
【００９３】
＜６．デバイスの回収＞
上述の実施の形態では、デバイス１００が事業者Ａから事業者Ｂに譲渡される場合を想定していたが、事業者Ａがデバイス１００を譲渡せずに回収する場合なども起こり得る。その場合、事業者Ａ自身が回収するのではなく、回収業者Ｃに回収を依頼することがあり、仮想事業者Ｘへの紐付けを一時的に回収業者Ｃにすると便利である。ここでは、デバイス１００に対する仮想事業者Ｘへの紐付けを回収業者Ｃに変更する場合について説明する。
【００９４】
図１５は、本技術の実施の形態におけるデバイス１００の仮想事業者Ｘへの紐付けを回収業者Ｃに変更する場合の例を示す図である。
【００９５】
事業者Ａは、事業終了、デバイス故障、設置不良に伴う回収または再設置などにより、デバイス１００が不要になった際に、仮想事業者Ｘがバインドされている事業者を、事業者Ａから回収業者Ｃに変更する。トラストプロキシサーバ２００の振る舞いは、譲渡による事業者Ｂへの変更と同様である。
【００９６】
デバイス１００から送信されるメッセージは、トラストプロキシサーバ２００を介して回収業者Ｃサーバ７００によって受信される。回収業者Ｃは、ビジネスロジック７１０として、デバイス１００から送られてくる位置情報などを使って、デバイス１００の場所を特定し、デバイス１００を回収する。すなわち、譲渡時と同様のバインド変更により、デバイス１００の回収に役立てることができる。
【００９７】
［効果］
このように、本技術の実施の形態によれば、事業者情報データベース３００において仮想事業者識別情報に関連付けて事業者識別情報を記憶することにより、事業者を特定することができる。したがって、デバイス１００の事業者に変更があった場合にも、デバイス１００の更新を行うことなく、運用を継続することができる。
【００９８】
なお、上述の実施の形態は本技術を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本技術の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本技術は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。
【００９９】
また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、ＣＤ（Compact Disc）、ＭＤ（MiniDisc）、ＤＶＤ（Digital Versatile Disc）、メモリカード、ブルーレイディスク（Blu-ray（登録商標）Disc）等を用いることができる。
【０１００】
なお、本明細書に記載された効果はあくまで例示であって、限定されるものではなく、また、他の効果があってもよい。
【０１０１】
なお、本技術は以下のような構成もとることができる。
（１）周囲環境を測定するセンシングデバイスから仮想事業者を宛先とするセンシング情報を受信する受信部と、
前記仮想事業者を識別する仮想事業者識別情報と実事業者を識別する実事業者識別情報とを関連付けて記憶する記憶部に問い合わせて前記センシング情報に対応する前記実事業者識別情報を特定する特定部と
を具備する情報処理装置。
（２）前記特定部は、前記特定された実事業者識別情報に基づいて前記センシング情報を送信する
前記（１）に記載の情報処理装置。
（３）前記センシングデバイスに固有の鍵情報を用いて前記仮想事業者を認証する認証部をさらに具備し、
前記受信部は、前記センシング情報とともに前記鍵情報を受信し、
前記特定部は、前記認証部における認証に成功した場合に前記特定された実事業者識別情報に基づいて前記センシング情報を送信する
前記（１）または（２）に記載の情報処理装置。
（４）前記特定部は、前記センシングデバイスに対して前記特定された実事業者識別情報を送信する
前記（１）に記載の情報処理装置。
（５）前記センシングデバイスに固有の鍵情報を用いて前記仮想事業者を認証する認証部をさらに具備し、
前記受信部は、前記鍵情報を受信し、
前記特定部は、前記認証部における認証に成功した場合に前記センシングデバイスに対して前記特定された実事業者識別情報および認証成功情報を送信し、
前記認証部は、前記センシングデバイスから前記センシング情報とともに前記認証成功情報を受け取るとそのセンシング情報を認証する
前記（１）または（４）に記載の情報処理装置。
（６）前記実事業者識別情報は、前記実事業者のＵＲＬアドレスである
前記（１）から（５）のいずれかに記載の情報処理装置。
（７）前記記憶部において前記仮想事業者識別情報に関連付けて記憶される前記実事業者識別情報を変更して、他の実事業者を識別する他事業者識別情報に切り替える切替部をさらに具備する前記（１）から（６）のいずれかに記載の情報処理装置。
（８）前記切替部は、前記他事業者からの要求に応じて前記他事業者識別情報への切替えを行う
前記（７）に記載の情報処理装置。
（９）前記切替部は、前記実事業者および前記他事業者の協調に従って前記他事業者識別情報への切替えを行う
前記（７）に記載の情報処理装置。
（１０）前記切替部は、前記記憶部において前記仮想事業者識別情報に関連付けて記憶される前記実事業者識別情報を変更して、無効化状態に切り替える
前記（７）に記載の情報処理装置。
（１１）前記記憶部をさらに具備する前記（１）から（１０）のいずれかに記載の情報処理装置。
（１２）周囲環境を測定するセンシングデバイスから仮想事業者を宛先とするセンシング情報を受信する受信手順と、
前記仮想事業者を識別する仮想事業者識別情報と実事業者を識別する実事業者識別情報とを関連付けて記憶する記憶部に問い合わせて前記センシング情報に対応する前記実事業者識別情報を特定する特定手順と
を具備する情報処理装置の処理方法。
【符号の説明】
【０１０２】
１０  事業者Ａ
１１  事業者Ｂ
２０  トラスト事業者
１００  デバイス
１１０  デバイス鍵ペア
１１１  デバイス秘密鍵
１１３  デバイス公開鍵
１１５  署名計算ライブラリ
１２０  トラストクライアント
２００  トラストプロキシサーバ
２０１  トラストサーバ
２１０  受信部
２２０  認証部
２３０  ＣＡ／ルート証明書
２４０  特定部
２６０  切替部
３００  事業者情報データベース
４００  デバイス情報データベース
５００  事業者Ａサーバ
６００  事業者Ｂサーバ
７００  回収業者Ｃサーバ
５１０、６１０、７１０  ビジネスロジック
【図１】
2019142428.tif 000003
【図２】
2019142428.tif 000004
【図３】
2019142428.tif 000005
【図４】
2019142428.tif 000006
【図５】
2019142428.tif 000007
【図６】
2019142428.tif 000008
【図７】
2019142428.tif 000009
【図８】
2019142428.tif 000010
【図９】
2019142428.tif 000011
【図１０】
2019142428.tif 000012
【図１１】
2019142428.tif 000013
【図１２】
2019142428.tif 000014
【図１３】
2019142428.tif 000015
【図１４】
2019142428.tif 000016
【図１５】
2019142428.tif 000017
【国際調査報告】
2019142428.tif 000018
2019142428.tif 000019