JP2023532179A - 要望に基づくエネルギー共有 - Google Patents

Abstract

例示的な操作は、満充電のために輸送体が必要とする第１のエネルギー量を充電ステーションによって判定することと、輸送体が後の時点で返還するであろう第２のエネルギー量を充電ステーションによって判定することと、第１のエネルギー量と第２のエネルギー量との間の差に等しい充電レベルまで輸送体を充電ステーションによって充電することと、のうちの１つ又は複数を含む。【選択図】図１

Description

関連出願の相互参照
本出願は、「優先度に基づくエネルギー移送（ＰＲＩＯＲＩＴＹ－ＢＡＳＥＤ ＥＮＥＲＧＹ ＴＲＡＮＳＦＥＲ）」と題する同時係属中の米国非仮特許出願に関連するものである。両出願は同日に出願され、それぞれが参照によりその全体が本明細書に組み込まれる。

自動車、オートバイ、トラック、飛行機、列車などの車両又は輸送体が、さまざまな方法で乗員及び／又は商品に対する輸送の要望に概ね応えている。輸送体に関連する機能を、輸送体の内部及び／又は外部にあるスマートフォン及び／又はコンピュータなどのさまざまな計算装置によって識別し、利用する場合がある。

例示的な一実施形態では、満充電のために輸送体に必要とされる第１のエネルギー量を充電ステーションによって判定することと、輸送体が後の時点で充電ステーションに返還するであろう第２のエネルギー量を充電ステーションによって判定することと、第１のエネルギー量と第２のエネルギー量との間の差に等しい充電レベルまで、充電ステーションによって、輸送体を充電することと、のうちの１つ又は複数を含む方法が提供される。

別の例示的な実施形態では、プロセッサ及びメモリを備えるシステムが提供される。ここで、プロセッサは、満充電のために輸送体に必要とされる第１のエネルギー量を判定することと、輸送体が後の時点で充電ステーションに返還するであろう第２のエネルギー量を判定することと、第１のエネルギー量と第２のエネルギー量との間の差に等しい充電レベルまで輸送体を充電することと、のうちの１つ又は複数を実施するように構成される。

更なる例示的な実施形態では、命令を含む非一時的なコンピュータ可読媒体が提供される。命令は、プロセッサによって読み取られると、プロセッサに、満充電のために輸送体に必要とされる第１のエネルギー量を判定することと、輸送体が後の時点で充電ステーションに返還するであろう第２のエネルギー量を判定することと、第１のエネルギー量と第２のエネルギー量との間の差に等しい充電レベルまで輸送体を充電することと、のうちの１つ又は複数を実施させる。

図１は、例示的な実施形態に係る輸送体ネットワーク図を示す。 図２Ａは、例示的な実施形態に係る、更なる輸送体ネットワーク図を示す。 図２Ｂは、例示的な実施形態に係る、別の輸送体ネットワーク図を示す。 図２Ｃは、例示的な実施形態に係る、ブロックチェーンを含むアーキテクチャ構成を示す。 図３Ａは、例示的な実施形態に係る流れ図を示す。 図３Ｂは、例示的な実施形態に係る別の流れ図を示す。 図４は、例示的な実施形態係る、機械学習輸送体ネットワーク図を示す。 図５Ａは、例示的な実施形態係る、車両に関連付けられたデータベーストランザクションを管理するための例示的な車両構成を示す。 図５Ｂは、例示的な実施形態係る、さまざまな車両間で実行されるデータベーストランザクションを管理するための別の例示的な車両構成を示す。 図６Ａは、例示的な実施形態係るブロックチェーンアーキテクチャ構成を示す。 図６Ｂは、例示的な実施形態係る別のブロックチェーン構成を示す。 図６Ｃは、例示的な実施形態係る、ブロックチェーントランザクションデータを保存するためのブロックチェーン構成を示す。 図６Ｄは、例示的な実施形態係る例示的なデータブロックを示す。 図７は、例示的な実施形態のうちの１つ又は複数を支援する例示的なシステムを示す。

本明細書で概ね説明し図面に示す本発明の構成要素は、多種多様な異なる構成で配置され設計され得ることが容易に理解されよう。このため、添付の図に示す方法、装置、非一時的コンピュータ可読媒体及びシステムのうちの少なくとも１つの実施形態に関する以下の詳細な説明は、特許請求される本出願の範囲を限定することを意図するものではなく、単に選択された実施形態を代表するにすぎない。

本明細書全体に記載した本発明の特徴、構造又は特性は、１つ又は複数の実施形態の任意の適切な方法で組み合わされてもよい。例えば、本明細書全体を通して、「例示的な実施形態」、「いくつかの実施形態」又は他の類似する言葉の使用は、実施形態に関連して説明した特定の特徴、構造又は特性が少なくとも１つの実施形態に含まれ得るという事実を指す。このため、本明細書全体にわたる「例示的な実施形態」、「いくつかの実施形態では」、「他の実施形態では」又は他の類似する言葉の出現がいずれも、必ずしも実施形態の同じグループを指すわけではなく、記載した特徴、構造又は特性は、１つ又は複数の実施形態の任意の適切な方法で組み合わされてもよい。図では、描かれている接続が一方向又は双方向の矢印であっても、要素間の任意の接続が一方向及び／又は双方向の通信を可能にすることができる。本解決策では、輸送体は、自動車、トラック、歩行者専用エリア用バッテリ式電気車両（ＢＥＶ）、ｅ－Ｐａｌｅｔｔｅ、燃料電池バス、オートバイ、スクータ、自転車、ボート、ＲＶ車両、飛行機、及びある場所から別の場所へ人及び／又は物資を輸送するために使用され得る任意の物体、のうちの１つ又は複数を含み得る。

さらに、「メッセージ」という用語を実施形態の説明で使用している場合があるが、パケット、フレーム、データグラムなどの他のタイプのネットワークデータも使用され得る。さらに、特定のタイプのメッセージ及び信号伝達を例示的な実施形態で描写する場合があるが、このようなメッセージ及び信号伝達は１つの特定のタイプのメッセージ及び信号伝達に限定されるものではない。

例示的な実施形態では、輸送体（本明細書では車両又は自動車とも呼ばれる）、データ収集システム、データ監視システム、検証システム、認可システム及び車両データ配信システムのうちの少なくとも１つを提供する方法、システム、コンポーネント、非一時的コンピュータ可読媒体、装置及び／又はネットワークが提供される。無線データネットワーク通信及び／又は有線通信メッセージなどの通信メッセージの形態で受信された車両状態状況データは、車両／輸送体の状態の状況を識別し且つ輸送体の状況及び／又は変化に関するフィードバックを提供するために処理されてもよい。一例では、ユーザプロファイルは、現在の車両イベント、サービスステーションでのサービス停止を認可し、その後の車両レンタルサービスを認可し、車両間通信を可能にするために、特定の輸送体／車両に適用されてもよい。

通信インフラ内では、分散型データベースは、相互に通信する複数のノードを含む分散ストレージシステムである。ブロックチェーンは、分散型データベースの一例であり、信頼できない関係者（untrusted party）間で記録を維持することができる追加専用（append-only）の不変データ構造（即ち、分散型台帳）を含む。信頼できない関係者は、本明細書ではピア、ノード又はピアノードと呼ばれる。各ピアはデータベース記録のコピーを保持し、分散したピア間で合意に達することなく単一のピアがデータベース記録を変更することはできない。例えば、ピアは合意プロトコルを実行して、ブロックチェーンストレージエントリを検証し、ストレージエントリをブロックにグループ化し、ブロックを介してハッシュチェーンを構築する。このプロセスは、一貫性を保つために、必要に応じてストレージエントリを並べ替えて台帳を作成する。パブリックブロックチェーン又は自由参加型（permissionless）ブロックチェーンでは、誰でも特定のＩＤなしで参加することができる。パブリックブロックチェーンは、暗号通貨を含み、プルーフオブワーク（ＰｏＷ）などのさまざまなプロトコルに基づく合意を使用することができる。一方で、許可型（permissioned）ブロックチェーンデータベースでは、資金、商品、情報などを交換する企業など、共通の目標を共有しているが互いに完全に信頼していないか又は完全に信頼することができないエンティティのグループ間の相互作用を保護することができる。本発明の解決策は、許可型及び／又は自由参加型ブロックチェーン設定で機能することができる。

スマートコントラクトは、（ブロックチェーンの形態である場合がある）共有型台帳又は分散型台帳の改ざん防止プロパティと、エンドースメント又はエンドースメントポリシーと呼ばれるメンバーノード間の基本的な同意を活用する、信頼できる分散アプリケーションである。一般に、ブロックチェーンエントリは、ブロックチェーンに委任される前に「承認」される一方、承認されていないエントリは無視される。典型的なエンドースメントポリシーは、スマートコントラクト実行可能コードが、承認に必要な一連のピアノードの形態で、エントリのエンドーサを指定することができるようにする。クライアントがエンドースメントポリシーで指定されたピアにエントリを送信すると、エントリが実行されてエントリが検証される。検証後、エントリはオーダ段階に入る。この段階では、合意プロトコルを使用して、ブロックにグループ化された承認済みエントリのオーダされた順序が生成される。

ノードは、ブロックチェーンシステムの通信エンティティである。「ノード」は、異なるタイプの複数のノードが同じ物理サーバ上で実行することができるという意味で、論理機能を実行してもよい。ノードは信頼ドメインにグループ化され、さまざまな方法でノードを制御する論理エンティティに関連付けられる。ノードは、エントリ呼び出しをエンドーサ（例えば、ピア）に送信し且つエントリ提案をオーダサービス（例えば、オーダノード）に送信するクライアントノード又は提出クライアントノードなど、さまざまなタイプを含み得る。別のタイプのノードには、クライアントが送信したエントリを受信し、エントリを委任し、ブロックチェーンエントリの台帳の状態とコピーを維持することができるピアノードが挙げられる。ピアにはこのほか、エンドーサの役割を演ずることができる。オーダサービスノード又はオーダ者とは、全ノードに対して通信サービスを実施するノードであり、エントリを委任してブロックチェーンのワールドステートを変更するときに、システム内のピアノードのそれぞれへの送信などの配信保証を実施する。ワールドステートは、通常、制御情報及びセットアップ情報を含む初期ブロックチェーンエントリを構成することができる。

台帳は、ブロックチェーンのあらゆる状態推移の、順序付けされ且つ改ざん防止された記録である。状態推移が、参加者（例えば、クライアントノード、オーダノード、エンドーサノード、ピアノードなど）によって送信されたスマートコントラクト実行可能コードの呼び出し（即ち、エントリ）から生じる場合がある。エントリが、作成、更新、削除などの１つ又は複数のオペランドとして台帳に委任される一連のアセットのキーと値の対をもたらす場合がある。台帳は、不変で順序付けされた記録をブロックに保存するために使用されるブロックチェーン（チェーンとも呼ばれる）を含む。台帳はこのほか、ブロックチェーンの現在の状態を維持する状態データベースを含む。典型的には、チャネルごとに１つの台帳がある。各ピアノードは、メンバーである各チャネルの台帳のコピーを保持する。

