JP7376695B2 - 輸送装置ソフトウェアアップデートの管理 - Google Patents

Description

自動車、オートバイ、トラック、飛行機、列車などのような車両(vehicles)または輸送装置(transports)は、一般的には、乗車人および／または品物に対して多様な方法で輸送の需要を提供する。輸送装置に関する機能は、スマートフォン、コンピュータ、またはタブレットなどのような種々の演算処理装置により識別および利用できる。

輸送装置に対するソフトウェアアップデートは、一般的には、各個々の輸送装置クライアントコンピュータにソフトウェアアップデートを提供する中央サーバにより実行される。これは一般的には、クラウドへのネットワーク接続を必要とする。しかし、ソフトウェアアップデートを配布する(distribute)ためのＷＡＮの過度の使用は効率的ではなく、安全でないこともあり得る。追加的に、ソフトウェアアップデートは、サーバにより送られる前に、十分に多くの数の輸送装置により十分にテストされてないこともあり得る。何百万もの輸送装置からのソフトウェアアップデートに関する情報を収集でき、それを安全且つ効率的に追尾できる中央集中型システムは存在していない。

従って、多数の輸送装置による広範囲のテストに基づく輸送装置ソフトウェアアップデートの安全な配布方法(propagation)を有することが所望される。また、共有ストレージに記録されているソフトウェアアップデートに関する情報を有することも所望される。

１つの例としての実施形態は、輸送装置のサブセットの輸送装置においてソフトウェアアップデートを受信することと、ソフトウェアアップデートが使用されていた時間期間と輸送装置のサブセットによるソフトウェアアップデートの利用回数の１つ以上に基づいてソフトウェアアップデートを有効化することと、有効化に基づいてソフトウェアアップデートを、輸送装置のサブセットよりも大きな、輸送装置の更なるサブセットに配布する(propagating)ことの１つ以上を含んでいる方法を提供できる。

他の例としての実施形態は、輸送装置のサブセットの第１輸送装置と、輸送装置の更なるサブセットの第２輸送装置が近接しているときに、マスタ輸送装置により、ソフトウェアアップデートの第１部分を、輸送装置の第１サブセットの輸送装置に送ることと、マスタ輸送装置により、マスタ輸送装置により、ソフトウェアアップデートの第２部分を、輸送装置の更なるサブセットの輸送装置に送ることと、第１輸送装置に、ソフトウェアアップデートの第１部分を第２輸送装置に送らせることと、第２輸送装置に、ソフトウェアアップデートの第２部分を第１輸送装置に送らせることとの１つ以上を含んでいる方法を提供できる。

更なる他の例としての実施形態は、輸送装置においてソフトウェアアップデートを受信することと、最も少ない量の潜在的相互作用を含んでいる第１環境において、ソフトウェアアップデートの第１有効化を実行することと、第１有効化が成功した場合、第１環境よりも多い量の潜在的相互作用を含んでいる更なる環境において、ソフトウェアアップデートの更なる有効化を実行することの１つ以上を含んでいる方法を提供できる。

他の例としての実施形態は、プロセッサとメモリを含んでいるシステムを提供でき、輸送装置のサブセットの輸送装置のプロセッサは、ソフトウェアアップデートを受信することと、ソフトウェアアップデートが使用されていた時間期間と輸送装置のサブセットによるソフトウェアアップデートの利用回数の１つ以上に基づいてソフトウェアアップデートを有効化することと、有効化に基づいてソフトウェアアップデートを、輸送装置のサブセットよりも大きな、輸送装置の更なるサブセットに配布することの１つ以上を実行するように構成されている。

他の例としての実施形態は、プロセッサとメモリを含んでいるシステムを提供でき、マスタ輸送装置のプロセッサは、輸送装置のサブセットの第１輸送装置と、輸送装置の更なるサブセットの第２輸送装置が近接しているときに、ソフトウェアアップデートの第１部分を、輸送装置の第１サブセットの輸送装置に送ることと、ソフトウェアアップデートの第２部分を、輸送装置の更なるサブセットの輸送装置に送ることと、第１輸送装置に、ソフトウェアアップデートの第１部分を第２輸送装置に送らせることと、第２輸送装置に、ソフトウェアアップデートの第２部分を第１輸送装置に送らせることとの１つ以上を実行するように構成されている。

更に他の例としての実施形態は、プロセッサとメモリを含んでいるシステムを提供でき、プロセッサは、輸送装置においてソフトウェアアップデートを受信することと、最も少ない量の潜在的相互作用を含んでいる第１環境において、ソフトウェアアップデートの第１有効化を実行することと、第１有効化が成功した場合、第１環境よりも多い量の潜在的相互作用を含んでいる更なる環境において、ソフトウェアアップデートの更なる有効化を実行することの１つ以上を実行するように構成されている。

更なる例としての実施形態は、命令を備えている非一時的コンピュータ可読媒体を提供し、命令はプロセッサにより読み込まれるとプロセッサに、ソフトウェアアップデートを受信することと、ソフトウェアアップデートが使用されていた時間期間と輸送装置のサブセットによるソフトウェアアップデートの利用回数の１つ以上に基づいてソフトウェアアップデートを有効化することと、有効化に基づいてソフトウェアアップデートを、輸送装置のサブセットよりも大きな、輸送装置の更なるサブセットに配布することの１つ以上を実行させる。

更なる例としての実施形態は、命令を備えている非一時的コンピュータ可読媒体を提供し、命令はプロセッサにより読み込まれるとプロセッサに、輸送装置のサブセットの第１輸送装置と、輸送装置の更なるサブセットの第２輸送装置が近接しているときに、ソフトウェアアップデートの第１部分を、輸送装置の第１サブセットの輸送装置に送ることと、ソフトウェアアップデートの第２部分を、輸送装置の更なるサブセットの輸送装置に送ることと、第１輸送装置に、ソフトウェアアップデートの第１部分を第２輸送装置に送らせることと、第２輸送装置に、ソフトウェアアップデートの第２部分を第１輸送装置に送らせることとの１つ以上を実行させる。

更なる例としての実施形態は、命令を備えている非一時的コンピュータ可読媒体を提供し、命令はプロセッサにより読み込まれるとプロセッサに、ソフトウェアアップデートを受信することと、最も少ない量の潜在的相互作用を含んでいる第１環境において、ソフトウェアアップデートの第１有効化を実行することと、第１有効化が成功した場合、第１環境よりも多い量の潜在的相互作用を含んでいる更なる環境において、ソフトウェアアップデートの更なる有効化を実行することの１つ以上を実行させる。

例としての実施形態に従う輸送装置ネットワーク図を例示している。 例としての実施形態に係る輸送装置ノードを含んでいる例としてのネットワーク図を示している。 例としての実施形態に係る輸送装置ノードを含んでいる他の例としてのネットワーク図を示している。 例としての実施形態に係る輸送装置ノードを含んでいる他の例としてのネットワーク図を示している。 例としての実施形態に係るブロックチェーンアーキテクチャ構成を例示している。 例としての実施形態に係る他のブロックチェーン構成を例示している。 例としての実施形態に係るブロックチェーントランザクションデータを格納するためのブロックチェーン構成を例示している。 例としての実施形態に係るフロー図を例示している。 例としての実施形態に係る他のフロー図を例示している。 例としての実施形態に係る更なるフロー図を例示している。 例としての実施形態に係る更なるフロー図を例示している。 例としての実施形態に係る更なるフロー図を例示している。 例としての実施形態に係る更なるフロー図を例示している。 例としての実施形態に係る、車両と関連付けられているブロックチェーントランザクションを管理するための例としてのブロックチェーン車両構成を示している。 例としての実施形態に係る、サービスセンタと車両との間のブロックチェーントランザクションを管理するための他の例としてのブロックチェーン車両構成を示している。 例としての実施形態に係る、種々の車両間で実行されるブロックチェーントランザクションを管理するための更に他の例としてのブロックチェーン車両構成を示している。 例としての実施形態に係る例としてのデータブロックを示している。 例としての実施形態の１つ以上をサポートする例としてのシステムを示している。

ここにおいて、図において全体的に記述および例示されているように、実例としての構成要素は、広く多様な異なる構成において配置および設計できるということは容易に理解されるであろう。そのため、付随する図において表わされているように、方法、装置、非一時的コンピュータ可読媒体、およびシステムの少なくとも１つの実施形態の下記の詳細な記述は、請求される本願の範囲を制限することは意図されておらず、選択された実施形態の単なる代表例である。

この明細書を通して記述されているように、実例としての特徴、構造、または特性は、１つ以上の実施形態において任意の適切な方法で組み合わせることができる。例えば、「例としての実施形態」、「幾つかの実施形態」というフレーズ、または他の類似の語句の使用は、少なくともこの明細書を通しては、実施形態と関連して記述される特別な特徴、構造、または、特性を、少なくとも１つの実施形態に含むことができるという事実のことを指している。そのため、「例としての実施形態」、「幾つかの実施形態においては」、「他の実施形態においては」というフレーズ、または他の類似の語句の登場は、この明細書を通して、実施形態の同じグループを必ずしも指してはおらず、記述されている特徴、構造、または特性は、１つ以上の実施形態において任意の適切な方法で組み合わせることができる。図において、要素間の何れの接続も、記述されている接続が１方向または双方向矢印であっても、１方向および／または双方向を許可できる。本願においては、輸送装置は、自動車、トラック、オートバイ、スクータ、自転車、ボート、レクリエーション用車両、飛行機、および、人間および／または品物をある場所から他の場所に輸送するために使用できる任意の対象物を含むことができる。

加えて、実施形態の記述において、「メッセージ」という用語が使用されているが、本願は、パケット、フレーム、データグラムなどのような多くのタイプのネットワークデータに適用できる。「メッセージ」という用語はまた、パケット、フレーム、データグラム、およびその任意の等価物を含んでいる。更に、あるタイプのメッセージと信号を、例としての実施形態のおいて示すことができるが、それらはあるタイプのメッセージに制限されず、本願は、あるタイプの信号に制限されない。

例としての実施形態は、方法、システム、構成要素、非一時的コンピュータ可読媒体、装置、および／またはネットワークを提供し、それらは、輸送装置（ここにおいては、車両とも称される）、データ収集システム、データ監視システム、有効化システム、認可システム、および車両データ配信システムの少なくとも１つを提供する。無線データネットワーク通信、および／または有線通信メッセージなどのような、通信アップデートメッセージの形状で受信した車両ステータス状態データは、車両／輸送装置ステータス状態を識別して、輸送装置の状態変化に関するフィードバックを提供するために受信且つ処理できる。１つの例においては、ユーザプロファイルを、現在の車両イベント、サービスステーションにおけるサービスのための停止を認可し、後続する車両レンタルサービスを認可するために特別な輸送装置／車両に適用できる。

