JP6652767B2 - 接続デバイスのステータスを管理するための方法 - Google Patents

Description

本発明は、モバイルデバイスの所有権を管理するための方法および装置に関し、より詳細には分散型データベースの技術ドメインに関する。

ほとんどのモバイルデバイスは、紛失、盗難、または破壊などの予期しないイベントから保護されるように、最近は保険を掛けられている。

保険詐欺が一般的になってきたが、その一方で被害者は盗難に遭った人だけでなく、盗まれたデバイスの中古品の買手がなることもある。例として、盗まれたデバイスは、デバイスがいずれかの盗まれたデバイスのデータベースに登録されていないか、またはまだ盗まれたとみなされていない国で売られることがある。

第３世代パートナーシッププロジェクト（３ＧＰＰ：３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）標準によれば、盗まれたと宣言されるデバイスの識別子は、事業者のデータベースに格納される。この場合、合法的な所有者が、盗まれたデバイスを警察、その事業者、およびその保険に宣言するプロセス中に、窃盗犯は盗まれたデバイスを中古品購入者に売ることができる。デバイスが、テレコミュニケーションシステムによってまだ盗まれたとみなされていないときに、被害者がデバイスの購入時にデバイスをテストすると、デバイスは完全に動作する。しかし、デバイスが後でネットワークに接続すると、元の事業者とデータベースを共有する事業者によってブロックされる可能性がある。主な被害者は、実際には、保険会社および中古デバイスの買手であり、元の買手は、それ自身の保険会社によって一般に返金される。

３ＧＰＰにおいて、デバイスの識別子は、移動端末装置識別子（ＩＭＥＩ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ ｓｔａｔｉｏｎ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）であり、データベースは、機器識別登録簿（ＥＩＲ：Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ Ｒｅｇｉｓｔｅｒ）と呼ばれる。デバイスが盗まれたと宣言されると、デバイスのＩＭＥＩは事業者のＥＩＲデータベースに提供される。デバイスが３ＧＰＰネットワークに接続すると、デバイスのＩＭＥＩはＥＩＲデータベースに送信され、ＥＩＲデータベースに格納されているＩＭＥＩと照合される。既に強調されているように、デバイスが盗まれたと宣言された場合、デバイスはネットワークに接続することができない。この技術にはいくつかの限界がある。第１に、ＥＩＲデータベースは、この技術を効率的にするのに必要なだけの事業者間では共有されない可能性がある。第２に、デバイスの使用が本当に禁止されるまでのプロセスが長い。その上、ＥＩＲデータベースの情報へのアクセスは、１つまたはいくつかのモバイル事業者に限定される。この技術は、盗まれたデバイスの使用を禁止するために、盗まれたデバイスの宣言に限定されるということにも留意する必要がある。

モノのインターネット（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）に関連して、およびモバイルデバイスの所有権の管理に関連して用いられる別の既存技術がこれから論じられる。

スマートウォッチ、または住居環境管理デバイス、気象センサ、もしくはキータグなどの様々な種類の接続センサなどの二次的なデバイスは典型的には、限定されたユーザインターフェースを有するか、またはユーザインターフェースがなく、例えば、ＩｏＴサービスプロバイダによって提供されるセルラー接続またはＷｉＦｉといった、インターネットとのワイヤレス接続しかないことがある。

例えば、キーセットを探すために使用されるキータグなどの接続デバイスの場合、デバイスとユーザの間にリンクが確立される必要がある。その上、キータグは、その登録された所有者によってのみ探すことが可能である。自分のキーを紛失したことを所有者が宣言すると、キータグに関連付けられた、紛失したキーの位置をその所有者に中継して送り返すために、コミュニティが動員される。所与の所有者に一旦関連付けられたキータグの所有権は、別の所有者に移譲されることがある。新しい所有者は、自分のキーを紛失したと宣言でき、これらのキーを探すことができる唯一の人であることが求められる。実際、以前の所有者が、デバイスの新しい所有者を探すことができるので、以前の所有者がデバイスを紛失したと宣言できたとすると、プライバシーの問題に遭遇するだろう。デバイスの所有権を以前の所有者から新しい所有者に移譲するプロセスは存在するが、厄介であり、長い。このようなデバイスの例は、Ｔｉｌｅ（商標）と呼ばれるコンパニオンデバイスであり、Ｔｉｌｅ Ｉｎｃｏｒｐｏｒａｔｅｄによって提供される。

所有権の証拠として、秘密コードが使用されることもある。秘密コードを新しい所有者に提供することが、問題の解決策として利用されることもある。しかしこの技法はいくつかの欠点を伴う。元のユーザが秘密コードを紛失するか、または忘れてしまうことがある。さらに、秘密コードが、物理デバイスの複数の被害者に無関係に「売られる」ことがある。これは、例えば、ＩｏＴデバイスが様々な場所に設置されるときのケースである。

したがって、デバイスの所有権が合法であることを保証し、この所有権を第１の所有者から第２の所有者にセキュアかつ効率的に移譲できるようにする技術が必要である。

本発明は、複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース（ｉｍｍｕｔａｂｌｅ ｄｉｓｔｒｉｂｕｔｅｄ ｄａｔａｂａｓｅ）内でアサーションを公開することによって、接続デバイスのステータスを管理するための方法に関する。方法は：
− 第１のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを、前記第１のユーザに関連付けられた第１の端末から接続デバイスによって受信することであって、前記ステータス情報が、接続デバイスの所有権を管理するために使用されることと、
− 第１のユーザが接続デバイスのステータスの修正を認められることを、接続デバイスによって検証すること、および肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意することであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名されることと、
− ステータス情報を含むアサーションを公開するために、アサーションリクエストを不変分散型データベースに接続デバイスによって送信することであって、接続デバイスに関連付けられた公開鍵を使用して不変分散型データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開されることと
を行うステップを含む。

例として、ステータス情報は、接続デバイスの新しい所有者の識別子を含む。

例として、新しい所有者の識別子は、公開鍵と秘密鍵を含むペアの鍵に属する公開鍵であり、前記鍵のペアは、接続デバイスの新しい所有者のものである。

例として、命令メッセージは、接続デバイスの以前の所有者の識別子と、合法的な所有者として新しい所有者を示す不変分散型データベース内のアサーションの公開により以前の所有者を新しい所有者に置き換えるための指示とを含む。