チェーンは、ハッシュリンクされたブロックとして構造化されたエントリログであり、各ブロックには、Ｎが１以上である一連のＮエントリが含まれる。ブロックヘッダは、ブロックのエントリのハッシュのほか、前のブロックのヘッダのハッシュを含む。このようにして、台帳の全エントリを順序付けし、暗号学的に連結してもよい。このため、ハッシュリンクを壊さずに台帳データを改ざんすることはできない。ごく最近追加されたブロックチェーンブロックのハッシュが、それより前のチェーン上のあらゆるエントリを表し、全ピアノードが一貫した信頼できる状態にあることを確実なものにすることができる。チェーンは、ピアノードファイルシステム（即ち、局所的な付属のストレージ、クラウドなど）状に保存されてもよく、ブロックチェーン作業負荷の追加専用の性質を効率的に支持する。

不変台帳の現在の状態は、チェーンエントリログに含まれる全キーの最新の値を表す。現在の状態は、チャネルに知られている最新のキー値を表すため、ワールドステートと呼ばれることがある。スマートコントラクト実行可能コードの呼び出しが、台帳の現在の状態データに対してエントリを実行する。このようなスマートコントラクト実行可能コードの相互作用を効率化するために、キーの最新の値を状態データベースに保存してもよい。状態データベースは、単にチェーンのエントリログへのインデックス付きビューである場合があるため、いつでもチェーンから再生成することができる。状態データベースは、ピアノードの起動時及びエントリが受け入れられる前に、自動的に回復されてもよい（あるいは必要に応じて生成されてもよい）。

ブロックチェーンは、中央ストレージではなく、分散型で不変の安全なストレージであり、ノードはストレージ内の記録への変更を共有する必要がある点で、従来のデータベースとは異なる。ブロックチェーンに固有であり、ブロックチェーンの実装に役立ついくつかのプロパティには、不変の台帳、スマートコントラクト、セキュリティ、プライバシー、分散化、合意、承認、アクセス可能性などが含まれるが、ここに挙げたものに限定されない。

例示的な実施形態では、特定の車両にサービスが提供されたり、及び／又は車両に適用されるユーザプロファイルにサービスが提供されたりする。例えば、ユーザは、車両の所有者、あるいは別の関係者が所有する車両の操作者であってもよい。車両は一定の間隔でサービスを必要とする場合があり、サービスの要望では、サービスを受けることを許可する前に承諾を必要とする場合がある。このほか、サービスセンタが、車両の現在のルート計画とサービス要件の相対的なレベル（例えば、即時、重度、中程度、軽度など）に基づいて、近くのエリアの車両にサービスを提供してもよい。車両の要望は、感知したデータを車両内の中央制御コンピュータ装置及び／又は車両から離れた中央制御コンピュータ装置に報告する１つ又は複数の車両及び／又は道路のセンサ又はカメラを介して監視されてもよい。このデータは、レビューと行動のために管理サーバに転送される。センサは、輸送体の内部、輸送体の外部、輸送体から離れた固定物体及び輸送体に近接する別の輸送体のうちの１つ又は複数に配置されてもよい。センサはこのほか、輸送体の速度、輸送体の制動、輸送体の加速、燃料の残量、サービスの要望、輸送体のギアシフト、輸送体のステアリングなどに関連付けられてもよい。本明細書で説明するように、このほか、センサは、輸送体内の無線装置及び／又は輸送体に近接する無線装置などの装置であってもよい。このほか、センサ情報を使用して、車両が安全に動作しているか否か及び乗員が車両アクセス及び／又は使用期間中などの任意の予期しない車両状況に関与しているか否かが識別されてもよい。車両の動作前、動作中及び／又は動作後に収集された車両情報を識別し、共有型／分散型台帳のトランザクションに保存してもよい。このトランザクションは、許可付与共同体によって、ひいてはブロックチェーンメンバーシップグループなどを介した「分散型」の方法にて判定されるように生成されて不変の台帳に委任されてもよい。

各利害関係者（即ち、所有者、ユーザ、企業、代理店など）は、個人情報の公開を制限したい場合があるため、ブロックチェーンとその不変性を使用して、特定のユーザ車両プロファイルごとに許可を管理することができる。スマートコントラクトは、補償を提供し、ユーザプロファイルの点数／評価／批評を定量化し、車両イベント許可を適用し、サービスが必要な時期を判定し、衝突イベント及び／又は劣化イベントを特定し、安全上の懸念イベントを特定し、イベントの関係者を特定し、且つそのような車両イベントデータへのアクセスを求めている登録エンティティに配信を提供するために用いられてもよい。このほか、結果を特定してもよく、必要な情報は、ブロックチェーンに関連付けられた合意アプローチに基づいて、登録された企業間及び／又は個人間で共有することができる。そのようなアプローチは、従来の集中型データベースでは実施されないことがあり得る。

本解決策のさまざまな運転システムは、ソフトウェア、一連のセンサのほか、機械学習機能、光検出及び測距（ＬＩＤＡＲ）投影機、レーダ、超音波センサなどを利用して、輸送体がナビゲーション及びその他の目的で使用することができる地形と道路の地図を作成することができる。いくつかの実施形態では、このほか、ＧＰＳ、地図、カメラ、センサなどを、ＬＩＤＡＲの代わりに自律型車両で使用することができる。

本解決策は、特定の実施形態では、自動化された迅速な認証スキームを介してサービスを車両に認可することを含む。例えば、充電ステーション又は燃料ポンプまでの運転は、車両の操作者又は自律型輸送体によって実施される場合があり、サービス及び／又は充電ステーションによって認証が受信される場合、充電又は燃料を受け取るための認証は遅滞なく実施される場合がある。車両は、サービスを受け入れることを認可されたアカウントに連結された現在有効なプロファイルを有する車両の識別を提供する通信信号を提供することができ、通信信号は後に補償によって修正されることができる。別の識別子をユーザの装置から無線でサービスセンタに送信して、輸送体とサービスセンタとの間の第１の認可作業を追加の認可作業に置き換えるか補足するなど、追加の認証を提供するために追加の手段が使用されてもよい。

共有され受信されたデータがデータベースに保存されてもよい。このデータベースは、データを１つの単一データベース（例えば、データベースサーバ）内で、概ね１つの特定の場所に保持する。この場所は、中央コンピュータ、例えば、デスクトップの中央処理装置（ＣＰＵ）、サーバのＣＰＵ又はメインフレームコンピュータである。集中データベースに保存された情報に、典型的には、複数の異なる点からアクセスすることができる。集中データベースでは、その場所が１か所であるため、特にセキュリティの目的で、管理、保守及び制御が容易である。集中データベース内では、このほか、全データを１つの場所に保存することが、所与のデータセットに一次記録が１つしかないことを意味するため、データの冗長性が最小限に抑えられる。輸送体関連のデータ及びトランザクションを保存するためにブロックチェーンが使用されてもよい。

例示的な実施形態によれば、輸送体と充電ステーションとの間の要望に基づくエネルギー共有のための解決策が提供される。Ｖｅｈｉｃｌｅ ｔｏ Ｇｒｉｄ（車両対グリッド）（Ｖ２Ｇ）による余剰エネルギーの提供は、特に、エネルギー需要が高い時期に有用である。電気輸送体又はハイブリッド輸送体が、一時的な移動エネルギーストレージとして機能する可能性がある。例示的な実施形態では、電気輸送体又はハイブリッド輸送体から得られるエネルギー量を制御してもよく、一定期間内に輸送体が要求するであろう第２のエネルギー量を判定してもよい。輸送体が、サーバからの指示に基づいて、充電ステーションを介してグリッドにエネルギーを返還することを独自に判定してもよい。この決定（又は指示）は、現在の気温、１年のうちの１日、１日のうちのある時間、予測される天候の変化、物体（輸送体、住居、施設など）の現在のエネルギー使用量及び（地理的な場所、都市などの）全体的なエネルギー使用量に基づくものであってもよい。この決定はこのほか、（以下でさらに説明する）エネルギー消費状況をモデル化するＡＩシステムによって提供される機械学習データに基づいて実施されてもよい。

一実施形態では、充電ステーションにエネルギーを提供する輸送体は、充電ステーションからそのようなエネルギーを取り出さないことによってエネルギーを保存する輸送体と同等である。充電ステーションは、輸送体にエネルギーを提供してもよいが、履歴データ又は機械学習データに基づいて、この輸送体によって近い将来に充電ステーションに返還されると考えられるエネルギーの量を提供しなくてもよい。

例えば、輸送体のユーザが、充電ステーションから輸送体を１００％まで充電したいと考えている。充電ステーションは、使用量が５０％のみであろうことと、輸送体が通常、将来充電ステーションに２５%を返還することを「確信」している。充電ステーションは、輸送体上及び／又は輸送体外にあり得るデータストレージから取得した以前の使用記録に基づいて、この情報を認識している。さらに、充電ステーションは、特定の期間（時間、日、週など）にわたる輸送体の目的地及びルートを受信してもよい。この情報は、輸送体、輸送体及び充電ステーションに通信可能に結合されたサーバ、別の輸送体、携帯電話などの装置などから受信することができる。この情報に基づいて、充電ステーションは、輸送体が必要とするであろうエネルギー量を判定し、同等又はほぼ同等の量を提供することができる。充電ステーションはこのほか、輸送体が必要とするエネルギー量を判定する際に、天候、道路状況、交通状況、輸送体の状況などを考慮してもよい。充電ステーションは、必要な量のエネルギーを提供することにより、輸送体が１００%の電力を供給されていた場合に充電ステーションが輸送体に提供したであろう追加のエネルギーを保持する。そのため、輸送体は充電ステーションに戻り、余剰エネルギーをグリッドに返還する必要がなくなる。任意の余剰エネルギーを提供するために充電ステーションに戻る必要がない輸送体に関連する節約を計算することができる。

本明細書の例を参照すると、充電ステーションは、エネルギー使用量が５０%になり且つ残りのエネルギー充電が２５%になるであろうと判定するため、ユーザが輸送体に１００％充電したい場合であっても、エネルギーの移送を７５％で停止してもよい。エネルギーの２５%を充電ステーションから取り出さないことは、一時的に１００%のエネルギー充電を輸送体に提供してから、輸送体が戻って、この例では２５%～５０%などの充電を再び預け入れるよりも、Ｖ２Ｇエネルギー移送を提供するのに効率的な方法である。充電ステーションとの間の往復で定期的に消費されるであろう節約エネルギー量は、往復を実施しない輸送体に基づいて、節約された量（２５%）と、消費されて現在節約されていたであろう量（例えば、２．５%）とを合計した量を含み得る総節約エネルギー量を求めて、計算される。エネルギー節約量は、輸送体のタイプ、充電ステーションまでの距離、輸送体に関連する区分及び１日あたりの乗員数などに基づいて、充電ステーション（又は輸送体）によって計算されてもよい。一例では、輸送体（又はそのユーザ）が、エネルギー移送の対価（例えば、金銭的クレジット又はエネルギークレジット）を受け取ってもよい。