通信インフラストラクチャ内で、非中央集中型データベースは、分散型ストレージシステムであり、お互いに通信する複数のノードを含んでいる。ブロックチェーンは、非中央集中型データベースの例であり、信頼性を有しない関係者間の記録を維持できる、追加専用不変データ構造（つまり、分散型台帳）を含んでいる。ここにおいては、信頼性を有しない関係者は、ピア、ノード、またはピアノードと称される。各ピアは、データベースの記録のコピーを維持し、単一のピアでは、分散しているピアの間でのコンセンサスが取れない限り、データベース記録を修正できない。例えば、ピアは、ブロックチェーンストレージエンティティを有効化し、ストレージエンティティをブロックにグループ化し、ブロックを介してハッシュチェーンを構築するためにコンセンサスプロトコルを実行できる。このプロセスは、必要であれば、一貫性のために、ストレージエンティティを順序付けすることにより台帳を形成する。公共または認可不要ブロックチェーンにおいては、特定のアイデンティティがなくても誰でも参加できる。公共ブロックチェーンは暗号通貨を含むことができ、プルーフオブワーク（ＰｏＷ）などのような種々のプロトコルに基づいてコンセンサスを使用できる。一方、許可されたブロックチェーンデータベースは、共通の目標を共有するが、ファンド、品物、情報などを交換するビジネスなどのような、互いに完全には信頼していない、または信頼できないエンティティのグループ間の相互作用を確実にできるシステムを提供する。実例としての適用は、許可された、および／または、許可不要ブロックチェーン設定において機能できる。

スマートコントラクトは、共有または分散化台帳（つまり、ブロックチェーンの形状であってよい）データベースの耐改竄特性と、エンドースメントまたはエンドースメントポリシーと称されるメンバノード間の基盤となる合意を利用する信頼性のある分散型アプリケーションである。一般的に、ブロックチェーンエンティティは、ブロックチェーンに投入される前にエンドースされるが、一方、エンドースされないエントリは無視される。典型的なエンドースメントポリシーは、スマートコントラクト実行可能コードが、エンドースメントのために必要なピアノードのセットの形状のエントリに対するエンドーサを特定することを可能にする。クライアントがエントリを、エンドースメントポリシーにおいて特定されたピアに送ると、エントリはエントリを有効化するために実行される。有効化の後、エントリはオーダリングフェーズに入り、コンセンサスプロトコルが、ブロックにグループ化されたエンドースされたエントリの順序付けられたシーケンスを生成するために使用される。

ノードは、ブロックチェーンシステムの通信エンティティである。「ノード」は、複数の異なるタイプのノードが同じ物理サーバ上で動作できるという意味において論理機能を実行できる。ノードはトラストドメインにおいてグループ化され、ノードを種々の方法で制御する論理エントリと関連付けられる。ノードは、エントリ呼出しをエンドーサ（例えば、ピア）提出し、エントリ提案をオーダリングサービス（例えば、オーダリングノード）にブロードキャストするクライアントまたは提出クライアントなどのような異なるタイプを含むことができる。他のタイプのノードはピアノードであり、ピアノードはクライアントから提出されたエントリを受信でき、エントリを投入し、ブロックチェーンエントリの台帳の状態とコピーを維持できる。ピアはまたエンドーサの役割も有することができるが、それは必要条件ではない。オーダリングサービスノードまたはオーダラは、すべてのノードに対する通信サービスを動作させているノードであり、エントリを投入し、通常は制御と設定情報を含んでいる、初期ブロックチェーンエントリの別名でもある、ブロックチェーンのワールド状態を修正するときに、システムにおけるピアノードのそれぞれに対するブロードキャストなどのようなデリバリの保証を実現する。

台帳は、ブロックチェーンのすべての状態遷移の順序付けられた、耐改竄性記録である。状態遷移は、参加している関係者（例えば、クライアントノード、オーダリングノード、エンドーサノード、ピアノードなど）により提出された、スマートコントラクト実行可能コード呼出し（つまり、エントリ）から起因することができる。エントリは、ｃｒｅａｔｅｓ（作成）、ｕｐｄａｔｅｓ（更新）、ｄｅｌｅｔｅｓ（削除）などのような１つ以上のオペランドとして台帳に投入されている資産キーバリューペアのセットという結果になることができる。台帳はブロックチェーン（チェーンとも称される）を含んでおり、ブロックチェーンは、不変の、順序付けられた記録をブロックに格納するために使用される。台帳はまた状態データベースも含んでおり、状態データベースは、ブロックチェーンの現在の状態を維持している。典型的には、１つのチャネル当たり１つの台帳がある。各ピアノードは、自身がメンバである各チャネルに対する台帳のコピーを維持している。

チェーンはエントリログであり、ハッシュとリンクされたブロックとして構造化されており、各ブロックは、Ｎ個のエントリのシーケンスを含んでおり、ここにおいてＮは１以上である。ブロックヘッダは、先行するブロックヘッダのハッシュと共に、ブロックエントリのハッシュも含んでいる。このようにして、台帳上のすべてのエントリは順序付けることができ、暗号的に互いにリンクさせることができる。従って、ハッシュリンクを破壊しない限り台帳を改竄することはできない。最も現時点に近い時点で追加されたブロックチェーンブロックのハッシュは、その前に来たチェーン上のすべてのエントリを表現し、すべてのピアノードは、一貫性があり、信頼性のある状態であることを確実にすることを可能とする。チェーンはピアノードファイルシステム（つまり、ローカルな付与されたストレージ、クラウドなど）に格納でき、ブロックチェーンワークロードの追加専用の性質を効率よくサポートする。

不変台帳の現在の状態は、チェーンエントリログに含まれているすべてのキーに対する最新の値を表わしている。現在の状態が、チャネルには既知の最新のキーバリューを表わしているので、それは、ワールド状態と称されることもある。スマートコントラクト実行可能コード呼出しは、台帳の現在の状態データに対してエントリを実行する。これらのスマートコントラクト実行可能コード相互作用を効率的にするために、キーの最新の値を状態データベースに格納できる。状態データベースは、チェーンのエントリログへの単なるインデックス付きビューであり得るので、従って、それは、いつでもチェーンから再生成できる。状態データベースは、ピアノードが起動したとき、そしてエントリが容認される前に自動的に回復できる（または、必要であれば、再生成できる）。

ブロックチェーンは従来のデータベースとは、ブロックチェーンが中央集中型ストレージではなく、ノードは、ストレージにおけるレコードの変化を共有しなくてはならない非中央集中型、不変、および安全ストレージであるということにおいて異なっている。ブロックチェーンに固有で、ブロックチェーンを実現することにおいて支援する幾つかの特性としては、下記に制限されないが、不変台帳、スマートコントラクト、セキュリティ、プライバシ、非中央集中化、コンセンサス、エンドースメント、アクセス可能性などがある。

例としての実施形態は、車両サービスを特別な車両に提供し、および／または、車両に適用されたユーザプロファイルと関連付けられているユーザにリクエストするための方法を提供する。例えば、ユーザは車両の所有者、または他の関係者により所有されている車両の運転手であってよい。車両は、ある間隔でサービスを要求でき、サービス需要は、サービスが受信されることを許可する前に認可を要求できる。また、サービスセンタは、車両の現在のルートプランと、サービスの必要条件の相対的レベル（例えば、即座の、厳しい、中間的な、重要でないなど）に基づいて、近くの領域における車両にサービスを提供できる。車両の需要は、１つ以上のセンサにより監視でき、そのセンサは、車両における中央コントローラコンピュータ装置に感知されたデータを報告し、その結果として、それは調査および行動のために管理サーバに転送される。

センサは、輸送装置の内部、輸送装置の外部、輸送装置とは離れている固定された対象物の上、および、輸送装置に近い他の輸送装置上の１つ以上に位置させることができる。センサはまた、輸送装置の速度、輸送装置の制動、輸送装置の加速、燃料レベル、サービス需要、輸送装置のギアシフト、輸送装置のステアリングなどとも関連付けることができる。センサの概念はまた、モバイル装置などのような装置であってもよい。また、センサ情報は、車両が安全に動作しているかどうか、および、同乗者が、車両のアクセス期間などのような、予期せぬ車両状態に巻き込まれてしまったかどうかを識別するためにも使用できる。車両の動作の前、その間、および／または、その後に収集された車両情報は、共有／分散型台帳上のトランザクションにおいて識別且つ格納でき、それは、ブロックチェーンメンバシップグループを介してなどのように、許可認定協会により決定されているように、そしてそのため「非中央集中型」の方法で再生成でき、不変台帳に投入できる。各利害関係者（つまり、会社、機関など）は、私的情報の開示を制限したいと所望することもできるので、従って、ブロックチェーンとその不変性は開示を制限でき、各特別なユーザ車両プロファイルに対する許可を管理できる。スマートコントラクトを、補償を提供し、ユーザプロファイルのスコア／格付け／評価を定量化し、車両イベント許可を適用し、サービスがいつ必要かを決定し、衝突および／または退化イベントを識別し、安全性に関するイベントを識別し、イベントへの関係者を識別し、および、そのような車両イベントデータへのアクセスを求める登録されているエンティティに配信を提供するために使用できる。また、結果は識別でき、必要な情報は、ブロックチェーンと関連付けられている「コンセンサス」アプローチに基づいて、登録されている会社および／または個人の間で共有できる。そのようなアプローチは、従来の中央集中型データベースでは実現できなかった。

すべての自律運転システムは、ソフトウェアの全体スーツおよびセンサのアレイに内蔵されている。機械学習、ライダープロジェクタ、レーダー、および超音波センサはすべて、自己運転自動車が走行できる世界のリビングマップを作成するために共に働く。完全自律への競争の中にいるほとんどの会社は、幾つかの優れた例外はあるが、ライダー＋レーダー＋カメラ＋超音波の同じ基本的な技術基盤に依存している。

他の実施形態においては、ＧＰＳ、マップ、および他のカメラとセンサがライダーのない自律車両において使用されているが、これは、ライダーが高価で不要なものと見なされることがよくあるからである。研究者は、立体カメラは、より高価なライダー機能に対する低コストの代替品であると決定している。

実例としての適用は、ある実施形態において、自動化されている迅速認証スキームを介してサービスに対して車両を許可することを含んでいる。例えば、充電ステーションまたは燃料ポンプまで運転することは、車両の運転手により実行でき、充電または燃料を受けることに対する認可は、その認可がサービスステーションにおいて受信されるのであれば遅延なく実行できる。車両は、サービスを受けることが認可され、後で補償により調整できるアカウントとリンクされている現在アクティブなプロファイルを有する車両のＩＤを提供する通信信号を提供できる。他の識別子をユーザの装置から無線で、輸送装置とサービスセンタとの間の第１認可努力を、追加的な認可努力で置換またはそれで補充するためにサービスセンタに送ることができるような、追加的な手段を更なる認可を提供するために使用できる。

共有され受信されたデータはデータベースに格納でき、データベースは単一のデータベース（例えば、データベースサーバ）で、一般的には１つの特別な位置においてデータを維持する。この位置は、例えば、デスクトップ中央演算処理装置（ＣＰＵ）、サーバＣＰＵ、またはメインフレームコンピュータなどの中央コンピュータであることがよくある。中央集中型データベースに格納されている情報は、典型的には複数の異なるポイントからアクセス可能である。中央集中型データベースは、その単一の位置のために、特に、セキュリティの目的のためには、管理、維持、および制御することが容易である。中央集中型データベース内では、すべてのデータの単一の格納場所はまた、データの所与のセットは１つの主要な記録しか有していないことも意味するので、データの冗長性は最小となる。

例としての実施形態によれば、ＷＡＮ技術を使用しない、ソフトウェアアップデートの車両への配布が提供される。１つの例としての実施形態は、輸送装置の第１セットによりテストが実行された後でのみ、ソフトウェアアップデートが配布されることを可能にする。テストは、ある時間期間において実行でき、または、ソフトウェアアップデートコードの多数の回数の実行において実行できる。ソフトウェアのテストが失敗すると、輸送装置には警報が出され、輸送装置のソフトウェアは、以前のソフトウェアバージョンに戻ることができる。

