(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-27
(45)【発行日】2024-07-05
(54)【発明の名称】要望に基づくエネルギー共有
(51)【国際特許分類】
G06Q 50/06 20240101AFI20240628BHJP
B60L 50/60 20190101ALI20240628BHJP
B60L 53/14 20190101ALI20240628BHJP
B60L 53/66 20190101ALI20240628BHJP
B60L 58/12 20190101ALI20240628BHJP
H02J 7/04 20060101ALI20240628BHJP
H02J 7/00 20060101ALI20240628BHJP
【FI】
G06Q50/06
B60L50/60
B60L53/14
B60L53/66
B60L58/12
H02J7/04 A
H02J7/00 P
H02J7/00 302A
(21)【出願番号】P 2022574304
(86)(22)【出願日】2021-06-02
(86)【国際出願番号】 US2021035324
(87)【国際公開番号】W WO2021262403
(87)【国際公開日】2021-12-30
【審査請求日】2023-01-31
(32)【優先日】2020-06-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】519092129
【氏名又は名称】トヨタ モーター ノース アメリカ,インコーポレイティド
(74)【代理人】
【識別番号】100099759
【氏名又は名称】青木 篤
(74)【代理人】
【識別番号】100123582
【氏名又は名称】三橋 真二
(74)【代理人】
【識別番号】100092624
【氏名又は名称】鶴田 準一
(74)【代理人】
【識別番号】100147555
【氏名又は名称】伊藤 公一
(74)【代理人】
【識別番号】100123593
【氏名又は名称】関根 宣夫
(74)【代理人】
【識別番号】100133835
【氏名又は名称】河野 努
(72)【発明者】
【氏名】ノーマン ルー
【審査官】永野 一郎
(56)【参考文献】
【文献】特開2013-037598(JP,A)
【文献】中国特許出願公開第106532874(CN,A)
【文献】中国実用新案第201868954(CN,U)
【文献】米国特許出願公開第2016/0280091(US,A1)
【文献】特開2013-126350(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
B60L 50/60
B60L 53/14
B60L 53/66
B60L 58/12
H02J 7/04
H02J 7/00
(57)【特許請求の範囲】
【請求項1】
満充電のために輸送体に必要とされる第1のエネルギー量を充電ステーションによって判定することと、
以前の使用記録に基づいて、前記輸送体が後の時点で前記充電ステーションに返還する第2のエネルギー量を前記充電ステーションによって判定することと、
前記第1のエネルギー量と前記第2のエネルギー量との間の差に等しい充電レベルまで、前記充電ステーションによって、前記輸送体を充電することと、を含む方法。
【請求項2】
前記第2のエネルギー量と、前記第1のエネルギー量に対する前記第2のエネルギー量の比例配分に
前記第2のエネルギー量を乗算して計算された第3のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電することをさらに含む、請求項1に記載の方法。
【請求項3】
前記輸送体が前記第2のエネルギー量を返還するために戻るときの前記輸送体の前記充電ステーションへの予測される往復に基づいてエネルギーの節約量を計算することをさらに含む、請求項1又は2に記載の方法。
【請求項4】
前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供することを更に含
む、請求項3に記載の方法。
【請求項5】
前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第2のエネルギー量を判定することをさらに含
み、
前記機械学習データは、少なくとも気温、時間帯及び時期に基づいてエネルギーの使用量と需要を予測するAIモデルによって生成される、請求項1又は2に記載の方法。
【請求項6】
前記輸送体からの前記第2のエネルギー量の移送に関する確認を受信することを更に含み、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、請求項1又は2に記載の方法。
【請求項7】
前記ブロックチェーン合意に基づいてブロックチェーン上にエネルギー移送関連のトランザクションを記録するためにスマートコントラクトを実行することを更に含む、請求項6に記載の方法。
【請求項8】
充電ステーションのプロセッサと、
機械可読命令が保存されたメモリであって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに、
満充電のために輸送体に必要とされる第1のエネルギー量を判定させ、
以前の使用記録に基づいて、後の時点で前記輸送体が前記充電ステーションに返還する第2のエネルギー量を判定させ、
前記第1のエネルギー量と前記第2のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電させる、メモリと、を具備する、システム。
【請求項9】
前記命令は、前記プロセッサに、更に、前記第2のエネルギー量と、前記第1のエネルギー量に対する前記第2のエネルギー量の比例配分に
前記第2のエネルギー量を乗算して計算された第3のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる、請求項8に記載のシステム。
【請求項10】
前記命令は、前記プロセッサに、更に、前記輸送体が前記第2のエネルギー量を返還するために戻るときに、前記輸送体の前記充電ステーションへの予測される往復に基づいて、エネルギーの節約量を計算させる、請求項8又は9に記載のシステム。
【請求項11】
前記命令は、前記プロセッサに、更に、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供さ
せる、請求項10に記載のシステム。
【請求項12】
前記命令は、前記プロセッサに、更に、前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第2のエネルギー量を判定さ
せ、
前記機械学習データは、少なくとも気温、時間帯及び時期に基づいてエネルギーの使用量と需要を予測するAIモデルによって生成される、請求項8又は9に記載のシステム。
【請求項13】
前記命令は、前記プロセッサに、更に、前記輸送体からの前記第2のエネルギー量の移送に関する確認を受信させ、前記確認は、前記輸送体及
び充電ステーションによって表されるピア間のブロックチェーン合意を含む、請求項8又は9に記載のシステム。
【請求項14】
前記命令は、前記プロセッサに、更に、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる、請求項13に記載のシステム。
【請求項15】
命令を含む非一時的なコンピュータ可読媒体であって、前記命令は、プロセッサによって読み取られると、前記プロセッサに、
満充電のために輸送体に必要とされる第1のエネルギー量を判定することと、
以前の使用記録に基づいて、前記輸送体が後の時点で前記充電ステーションに返還する第2のエネルギー量を判定することと、
前記第1のエネルギー量と前記第2のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電することと、を実施させる、非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、「優先度に基づくエネルギー移送(PRIORITY-BASED ENERGY TRANSFER)」と題する同時係属中の米国非仮特許出願に関連するものである。両出願は同日に出願され、それぞれが参照によりその全体が本明細書に組み込まれる。
【背景技術】
【0002】
自動車、オートバイ、トラック、飛行機、列車などの車両又は輸送体が、さまざまな方法で乗員及び/又は商品に対する輸送の要望に概ね応えている。輸送体に関連する機能を、輸送体の内部及び/又は外部にあるスマートフォン及び/又はコンピュータなどのさまざまな計算装置によって識別し、利用する場合がある。
【発明の概要】
【0003】
例示的な一実施形態では、満充電のために輸送体に必要とされる第1のエネルギー量を充電ステーションによって判定することと、輸送体が後の時点で充電ステーションに返還するであろう第2のエネルギー量を充電ステーションによって判定することと、第1のエネルギー量と第2のエネルギー量との間の差に等しい充電レベルまで、充電ステーションによって、輸送体を充電することと、のうちの1つ又は複数を含む方法が提供される。
【0004】
別の例示的な実施形態では、プロセッサ及びメモリを備えるシステムが提供される。ここで、プロセッサは、満充電のために輸送体に必要とされる第1のエネルギー量を判定することと、輸送体が後の時点で充電ステーションに返還するであろう第2のエネルギー量を判定することと、第1のエネルギー量と第2のエネルギー量との間の差に等しい充電レベルまで輸送体を充電することと、のうちの1つ又は複数を実施するように構成される。
【0005】
更なる例示的な実施形態では、命令を含む非一時的なコンピュータ可読媒体が提供される。命令は、プロセッサによって読み取られると、プロセッサに、満充電のために輸送体に必要とされる第1のエネルギー量を判定することと、輸送体が後の時点で充電ステーションに返還するであろう第2のエネルギー量を判定することと、第1のエネルギー量と第2のエネルギー量との間の差に等しい充電レベルまで輸送体を充電することと、のうちの1つ又は複数を実施させる。
【図面の簡単な説明】
【0006】
【
図1】
図1は、例示的な実施形態に係る輸送体ネットワーク図を示す。
【
図2A】
図2Aは、例示的な実施形態に係る、更なる輸送体ネットワーク図を示す。
【
図2B】
図2Bは、例示的な実施形態に係る、別の輸送体ネットワーク図を示す。
【
図2C】
図2Cは、例示的な実施形態に係る、ブロックチェーンを含むアーキテクチャ構成を示す。
【
図3B】
図3Bは、例示的な実施形態に係る別の流れ図を示す。
【
図4】
図4は、例示的な実施形態係る、機械学習輸送体ネットワーク図を示す。
【
図5A】
図5Aは、例示的な実施形態係る、車両に関連付けられたデータベーストランザクションを管理するための例示的な車両構成を示す。
【
図5B】
図5Bは、例示的な実施形態係る、さまざまな車両間で実行されるデータベーストランザクションを管理するための別の例示的な車両構成を示す。
【
図6A】
図6Aは、例示的な実施形態係るブロックチェーンアーキテクチャ構成を示す。
【
図6B】
図6Bは、例示的な実施形態係る別のブロックチェーン構成を示す。
【
図6C】
図6Cは、例示的な実施形態係る、ブロックチェーントランザクションデータを保存するためのブロックチェーン構成を示す。
【
図6D】
図6Dは、例示的な実施形態係る例示的なデータブロックを示す。
【
図7】
図7は、例示的な実施形態のうちの1つ又は複数を支援する例示的なシステムを示す。
【発明を実施するための形態】
【0007】
本明細書で概ね説明し図面に示す本発明の構成要素は、多種多様な異なる構成で配置され設計され得ることが容易に理解されよう。このため、添付の図に示す方法、装置、非一時的コンピュータ可読媒体及びシステムのうちの少なくとも1つの実施形態に関する以下の詳細な説明は、特許請求される本出願の範囲を限定することを意図するものではなく、単に選択された実施形態を代表するにすぎない。
【0008】
本明細書全体に記載した本発明の特徴、構造又は特性は、1つ又は複数の実施形態の任意の適切な方法で組み合わされてもよい。例えば、本明細書全体を通して、「例示的な実施形態」、「いくつかの実施形態」又は他の類似する言葉の使用は、実施形態に関連して説明した特定の特徴、構造又は特性が少なくとも1つの実施形態に含まれ得るという事実を指す。このため、本明細書全体にわたる「例示的な実施形態」、「いくつかの実施形態では」、「他の実施形態では」又は他の類似する言葉の出現がいずれも、必ずしも実施形態の同じグループを指すわけではなく、記載した特徴、構造又は特性は、1つ又は複数の実施形態の任意の適切な方法で組み合わされてもよい。図では、描かれている接続が一方向又は双方向の矢印であっても、要素間の任意の接続が一方向及び/又は双方向の通信を可能にすることができる。本解決策では、輸送体は、自動車、トラック、歩行者専用エリア用バッテリ式電気車両(BEV)、e-Palette、燃料電池バス、オートバイ、スクータ、自転車、ボート、RV車両、飛行機、及びある場所から別の場所へ人及び/又は物資を輸送するために使用され得る任意の物体、のうちの1つ又は複数を含み得る。
【0009】
さらに、「メッセージ」という用語を実施形態の説明で使用している場合があるが、パケット、フレーム、データグラムなどの他のタイプのネットワークデータも使用され得る。さらに、特定のタイプのメッセージ及び信号伝達を例示的な実施形態で描写する場合があるが、このようなメッセージ及び信号伝達は1つの特定のタイプのメッセージ及び信号伝達に限定されるものではない。
【0010】
例示的な実施形態では、輸送体(本明細書では車両又は自動車とも呼ばれる)、データ収集システム、データ監視システム、検証システム、認可システム及び車両データ配信システムのうちの少なくとも1つを提供する方法、システム、コンポーネント、非一時的コンピュータ可読媒体、装置及び/又はネットワークが提供される。無線データネットワーク通信及び/又は有線通信メッセージなどの通信メッセージの形態で受信された車両状態状況データは、車両/輸送体の状態の状況を識別し且つ輸送体の状況及び/又は変化に関するフィードバックを提供するために処理されてもよい。一例では、ユーザプロファイルは、現在の車両イベント、サービスステーションでのサービス停止を認可し、その後の車両レンタルサービスを認可し、車両間通信を可能にするために、特定の輸送体/車両に適用されてもよい。
【0011】
通信インフラ内では、分散型データベースは、相互に通信する複数のノードを含む分散ストレージシステムである。ブロックチェーンは、分散型データベースの一例であり、信頼できない関係者(untrusted party)間で記録を維持することができる追加専用(append-only)の不変データ構造(即ち、分散型台帳)を含む。信頼できない関係者は、本明細書ではピア、ノード又はピアノードと呼ばれる。各ピアはデータベース記録のコピーを保持し、分散したピア間で合意に達することなく単一のピアがデータベース記録を変更することはできない。例えば、ピアは合意プロトコルを実行して、ブロックチェーンストレージエントリを検証し、ストレージエントリをブロックにグループ化し、ブロックを介してハッシュチェーンを構築する。このプロセスは、一貫性を保つために、必要に応じてストレージエントリを並べ替えて台帳を作成する。パブリックブロックチェーン又は自由参加型(permissionless)ブロックチェーンでは、誰でも特定のIDなしで参加することができる。パブリックブロックチェーンは、暗号通貨を含み、プルーフオブワーク(PoW)などのさまざまなプロトコルに基づく合意を使用することができる。一方で、許可型(permissioned)ブロックチェーンデータベースでは、資金、商品、情報などを交換する企業など、共通の目標を共有しているが互いに完全に信頼していないか又は完全に信頼することができないエンティティのグループ間の相互作用を保護することができる。本発明の解決策は、許可型及び/又は自由参加型ブロックチェーン設定で機能することができる。
【0012】
スマートコントラクトは、(ブロックチェーンの形態である場合がある)共有型台帳又は分散型台帳の改ざん防止プロパティと、エンドースメント又はエンドースメントポリシーと呼ばれるメンバーノード間の基本的な同意を活用する、信頼できる分散アプリケーションである。一般に、ブロックチェーンエントリは、ブロックチェーンに委任される前に「承認」される一方、承認されていないエントリは無視される。典型的なエンドースメントポリシーは、スマートコントラクト実行可能コードが、承認に必要な一連のピアノードの形態で、エントリのエンドーサを指定することができるようにする。クライアントがエンドースメントポリシーで指定されたピアにエントリを送信すると、エントリが実行されてエントリが検証される。検証後、エントリはオーダ段階に入る。この段階では、合意プロトコルを使用して、ブロックにグループ化された承認済みエントリのオーダされた順序が生成される。
【0013】
ノードは、ブロックチェーンシステムの通信エンティティである。「ノード」は、異なるタイプの複数のノードが同じ物理サーバ上で実行することができるという意味で、論理機能を実行してもよい。ノードは信頼ドメインにグループ化され、さまざまな方法でノードを制御する論理エンティティに関連付けられる。ノードは、エントリ呼び出しをエンドーサ(例えば、ピア)に送信し且つエントリ提案をオーダサービス(例えば、オーダノード)に送信するクライアントノード又は提出クライアントノードなど、さまざまなタイプを含み得る。別のタイプのノードには、クライアントが送信したエントリを受信し、エントリを委任し、ブロックチェーンエントリの台帳の状態とコピーを維持することができるピアノードが挙げられる。ピアにはこのほか、エンドーサの役割を演ずることができる。オーダサービスノード又はオーダ者とは、全ノードに対して通信サービスを実施するノードであり、エントリを委任してブロックチェーンのワールドステートを変更するときに、システム内のピアノードのそれぞれへの送信などの配信保証を実施する。ワールドステートは、通常、制御情報及びセットアップ情報を含む初期ブロックチェーンエントリを構成することができる。
【0014】
台帳は、ブロックチェーンのあらゆる状態推移の、順序付けされ且つ改ざん防止された記録である。状態推移が、参加者(例えば、クライアントノード、オーダノード、エンドーサノード、ピアノードなど)によって送信されたスマートコントラクト実行可能コードの呼び出し(即ち、エントリ)から生じる場合がある。エントリが、作成、更新、削除などの1つ又は複数のオペランドとして台帳に委任される一連のアセットのキーと値の対をもたらす場合がある。台帳は、不変で順序付けされた記録をブロックに保存するために使用されるブロックチェーン(チェーンとも呼ばれる)を含む。台帳はこのほか、ブロックチェーンの現在の状態を維持する状態データベースを含む。典型的には、チャネルごとに1つの台帳がある。各ピアノードは、メンバーである各チャネルの台帳のコピーを保持する。
【0015】
チェーンは、ハッシュリンクされたブロックとして構造化されたエントリログであり、各ブロックには、Nが1以上である一連のNエントリが含まれる。ブロックヘッダは、ブロックのエントリのハッシュのほか、前のブロックのヘッダのハッシュを含む。このようにして、台帳の全エントリを順序付けし、暗号学的に連結してもよい。このため、ハッシュリンクを壊さずに台帳データを改ざんすることはできない。ごく最近追加されたブロックチェーンブロックのハッシュが、それより前のチェーン上のあらゆるエントリを表し、全ピアノードが一貫した信頼できる状態にあることを確実なものにすることができる。チェーンは、ピアノードファイルシステム(即ち、局所的な付属のストレージ、クラウドなど)状に保存されてもよく、ブロックチェーン作業負荷の追加専用の性質を効率的に支持する。
【0016】
不変台帳の現在の状態は、チェーンエントリログに含まれる全キーの最新の値を表す。現在の状態は、チャネルに知られている最新のキー値を表すため、ワールドステートと呼ばれることがある。スマートコントラクト実行可能コードの呼び出しが、台帳の現在の状態データに対してエントリを実行する。このようなスマートコントラクト実行可能コードの相互作用を効率化するために、キーの最新の値を状態データベースに保存してもよい。状態データベースは、単にチェーンのエントリログへのインデックス付きビューである場合があるため、いつでもチェーンから再生成することができる。状態データベースは、ピアノードの起動時及びエントリが受け入れられる前に、自動的に回復されてもよい(あるいは必要に応じて生成されてもよい)。
【0017】
ブロックチェーンは、中央ストレージではなく、分散型で不変の安全なストレージであり、ノードはストレージ内の記録への変更を共有する必要がある点で、従来のデータベースとは異なる。ブロックチェーンに固有であり、ブロックチェーンの実装に役立ついくつかのプロパティには、不変の台帳、スマートコントラクト、セキュリティ、プライバシー、分散化、合意、承認、アクセス可能性などが含まれるが、ここに挙げたものに限定されない。
【0018】
例示的な実施形態では、特定の車両にサービスが提供されたり、及び/又は車両に適用されるユーザプロファイルにサービスが提供されたりする。例えば、ユーザは、車両の所有者、あるいは別の関係者が所有する車両の操作者であってもよい。車両は一定の間隔でサービスを必要とする場合があり、サービスの要望では、サービスを受けることを許可する前に承諾を必要とする場合がある。このほか、サービスセンタが、車両の現在のルート計画とサービス要件の相対的なレベル(例えば、即時、重度、中程度、軽度など)に基づいて、近くのエリアの車両にサービスを提供してもよい。車両の要望は、感知したデータを車両内の中央制御コンピュータ装置及び/又は車両から離れた中央制御コンピュータ装置に報告する1つ又は複数の車両及び/又は道路のセンサ又はカメラを介して監視されてもよい。このデータは、レビューと行動のために管理サーバに転送される。センサは、輸送体の内部、輸送体の外部、輸送体から離れた固定物体及び輸送体に近接する別の輸送体のうちの1つ又は複数に配置されてもよい。センサはこのほか、輸送体の速度、輸送体の制動、輸送体の加速、燃料の残量、サービスの要望、輸送体のギアシフト、輸送体のステアリングなどに関連付けられてもよい。本明細書で説明するように、このほか、センサは、輸送体内の無線装置及び/又は輸送体に近接する無線装置などの装置であってもよい。このほか、センサ情報を使用して、車両が安全に動作しているか否か及び乗員が車両アクセス及び/又は使用期間中などの任意の予期しない車両状況に関与しているか否かが識別されてもよい。車両の動作前、動作中及び/又は動作後に収集された車両情報を識別し、共有型/分散型台帳のトランザクションに保存してもよい。このトランザクションは、許可付与共同体によって、ひいてはブロックチェーンメンバーシップグループなどを介した「分散型」の方法にて判定されるように生成されて不変の台帳に委任されてもよい。
【0019】
各利害関係者(即ち、所有者、ユーザ、企業、代理店など)は、個人情報の公開を制限したい場合があるため、ブロックチェーンとその不変性を使用して、特定のユーザ車両プロファイルごとに許可を管理することができる。スマートコントラクトは、補償を提供し、ユーザプロファイルの点数/評価/批評を定量化し、車両イベント許可を適用し、サービスが必要な時期を判定し、衝突イベント及び/又は劣化イベントを特定し、安全上の懸念イベントを特定し、イベントの関係者を特定し、且つそのような車両イベントデータへのアクセスを求めている登録エンティティに配信を提供するために用いられてもよい。このほか、結果を特定してもよく、必要な情報は、ブロックチェーンに関連付けられた合意アプローチに基づいて、登録された企業間及び/又は個人間で共有することができる。そのようなアプローチは、従来の集中型データベースでは実施されないことがあり得る。
【0020】
本解決策のさまざまな運転システムは、ソフトウェア、一連のセンサのほか、機械学習機能、光検出及び測距(LIDAR)投影機、レーダ、超音波センサなどを利用して、輸送体がナビゲーション及びその他の目的で使用することができる地形と道路の地図を作成することができる。いくつかの実施形態では、このほか、GPS、地図、カメラ、センサなどを、LIDARの代わりに自律型車両で使用することができる。
【0021】
本解決策は、特定の実施形態では、自動化された迅速な認証スキームを介してサービスを車両に認可することを含む。例えば、充電ステーション又は燃料ポンプまでの運転は、車両の操作者又は自律型輸送体によって実施される場合があり、サービス及び/又は充電ステーションによって認証が受信される場合、充電又は燃料を受け取るための認証は遅滞なく実施される場合がある。車両は、サービスを受け入れることを認可されたアカウントに連結された現在有効なプロファイルを有する車両の識別を提供する通信信号を提供することができ、通信信号は後に補償によって修正されることができる。別の識別子をユーザの装置から無線でサービスセンタに送信して、輸送体とサービスセンタとの間の第1の認可作業を追加の認可作業に置き換えるか補足するなど、追加の認証を提供するために追加の手段が使用されてもよい。
【0022】
共有され受信されたデータがデータベースに保存されてもよい。このデータベースは、データを1つの単一データベース(例えば、データベースサーバ)内で、概ね1つの特定の場所に保持する。この場所は、中央コンピュータ、例えば、デスクトップの中央処理装置(CPU)、サーバのCPU又はメインフレームコンピュータである。集中データベースに保存された情報に、典型的には、複数の異なる点からアクセスすることができる。集中データベースでは、その場所が1か所であるため、特にセキュリティの目的で、管理、保守及び制御が容易である。集中データベース内では、このほか、全データを1つの場所に保存することが、所与のデータセットに一次記録が1つしかないことを意味するため、データの冗長性が最小限に抑えられる。輸送体関連のデータ及びトランザクションを保存するためにブロックチェーンが使用されてもよい。
【0023】
例示的な実施形態によれば、輸送体と充電ステーションとの間の要望に基づくエネルギー共有のための解決策が提供される。Vehicle to Grid(車両対グリッド)(V2G)による余剰エネルギーの提供は、特に、エネルギー需要が高い時期に有用である。電気輸送体又はハイブリッド輸送体が、一時的な移動エネルギーストレージとして機能する可能性がある。例示的な実施形態では、電気輸送体又はハイブリッド輸送体から得られるエネルギー量を制御してもよく、一定期間内に輸送体が要求するであろう第2のエネルギー量を判定してもよい。輸送体が、サーバからの指示に基づいて、充電ステーションを介してグリッドにエネルギーを返還することを独自に判定してもよい。この決定(又は指示)は、現在の気温、1年のうちの1日、1日のうちのある時間、予測される天候の変化、物体(輸送体、住居、施設など)の現在のエネルギー使用量及び(地理的な場所、都市などの)全体的なエネルギー使用量に基づくものであってもよい。この決定はこのほか、(以下でさらに説明する)エネルギー消費状況をモデル化するAIシステムによって提供される機械学習データに基づいて実施されてもよい。
【0024】
一実施形態では、充電ステーションにエネルギーを提供する輸送体は、充電ステーションからそのようなエネルギーを取り出さないことによってエネルギーを保存する輸送体と同等である。充電ステーションは、輸送体にエネルギーを提供してもよいが、履歴データ又は機械学習データに基づいて、この輸送体によって近い将来に充電ステーションに返還されると考えられるエネルギーの量を提供しなくてもよい。
【0025】
例えば、輸送体のユーザが、充電ステーションから輸送体を100%まで充電したいと考えている。充電ステーションは、使用量が50%のみであろうことと、輸送体が通常、将来充電ステーションに25%を返還することを「確信」している。充電ステーションは、輸送体上及び/又は輸送体外にあり得るデータストレージから取得した以前の使用記録に基づいて、この情報を認識している。さらに、充電ステーションは、特定の期間(時間、日、週など)にわたる輸送体の目的地及びルートを受信してもよい。この情報は、輸送体、輸送体及び充電ステーションに通信可能に結合されたサーバ、別の輸送体、携帯電話などの装置などから受信することができる。この情報に基づいて、充電ステーションは、輸送体が必要とするであろうエネルギー量を判定し、同等又はほぼ同等の量を提供することができる。充電ステーションはこのほか、輸送体が必要とするエネルギー量を判定する際に、天候、道路状況、交通状況、輸送体の状況などを考慮してもよい。充電ステーションは、必要な量のエネルギーを提供することにより、輸送体が100%の電力を供給されていた場合に充電ステーションが輸送体に提供したであろう追加のエネルギーを保持する。そのため、輸送体は充電ステーションに戻り、余剰エネルギーをグリッドに返還する必要がなくなる。任意の余剰エネルギーを提供するために充電ステーションに戻る必要がない輸送体に関連する節約を計算することができる。
【0026】
本明細書の例を参照すると、充電ステーションは、エネルギー使用量が50%になり且つ残りのエネルギー充電が25%になるであろうと判定するため、ユーザが輸送体に100%充電したい場合であっても、エネルギーの移送を75%で停止してもよい。エネルギーの25%を充電ステーションから取り出さないことは、一時的に100%のエネルギー充電を輸送体に提供してから、輸送体が戻って、この例では25%~50%などの充電を再び預け入れるよりも、V2Gエネルギー移送を提供するのに効率的な方法である。充電ステーションとの間の往復で定期的に消費されるであろう節約エネルギー量は、往復を実施しない輸送体に基づいて、節約された量(25%)と、消費されて現在節約されていたであろう量(例えば、2.5%)とを合計した量を含み得る総節約エネルギー量を求めて、計算される。エネルギー節約量は、輸送体のタイプ、充電ステーションまでの距離、輸送体に関連する区分及び1日あたりの乗員数などに基づいて、充電ステーション(又は輸送体)によって計算されてもよい。一例では、輸送体(又はそのユーザ)が、エネルギー移送の対価(例えば、金銭的クレジット又はエネルギークレジット)を受け取ってもよい。
【0027】
一実施形態では、輸送体は、ブロックチェーンネットワークを介してサーバ及び充電ステーションに通信可能に結合されてもよい。輸送体、サーバ及び充電ステーションは、ブロックチェーンピアとして機能してもよい。エネルギー要求は、充電ステーションの範囲内のいくつかの輸送体ピアに送信されてもよい。充電ステーションは、ブロックチェーン台帳に記録されたトランザクションに基づいて、充電ステーションにエネルギーを提供した輸送体を特定してもよい。
【0028】
一実施形態では、輸送体は、ローカルストレージ又はブロックチェーン台帳のローカルのコピーに全記録を保持する。これとは別に、記録は中央サーバで作成されてもよい。記録は、以前に記録されたエネルギーの節約量と共に、輸送体のエネルギー移送履歴を含んでもよい。輸送体はこのほか、現在のエネルギーレベルと、乗客及び/又は貨物の移送中の推定エネルギーレベルとを記録してもよい。このデータに基づいて、エネルギー要求が輸送体に送信されてもよい。一方で、短い局地的移動を記録する輸送体は、大量の余剰エネルギーを有する。輸送体が貨物及び/又は乗客の移送を完了した時点で、現在のエネルギーレベルが記録され、余剰エネルギーの利用可能性が再評価されてもよい。一例では、予測される利用可能なエネルギー量は、輸送体のプロセッサによって計算され、サーバ又は充電ステーションで利用可能にされてもよい。別の例では、サーバは、輸送体のローカルストレージにアクセスしてもよく、現在のエネルギーレベル、輸送体の現在の位置、輸送体の目的地などに基づいて、予測されるエネルギーレベルを判定してもよい。
【0029】
輸送体へ又は輸送体から移送されるエネルギーの量は、輸送体上及び/又は輸送体外に配置され得るサーバ又はコンピュータによって判定されてもよい。昼夜の時間、エネルギーの移送時間、移送されるエネルギーの値、グリッドからのエネルギーの最終的な受信者のタイプ、充電ステーションから別の輸送体へのエネルギーの直接移送などのパラメータが考慮されてもよい。充電ステーション(又はサーバ)は、アクセス可能な(距離及び/又は時間を含む)範囲内で利用可能な輸送体が何かを判定してもよい。充電ステーション/サーバはこのほか、その要求している充電ステーションからの現在の距離と輸送体のエネルギー消費量とに基づいて、輸送体からエネルギーを取得する効率を推定してもよい。例えば、サーバが、要求している充電ステーションの範囲内でいくつかの輸送体を検出した場合、充電ステーション/サーバは、充電ステーション/サーバと輸送体との間の通信を介して余剰エネルギーを有する輸送体を特定してもよい。サーバは、輸送体ごとに、要求している充電ステーションに到達するために必要な追加のエネルギー消費量を計算してもよい。次に、追加のエネルギー消費量が最も少ない輸送体は、最も効率的な余剰エネルギーの移送を実施する充電ステーションに誘導されてもよい。
【0030】
例示的な実施形態によれば、車両と充電ステーションとの間の余剰エネルギーを管理するアプローチが実施される。本明細書で説明するように、輸送体は無差別に充電ステーションに送られるわけではなく、単純に100%まで充電されるわけではない場合がある。代わりに、本システムは、輸送体が余剰エネルギーを有し、充電ステーションにエネルギーを返還する履歴を有し(あるいはエネルギーを提供するための合意を提供し)、充電ステーションなどに到達するための最小量の追加エネルギーを必要とする場合、グリッドに余剰エネルギーを提供するために輸送体を充電ステーションに誘導する。そのため、充電ステーション及び輸送体が、さらに効率的で堅牢なエネルギー保存を可能にする予測及び追加のエネルギー量を量る能力が提供される。
【0031】
一実施形態では、輸送体は、ブロックチェーンネットワークを介して充電ステーションに接続されてもよい。輸送体及び充電ステーションは、ブロックチェーンピアとして機能してもよい。エネルギー要求は、充電ステーションのアクセス可能な範囲内のいくつかの輸送体に送信されてもよい。輸送体及び充電ステーションノードは、どの輸送体がエネルギーを提供する予定か、エネルギーの100%未満を充電する予定かについて合意に達してもよい。充電ステーションピアが少なくとも1つの輸送体から合意を受信した時点で、その輸送体は充電ステーションに誘導され得る一方で、他の輸送体は他に誘導される。エネルギー移送トランザクションは、利用可能なエネルギー量を追跡するためにブロックチェーンに記録されてもよい。一実施形態では、ブロックチェーンピア(即ち、充電ステーション及び輸送体)のそれぞれが、ブロックチェーン台帳の独自のローカルコピーを維持する。このようにして、輸送体ピアは、スマートコントラクトを実行して、エネルギー移送(又は充電)トランザクションのそれぞれを、そのローカル台帳に記録してもよい。例えば、輸送体は受け取り場所と受け渡し場所と時間とを、その受け取り場所と目的地でのエネルギーレベルと共に記録してもよい。目的地のエネルギーレベルは、輸送体のモデルの既知のエネルギー消費量に基づいて推定されてもよい。受け渡しが完了した時点で、輸送体は、現在の場所及びエネルギーレベルをタイムスタンプと共にローカル台帳に記録してもよい。輸送体の余剰エネルギーの利用可能性は、受け渡しの完了時に更新されてもよい。このようにして、サーバ又は充電ステーションのピアは、余剰エネルギーを有する輸送体に関する全情報を有してもよい。このため、充電ステーションは、その現在位置と、エネルギーレベルと、要求している充電ステーションまでの移動に必要な追加のエネルギー消費とに基づいて、輸送体へのエネルギー移送の要求を生成してもよい。余剰エネルギーレベル、タイムスタンプ付きの場所、輸送体のタイプ及びそのエネルギー消費量は、ブロックチェーン台帳から充電ステーションピアによって取得されてもよい。輸送体の現在のエネルギーレベルは、余剰エネルギーを共有するか、少なめのエネルギーを充電するのに充分なものである必要がある。例えば、特定のタイプの輸送体が、50%のエネルギーで3日間、現地で駆動することができる。輸送体の現在のエネルギーレベルが75%である場合、輸送体は、そのエネルギーの最大25%を、要求している充電ステーションに安全に移送することができる。さらに、輸送体にエネルギーが必要な場合、現地の運転要求に基づいて、満充電ではなく50%しか充電しない場合がある。次に、充電ステーションピアが輸送体を選択する場合、充電ステーションが要求したエネルギー量に対する輸送体の利用可能なエネルギーに基づいて、エネルギー移送の合意が達成される。輸送体がエネルギーを充電ステーションに移送した時点(あるいは充電ステーションから取り出すエネルギーが少なくなった時点)で、エネルギー移送トランザクションがブロックチェーンに記録され、さらに(金銭的クレジット又はエネルギークレジットなどの)対価が実施される。
【0032】
本明細書で考察するように、輸送体は、どの輸送体がエネルギーを提供する予定か(あるいは100%未満の充電になるか)について合意に達してもよい。充電ステーションピアが少なくとも1つの輸送体から合意を受信した時点で、輸送体は、エネルギー移送(又は部分充電)のために充電ステーションに誘導されてもよい。エネルギー移送トランザクションは、利用可能なエネルギー量の追跡を維持するためにブロックチェーンに記録されてもよい。節約量は、将来の参照用に輸送体ごとに記録されてもよい。各エネルギー移送トランザクションは、将来の監査と輸送体ごとの記録とを保持するために、ブロックチェーンに記録されてもよい。
【0033】
図1は、例示的な実施形態係る輸送体ネットワーク図を示す。
図1を参照すると、ネットワーク
図100は、(図示しない)ネットワークを介して充電ステーション(又は充電ステーションノード)112に接続された電気(又はハイブリッド)輸送体104及び105を含む。充電ステーション112は、輸送体104及び105のうちの1つ又は複数からエネルギーの要求134/135を受信してもよい。同じように、充電ステーション112は、範囲内を移動する電気(又はハイブリッド)輸送体104及び105を検出し、このような輸送体にエネルギーの要求134/135を送信してもよい。輸送体104及び105は、その現在の充電データを充電ステーション112に提供してもよい。輸送体の現在の充電データが充分であると充電ステーション112が判定した場合、充電ステーション112は、エネルギーを提供するために充電ステーションに移動するように輸送体に指示してもよい。充電ステーション112が、輸送体の現在の充電データが低いと判定し、且つ、例えば、25%の返還充電がこの輸送体のために残っていて利用可能であると判定した場合、充電ステーション112は、輸送体に充電ステーション112まで移動し、残りの充電を受け取るように指示してもよい。
【0034】
一実施形態では、輸送体104及び105がほぼ同じ量のエネルギーを有する場合、輸送体のうちの1つが、アクセス可能な範囲内の輸送体間の同意(即ち、合意)138に基づいて、充電ステーション112に確認/合意132を提供してもよい。一例では、充電ステーション112は、(支払いクレジット、エネルギークレジットなどに基づいて)将来の監査のため、及び/又は後の時点でほぼ同じ量のエネルギーをこの輸送体に返還するために、特定の輸送体が一定量のエネルギーを充電ステーション112に提供したことを記録してもよい。
【0035】
図2Aは、例示的な実施形態係る輸送体ネットワーク
図200を示す。ネットワークは、プロセッサ204を含む輸送体ノード202のほか、プロセッサ204’を含む輸送体ノード202’を含む要素を備える。輸送体ノード202、202’は、プロセッサ204、204’のほか、送受信機、送信機、受信機、ストレージ、センサをはじめとする通信を提供可能な要素を含む(図示しない)他の要素を介して互いに通信してもよい。輸送体ノード202、202’間の通信は、(図示しない)私的ネットワーク及び/又は公共ネットワークを介して、あるいは他の輸送体ノードと、プロセッサ、メモリ及びソフトウェアのうちの1つ又は複数を備える要素とを介して、直接実施されることがある。単一の輸送体ノード及びプロセッサとして描写しているが、複数の輸送体ノード及びプロセッサが存在してもよい。本明細書に記載したり、及び/又は描写したりするアプリケーション、特徴、ステップ、ソリューションなどのうちの1つ又は複数を、本発明の要素が利用したり、及び/又は提供したりしてもよい。
【0036】
図2Bは、例示的な実施形態係る、別の輸送体ネットワーク
図210を示す。ネットワークは、プロセッサ204を含む輸送体ノード202のほか、プロセッサ204’を含む輸送体ノード202’を含む要素を備える。輸送体ノード202、202’は、プロセッサ204、204’のほか、送受信機、送信機、受信機、ストレージ、センサをはじめとする通信を提供可能な要素を含む(図示しない)他の要素を介して互いに通信してもよい。輸送体ノード202、202’間の通信は、(図示しない)私的ネットワーク及び/又は公共ネットワークを介して、あるいは他の輸送体ノードと、プロセッサ、メモリ及びソフトウェアのうちの1つ又は複数を備える要素とを介して、直接実施されることがある。プロセッサ204、204’は、センサ212、有線装置214、無線装置216、データベース218、携帯電話220、輸送体ノード222、コンピュータ224、入出力装置226及び音声アプリケーション228を含む1つ又は複数の要素230とさらに通信することができる。プロセッサ204、204’は、プロセッサ、メモリ及びソフトウェアのうちの1つ又は複数を備える要素とさらに通信することができる。
【0037】
単一の輸送体ノード、プロセッサ及び要素として描写しているが、複数の輸送体ノード、プロセッサ及び要素が存在してもよい。情報又は通信が、プロセッサ204、204’及び要素230のいずれかとの間で発生することがある。例えば、携帯電話220は、プロセッサ204に情報を提供してもよい。プロセッサ204は、輸送体ノード202を起動して行動を実行させてもよく、情報又は追加情報をプロセッサ204’にさらに提供してもよい。プロセッサ204’は、輸送体ノード202’を起動して行動を実行させてもよく、情報又は追加情報を携帯電話220、輸送体ノード222及び/又はコンピュータ224にさらに提供してもよい。本明細書に記載したり、及び/又は描写したりするアプリケーション、特徴、ステップ、ソリューションなどのうちの1つ又は複数を、本発明の要素が利用したり、及び/又は提供したりしてもよい。
【0038】
図2Cは、例示的な実施形態係る、輸送体から充電ステーションへの優先度に基づくエネルギー移送のための輸送ネットワーク図を示す。
図2Cを参照すると、ネットワーク
図240は、ブロックチェーンネットワーク206を介して他の輸送体ノード202’及び充電ステーションノード203に接続された輸送体ノード202を含む。充電ステーションノード203は、輸送体/車両を代表し得る輸送体ノード202及び202’に接続されてもよい。ブロックチェーンネットワーク206は、エネルギー移送関連データ(即ち、供給者側輸送体ID、エネルギー量、残量、節約量、移送の日時など)を保存するための台帳208を有してもよい。
【0039】
この例では、1つの充電ステーションノード203のみを詳細に説明しているが、複数のそのようなノードをブロックチェーン206に接続してもよい。充電ステーションノード203は、追加の構成要素を含んでもよく、本明細書で開示する充電ステーションノード203の範囲から逸脱することなく、本明細書で説明する構成要素のいくつかを削除したり、及び/又は修正したりしてもよいことを理解されたい。充電ステーションノード203は、計算装置又はサーバコンピュータなどであってもよく、半導体ベースのマイクロプロセッサ、中央処理装置(CPU)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)及び/又は別のハードウェア装置であり得るプロセッサ204を含んでもよい。単一のプロセッサ204を示しているが、充電ステーションノード203は、本出願の範囲から逸脱することなく、複数のプロセッサ、複数のコアなどを含み得ることを理解されたい。
【0040】
充電ステーションノード203はこのほか、プロセッサ204によって実行可能な機械可読命令を保存し得る非一時的コンピュータ可読媒体201を含んでもよい。機械可読命令の例を、ステップ211~215として示し、本明細書でさらに考察する。非一時的コンピュータ可読媒体201の例には、実行可能な命令を含むか保存する電子、磁気、光学又は他の物理的記憶装置を含んでもよい。例えば、非一時的コンピュータ可読媒体201は、ランダムアクセスメモリ(RAM)、電気的に消去可能なプログラム可能読み取り専用メモリ(EEPROM)、ハードディスク、光ディスク又は他のタイプの記憶装置であってもよい。プロセッサ及び/又はコンピュータ可読媒体は、輸送体ノード上及び/又は輸送体ノード外に全体的に存在しても、部分的に存在してもよい。コンピュータ可読媒体に保存されたステップ又は特徴は、任意の順序でプロセッサ及び/又は要素のいずれかによって完全に実施されても部分的に実施されてもよい。
【0041】
プロセッサ204は、機械可読命令211を実行して、満充電のために輸送体(例えば、202/202’)が必要とする第1のエネルギー量を判定してもよい。輸送体202及び202’のそれぞれは、ブロックチェーンネットワーク206上のネットワークノードとして機能してもよい。ブロックチェーン206のネットワークは、参加ノード(例えば、202及び202’)のためのトランザクションを管理し得る輸送体(即ち、ノード)上に位置する1つ又は複数のスマートコントラクトを使用するように構成されてもよい。プロセッサ204は、機械可読命令213を実行して、輸送体202/202’が後に充電ステーション212に返還するであろう第2のエネルギー量を判定してもよい。プロセッサ204は、機械可読命令215を実行して、輸送体202/202’を、第1のエネルギー量と第2のエネルギー量との間の差に等しい充電レベルまで充電してもよい。さらに、1つ又は複数のステップ又は特徴を追加しても、省略しても、組み合わせても、後に実施するなどしてもよい。
【0042】
図3Aは、例示的な実施形態係る方法の流れ
図300を示す。
図3Aを参照すると、充電ステーションノード203(
図2Cを参照)によって例示的な方法が実行されてもよい。
図3Aに示す方法300は、追加の操作を含んでもよく、本出願の範囲から逸脱することなく、そこに記載の操作のいくつかを削除したり、及び/又は変更したりしてもよいことを理解されたい。このほか、方法300について、説明のために
図2Cに示した特徴を参照して説明する。特に、SCノード203のプロセッサ204は、方法300に含まれる操作の一部又は全部を実行してもよい。
【0043】
図3Aを参照すると、プロセッサ204は、以下の各ステップのそれぞれのうちの1つ又は複数を実施してもよい。ブロック302では、プロセッサ204は、輸送体が満充電のために必要とする第1のエネルギー量を判定してもよい。ブロック304では、プロセッサ204は、輸送体が後に充電ステーションに返還するであろう第2のエネルギー量を判定してもよい。ブロック306では、プロセッサ204は、第1のエネルギー量と第2のエネルギー量との間の差に等しい充電レベルまで輸送体を充電してもよい。
【0044】
図3Bは、例示的な実施形態係る例示的な方法の流れ
図320を示す。
図3Bを参照すると、方法320は、以下のステップのうちの1つ又は複数も含んでもよい。ブロック322では、プロセッサ204は、第1のエネルギー量に対する第2のエネルギー量の比例配分に基づいて計算された第3のエネルギー量と、第2のエネルギー量との間の差に等しい充電レベルまで、後の時点で輸送体を充電してもよい。このため、輸送体が要求された充電(又は満充電)の25%を常に放棄する場合、第3のエネルギー量は第2のエネルギー量の25%として計算されてもよい。
【0045】
ブロック324では、プロセッサ204は、輸送体が戻って第2のエネルギー量を返還するときの充電ステーションへの輸送体の予測される往復に基づいてエネルギーの節約量を計算してもよい。ブロック326では、プロセッサ204は、エネルギーの節約量を充電レベルと共に輸送体に提供してもよい。エネルギーの節約量は、第2のエネルギー量を放棄する動機として機能してもよい。ブロック328では、プロセッサ204は、輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第2のエネルギー量を判定してもよい。機械学習データは、気温、時間帯、時期などに基づいてエネルギーの使用量と需要を予測するAIモデルによって生成されてもよい。ブロック330では、プロセッサ204は、輸送体からの第2のエネルギー量の移送についての確認を受信してもよい。確認は、輸送体及び充電ステーションによって代表されるピア間のブロックチェーン合意であり得ることに留意されたい。ブロック332では、プロセッサ204は、スマートコントラクトを実行して、ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録してもよい。
【0046】
図4は、例示的な実施形態係る、機械学習輸送体ネットワーク
図400を示す。ネットワーク400は、機械学習サブシステム406と相互作用する輸送体ノード402を含む。輸送体ノードは、1つ又は複数のセンサ404を含む。
【0047】
機械学習サブシステム406は、学習モデル408を含む。学習モデル408は、1つ又は複数の訓練データセットにパターンを見つけることによって予測を生成する機械学習訓練システム410によって作成される数学的アーティファクトである。いくつかの実施形態では、機械学習サブシステム406は、輸送体ノード402に存在する。他の実施形態では、機械学習サブシステム406は、輸送体ノード402の外部に存在する。
【0048】
輸送体ノード402は、1つ又は複数のセンサ404から機械学習サブシステム406にデータを送信する。機械学習サブシステム406は、1つ又は複数の予測を戻す学習モデル408に1つ又は複数のセンサ404のデータを提供する。機械学習サブシステム406は、学習モデル408からの予測に基づいて、1つ又は複数の命令を輸送体ノード402に送信する。
【0049】
更なる実施形態では、輸送体ノード402は、1つ又は複数のセンサ404のデータを機械学習訓練システム410に送信してもよい。さらに別の実施形態では、機械学習サブシステム406は、センサ404のデータを機械学習サブシステム410に送信してもよい。本明細書で説明したり、及び/又は描写したりするアプリケーション、特徴、ステップ、ソリューションなどのうちの1つ又は複数が、本明細書で説明する機械学習ネットワーク400を利用してもよい。
【0050】
図5Aは、例示的な実施形態係る、車両に関連するデータベーストランザクションを管理するための例示的な車両構成500を示す。
図5Aを参照すると、特定の輸送体/車両525がトランザクション(例えば、車両サービス、販売業者トランザクション、受け渡し/受け取り、輸送サービスなど)に従事しているとき、車両はアセット510を受け取ったり、及び/又はトランザクションによってアセット512を放出/移転したりしてもよい。輸送体プロセッサ526は車両525に存在し、輸送体プロセッサ526、データベース530、輸送体プロセッサ526及びトランザクションモジュール520の間に通信が存在する。トランザクションモジュール520は、アセット、関係者、クレジット、サービスの説明、日付、時間、場所、結果、通知、予期しないイベントなどの情報を記録してもよい。トランザクションモジュール520内のそのようなトランザクションは、データベース530に複製されてもよい。データベース530は、SQLデータベース、RDBMS、リレーショナルデータベース、非リレーショナルデータベース、ブロックチェーン、分散型台帳のうちの1つであることがあり、輸送体に搭載されていてもよく、輸送体に搭載されていなくてもよく、直接及び/又はネットワークを介してアクセス可能であったりしてもよく、或いは、輸送体にアクセス可能であってもよい。
【0051】
図5Bは、例示的な実施形態係る、さまざまな車両間で実施されるデータベーストランザクションを管理するための例示的な車両構成550を示す。車両525は、車両がサービスを他の車両と共有する必要がある状況に達したときに、別の車両508に関与して、共有、転送、サービスコールの取得などのさまざまな行動を実施してもよい。例えば、車両508は、バッテリの充電が予定されている可能性があったり、及び/又はタイヤに問題がある可能性があったり、配送のために荷物を引き取る途中である可能性があったりする。輸送体プロセッサ528は、車両508内に存在し、輸送体プロセッサ528、データベース554、輸送体プロセッサ528及びトランザクションモジュール552の間に通信が存在する。車両508は、別の車両525であってそのネットワーク内にあり且つそのブロックチェーンメンバーサービスで動作する別の車両525に通知してもよい。輸送体プロセッサ526が車両525内に存在し、輸送体プロセッサ526、データベース530、輸送体プロセッサ526及びトランザクションモジュール520の間に通信が存在する。次に、車両525は、車両508及び/又は(図示しない)サーバから無線通信要求を介して情報を受信して、荷物の集荷を実施してもよい。トランザクションは、両方の車両のトランザクションモジュール552及び520のログに記録される。クレジットは車両508から車両525に転送され、転送されたサービスの記録は、ブロックチェーンが互いに異なるか、全メンバーが使用する同じブロックチェーンのログに記録されていることを前提として、データベース530/554のログに記録される。データベース554は、SQLデータベース、RDBMS、リレーショナルデータベース、非リレーショナルデータベース、ブロックチェーン、分散型台帳のうちの1つであることがあり、輸送体に搭載されていてもよく、輸送体に搭載されていなくてもよく、直接及び/又はネットワーク経由でアクセス可能であったりしてもよい。
【0052】
図6Aは、例示的な実施形態係るブロックチェーンアーキテクチャ構成600を示す。
図6Aを参照すると、ブロックチェーンアーキテクチャ600は、特定のブロックチェーン要素、例えば、ブロックチェーングループ610の一部としてのブロックチェーンメンバーノード602~606のグループを含んでもよい。例示的な一実施形態では、許可型ブロックチェーンに、全関係者がアクセス可能であるわけではなく、ブロックチェーンデータへのアクセスが許可されたメンバーのみがアクセス可能である。ブロックチェーンノードは、ブロックチェーンエントリの追加と検証プロセス(合意)など、さまざまな活動に参加する。ブロックチェーンノードのうちの1つ又は複数は、エンドースメントポリシーに基づいてエントリを承認してもよく、全ブロックチェーンノードにオーダサービスを提供してもよい。ブロックチェーンノードは、ブロックチェーン行動(認証など)を開始し、ブロックチェーンに保存されているブロックチェーンの不変台帳への書き込みを試みてもよい。その台帳のコピーはこのほか、基盤となる物理的インフラに保存されてもよい。
【0053】
ブロックチェーントランザクション620は、トランザクションが受信され、メンバーのノードによって指示された合意モデルによって承認されると、コンピュータのメモリに保存される。承認されたトランザクション626を、ブロックチェーンの現在のブロックに保存し、現在のブロック内のトランザクションのデータコンテンツのハッシュを実行し、前のブロックの前のハッシュを参照することを含む委任手順を介してブロックチェーンに委任する。ブロックチェーン内には、登録された受信者、車両の特徴、要件、許可、センサの閾値など、スマートコントラクト実行可能アプリケーションコード632に含まれるトランザクションの同意及び行動の状況を定義する1つ又は複数のスマートコントラクト630が存在してもよい。このコードは、要求側エンティティが車両サービスを受けるために登録されているか否か、プロファイル状況に基づいてどのようなサービスの特徴を受け取る資格があるか/要求されているか、その後のイベントでエンティティの行動を監視するか否かを識別するように構成されてもよい。例えば、サービスイベントが発生し、ユーザが車両に乗っている場合、センサデータの監視が引き起こされてもよく、車両の充電レベルなどの特定のパラメータが特定の閾値を特定の期間上回っているか下回っていると識別されてもよく、その結果、サービスを識別して、参考のため保存することができるように、管理者(即ち、車両の所有者、車両の操作者、サーバなど)に警告を送信する必要がある現在の状況が変更されてもよい。収集された車両センサデータは、車両の状況に関する情報を収集するために使用されるセンサデータの種類に基づくものであってもよい。センサデータはこのほか、移動する場所、平均速度、最高速度、加速率、何らかの衝突があったか否か、予想されたルートが取られたか、次の目的地はどこか、安全対策が整っているか否か、車両に充分な充電/燃料があるか否かなどの車両イベントデータ634の基礎になってもよい。そのような情報はいずれも、次にブロックチェーンに保存されるスマートコントラクト状況630の基礎となってもよい。例えば、スマートコントラクトに保存されたセンサ閾値を、検出されたサービスが必要であるか否か、いつ、どこでサービスを実施する必要があるかの基準として使用することができる。
【0054】
図6Bは、例示的な実施形態係る共有型台帳構成を示す。
図6Bを参照すると、ブロックチェーン論理例640は、特定のトランザクションのために計算装置及び実行プラットフォームに関連しているAPI又はプラグインアプリケーションとして、ブロックチェーンアプリケーションインターフェース642を含む。ブロックチェーン構成640は、アプリケーションプログラミングインターフェース(API)に連結されて、保存されたプログラム/アプリケーションコード(例えば、スマートコントラクト実行可能コード、スマートコントラクトなど)にアクセスして実行する1つ又は複数のアプリケーションであって、参加者が求めるカスタマイズされた構成によって作成することができ、自身の状態を維持し、自身のアセットを制御し、外部情報を受信することができる1つ又は複数のアプリケーションを含んでもよい。これをエントリとして展開し、分散型台帳に追加することを介して、全ブロックチェーンノードにインストールすることができる。
【0055】
スマートコントラクトアプリケーションコード644は、アプリケーションコードを確立することによって、ブロックチェーントランザクションの基礎を提供する。アプリケーションコードが実行されると、トランザクション状況が有効になる。スマートコントラクト630が実行されると、特定の承認済みトランザクション626が生成され、次にブロックチェーンプラットフォーム652に転送される。プラットフォームは、セキュリティ/認可658と、トランザクション管理656を実行する計算装置と、トランザクションとスマートコントラクトをブロックチェーンに保存するメモリとしてのストレージ部分654と、を含む。
【0056】
ブロックチェーンプラットフォームは、ブロックチェーンデータと、サービス(例えば、暗号信託サービス、仮想実行環境など)と、新たなエントリを受信して保存し、データエントリへのアクセスを求めている監査人へのアクセスを提供するために使用され得る基盤となる物理的コンピュータインフラとのさまざまな層を含んでもよい。ブロックチェーンは、プログラムコードを処理し、物理的インフラを使用するために必要な仮想実行環境へのアクセスを提供するインターフェースを公開してもよい。暗号信託サービスを使用して、アセット交換エントリなどのエントリを検証し、情報を非公開にしてもよい。
【0057】
図6A及び
図6Bのブロックチェーンアーキテクチャ構成は、ブロックチェーンプラットフォームによって公開される1つ又は複数のインターフェースと、ブロックチェーンプラットフォームによって提供されるサービスとを介して、プログラム/アプリケーションコードを処理し、実行してもよい。非限定的な例として、督促、更新及び/又は変更、更新などの対象となる他の通知を実行すべくスマートコントラクトが作成されてもよい。スマートコントラクト自体を使用して、認可とアクセスの要件及び台帳の使用に関連する規則を特定することができる。例えば、情報は、ブロックチェーン層に含まれる1つ又は複数の処理エンティティ(例えば、プロセッサ、仮想マシンなど)によって処理され得る新たなエントリを含んでもよい。結果には、スマートコントラクトで定義された基準及び/又はピアの合意に基づいて、新たなエントリを拒否するか承認する決定が含まれてもよい。物理的インフラは、本明細書に記載のデータ又は情報のいずれかを取得するために利用されてもよい。
【0058】
スマートコントラクト実行可能コード内では、高レベルのアプリケーションとプログラミング言語を介してスマートコントラクトが作成され、ブロックチェーンのブロックに書き込まれてもよい。スマートコントラクトは、ブロックチェーン(例えば、ブロックチェーンピアの分散型ネットワーク)に登録されたり、保存されたり、及び/又は複製されたりする実行可能コードを含んでもよい。エントリは、スマートコントラクトコードの実行であり、スマートコントラクトに関連付けられた状況が満たされることに応答して実施されることができる。スマートコントラクトの実行は、デジタルブロックチェーン台帳の状態に対する信頼できる変更を引き起こしてもよい。スマートコントラクトの実行によって引き起こされるブロックチェーン台帳の変更は、1つ又は複数の合意プロトコルを介して、ブロックチェーンピアの分散ネットワーク全体に自動的に複製されてもよい。
【0059】
スマートコントラクトは、データをキーと値の対の形態でブロックチェーンに書き込んでもよい。さらに、スマートコントラクトコードは、ブロックチェーンに保存された値を読み取り、それをアプリケーション操作で使用することができる。スマートコントラクトコードは、さまざまな論理操作の出力をブロックチェーンに書き込んでもよい。このコードは、仮想マシン又は他の計算プラットフォームで一時的なデータ構造を作成するために使用されてもよい。ブロックチェーンに書き込まれたデータは公開されたり、及び/又は暗号化されて非公開として維持されたりすることができる。スマートコントラクトによって使用/生成される一時データは、供給された実行環境によってメモリに保持され、次にブロックチェーンに必要なデータが特定された時点で削除される。
【0060】
スマートコントラクト実行可能コードには、追加の特徴と共に、スマートコントラクトのコード解釈が含まれてもよい。本明細書で説明するように、スマートコントラクト実行可能コードは、合意プロセス中にチェーン検証ソフトによって一緒に実行されて検証される計算ネットワーク上に展開されるプログラムコードであってもよい。スマートコントラクトの実行可能コードは、ハッシュを受け取り、ブロックチェーンから、以前に保存された特徴抽出器を使用して作成されたデータテンプレートに関連付けられたハッシュを取得する。ハッシュ識別子のハッシュと、保存された識別子テンプレートデータから作成されたハッシュとが一致する場合、スマートコントラクト実行可能コードは要求されたサービスに認可キーを送信する。スマートコントラクト実行可能コードは、暗号化の詳細に関連付けられたブロックチェーンデータに書き込まれてもよい。
【0061】
図6Cは、例示的な実施形態係る、ブロックチェーントランザクションデータを保存するためのブロックチェーン構成を示す。
図6Cを参照すると、例示的な構成660では、車両662と、ユーザ装置664と、分散型台帳(即ち、ブロックチェーン)668と情報を共有するサーバ666と、が提供される。サーバは、既知の確立されたユーザプロファイルが、確立された評価プロファイルを有する車両を借りようとしている場合に、車両サービス提供者に問い合わせてユーザプロファイル評価情報を共有するサービス提供者エンティティを表してもよい。サーバ666は、車両のサービス要件に関連するデータを受信して処理していてもよい。車両センサデータが燃料/充電、メンテナンスサービスなどの要望を示すなどのサービスイベントが発生すると、車両サービスイベントを呼び出すために使用され得る規則、閾値、センサ情報収集などを呼び出すべく、スマートコントラクトが使用されてもよい。ブロックチェーントランザクションデータ670は、アクセスイベント、車両のサービス状況に対するその後の更新、イベント更新などのトランザクションごとに保存される。トランザクションは、関係者と、要件(例えば、18歳、サービス資格のある候補者、有効な運転免許証など)と、報酬レベルと、イベント中の移動距離と、イベントへのアクセスと車両サービスの主催を許可された登録済み受信者と、権利/許可と、次のサービスイベントの詳細をログに記録し、車両の条件状況を識別するために車両イベント操作中に取得されたセンサデータと、サービスイベントが完了したか及び車両の条件状況が完了したかを判定するために使用される閾値と、を含んでもよい。
【0062】
図6Dは、例示的な実施形態係る、分散型台帳に追加することができるブロックチェーンブロック680と、ブロック構造682A~682nの内容と、を示す。
図6Dを参照すると、(図示しない)クライアントが、エントリをブロックチェーンノードに送信して、ブロックチェーン上で活動を実施してもよい。例として、クライアントは、ブロックチェーンのエントリを提案する装置、個人又はエンティティなどのリクエスタに代わって作動するアプリケーションであってもよい。複数のブロックチェーンピア(例えば、ブロックチェーンノード)は、ブロックチェーンネットワークの状態と分散型台帳のコピーを維持してもよい。さまざまなタイプのブロックチェーンノード/ピアが、クライアントによって提案されたエントリをシミュレートして承認する承認ピアと、承認を検証し、エントリを検証し、エントリを分散型台帳に委任する委任ピアとを含むブロックチェーンネットワークに存在してもよい。この例では、ブロックチェーンノードは、エンドーサノード、コミッタノード又はその両方の役割を演じてもよい。
【0063】
本システムは、不変の順序付けされた記録をブロックに保存するブロックチェーンと、ブロックチェーンの現在の状態を維持する状態データベース(現在の世界状況)とを含む。チャネルごとに1つの分散型台帳が存在してもよく、各ピアは、メンバーであるチャネルごとに分散型台帳の独自のコピーを保持する。本ブロックチェーンは、各ブロックに一連のNエントリが含まれるハッシュリンクされたブロックとして構造化されたエントリログである。ブロックには、
図6Dに示すようなさまざまな構成要素が含まれてもよい。ブロックのリンクは、現在のブロックのブロックヘッダ内に前のブロックのヘッダのハッシュを追加することによって生成されてもよい。このようにして、ブロックチェーン上の全エントリが順序付けられ、暗号学的に互いに連結され、ハッシュリンクを壊すことなくブロックチェーンデータの改ざんを防止する。さらに、リンクがあるため、ブロックチェーンの最新のブロックは、それ以前の全エントリを表す。本発明のブロックチェーンは、追加専用のブロックチェーン作業負荷をサポートするピアファイルシステム(ローカルストレージ又は接続ストレージ)に保存されてもよい。
【0064】
ブロックチェーンと分散型台帳の現在の状態は、状態データベースに保存されてもよい。ここで、現在の状態データは、ブロックチェーンのチェーンエントリログに含まれている全キーの最新の値を表す。スマートコントラクト実行可能コードの呼び出しが、状態データベース内の現在の状態に対してエントリを実行する。このようなスマートコントラクト実行可能コードの相互作用を非常に効率的なものにするために、全キーの最新の値が状態データベースに保存される。状態データベースは、ブロックチェーンのエントリログへの索引付きビューを含んでいる場合があるため、いつでもチェーンから再生成することができる。状態データベースは、エントリが受け入れられる前に、ピアの起動時に自動的に回復されてもよい(あるいは必要に応じて生成されてもよい)。
【0065】
承認ノードが、クライアントからエントリを受信し、シミュレートされた結果に基づいてエントリを承認する。承認ノードは、エントリの提案をシミュレートするスマートコントラクトを保持する。承認ノードがエントリを承認すると、承認ノードはエントリ承認を作成する。エントリ承認は、承認ノードから、シミュレートされたエントリの承認を示すクライアントアプリケーションへの署名付き応答である。エントリを承認する方法は、スマートコントラクト実行可能コード内で指定され得るエンドースメントポリシーによって異なる。エンドースメントポリシーの一例には、「承認するピアの過半数がエントリを承認する必要がある」が挙げられる。異なるチャネルには、異なるエンドースメントポリシーがあってもよい。承認されたエントリを、クライアントアプリケーションによってオーダサービスに転送する。
【0066】
オーダサービスは、承認されたエントリを受け入れ、ブロックにオーダし、委任ピアにブロックを配信する。例えば、オーダサービスは、エントリの閾値に達するか、タイマーがタイムアウトするか、別の状況になったときに、新たなブロックを開始してもよい。この例では、ブロックチェーンノードは、ブロックチェーンに保存するためのデータブロック682Aを受信した委任ピアである。オーダサービスは、オーダ者のクラスターから構成されてもよい。オーダサービスは、エントリ、スマートコントラクトを処理することも、共有台帳を維持することもしない。むしろ、オーダサービスは、承認されたエントリを受け入れ、そのようなエントリを分散型台帳に委任するオーダを指定する。ブロックチェーンネットワークのアーキテクチャは、「オーダ」の特定の実装(例えば、Solo、Kafka、BFTなど)がプラグ着脱可能なコンポーネントになるように設計されてもよい。
【0067】
エントリは、一貫した順序で分散型台帳に書き込まれる。エントリのオーダは、状態データベースへの更新がネットワークに委任されたときに有効になるように確立される。暗号パズルの解決又は検索を通じてオーダが発生する暗号通貨ブロックチェーンシステム(例えば、ビットコインなど)とは異なり、この例では、分散型台帳の関係者がそのネットワークに最適なオーダ機構を選択してもよい。
【0068】
図6Dを参照すると、ブロックチェーン及び/又は分散型台帳に保存されるブロック682A(データブロックとも呼ばれる)は、ブロックヘッダ684A~684n、トランザクション固有データ686A~686n及びブロックメタデータ688A~688nなどの複数のデータセグメントを含んでもよい。ブロック682A及びその内容など、さまざまな図示のブロック及びその内容は、単に例示を目的としており、例示的な実施形態の範囲を限定することを意図していないことを理解されたい。場合によっては、ブロックヘッダ684Aとブロックメタデータ688Aの両方が、エントリデータを保存するトランザクション固有データ686Aよりも小さい場合がある。しかし、これは要件ではない。ブロック682Aは、ブロックデータ690A~690n内のN個(例えば、100個、500個、1000個、2000個、3000個など)のエントリのトランザクション情報を保存してもよい。ブロック682Aはこのほか、ブロックヘッダ684A内の(例えば、ブロックチェーン上の)前のブロックへのリンクを含んでもよい。特に、ブロックヘッダ684Aは、前のブロックのヘッダのハッシュを含んでもよい。ブロックヘッダ684Aはこのほか、一意のブロック番号、現在のブロック682Aのブロックデータ690Aのハッシュなどを含んでもよい。ブロック682Aのブロック番号は、一意であってもよく、ゼロから始まる漸増/順次の順序で割り当てられてもよい。ブロックチェーンの第1のブロックは、ブロックチェーン、そのメンバー、そのブロックに保存されているデータなどに関する情報を含む起源ブロックと呼ばれる場合がある。
【0069】
ブロックデータ690Aは、ブロック内に記録される各エントリのエントリ情報を保存してもよい。例えば、エントリデータには、エントリのタイプ、バージョン、タイムスタンプ、分散型台帳のチャネルID、エントリID、エポック、ペイロードの可視性、スマートコントラクト実行可能コードパス(deploytx)、スマートコントラクト実行可能コード名、スマートコントラクト実行可能コードバージョン、入力(スマートコントラクト実行可能コードと機能)、公開鍵及び証明書などのクライアント(作成者)ID、クライアントの署名、エンドーサのID、エンドーサ署名、提案ハッシュ、スマートコントラクト実行可能コードイベント、応答状況、名前空間、読み取りセット(エントリによって読み取られるキーとバージョンのリストなど)、書き込みセット(キーと値のリストなど)、開始キー、終了キー、キーのリスト、メルケルツリークエリの概要などが含まれてもよい。エントリデータは、N個のエントリのそれぞれについて保存されてもよい。
【0070】
いくつかの実施形態では、ブロックデータ690Aはこのほか、ブロックチェーン内のブロックのハッシュリンクされたチェーンに追加情報を追加するトランザクション固有データ686Aを保存してもよい。このため、データ686Aは、分散型台帳上のブロックの不変ログに保存することができる。そのようなデータ686Aを保存する利点のいくつかは、本明細書で開示し描写するさまざまな実施形態に反映される。ブロックメタデータ688Aは、メタデータの複数のフィールドを(例えば、バイト配列などとして)保存してもよい。メタデータフィールドには、ブロック作成時の署名、最後の構成ブロックへの参照、ブロック内の有効なエントリと無効なエントリを識別するエントリフィルタ、ブロックをオーダしたオーダサービスの最後のオフセットなどが含まれてもよい。署名、最後の構成ブロック及びオーダ者のメタデータは、オーダサービスによって追加されてもよい。一方、ブロックのコミッタ(ブロックチェーンノードなど)が、エンドースメントポリシー、読み取り/書き込みセットの検証などに基づいて有効/無効情報を追加してもよい。エントリフィルタは、ブロックデータ610A内のエントリの数に等しいサイズのバイト配列と、エントリが有効/無効であったか否かを識別する検証コードとを含んでもよい。
【0071】
ブロックチェーン内の他のブロック682Bから682nはこのほか、ヘッダ、ファイル及び値を有する。しかし、第1のブロック682Aとは異なり、他のブロックのヘッダ684A~684nのそれぞれは、直前のブロックのハッシュ値を含む。直前のブロックのハッシュ値は、前のブロックのヘッダのハッシュだけであっても、前のブロック全体のハッシュ値であってもよい。残りのブロックのそれぞれに前のブロックのハッシュ値を含めることにより、監査可能で不変の管理の連鎖を確立するために、矢印692で示すように、N番目のブロックから起源ブロック(及び関連付けられた元のファイル)まで、ブロック単位でトレースを実施することができる。
【0072】
本明細書に記載の実施形態は、ハードウェア、プロセッサによって実行されるコンピュータプログラム、ファームウェア又はその組み合わせで実装されてもよい。コンピュータプログラムは、記憶媒体などのコンピュータ可読媒体上で具体化されてもよい。例えば、コンピュータプログラムは、ランダムアクセスメモリ(「RAM」)、フラッシュメモリ、読み取り専用メモリ(「ROM」)、消去可能なプログラム可能読み取り専用メモリ(「EPROM」)、電気的に消去可能なプログラム可能読み取り専用メモリ(「EEPROM」)、レジスタ、ハードディスク、取り外し可能ディスク、コンパクトディスク読み取り専用メモリ(「CD-ROM」)、あるいは当技術分野で知られている任意の他の形態の記憶媒体に存在してもよい。
【0073】
例示的な記憶媒体を、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込み得るように、プロセッサに結合してもよい。これとは別に、記憶媒体はプロセッサに一体化されてもよい。プロセッサ及び記憶媒体は、特定用途向け集積回路(「ASIC」)に存在してもよい。これとは別に、プロセッサ及び記憶媒体は、別個の構成要素として存在してもよい。例えば、
図7は、例示的なコンピュータシステムアーキテクチャ700を示す。このアーキテクチャは、説明したコンポーネントなどのいずれかを表しても、いずれかに統合されてもよい。
【0074】
図7は、本明細書に記載したアプリケーションの実施形態の使用又は機能の範囲に関する任意の制限を示唆することを意図するものではない。いずれにしても、計算ノード700は、本明細書に記載の機能のいずれかを実装したり、及び/又は実施したりしてもよい。
【0075】
計算ノード700には、多数の他の汎用又は専用の計算システム環境又は構成で動作可能であるコンピュータシステム/サーバ702がある。コンピュータシステム/サーバ702での使用に適し得る周知の計算システム、環境及び/又は構成の例には、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、手持ち式又はラップトップ型の装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家電、ネットワークPC、ミニコンピュータシステム、メインフレームコンピュータシステム、システム又は装置のいずれかを含む分散型クラウド計算環境などが挙げられるが、ここに挙げたものに限定されない。
【0076】
コンピュータシステム/サーバ702を、コンピュータシステムによって実行されるプログラムモジュールなどのコンピュータシステム実行可能命令の一般的な文脈で説明してもよい。一般に、プログラムモジュールには、特定のタスクを実行するか、特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などが含まれてもよい。コンピュータシステム/サーバ702は、通信ネットワークを介して連結されたリモート処理装置によってタスクが実行される分散クラウド計算環境にて実施されてもよい。分散型クラウド計算環境では、プログラムモジュールは、メモリ記憶装置を含むローカル及びリモートの両方のコンピュータシステム記憶媒体に配置されてもよい。
【0077】
図7に示すように、クラウド計算ノード700内のコンピュータシステム/サーバ702を、汎用計算装置の形態で示す。コンピュータシステム/サーバ702の構成要素は、1つ又は複数のプロセッサ又は処理ユニット704と、システムメモリ706と、システムメモリ706を含むさまざまなシステム構成要素をプロセッサ704に結合するバスとを含んでもよいが、ここに挙げたものに限定されない。
【0078】
バスは、メモリバス又はメモリコントローラと、周辺バスと、アクセラレイティッドグラフィックスポートと、さまざまなバスアーキテクチャのいずれかを使用するプロセッサ又はローカルバスとを含むいくつかのタイプのバス構造のいずれかの1つ又は複数を表す。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ(ISA)バス、マイクロチャネルアーキテクチャ(MCA)バス、拡張ISA(EISA)バス、Video Electronics Standards Association(VESA)ローカルバス及びPeripheral Component Interconnects(PCI)バスが含まれる。
【0079】
コンピュータシステム/サーバ702は、典型的には、さまざまなコンピュータシステム可読媒体を含む。そのような媒体は、コンピュータシステム/サーバ702によってアクセス可能な任意の利用可能な媒体であり、揮発性媒体及び不揮発性媒体の両方、取り外し可能媒体及び取り外し不可能媒体の両方を含む。システムメモリ706は、一実施形態では、他の図の流れ図を実施する。システムメモリ706は、ランダムアクセスメモリ(RAM)708及び/又はキャッシュメモリ710などの揮発性メモリの形態のコンピュータシステム可読媒体を含むことがある。コンピュータシステム/サーバ702は、他のリムーバブル/非リムーバブル、揮発性/不揮発性のコンピュータシステム記憶媒体をさらに含んでもよい。ほんの一例として、メモリ706は、(図示せず、典型的には「ハードドライブ」と呼ばれる)取り外し不可能で不揮発性の磁気媒体から読み書きするために設けることができる。図示していないが、取り外し可能で不揮発性の磁気ディスク(例えば、「フロッピーディスク」)から読み書きするための磁気ディスクドライブと、CD-ROM、DVD-ROM又はその他の光学媒体などの取り外し可能で不揮発性の光学ディスクから読み書きするための光ディスクドライブと、を設けることができる。そのような場合、それぞれを1つ又は複数のデータ媒体インターフェースによってバスに接続することができる。本明細書でさらに図示し説明するように、メモリ706は、アプリケーションのさまざまな実施形態の機能を実施するように構成されたプログラムモジュールのセット(例えば、少なくとも1つ)を有する少なくとも1つのプログラム製品を含んでもよい。
【0080】
プログラムモジュールのセット(少なくとも1つ)を有するプログラム/ユーティリティは、限定ではなく例として、メモリ706のほか、オペレーティングシステム、1つ又は複数のアプリケーションプログラム、他のプログラムモジュール及びプログラムデータに保存されてもよい。オペレーティングシステム、1つ又は複数のアプリケーションプログラム、他のプログラムモジュール及びプログラムデータ又はその何らかの組み合わせのそれぞれが、ネットワーク構築環境の実装を含んでもよい。プログラムモジュールは、本明細書で説明するアプリケーションのさまざまな実施形態の機能及び/又は方法論を概ね実施する。
【0081】
当業者によって理解されるであろうように、本出願の態様を、システム、方法又はコンピュータプログラム製品として具体化してもよい。このため、本出願の態様が、全体的にハードウェアの実施形態、(ファームウェア、常駐ソフトウェア、マイクロコードなどを含む)全体的にソフトウェアの実施形態、あるいは本明細書ではいずれも、「回路」、「モジュール」又は「システム」と概ね呼ばれ得るソフトウェア及びハードウェアの態様を組み合わせた実施形態の形態をとってもよい。さらに、本出願の態様が、コンピュータ可読プログラムコードが具体化された1つ又は複数のコンピュータ可読媒体で具体化されたコンピュータプログラム製品の形態をとってもよい。
【0082】
コンピュータシステム/サーバ702はこのほか、キーボード、ポインティング装置、ディスプレイ、音声認識モジュールなどを含み得る入出力装置712(入出力アダプタなど)を介して、ユーザがコンピュータシステム/サーバ702と対話することができるようにする1つ又は複数の装置を介して、及び/又はコンピュータシステム/サーバ702が1つ又は複数の他の計算装置と通信することができるようにする任意の装置(例えば、ネットワークカード、モデムなど)を介して、1つ又は複数の外部装置と通信してもよい。そのような通信は、装置712の入出力インターフェースを介して実施され得る。さらにまた、コンピュータシステム/サーバ702は、ネットワークアダプタを介して、ローカルエリアネットワーク(LAN)、一般的なワイドエリアネットワーク(WAN)及び/又は公衆ネットワーク(例えば、インターネット)などの1つ又は複数のネットワークと通信することができる。図示のように、装置712は、バスを介してコンピュータシステム/サーバ702の他のコンポーネントと通信する。図示していないが、他のハードウェア及び/又はソフトウェアコンポーネントをコンピュータシステム/サーバ702と共に使用することがあり得ることを理解されたい。例としては、マイクロコード、装置ドライバ、冗長処理ユニット、外部ディスクドライブアレイ、RAIDシステム、テープドライブ、データ記録記憶システムなどが挙げられるが、ここに挙げたものに限定されない。
【0083】
システム、方法及び非一時的なコンピュータ可読媒体のうちの少なくとも1つの例示的な実施形態を、添付の図面に示し、前述の詳細な説明で説明してきたが、アプリケーションは、開示した実施形態に限定されないが、以下の特許請求の範囲に記載し定義するように、多数の再配置、修正及び置換が可能であることが理解されよう。例えば、さまざまな図のシステムの能力は、本明細書に記載のモジュール又はコンポーネントのうちの1つ又は複数によって実施するか、分散型アーキテクチャで実施することができ、送信機、受信機又は両方の対を含んでもよい。例えば、個々のモジュールによって実施される機能の全部又は一部を、このようなモジュールの1つ又は複数によって実施してもよい。さらに、本明細書で説明する機能は、モジュール又はコンポーネントの内部又は外部のさまざまなイベントに関連して、さまざまな時点で実施されてもよい。このほか、さまざまなモジュール間で送信される情報は、データネットワーク、インターネット、音声ネットワーク、インターネットプロトコルネットワーク、無線装置、有線装置及び/又は複数のプロトコルのうちの少なくとも1つを介してモジュール間で送信されることができる。このほか、モジュールのいずれかによって送受信されるメッセージは、直接送受信されたり、及び/又は他のモジュールの1つ又は複数を介して送受信されたりしてもよい。
【0084】
当業者には、「システム」が、パーソナルコンピュータ、サーバ、コンソール、携帯情報端末(PDA)、携帯電話、タブレット計算装置、スマートフォン又は任意の他の適切な計算装置又は装置の組み合わせとして具体化されることがあり得ることが理解されよう。記載した機能を「システム」によって実施されるものとして提示することは、本出願の範囲を限定することを意図するものでは決してなく、多くの実施形態の一例を提供することを意図するものである。実際、本明細書で開示する方法、システム及び装置を、計算技術と一致する局所化された形態及び分散された形態で実装してもよい。
【0085】
この明細書で説明するシステムの特徴の一部を、その実装の独立性をさらに具体的に強調するために、モジュールとして提示していることに留意されたい。例えば、モジュールを、カスタム超大規模集積(VLSI)回路又はゲートアレイ、論理チップ、トランジスタ又は他の個別部品などの既製の半導体を含むハードウェア回路として実装してもよい。このほか、モジュールを、フィールドプログラム可能ゲートアレイ、プログラム可能アレイ論理、プログラム可能論理装置、グラフィック処理ユニットなどのプログラム可能ハードウェア装置に実装してもよい。
【0086】
このほか、モジュールを、さまざまなタイプのプロセッサによる実行のために、ソフトウェアに少なくとも部分的に実装してもよい。実行可能コードの識別されたユニットには、例えば、オブジェクト、手順又は機能として編成され得るコンピュータ命令の1つ又は複数の物理的ブロック又は論理的ブロックが含まれてもよい。それにもかかわらず、識別されたモジュールの実行ファイルは、物理的に一緒に配置する必要はないが、論理的に結合されるとモジュールを構成し、モジュールの規定の目的を達成するさまざまな場所に保存された異種の命令を含む場合がある。さらに、モジュールを、例えば、データを保存するために使用されるハードディスクドライブ、フラッシュ装置、ランダムアクセスメモリ(RAM)、テープ又は任意の他の媒体であり得るコンピュータ可読媒体に保存してもよい。
【0087】
実際、実行可能コードのモジュールが、単一の命令又は多数の命令であり得ることがあり、いくつかの異なるコードセグメント、異なるプログラム間及びいくつかのメモリ装置に分散することさえある。同じように、運用データを、本明細書ではモジュール内で識別し図示してもよく、任意の適切な形態で具体化し、任意の適切なタイプのデータ構造内に編成してもよい。運用データは、単一のデータセットとして収集されても、異なる記憶装置を含む異なる場所に分散されてもよく、単にシステム又はネットワーク上の電子信号として、少なくとも部分的に存在してもよい。
【0088】
本出願の構成要素は、本明細書で概ね説明し図に示すように、多種多様な異なる構成で配置され設計され得ることが容易に理解されよう。このため、実施形態の詳細な説明は、特許請求される本出願の範囲を限定することを意図するものではなく、本出願の選択された実施形態を単に代表するものである。
【0089】
当業者であれば、本明細書に記載の機能を異なる順序のステップで実施したり、及び/又は開示したものとは異なる構成のハードウェア要素によって実施したりしてもよいことを容易に理解するであろう。このため、本出願をこのような好ましい実施形態に基づいて説明してきたが、特定の修正、変更及び代替構造が明白なものであることは当業者には明らかであろう。
【0090】
本出願の好ましい実施形態を説明してきたが、説明した実施形態は例示にすぎず、本出願の範囲は、添付の特許請求の範囲のみによって、それに対する均等物及び変更(例えば、プロトコル、ハードウェアデバイス、ソフトウェアプラットフォームなど)の全範囲を考慮して、定義されることを理解されたい。
本開示は、以下の態様を含む。
〔態様1〕
満充電のために輸送体に必要とされる第1のエネルギー量を充電ステーションによって判定することと、
前記輸送体が後の時点で前記充電ステーションに返還する第2のエネルギー量を前記充電ステーションによって判定することと、
前記第1のエネルギー量と前記第2のエネルギー量との間の差に等しい充電レベルまで、前記充電ステーションによって、前記輸送体を充電することと、を含む方法。
〔態様2〕
前記第2のエネルギー量と、前記第1のエネルギー量に対する前記第2のエネルギー量の比例配分に基づいて計算された第3のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電することをさらに含む、態様1に記載の方法。
〔態様3〕
前記輸送体が前記第2のエネルギー量を返還するために戻るときの前記輸送体の前記充電ステーションへの予測される往復に基づいてエネルギーの節約量を計算することをさらに含む、態様1に記載の方法。
〔態様4〕
前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供することを更に含み、前記エネルギーの節約量は、前記第2のエネルギー量を放棄する動機として機能する、態様3に記載の方法。
〔態様5〕
前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第2のエネルギー量を判定することをさらに含む、態様1に記載の方法。
〔態様6〕
前記輸送体からの前記第2のエネルギー量の移送に関する確認を受信することを更に含み、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、態様1に記載の方法。
〔態様7〕
前記ブロックチェーン合意に基づいてブロックチェーン上にエネルギー移送関連のトランザクションを記録するためにスマートコントラクトを実行することを更に含む、態様6に記載の方法。
〔態様8〕
充電ステーションのプロセッサと、
機械可読命令が保存されたメモリであって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに、
満充電のために輸送体に必要とされる第1のエネルギー量を判定させ、
後の時点で前記輸送体が前記充電ステーションに返還する第2のエネルギー量を判定させ、
前記第1のエネルギー量と前記第2のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電させる、メモリと、を具備する、システム。
〔態様9〕
前記命令は、前記プロセッサに、更に、前記第2のエネルギー量と、前記第1のエネルギー量に対する前記第2のエネルギー量の比例配分に基づいて計算された第3のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる、態様8に記載のシステム。
〔態様10〕
前記命令は、前記プロセッサに、更に、前記輸送体が前記第2のエネルギー量を返還するために戻るときに、前記輸送体の前記充電ステーションへの予測される往復に基づいて、エネルギーの節約量を計算させる、態様8に記載のシステム。
〔態様11〕
前記命令は、前記プロセッサに、更に、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供させ、前記エネルギーの節約量は、前記第2のエネルギー量を放棄する動機として機能する、態様10に記載のシステム。
〔態様12〕
前記命令は、前記プロセッサに、更に、前記輸送体によるエネルギー返還の履歴データに基づいて計算された機械学習データに基づいて、第2のエネルギー量を判定させる、態様8に記載のシステム。
〔態様13〕
前記命令は、前記プロセッサに、更に、前記輸送体からの前記第2のエネルギー量の移送に関する確認を受信させ、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、態様8に記載のシステム。
〔態様14〕
前記命令は、前記プロセッサに、更に、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる、態様13に記載のシステム。
〔態様15〕
命令を含む非一時的なコンピュータ可読媒体であって、前記命令は、プロセッサによって読み取られると、前記プロセッサに、
満充電のために輸送体に必要とされる第1のエネルギー量を判定することと、
前記輸送体が後の時点で前記充電ステーションに返還する第2のエネルギー量を判定することと、
前記第1のエネルギー量と前記第2のエネルギー量との間の差に等しい充電レベルまで前記輸送体を充電することと、を実施させる、非一時的なコンピュータ可読媒体。
〔態様16〕
プロセッサによって読み取られると、前記プロセッサに、前記第2のエネルギー量と、前記第1のエネルギー量に対する前記第2のエネルギー量の比例配分に基づいて計算された第3のエネルギー量との間の差に等しい充電レベルまで、前記輸送体を前記後の時点で充電させる命令を更に含む、態様15に記載の非一時的なコンピュータ可読媒体。
〔態様17〕
プロセッサによって読み取られると、前記プロセッサに、前記輸送体が前記第2のエネルギー量を返還するために戻るときの前記充電ステーションまでの前記輸送体の予測される往復に基づいて、エネルギーの節約量を計算させる命令を更に含む、態様15に記載の非一時的なコンピュータ可読媒体。
〔態様18〕
プロセッサによって読み取られると、前記プロセッサに、前記エネルギーの節約量を前記充電レベルと共に前記輸送体へ提供させる命令であって、前記エネルギーの節約量が前記第2のエネルギー量を放棄する動機として機能する、命令を更に含む、態様17に記載の非一時的なコンピュータ可読媒体。
〔態様19〕
プロセッサによって読み取られると、前記プロセッサに、前記輸送体からの前記第2のエネルギー量の移送に関する確認を受信させる命令であって、前記確認は、前記輸送体及び前記充電ステーションによって表されるピア間のブロックチェーン合意を含む、命令を更に含む、態様15に記載の非一時的なコンピュータ可読媒体。
〔態様20〕
プロセッサによって読み取られると、前記プロセッサに、スマートコントラクトを実行させて、前記ブロックチェーン合意に基づいてブロックチェーンにエネルギー移送関連のトランザクションを記録させる命令を更に含む、態様19に記載の非一時的なコンピュータ可読媒体。