一実施形態では、輸送体は、ブロックチェーンネットワークを介してサーバ及び充電ステーションに通信可能に結合されてもよい。輸送体、サーバ及び充電ステーションは、ブロックチェーンピアとして機能してもよい。エネルギー要求は、充電ステーションの範囲内のいくつかの輸送体ピアに送信されてもよい。充電ステーションは、ブロックチェーン台帳に記録されたトランザクションに基づいて、充電ステーションにエネルギーを提供した輸送体を特定してもよい。

一実施形態では、輸送体は、ローカルストレージ又はブロックチェーン台帳のローカルのコピーに全記録を保持する。これとは別に、記録は中央サーバで作成されてもよい。記録は、以前に記録されたエネルギーの節約量と共に、輸送体のエネルギー移送履歴を含んでもよい。輸送体はこのほか、現在のエネルギーレベルと、乗客及び／又は貨物の移送中の推定エネルギーレベルとを記録してもよい。このデータに基づいて、エネルギー要求が輸送体に送信されてもよい。一方で、短い局地的移動を記録する輸送体は、大量の余剰エネルギーを有する。輸送体が貨物及び／又は乗客の移送を完了した時点で、現在のエネルギーレベルが記録され、余剰エネルギーの利用可能性が再評価されてもよい。一例では、予測される利用可能なエネルギー量は、輸送体のプロセッサによって計算され、サーバ又は充電ステーションで利用可能にされてもよい。別の例では、サーバは、輸送体のローカルストレージにアクセスしてもよく、現在のエネルギーレベル、輸送体の現在の位置、輸送体の目的地などに基づいて、予測されるエネルギーレベルを判定してもよい。

輸送体へ又は輸送体から移送されるエネルギーの量は、輸送体上及び／又は輸送体外に配置され得るサーバ又はコンピュータによって判定されてもよい。昼夜の時間、エネルギーの移送時間、移送されるエネルギーの値、グリッドからのエネルギーの最終的な受信者のタイプ、充電ステーションから別の輸送体へのエネルギーの直接移送などのパラメータが考慮されてもよい。充電ステーション（又はサーバ）は、アクセス可能な（距離及び／又は時間を含む）範囲内で利用可能な輸送体が何かを判定してもよい。充電ステーション／サーバはこのほか、その要求している充電ステーションからの現在の距離と輸送体のエネルギー消費量とに基づいて、輸送体からエネルギーを取得する効率を推定してもよい。例えば、サーバが、要求している充電ステーションの範囲内でいくつかの輸送体を検出した場合、充電ステーション／サーバは、充電ステーション／サーバと輸送体との間の通信を介して余剰エネルギーを有する輸送体を特定してもよい。サーバは、輸送体ごとに、要求している充電ステーションに到達するために必要な追加のエネルギー消費量を計算してもよい。次に、追加のエネルギー消費量が最も少ない輸送体は、最も効率的な余剰エネルギーの移送を実施する充電ステーションに誘導されてもよい。

例示的な実施形態によれば、車両と充電ステーションとの間の余剰エネルギーを管理するアプローチが実施される。本明細書で説明するように、輸送体は無差別に充電ステーションに送られるわけではなく、単純に１００%まで充電されるわけではない場合がある。代わりに、本システムは、輸送体が余剰エネルギーを有し、充電ステーションにエネルギーを返還する履歴を有し（あるいはエネルギーを提供するための合意を提供し）、充電ステーションなどに到達するための最小量の追加エネルギーを必要とする場合、グリッドに余剰エネルギーを提供するために輸送体を充電ステーションに誘導する。そのため、充電ステーション及び輸送体が、さらに効率的で堅牢なエネルギー保存を可能にする予測及び追加のエネルギー量を量る能力が提供される。

一実施形態では、輸送体は、ブロックチェーンネットワークを介して充電ステーションに接続されてもよい。輸送体及び充電ステーションは、ブロックチェーンピアとして機能してもよい。エネルギー要求は、充電ステーションのアクセス可能な範囲内のいくつかの輸送体に送信されてもよい。輸送体及び充電ステーションノードは、どの輸送体がエネルギーを提供する予定か、エネルギーの１００%未満を充電する予定かについて合意に達してもよい。充電ステーションピアが少なくとも１つの輸送体から合意を受信した時点で、その輸送体は充電ステーションに誘導され得る一方で、他の輸送体は他に誘導される。エネルギー移送トランザクションは、利用可能なエネルギー量を追跡するためにブロックチェーンに記録されてもよい。一実施形態では、ブロックチェーンピア（即ち、充電ステーション及び輸送体）のそれぞれが、ブロックチェーン台帳の独自のローカルコピーを維持する。このようにして、輸送体ピアは、スマートコントラクトを実行して、エネルギー移送（又は充電）トランザクションのそれぞれを、そのローカル台帳に記録してもよい。例えば、輸送体は受け取り場所と受け渡し場所と時間とを、その受け取り場所と目的地でのエネルギーレベルと共に記録してもよい。目的地のエネルギーレベルは、輸送体のモデルの既知のエネルギー消費量に基づいて推定されてもよい。受け渡しが完了した時点で、輸送体は、現在の場所及びエネルギーレベルをタイムスタンプと共にローカル台帳に記録してもよい。輸送体の余剰エネルギーの利用可能性は、受け渡しの完了時に更新されてもよい。このようにして、サーバ又は充電ステーションのピアは、余剰エネルギーを有する輸送体に関する全情報を有してもよい。このため、充電ステーションは、その現在位置と、エネルギーレベルと、要求している充電ステーションまでの移動に必要な追加のエネルギー消費とに基づいて、輸送体へのエネルギー移送の要求を生成してもよい。余剰エネルギーレベル、タイムスタンプ付きの場所、輸送体のタイプ及びそのエネルギー消費量は、ブロックチェーン台帳から充電ステーションピアによって取得されてもよい。輸送体の現在のエネルギーレベルは、余剰エネルギーを共有するか、少なめのエネルギーを充電するのに充分なものである必要がある。例えば、特定のタイプの輸送体が、５０%のエネルギーで３日間、現地で駆動することができる。輸送体の現在のエネルギーレベルが７５%である場合、輸送体は、そのエネルギーの最大２５%を、要求している充電ステーションに安全に移送することができる。さらに、輸送体にエネルギーが必要な場合、現地の運転要求に基づいて、満充電ではなく５０%しか充電しない場合がある。次に、充電ステーションピアが輸送体を選択する場合、充電ステーションが要求したエネルギー量に対する輸送体の利用可能なエネルギーに基づいて、エネルギー移送の合意が達成される。輸送体がエネルギーを充電ステーションに移送した時点（あるいは充電ステーションから取り出すエネルギーが少なくなった時点）で、エネルギー移送トランザクションがブロックチェーンに記録され、さらに（金銭的クレジット又はエネルギークレジットなどの）対価が実施される。

本明細書で考察するように、輸送体は、どの輸送体がエネルギーを提供する予定か（あるいは１００％未満の充電になるか）について合意に達してもよい。充電ステーションピアが少なくとも１つの輸送体から合意を受信した時点で、輸送体は、エネルギー移送（又は部分充電）のために充電ステーションに誘導されてもよい。エネルギー移送トランザクションは、利用可能なエネルギー量の追跡を維持するためにブロックチェーンに記録されてもよい。節約量は、将来の参照用に輸送体ごとに記録されてもよい。各エネルギー移送トランザクションは、将来の監査と輸送体ごとの記録とを保持するために、ブロックチェーンに記録されてもよい。

図１は、例示的な実施形態係る輸送体ネットワーク図を示す。図１を参照すると、ネットワーク図１００は、（図示しない）ネットワークを介して充電ステーション（又は充電ステーションノード）１１２に接続された電気（又はハイブリッド）輸送体１０４及び１０５を含む。充電ステーション１１２は、輸送体１０４及び１０５のうちの１つ又は複数からエネルギーの要求１３４／１３５を受信してもよい。同じように、充電ステーション１１２は、範囲内を移動する電気（又はハイブリッド）輸送体１０４及び１０５を検出し、このような輸送体にエネルギーの要求１３４／１３５を送信してもよい。輸送体１０４及び１０５は、その現在の充電データを充電ステーション１１２に提供してもよい。輸送体の現在の充電データが充分であると充電ステーション１１２が判定した場合、充電ステーション１１２は、エネルギーを提供するために充電ステーションに移動するように輸送体に指示してもよい。充電ステーション１１２が、輸送体の現在の充電データが低いと判定し、且つ、例えば、２５％の返還充電がこの輸送体のために残っていて利用可能であると判定した場合、充電ステーション１１２は、輸送体に充電ステーション１１２まで移動し、残りの充電を受け取るように指示してもよい。

一実施形態では、輸送体１０４及び１０５がほぼ同じ量のエネルギーを有する場合、輸送体のうちの１つが、アクセス可能な範囲内の輸送体間の同意（即ち、合意）１３８に基づいて、充電ステーション１１２に確認／合意１３２を提供してもよい。一例では、充電ステーション１１２は、（支払いクレジット、エネルギークレジットなどに基づいて）将来の監査のため、及び／又は後の時点でほぼ同じ量のエネルギーをこの輸送体に返還するために、特定の輸送体が一定量のエネルギーを充電ステーション１１２に提供したことを記録してもよい。

図２Ａは、例示的な実施形態係る輸送体ネットワーク図２００を示す。ネットワークは、プロセッサ２０４を含む輸送体ノード２０２のほか、プロセッサ２０４’を含む輸送体ノード２０２’を含む要素を備える。輸送体ノード２０２、２０２’は、プロセッサ２０４、２０４’のほか、送受信機、送信機、受信機、ストレージ、センサをはじめとする通信を提供可能な要素を含む（図示しない）他の要素を介して互いに通信してもよい。輸送体ノード２０２、２０２’間の通信は、（図示しない）私的ネットワーク及び／又は公共ネットワークを介して、あるいは他の輸送体ノードと、プロセッサ、メモリ及びソフトウェアのうちの１つ又は複数を備える要素とを介して、直接実施されることがある。単一の輸送体ノード及びプロセッサとして描写しているが、複数の輸送体ノード及びプロセッサが存在してもよい。本明細書に記載したり、及び／又は描写したりするアプリケーション、特徴、ステップ、ソリューションなどのうちの１つ又は複数を、本発明の要素が利用したり、及び／又は提供したりしてもよい。