例として、受信された命令メッセージは秘密データを含み、第１のユーザと接続デバイスが同じ秘密を共有していることを示す、接続デバイスに格納された秘密データと、受信された秘密データが一致する場合、第１のユーザが、接続デバイスのステータスの修正を認められるものとみなされる。

例として、接続デバイスの所有権は、第２のユーザが新しい所有者になるように第１のユーザから第２のユーザに移譲され、移譲は、肯定応答メッセージを第１の端末に送信することによって第２のユーザが関連付けられる第２の端末を使用して第２のユーザによって始められ、前記肯定応答メッセージは、接続デバイスの所有権を第２のユーザに移譲するための少なくとも命令、および第２のユーザの識別子を含む。

例として、接続デバイスの所有権は、第１のユーザが新しい所有者になるように第２のユーザから第１のユーザに移譲され、移譲は、肯定応答メッセージを第１の端末に送信することによって第２のユーザが関連付けられる第２の端末を使用して第２のユーザによって始められ、前記肯定応答メッセージは、接続デバイスの所有権を第１のユーザに移譲するための少なくとも命令、および第２のユーザの識別子を含む。

例として、接続デバイスは、第１のユーザが接続デバイスの合法的な所有者であることを公開アサーションが示す場合、接続デバイスの所有権記録、または不変分散型データベース内の所有権記録をチェックすることによって、第１のユーザが接続デバイスのステータスの修正を認められることを、検証する。

例として、命令メッセージは、アプリケーションがインストールされる第１の端末から受信され、前記アプリケーションは、命令メッセージの用意を制御するように構成される。

例として、接続デバイスは、不変分散型データベース内で公開される接続デバイスのステータス情報を読むために不変分散型データベースにリクエストを送信し、それに応じて前記ステータス情報を受信する。

例として、接続デバイスが盗まれたか、または紛失したことを、受信されたステータス情報が示す場合、接続デバイスは、最小サービスモードに切り替え、接続デバイスの合法的な所有者からの命令の受信を待つ。

本発明はまた、複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内に公開されたアサーションを読むことによって、第三者からアクセス可能なステータス情報に関連付けられる接続デバイスに関し、接続デバイスは、
− 第１のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを受信することと、
− 第１のユーザが接続デバイスのステータスの修正を認められることを、検証し、肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意することであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名されることと、
− ステータス情報を含むアサーションを公開するために不変分散型データベースにアサーションリクエストを送信することであって、接続デバイスに関連付けられた公開鍵を使用して不変分散型データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開されることと
を行うように構成される。

本発明のさらなる特徴および利点は、本発明の１つの好ましい実施形態の詳細な説明を読むとさらに明確に理解でき、以下の図面と共に指示的かつ非限定的な例として示される。

複数のステークホルダによって確認され、検証されるアサーションを公開するために使用される分散型データベースを含むワイヤレスシステムの概略図である。 分散型データベース内でアサーションを公開するために行われ得る処理の例を示す図である。 １つまたはいくつかのアサーションの公開につながるプロセスが、どのようにして時間内に編成され得るかを概略的に示す図である。 第１のユーザによって購入されるデバイスの所有権の初めの宣言のために行われ得るシーケンス図の例を示す図である。 所有権の移譲を宣言するために行われ得るシーケンス図の例を示す図である。 デバイスが盗まれたことを宣言するために行われ得るシーケンス図の例を示す図である。

本明細書において、接続デバイスのステータスを管理するために１つの発明が提案される。以下の例において、これは、接続デバイスの所有権を管理することに関連して説明される。しかし本発明は、接続デバイスのステータスを管理することに、より一般的に適用可能である。ステータスは、例えば、所有権情報、または他のデバイスと比較したリソースへのアクセスの優先度に対応することができる。さらに本発明は、いわゆるＩｏＴデバイスが特に関連するユースケースであるので、ＩｏＴデバイスに関して説明される。しかし本発明は、例えば、５Ｇスマートフォン、タブレット型コンピュータ、またはワイヤレス接続を介して通信できる車両といった、任意のタイプの接続デバイスのステータスを管理するために使用されてよい。

図１は、複数のステークホルダによって確認され、検証されるアサーションを公開するために使用される分散型データベースを含むワイヤレスシステムの概略図である。

システムには、複数のステークホルダ１１０−１１４がいる。ステークホルダは、ワイヤレスシステムのアクタによって運用される計算ノードである。本説明において、計算ノードは、通信ネットワーク上でデータを受信し伝達するためのハードウェア手段およびソフトウェア手段を有し、プログラムを実行するデバイスを指す。ネットワークに接続されるコンピュータは、計算ノードの例である。

この例において、第１および第２のモバイルネットワーク事業者によって２つの計算ノード１１０、１１１がそれぞれ運用され、ＩｏＴモバイルネットワーク事業者によって１つの計算ノード１１２が運用され、デバイス製造業者、警察、保険会社、または中古市場メーカなどの他のタイプのアクタによって２つの計算ノード１１３、１１４が運用される。

システムは、宣言エンティティとして指定される他のエンティティも含む。宣言エンティティは、分散型データベース１３０内で１つまたはいくつかのアサーションの公開をリクエストできるエンティティである。本説明において、分散型データベースは、ネットワークの複数の計算ノード全体にわたってデータが格納されるデータベースを指す。好ましい実施形態によれば、分散型データベースは不変である。有利には、本発明に関連して使用され得る不変分散型データベースの例は、ブロックチェーンである。

図１によって提供される例に、第１のモバイルネットワーク事業者の４人のサブスクライバによって使用される４台のモバイルデバイス１２１、第２のモバイルネットワーク事業者の４人のサブスクライバによって使用される４台のモバイルデバイス１２０、およびＩｏＴモバイルネットワーク事業者の４人のサブスクライバによって使用される４台のＩｏＴデバイス１２２が表される。