他の実施形態においては、マスタ輸送装置システムは、ソフトウェアアップデートを車両に配布するときに、ソフトウェアアップデートを少なくとも２つの部分に分割し、ソフトウェアアップデート部分を異なる時間および／または異なるソースから送ることにより追加的なセキュリティを可能にすることができる。１つの例としての実施形態においては、ソフトウェアアップデートは、まずマスタ輸送装置から送ることができる。例としての実施形態は、ブロックチェーン技術を介するアップデートの認可を伴うソフトウェアアップデートの非中央集中型配布を提供できる。

例としての実施形態によれば、マスタ輸送装置は、ソフトウェアアップデートの何れの部分を何れの輸送装置に与えるかを、輸送装置の特性（例えば、輸送装置のセキュリティレベル、輸送装置の使用年月、ソフトウェアを適切に実行できる輸送装置におけるハードウェア、輸送装置の状態、輸送装置のユーザ／同乗者の特性、輸送装置における、または輸送装置に関連する特徴の使用）に基づいて決定できる。アップデートは、アップデートの可能性のある使用法、例えば、何れの輸送装置が、ソフトウェアアップデートをより良好にテスト／利用できるかに基づいて提供できる。１つの例においては、車両１はアップデートの第１部分（ＡＢＣ）を、車両２はアップデートの他の部分（ＡＢＣ’）を、同じマスタ輸送装置から得ることができる。ソフトウェアアップデートは、３つ以上の部分に分割でき、例えば、幾つかの輸送装置は２つの部分を、幾つかの輸送装置は３つの部分を、そして幾つかの輸送装置はｎ個の部分を受信できる。マスタ輸送装置は、輸送装置のサブセットおよび輸送装置の更なるサブセットより高いセキュリティのレベルを有することができる。ソフトウェアアップデートの如何なる問題もマスタ輸送装置に報告できる（マスタ輸送装置はそれを中央サーバに報告できる）。何れかの部分に、または、アップデートの収集された第１および第２部分に問題が起こると、マスタ輸送装置を、問題が起きた輸送装置の近くの移動させることができ、問題を決定して解決するためにその輸送装置を監視できる。

更なる他の例としての実施形態においては、ソフトウェアアップデートが受信され、収集され、そして実行されると、輸送装置は古いソフトウェアバージョンの起動を継続し、潜在的な問題が最も少ない状況において、新しいアップデートされたソフトウェアを間欠的に使用する。例えば、アップデートが制動ソフトウェアアップデートに対してなされた場合、輸送装置は、アップデートされたソフトウェアを、運転環境において最も交通量が少ないとき（そして、歩行者および／または対象物がないとき）に使用できる。アップデートされたソフトウェアがこの運転環境において有効化されると、輸送装置は、異なる潜在的に問題がある運転環境（例えば、より交通量が多い、歩行者、および／または対象物がある環境）においてそのアップデートされたソフトウェアを使用できる。例としての実施形態によれば、輸送装置の運転手は、ソフトウェアアップデート管理アプリケーションの機能に気付いていない可能性がある。輸送装置のシステムは、ソフトウェアアップデートを異なる環境において少しずつ回数を増やしながらテストし、必要であれば、ソフトウェアの以前のバージョンに戻ることができる。

更に他の実施形態においては、マスタ輸送装置は、何れの部分を何れの輸送装置に与えるかを、輸送装置の特性（例えば、輸送装置のセキュリティレベル、輸送装置の使用年月、ソフトウェアを適切に実行できる輸送装置におけるハードウェア、輸送装置の状態、輸送装置のユーザ／同乗者の特性、輸送装置における、または輸送装置に関連する特徴の使用）に基づいて決定できる。アップデートは、アップデートの可能性のある使用法、例えば、何れの輸送装置が、ソフトウェアをより良好にテスト／利用できるかに基づくことができる。

更なる実施形態においては、異なる車両は、提出された時間または日付、車両および／またはソフトウェアおよび／またはユーザの特性に基づいて、ソフトウェアの部分を集めることができる。例えば、車両１は第１部分（ＡＢＣ）を得ることができ、まさに次の送信で、車両２は第１部分（ＡＢＣ’）を同じマスタ輸送装置から得ることができる（つまり、第１部分は異なることができる）。

更なる実施形態においては、ソフトウェアアップデートは、３つ以上の部分に分割できる。幾つかの輸送装置は２つの部分、幾つかの輸送装置は３つの部分、幾つかの輸送装置はｎ個の部分を受信できる。

更なる実施形態においては、マスタ輸送装置は、輸送装置のサブセットと輸送装置の更なるサブセットよりも高いセキュリティのレベル、ソフトウェアアップデートの第１部分、およびソフトウェアアップデートの第２部分の１つ以上を備えている。

更なる実施形態においては、ソフトウェアについての如何なる問題も、マスタ輸送装置に報告される（そして、中央サーバに報告できる）。

更なる実施形態においては、アップデートの何れかの部分、または集められた第１および第２部分で問題が起こると、マスタ輸送装置は、問題のある輸送装置に近接することができ、問題を監視および問題にアクセスできる。

図１Ａは、例としての実施形態に従う、輸送装置ネットワーク図１００を例示している。１つの例としての実施形態によれば、輸送装置（例えば、１０５）のサブセットの輸送装置のプロセッサ１０４’は、ソフトウェアアップデートを受信するように構成できる。ソフトウェアアップデートは、マスタ輸送装置ノード（例えば、１０２）により提供できる。プロセッサ１０４’は、輸送装置（例えば、１０５）によりソフトウェアアップデートが使用されていた時間期間に基づいてソフトウェアアップデートを有効化できる。１つの例においては、プロセッサ１０４’は、輸送装置（例えば、１０５）のサブセットによるソフトウェアアップデートの利用回数に基づいてソフトウェアアップデートを有効化できる。プロセッサ１０４’は有効化に基づいて、ソフトウェアアップデートを輸送装置（例えば、１０７）の更なるサブセットに配布できる。輸送装置１０７のサブセットは輸送装置１０５のサブセットよりも大きい。

他の例としての実施形態によれば、マスタ輸送装置１０２のプロセッサ１０４は、ソフトウェアアップデートの第１部分を、輸送装置１０５の第１サブセットの輸送装置に送るように構成できる。マスタ輸送装置１０２のプロセッサ１０４は、ソフトウェアアップデートの第２部分を、輸送装置１０７の更なるサブセットの輸送装置に送ることができる。そして、輸送装置１０５のサブセットの第１輸送装置と、輸送装置１０７の更なるサブセットの第２輸送装置が近接しているときに、プロセッサ１０４は、ソフトウェアアップデートの第１部分を第２輸送装置１０７に送らせるコマンドを第１輸送装置１０５に送ることができる。そして、プロセッサ１０４は、ソフトウェアアップデートの第２部分を第１輸送装置１０５に送らせるコマンドを第２輸送装置に送ることができる。そのため、それぞれの輸送装置１０５と１０７のプロセッサ１０４’と１０４”は、完全なソフトウェアアップデートを集めることができる。

更なる例としての実施形態によれば、プロセッサ１０４’（または１０４”）は、ソフトウェアアップデートを受信し（例えば、マスタ輸送装置１０２から）、第１環境においてソフトウェアアップデートの第１有効化を実行するように構成できる。第１環境は、最も少ない量の潜在的相互作用（最少の交通量、歩行者がいない、通常の天候条件など）を含むことができる。そして、プロセッサ１０４’（または１０４”）は、第１有効化が成功した場合、更なる環境において、ソフトウェアアップデートの更なる有効化を実行できる。更なる環境は、第１環境よりも多い量の潜在的相互作用を含むことができる（例えば、より多い交通量、歩行者、困難な天候条件など）。

図１Ｂは、ソフトウェアアップデートの管理のためのネットワーク図を例示している。図１Ｂを参照すると、ネットワーク図１１１は、ブロックチェーンネットワーク１０６を介して輸送装置ノード１０５の他のサブセットに接続されている輸送装置ノード１０２のサブセットを含んでいる。輸送装置ノード１０２と１０５は輸送装置／車両であることができる。ブロックチェーンネットワーク１０６は、ソフトウェアアップデートのタイムスタンプを含んでいる、ソフトウェアアップデート関連のデータなどのようなデータを格納するための台帳１０８を有することができる。輸送装置ノード１０２は、輸送装置ノード（示されていない）の他のサブセットに接続できる。

この例は、１つの輸送装置ノード１０２のみを詳細に記述しているが、複数のそのようなノードをブロックチェーン１０６に接続できる。ここにおいて開示されている輸送装置ノード１０２の範囲から逸脱することなく、輸送装置ノード１０２は追加的な構成要素を含むことができ、ここにおいて記述されている構成要素の幾つかは除去および／または修正できるということは理解されるべきである。輸送装置ノード１０２は、演算処理装置またはサーバコンピュータなどを有することができ、半導体に基づくマイクロプロセッサであってよいプロセッサ１０４、中央演算処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および／または他のハードウェア装置を含むことができる。単一のプロセッサ１０４が示されているが、輸送装置ノード１０２は、複数のプロセッサ、複数のコアなどを、輸送装置ノード１０２システムの範囲から逸脱することなく含むことができるということは理解されるべきである。

輸送装置ノード１０２はまた、プロセッサ１０４により実行可能な機械可読命令を格納できる非一時的コンピュータ可読媒体１１２も含むことができる。機械可読命令の例は、１１４～１１８として示されており、下記において更に検討される。非一時的コンピュータ可読媒体１１２の例としては、実行可能命令を含んでいる、または格納している電子的、磁気的、光学的、または他の物理的格納装置を含むことができる。例えば、非一時的コンピュータ可読媒体１１２は、ランダムアクセスメモリ（ＲＡＭ）、電気的消去可能型プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、ハードディスク、光ディスク、または他のタイプの格納装置であってよい。

プロセッサ１０４は、輸送装置１０４においてソフトウェアアップデートを受信するための機械可読命令１１４を実行できる。輸送装置１０２と１０５のそれぞれは、ブロックチェーン１０６上のネットワークピア（つまり、ノード）として働くことができる。上記で検討したように、ブロックチェーン台帳１０８は、ソフトウェアアップデート関連のトランザクションを格納できる。ブロックチェーン１０６ネットワークは、他の参加輸送装置ノード１０５に対するトランザクションを管理できる輸送装置（つまりノード）１０２上に位置している１つ以上のスマートコントラクトを使用するように構成できる。輸送装置ノード１０２は、台帳１０８に格納される情報をブロックチェーン１０６に提供できる。

プロセッサ１０４は、ソフトウェアアップデートを有効化するための機械可能命令１１６を実行できる。ソフトウェアアップデートは、ソフトウェアアップデートが使用されていた時間期間と輸送装置１０２のサブセットによるソフトウェアアップデートの利用回数に基づいて有効化できる。プロセッサ１０４は、輸送装置（例えば、１０５）の更なるサブセットに、有効化に基づいてソフトウェアアップデートを配布するための機械可読命令１１８を実行できる。輸送装置１０５の更なるサブセットは、輸送装置１０２のサブセットよりも大きい。