図２Ｂは、例示的な実施形態係る、別の輸送体ネットワーク図２１０を示す。ネットワークは、プロセッサ２０４を含む輸送体ノード２０２のほか、プロセッサ２０４’を含む輸送体ノード２０２’を含む要素を備える。輸送体ノード２０２、２０２’は、プロセッサ２０４、２０４’のほか、送受信機、送信機、受信機、ストレージ、センサをはじめとする通信を提供可能な要素を含む（図示しない）他の要素を介して互いに通信してもよい。輸送体ノード２０２、２０２’間の通信は、（図示しない）私的ネットワーク及び／又は公共ネットワークを介して、あるいは他の輸送体ノードと、プロセッサ、メモリ及びソフトウェアのうちの１つ又は複数を備える要素とを介して、直接実施されることがある。プロセッサ２０４、２０４’は、センサ２１２、有線装置２１４、無線装置２１６、データベース２１８、携帯電話２２０、輸送体ノード２２２、コンピュータ２２４、入出力装置２２６及び音声アプリケーション２２８を含む１つ又は複数の要素２３０とさらに通信することができる。プロセッサ２０４、２０４’は、プロセッサ、メモリ及びソフトウェアのうちの１つ又は複数を備える要素とさらに通信することができる。

単一の輸送体ノード、プロセッサ及び要素として描写しているが、複数の輸送体ノード、プロセッサ及び要素が存在してもよい。情報又は通信が、プロセッサ２０４、２０４’及び要素２３０のいずれかとの間で発生することがある。例えば、携帯電話２２０は、プロセッサ２０４に情報を提供してもよい。プロセッサ２０４は、輸送体ノード２０２を起動して行動を実行させてもよく、情報又は追加情報をプロセッサ２０４’にさらに提供してもよい。プロセッサ２０４’は、輸送体ノード２０２’を起動して行動を実行させてもよく、情報又は追加情報を携帯電話２２０、輸送体ノード２２２及び／又はコンピュータ２２４にさらに提供してもよい。本明細書に記載したり、及び／又は描写したりするアプリケーション、特徴、ステップ、ソリューションなどのうちの１つ又は複数を、本発明の要素が利用したり、及び／又は提供したりしてもよい。

図２Ｃは、例示的な実施形態係る、輸送体から充電ステーションへの優先度に基づくエネルギー移送のための輸送ネットワーク図を示す。図２Ｃを参照すると、ネットワーク図２４０は、ブロックチェーンネットワーク２０６を介して他の輸送体ノード２０２’及び充電ステーションノード２０３に接続された輸送体ノード２０２を含む。充電ステーションノード２０３は、輸送体／車両を代表し得る輸送体ノード２０２及び２０２’に接続されてもよい。ブロックチェーンネットワーク２０６は、エネルギー移送関連データ（即ち、供給者側輸送体ＩＤ、エネルギー量、残量、節約量、移送の日時など）を保存するための台帳２０８を有してもよい。

この例では、１つの充電ステーションノード２０３のみを詳細に説明しているが、複数のそのようなノードをブロックチェーン２０６に接続してもよい。充電ステーションノード２０３は、追加の構成要素を含んでもよく、本明細書で開示する充電ステーションノード２０３の範囲から逸脱することなく、本明細書で説明する構成要素のいくつかを削除したり、及び／又は修正したりしてもよいことを理解されたい。充電ステーションノード２０３は、計算装置又はサーバコンピュータなどであってもよく、半導体ベースのマイクロプロセッサ、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）及び／又は別のハードウェア装置であり得るプロセッサ２０４を含んでもよい。単一のプロセッサ２０４を示しているが、充電ステーションノード２０３は、本出願の範囲から逸脱することなく、複数のプロセッサ、複数のコアなどを含み得ることを理解されたい。

充電ステーションノード２０３はこのほか、プロセッサ２０４によって実行可能な機械可読命令を保存し得る非一時的コンピュータ可読媒体２０１を含んでもよい。機械可読命令の例を、ステップ２１１～２１５として示し、本明細書でさらに考察する。非一時的コンピュータ可読媒体２０１の例には、実行可能な命令を含むか保存する電子、磁気、光学又は他の物理的記憶装置を含んでもよい。例えば、非一時的コンピュータ可読媒体２０１は、ランダムアクセスメモリ（ＲＡＭ）、電気的に消去可能なプログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）、ハードディスク、光ディスク又は他のタイプの記憶装置であってもよい。プロセッサ及び／又はコンピュータ可読媒体は、輸送体ノード上及び／又は輸送体ノード外に全体的に存在しても、部分的に存在してもよい。コンピュータ可読媒体に保存されたステップ又は特徴は、任意の順序でプロセッサ及び／又は要素のいずれかによって完全に実施されても部分的に実施されてもよい。

プロセッサ２０４は、機械可読命令２１１を実行して、満充電のために輸送体（例えば、２０２／２０２’）が必要とする第１のエネルギー量を判定してもよい。輸送体２０２及び２０２’のそれぞれは、ブロックチェーンネットワーク２０６上のネットワークノードとして機能してもよい。ブロックチェーン２０６のネットワークは、参加ノード（例えば、２０２及び２０２’）のためのトランザクションを管理し得る輸送体（即ち、ノード）上に位置する１つ又は複数のスマートコントラクトを使用するように構成されてもよい。プロセッサ２０４は、機械可読命令２１３を実行して、輸送体２０２／２０２’が後に充電ステーション２１２に返還するであろう第２のエネルギー量を判定してもよい。プロセッサ２０４は、機械可読命令２１５を実行して、輸送体２０２／２０２’を、第１のエネルギー量と第２のエネルギー量との間の差に等しい充電レベルまで充電してもよい。さらに、１つ又は複数のステップ又は特徴を追加しても、省略しても、組み合わせても、後に実施するなどしてもよい。

図３Ａは、例示的な実施形態係る方法の流れ図３００を示す。図３Ａを参照すると、充電ステーションノード２０３（図２Ｃを参照）によって例示的な方法が実行されてもよい。図３Ａに示す方法３００は、追加の操作を含んでもよく、本出願の範囲から逸脱することなく、そこに記載の操作のいくつかを削除したり、及び／又は変更したりしてもよいことを理解されたい。このほか、方法３００について、説明のために図２Ｃに示した特徴を参照して説明する。特に、ＳＣノード２０３のプロセッサ２０４は、方法３００に含まれる操作の一部又は全部を実行してもよい。

図３Ａを参照すると、プロセッサ２０４は、以下の各ステップのそれぞれのうちの１つ又は複数を実施してもよい。ブロック３０２では、プロセッサ２０４は、輸送体が満充電のために必要とする第１のエネルギー量を判定してもよい。ブロック３０４では、プロセッサ２０４は、輸送体が後に充電ステーションに返還するであろう第２のエネルギー量を判定してもよい。ブロック３０６では、プロセッサ２０４は、第１のエネルギー量と第２のエネルギー量との間の差に等しい充電レベルまで輸送体を充電してもよい。

図３Ｂは、例示的な実施形態係る例示的な方法の流れ図３２０を示す。図３Ｂを参照すると、方法３２０は、以下のステップのうちの１つ又は複数も含んでもよい。ブロック３２２では、プロセッサ２０４は、第１のエネルギー量に対する第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量と、第２のエネルギー量との間の差に等しい充電レベルまで、後の時点で輸送体を充電してもよい。このため、輸送体が要求された充電（又は満充電）の２５%を常に放棄する場合、第３のエネルギー量は第２のエネルギー量の２５%として計算されてもよい。

ブロック３２４では、プロセッサ２０４は、輸送体が戻って第２のエネルギー量を返還するときの充電ステーションへの輸送体の予測される往復に基づいてエネルギーの節約量を計算してもよい。ブロック３２６では、プロセッサ２０４は、エネルギーの節約量を充電レベルと共に輸送体に提供してもよい。エネルギーの節約量は、第２のエネルギー量を放棄する動機として機能してもよい。ブロック３２８では、プロセッサ２０４は、輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第２のエネルギー量を判定してもよい。機械学習データは、気温、時間帯、時期などに基づいてエネルギーの使用量と需要を予測するＡＩモデルによって生成されてもよい。ブロック３３０では、プロセッサ２０４は、輸送体からの第２のエネルギー量の移送についての確認を受信してもよい。確認は、輸送体及び充電ステーションによって代表されるピア間のブロックチェーン合意であり得ることに留意されたい。ブロック３３２では、プロセッサ２０４は、スマートコントラクトを実行して、ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録してもよい。

図４は、例示的な実施形態係る、機械学習輸送体ネットワーク図４００を示す。ネットワーク４００は、機械学習サブシステム４０６と相互作用する輸送体ノード４０２を含む。輸送体ノードは、１つ又は複数のセンサ４０４を含む。

機械学習サブシステム４０６は、学習モデル４０８を含む。学習モデル４０８は、１つ又は複数の訓練データセットにパターンを見つけることによって予測を生成する機械学習訓練システム４１０によって作成される数学的アーティファクトである。いくつかの実施形態では、機械学習サブシステム４０６は、輸送体ノード４０２に存在する。他の実施形態では、機械学習サブシステム４０６は、輸送体ノード４０２の外部に存在する。

輸送体ノード４０２は、１つ又は複数のセンサ４０４から機械学習サブシステム４０６にデータを送信する。機械学習サブシステム４０６は、１つ又は複数の予測を戻す学習モデル４０８に１つ又は複数のセンサ４０４のデータを提供する。機械学習サブシステム４０６は、学習モデル４０８からの予測に基づいて、１つ又は複数の命令を輸送体ノード４０２に送信する。

更なる実施形態では、輸送体ノード４０２は、１つ又は複数のセンサ４０４のデータを機械学習訓練システム４１０に送信してもよい。さらに別の実施形態では、機械学習サブシステム４０６は、センサ４０４のデータを機械学習サブシステム４１０に送信してもよい。本明細書で説明したり、及び／又は描写したりするアプリケーション、特徴、ステップ、ソリューションなどのうちの１つ又は複数が、本明細書で説明する機械学習ネットワーク４００を利用してもよい。

図５Ａは、例示的な実施形態係る、車両に関連するデータベーストランザクションを管理するための例示的な車両構成５００を示す。図５Ａを参照すると、特定の輸送体／車両５２５がトランザクション（例えば、車両サービス、販売業者トランザクション、受け渡し／受け取り、輸送サービスなど）に従事しているとき、車両はアセット５１０を受け取ったり、及び／又はトランザクションによってアセット５１２を放出／移転したりしてもよい。輸送体プロセッサ５２６は車両５２５に存在し、輸送体プロセッサ５２６、データベース５３０、輸送体プロセッサ５２６及びトランザクションモジュール５２０の間に通信が存在する。トランザクションモジュール５２０は、アセット、関係者、クレジット、サービスの説明、日付、時間、場所、結果、通知、予期しないイベントなどの情報を記録してもよい。トランザクションモジュール５２０内のそのようなトランザクションは、データベース５３０に複製されてもよい。データベース５３０は、ＳＱＬデータベース、ＲＤＢＭＳ、リレーショナルデータベース、非リレーショナルデータベース、ブロックチェーン、分散型台帳のうちの１つであることがあり、輸送体に搭載されていてもよく、輸送体に搭載されていなくてもよく、直接及び／又はネットワークを介してアクセス可能であったりしてもよく、或いは、輸送体にアクセス可能であってもよい。