本説明において、ＩｏＴデバイスは、マシンツーマシンの通信モジュールを備えるモバイルデバイスを指す。マシンツーマシン（Ｍ２Ｍ：Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）は、１つの端末から別の端末へのデータの伝達、またはＧＳＭ／ＧＰＲＳ、ＵＭＴＳ／ＨＳＤＰＡ、ＣＤＭＡ／ＥＶＤＯ、ＬＴＥ、もしくは他のモジュールを介したマシン間のデータの交換を指す。現在Ｍ２Ｍは、セキュリティ監視、自動販売機、公共交通システム、車両監視および管理、工業プロセス自動化、自動車機械設備（ｍｏｔｏｒ ｍａｃｈｉｎｅｒｉｅｓ）、スマートシティなどの分野において、一般に適用される。

この例において、これらのデバイスはステークホルダではなく、宣言エンティティの役割しかない。しかし、システムの所与のアクタは、分散型データベース内でアサーションを公開する必要があることもある。この場合、所与の計算ノードは、ステークホルダおよび宣言エンティティの機能を実装するように構成されてよい。これは、例えば、２つのＩｏＴデバイス製造業者１１３、１１４のケースであり、両者はこのように構成される計算ノードを運用することができる。

この特定の例に関連して、システムの様々なアクタの主な機能が、この後説明される。

モバイルネットワーク事業者はそのサブスクライバを有しているか、またはサブスクライバのホーム事業者（ＨＰＬＭＮ）にアクセスすることができる。モバイルネットワーク事業者は、そのサブスクライバを分散型データベースに記載する責任があることがある。ＭＮＯは、その無線ネットワーク、そのサブスクリプションサービス、および認証機能などの、ＭＮＯのネットワークリソースへのアクセスをモバイルデバイスに提供する。ＭＮＯは、クレデンシャルを検証すること、およびモバイルデバイスを認証することにも責任がある。ＭＮＯは、ユーザによってサブスクライブされたサービスを検証することもできる。さらにＭＮＯのネットワークは、分散型データベースへのアクセスを提供するように構成される。既に強調されたように、ＭＮＯは、分散型データベース内で署名済のアサーションを検証および公開することができるアクタであってもよい。

暗号動作に、またはセキュア情報の格納に関して、ＩｏＴデバイスは、例えば、ＵＩＣＣ、ｅＳＥ、またはｅＵＩＣＣといったセキュア要素に関連付けられてよい。

セキュア要素は、例えば、ＵＩＣＣ（ユニバーサル集積回路カード（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ））である。ＵＩＣＣは、スマートカードの形式、パッケージ化されたチップの形式、または任意の他の形式であってよい。ＵＩＣＣは、例えば、ＧＳＭおよびＵＭＴＳネットワークにおけるモバイル端末で使用されることがある。ＵＩＣＣは、すべての種類の個人データのネットワーク認証、完全性、およびセキュリティを保証する。

ＵＩＣＣは、ＧＳＭ／ＧＰＲＳネットワークのためのＳＩＭアプリケーションを主に収め、ＵＭＴＳネットワークのためのＵＳＩＭアプリケーションにおいて、ＳＩＭアプリケーションがＵＳＩＭアプリケーションである。ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）をサポートするネットワークに関して、ＵＩＣＣはＩＳＩＭアプリケーションを収める。ＵＩＣＣは、ＵＭＴＳおよびＬＴＥネットワークへ同じスマートカードがアクセスできるようにするいくつかの他のアプリケーションを収めることもあり、電話帳の格納ならびに他のタイプのサービスも可能にする。

ＵＩＣＣは通常、モバイル端末またはＩｏＴデバイスから取り去られてもよい。自分のＵＩＣＣを自分の新しい端末に挿入しても、ユーザはまだ、自分のアプリケーション、連絡先、およびクレデンシャル（ネットワーク事業者）にアクセスすることができる。

セキュア要素は、ｅＵＩＣＣタイプ（埋込型ＵＩＣＣ）のものであってもよい。ｅＵＩＣＣは、はんだ付けされているか、またはデバイスに完全にリンクされているわけではないが、取り去られることを意図していないので苦労して取り去ることができる、離れているか、またはマシンに完全に統合されている端末内に配置される、ＵＩＣＣである。（例えば、非常に小さく、したがって扱いやすくないという）ＵＩＣＣの特殊なフォームファクタが、ＵＩＣＣが実際に端末内に統合されることを考慮すべき理由になることもある。ソフトウェアによってセキュア要素の機能を実装している技術が、本発明に関連して考慮されてもよい。

モバイルネットワーク事業者のサブスクライバは、モバイルネットワーク事業者（ＭＮＯ：Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ）に対する有効なサブスクリプションを有する。サブスクライバは、例えば、そのモバイルネットワーク事業者を介して、システム内で使用され得るサブスクライバ自身の公開鍵／秘密鍵のペアを有することもできる。サブスクライバは、自分が購入したＩｏＴデバイスをアクティベートすることができる人である。

所与のＩｏＴデバイスのアクティベートにつながる暗号プロセスを行うために、サブスクライバは、例えば、スマートフォンといったモバイルデバイス、またはセキュア要素内のアプリケーションに関連付けられてよい。

分散型データベースは、システムのステークホルダによって署名され、検証されたすべての有効なアサーションを統合することができる。これらは、システムのステークホルダがアクセスでき、ステークホルダのそれぞれは、システム内で公開された所与のアサーションを読むことができ、その公開を要求した宣言エンティティを認証することができる。

要約として、図１で説明されるようなテレコミュニケーションシステムは、以下を含む：
− ネットワーク事業者１１０−１１２、またはデバイス製造業者、デバイス証明エンティティ、保険会社、警察、もしくは中古市場メーカなどの他のアクタ１１３、１１４によって運用される、複数のステークホルダ１１０−１１４からなる分散型データベース１３０。
− 例えば、ダウンロードされたアプリケーションを使用してアサーションの公開をリクエストするために、サブスクライバが分散型データベースにアクセスできるようにしている１つまたはいくつかのデバイス１２０、１２１。
− 所有権が管理される必要があり、分散型データベース１３０と対話できる、例えば、ＩｏＴデバイスといった、１つまたはいくつかのデバイス１２２。
− 様々なアクタを接続するために使用されるテレコミュニケーションネットワーク１３１。

システムの様々なアクタを取り巻き得る役割および責任が以下に説明される。すべてのこれらの役割および責任は、デバイスの所有権を管理するために、提案されたメカニズムを実装するのに必須ではなく、例証のためだけに以下に示される。