図１Ｃは、輸送装置ソフトウェアアップデートの管理のためのネットワーク図を例示している。図１Ｃを参照すると、ネットワーク図１２１は、ソフトウェアアップデート関連のトランザクション１１０を格納するための台帳１０８を有しているブロックチェーンネットワーク１０６を介して、他の輸送装置ノード１０５と１０７に接続されているマスタ輸送装置ノードとして働く輸送装置ノード１０２を含んでいる。輸送装置ノード１０２、１０５、および１０７もまた、ブロックチェーン１０６ピアとして働くことができる。この例は、１つのマスタ輸送装置ノード１０２のみを詳細に記述しているが、複数のそのようなノードをブロックチェーン１０６に接続できる。ここにおいて開示されているマスタ輸送装置ノード１０２の範囲から逸脱することなく、マスタ輸送装置ノード１０２は追加的な構成要素を含むことができ、ここにおいて記述されている構成要素の幾つかは、除去および／または修正できるということは理解されるべきである。マスタ輸送装置ノード１０２は、演算処理装置またはサーバコンピュータなどを有することができ、半導体に基づくマイクロプロセッサであってよいプロセッサ１０４、中央演算処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および／または他のハードウェア装置を含むことができる。単一のプロセッサ１０４が示されているが、マスタ輸送装置ノード１０２は、複数のプロセッサ、複数のコアなどを、マスタ輸送装置ノード１０２システムの範囲から逸脱することなく含むことができるということは理解されるべきである。

マスタ輸送装置ノード１０２はまた、プロセッサ１０４により実行可能な機械可読命令を格納できる非一時的コンピュータ可読媒体１１２’も含むことができる。機械可読命令の例は、１１３～１１７として示されており、下記において更に検討される。非一時的コンピュータ可読媒体１１２’の例としては、実行可能命令を含んでいる、または格納している電子的、磁気的、光学的、または他の物理的格納装置を含むことができる。例えば、非一時的コンピュータ可読媒体１１２’は、ランダムアクセスメモリ（ＲＡＭ）、電気的消去可能型プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、ハードディスク、光ディスク、または他のタイプの格納装置であってよい。

プロセッサ１０４は、ソフトウェアアップデートの第１部分を輸送装置１１３の第１サブセットの輸送装置に送るための機械可読命令１１２’を実行できる。ブロックチェーン１０６は、複数の参加ノード（例えば、１０５と１０７）に対するトランザクションを管理する１つ以上のスマートコントラクトを使用するように構成できる。マスタ輸送装置１０２は、ソフトウェアアップデートに関連する情報をブロックチェーン１０６に提供でき、このトランザクションは、台帳１０８に格納できる。

プロセッサ１０４は、ソフトウェアアップデートの第２部分を輸送装置（例えば、１０７）の更なるサブセットの輸送装置に送るための機械可読命令１１５を実行できる。プロセッサ１０４は、輸送装置１０５のサブセットの第１輸送装置と、輸送装置１０７の更なるサブセットの第２輸送装置が近接しているときに、第１輸送装置に、ソフトウェアアップデートの第１部分を第２輸送装置に送らせ、第２輸送装置１０７に、ソフトウェアアップデートの第２部分を第１輸送装置１０５に送らせるために、機械可読命令１１７を実行できる。

図１Ｄは、輸送装置ソフトウェアアップデートの管理のためのネットワーク図を例示している。図１Ｄを参照すると、ネットワーク図１３０は、ソフトウェア有効化データとトランザクション１１０を格納するための台帳１０８を有している、ブロックチェーンネットワーク１０６を介して他の輸送装置ノード１０５に接続されている輸送装置ノード１０２（例えば、車両）を含んでいる。輸送装置ノード１０２と１０５もまた、ブロックチェーン１０６ピアとして働くことができる。この例は、１つの輸送装置ノード１０２のみを詳細に記述しているが、複数のそのようなノードをブロックチェーン１０６に接続できる。ここにおいて開示されているマスタ輸送装置ノード１０２の範囲から逸脱することなく、マスタ輸送装置ノード１０２は追加的な構成要素を含むことができ、ここにおいて記述されている構成要素の幾つかは除去および／または修正できるということは理解されるべきである。輸送装置ノード１０２は、演算処理装置またはサーバコンピュータなどを有することができ、半導体に基づくマイクロプロセッサであってよいプロセッサ１０４、中央演算処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および／または他のハードウェア装置を含むことができる。単一のプロセッサ１０４が示されているが、輸送装置ノード１０２は、複数のプロセッサ、複数のコアなどを、輸送装置ノード１０２の範囲から逸脱することなく含むことができるということは理解されるべきである。

輸送装置ノード１０２はまた、プロセッサ１０４により実行可能な機械可読命令を格納できる非一時的コンピュータ可読媒体１１２”も含むことができる。機械可読命令の例は、１３２～１３６として示されており、下記において更に検討される。非一時的コンピュータ可読媒体１１２”の例としては、実行可能命令を含んでいる、または格納している電子的、磁気的、光学的、または他の物理的格納装置を含むことができる。例えば、非一時的コンピュータ可読媒体１１２”は、ランダムアクセスメモリ（ＲＡＭ）、電気的消去可能型プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、ハードディスク、光ディスク、または他のタイプの格納装置であってよい。

プロセッサ１０４は、ソフトウェアアップデートを輸送装置１０２において受信するための機械可読命令１３２を実行できる。ブロックチェーン１０６は、複数の参加輸送装置ノード１０５に対するトランザクションを管理する１つ以上のスマートコントラクトを使用するように構成できる。輸送装置１０２は、ソフトウェアアップデートに関連する情報をブロックチェーン１０６に提供でき、このトランザクションは、台帳１０８に格納できる。

プロセッサ１０４は、最も少ない量の潜在的相互作用を含んでいる第１環境において、ソフトウェアアップデートの第１有効化を実行するための機械可読命令１３４を実行できる。プロセッサ１０４は、第１有効化が成功した場合、更なる環境においてソフトウェアアップデートの更なる有効化を実行するための機械可読命令１３６を実行できる。更なる環境は、第１環境よりも多い量の潜在的相互作用を含むことができる。

図２Ａは、例としての実施形態に係るブロックチェーンアーキテクチャ構成２００を例示している。図２Ａを参照すると、ブロックチェーンアーキテクチャ２００はあるブロックチェーン要素、例えば、ブロックチェーンメンバノード２０２～２０６のグループを、ブロックチェーングループ２１０の一部として含むことができる。１つの例としての実施形態においては、許可されたブロックチェーンは、すべての関係者がアクセス可能であるわけではなく、ブロックチェーンデータへの許可されたアクセスを有するメンバのみがアクセス可能である。ブロックチェーンノードは、ブロックチェーンエントリ追加および有効化プロセス（コンセンサス）などのような多数の活動に参加する。ブロックチェーンノードの１つ以上は、エンドースメントポリシーに基づいてエントリをエンドースでき、すべてのブロックチェーンノードに対してオーダリングサービスを提供できる。ブロックチェーンノードは、ブロックチェーン行動（認証などのような）を初期化でき、ブロックチェーンに格納されているブロックチェーン不変台帳への書き込みを求めようとすることができ、台帳のコピーもまた、基盤となる物理インフラストラクチャに格納できる。

ブロックチェーントランザクション２２０は、トランザクションが、メンバのノードにより指示されたコンセンサスモデルにより受信および容認されると、コンピュータのメモリに格納される。容認されたトランザクション２２６は、ブロックチェーンの現在のブロックに格納され、現在のブロックにおけるトランザクションのデータコンテンツのハッシュを実行し、以前のブロックの以前のハッシュを参照することを含んでいる投入手順を介してブロックチェーンに投入される。ブロックチェーン内には、１つ以上のスマートコントラクト２３０が存在することができ、それらのスマートコントラクト２３０は、登録されている受信者、車両の特徴、必要条件、許可、センサ閾値などのような、スマートコントラクト実行可能アプリケーションコード２３２に含まれているトランザクション合意の条件および行動を定義できる。コードは、要求しているエンティティが車両サービスを受信するように登録されているかどうか、それらのプロファイルステータスを考慮して、何れのサービス特徴を受信する権利が与えられている、および／または、要求されているか、および、後続のイベントにおいてそれらの行動を監視するかどうかを識別するように構成できる。例えば、サービスイベントが起こり、ユーザが車両に乗っているときに、センサデータ監視を誘発でき、車両の充電レベルなどのようなあるパラメータを、特別な時間期間の間、特別な閾値を超えている／それ未満として識別できる。そして、結果は現在のステータスに対する変更であることができ、サービスを識別でき、参考のために格納できるように、管理関係者（例えば、車両の所有者、車両の運転手、サーバなど）に警報が送られることを要求する。収集された車両センサデータは、車両のステータスについての情報を収集するために使用されたセンサデータのタイプに基づくことができる。センサデータはまた、走行する位置、平均速度、最高速度、加速率、何らかの衝突があったかどうか、予期されたルートが取られたか、次の目的地はどこか、安全対策はきちんと用意されているか、車両は十分な充電量／燃料を有しているかどうかなどのような車両イベントデータ２３４に対する根拠ともなり得る。そのような情報のすべては、スマートコントラクト条件２３０の根拠となり得、ブロックチェーンに格納される。例えば、スマートコントラクトに格納されているセンサ閾値は、検出されたサービスが必要かどうか、サービスはいつ、どこで実行されるべきかに対する根拠として使用できる。

図２Ｂは、例としての実施形態に係る共有台帳構成を例示している。図２Ｂを参照すると、ブロックチェーンロジック例２５０は、演算処理装置および、特別なトランザクションに対する実行プラットフォームにリンクするＡＰＩまたはプラグインアプリケーションとしてのブロックチェーンアプリケーションインタフェース２５２を含んでいる。ブロックチェーン構成２５０は、参加者により求められたカスタマイズされた構成に従って作成でき、自身の状態を維持し、自身の資産を制御し、外部情報を受信できる、格納されているプログラム／アプリケーションコード（例えば、スマートコントラクト実行可能コード、スマートコントラクトなど）にアクセスして実行するためのアプリケーションプログラミングインタフェース（ＡＰＩ）にリンクされている１つ以上のアプリケーションを含むことができる。これは、エントリとして展開でき、分散型台帳に付け加えることを介して、すべてのブロックチェーンノード上でインストールできる。

スマートコントラクトアプリケーションコード２５４は、実行されるとトランザクション条項と条件を有効にさせるアプリケーションコードを確立することにより、ブロックチェーンに対する根拠を提供する。スマートコントラクト２３０は、実行されると、ある容認されたトランザクション２２６が生成されるようにさせ、そしてトランザクション２２６は、ブロックチェーンプラットフォーム２６２に転送される。プラットフォームは、セキュリティ／認可２６８と、トランザクション管理２６６を実行する演算処理装置と、トランザクションとスマートコントラクトをブロックチェーンに格納するメモリとしての格納部２６４を含んでいる。

ブロックチェーンプラットフォームは、ブロックチェーンデータ、サービス（例えば、暗号化トラストサービス、仮想実行環境など）の種々の層と、新しいエントリを受信および格納し、データエントリにアクセスしようとするオーディタにアクセスを提供するために使用できる基盤となる物理コンピュータインフラストラクチャを含むことができる。ブロックチェーンは、プログラムコードを処理し、物理インフラストラクチャに従事するために必要な、仮想実行環境へのアクセスを提供するインタフェースを開示できる。暗号化トラストサービスは、資産交換エントリなどのようなエントリを検証し、情報をプライベートに保つために使用できる。