図５Ｂは、例示的な実施形態係る、さまざまな車両間で実施されるデータベーストランザクションを管理するための例示的な車両構成５５０を示す。車両５２５は、車両がサービスを他の車両と共有する必要がある状況に達したときに、別の車両５０８に関与して、共有、転送、サービスコールの取得などのさまざまな行動を実施してもよい。例えば、車両５０８は、バッテリの充電が予定されている可能性があったり、及び／又はタイヤに問題がある可能性があったり、配送のために荷物を引き取る途中である可能性があったりする。輸送体プロセッサ５２８は、車両５０８内に存在し、輸送体プロセッサ５２８、データベース５５４、輸送体プロセッサ５２８及びトランザクションモジュール５５２の間に通信が存在する。車両５０８は、別の車両５２５であってそのネットワーク内にあり且つそのブロックチェーンメンバーサービスで動作する別の車両５２５に通知してもよい。輸送体プロセッサ５２６が車両５２５内に存在し、輸送体プロセッサ５２６、データベース５３０、輸送体プロセッサ５２６及びトランザクションモジュール５２０の間に通信が存在する。次に、車両５２５は、車両５０８及び／又は（図示しない）サーバから無線通信要求を介して情報を受信して、荷物の集荷を実施してもよい。トランザクションは、両方の車両のトランザクションモジュール５５２及び５２０のログに記録される。クレジットは車両５０８から車両５２５に転送され、転送されたサービスの記録は、ブロックチェーンが互いに異なるか、全メンバーが使用する同じブロックチェーンのログに記録されていることを前提として、データベース５３０／５５４のログに記録される。データベース５５４は、ＳＱＬデータベース、ＲＤＢＭＳ、リレーショナルデータベース、非リレーショナルデータベース、ブロックチェーン、分散型台帳のうちの１つであることがあり、輸送体に搭載されていてもよく、輸送体に搭載されていなくてもよく、直接及び／又はネットワーク経由でアクセス可能であったりしてもよい。

図６Ａは、例示的な実施形態係るブロックチェーンアーキテクチャ構成６００を示す。図６Ａを参照すると、ブロックチェーンアーキテクチャ６００は、特定のブロックチェーン要素、例えば、ブロックチェーングループ６１０の一部としてのブロックチェーンメンバーノード６０２～６０６のグループを含んでもよい。例示的な一実施形態では、許可型ブロックチェーンに、全関係者がアクセス可能であるわけではなく、ブロックチェーンデータへのアクセスが許可されたメンバーのみがアクセス可能である。ブロックチェーンノードは、ブロックチェーンエントリの追加と検証プロセス（合意）など、さまざまな活動に参加する。ブロックチェーンノードのうちの１つ又は複数は、エンドースメントポリシーに基づいてエントリを承認してもよく、全ブロックチェーンノードにオーダサービスを提供してもよい。ブロックチェーンノードは、ブロックチェーン行動（認証など）を開始し、ブロックチェーンに保存されているブロックチェーンの不変台帳への書き込みを試みてもよい。その台帳のコピーはこのほか、基盤となる物理的インフラに保存されてもよい。

ブロックチェーントランザクション６２０は、トランザクションが受信され、メンバーのノードによって指示された合意モデルによって承認されると、コンピュータのメモリに保存される。承認されたトランザクション６２６を、ブロックチェーンの現在のブロックに保存し、現在のブロック内のトランザクションのデータコンテンツのハッシュを実行し、前のブロックの前のハッシュを参照することを含む委任手順を介してブロックチェーンに委任する。ブロックチェーン内には、登録された受信者、車両の特徴、要件、許可、センサの閾値など、スマートコントラクト実行可能アプリケーションコード６３２に含まれるトランザクションの同意及び行動の状況を定義する１つ又は複数のスマートコントラクト６３０が存在してもよい。このコードは、要求側エンティティが車両サービスを受けるために登録されているか否か、プロファイル状況に基づいてどのようなサービスの特徴を受け取る資格があるか／要求されているか、その後のイベントでエンティティの行動を監視するか否かを識別するように構成されてもよい。例えば、サービスイベントが発生し、ユーザが車両に乗っている場合、センサデータの監視が引き起こされてもよく、車両の充電レベルなどの特定のパラメータが特定の閾値を特定の期間上回っているか下回っていると識別されてもよく、その結果、サービスを識別して、参考のため保存することができるように、管理者（即ち、車両の所有者、車両の操作者、サーバなど）に警告を送信する必要がある現在の状況が変更されてもよい。収集された車両センサデータは、車両の状況に関する情報を収集するために使用されるセンサデータの種類に基づくものであってもよい。センサデータはこのほか、移動する場所、平均速度、最高速度、加速率、何らかの衝突があったか否か、予想されたルートが取られたか、次の目的地はどこか、安全対策が整っているか否か、車両に充分な充電／燃料があるか否かなどの車両イベントデータ６３４の基礎になってもよい。そのような情報はいずれも、次にブロックチェーンに保存されるスマートコントラクト状況６３０の基礎となってもよい。例えば、スマートコントラクトに保存されたセンサ閾値を、検出されたサービスが必要であるか否か、いつ、どこでサービスを実施する必要があるかの基準として使用することができる。

図６Ｂは、例示的な実施形態係る共有型台帳構成を示す。図６Ｂを参照すると、ブロックチェーン論理例６４０は、特定のトランザクションのために計算装置及び実行プラットフォームに関連しているＡＰＩ又はプラグインアプリケーションとして、ブロックチェーンアプリケーションインターフェース６４２を含む。ブロックチェーン構成６４０は、アプリケーションプログラミングインターフェース（ＡＰＩ）に連結されて、保存されたプログラム／アプリケーションコード（例えば、スマートコントラクト実行可能コード、スマートコントラクトなど）にアクセスして実行する１つ又は複数のアプリケーションであって、参加者が求めるカスタマイズされた構成によって作成することができ、自身の状態を維持し、自身のアセットを制御し、外部情報を受信することができる１つ又は複数のアプリケーションを含んでもよい。これをエントリとして展開し、分散型台帳に追加することを介して、全ブロックチェーンノードにインストールすることができる。

スマートコントラクトアプリケーションコード６４４は、アプリケーションコードを確立することによって、ブロックチェーントランザクションの基礎を提供する。アプリケーションコードが実行されると、トランザクション状況が有効になる。スマートコントラクト６３０が実行されると、特定の承認済みトランザクション６２６が生成され、次にブロックチェーンプラットフォーム６５２に転送される。プラットフォームは、セキュリティ／認可６５８と、トランザクション管理６５６を実行する計算装置と、トランザクションとスマートコントラクトをブロックチェーンに保存するメモリとしてのストレージ部分６５４と、を含む。

ブロックチェーンプラットフォームは、ブロックチェーンデータと、サービス（例えば、暗号信託サービス、仮想実行環境など）と、新たなエントリを受信して保存し、データエントリへのアクセスを求めている監査人へのアクセスを提供するために使用され得る基盤となる物理的コンピュータインフラとのさまざまな層を含んでもよい。ブロックチェーンは、プログラムコードを処理し、物理的インフラを使用するために必要な仮想実行環境へのアクセスを提供するインターフェースを公開してもよい。暗号信託サービスを使用して、アセット交換エントリなどのエントリを検証し、情報を非公開にしてもよい。

図６Ａ及び図６Ｂのブロックチェーンアーキテクチャ構成は、ブロックチェーンプラットフォームによって公開される１つ又は複数のインターフェースと、ブロックチェーンプラットフォームによって提供されるサービスとを介して、プログラム／アプリケーションコードを処理し、実行してもよい。非限定的な例として、督促、更新及び／又は変更、更新などの対象となる他の通知を実行すべくスマートコントラクトが作成されてもよい。スマートコントラクト自体を使用して、認可とアクセスの要件及び台帳の使用に関連する規則を特定することができる。例えば、情報は、ブロックチェーン層に含まれる１つ又は複数の処理エンティティ（例えば、プロセッサ、仮想マシンなど）によって処理され得る新たなエントリを含んでもよい。結果には、スマートコントラクトで定義された基準及び／又はピアの合意に基づいて、新たなエントリを拒否するか承認する決定が含まれてもよい。物理的インフラは、本明細書に記載のデータ又は情報のいずれかを取得するために利用されてもよい。

スマートコントラクト実行可能コード内では、高レベルのアプリケーションとプログラミング言語を介してスマートコントラクトが作成され、ブロックチェーンのブロックに書き込まれてもよい。スマートコントラクトは、ブロックチェーン（例えば、ブロックチェーンピアの分散型ネットワーク）に登録されたり、保存されたり、及び／又は複製されたりする実行可能コードを含んでもよい。エントリは、スマートコントラクトコードの実行であり、スマートコントラクトに関連付けられた状況が満たされることに応答して実施されることができる。スマートコントラクトの実行は、デジタルブロックチェーン台帳の状態に対する信頼できる変更を引き起こしてもよい。スマートコントラクトの実行によって引き起こされるブロックチェーン台帳の変更は、１つ又は複数の合意プロトコルを介して、ブロックチェーンピアの分散ネットワーク全体に自動的に複製されてもよい。

スマートコントラクトは、データをキーと値の対の形態でブロックチェーンに書き込んでもよい。さらに、スマートコントラクトコードは、ブロックチェーンに保存された値を読み取り、それをアプリケーション操作で使用することができる。スマートコントラクトコードは、さまざまな論理操作の出力をブロックチェーンに書き込んでもよい。このコードは、仮想マシン又は他の計算プラットフォームで一時的なデータ構造を作成するために使用されてもよい。ブロックチェーンに書き込まれたデータは公開されたり、及び／又は暗号化されて非公開として維持されたりすることができる。スマートコントラクトによって使用／生成される一時データは、供給された実行環境によってメモリに保持され、次にブロックチェーンに必要なデータが特定された時点で削除される。

スマートコントラクト実行可能コードには、追加の特徴と共に、スマートコントラクトのコード解釈が含まれてもよい。本明細書で説明するように、スマートコントラクト実行可能コードは、合意プロセス中にチェーン検証ソフトによって一緒に実行されて検証される計算ネットワーク上に展開されるプログラムコードであってもよい。スマートコントラクトの実行可能コードは、ハッシュを受け取り、ブロックチェーンから、以前に保存された特徴抽出器を使用して作成されたデータテンプレートに関連付けられたハッシュを取得する。ハッシュ識別子のハッシュと、保存された識別子テンプレートデータから作成されたハッシュとが一致する場合、スマートコントラクト実行可能コードは要求されたサービスに認可キーを送信する。スマートコントラクト実行可能コードは、暗号化の詳細に関連付けられたブロックチェーンデータに書き込まれてもよい。