分散型データベース１３０は、以下を行う責任を負い得る：
− 公開アサーションリポジトリをシステムのすべてのアクタがアクセスでき、利用できるようにすること。
− 公開アサーションのオリジネータの匿名を確約すること。
− 公開された公開アサーションの真正性および有効性を検証すること。
− 公開されることになるアサーションにタイムスタンプを押すことおよび署名すること。
− ユーザの秘密鍵／公開鍵のペアをバックアップすること、および鍵回復処理を提供すること。

ＩｏＴデバイス１２２は、以下を行う責任を負い得る：
− 合法的な所有者のリスト維持すること。各デバイスに対して１人または数人の所有者がいてよく、これらの所有者は、各デバイスのものである公開鍵／秘密鍵のペアのうちの公開鍵によって識別されてよい。
− デバイスに関連付けられた秘密コードを自分が知っていることが検証されると、自分が最初の１次所有者としてユーザの公開鍵によって識別され得るユーザを受け入れること。
− デバイスの合法的な所有者から受信された命令の真正性および有効性を検証すること。
− 暗号アルゴリズムに基づいて公開鍵をセキュアに計算すること。
− 署名済のアサーションリクエストを生成して分散型データベースのステークホルダに伝達すること。
− 分散型データベース内で公開されたデバイスのステータスを、要求されたときに検証すること。
− 紛失したまたは盗まれたと宣言された後にデバイスが再びオンラインになっていることを、デバイスの合法的な所有者にアラートすること。

接続端末を使用するユーザは、以下を行う責任を負い得る：
− ＩｏＴデバイスのステータスを監視または変更するために接続端末上でアプリケーションを得ること。接続端末は、例えば、モバイル端末、タブレット型コンピュータ、ラップトップ、またはスマートウォッチであってよい。
− ＩｏＴデバイスに関連付けられた秘密コードを入手すること。
− ダウンロードされたアプリケーションを介してＩｏＴデバイスから所有権の宣言／アサーションをリクエストすること。
− ＩｏＴデバイスによってアサーションリクエストの送信をトリガすること。

ダウンロードされたアプリケーションは、以下を行う責任を負い得る：
− ユーザに関連付けられた公開鍵／秘密鍵のペアを得ることまたは生成すること。
− 例えば、セキュア要素の中にユーザの秘密鍵をセキュアに格納すること。
− ユーザの代わりに、例えば、セキュア要素の中で暗号アルゴリズムをセキュアに実行すること。
− 例えば、初めの所有権情報、または所有権の移譲に関連した命令を生成してＩｏＴデバイスに送信すること。
− 例えば、デバイスを紛失したまたは盗まれたことを宣言するために、ユーザのアサーションリクエストを生成して少なくとも分散型データベースのステークホルダに送信すること。
− ユーザの公開鍵／秘密鍵のペアのバックアップ。

他のアクタの責任は、彼らの特性に依存する。例として、証明エンティティは、一定の動作を行うために、デバイスが十分にセキュアであると宣言することができる。アクタはその他に、このような宣言に責任がある。警察は、いくつかのデバイスが無効にされていることを分散型データベース内で宣言することができる。

任意のアクタが、デバイスの公開鍵によって識別された任意のデバイスの所有権のステータスを検証することができる。

図２は、分散型データベース内でアサーションを公開するために行われ得る処理の例を示す。

所与の処理期間において、第１のステークホルダ２０５は、４つの宣言エンティティ２００−２０３から４つのアサーションリクエスト２０４を収集する。アサーションリクエストは、分散型データベース内でステークホルダによって公開されることになる情報の少なくとも一部を含むメッセージである。

本発明の１つの実施形態によれば、公開鍵と秘密鍵を含む鍵のペアは、各宣言エンティティに関連付けられる。このタイプの鍵のペアは、宣言エンティティの鍵のペアすなわちＤＥの鍵のペアとして指定される。さらに、ＤＥの公開鍵、またはＤＥの公開鍵に適用される一方向性関数もしくはハッシュ関数（例えば、ＳＨＡ−２５６）の結果は、宣言エンティティの識別子として使用されてよい。宣言エンティティは、ＤＥの鍵のペアの秘密鍵を使用して、アサーションリクエストに署名することができる。

例として、アサーションリクエストは、例えば、ＤＥの公開鍵に対する宣言エンティティの識別子を含む。アサーションリクエストは、アサーションの主題を示すラベルを含んでもよい。このラベルは、ステークホルダによって後で解釈され得るデジタルシーケンスである。

次に、第１のステークホルダは、宣言エンティティのＤＥの公開鍵を使用してアサーションリクエストに署名した宣言エンティティを認証し、アサーションブロック２０６を生成することができる。

アサーションブロック２０６は、所与の処理期間中に第１のステークホルダ２０５によって受信されたアサーションすべてを含む。アサーションブロック２０６は、ＦＳの鍵のペアの秘密鍵を使用してそれぞれの受信されたアサーションに署名することによって、および、または代替的に、やはりＦＳの鍵のペアの秘密鍵を使用して全体ブロックに署名することによって構築されてよい。

次に、第１のステークホルダ２０６は、署名済のアサーションブロックを第２のステークホルダ２３３に送信する。

所与の処理期間中、第２のステークホルダ２３３は、１人もしくは何人かのステークホルダ２２０−２２２によって発せられたアサーションブロック２３０−２３２の１つもしくはいくつかを受信するかいずれも受信しないことができる。次に、第２のステークホルダは、受信されたアサーションブロックを集約し、集約アサーションブロック２４０を提供するためにこの集約の結果に署名する。

集約アサーションブロック２４０はその後、分散型データベース内で公開されてよい２６０。

１つの実施形態によれば、第２のステークホルダのものである鍵のペアにより、署名２５０が生成される。この鍵のペアは、第２のステークホルダ（ＳｅＳ：ｓｅｃｏｎｄ ｓｔａｋｅｈｏｌｄｅｒ）鍵のペアとして指定され、ＳｅＳの秘密鍵およびＳｅＳの公開鍵を備える。好ましい実施形態において、使用される署名アルゴリズムは、現在の処理期間中に受信されたアサーションブロック２３０、２３１、２３２、ならびに分散型データベース内で公開された最後の集約アサーションブロックに対して生成された署名２３４を入力として用いる。