図２Ａと２Ｂのブロックチェーンアーキテクチャ構成は、ブロックチェーンプラットフォームにより開示されたインタフェースを介して、プログラム／アプリケーションを処理および実行でき、ブロックチェーンプラットフォームにより提供されたサービスを処理および実行できる。非制限的な例として、スマートコントラクトは、リマインダ、更新、および／または、変更、更新などが行われる他の通知を実行するために作成できる。スマートコントラクトはそれ自身を、認可およびアクセス必要条件と関連付けられているルール、および台帳の使用法を識別するために使用できる。例えば、情報は新しいエントリを含むことができ、そのエントリは、ブロックチェーン層に含まれている１つ以上の処理エンティティ（例えば、プロセッサ、仮想マシンなど）により処理できる。結果は、スマートコントラクトにおいて定義されている基準、および／または、ピアのコンセンサスに基づいて、新しいエントリを拒絶または容認するかの決定を含むことができる。物理インフラストラクチャは、ここにおいて記述されているデータまたは情報の何れをも取り出すために利用できる。

スマートコントラクト実行可能コード内で、スマートコントラクトは、高いレベルのアプリケーションとプログラミング言語を介して作成でき、ブロックチェーンにおけるブロックに書き込むことができる。スマートコントラクトは、ブロックチェーン（例えば、ブロックチェーンピアの分散型ネットワーク）で登録、格納、および／または、複製される実行可能コードを含むことができる。エントリはスマートコントラクトコードの実行であり、スマートコントラクトと関連付けられている条件が満たされることに応答して実行できる。スマートコントラクトの実行は、デジタルブロックチェーン台帳の状態に対する信頼性のある修正を誘発できる。スマートコントラクトの実行によるブロックチェーン台帳への修正は、１つ以上のコンセンサスプロトコルを通して、ブロックチェーンピアの分散型ネットワーク全体で自動的に複製できる。

スマートコントラクトは、キーバリューペアのフォーマットでブロックチェーンにデータを書き込むことができる。更に、スマートコントラクトコードはブロックチェーンに格納されている値を読むことができ、その値をアプリケーションの動作において使用できる。スマートコントラクトコードは、種々のロジック動作の出力をブロックチェーンに書き込むことができる。コードは、仮想マシンまたは他の演算処理プラットフォームにおいて一時的データ構造を作成するために使用できる。ブロックチェーンに書き込まれたデータは公開することができ、および／または、暗号化してプライベートなものとして保管できる。スマートコントラクトにより使用／生成される一時的データは、供給された実行環境によりメモリに保持され、ブロックチェーンに対して必要なデータが識別されると削除される。

スマートコントラクト実行可能コードは、追加的特徴を有する、スマートコントラクトのコード解釈を含むことができる。ここにおいて記述されているように、スマートコントラクト実行可能コードは、演算処理ネットワーク上で展開されるプログラムコードであってよく、コンセンサスプロセスの間に、チェーンバリデータにより共に実行および有効化される。スマートコントラクト実行可能コードはハッシュを受信し、ブロックチェーンから、以前に格納された特徴エクストラクタの使用により作成されたデータテンプレートと関連付けられているハッシュを取り出す。ハッシュ識別子のハッシュと、格納されている識別子テンプレートデータから作成されたハッシュが一致すると、スマートコントラクト実行可能コードは、要求されているサービスに認可キーを送る。スマートコントラクト実行可能コードは、暗号化詳細と関連付けられているブロックチェーンデータに書き込むことができる。

図２Ｃは、例としての実施形態に係る、ブロックチェーントランザクションデータを格納するためのブロックチェーン構成を例示している。図２Ｃを参照すると、例としての構成２７０は、車両２７２、ユーザ装置２７４、およびサーバ２７６を提供し、これらは、分散型台帳（つまり、ブロックチェーン）２７８と情報を共有している。サーバは、既知および確立されたユーザプロファイルが、確立された格付けプロファイルで車両を借りようと試みている場合において、車両サービスプロバイダにユーザプロファイル格付け情報を共有することを問い合わせているサービスプロバイダエンティティであることができる。サーバ２７６は、車両のサービス必要条件に関連するデータを受信および処理できる。車両センサデータが、燃料／充電、メンテナンスサービスなどが必要であること示すことなどのようなサービスイベントが起こると、車両サービスイベントを呼び出すために使用できる、ルール、閾値、センサ情報集合体などを呼び出すためにスマートコントラクトを使用できる。ブロックチェーントランザクションデータ２８０は、アクセスイベント、車両サービスステータスに対する後続のアップデート、イベントアップデートなどのような各トランザクションに対して保存される。トランザクションは、関係者、必要条件（例えば、年齢１８才、サービスを受けられる候補、有効な運転免許証など）、補償レベル、イベントの間に走行した距離、イベントにアクセスすることと、車両サービスのホストとなることを許可された登録されている受信者、権利／許可、次のサービスイベントの詳細を記録し、車両の状態ステータスを識別するために、車両イベント動作の間に取り出されたセンサデータ、および、サービスイベントは完了したか、および車両の状態ステータスは変化したかどうかについて決定するために使用される閾値を含むことができる。

図３Ａは、例としての実施形態に係るフロー図３００を例示している。図３Ａを参照すると、例としての方法は、輸送装置ノード１０２（図１Ｂ参照）により実行できる。図３Ａにおいて示されている方法３００は、方法３００の範囲から逸脱することなく、追加的な動作を含むことができ、ここにおいて記述されている動作の幾つかは除去および／または修正できるということは理解されるべきである。方法３００の記述もまた、例示としての目的のための図１Ｂにおいて示されている特徴を参照してなされる。特に、輸送装置ノード１０２のプロセッサ１０４は、方法３００に含まれている動作の幾つかまたはすべてを実行できる。

図３Ａを参照すると、ブロック３０２において、プロセッサ１０４は、輸送装置においてソフトウェアアップデートを受信できる。ブロック３０４において、プロセッサ１０４は、ソフトウェアアップデートが使用されていた時間期間と輸送装置のサブセットによるソフトウェアアップデートの利用回数の１つ以上に基づいて、ソフトウェアアップデートを有効化できる。ブロック３０６において、プロセッサ１０４は、輸送装置の更なるサブセットに、有効化に基づいてソフトウェアアップデートを配布できる。輸送装置の更なるサブセットは、輸送装置のサブセットよりも大きくてよい。

図３Ｂは、例としての実施形態にかかわる例としての方法のフロー図３２０を示している。図３Ｂを参照すると、方法３２０もまた、下記のステップの１つ以上を含むことができる。ブロック３２２において、プロセッサ１０４は、すべての残っている輸送装置のセットにソフトウェアアップデートを配布でき、ここにおいて、すべての残っている輸送装置のセットは、輸送装置の更なるセットよりも大きい。輸送装置のサブセット、輸送装置の更なるサブセット、およびすべての残っている輸送装置のセットは、既存のソフトウェア、既存のハードウェア、地理的位置、環境の温度、輸送装置の型(transport make)、輸送装置のモデル、輸送装置の状態、道路の状態、および輸送装置の目的地の１つ以上に基づいている。

ブロック３２４において、プロセッサ１０４は、有効化に基づいてネガティブな結果が決定されると、輸送装置のサブセット、輸送装置の更なるサブセット、およびすべての残っている輸送装置のセットの１つ以上を変更すること、そして、輸送装置のサブセット、輸送装置の更なるサブセット、およびすべての残っている輸送装置のセットの１つ以上を、ソフトウェアの初期バージョンの１つ以上と、以前のソフトウェアアップデートに戻すことの１つ以上を実行できる。ブロック３２６において、プロセッサ１０４は、輸送装置のサブセットによる第１時間量、および輸送装置の更なるサブセットによる、第１時間量よりも少ない第２時間量だけソフトウェアアップデートを使用できる。輸送装置のサブセットは、ブロックチェーンネットワークに属することができる。ブロック３２８において、プロセッサ１０４は、ソフトウェアアップデートを有効化して、ソフトウェアアップデートを複数の輸送装置を通して配布するために、ブロックチェーンネットワークのスマートコントラクトを実行できる。

図３Ｃは、例としての実施形態に係るフロー図３３０を例示している。図３Ｃを参照すると、例としての方法は、マスタ輸送装置ノード１０２（図１Ｃ参照）により実行できる。図３Ｃにおいて示されている方法３００は、方法３３０の範囲から逸脱することなく、追加的な動作を含むことができ、ここにおいて記述されている動作の幾つかは除去および／または修正できるということは理解されるべきである。方法３３０の記述もまた、例示としての目的のための図１Ｃにおいて示されている特徴を参照してなされる。特に、マスタ輸送装置ノード１０２のプロセッサ１０４は、方法３３０に含まれている動作の幾つかまたはすべてを実行できる。

図３Ｃを参照すると、ブロック３３３において、プロセッサ１０４は、ソフトウェアアップデートの第１部分を、輸送装置の第１サブセットの輸送装置に送ることができる。ブロック３３５において、プロセッサ１０４は、ソフトウェアアップデートの第２部分を、輸送装置の更なるサブセットの輸送装置に送ることができる。ブロック３３７において、プロセッサ１０４は、輸送装置のサブセットの第１輸送装置と、輸送装置の更なるサブセットの第２輸送装置が近接しているときに、第１輸送装置に、ソフトウェアアップデートの第１部分を第２輸送装置に送らせ、第２輸送装置に、ソフトウェアアップデートの第２部分を第１輸送装置に送らせることができる。

図３Ｄは、例としての実施形態に係る例としての方法のフロー図３４０を示している。図３Ｄを参照すると、方法３４０もまた、下記のステップの１つ以上を含むことができる。ブロック３４２において、プロセッサ１０４は、輸送装置のサブセットと輸送装置の更なるサブセットへの送信の前に、ソフトウェアアップデートの第１部分と第２部分を決定できる。ブロック３４４において、プロセッサ１０４は、輸送装置のサブセットと輸送装置の更なるサブセットが、ソフトウェアアップデートの第１部分と第２部分の１つ以上を受信しておらず、ソフトウェアアップデートの第１部分と第２部分の１つ以上を実行していないときは、マスタ輸送装置を、ある地理的領域にルーティングする(route)ことができる。

ブロック３４６において、プロセッサ１０４は、ソフトウェアアップデートの第１部分を受信してからある時間期間が経過したときに、第１輸送装置を第２輸送装置の近傍にルーティングすることができ、ソフトウェアアップデートの第１部分を受信してからある時間期間が経過したときに、第２輸送装置を第１輸送装置の近傍にルーティングすることができる。ブロック３４８において、プロセッサ１０４は、ソフトウェアアップデートの第１部分と第２部分をマスタ輸送装置におけるトランシーバにより送信でき、トランシーバにより、第１輸送装置と第２輸送装置の１つ以上において、ソフトウェアアップデートの第１部分と第２部分を受信でき、第１輸送装置と第２輸送装置の１つ以上におけるメモリに、ソフトウェアアップデートの第１部分と第２部分を格納でき、プロセッサにより、第１輸送装置と第２輸送装置上で、第１部分と第２部分を組み合わせることができる。

マスタ輸送装置、輸送装置のサブセット、および輸送装置の更なるサブセットはブロックチェーンネットワーク上で接続できるということに留意されたい。ブロック３５０において、プロセッサ１０４は、ソフトウェアアップデートの部分を、輸送装置間で交換するためにスマートコントラクトを実行できる。

図３Ｅは、例としての実施形態に係るフロー図３６０を例示している。図３Ｅを参照すると、例としての方法は、輸送装置ノード１０２（図１Ｄ参照）により実行できる。図３Ｅにおいて示されている方法３６０は、方法３６０の範囲から逸脱することなく、追加的な動作を含むことができ、ここにおいて記述されている動作の幾つかは除去および／または修正できるということは理解されるべきである。方法３６０の記述もまた、例示としての目的のための図１Ｄにおいて示されている特徴を参照してなされる。特に、輸送装置ノード１０２のプロセッサ１０４は、方法３６０に含まれている動作の幾つかまたはすべてを実行できる。