図６Ｃは、例示的な実施形態係る、ブロックチェーントランザクションデータを保存するためのブロックチェーン構成を示す。図６Ｃを参照すると、例示的な構成６６０では、車両６６２と、ユーザ装置６６４と、分散型台帳（即ち、ブロックチェーン）６６８と情報を共有するサーバ６６６と、が提供される。サーバは、既知の確立されたユーザプロファイルが、確立された評価プロファイルを有する車両を借りようとしている場合に、車両サービス提供者に問い合わせてユーザプロファイル評価情報を共有するサービス提供者エンティティを表してもよい。サーバ６６６は、車両のサービス要件に関連するデータを受信して処理していてもよい。車両センサデータが燃料／充電、メンテナンスサービスなどの要望を示すなどのサービスイベントが発生すると、車両サービスイベントを呼び出すために使用され得る規則、閾値、センサ情報収集などを呼び出すべく、スマートコントラクトが使用されてもよい。ブロックチェーントランザクションデータ６７０は、アクセスイベント、車両のサービス状況に対するその後の更新、イベント更新などのトランザクションごとに保存される。トランザクションは、関係者と、要件（例えば、１８歳、サービス資格のある候補者、有効な運転免許証など）と、報酬レベルと、イベント中の移動距離と、イベントへのアクセスと車両サービスの主催を許可された登録済み受信者と、権利／許可と、次のサービスイベントの詳細をログに記録し、車両の条件状況を識別するために車両イベント操作中に取得されたセンサデータと、サービスイベントが完了したか及び車両の条件状況が完了したかを判定するために使用される閾値と、を含んでもよい。

図６Ｄは、例示的な実施形態係る、分散型台帳に追加することができるブロックチェーンブロック６８０と、ブロック構造６８２Ａ～６８２ｎの内容と、を示す。図６Ｄを参照すると、（図示しない）クライアントが、エントリをブロックチェーンノードに送信して、ブロックチェーン上で活動を実施してもよい。例として、クライアントは、ブロックチェーンのエントリを提案する装置、個人又はエンティティなどのリクエスタに代わって作動するアプリケーションであってもよい。複数のブロックチェーンピア（例えば、ブロックチェーンノード）は、ブロックチェーンネットワークの状態と分散型台帳のコピーを維持してもよい。さまざまなタイプのブロックチェーンノード／ピアが、クライアントによって提案されたエントリをシミュレートして承認する承認ピアと、承認を検証し、エントリを検証し、エントリを分散型台帳に委任する委任ピアとを含むブロックチェーンネットワークに存在してもよい。この例では、ブロックチェーンノードは、エンドーサノード、コミッタノード又はその両方の役割を演じてもよい。

本システムは、不変の順序付けされた記録をブロックに保存するブロックチェーンと、ブロックチェーンの現在の状態を維持する状態データベース（現在の世界状況）とを含む。チャネルごとに１つの分散型台帳が存在してもよく、各ピアは、メンバーであるチャネルごとに分散型台帳の独自のコピーを保持する。本ブロックチェーンは、各ブロックに一連のＮエントリが含まれるハッシュリンクされたブロックとして構造化されたエントリログである。ブロックには、図６Ｄに示すようなさまざまな構成要素が含まれてもよい。ブロックのリンクは、現在のブロックのブロックヘッダ内に前のブロックのヘッダのハッシュを追加することによって生成されてもよい。このようにして、ブロックチェーン上の全エントリが順序付けられ、暗号学的に互いに連結され、ハッシュリンクを壊すことなくブロックチェーンデータの改ざんを防止する。さらに、リンクがあるため、ブロックチェーンの最新のブロックは、それ以前の全エントリを表す。本発明のブロックチェーンは、追加専用のブロックチェーン作業負荷をサポートするピアファイルシステム（ローカルストレージ又は接続ストレージ）に保存されてもよい。

ブロックチェーンと分散型台帳の現在の状態は、状態データベースに保存されてもよい。ここで、現在の状態データは、ブロックチェーンのチェーンエントリログに含まれている全キーの最新の値を表す。スマートコントラクト実行可能コードの呼び出しが、状態データベース内の現在の状態に対してエントリを実行する。このようなスマートコントラクト実行可能コードの相互作用を非常に効率的なものにするために、全キーの最新の値が状態データベースに保存される。状態データベースは、ブロックチェーンのエントリログへの索引付きビューを含んでいる場合があるため、いつでもチェーンから再生成することができる。状態データベースは、エントリが受け入れられる前に、ピアの起動時に自動的に回復されてもよい（あるいは必要に応じて生成されてもよい）。

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

オーダサービスは、承認されたエントリを受け入れ、ブロックにオーダし、委任ピアにブロックを配信する。例えば、オーダサービスは、エントリの閾値に達するか、タイマーがタイムアウトするか、別の状況になったときに、新たなブロックを開始してもよい。この例では、ブロックチェーンノードは、ブロックチェーンに保存するためのデータブロック６８２Ａを受信した委任ピアである。オーダサービスは、オーダ者のクラスターから構成されてもよい。オーダサービスは、エントリ、スマートコントラクトを処理することも、共有台帳を維持することもしない。むしろ、オーダサービスは、承認されたエントリを受け入れ、そのようなエントリを分散型台帳に委任するオーダを指定する。ブロックチェーンネットワークのアーキテクチャは、「オーダ」の特定の実装（例えば、Ｓｏｌｏ、Ｋａｆｋａ、ＢＦＴなど）がプラグ着脱可能なコンポーネントになるように設計されてもよい。

エントリは、一貫した順序で分散型台帳に書き込まれる。エントリのオーダは、状態データベースへの更新がネットワークに委任されたときに有効になるように確立される。暗号パズルの解決又は検索を通じてオーダが発生する暗号通貨ブロックチェーンシステム（例えば、ビットコインなど）とは異なり、この例では、分散型台帳の関係者がそのネットワークに最適なオーダ機構を選択してもよい。

図６Ｄを参照すると、ブロックチェーン及び／又は分散型台帳に保存されるブロック６８２Ａ（データブロックとも呼ばれる）は、ブロックヘッダ６８４Ａ～６８４ｎ、トランザクション固有データ６８６Ａ～６８６ｎ及びブロックメタデータ６８８Ａ～６８８ｎなどの複数のデータセグメントを含んでもよい。ブロック６８２Ａ及びその内容など、さまざまな図示のブロック及びその内容は、単に例示を目的としており、例示的な実施形態の範囲を限定することを意図していないことを理解されたい。場合によっては、ブロックヘッダ６８４Ａとブロックメタデータ６８８Ａの両方が、エントリデータを保存するトランザクション固有データ６８６Ａよりも小さい場合がある。しかし、これは要件ではない。ブロック６８２Ａは、ブロックデータ６９０Ａ～６９０ｎ内のＮ個（例えば、１００個、５００個、１０００個、２０００個、３０００個など）のエントリのトランザクション情報を保存してもよい。ブロック６８２Ａはこのほか、ブロックヘッダ６８４Ａ内の（例えば、ブロックチェーン上の）前のブロックへのリンクを含んでもよい。特に、ブロックヘッダ６８４Ａは、前のブロックのヘッダのハッシュを含んでもよい。ブロックヘッダ６８４Ａはこのほか、一意のブロック番号、現在のブロック６８２Ａのブロックデータ６９０Ａのハッシュなどを含んでもよい。ブロック６８２Ａのブロック番号は、一意であってもよく、ゼロから始まる漸増／順次の順序で割り当てられてもよい。ブロックチェーンの第１のブロックは、ブロックチェーン、そのメンバー、そのブロックに保存されているデータなどに関する情報を含む起源ブロックと呼ばれる場合がある。

ブロックデータ６９０Ａは、ブロック内に記録される各エントリのエントリ情報を保存してもよい。例えば、エントリデータには、エントリのタイプ、バージョン、タイムスタンプ、分散型台帳のチャネルＩＤ、エントリＩＤ、エポック、ペイロードの可視性、スマートコントラクト実行可能コードパス（ｄｅｐｌｏｙｔｘ）、スマートコントラクト実行可能コード名、スマートコントラクト実行可能コードバージョン、入力（スマートコントラクト実行可能コードと機能）、公開鍵及び証明書などのクライアント（作成者）ＩＤ、クライアントの署名、エンドーサのＩＤ、エンドーサ署名、提案ハッシュ、スマートコントラクト実行可能コードイベント、応答状況、名前空間、読み取りセット（エントリによって読み取られるキーとバージョンのリストなど）、書き込みセット（キーと値のリストなど）、開始キー、終了キー、キーのリスト、メルケルツリークエリの概要などが含まれてもよい。エントリデータは、Ｎ個のエントリのそれぞれについて保存されてもよい。

いくつかの実施形態では、ブロックデータ６９０Ａはこのほか、ブロックチェーン内のブロックのハッシュリンクされたチェーンに追加情報を追加するトランザクション固有データ６８６Ａを保存してもよい。このため、データ６８６Ａは、分散型台帳上のブロックの不変ログに保存することができる。そのようなデータ６８６Ａを保存する利点のいくつかは、本明細書で開示し描写するさまざまな実施形態に反映される。ブロックメタデータ６８８Ａは、メタデータの複数のフィールドを（例えば、バイト配列などとして）保存してもよい。メタデータフィールドには、ブロック作成時の署名、最後の構成ブロックへの参照、ブロック内の有効なエントリと無効なエントリを識別するエントリフィルタ、ブロックをオーダしたオーダサービスの最後のオフセットなどが含まれてもよい。署名、最後の構成ブロック及びオーダ者のメタデータは、オーダサービスによって追加されてもよい。一方、ブロックのコミッタ（ブロックチェーンノードなど）が、エンドースメントポリシー、読み取り／書き込みセットの検証などに基づいて有効／無効情報を追加してもよい。エントリフィルタは、ブロックデータ６１０Ａ内のエントリの数に等しいサイズのバイト配列と、エントリが有効／無効であったか否かを識別する検証コードとを含んでもよい。

ブロックチェーン内の他のブロック６８２Ｂから６８２ｎはこのほか、ヘッダ、ファイル及び値を有する。しかし、第１のブロック６８２Ａとは異なり、他のブロックのヘッダ６８４Ａ～６８４ｎのそれぞれは、直前のブロックのハッシュ値を含む。直前のブロックのハッシュ値は、前のブロックのヘッダのハッシュだけであっても、前のブロック全体のハッシュ値であってもよい。残りのブロックのそれぞれに前のブロックのハッシュ値を含めることにより、監査可能で不変の管理の連鎖を確立するために、矢印６９２で示すように、Ｎ番目のブロックから起源ブロック（及び関連付けられた元のファイル）まで、ブロック単位でトレースを実施することができる。