プロセスの利点は、分散型データベース内で、以前に署名済の集約アサーションブロックの権限付与されていない挿入または削除を任意のステークホルダによって検知できるようになることである。データベースへの集約アサーションブロックの追加は、データベースの最後にだけ行われうる。

権限付与されていない挿入または削除を任意のステークホルダによって検知できるようにするデータベースは、不変であるとして指定されることが多く、これは図２によって提供される例におけるケースである。本説明において、言及された分散型データベースは不変である。

本発明の１つの実施形態によれば、署名済の集約アサーションブロックを公開する前に、分散型データベースのステークホルダのすべてまたは一部によって検証が対処される。

署名済の集約アサーションブロックが公開されると、任意のステークホルダは、公開されたアサーションにアクセスし、集約アサーションブロックの署名を検証し、識別された宣言エンティティによって所与のアサーションが発せられたことを検証することができる。

所与のステークホルダは、前述の「第１」および「第２」のステークホルダの両者の機能を実行することができるということを当業者は理解するであろう。しかし所与のアサーションブロックを生成するステークホルダ、および前記所与のアサーションを含む署名済の集約アサーションブロックを生成するステークホルダは、異なることが非常に好ましい。

ビットコインなどのピアツーピアのデータベースとは異なり、システムのステークホルダだけが、公開されたアサーションにアクセスできるということに留意することが重要である。このために、ステークホルダは、信頼できる第三者に登録される必要がある。この信頼できる当事者は、それ自体がステークホルダである計算ノードによって実装されてよい。例として、信頼できる第三者ＴＴＰ１は、システムの最初に登録されたステークホルダである。新しいアクタがこの方式に加わりたいと思うとき、新しいアクタは、例えばＴＴＰ１といったステークホルダのうちの１つに最初に登録する必要がある。次に例として、ＴＴＰ１は、クレデンシャル、および新しいアクタの能力を検証する。検証が成功すると、ＴＴＰ１は、ＴＴＰ１によって新しいアクタが登録されることを示す署名済の集約アサーションブロックを生成するステークホルダにアサーションを提供することができる。新しいアクタの登録のアサーションが分散型データベースに公開されると、新しいアクタは登録され、この方式の新しいステークホルダになる。この新しいステークホルダは次に、新しいアクタを登録し、分散型に公開されることになるアサーションブロックおよび集約アサーションブロックを生成することができる。

公開鍵と秘密鍵を含む鍵のペアは、それぞれの登録されたステークホルダに割り振られる。これは、図２によって説明のために言及された、第１および第２のステークホルダにそれぞれ割り振られるＦＳおよびＳｅＳの鍵のペアに対応する。

所与のステークホルダは、すべての登録されたステークホルダの公開鍵を知っている。したがって彼らは、所与の集約アサーションブロックまたは所与のアサーションブロックが、権限付与された（すなわち登録された）ステークホルダによって正しく署名されたことをいつでも検証することができる。

図３は、１つまたはいくつかのアサーションの公開につながるプロセスが、どのようにして時間内に編成され得るかを概略的に示す。

この例において、処理サイクルは、ステークホルダの数または処理されることになるアサーションの数、システムの負荷などのシステム属性に依存し得る、指定された期間のうちの４つの処理期間Ｔ１、Ｔ２、Ｔ３、およびＴ４から成る。

第１の処理期間中、第１のステークホルダによってアサーションが受信される。１つまたはいくつかのアサーションから成るアサーションブロックが生成され、署名される３００。

第２の処理期間中、第１のステークホルダによって第２のステークホルダに、署名済のアサーションブロックが伝達される３０１。第２のステークホルダは、所定のスケジュールに基づいて選ばれてよく、所与のステークホルダは、集約アサーションブロックを生成する人として各処理期間に対して指定される。代替的に、第２のステークホルダは、ランダムに選ばれてよい。

第３の処理期間中、第２のステークホルダは、集約アサーションブロックを生成し、署名する３０２。

第４の処理期間中、システムのステークホルダすべてが、署名済の集約アサーションブロックの有効性を検証し、肯定的検証の場合、ブロックは、分散型データベース内で公開される３０２。

例示的な目的で処理期間の順序は提供されている。処理期間の順序は様々に対処されてよいということを当業者は理解するであろう。例えば、プロセス３００および３０１は、第１の処理期間内に対処されてよく、プロセス３０２および３０３は、第２の処理期間内に対処されてよい。

図４は、第１のユーザによって購入されるデバイスの所有権の初めの宣言のために行われ得るシーケンス図の例である。

この例において、第１のユーザであるユーザ１は、ＩｏＴデバイスの所有権を管理するためにアプリケーションがサービスへのアクセスを可能にする、例えば、モバイル端末、ラップトップ、またはタブレット型コンピュータといった端末を使用する。アプリケーションは、Ａｐｐｌｅ ＳｔｏｒｅまたはＧｏｏｇｌｅ Ｐｌａｙなどのアプリケーションマーケット上で利用可能になることがある（ＡｐｐｌｅおよびＧｏｏｇｌｅは登録商標である）。

サービスを使用するためにユーザ１が記載されることが仮定される。１つの実施形態によれば、記載されると、アプリケーションがインストールされる端末は、秘密鍵／公開鍵のペアを提供される。この鍵のペアは、端末によってローカルに生成されてもよい。ユーザ１の端末が、鍵のペアを格納するセキュア要素と連携することを含むこともできる。このセキュア要素は、セキュア環境内で暗号アルゴリズムを行うように構成されてもよい。このセキュア要素は、例えば、ＵＩＣＣ、ｅＵＩＣＣ、またはｅＳＥである。

所有権が管理される必要がある新たに購入されたＩｏＴデバイスは、ユーザ１と共有される秘密を有する。この秘密は、例えば、個人識別番号（ＰＩＮ：ｐｅｒｓｏｎａｌ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ）、シリアル番号、またはＩＭＥＩなどのコードである。この秘密は、デバイス上に、デバイスのユーザマニュアル上に、またはより一般的には、例えば、デバイスのパッケージを開けた後に、ＩｏＴデバイスの合法的な所有者だけしか知らない場所に印刷されてもよい。

デバイス上に秘密が印刷される場合、これは、一連のキャラクタ、ディジット、またはフラッシュコード（ＱＲコード）の形をとることができる。代替的に、これは、非接触タグの中に格納されてよく、またＩｏＴデバイスによって生成されてユーザ１に表示されてもよい。