図３Ｅを参照すると、ブロック３６２において、プロセッサ１０４は、輸送装置においてソフトウェアアップデートを受信できる。ブロック３６４において、プロセッサ１０４は、第１環境においてソフトウェアアップデートの第１有効化を実行でき、ここにおいて第１環境は、最も少ない量の潜在的相互作用を含んでいる。ブロック３６６において、プロセッサ１０４は、第１有効化が成功した場合、更なる環境において、ソフトウェアアップデートの更なる有効化を実行できる。更なる環境は、第１環境よりも多くの量の潜在的相互作用を含むことができる。

図３Ｆは、例としての実施形態に係る例としての方法のフロー図３８０を示している。図３Ｆを参照すると、方法３８０もまた、下記のステップの１つ以上を含むことができる。ブロック３８２において、プロセッサ１０４は、第１有効化と第２有効化の１つ以上が失敗すると、以前のソフトウェアバージョンに戻ることができる。ブロック３８４において、プロセッサ１０４は、他の輸送装置から、ソフトウェアアップデートの更なる有効化を受信できる。ブロック３８６において、プロセッサ１０４は、更なる環境の解析に基づいて、ソフトウェアアップデートを呼び出すことができる。ブロック３８８において、プロセッサ１０４は、複数の輸送装置から、ソフトウェアアップデートの更なる有効化についての確認を受信できる。確認は、輸送装置が属しているブロックチェーン上のコンセンサスを構成できる。ブロック３９０において、プロセッサ１０４は、有効化されたソフトウェアアップデートを反映している少なくとも１つのデータブロックをブロックチェーンの台帳に記録するためにスマートコントラクトを実行できる。

図４Ａは、例としての実施形態に係る、車両と関連付けられているブロックチェーントランザクションを管理するための例としてのブロックチェーン車両構成４００を示している。図４Ａを参照すると、特別な輸送装置／車両４２５は、資産転送トランザクション（例えば、アクセスキー交換、車両サービス、ディーラートランザクション、配達／集荷、輸送サービスなど）のようなトランザクションに従事している。車両４２５は、スマートコントラクトにより定義されるトランザクションに従って、資産４１０を受信でき、および／または、資産４１２を放出／転送できる。トランザクションモジュール４２０は、関係者、クレジット、サービス明細、日付、時間、位置、結果、通知、予期せぬイベントなどのような情報を記録できる。トランザクションモジュール４２０におけるそれらのトランザクションはブロックチェーン４３０に複製でき、リモートサーバおよび／またはリモートブロックチェーンピアにより管理することができ、その中において、車両４２５は、自身がブロックチェーンメンバおよび／またはブロックチェーンピアであることができる。他の実施形態においては、ブロックチェーン４３０は車両４２５上に常駐している。受信および／または転送された資産は、ここにおいて記述されているように、位置とコンセンサスに基づくことができる。

図４Ｂは、例としての実施形態に係る、サービスノード（例えば、ガソリンスタンド、サービスセンタ、車体工場、レンタルセンサ、自動車ディーラ、ローカルサービスショップ、配達／集荷センタなど）と車両との間のブロックチェーントランザクションを管理するための例としてのブロックチェーン車両構成４４０を示している。この例においては、車両４２５は、サービスを必要としている、および／または、特別な位置で停止する必要があるので、サービスノード４４２まで、自身で移動している。サービスノード４４２はサービス（例えば、ガソリンを入れる）、または、オイル変更、バッテリ充電または取り替え、タイヤ変更または取り替え、および任意の他の輸送装置に関連するサービスなどを、特別な手順で、特別な時間におけるサービスコールに対して車両４２５を登録できる。提供されたサービス４４４はスマートコントラクトに基づいて実行でき、この場合のスマートコントラクトは、ブロックチェーン４３０からダウンロードされ、またはブロックチェーン４３０を介してアクセスされて、特別な交換率でそのようなサービスを実行することの許可に対して識別される。サービスは、トランザクションモジュール４２０のトランザクションログにおいて記録でき、クレジット４１２は、サービスセンタ４４２に転送され、ブロックチェーンは、最近のサービスに関するすべての情報を表わすためにトランザクションを記録できる。他の実施形態においては、ブロックチェーン４３０は車両４２５および／またはサービスセンタサーバ上に常駐している。１つの例においては、輸送装置イベントは燃料補給または他の車両サービスを要求でき、そして乗者人には、そのようなサービスに対する資産バリュー(asset value)の増加に対して責任を負わせることができる。サービスはブロックチェーン通知を介して提供でき、資産バリューを、それぞれの資産バリューを介して乗者人に再分配するために使用される。サービスセンタの行動に対する信頼性は、ここにおいて記述されているような、資産転送に基づくことができる。

図４Ｃは、例としての実施形態に係る、種々の車両間で実行されたブロックチェーントランザクションを管理するための例としてのブロックチェーン車両構成４５０を示している。車両４２５は、車両が、資産を他の車両と共有する必要があるステータスになると、アクセスキーを共有する、キーを転送する、サービスコールを得るなどのような種々の動作を実行するために他の車両４０８と係ることができる。例えば、車両４０８はバッテリ充電の必要があり、および／または、タイヤに問題があり、配達のための荷物を集荷する途中であることがあり得る。車両４０８は、同じネットワーク内の、同じブロックチェーンメンバサービスで動作する他の車両４２５に通知できる。そして車両４２５は、荷物の集荷を実行する無線通信要求を介して車両４０８から、および／または、サーバ（示されていない）から情報を受信できる。トランザクションは、両方の車両のトランザクションモジュール４５２と４２０に記録される。資産は車両４０８から車両４２５に転送され、資産転送の記録は、ブロックチェーンが互いに異なっていると仮定して、ブロックチェーン４３０／４５４に記録され、または、すべてのメンバにより使用される同じブロックチェーンに記録される。転送された資産に対する信頼性は、ここにおいて記述されているように、資産バリュー（例えば、アクセスキー）に基づくことができる。

図５は、例としての実施形態に係る、分散型台帳に追加できるブロックチェーンブロック５００と、ブロック構造５０２Ａ～５０２ｎの内容を例示している。図５を参照すると、クライアント（示されていない）は、ブロックチェーン上での行動を実行に移すために、ブロックチェーンノードにエントリを提出できる。例として、クライアントは、ブロックチェーンに対してエントリを提案する装置、人間、またはエンティティなどのような、要求者の代わりに行動するアプリケーションであってよい。複数のブロックチェーンピア（例えば、ブロックチェーンノード）はブロックチェーンネットワークの状態と、分散型台帳の複製を維持できる。クライアントにより提案されたエントリをシミュレートおよびエンドースするエンドーシングピアと、エンドースメントを検証し、エントリを有効化し、エントリを分散型台帳に投入するコミットピアを含むブロックチェーンネットワークに、異なるタイプのブロックチェーンノード／ピアが存在することができる。この例においては、ブロックチェーンノードは、エンドーサノード、または、コミッタノード、またはその両者の役割を実行できる。

実例としてのシステムは、ブロックにおける不変の、順序付けられた記録と、ブロックチェーンの現在の状態を維持している状態データベース（現在のワールド状態）を格納しているブロックチェーンを含んでいる。１つの分散型台帳が１つのチャネルに対して存在でき、各ピアは、自身がメンバである各チャネルに対する分散型台帳の自身の複製を維持している。実例としてのブロックチェーンはエントリログであり、ハッシュとリンクされたブロックとして構造化されており、各ブロックは、Ｎ個のエントリのシーケンスを含んでいる。ブロックは、図５において示されているような種々の構成要素を含むことができる。ブロックのリンク結合は、現在のブロックのブロックヘッダ内の以前のブロックヘッダのハッシュを追加することにより生成できる。このようにして、ブロックチェーン上のすべてのエントリは順序付けられ且つ暗号的にリンクされ、ハッシュリンクを破壊しない限りブロックチェーンデータの改竄を防いでいる。更に、リンクのために、ブロックチェーンにおける最新のブロックは、その前に来たすべてのエントリを表わしている。実例としてのブロックチェーンは、追加のみブロックチェーンワークロードをサポートする、ピアファイルシステム（ローカルまたは取り付けられたストレージ）に格納できる。

ブロックチェーンと分散型台帳の現在の状態は、状態データベースに格納できる。ここで、現在の状態データは、ブロックチェーンのチェーンエントリログに今まで含まれていたすべてのキーに対する最新の値を表わしている。スマートコントラクト実行可能コード呼出しは、状態データベースにおける現在の状態に対してエントリを実行する。これらのスマートコントラクト実行可能コード呼出しを非常に効率的にするために、すべてのキーの最新の値が状態データベースに格納される。状態データベースは、ブロックチェーンのエントリログへのインデックス付きビューを含むことができるので、従って、如何なるときでも、状態データベースをチェーンから再生成できる。状態データベースは、ピアが起動したときであって、エントリが容認される前に自動的に回復できる（または、必要であれば、生成できる）。

エンドーシングノードはクライアントからエントリを受信して、シミュレートされた結果に基づいてエントリをエンドースする。エンドーシングノードは、エントリ提案をシミュレートするスマートコントラクトを保持している。エンドーシングノードがエントリをエンドースするとき、エンドーシングノードは、エンドーシングノードからクライアントアプリケーションへの、シミュレートされたエントリのエンドースメントを示す署名付き応答であるエントリエンドースメントを作成する。エントリをエンドースする方法は、スマートコントラクト実行可能コード内で指定できるエンドースメントポリシーに依存している。エンドースメントポリシーの例としては、「エンドーシングピアの大半がエントリをエンドースしなければならない」ということである。異なるチャネルは、異なるエンドースメントポリシーを有することができる。エンドースされたエントリは、クライアントアプリケーションによりオーダリングサービスに転送される。

オーダリングサービスはエンドースされたエントリを容認し、ブロックにおいて順序付けし、ブロックをコミットピアに引き渡す。例えば、オーダリングサービスは、エントリの閾値に到達すると、または、タイマがタイムアウトすると、または他の条件が満たされると新しいブロックを初期化できる。この例においては、ブロックチェーンノードは、ブロックチェーン上への格納のためのデータブロック６０２Ａを受信したコミットピアである。オーダリングサービスはオーダラのクラスタにより構成できる。オーダリングサービスはエントリ、スマートコントラクトを処理せず、また、分散型台帳も維持しない。そうではなく、オーダリングサービスは、エンドースされたエントリを容認でき、それらのエントリがどのような順序で分散型台帳に投入されるかを指定する。ブロックチェーンネットワークのアーキテクチャは、「オーダリング」（例えば、Ｓｏｌｏ、Ｋａｆｋａ、ＢＦＴなど）の特定の実現形態がプラグ接続可能な構成要素になるように設計できる。

エントリは、一貫性のある順序で分散型台帳に書き込まれる。エントリの順序は、状態データベースへのアップデートがネットワークに投入されるときに、それが有効であることを確実にするために確立される。オーダリングが、暗号パズルを解くことや、マイニング(mining)を通して起こる暗号通貨ブロックチェーンシステム（例えば、ビットコインなど）とは異なり、この例においては、分散型台帳の関係者は、そのネットワークに最も適合するオーダリング機構を選択できる。