本明細書に記載の実施形態は、ハードウェア、プロセッサによって実行されるコンピュータプログラム、ファームウェア又はその組み合わせで実装されてもよい。コンピュータプログラムは、記憶媒体などのコンピュータ可読媒体上で具体化されてもよい。例えば、コンピュータプログラムは、ランダムアクセスメモリ（「ＲＡＭ」）、フラッシュメモリ、読み取り専用メモリ（「ＲＯＭ」）、消去可能なプログラム可能読み取り専用メモリ（「ＥＰＲＯＭ」）、電気的に消去可能なプログラム可能読み取り専用メモリ（「ＥＥＰＲＯＭ」）、レジスタ、ハードディスク、取り外し可能ディスク、コンパクトディスク読み取り専用メモリ（「ＣＤ－ＲＯＭ」）、あるいは当技術分野で知られている任意の他の形態の記憶媒体に存在してもよい。

例示的な記憶媒体を、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込み得るように、プロセッサに結合してもよい。これとは別に、記憶媒体はプロセッサに一体化されてもよい。プロセッサ及び記憶媒体は、特定用途向け集積回路（「ＡＳＩＣ」）に存在してもよい。これとは別に、プロセッサ及び記憶媒体は、別個の構成要素として存在してもよい。例えば、図７は、例示的なコンピュータシステムアーキテクチャ７００を示す。このアーキテクチャは、説明したコンポーネントなどのいずれかを表しても、いずれかに統合されてもよい。

図７は、本明細書に記載したアプリケーションの実施形態の使用又は機能の範囲に関する任意の制限を示唆することを意図するものではない。いずれにしても、計算ノード７００は、本明細書に記載の機能のいずれかを実装したり、及び／又は実施したりしてもよい。

計算ノード７００には、多数の他の汎用又は専用の計算システム環境又は構成で動作可能であるコンピュータシステム／サーバ７０２がある。コンピュータシステム／サーバ７０２での使用に適し得る周知の計算システム、環境及び／又は構成の例には、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、手持ち式又はラップトップ型の装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家電、ネットワークＰＣ、ミニコンピュータシステム、メインフレームコンピュータシステム、システム又は装置のいずれかを含む分散型クラウド計算環境などが挙げられるが、ここに挙げたものに限定されない。

コンピュータシステム／サーバ７０２を、コンピュータシステムによって実行されるプログラムモジュールなどのコンピュータシステム実行可能命令の一般的な文脈で説明してもよい。一般に、プログラムモジュールには、特定のタスクを実行するか、特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などが含まれてもよい。コンピュータシステム／サーバ７０２は、通信ネットワークを介して連結されたリモート処理装置によってタスクが実行される分散クラウド計算環境にて実施されてもよい。分散型クラウド計算環境では、プログラムモジュールは、メモリ記憶装置を含むローカル及びリモートの両方のコンピュータシステム記憶媒体に配置されてもよい。

図７に示すように、クラウド計算ノード７００内のコンピュータシステム／サーバ７０２を、汎用計算装置の形態で示す。コンピュータシステム／サーバ７０２の構成要素は、１つ又は複数のプロセッサ又は処理ユニット７０４と、システムメモリ７０６と、システムメモリ７０６を含むさまざまなシステム構成要素をプロセッサ７０４に結合するバスとを含んでもよいが、ここに挙げたものに限定されない。

バスは、メモリバス又はメモリコントローラと、周辺バスと、アクセラレイティッドグラフィックスポートと、さまざまなバスアーキテクチャのいずれかを使用するプロセッサ又はローカルバスとを含むいくつかのタイプのバス構造のいずれかの１つ又は複数を表す。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ（ＰＣＩ）バスが含まれる。

コンピュータシステム／サーバ７０２は、典型的には、さまざまなコンピュータシステム可読媒体を含む。そのような媒体は、コンピュータシステム／サーバ７０２によってアクセス可能な任意の利用可能な媒体であり、揮発性媒体及び不揮発性媒体の両方、取り外し可能媒体及び取り外し不可能媒体の両方を含む。システムメモリ７０６は、一実施形態では、他の図の流れ図を実施する。システムメモリ７０６は、ランダムアクセスメモリ（ＲＡＭ）７０８及び／又はキャッシュメモリ７１０などの揮発性メモリの形態のコンピュータシステム可読媒体を含むことがある。コンピュータシステム／サーバ７０２は、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータシステム記憶媒体をさらに含んでもよい。ほんの一例として、メモリ７０６は、（図示せず、典型的には「ハードドライブ」と呼ばれる）取り外し不可能で不揮発性の磁気媒体から読み書きするために設けることができる。図示していないが、取り外し可能で不揮発性の磁気ディスク（例えば、「フロッピーディスク」）から読み書きするための磁気ディスクドライブと、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ又はその他の光学媒体などの取り外し可能で不揮発性の光学ディスクから読み書きするための光ディスクドライブと、を設けることができる。そのような場合、それぞれを１つ又は複数のデータ媒体インターフェースによってバスに接続することができる。本明細書でさらに図示し説明するように、メモリ７０６は、アプリケーションのさまざまな実施形態の機能を実施するように構成されたプログラムモジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含んでもよい。

プログラムモジュールのセット（少なくとも１つ）を有するプログラム／ユーティリティは、限定ではなく例として、メモリ７０６のほか、オペレーティングシステム、１つ又は複数のアプリケーションプログラム、他のプログラムモジュール及びプログラムデータに保存されてもよい。オペレーティングシステム、１つ又は複数のアプリケーションプログラム、他のプログラムモジュール及びプログラムデータ又はその何らかの組み合わせのそれぞれが、ネットワーク構築環境の実装を含んでもよい。プログラムモジュールは、本明細書で説明するアプリケーションのさまざまな実施形態の機能及び／又は方法論を概ね実施する。

当業者によって理解されるであろうように、本出願の態様を、システム、方法又はコンピュータプログラム製品として具体化してもよい。このため、本出願の態様が、全体的にハードウェアの実施形態、（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）全体的にソフトウェアの実施形態、あるいは本明細書ではいずれも、「回路」、「モジュール」又は「システム」と概ね呼ばれ得るソフトウェア及びハードウェアの態様を組み合わせた実施形態の形態をとってもよい。さらに、本出願の態様が、コンピュータ可読プログラムコードが具体化された１つ又は複数のコンピュータ可読媒体で具体化されたコンピュータプログラム製品の形態をとってもよい。

コンピュータシステム／サーバ７０２はこのほか、キーボード、ポインティング装置、ディスプレイ、音声認識モジュールなどを含み得る入出力装置７１２（入出力アダプタなど）を介して、ユーザがコンピュータシステム／サーバ７０２と対話することができるようにする１つ又は複数の装置を介して、及び／又はコンピュータシステム／サーバ７０２が１つ又は複数の他の計算装置と通信することができるようにする任意の装置（例えば、ネットワークカード、モデムなど）を介して、１つ又は複数の外部装置と通信してもよい。そのような通信は、装置７１２の入出力インターフェースを介して実施され得る。さらにまた、コンピュータシステム／サーバ７０２は、ネットワークアダプタを介して、ローカルエリアネットワーク（ＬＡＮ）、一般的なワイドエリアネットワーク（ＷＡＮ）及び／又は公衆ネットワーク（例えば、インターネット）などの１つ又は複数のネットワークと通信することができる。図示のように、装置７１２は、バスを介してコンピュータシステム／サーバ７０２の他のコンポーネントと通信する。図示していないが、他のハードウェア及び／又はソフトウェアコンポーネントをコンピュータシステム／サーバ７０２と共に使用することがあり得ることを理解されたい。例としては、マイクロコード、装置ドライバ、冗長処理ユニット、外部ディスクドライブアレイ、ＲＡＩＤシステム、テープドライブ、データ記録記憶システムなどが挙げられるが、ここに挙げたものに限定されない。

システム、方法及び非一時的なコンピュータ可読媒体のうちの少なくとも１つの例示的な実施形態を、添付の図面に示し、前述の詳細な説明で説明してきたが、アプリケーションは、開示した実施形態に限定されないが、以下の特許請求の範囲に記載し定義するように、多数の再配置、修正及び置換が可能であることが理解されよう。例えば、さまざまな図のシステムの能力は、本明細書に記載のモジュール又はコンポーネントのうちの１つ又は複数によって実施するか、分散型アーキテクチャで実施することができ、送信機、受信機又は両方の対を含んでもよい。例えば、個々のモジュールによって実施される機能の全部又は一部を、このようなモジュールの１つ又は複数によって実施してもよい。さらに、本明細書で説明する機能は、モジュール又はコンポーネントの内部又は外部のさまざまなイベントに関連して、さまざまな時点で実施されてもよい。このほか、さまざまなモジュール間で送信される情報は、データネットワーク、インターネット、音声ネットワーク、インターネットプロトコルネットワーク、無線装置、有線装置及び／又は複数のプロトコルのうちの少なくとも１つを介してモジュール間で送信されることができる。このほか、モジュールのいずれかによって送受信されるメッセージは、直接送受信されたり、及び／又は他のモジュールの１つ又は複数を介して送受信されたりしてもよい。

当業者には、「システム」が、パーソナルコンピュータ、サーバ、コンソール、携帯情報端末（ＰＤＡ）、携帯電話、タブレット計算装置、スマートフォン又は任意の他の適切な計算装置又は装置の組み合わせとして具体化されることがあり得ることが理解されよう。記載した機能を「システム」によって実施されるものとして提示することは、本出願の範囲を限定することを意図するものでは決してなく、多くの実施形態の一例を提供することを意図するものである。実際、本明細書で開示する方法、システム及び装置を、計算技術と一致する局所化された形態及び分散された形態で実装してもよい。

この明細書で説明するシステムの特徴の一部を、その実装の独立性をさらに具体的に強調するために、モジュールとして提示していることに留意されたい。例えば、モジュールを、カスタム超大規模集積（ＶＬＳＩ）回路又はゲートアレイ、論理チップ、トランジスタ又は他の個別部品などの既製の半導体を含むハードウェア回路として実装してもよい。このほか、モジュールを、フィールドプログラム可能ゲートアレイ、プログラム可能アレイ論理、プログラム可能論理装置、グラフィック処理ユニットなどのプログラム可能ハードウェア装置に実装してもよい。

このほか、モジュールを、さまざまなタイプのプロセッサによる実行のために、ソフトウェアに少なくとも部分的に実装してもよい。実行可能コードの識別されたユニットには、例えば、オブジェクト、手順又は機能として編成され得るコンピュータ命令の１つ又は複数の物理的ブロック又は論理的ブロックが含まれてもよい。それにもかかわらず、識別されたモジュールの実行ファイルは、物理的に一緒に配置する必要はないが、論理的に結合されるとモジュールを構成し、モジュールの規定の目的を達成するさまざまな場所に保存された異種の命令を含む場合がある。さらに、モジュールを、例えば、データを保存するために使用されるハードディスクドライブ、フラッシュ装置、ランダムアクセスメモリ（ＲＡＭ）、テープ又は任意の他の媒体であり得るコンピュータ可読媒体に保存してもよい。