別の実施形態によれば、ＩｏＴデバイスは、それ自体の公開鍵／秘密鍵のペアを有し、セキュアな永続メモリ、セキュア要素、ＵＩＣＣ、またはｅＵＩＣＣにおけるデバイスの内部に格納される。

ユーザ１は、ＩｏＴデバイスの秘密およびデバイスの公開鍵を入手する４００。これは、ＩｏＴデバイス上、またはその元のパッケージ上のこれらの情報を読むことによって、およびその後キー入力することによって行われてよく、また端末のカメラを使用して、または近距離無線通信（ＮＦＣ：Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）インターフェースなどの、短距離ワイヤレスインターフェース使用して入手されてもよい。

ユーザ１の端末は次に、例えば以下を含む宣言の暗号署名を行うことによって所有権の宣言を生成する：
− ユーザ１がＩｏＴデバイスの所有者であることを示す命令。
− 宣言した所有者の識別子として提供されるユーザ１の公開鍵。
− 所有権がアサーションされるデバイスの識別子として提供されるＩｏＴデバイスの公開鍵。
− ＩｏＴデバイスの公開鍵で暗号にされ得る秘密コード。

例えば、宣言は、ユーザ１のものである秘密鍵を使用して署名されてよい。

宣言はその後、例えば、直接のデバイス間通信を使用して、または代替的に、ワイヤレステレコミュニケーションネットワークを通じて、通信インターフェースを介してＩｏＴデバイスに伝達される４０１。

ユーザ１は任意選択で、登録されたデータベース（図示せず）のステークホルダに同じ宣言を送信することもできる。

本発明の一態様によれば、デバイスによって受信された所有権の宣言の真正性は、ユーザ１の公開鍵を使用して前記宣言の署名をチェックすることによってアサーションを生成する前にチェックされてよい。

ＩｏＴデバイスは、ＩｏＴデバイスを識別する正しい公開鍵、およびこのデバイスの正しい秘密を宣言が含むことを検証することもできる。

宣言を受信すると、ＩｏＴデバイスは、秘密コードが暗号にされた場合、秘密コードを復号すること、秘密コードを検証すること、提供された秘密コードがＩｏＴデバイスの内部に格納された参照コードにマッチする場合、署名済のアサーションリクエストを生成することを行うことができる４０２。例として、署名済のアサーションリクエストは以下を含む：
− アサーションリクエストが所有権の宣言に関連するという指示。
− 例えば、ユーザ１の公開鍵といった、所有者の識別子。
− 例えば、ＩｏＴデバイスの公開鍵といった、デバイスの識別子。
− ＩｏＴデバイスによって、ＩｏＴデバイスの秘密鍵を使用して生成される署名。

次に、署名済のアサーションリクエストは、分散型データベースのステークホルダにＩｏＴデバイスによって送信される４０３。

アサーションリクエストを受信すると、ステークホルダは、アサーションリクエストの有効性を検証する。このために、以下のことがチェックされる：
− ＩｏＴデバイスの公開鍵を使用することによって署名が有効であること。
− これが所有権の初めの宣言であること。

アサーションが有効な場合、ステークホルダは、アサーションがデータベースに公開されるようにアサーションを用意することができる。図２によって提案された例については、アサーションリクエストを受信するステークホルダがアサーションを用意する。アサーションは、例えば、以下を含む：
− アサーションが所有権の宣言に関連するという指示。
− 例えば、ユーザ１の公開鍵といった、所有者の識別子。
− 例えば、ＩｏＴデバイスの公開鍵といった、デバイスの識別子。
− アサーションリクエストを受信したステークホルダによって、このステークホルダの秘密鍵を使用して生成される署名。

次に、ステークホルダは、少なくとも１つのアサーションのセットを含むアサーションブロックを構築し、このアサーションブロックを、その後分散型データベース内で公開される署名済の集約アサーションブロックを生成するために、いくつかのアサーションブロックを集約して署名できる第２のステークホルダに伝達することができる。

公開されると、ＩｏＴデバイスの所有者を識別するアサーションは、ユーザ１を含む任意の認められたアクタによって、このアクタの端末およびＩｏＴデバイス自体を介してアクセス可能になる４０５、４０６。

図５は、所有権の移譲を宣言するために行われ得るシーケンス図の例である。

この例において、ユーザ２として指定された第２のユーザは、ユーザ１として指定された第１のユーザによって所有されるＩｏＴデバイスを入手したいと思っている。

ユーザ１およびユーザ２は、彼らの端末にダウンロードされたアプリケーションを使用して、彼らに関連付けられた公開鍵／秘密鍵のペアをそれぞれ得た。

さらに、図４の例によって示されるように、ＩｏＴデバイスを用いてユーザ１が初めの所有権の宣言を正常に行ったことが仮定される。したがって、対応するアサーションが分散型データベース内で公開される。

ユーザ２の秘密鍵で署名された所有権の移譲に対するユーザ２の肯定応答５００を、ユーザ２がユーザ１に提供するときに、所有権の移譲が始められてよい。肯定応答は、例えば、以下を含む：
− ＩｏＴデバイスの所有権の移譲に関する肯定応答。
− 例えば、ＩｏＴデバイスの公開鍵といった、デバイスの識別子。
− 新しいユーザの識別子としてのユーザ２の公開鍵。
− ユーザ２によって、ユーザ２の秘密鍵を使用して生成される署名。

例えば、ユーザ２は、分散型データベースにアクセスすることによって、ユーザ１がＩｏＴデバイスの実際の所有者であることを、取得前に検証することができる。

ユーザ１は、ユーザ１の秘密鍵を使用して署名された所有権変更の命令５０１を、ユーザ１の端末を使用してＩｏＴデバイスに送信する。命令は、例えば以下を含む：
− ＩｏＴデバイスの所有権を変更する命令。
− 現在の所有者の識別子としてのユーザ１の公開鍵。
− ＩｏＴデバイスの所有権の移譲に関するユーザ２の肯定応答。

有利には、ＩｏＴデバイスの合法的な所有者としてユーザ１が既に登録されているので、ＩｏＴデバイスの秘密コードをユーザ１が送信する必要はない。