図５を参照すると、ブロックチェーンおよび／または分散型台帳に格納されているブロック５０２Ａ（データブロックとも称される）は、ブロックヘッダ５０４Ａ～５０４ｎ、トランザクション特定データ５０６Ａ～５０６ｎ、およびブロックメタデータ５０８Ａ～５０８ｎなどのような複数のデータセグメントを含むことができる。ブロック５０２Ａとその内容などのような、種々の示されているブロックとその内容は、例としての目的のみのために過ぎず、例としての実施形態の範囲を制限することは意味していないということは認識されるべきである。幾つかの場合においては、ブロックヘッダ５０４Ａとブロックメタデータ５０８Ａの両者は、エントリデータを格納しているトランザクション特定データ５０６Ａよりも小さくてもよいが、これは必要条件ではない。ブロック５０２Ａは、ブロックデータ５１０Ａ～５１０ｎ内に、Ｎ（例えば、１００、５００、１，０００、２，０００、３，０００など）個のエントリのトランザクション情報を格納できる。ブロック５０２Ａはまた、ブロックヘッダ５０４Ａ内の以前のブロック（例えば、ブロックチェーン上）へのリンクも含むことができる。特に、ブロックヘッダ５０４Ａは、以前のブロックヘッダのハッシュを含むことができる。ブロックヘッダ５０４Ａはまた、固有なブロック番号、現在のブロック５０２Ａのブロックデータ５１０Ａのハッシュなども含むことができる。ブロック５０２Ａのブロック番号は固有であることができ、ゼロから開始して増大／連続順序で割り当てることができる。ブロックチェーンにおける第１ブロックはジェネシスブロックとも称することができ、ブロックチェーン、そのメンバ、そこに格納されているデータなどについての情報を含んでいる。

ブロックデータ５１０Ａは、ブロック内に記録されている各エントリのエントリ情報を格納できる。例えば、エントリデータは、１つ以上のタイプのエントリ、バージョン、タイムスタンプ、分散型台帳のチャネルＩＤ、エントリＩＤ、エポック、ペイロードの可視性、スマートコントラクト実行可能コード経路（展開ｔｘ）、スマートコントラクト実行可能コード名、スマートコントラクト実行可能コードバージョン、入力（スマートコントラクト実行可能コードと機能）、パブリックキーと証明書などのようなクライアント（作成者）アイデンティティ、クライアントの署名、エンドーサのアイデンティティ、エンドーサの署名、提案ハッシュ、スマートコントラクト実行可能コードイベント、応答ステータス、名前空間、読み込みセット（エントリにより読み込まれたキーとバージョンなどのリスト）、書き込みセット（キーと値などのリスト）、開始キー、終了キー、キーのリスト、マークル（Ｍｅｒｋｌｅ）ツリークエリサマリなどを含むことができる。エントリデータは、Ｎ個のエントリのそれぞれに対して格納できる。

幾つかの実施形態においては、ブロックデータ５１０Ａはまた、追加的情報を、ブロックチェーンにおけるブロックのハッシュとリンクされたチェーンに追加するトランザクション特定データ５０６Ａも格納できる。従って、データ５０６Ａは、分散型台帳上のブロックの不変ログに格納できる。そのようなデータ５０６Ａを格納することの恩典の幾つかは、ここにおいて開示且つ示されている種々の実施形態において反映されている。ブロックメタデータ５０８Ａは、メタデータの複数のフィールドを格納できる（例えば、バイトアレイとしてなど）。メタデータフィールドは、ブロック作成に関する署名、最新構成ブロックへの参照、ブロック内の有効および無効エントリを識別するエントリフィルタ、ブロックを順序付けしたオーダリングサービスの存続している最新オフセットなどを含むことができる。署名、最新構成ブロック、およびオーダラのメタデータは、オーダリングサービスにより追加できる。一方、ブロックのコミッタ（ブロックチェーンノードなどような）は、エンドースメントポリシー、読取り／書込みセットの検証などに基づいて、有効／無効情報を追加できる。エントリフィルタは、ブロックデータ５１０Ａにおけるエントリの数と等しいサイズのバイトアレイと、エントリが有効／無効であったかを識別する有効化コードを含むことができる。

ブロックチェーンにおける他のブロック５０２Ｂ～５０２ｎもまた、ヘッダ、ファイル、および値を有することができる。しかし、第１ブロック５０２Ａとは異なり、他のブロックにおけるヘッダ５０４Ａ～５０４ｎのそれぞれは、直前の先行するブロックのハッシュ値を含んでいる。直前の先行するブロックのハッシュ値は、前のブロックのヘッダの単なるハッシュであってよく、または、前のブロック全体のハッシュ値であってよい。残りのブロックのそれぞれにおいて先行するブロックのハッシュ値を含むことにより、監査可能且つ不変な管理の連鎖（ｃｈａｉｎ－ｏｆ－ｃｕｓｔｏｄｙ）（証拠保全とも称される）を確立するために、矢印５１２により示されているように、ブロック毎に基づいて、Ｎ番目のブロックからジェネシスブロック（および関連付けられているオリジナルファイル）に戻る追尾を実行できる。

上記の実施形態は、ハードウェア、プロセッサにより実行されるコンピュータプログラム、ファームウェア、または上記の組み合わせにおいて実現できる。コンピュータプログラムは、格納媒体などのようなコンピュータ可読媒体に含むことができる。例えば、コンピュータプログラムは、ランダムアクセスメモリ（「ＲＡＭ」）、フラッシュメモリ、リードオンリメモリ（「ＲＯＭ」）、消去可能型プログラマブルリードオンリメモリ（「ＥＰＲＯＭ」）、電気的消去可能型プログラマブルリードオンリメモリ（「ＥＥＰＲＯＭ」）、レジスタ、ハードディスク、リムーバブルディスク、コンパクトディスクリードオンリメモリ（「ＣＤ－ＲＯＭ」）、または、この技術において知られている格納媒体の任意の他の形状において常駐できる。

例としての格納媒体は、プロセッサが格納媒体から情報を読み込むことができ、格納媒体に情報を書き込むことができるようにプロセッサに結合できる。代替として、格納媒体はプロセッサに統合できる。プロセッサと格納媒体は、特定用途向け集積回路（「ＡＳＩＣ」）に常駐できる。代替として、プロセッサと格納媒体は、分離構成要素として常駐できる。例えば、図６は、上記の構成要素の何れかであってよい、または、上記の構成要素の何れかに統合できる、例としてのコンピュータシステムアーキテクチャ６００を示している。

図６は、ここにおいて記述されている本願の実施形態の使用または機能の範囲に関する如何なる制限も示唆することは意図されていない。とにかく、演算処理ノード６００は実現されることができ、および／または、上記の機能の何れをも実行できる。

演算処理ノード６００においては、コンピュータシステム／サーバ６０２があり、コンピュータシステム／サーバ６０２は、多数の他の汎用または特殊目的演算処理システム環境または構成で動作する。コンピュータシステム／サーバ６０２との使用に対して適切であることができる、よく知られている演算処理システム、環境、および／または、構成の例としては、下記に制限されることはないが、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、手持ち型またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサに基づくシステム、セットトップボックス、プログラマブルコンシューマ電子機器、ネットワークＰＣ、ミニコンピュータシステム、メインフレームコンピュータシステム、および、上記のシステムまたは装置の何れかを含んでいる分散型クラウド演算処理環境などがある。

コンピュータシステム／サーバ６０２は、プログラムモジュールなどのような、コンピュータシステムにより実行されるコンピュータシステム実行可能命令の一般的な状況において記述できる。一般的に、プログラムモジュールは、特別なタスクを実行する、または、特別な抽象データタイプを実現する、ルーチン、プログラム、オブジェクト、構成要素、ロジック、データ構造などを含むことができる。コンピュータシステム／サーバ６０２は、分散型クラウド演算処理環境において実践でき、タスクは、通信ネットワークを通してリンクされているリモート処理装置により実行される。分散型クラウド演算処理環境においては、プログラムモジュールは、メモリ格納装置を含む、ローカルおよびリモートコンピュータシステム格納媒体の両者に位置させることができる。

図６において示されているように、クラウド演算処理ノード６００におけるコンピュータシステム／サーバ６０２は、汎用演算処理装置の形状で示されている。コンピュータシステム／サーバ６０２の構成要素は、下記に制限されないが、１つ以上のプロセッサまたは処理ユニット６０４、システムメモリ６０６、および、システムメモリ６０６を含む種々のシステム構成要素をプロセッサ６０４に結合するバスを含むことができる。

バスは、多様なバスアーキテクチャの何れかを使用する、メモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート、およびプロセッサまたはローカルバスを含む、幾つかのタイプのバス構造の何れかの１つ以上であり、または田多様なバスアーキテクチャの何れかを使用するローカルバスである。例として、制限ではないが、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準協会（ＶＥＳＡ）ローカルバス、および周辺構成要素相互接続（ＰＣＩ）バスが含まれる。

コンピュータシステム／サーバ６０２は典型的には、多様なコンピュータシステム可読媒体を含んでいる。そのような媒体は、コンピュータシステム／サーバ６０２によりアクセス可能な任意の利用可能な媒体であってよく、揮発性および不揮発性媒体とリムーバブルまたは非リムーバブル媒体の両者を含んでいる。１つの実施形態においては、システムメモリ６０６は、他の図のフロー図を実現する。システムメモリ６０６は、ランダムアクセスメモリ（ＲＡＭ）６０８および／またはキャッシュメモリ６１０などのような、揮発性メモリの形状のコンピュータシステム可読媒体を含むことができる。コンピュータシステム／サーバ６０２は更に、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータシステム格納媒体を含むことができる。例としての目的のためのみに、メモリ６０６は、非リムーバブル、不揮発性磁気媒体（示されておらず、典型的には「ハードドライブ」と呼ばれる）からの読み込み、およびそこへの書き込みのために提供できる。示されていないが、非リムーバブル、不揮発性磁気ディスク（例えば、「フロッピディスク」）からの読み込み、およびそこへの書き込みのための磁気ディスクドライブ、および、ＣＤ－ＲＯＭ、または他の光学式媒体などのような、リムーバブル、不揮発性光ディスクからの読み込み、またはそこへの書き込みのための光ディスクドライブを提供することができる。そのような実例においては、１つ以上のデータ媒体インタフェースによりそれぞれをバスに接続できる。下記に更に示され、記述されるように、メモリ６０６は、本願の種々の実施形態の機能を実行するように構成されているプログラムモジュールのセット（例えば、少なくとも１つのセット）を有している少なくとも１つのプログラム製品を含むことができる。

プログラムモジュールのセット（少なくとも１つのセット）を有しているプログラム／ユーティリティは、例として、そして制限はないが、オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータと共に、メモリ６０６に格納できる。オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータまたはそれらのある組み合わせのそれぞれは、ネットワーキング環境の実現形態を含むことができる。プログラムモジュールは、一般的には、ここにおいて記述されているように、本願の種々の実施形態の機能および／または方法を実行する。

当業者には認識されるように、本願の態様は、システム、方法、またはコンピュータプログラム製品として具現化できる。従って、本願の態様は、全体的なハードウェア実施形態、全体的なソフトウェア実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含んでいる）、または、ここにおいては全体として「回路」、「モジュール」、または「システム」と称することができる、ソフトウェアとハードウェア態様を組み合わせている実施形態の形状を取ることができる。更に、本願の態様は、コンピュータ可読プログラムコードを含んでいる１つ以上のコンピュータ可読媒体において具現化されているコンピュータプログラム製品の形状を取ることができる。