実際、実行可能コードのモジュールが、単一の命令又は多数の命令であり得ることがあり、いくつかの異なるコードセグメント、異なるプログラム間及びいくつかのメモリ装置に分散することさえある。同じように、運用データを、本明細書ではモジュール内で識別し図示してもよく、任意の適切な形態で具体化し、任意の適切なタイプのデータ構造内に編成してもよい。運用データは、単一のデータセットとして収集されても、異なる記憶装置を含む異なる場所に分散されてもよく、単にシステム又はネットワーク上の電子信号として、少なくとも部分的に存在してもよい。

本出願の構成要素は、本明細書で概ね説明し図に示すように、多種多様な異なる構成で配置され設計され得ることが容易に理解されよう。このため、実施形態の詳細な説明は、特許請求される本出願の範囲を限定することを意図するものではなく、本出願の選択された実施形態を単に代表するものである。

当業者であれば、本明細書に記載の機能を異なる順序のステップで実施したり、及び／又は開示したものとは異なる構成のハードウェア要素によって実施したりしてもよいことを容易に理解するであろう。このため、本出願をこのような好ましい実施形態に基づいて説明してきたが、特定の修正、変更及び代替構造が明白なものであることは当業者には明らかであろう。

本出願の好ましい実施形態を説明してきたが、説明した実施形態は例示にすぎず、本出願の範囲は、添付の特許請求の範囲のみによって、それに対する均等物及び変更（例えば、プロトコル、ハードウェアデバイス、ソフトウェアプラットフォームなど）の全範囲を考慮して、定義されることを理解されたい。

本出願の好ましい実施形態を説明してきたが、説明した実施形態は例示にすぎず、本出願の範囲は、添付の特許請求の範囲のみによって、それに対する均等物及び変更（例えば、プロトコル、ハードウェアデバイス、ソフトウェアプラットフォームなど）の全範囲を考慮して、定義されることを理解されたい。
本開示は、以下の態様を含む。
〔態様１〕
満充電のために輸送体に必要とされる第１のエネルギー量を充電ステーションによって判定することと、
前記輸送体が後の時点で前記充電ステーションに返還する第２のエネルギー量を前記充電ステーションによって判定することと、
前記第１のエネルギー量と前記第２のエネルギー量との間の差に等しい充電レベルまで、前記充電ステーションによって、前記輸送体を充電することと、を含む方法。
〔態様２〕
前記第２のエネルギー量と、前記第１のエネルギー量に対する前記第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電することをさらに含む、態様１に記載の方法。
〔態様３〕
前記輸送体が前記第２のエネルギー量を返還するために戻るときの前記輸送体の前記充電ステーションへの予測される往復に基づいてエネルギーの節約量を計算することをさらに含む、態様１に記載の方法。
〔態様４〕
前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供することを更に含み、前記エネルギーの節約量は、前記第２のエネルギー量を放棄する動機として機能する、態様３に記載の方法。
〔態様５〕
前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第２のエネルギー量を判定することをさらに含む、態様１に記載の方法。
〔態様６〕
前記輸送体からの前記第２のエネルギー量の移送に関する確認を受信することを更に含み、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、態様１に記載の方法。
〔態様７〕
前記ブロックチェーン合意に基づいてブロックチェーン上にエネルギー移送関連のトランザクションを記録するためにスマートコントラクトを実行することを更に含む、態様６に記載の方法。
〔態様８〕
充電ステーションのプロセッサと、
機械可読命令が保存されたメモリであって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに、
満充電のために輸送体に必要とされる第１のエネルギー量を判定させ、
後の時点で前記輸送体が前記充電ステーションに返還する第２のエネルギー量を判定させ、
前記第１のエネルギー量と前記第２のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電させる、メモリと、を具備する、システム。
〔態様９〕
前記命令は、前記プロセッサに、更に、前記第２のエネルギー量と、前記第１のエネルギー量に対する前記第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる、態様８に記載のシステム。
〔態様１０〕
前記命令は、前記プロセッサに、更に、前記輸送体が前記第２のエネルギー量を返還するために戻るときに、前記輸送体の前記充電ステーションへの予測される往復に基づいて、エネルギーの節約量を計算させる、態様８に記載のシステム。
〔態様１１〕
前記命令は、前記プロセッサに、更に、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供させ、前記エネルギーの節約量は、前記第２のエネルギー量を放棄する動機として機能する、態様１０に記載のシステム。
〔態様１２〕
前記命令は、前記プロセッサに、更に、前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第２のエネルギー量を判定させる、態様８に記載のシステム。
〔態様１３〕
前記命令は、前記プロセッサに、更に、前記輸送体からの前記第２のエネルギー量の移送に関する確認を受信させ、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、態様８に記載のシステム。
〔態様１４〕
前記命令は、前記プロセッサに、更に、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる、態様１３に記載のシステム。
〔態様１５〕
命令を含む非一時的なコンピュータ可読媒体であって、前記命令は、プロセッサによって読み取られると、前記プロセッサに、
満充電のために輸送体に必要とされる第１のエネルギー量を判定することと、
前記輸送体が後の時点で前記充電ステーションに返還する第２のエネルギー量を判定することと、
前記第１のエネルギー量と前記第２のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電することと、を実施させる、非一時的なコンピュータ可読媒体。
〔態様１６〕
プロセッサによって読み取られると、前記プロセッサに、前記第２のエネルギー量と、前記第１のエネルギー量に対する前記第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる命令を更に含む、態様１５に記載の非一時的なコンピュータ可読媒体。
〔態様１７〕
プロセッサによって読み取られると、前記プロセッサに、前記輸送体が前記第２のエネルギー量を返還するために戻るときの前記充電ステーションまでの前記輸送体の予測される往復に基づいて、エネルギーの節約量を計算させる命令を更に含む、態様１５に記載の非一時的なコンピュータ可読媒体。
〔態様１８〕
プロセッサによって読み取られると、前記プロセッサに、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供させる命令であって、前記エネルギーの節約量が前記第２のエネルギー量を放棄する動機として機能する、命令を更に含む、態様１７に記載の非一時的なコンピュータ可読媒体。
〔態様１９〕
プロセッサによって読み取られると、前記プロセッサに、前記輸送体からの前記第２のエネルギー量の移送に関する確認を受信させる命令であって、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、命令を更に含む、態様１５に記載の非一時的なコンピュータ可読媒体。
〔態様２０〕
プロセッサによって読み取られると、前記プロセッサに、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる命令を更に含む、態様１９に記載の非一時的なコンピュータ可読媒体。

Claims (20)

1. 満充電のために輸送体に必要とされる第１のエネルギー量を充電ステーションによって判定することと、
   前記輸送体が後の時点で前記充電ステーションに返還する第２のエネルギー量を前記充電ステーションによって判定することと、
   前記第１のエネルギー量と前記第２のエネルギー量との間の差に等しい充電レベルまで、前記充電ステーションによって、前記輸送体を充電することと、を含む方法。
2. 前記第２のエネルギー量と、前記第１のエネルギー量に対する前記第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電することをさらに含む、請求項１に記載の方法。
3. 前記輸送体が前記第２のエネルギー量を返還するために戻るときの前記輸送体の前記充電ステーションへの予測される往復に基づいてエネルギーの節約量を計算することをさらに含む、請求項１に記載の方法。
4. 前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供することを更に含み、前記エネルギーの節約量は、前記第２のエネルギー量を放棄する動機として機能する、請求項３に記載の方法。
5. 前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第２のエネルギー量を判定することをさらに含む、請求項１に記載の方法。
6. 前記輸送体からの前記第２のエネルギー量の移送に関する確認を受信することを更に含み、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、請求項１に記載の方法。
7. 前記ブロックチェーン合意に基づいてブロックチェーン上にエネルギー移送関連のトランザクションを記録するためにスマートコントラクトを実行することを更に含む、請求項６に記載の方法。
8. 充電ステーションのプロセッサと、
   機械可読命令が保存されたメモリであって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに、
   満充電のために輸送体に必要とされる第１のエネルギー量を判定させ、
   後の時点で前記輸送体が前記充電ステーションに返還する第２のエネルギー量を判定させ、
   前記第１のエネルギー量と前記第２のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電させる、メモリと、を具備する、システム。
9. 前記命令は、前記プロセッサに、更に、前記第２のエネルギー量と、前記第１のエネルギー量に対する前記第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる、請求項８に記載のシステム。
10. 前記命令は、前記プロセッサに、更に、前記輸送体が前記第２のエネルギー量を返還するために戻るときに、前記輸送体の前記充電ステーションへの予測される往復に基づいて、エネルギーの節約量を計算させる、請求項８に記載のシステム。
11. 前記命令は、前記プロセッサに、更に、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供させ、前記エネルギーの節約量は、前記第２のエネルギー量を放棄する動機として機能する、請求項１０に記載のシステム。
12. 前記命令は、前記プロセッサに、更に、前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第２のエネルギー量を判定させる、請求項８に記載のシステム。
13. 前記命令は、前記プロセッサに、更に、前記輸送体からの前記第２のエネルギー量の移送に関する確認を受信させ、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、請求項８に記載のシステム。
14. 前記命令は、前記プロセッサに、更に、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる、請求項１３に記載のシステム。
15. 命令を含む非一時的なコンピュータ可読媒体であって、前記命令は、プロセッサによって読み取られると、前記プロセッサに、
    満充電のために輸送体に必要とされる第１のエネルギー量を判定することと、
    前記輸送体が後の時点で前記充電ステーションに返還する第２のエネルギー量を判定することと、
    前記第１のエネルギー量と前記第２のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電することと、を実施させる、非一時的なコンピュータ可読媒体。
16. プロセッサによって読み取られると、前記プロセッサに、前記第２のエネルギー量と、前記第１のエネルギー量に対する前記第２のエネルギー量の比例配分に基づいて計算された第３のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる命令を更に含む、請求項１５に記載の非一時的なコンピュータ可読媒体。
17. プロセッサによって読み取られると、前記プロセッサに、前記輸送体が前記第２のエネルギー量を返還するために戻るときの前記充電ステーションまでの前記輸送体の予測される往復に基づいて、エネルギーの節約量を計算させる命令を更に含む、請求項１５に記載の非一時的なコンピュータ可読媒体。
18. プロセッサによって読み取られると、前記プロセッサに、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供させる命令であって、前記エネルギーの節約量が前記第２のエネルギー量を放棄する動機として機能する、命令を更に含む、請求項１７に記載の非一時的なコンピュータ可読媒体。
19. プロセッサによって読み取られると、前記プロセッサに、前記輸送体からの前記第２のエネルギー量の移送に関する確認を受信させる命令であって、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、命令を更に含む、請求項１５に記載の非一時的なコンピュータ可読媒体。
20. プロセッサによって読み取られると、前記プロセッサに、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる命令を更に含む、請求項１９に記載の非一時的なコンピュータ可読媒体。