代替的に、ユーザ１とユーザ２が彼らの公開鍵を交換するときの初めのステップに続いて、ユーザ１の秘密鍵で署名されたＩｏＴデバイスの所有権の移譲の同意をユーザ１がユーザ２に提供するときに、所有権の移譲が始められる。同意は、例えば以下を含む：
− ＩｏＴデバイスの所有権を変更することへの同意。
− 例えば、ＩｏＴデバイスの公開鍵といった、デバイスの識別子。
− 現在の所有者の識別子としてのユーザ１の公開鍵。
− 新しい所有者の識別子としてのユーザ２の公開鍵。
− ユーザ１によって、ユーザ１の秘密鍵を使用して生成される署名。

ユーザ２は、ユーザ２の秘密鍵を使用して署名された所有権変更の命令を、ユーザ２の端末を使用してＩｏＴデバイスに送信する。命令は、例えば、以下を含む：
− ＩｏＴデバイスの所有権を変更する命令。
− ＩｏＴデバイスの所有権の移譲に関するユーザ１の同意。
− 新しい所有者の識別子としてのユーザ２の公開鍵。
− ユーザ２によって、ユーザ２の秘密鍵を使用して生成される署名。

ＩｏＴデバイスの所有権を変更するための命令を受信すると、ＩｏＴデバイスは以下のタスクを行う５０２：
− ユーザ１の公開鍵を使用して署名の有効性をチェックすることによって、ユーザ１からの命令または同意の真正性を検証すること。
− ユーザ２の公開鍵を使用して署名の有効性をチェックすることによって、ユーザ２からの命令または肯定応答の真正性を検証すること。
− 例えば、ＩｏＴデバイスの現在の所有者の識別子としてユーザ１の公開鍵が公開されていることを分散型データベース内で検証することによって、デバイスの合法的な所有者としてユーザ１が宣言されることを検証すること。
− ユーザ１の置換えの際、新しい所有者としてユーザ２を宣言するために、新しいアサーションを生成すること。
− ＩｏＴデバイスの秘密鍵で宣言に署名すること。

所有権変更のアサーションは次に、分散型データベースのステークホルダに伝達される５０３。

この新しいアサーションを受信すると、ステークホルダは以下のタスクを行う５０４：
− ＩｏＴデバイスの公開鍵を使用してアサーションの真正性を検証すること。
− 分散型データベース内に並行アサーションがないことをチェックすること。
− ステークホルダの秘密鍵で所有権変更の新しいアサーションにタイムスタンプを押し、署名する。
− アサーションが公開されるように、第２のステークホルダへのアサーションブロック中へ送信すること。
− 分散型データベース内で署名済のアサーションを公開すること。

このステージから、分散型データベースへのアクセスを認められる任意のアクタ５０５が、ＩｏＴデバイスの新しい所有権をチェックすることができる。特に、ＩｏＴデバイスの所有権が正しくユーザ２に移譲されたことをユーザ２が検証することができる５０６。

図６は、デバイスが盗まれたことを宣言するために行われ得るシーケンス図の例である。

紛失または盗まれたデバイスの場合、合法的な所有者が、盗難または紛失をすぐに宣言することができる。この宣言はその後、デバイスのステータスが何であるかをシステムの任意のユーザが公開直後にチェックできるように、分散型データベース内で公開される。この例によれば、デバイスの合法的な所有者であるユーザ１が、盗まれたものとしてデバイスを宣言する。例として、このデバイスのステータス「盗難」がデータベース内で公開されることになる。この新しいステータス情報が、例えば、ＩｏＴデバイスに悪いことは何も起こらなかったことを示す、分散型データベース内で公開されたステータス「通常」を置き換える。

さらに、異なるステータス指標が分散型データベース内で公開されることになる他のタイプのイベントが宣言されてもよい。例えば、デバイスの紛失が合法的なユーザによって宣言されてよく、その結果、ステータス「紛失」が、分散型データベース内でこのデバイスに対して公開される。

合法的な所有者であるユーザ１は、ＩｏＴデバイスの所有権を管理するためにユーザが分散型データベースとデータを交換できるようにするダウンロードされたアプリケーションを有する通信端末を介して、デバイスが紛失したことを示すアサーションリクエスト内の宣言を分散型データベースに伝達する６００。このアサーションリクエストはユーザ１の秘密鍵を使用して署名され、このプロセスは前述のアプリケーションによって行われる。

例えば、アサーションリクエストは、以下を含む：
− 例えば、ユーザ１の公開鍵といった、所有者の識別子。
− 例えば、ＩｏＴデバイスの公開鍵といった、デバイスの識別子。
− ＩｏＴデバイスが「盗難」されたことを示す指示。

アサーションリクエストを受信し、前記リクエスト６０１を検証した後、アサーションは分散型データベース内で用意され、公開される６０２。より正確には、また例として、分散型データベースの第１のステークホルダが宣言の真正性を検証する。このために、アサーションリクエストの署名が、ユーザ１の公開鍵を使用して検証される。その後、第１のステークホルダは、リクエスト内で提供される所有者の識別子が、このリクエストに対する分散型データベース内で公開されている識別子にマッチすることを検証する。この例において、検証される識別子は、ユーザ１の鍵のペアのうちの公開鍵に対応する。

宣言が真正かつ有効である場合、第１のステークホルダは、ユーザ１に属するデバイスが盗まれたことを示すアサーションを用意することができる。アサーションは、以下から成る可能性がある：
− ＩｏＴデバイスが「盗難」されたことを示す指示。
− 例えば、ユーザ１の公開鍵といった、所有者の識別子。
− 例えば、ＩｏＴデバイスの公開鍵といった、デバイスの識別子。
− アサーションリクエストを受信したステークホルダによって、このステークホルダの秘密鍵を使用して生成される署名。

署名済のアサーションはその後、第２のステークホルダによって分散型データベース上で、例えば、図２によって示されるような署名済の集約アサーションブロック内に公開される。

したがって、分散型データベースにアクセスできる任意のアクタは、デバイスの現在の所有権およびステータスをチェックすることができる６０３。

例えば、デバイスの将来の買手は、デバイスの合法的な所有者であるユーザ１によって、デバイスが紛失した／盗まれたと宣言されたかどうかを確かめることができる。