コンピュータシステム／サーバ６０２はまた、キーボード、ポインティングデバイス、ディスプレイなどのようなＩ／Ｏアダプタ６１２を介して、ユーザがコンピュータシステム／サーバ６０２と相互作用することを可能にする１つ以上の装置、および／または、コンピュータシステム／サーバ６０２が、１つ以上の他の演算処理装置と通信することを可能にする任意の装置（例えば、ネットワークカード、モデムなど）などのような１つ以上の外部装置と通信することもできる。そのような通信は、アダプタ６１２のＩ／Ｏインタフェースを介して実行できる。更に、コンピュータシステム／サーバ６０２は、ローカルエリアネットワーク（ＬＡＮ）、一般的なワイドエリアネットワーク（ＷＡＮ）、および／または、ネットワークアダプタを介して公共ネットワーク（例えば、インターネット）などのような１つ以上のネットワークと通信できる。示されているように、アダプタ６１２は、バスを介して、コンピュータシステム／サーバ６０２の他の構成要素と通信する。示されていないが、他のハードウェアおよび／またはソフトウェア構成要素は、コンピュータシステム／サーバ６０２と連携して使用できるということは理解されるべきである。例としては、下記に制限されないが、マイクロコード、デバイスドライバ、冗長処理ユニット、外部ディスクドライブアレイ、ＲＡＩＤシステム、テープドライブ、およびデータアーカイバル格納システムなどが含まれる。

システム、方法、および非一時的コンピュータ可読媒体の少なくとも１つの例としての実施形態が付随する図面において示され、前述の詳細な記述において記述されてきたが、本願は、開示されている実施形態に制限されず、下記の請求項により記述および定義されているような、種々の再配置、修正、および置換が可能であるということは理解されるであろう。例えば、種々の図のシステムの機能は、ここにおいて記述されているモジュールまたは構成要素の１つ以上により実行でき、または、分散型アーキテクチャおいて実行でき、送信機、受信機、またはその両者の対を含むことができる。例えば、個々のモジュールにより実行される機能のすべてまたは一部は、これらのモジュールの１つ以上により実行できる。更に、ここにおいて記述されている機能は、種々の時間において実行でき、モジュールまたは構成要素の内部または外部の種々のイベントと関連して実行できる。また、種々のモジュール間で送られる情報は、データネットワーク、インターネット、ボイスネットワーク、インターネットプロトコルネットワーク、無線装置、有線装置の少なくとも１つを介して、および／または、複数のプロトコルを介して、モジュール間で送ることができる。また、モジュールの何れかにより送られた、または受信されたメッセージは、直接、および／または、他のモジュールの１つ以上を介して送ることができ、または受信できる。

当業者は、「システム」は、パーソナルコンピュータ、サーバ、コンソール、携帯情報端末（ＰＤＡ）、セルフォン、タブレット演算処理装置、スマートフォン、または、任意の他の適切な演算処理装置、または、装置の組み合わせとして具現化できるということは認識するであろう。上記の機能を「システム」により実行されるものとして表わしたのは、本願の範囲を如何なる意味でも制限することは意図されておらず、多数の実施形態の１つの例を提供することが意図されている。実際、ここにおいて開示されている方法、システム、および装置は、演算処理技術と一貫性のある局所型または分散型の形状で実現できる。

本明細書において記述されているシステムの特徴の幾つかは、それらの実現独立性を、より特別に強調するためにモジュールとして表わされているということに留意すべきである。例えば、モジュールは、カスタマイズされた超大規模集積（ＶＬＳＩ）回路またはゲートアレイ、ロジックチップなどのような常駐導体、トランジスタ、または他の分離構成要素などを備えているハードウェア回路として実現できる。モジュールはまた、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス、グラフィックス処理ユニットなどのようなプログラマブルハードウェア装置においても実現できる。

モジュールはまた、種々のタイプのプロセッサによる実行のために、ソフトウェアにおいて少なくとも部分的には実現できる。実行可能コードの識別されているユニットは、例えば、オブジェクト、手順、または機能として組織化できるコンピュータ命令の、例えば、１つ以上の物理的またはロジックブロックを含むことができる。それにも拘わらず、識別されたモジュールは、実行のために物理的に共に位置する必要はなく、異なる位置に格納されている別個の命令を備えることができ、モジュールは論理的に結合されると、モジュールを備えることができ、モジュールに対する記述されている目的を達成することができる。更に、モジュールは、例えば、ハードディスクドライブ、フラッシュデバイス、ランダムアクセスメモリ（ＲＡＭ）、テープ、または、データを格納するために使用される任意の他のそのような媒体であってよく、コンピュータ可読媒体に格納できる。

実際、実行可能コードのモジュールは、単一の命令、多数の命令、および、異なるプログラム間で、そして、幾つかの記憶装置にわたり、幾つかの異なるコードセグメント上で分散させることさえできる。同様に、動作データは、モジュール内で、ここにおいて識別および例示でき、任意の適切な形状で具現化でき、および、任意の適切なタイプのデータ構造内で組織化できる。動作データは、単一データセットとして収集でき、または、異なる格納装置上を含む異なる位置上で分散でき、少なくとも部分的には、システムまたはネットワーク上の単なる電子信号として存在できる。

本願の構成要素は、ここにおいては、図において全体的に記述および例示されているように、広く多様な異なる構成において配置および設計できるということは容易に理解されるであろう。そのため、実施形態の詳細な記述は、主張されている本願の範囲を制限することは意図されておらず、本願の選択された実施形態の単なる代表例である。

この技術における通常の技量を有する者は、上記のことは異なる順序のステップで実践でき、および／または、開示されている構成とは異なる構成においてハードウェア要素により実践できるということは容易に理解するであろう。従って、本願はこれらの好適な実施形態に基づいて記述されてきたが、当業者には、ある修正と変形は明白であり、および代替の構成も明白であろう。

本願の好適な実施形態が記述されてきたが、記述されている実施形態は、例示の目的のためのみであり、本願の範囲は、等価物およびそれらに対する修正（例えば、プロトコル、ハードウェア装置、ソフトウェアプラットフォームなど）の全範囲を考慮したときに、付随する請求項によりのみ定義されるということは理解されるべきである。
本開示は以下の態様を包含する。
（１）
システムであって、
輸送装置のサブセットの輸送装置のプロセッサと、
前記プロセッサに通信可能に結合されているメモリと、を備え、前記プロセッサは、
前記輸送装置においてソフトウェアアップデートを受信し、
前記ソフトウェアアップデートを、
前記ソフトウェアアップデートが使用された時間期間と、
前記輸送装置のサブセットによる前記ソフトウェアアップデートの利用回数と、
の１つ以上に基づいて有効化し、
前記有効化に基づいて前記ソフトウェアアップデートを、前記輸送装置のサブセットよりも大きい前記輸送装置の更なるサブセットに配布する、
システム。
（２）
前記プロセッサは、前記ソフトウェアアップデートを、前記輸送装置の更なるサブセットよりも大きい、すべての残っている輸送装置のセットに配布する、上記（１）に記載のシステム。
（３）
前記輸送装置のサブセット、前記輸送装置の更なるサブセット、および、すべての残っている輸送装置のセットの１つ以上は、
既存のソフトウェア、
既存のハードウェア、
地理的位置、
環境の温度、
輸送装置の型、
輸送装置のモデル、
輸送装置の状態、
道路の状態、および
輸送装置の目的地の１つ以上に基づいている、上記（１）に記載のシステム。
（４）
前記プロセッサは、前記有効化に基づいて、ネガティブな結果が決定されると、前記輸送装置のサブセット、前記輸送装置の更なるサブセット、および、すべての残っている輸送装置のセットの１つ以上を変更する、上記（１）に記載のシステム。
（５）
前記プロセッサは、前記有効化に基づいて、ネガティブな結果が決定されると、前記輸送装置のサブセット、前記輸送装置の更なるサブセット、および、すべての残っている輸送装置のセットの１つ以上を、ソフトウェアの初期バージョンの１つ以上、および、以前のソフトウェアアップデートに戻す、上記（１）に記載のシステム。
（６）
前記プロセッサは、前記ソフトウェアアップデートを、
前記輸送装置のサブセットによる第１時間量、および、
前記輸送装置の更なるサブセットよる第２時間量に対して使用し、
前記第１時間量は第２時間量よりも大きい、
上記（１）に記載のシステム。
（７）
前記輸送装置のサブセットは、ブロックチェーンネットワークに属している、上記（１）に記載のシステム。
（８）
前記プロセッサは、前記ソフトウェアアップデートを有効化し、前記ソフトウェアアップデートを複数の前記輸送装置を通して配布するために前記ブロックチェーンネットワークのスマートコントラクトを実行する、上記（７）に記載のシステム。
（９）
前記プロセッサは、前記ソフトウェアアップデートの第１有効化を、最も少ない量の潜在的相互作用を含んでいる第１環境において実行し、前記第１有効化が成功した場合、前記ソフトウェアアップデートの更なる有効化を、前記第１環境よりも多くの量の潜在的相互作用を含んでいる更なる環境において実行する、上記（１）に記載のシステム。
（１０）
前記プロセッサは、前記ソフトウェアアップデートの更なる有効化を他の輸送装置から受信する、上記（９）に記載のシステム。

Claims (8)

1. システムであって、
   輸送装置のサブセットの輸送装置のプロセッサと、
   前記プロセッサに通信可能に結合されているメモリと、を備え、前記プロセッサは、
   前記輸送装置においてソフトウェアアップデートを受信し、
   前記ソフトウェアアップデートを、
   前記ソフトウェアアップデートが使用された時間期間と、
   前記輸送装置のサブセットによる前記ソフトウェアアップデートの利用回数と、
   の１つ以上に基づいて有効化し、
   前記有効化に基づいて前記ソフトウェアアップデートを、前記輸送装置のサブセットよりも大きい前記輸送装置の更なるサブセットに配布する、
   システム。
2. 前記プロセッサは、前記ソフトウェアアップデートを、前記輸送装置の更なるサブセットよりも大きい、すべての残っている輸送装置のセットに配布する、請求項１に記載のシステム。
3. 前記輸送装置のサブセット、前記輸送装置の更なるサブセット、および、すべての残っている輸送装置のセットの１つ以上は、
   既存のソフトウェア、
   既存のハードウェア、
   地理的位置、
   環境の温度、
   輸送装置の型、
   輸送装置のモデル、
   輸送装置の状態、
   道路の状態、および
   輸送装置の目的地の１つ以上に基づいている、請求項１に記載のシステム。
4. 前記プロセッサは、前記ソフトウェアアップデートを、
   前記輸送装置のサブセットによる第１時間量、および、
   前記輸送装置の更なるサブセットよる第２時間量に対して使用し、
   前記第１時間量は第２時間量よりも大きい、
   請求項１に記載のシステム。
5. 前記輸送装置のサブセットは、ブロックチェーンネットワークに属している、請求項１に記載のシステム。
6. 前記プロセッサは、前記ソフトウェアアップデートを有効化し、前記ソフトウェアアップデートを複数の前記輸送装置を通して配布するために前記ブロックチェーンネットワークのスマートコントラクトを実行する、請求項５に記載のシステム。
7. 前記プロセッサは、前記ソフトウェアアップデートの第１有効化を、最も少ない量の潜在的相互作用を含んでいる第１環境において実行し、前記第１有効化が成功した場合、前記ソフトウェアアップデートの更なる有効化を、前記第１環境よりも多くの量の潜在的相互作用を含んでいる更なる環境において実行する、請求項１に記載のシステム。
8. 前記プロセッサは、前記ソフトウェアアップデートの更なる有効化を他の輸送装置から受信する、請求項７に記載のシステム。

Images