また、所与のデバイスが紛失した／盗まれたとデバイスの所有者によって宣言されたことを警察が検知することができ、デバイスの何らかの使用が不法であるとみなされる可能性がある。

警察および保険会社はシステムの一部であってよく、使用に不適正なデバイスを宣言することができる。結果として、デバイスを見つけた人は誰でも、デバイスを警察に報告するか、またはデバイスを保険会社に返すことが奨励される。

さらにＩｏＴデバイスは、分散型データベースにアクセスすることによって、ＩｏＴデバイス自体のステータスをチェックすることができる６０４。これは、特定のイベントが発生した時にデバイスのスイッチが入るか、または切られるときに周期的に行われてよい。

デバイスが紛失したと宣言されたことを、デバイスが発見する場合６０４、デバイスは、デバイスが再びオンラインになっていること、およびデバイスが、ユーザ１からのさらなる命令を待っていることを示すアラートメッセージ６０５をユーザ１に送信することができる。

さらに、ＩｏＴデバイスは最小サービスに移行し、ＩｏＴデバイスの合法的な所有者であるユーザ１からの新しい命令を待つことができる。

ユーザ１は、例えば、ユーザ１がデバイスを見つけて取り戻した場合、再アクティベート命令をデバイスに直接送信することによって、デバイスを再アクティベートすることを決めることができる。これは、ステータスを盗難から通常に変更するために、アサーションリクエストをデータベースに送信するようにデバイスをトリガする。

Claims (12)

1. 複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内でアサーションを公開することによって、接続デバイスのステータスを管理するための方法であって、
   − 第１のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを、前記第１のユーザに関連付けられた第１の端末から接続デバイスによって受信するステップ（５０１）であって、前記ステータス情報が、接続デバイスの所有権を管理するために使用される、ステップ（５０１）と、
   − 第１のユーザが接続デバイスのステータスの修正を認められることを、接続デバイスによって検証し（５０２）、肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意するステップであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名される、ステップと、
   − ステータス情報を含むアサーションを公開するために、アサーションリクエストを不変分散型データベースに接続デバイスによって送信するステップ（５０３）であって、接続デバイスに関連付けられた公開鍵を使用して分散型不変データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開される、ステップ（５０３）と
   を行うステップを含む方法。
2. ステータス情報のステータス情報が、接続デバイスの新しい所有者の識別子を含む、請求項１に記載の方法。
3. 新しい所有者の識別子が、公開鍵と秘密鍵を含むペアの鍵に属する公開鍵であり、前記鍵のペアが、接続デバイスの新しい所有者のものである、請求項２に記載の方法。
4. 命令メッセージが、接続デバイスの以前の所有者の識別子と、合法的な所有者として新しい所有者を示す不変分散型データベース内のアサーションの公開により以前の所有者を新しい所有者に置き換えるための指示とを含む、請求項２または３記載の方法。
5. 受信された命令メッセージ（５０１）が秘密データを含み、第１のユーザと接続デバイスが同じ秘密を共有していることを示す、接続デバイスに格納された秘密データと、受信された秘密データが一致する場合、第１のユーザが、接続デバイスのステータスの修正を認められるものとみなされる、請求項１から４のいずれか一項に記載の方法。
6. 接続デバイスの所有権が、第２のユーザが新しい所有者になるように第１のユーザから第２のユーザに移譲され、移譲が、肯定応答メッセージを第１の端末に送信することによって第２のユーザが関連付けられる第２の端末を使用して第２のユーザによって始められ、前記肯定応答メッセージが、接続デバイスの所有権を第２のユーザに移譲するための少なくとも命令、および第２のユーザの識別子を含む、請求項２から５のいずれか一項に記載の方法。
7. 接続デバイスの所有権が、第１のユーザが新しい所有者になるように第２のユーザから第１のユーザに移譲され、移譲が、肯定応答メッセージを第１の端末に送信することによって第２のユーザが関連付けられる第２の端末を使用して第２のユーザによって始められ、前記肯定応答メッセージが、接続デバイスの所有権を第１のユーザに移譲するための少なくとも命令、および第２のユーザの識別子を含む、請求項２から５のいずれか一項に記載の方法。
8. 接続デバイスが、第１のユーザが接続デバイスの合法的な所有者であることを公開アサーションが示す場合、接続デバイスの所有権記録、または不変分散型データベース内の所有権記録をチェックすることによって、第１のユーザが接続デバイスのステータスの修正を認められることを、検証する、請求項１から７のいずれか一項に記載の方法。
9. 命令メッセージが、アプリケーションがインストールされる第１の端末から受信され、前記アプリケーションが、命令メッセージの用意を制御するように構成される、請求項１から８のいずれか一項に記載の方法。
10. 接続デバイスが、不変分散型データベース内で公開される接続デバイスのステータス情報を読むために不変分散型データベースにリクエストを送信し、それに応じて前記ステータス情報を受信する、請求項１から９のいずれか一項に記載の方法。
11. 接続デバイスが盗まれたか、または紛失したことを、受信されたステータス情報が示す場合、接続デバイスが、最小サービスモードに切り替え、接続デバイスの合法的な所有者からの命令の受信を待つ、請求項１０に記載の方法。
12. 複数の計算ノード、接続デバイスと関連付けられた公開鍵と秘密鍵を含むペアの鍵から成る不変分散型データベース内に公開されたアサーションを読むことによって、第三者からアクセス可能なステータス情報に関連付けられる接続デバイスであって、
    − 第１のユーザの識別子、および接続デバイスに対して考慮されるべき少なくともステータス情報を含む命令メッセージを受信することであって、前記ステータス情報が、接続デバイスの所有権を管理するために使用されることと、
    − 第１のユーザが接続デバイスのステータスの修正を認められることを、検証し、肯定的検証の場合、ステータス情報を含むアサーションリクエストを用意することであって、アサーションリクエストが、接続デバイスの秘密鍵を使用して、接続デバイスによって署名されることと、
    − ステータス情報を含むアサーションを公開するために不変分散型データベースにアサーションリクエストを送信することであって、接続デバイスに関連付けられた公開鍵を使用して不変分散型データベースの計算ノードによって署名が肯定的に検証されるとアサーションが公開されることと
    を行うように構成される、接続デバイス。

Images