特許 6876806 ブロックチェーンコンセンサス形成の方法およびデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6876806

(24)【登録日】2021年4月28日

(45)【発行日】2021年5月26日

(54)【発明の名称】ブロックチェーンコンセンサス形成の方法およびデバイス

(51)【国際特許分類】

   G06F 9/50 20060101AFI20210517BHJP

【ＦＩ】

   G06F9/50 150C

【請求項の数】15

【全頁数】23

(21)【出願番号】特願2019-535948(P2019-535948)

(86)(22)【出願日】2018年3月26日

(65)【公表番号】特表2020-509445(P2020-509445A)

(43)【公表日】2020年3月26日

(86)【国際出願番号】CN2018080439

(87)【国際公開番号】WO2018177235

(87)【国際公開日】20181004

【審査請求日】2019年8月26日

(31)【優先権主張番号】201710191996.2

(32)【優先日】2017年3月28日

(33)【優先権主張国】CN

【早期審査対象出願】

(73)【特許権者】

【識別番号】520015461

【氏名又は名称】アドバンスド ニュー テクノロジーズ カンパニー リミテッド

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(74)【代理人】

【識別番号】100205785

【弁理士】

【氏名又は名称】▲高▼橋 史生

(72)【発明者】

【氏名】ハオ・ウ

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 特開２０１６−２１８６３３（ＪＰ，Ａ）

【文献】 特開２０１６−２００９５４（ＪＰ，Ａ）

【文献】 特表２０２０−５１４８６６（ＪＰ，Ａ）

【文献】 特表２０２０−５１０８９２（ＪＰ，Ａ）

【文献】 特表２０２０−５０４９１６（ＪＰ，Ａ）

【文献】 米国特許第０９５２９９２３（ＵＳ，Ｂ１）

【文献】 米国特許出願公開第２０１６／０３４２９７７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１６／０３３００３１（ＵＳ，Ａ１）

【文献】 淵田康之，ブロックチェーンと金融取引の革新，野村資本市場クォータリー，株式会社野村資本市場研究所，２０１５年１１月 １日，第19巻，第2号，(通巻74号)，pp.11〜35

【文献】 アンドレアス・Ｍ・アントノブロス，ビットコインとブロックチェーン 暗号通貨を支える技術，ＮＴＴ出版株式会社，２０１７年 ３月 ７日，初版第6刷，pp.183〜211

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

コンピュータ実施方法であって、
ブロックチェーン内の第1のノードにより、前記ブロックチェーン内の第2のノードから第1のブロックチェーントランザクションを受信するステップであって、前記第2のノードが前記ブロックチェーン内の複数のノードにブロードキャストメッセージを送信し、前記ブロードキャストメッセージが前記第1のブロックチェーントランザクションを含む、ステップと、
前記ブロックチェーン内の前記第1のノードにより、前記ブロックチェーン内の前記第2のノードが前記第1のブロックチェーントランザクションを受信した時間に基づいて、前記第1のブロックチェーントランザクションの対応するハンドリング時間を決定するステップと、
前記ブロックチェーン内の前記第1のノードにより、前記対応するハンドリング時間を含む前記第1のブロックチェーントランザクションをキャッシュに格納するステップであって、前記キャッシュが少なくとも1つの追加のブロックチェーントランザクションを格納しており、前記少なくとも1つの追加のブロックチェーントランザクションの各々が個別のハンドリング時間に関連付けられる、ステップと、
前記ブロックチェーン内の前記第1のノードにより、前記キャッシュ内の少なくとも2つのブロックチェーントランザクションに対してコンセンサス形成が実施される必要があるか否かを決定するステップであって、前記少なくとも2つのブロックチェーントランザクションが少なくとも第1のハンドリング時間および第2のハンドリング時間にそれぞれ関連付けられ、前記第1のハンドリング時間および前記第2のハンドリング時間は、前記第2のノードが前記少なくとも2つのブロックチェーントランザクションを受信した時間に基づく時間である、ステップと、
前記コンセンサス形成が実施される必要があるとの決定に応答して、前記ブロックチェーン内の前記第1のノードにより、前記少なくとも2つのブロックチェーントランザクションに関連付けられた少なくとも前記第1のハンドリング時間および前記第2のハンドリング時間に従って、前記コンセンサス形成を実施すべき前記少なくとも2つのブロックチェーントランザクションを選択するステップと、
前記ブロックチェーン内の前記第1のノードにより、少なくとも前記第1のハンドリング時間および前記第2のハンドリング時間に従って、前記少なくとも2つのブロックチェーントランザクションに対して前記コンセンサス形成を実施するステップと
を含むコンピュータ実施方法。

【請求項2】

前記第1のブロックチェーントランザクションの対応するハンドリング時間を決定する前記ステップの後に、
前記ブロックチェーン内の前記第1のノードにより、前記第1のブロックチェーントランザクションおよび前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を、前記ブロックチェーン内の別のノードにブロードキャストするステップ
をさらに含む、請求項1に記載のコンピュータ実施方法。

【請求項3】

前記第1のブロックチェーントランザクションの対応するハンドリング時間を決定する前記ステップが、
前記第2のノードにおいて決定されたローカルタイムスタンプに基づくものであり、前記ローカルタイムスタンプが、前記ブロックチェーン内の前記第2のノードが前記第1のブロックチェーントランザクションを受信したローカル時間である、
請求項1に記載のコンピュータ実施方法。

【請求項4】

前記コンセンサス形成を実施すべき前記少なくとも2つのブロックチェーントランザクションを選択する前記ステップが、前記第1のブロックチェーントランザクションが格納されることとなるブロックチェーンブロックのブロック容量を満足させることにさらに基づく、請求項1に記載のコンピュータ実施方法。

【請求項5】

前記第1のブロックチェーントランザクションが、サービス属性、サービス識別子、バージョン識別子、公開鍵、シグネチャ、サービス情報、およびブロック識別子のうちの少なくとも1つを含む、請求項1に記載のコンピュータ実施方法。

【請求項6】

動作を実行するためにコンピュータシステムによって実行可能な1つまたは複数の命令を記録した、コンピュータ可読非一時的媒体であって、
前記動作が、
ブロックチェーン内の第1のノードにより、前記ブロックチェーン内の第2のノードから第1のブロックチェーントランザクションを受信することであって、前記第2のノードが前記ブロックチェーン内の複数のノードにブロードキャストメッセージを送信し、前記ブロードキャストメッセージが前記第1のブロックチェーントランザクションを含む、ことと、
前記ブロックチェーン内の前記第1のノードにより、前記ブロックチェーン内の前記第2のノードが前記第1のブロックチェーントランザクションを受信した時間に基づいて、前記第1のブロックチェーントランザクションの対応するハンドリング時間を決定することと、
前記ブロックチェーン内の前記第1のノードにより、前記対応するハンドリング時間を含む前記第1のブロックチェーントランザクションをキャッシュに格納することであって、前記キャッシュが少なくとも1つの追加のブロックチェーントランザクションを格納しており、前記少なくとも1つの追加のブロックチェーントランザクションの各々が個別のハンドリング時間に関連付けられる、ことと、
前記ブロックチェーン内の前記第1のノードにより、前記キャッシュ内の少なくとも2つのブロックチェーントランザクションに対してコンセンサス形成が実施される必要があるか否かを決定することであって、前記少なくとも2つのブロックチェーントランザクションが少なくとも第1のハンドリング時間および第2のハンドリング時間にそれぞれ関連付けられ、前記第1のハンドリング時間および前記第2のハンドリング時間は、前記第2のノードが前記少なくとも2つのブロックチェーントランザクションを受信した時間に基づく時間である、ことと、
前記コンセンサス形成が実施される必要があるとの決定に応答して、前記ブロックチェーン内の前記第1のノードにより、前記少なくとも2つのブロックチェーントランザクションに関連付けられた少なくとも前記第1のハンドリング時間および前記第2のハンドリング時間に従って、前記コンセンサス形成を実施すべき前記少なくとも2つのブロックチェーントランザクションを選択することと、
前記ブロックチェーン内の前記第1のノードにより、少なくとも前記第1のハンドリング時間および前記第2のハンドリング時間に従って、前記少なくとも2つのブロックチェーントランザクションに対して前記コンセンサス形成を実施することと
を含む、コンピュータ可読非一時的媒体。

【請求項7】

前記動作が、
前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を決定した後に、前記ブロックチェーン内の前記第1のノードにより、前記第1のブロックチェーントランザクションおよび前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を、前記ブロックチェーン内の別のノードにブロードキャストすること
をさらに含む、請求項6に記載のコンピュータ可読非一時的媒体。

【請求項8】

前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を決定することが、
前記第2のノードにおいて決定されたローカルタイムスタンプに基づくものであり、前記ローカルタイムスタンプが、前記ブロックチェーン内の前記第2のノードが前記第1のブロックチェーントランザクションを受信したローカル時間である、
請求項6に記載のコンピュータ可読非一時的媒体。

【請求項9】

前記コンセンサス形成を実施すべき前記少なくとも2つのブロックチェーントランザクションを選択することが、前記第1のブロックチェーントランザクションが格納されることとなるブロックチェーンブロックのブロック容量を満足させることにさらに基づく、請求項6に記載のコンピュータ可読非一時的媒体。

【請求項10】

前記第1のブロックチェーントランザクションが、サービス属性、サービス識別子、バージョン識別子、公開鍵、シグネチャ、サービス情報、およびブロック識別子のうちの少なくとも1つを含む、請求項6に記載のコンピュータ可読非一時的媒体。

【請求項11】

コンピュータ実装システムであって、
1つまたは複数のコンピュータと、
前記1つまたは複数のコンピュータに相互動作可能に接続され、1つまたは複数の命令を格納したマシン可読非一時的媒体を有した、1つまたは複数のコンピュータメモリデバイスと
を備え、
前記1つまたは複数の命令は、前記1つまたは複数のコンピュータによって実行されると、前記1つまたは複数のコンピュータに1つまたは複数の動作を行わせ、
前記1つまたは複数の動作が、
ブロックチェーン内の第1のノードにより、前記ブロックチェーン内の第2のノードから第1のブロックチェーントランザクションを受信することであって、前記第2のノードが前記ブロックチェーン内の複数のノードにブロードキャストメッセージを送信し、前記ブロードキャストメッセージが前記第1のブロックチェーントランザクションを含む、ことと、
前記ブロックチェーン内の前記第1のノードにより、前記ブロックチェーン内の前記第2のノードが前記第1のブロックチェーントランザクションを受信した時間に基づいて、前記第1のブロックチェーントランザクションの対応するハンドリング時間を決定することと、
前記ブロックチェーン内の前記第1のノードにより、前記対応するハンドリング時間を含む前記第1のブロックチェーントランザクションをキャッシュに格納することであって、前記キャッシュが少なくとも1つの追加のブロックチェーントランザクションを格納しており、前記少なくとも1つの追加のブロックチェーントランザクションの各々が個別のハンドリング時間に関連付けられる、ことと、
前記ブロックチェーン内の前記第1のノードにより、前記キャッシュ内の少なくとも2つのブロックチェーントランザクションに対してコンセンサス形成が実施される必要があるか否かを決定することであって、前記少なくとも2つのブロックチェーントランザクションが少なくとも第1のハンドリング時間および第2のハンドリング時間にそれぞれ関連付けられ、前記第1のハンドリング時間および前記第2のハンドリング時間は、前記第2のノードが前記少なくとも2つのブロックチェーントランザクションを受信した時間に基づく時間である、ことと、
前記コンセンサス形成が実施される必要があるとの決定に応答して、前記ブロックチェーン内の前記第1のノードにより、前記少なくとも2つのブロックチェーントランザクションに関連付けられた少なくとも前記第1のハンドリング時間および前記第2のハンドリング時間に従って、前記コンセンサス形成を実施すべき前記少なくとも2つのブロックチェーントランザクションを選択することと、
前記ブロックチェーン内の前記第1のノードにより、少なくとも前記第1のハンドリング時間および前記第2のハンドリング時間に従って、前記少なくとも2つのブロックチェーントランザクションに対して前記コンセンサス形成を実施することと
を含む、コンピュータ実装システム。

【請求項12】

前記1つまたは複数の動作が、
前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を決定した後に、前記ブロックチェーン内の前記第1のノードにより、前記第1のブロックチェーントランザクションおよび前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を、前記ブロックチェーン内の別のノードにブロードキャストすること
をさらに含む、請求項11に記載のコンピュータ実装システム。

【請求項13】

前記第1のブロックチェーントランザクションの前記対応するハンドリング時間を決定することが、
前記第2のノードにおいて決定されたローカルタイムスタンプに基づくものであり、前記ローカルタイムスタンプが、前記ブロックチェーン内の前記第2のノードが前記第1のブロックチェーントランザクションを受信したローカル時間である、
請求項11に記載のコンピュータ実装システム。

【請求項14】

前記コンセンサス形成を実施すべき前記少なくとも2つのブロックチェーントランザクションを選択することが、前記第1のブロックチェーントランザクションが格納されることとなるブロックチェーンブロックのブロック容量を満足させることにさらに基づく、請求項11に記載のコンピュータ実装システム。

【請求項15】

前記第1のブロックチェーントランザクションが、サービス属性、サービス識別子、バージョン識別子、公開鍵、シグネチャ、サービス情報、およびブロック識別子のうちの少なくとも1つを含む、請求項11に記載のコンピュータ実装システム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、情報技術の分野に関し、詳細には、ブロックチェーンコンセンサス形成の方法およびデバイスに関する。

【背景技術】

【0002】

情報技術の発展に伴い、人々は、ブロックチェーン技術の開放性、耐タンパー性、および分散化などの利点のため、ブロックチェーン技術に注目している。既存のブロックチェーン技術は、分散化を特徴とするので、ブロックチェーン内で実行されたサービスがブロックチェーン内に格納される(すなわち、ブロックチェーン内にデータを記録するためにチェーニング動作が実施される)前に、ブロックチェーン内の各ノードは、そのサービスに対応するサービスデータ(例えば、そのサービスに対して処理が実施された後に取得された結果)に対して、コンセンサス形成を実施する必要がある。

【0003】

通常、ブロック容量(例えば予め決定された容量)は、ブロックチェーン内で限られているが、時に、ノード内のコンセンサス形成を待つサービスデータによって占有される空間が、ブロック容量よりも大きいことがある。したがって、既存の技術では、コンセンサス形成を開始するノードはさらに、格納されているサービスデータから一部のサービスデータを選択して、選択したサービスデータに対してコンセンサス形成を実施する必要がある。

【0004】

ノードは通常、サービスデータ内のある種の属性のデータ(例えば取引データ)に対応する値(例えば取引金額)に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択する。

【0005】

ブロックチェーン内の各ノードは、ノード内に格納されている複数のサービスデータの指定された属性に対応する値(例えば取引金額)に基づいて降順に、コンセンサス形成を実施すべき対象となる複数のサービスデータのリストを決定する。ブロックチェーン内の各ノードは、ノード内に格納されているとともにコンセンサス形成を実施すべき対象となる複数のサービスデータのリスト内にある、複数のサービスデータのシーケンスに基づいて、コンセンサス形成が実施される必要のあるサービスデータとしてのサービスデータを選択して、選択したサービスデータに対して実施されるコンセンサス形成を完了することができる。

【0006】

しかし、従来の方法には次の欠点がある。コンセンサス形成を実施すべき対象となるサービスデータのリスト内にある、コンセンサス形成を実施すべき対象となるサービスは、サービスデータ内の指定された属性に対応する値に基づいて並べられるので、値のより小さなサービスデータは、相対的に長い時間にわたってコンセンサス形成を待つ。その結果、サービスデータの相対的に低い処理効率が生じてしまう。

【発明の概要】

【課題を解決するための手段】

【0007】

本出願の実施態様は、既存のブロックチェーンコンセンサス形成方法では、一部のサービスデータの処理効率が、サービスデータが相対的に長い時間にわたってコンセンサス形成を待つので相対的に低い、という問題を軽減するための、ブロックチェーンコンセンサス形成方法を提供する。

【0008】

本出願の実施態様は、既存のブロックチェーンコンセンサス形成方法では、一部のサービスデータの処理効率が、サービスデータが相対的に長い時間にわたってコンセンサス形成を待つので相対的に低い、という問題を軽減するための、ブロックチェーンコンセンサス形成装置を提供する。

【0009】

本出願の一実施態様は、ブロックチェーンコンセンサス形成方法を提供し、方法は、ブロックチェーン内のノードによって、サービスデータを受信し、そのサービスデータのハンドリング時間を決定することと、ノードによって、ハンドリング時間を含むサービスデータを格納することと、サービスデータに対してコンセンサス形成が実施される必要のあるときに、ノードによって、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択することと、コンセンサス形成を実施すべき対象となる選択したサービスデータに対してコンセンサス形成を実施することとを含む。

【0010】

本出願の一実施態様は、ブロックチェーンコンセンサス形成装置を提供し、装置は、サービスデータを受信し、そのサービスデータのハンドリング時間を決定するように構成された決定モジュールと、ハンドリング時間を含むサービスデータを格納するように構成された格納モジュールと、サービスデータに対してコンセンサス形成が実施される必要のあるときに、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択するように構成された選択モジュールと、コンセンサス形成を実施すべき対象となる選択したサービスデータに対してコンセンサス形成を実施するように構成されたコンセンサス形成モジュールとを含む。

【0011】

本出願の実施態様において使用される、先に説明した技術的解決策のうちの少なくとも1つが、以下の有益な効果を達成することができる。

【0012】

サービスデータを受信すると、ブロックチェーン内のノードが、サービスデータのハンドリング時間を決定して、ハンドリング時間を含むサービスデータを格納し、それによって、サービスデータに対してコンセンサス形成が実施される必要のあるときに、ノードは、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択して、選択したサービスデータに対してコンセンサス形成を実施することができる。本出願において提供される方法によれば、コンセンサス形成を実施すべき対象となるサービスデータは、もはやサービスデータ内のある種の属性に対応する値に基づいて選択されず、サービスデータをハンドリングするノードによってサービスデータをハンドリングするハンドリング時間に基づいて選択される、ということが分かる。したがって、サービスデータがコンセンサス形成を待つ時間が、相対的に平衡することが実質的に確実になり、既存の技術における、一部のサービスデータが相対的に長い時間にわたってコンセンサス形成を待つという問題を軽減することができ、サービスデータの処理効率が実質的に向上し、ブロックチェーンの運用上のパフォーマンスが向上する。

【0013】

ここで説明する添付の図面は、本出願のさらなる理解を提供することが意図されており、本出願の一部をなす。本出願の例示的実施形態およびその説明は、本出願について説明することが意図されており、本出願に対する制限とはならない。

【図面の簡単な説明】

【0014】

【図1】本出願の一実施形態による、ブロックチェーンコンセンサス形成プロセスを示す図である。

【図2】本出願の一実施形態による、ブロックチェーンコンセンサス形成装置を示す概略構造図である。

【発明を実施するための形態】

【0015】

本出願の目的、技術的解決策、および利点をより明確にするために、以下では、本出願の技術的解決策について、本出願の特定の実施形態に即し、本出願の添付の図面を参照して、明確かつ包括的に説明する。当然ながら、説明する実施形態は、本出願の実施形態の全てではなく、一部にすぎない。当業者によって、本出願の実施形態に基づいて、創造的な努力なしに取得される他の実施形態はいずれも、本出願の保護範囲に含まれるものとする。

【0016】

既存のブロックチェーン技術では、ブロックチェーン内のデータが、ブロックチェーンネットワーク内のブロックチェーンノード(以下では略してノードと呼ぶ)によって共同で維持される。サービス要求を受信すると、ノードは通常、そのサービス要求に対応するサービスデータをブロック内に、キャッシュ、コンセンサス形成、および格納、という3つのステップを通じて格納し、そのブロックに対してチェーニング動作が実施されると、サービスデータがそのノードに対応するブロックチェーン内に格納される。ブロックチェーンネットワーク内の大多数のノードが、それぞれに対応するノードのブロックチェーンデータ内にサービスデータを格納しているとき、そのサービスデータは、それらのノードによって共同で維持されているブロックチェーンデータ内に格納されていると見なすことができる。

【0017】

コンセンサス形成は、必須ステップであり、プルーフオブワーク(PoW)メカニズム、プラクティカルビザンチンフォールトトレランス(PBFT)メカニズム、およびプルーフオブステークメカニズムなどのコンセンサスメカニズムが、現在使用されている。ここでは説明のために、プルーフオブワークメカニズムを一例として使用する。

【0018】

ノードは最初に、ユーザによって送信されたサービス要求を受信することができ、ここで、サービス要求はサービスデータを含んでおり、サービス要求は、ユーザによってノードに直接投入することができ、ノードは、ブロックチェーンネットワーク内の別のノードによってブロードキャストされたサービス要求を受信することもできる。どのようにノードがサービス要求を受信するかは、サービスの実行に影響を及ぼさない。

【0019】

その後、ノードは、対応するサービスデータをサービス要求に基づいて決定することができる。ノードが対応するサービスデータをサービス要求に基づいて決定するプロセスは、ノードがサービス要求をハンドリングするプロセスと呼ぶことができ、サービスデータを決定するための方法は、具体的事例によって異なってよい。例えば、一般的なサービス要求内に含まれるサービスデータは、サービス内で実行される必要のある内容を含む。例えば、取引サービス要求の場合、取引サービス要求は、支払人住所、支払人残高、支払金額、および受取人住所などの情報を含み、サービス要求を受信するノードは、サービスデータをサービス要求に基づいて直接決定することができる。別の例を挙げると、一般的なサービス要求は、スマートコントラクトに関する命令などのサービスデータをさらに含むことができる。したがって、サービス要求をハンドリングするとき、ノードはさらに、サービス要求内の異なるサービスデータに基づいてサービス処理を実施して、サービス処理の結果を取得する必要のある場合がある。したがって、サービスデータを決定するとき、サービス処理の結果もまた、サービスデータとして使用することができる。ノードは、サービス要求内に含まれるサービスデータと、サービス処理の結果の両方を、サービス要求に対応するサービスデータとして使用することもできる。サービスデータ内に含まれる内容は、そのデータがサービス要求に対応し、かつブロックチェーンデータ内に格納される必要があることを条件として、ブロックチェーンの構成によって異なってよい。したがって、そのデータは、サービスデータと見なすことができる。

【0020】

ブロックチェーンネットワーク内のノードを、サービス要求に関するハンドリングノードと非ハンドリングノードに分けることができることに留意されたい。ハンドリングノードは、ユーザまたは別のデバイスによって送信されたサービス要求を受信するノードである。非ハンドリングノードは、別のノードからブロードキャスト方式でサービス要求を取得するノードである。

【0021】

決定されたサービスデータが、コンセンサス形成が実施されたブロックチェーンデータ内に格納されていないとき、そのサービスデータは、コンセンサス形成を実施すべき対象となるサービスデータであり、ノードのキャッシュ内に格納することができる。

【0022】

次いで、コンセンサス形成を実施すべき対象となるサービスデータを決定した後、ノードは、コンセンサス形成を実施すべき対象となるサービスデータを、ブロックチェーンネットワーク内の別のノードにブロードキャストすることができ、すなわち、コンセンサス形成を実施すべき対象となるサービスデータを、ブロックチェーンネットワーク内の他のノードに同期させることができる。したがって、ブロックチェーンネットワーク内の各ノードは、コンセンサス形成を実施すべき対象となるとともにブロードキャスト方式で送信されたサービスデータを受信することができる。コンセンサス形成が後に実施されるとき、ブロックチェーンネットワーク内の各ノードは、コンセンサス形成を実施すべき対象となるサービスデータに対してコンセンサス形成を実施することができる。

【0023】

最後に、ブロックチェーンネットワーク内の各ノードは、ブロックチェーンのコンセンサスメカニズムに基づいて、コンセンサス形成を開始するノードを決定することができ、コンセンサス形成を開始するノードが、コンセンサス形成を実施すべき対象となるサービスデータを、コンセンサス形成を実施すべき対象となるとともにそのノード内に格納されているサービスデータから選択する。次いで、ブロックチェーンネットワーク内の各ノードは、ブロックチェーンのコンセンサスメカニズムに基づいて、コンセンサス形成を実施すべき対象となるとともにコンセンサス形成を開始するノードによって選択されたサービスデータに対してコンセンサス形成を実施することができる。

【0024】

コンセンサス形成を実施すべき対象となるとともにコンセンサス形成を開始するノードによって送信されたサービスデータに対してコンセンサス形成を実施するとき、ブロックチェーンネットワーク内の各ノードは、コンセンサス形成を実施すべき対象となる受信したサービスデータが、コンセンサス形成を実施すべき対象となるとともにノードのキャッシュ内にある複数のサービスデータのリスト内に格納されているかどうかを判定することができる。コンセンサス形成を実施すべき対象となる受信したサービスデータが、コンセンサス形成を実施すべき対象となるとともにノードのキャッシュ内にある複数のサービスデータのリスト内に格納されているとの判定に応答して、コンセンサス形成を実施すべき対象となる受信したサービスに対するコンセンサス形成は成功していると決定することができ、コンセンサス形成を実施すべき対象となるサービスデータを記録する新たなブロックが、ノードによって維持されるブロックチェーンデータ内に格納される。そうでない場合、新たなブロックは格納されない。

【0025】

本出願の実施形態において提供される技術的解決策については以下で、添付の図面を参照して詳細に説明する。

【0026】

図1は、本出願の一実施形態による、ブロックチェーンコンセンサス形成プロセスを示しており、このプロセスは、以下のステップを含むことができる。

【0027】

S101:ブロックチェーン内のノードが、サービスデータを受信して、そのサービスデータのハンドリング時間を決定する。

【0028】

ブロックチェーンネットワーク内には、通常、サービスノードとコンセンサスノードの2つのタイプのノードがある。サービスノードは通常、サービス要求を開始するように構成され、必須ノードではない。サービスノードが完全なブロックチェーンデータを格納するかどうかは、ブロックチェーンネットワークの構築状態に基づいて決定することができる。一部のブロックチェーンネットワーク内には、サービスノードがないことがある。コンセンサスノードは、ブロックチェーンネットワーク内の必須ノードであり、ブロックチェーンのコンセンサスメカニズムに基づいて、サービス要求を受信してコンセンサス形成を開始するか、または別のコンセンサスノードによって送信されたコンセンサス提案(consensus proposal)を受信するように構成される。コンセンサス形成が実施されたサービスデータが、ブロックチェーンのブロック内に格納される。本出願の本実施形態において説明するノードは、ブロックチェーンネットワーク内のコンセンサスノードと見なすことができ、このノードは、サービス要求を受信し、受信したサービスデータをサービス要求に基づいて決定することができる。

【0029】

ノードは、端末デバイス、例えば、モバイル電話、パーソナルコンピュータ、またはタブレットコンピュータなどのデバイスとすることができる。あるいは、ノードは、サーバであってもよく、サーバは、デバイスがブロックチェーンネットワークのノードとしてサービス要求を受信し、かつコンセンサス形成を開始できることを条件として、単独のデバイスであってもよく、複数のデバイスを含むシステムであってもよい。実施形態は、本出願では限定されない。

【0030】

加えて、既存の技術では、ブロックチェーンにおけるサービス要求は通常、それには限定されないが、表1に示すサービスデータを含む。

【0031】

【表1】

【0032】

表1は、サービス属性および対応する内容を示しており、対応する内容は、サービス要求内のサービスデータ内に含まれていてよく、すなわち、サービスデータは、他の内容をさらに含むということである。実施形態は、ここでは限定されない。バージョン属性は、説明のための一例として使用されている。バージョン属性に対応する内容は、サービス要求内に含まれていてもよく(すなわちクライアントソフトウェアまたはサービス要求を送信するノードによって書き込まれてもよく)、ノードによって、サービス要求に対してサービス処理を実施する後続のプロセスにおいて決定されて、サービスデータに対応するバージョン属性に追加されてもよい。別の例を挙げると、サービスに対応するブロック識別子に対応する内容は、ノードがサービス要求に対応するサービスデータをブロックチェーンの新たなブロック内に格納することができると決定したときの、新たなブロックの決定されたハッシュ値とすることができる。ノードがサービス要求を受信したとき、その属性の内容は空であってよく、具体的内容はノードによる書込みを待つことができる。

【0033】

加えて、サービス識別子は、サービス内容のダイジェストとすることもでき、ブロックチェーン内のサービスイニシエータによって決定されるグローバルな一意識別子とすることもでき、ノードがサービス要求をハンドリングするときにノードによって決定されるサービスデータの識別子とすることもできる。サービス識別子は、既存の技術における方法を使用して決定され得る。サービスデータをブロックチェーンデータ内で一意に決定することができることを条件として、実実施態は、本出願では限定されない。

【0034】

さらに、本出願の本実施形態では、サービス要求を受信した後に、ノードが、サービス要求に対応するサービスデータをサービス要求に基づいて決定する(すなわちサービス要求をハンドリングする)ことができ、それによって、後に、コンセンサス形成を実施すべき対象となるサービスデータをコンセンサス形成のために選択するとき、サービスデータをブロックチェーンデータの新たなブロック内に、コンセンサス形成を実施すべき対象となるサービスデータとして格納するかどうか(すなわち、チェーニング動作を実施するかどうか)を決定することができる。

【0035】

さらに、コンセンサス形成を後にサービスデータに対して実施するときに、サービスデータを、コンセンサス形成のために、コンセンサス形成を開始するノードによって選択することが、サービスデータ内の一部の属性のリソース量のため影響を受ける、という問題を軽減することができる。本出願の本実施形態では、サービス要求をハンドリングする(例えば、コンセンサス形成を実施すべき対象となるとともにサービス要求に対応するサービスデータを決定する)とき、ノードは、ノードのローカルタイムスタンプを決定し、そのローカルタイムスタンプを、コンセンサス形成を実施すべき対象となるサービスデータのハンドリング時間として使用することができる。

【0036】

サービス要求について、通常は、そのサービス要求をハンドリングするただ1つのノードがある。したがって、ノードによってサービス要求をハンドリングするときに決定される、コンセンサス形成を実施すべき対象となる対応するサービスデータのハンドリング時間も、ブロックチェーンデータ内で一意である。加えて、ハンドリング時間は、サービス要求に対応するサービスデータの内容によって異ならない。加えて、ハンドリング時間は、ノードがサービス要求をハンドリングするときに決定されるので、コンセンサス形成を実施すべき対象となるサービスデータをブロードキャスト方式で受信する別のノードが、コンセンサス形成の間に、コンセンサス形成を実施すべき対象となるサービスデータを受信した時間が異なるため異なる選択結果を決定するということはない。したがって、コンセンサス形成を実施すべき対象となるサービスデータのハンドリングタイムスタンプは影響を受けにくい(例えばサービス内容およびネットワーク遅延)。

【0037】

本出願の本実施形態では、ノードは、サービス要求に対応するサービスデータのハンドリング時間として、ノードがサービス要求を受信したときのノードのローカル時間に対応するタイムスタンプを使用することもできる。あるいは、サービスデータのタイムスタンプが、サービス要求を受信するノードによって決定される、すなわちブロックチェーンデータ内のサービスデータのタイムスタンプがただ1つのノードによって決定され得ることを条件として、ノードは、サービスデータのタイムスタンプを別の方式で決定することもできる(例えばサービスデータを受信したときに、ノードがそのサービスデータに対して処理を実施して、処理結果を取得し、処理結果の生成時間をそのサービスデータのハンドリング時間として決定する)。

【0038】

加えて、上で説明したように、異なるブロックチェーンまたは異なるサービス要求について、サービス要求に対応するサービスデータは、スマートコントラクトに関する動作命令などのデータをさらに含んでもよいので、ノードはさらに、サービスデータに基づいてサービス処理を実施して、サービス処理結果を取得する必要のある場合がある。したがって、サービスのハンドリング時間はさらに、ノードがサービス要求(またはサービス要求内のサービスデータ)に基づいてサービス処理を実施した後にサービス処理結果を取得したときの、ノードのローカルタイムスタンプとすることもできる。

【0039】

さらに、ノードによって決定されるハンドリング時間の精度が相対的に低い、例えば秒という時間精度レベルである場合、ノードが複数のサービス要求を1秒以内にハンドリングするとき、1秒以内にハンドリングされる複数のサービス要求の各々に対応するサービスデータは、同一ハンドリング時間を有する。結果として、コンセンサス形成を実施すべき対象となるサービスデータを後に選択することが困難となり得る。したがって、複数のサービスデータが同一ハンドリング時間を有する確率を下げるために、本出願の本実施形態では、より高い精度をハンドリング時間に与えることができ、例えば、ハンドリング時間はミリ秒精度で決定される。具体的には、ハンドリング時間は、要員によって、実際の利用の必要性に基づいて設定することができる。例えば、ブロックチェーンネットワーク内の各ノードは、平均して毎分、サービス要求を受信する。したがって、ハンドリング時間の時間精度は、相対的に低く設定することができる。

【0040】

S102:ノードが、ハンドリング時間を含むサービスデータを格納する。

【0041】

本出願の本実施形態では、サービスデータのハンドリング時間を決定した後に、ノードは、ハンドリング時間を含むサービスデータを格納する、例えばハンドリング時間を含むサービスデータをノードのローカルキャッシュ内に格納することができ、それによって、コンセンサス形成が後に実施される必要のあるときに、そのサービスデータに対してコンセンサス形成を実施することができる。

【0042】

ノードは、サービスデータに、ステップS101において決定されたサービスデータのハンドリング時間を追加することができる。サービスデータの属性内にすでにタイムスタンプ属性があり、タイムスタンプ属性の内容が空である場合、サービスデータの決定されたハンドリング時間がそのタイムスタンプ属性に書き込まれる。サービスデータのオリジナルのタイムスタンプ属性にデータが書き込まれている場合、またはサービスデータ内にタイムスタンプ属性がない場合、ノードは、そのサービスデータに関する新たな「ハンドリング時間」属性を追加することができ、ステップS101において決定されたサービスデータのハンドリング時間が、「ハンドリング時間」属性に書き込まれる。

【0043】

すなわち、本出願の本実施形態では、ノードがサービスデータにハンドリングタイムスタンプを追加するとき、ノードは、サービスデータに関するハンドリング時間属性を追加して、サービスデータのハンドリング時間の値をハンドリング時間属性の内容として使用することができ、それによって、サービスデータがハンドリング時間を含む。例えば、表1に示すサービスデータを一例として使用する。ノードはこのサービスデータを、表2に示すサービスデータに更新することができる。

【0044】

【表2】

【0045】

本出願の本実施形態におけるステップS101において説明したように、ハンドリング時間は、ノードがサービス処理を実施した後でサービス処理結果を決定した時間とすることもできる。したがって、本出願におけるステップS102を実施する前に、ノードはさらに、実際の利用状態に基づいて、サービス要求および/またはサービスデータを使用してサービス処理動作を実施することができる。サービス処理は、既存のブロックチェーン技術における、ノードによってサービスを処理するための方法を使用して実施することができるので、本出願では詳細は省略する。

【0046】

その上、ノードはさらに、ノードのキャッシュ内に、コンセンサス形成を待つ、ハンドリング時間を含むサービスデータを格納することができる。

【0047】

具体的には、ハンドリング時間を含むサービスデータを格納するとき、ノードは、ハンドリング時間を含むサービスデータを、コンセンサス形成を実施すべき対象となるサービスデータのプールの形でノードのキャッシュ内に格納するか、またはハンドリング時間を含むサービスデータを、リストの形でノードのキャッシュ内に格納することができる。ハンドリング時間を含むサービスデータを格納するための方法は、本出願では限定されない。

【0048】

S103:サービスデータに対してコンセンサス形成が実施される必要のあるときに、ノードが、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択して、コンセンサス形成を実施すべき対象となる選択したサービスデータに対してコンセンサス形成を実施する。

【0049】

本出願の本実施形態では、サービスデータに対してコンセンサス形成が実施される必要があると決定されると、コンセンサスメカニズムに関わらず、ブロックチェーン内の各ノードが、サービスデータのハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを一様に選択する。したがって、コンセンサス形成が実施されるときに同一サービスデータが使用されることが確実になり得る。

【0050】

本出願の本実施形態において説明したハンドリング時間をタイムスタンプと理解することができることに留意されたい。タイムスタンプは、ノードがサービス要求をハンドリングするときに、サービス要求に関してノードによって生成されるタイムスタンプとすることもでき、受信したサービス要求をノードが処理した後で生成されるタイムスタンプとすることもできる。実施形態は、ここでは限定されない。

【0051】

ノードは、格納されている複数のサービスデータのハンドリング時間の時間シーケンスに基づいて、コンセンサス形成を実施すべき対象となるサービスデータをコンセンサス形成のために選択することができる。

【0052】

具体的には、ノードのキャッシュは、複数のサービスデータを格納することができ、複数のサービスデータは、該ノードによって、サービス要求を受信することによって決定されたサービスデータ、およびブロックチェーンネットワーク内の別のノードによって該ノードに同期されるとともに該ノードによってブロードキャスト方式で受信されたサービスデータ(すなわち、別のノードによって決定された、コンセンサス形成を実施すべき対象となるサービス)を含む。該ノードによって決定されたサービスデータのハンドリング時間は、該ノードによって決定され、別のノードによって決定されたサービスデータのハンドリング時間は、該ノードによって決定されるのではなく、そのサービスデータに対応するサービス要求をハンドリングする別のノードによって決定される。

【0053】

ノード内に格納されている複数のサービスデータはいずれも、対応するハンドリング時間を含み、かつサービスデータは通常、異なるハンドリング時間を有するので、本出願の本実施形態では、ノードは最初に、複数のサービスデータを、複数のサービスデータのハンドリング時間の時間シーケンスに基づいてソートすることができる。

【0054】

次いで、ノードは、新たなブロックのブロック容量を、ブロックチェーンのコンセンサスメカニズムに基づいて決定し、さらに、そのブロック容量に基づいて、新たなブロック内に記録することのできるサービスデータ量を決定することができる。ブロックチェーンデータ内に記録されるデータによって占有される格納空間を低減させるために、サービスデータがブロック内に記録される前に、サービスデータのダイジェストが最初に計算され、サービスデータのダイジェストがブロック内に記録される。したがって、サービスデータ量を決定するとき、ノードは、サービスデータのダイジェストの占有空間およびブロック容量に基づいて、記録することのできるサービスデータ量を決定することができる。ノードによって記録することのできるサービスデータ量を決定するための方法は、本出願では限定されず、実際の利用の必要性に基づいて、コンセンサスメカニズムを構成することによって決定することができる。

【0055】

さらに、ノードは、コンセンサス形成のために決定されたサービスデータ量、および複数のソートされたサービスデータのシーケンスに基づいて、コンセンサス形成を実施すべき対象となるサービスデータとしてのサービスデータ量を選択することができる。

【0056】

コンセンサス形成を実施すべき対象となる同一サービスデータは、ブロックチェーン内の各ノードにおいて同一タイムスタンプを有するので、コンセンサス形成を実施すべき対象となるとともにブロックチェーンネットワーク内の別々のノードによって同時に決定された複数のサービスデータは、同一シーケンス内に並べられる。したがって、ブロックチェーンネットワーク内の別々のノードがコンセンサス形成を同時に開始する場合、別々のノードがコンセンサス形成を実施すべき対象となる同一サービスデータを選択する確率は、相対的に高い。

【0057】

例えば、ブロックチェーンネットワーク内のノードAについて、ノードAのキャッシュ内に格納されているサービスデータが表3に示されていると仮定されたい。

【0058】

【表3】

【0059】

サービス1およびサービス3は、ノードAによって、サービス要求をハンドリングすることによって決定されたサービスであり、サービス2は、ノードBによってノードAに送信されたサービスデータであり、サービス4は、ノードCによってノードAに送信されたサービスデータである。

【0060】

この場合、ノードAは、複数のサービスデータを、複数のサービスデータのハンドリング時間の時間シーケンスに基づいてソートすることができ、表4に示すソートリストを決定することができる。

【0061】

【表4】

【0062】

次いで、ノードAは、コンセンサスメカニズムに基づいて、コンセンサス形成が実施される必要のあるサービス数を決定することができる。コンセンサス形成が実施される必要のあるサービス数が2であると仮定すると、ノードAは、サービス4およびサービス2を、コンセンサス形成を実施すべき対象となるサービスデータとして選択することができる。

【0063】

ノードは、格納されている複数のサービスデータを、ハンドリング時間の時間シーケンスに基づいてソートするのではなく、複数のサービスデータのハンドリング時間を検討し、次いで、ハンドリング時間の時間シーケンスに基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択してもよい。ノードが、複数のサービスデータのハンドリング時間の時間シーケンスに基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択する、換言すれば、コンセンサス形成が、最初にハンドリングされたサービスデータに対して最初に実施されることを条件として、どのようにノードが、複数のサービスデータのハンドリング時間の時間シーケンスに基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択するかは、本出願では限定されない。

【0064】

図1に示すブロックチェーンコンセンサス形成プロセスによれば、サービスデータを受信すると、ブロックチェーンネットワーク内のノードが、サービスデータのハンドリング時間を決定して、ハンドリング時間を含むサービスデータを格納する。サービスデータに対してコンセンサス形成が実施される必要のあるときに、複数のサービスデータのハンドリング時間のシーケンスを、複数のサービスデータのハンドリング時間に基づいて決定することができ、コンセンサス形成を実施すべき対象となるとともにサービスデータが中に格納されるブロックのブロック容量を満足させるサービスデータを、ファーストハンドリングファーストコンセンサス(first handling first consensus)という原理に基づいて、コンセンサス形成のために順次選択することができる。したがって、たとえサービスデータが別のノードによって送信されたとしても、サービスデータのハンドリング時間は、サービスデータを受信したノードによってサービスデータをハンドリングするタイムスタンプであるので、サービスデータの同一ハンドリングタイムスタンプが、ブロックチェーンネットワーク内の各ノードによって記録される。したがって、コンセンサス形成は、ブロックチェーンネットワーク内で最初にハンドリングされたサービス要求に対して最初に実施され、サービスデータがコンセンサス形成を待つ時間が、相対的に平衡することが実質的に確実になり、既存の技術における、一部のサービスデータが相対的に長い時間にわたってコンセンサス形成を待つという問題を、既存の技術と比較して軽減することができ、サービスデータの処理効率が実質的に向上し、ブロックチェーンの運用上のパフォーマンスが向上する。

【0065】

加えて、本出願の本実施形態のステップS102では、サービスデータを格納するとき、ノードは、サービスデータをキャッシュ内に、サービスデータの時間シーケンスおよびハンドリング時間に基づいて格納することができる。この場合、サービスデータリストをノードのキャッシュ内に構成することができ、リスト内のサービスデータは、ハンドリング時間のシーケンスに基づいて並べられる。ステップS103では、サービスデータに対してコンセンサス形成が実施される必要のあるときに、コンセンサス形成を実施すべき対象となるサービス数だけが決定されればよく、サービスデータ量が、サービスデータリストから順次選択され、コンセンサス形成を実施すべき対象となるサービスデータとして使用される。

【0066】

さらに、本出願の本実施形態では、ブロックチェーンネットワーク内の別のノードによってブロードキャストされたサービスデータを受信すると、ノードは最初に、そのサービスデータが、ノード内に格納されているサービスデータ内にすでに存在するかどうかを判定することができる。サービスデータが、ノード内に格納されているサービスデータ内にすでに存在するとの決定に応答して、サービスデータはそのノード内に格納されない(すなわちコンセンサス形成を実施すべき対象となる2つの同一サービスが格納されることが回避される)。そうでない場合、サービスデータは、ノードのローカルキャッシュ内に格納される。

【0067】

さらに、サービスデータが時間シーケンスに基づいて並べられるサービスデータリストがノード内にある場合、サービスデータを格納することを決定すると、ノードは、受信したサービスデータをノードのサービスデータリストに、サービスデータの時間シーケンスおよびハンドリング時間に基づいて追加することができる。

【0068】

例えば、表4において説明したサービスデータリストが、ノードA内に格納されているサービスデータであると仮定されたい。ノードAによって受信され、かつノードBによって送信されたサービスデータが、サービス5であり、またサービス5のハンドリング時間が10であるとき、ノードAはサービス5をサービスデータリストに、ハンドリング時間の時間シーケンスに基づいて、表5に示すように挿入することができる。

【0069】

【表5】

【0070】

本出願の本実施形態において提供される方法の全てのステップを、同一デバイスによって実行することができ、または方法を、別々のデバイスによって実行することができることに留意されたい。例えば、ステップS101およびステップS102をデバイス1によって実行することができ、ステップS103をデバイス2によって実行することができる。別の例を挙げると、ステップS101をデバイス1によって実行することができ、ステップS102およびステップS103をデバイス2によって実行することができる。

【0071】

図1に示すブロックチェーンコンセンサス形成方法に基づいて、本出願の一実施形態はさらに、それに対応して、図2に示すブロックチェーンコンセンサス形成装置の概略構造図を提供する。

【0072】

図2は、本出願の一実施形態による、ブロックチェーンコンセンサス形成装置を示す概略構造図であり、装置は、サービスデータを受信して、そのサービスデータのハンドリング時間を決定するように構成された決定モジュール201と、ハンドリング時間を含むサービスデータを格納するように構成された格納モジュール202と、サービスデータに対してコンセンサス形成が実施される必要のあるときに、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択するように構成された選択モジュール203と、コンセンサス形成を実施すべき対象となる選択したサービスデータに対してコンセンサス形成を実施するように構成されたコンセンサス形成モジュール204とを含む。

【0073】

本出願の別の実施形態では、決定モジュール201が、サービスデータのハンドリング時間を決定することであって、サービスデータを受信した時間を決定し、その時間をサービスデータのハンドリング時間として決定すること、またはサービスデータを、そのサービスデータを受信した時間に処理して、処理結果を取得し、処理結果の生成時間をそのサービスデータのハンドリング時間として決定することを含む、サービスデータのハンドリング時間を決定するように構成される。

【0074】

本出願の別の実施形態では、装置は、ブロードキャストモジュール205をさらに含む。

【0075】

ブロードキャストモジュール205は、サービスデータのハンドリング時間が決定された後に、ハンドリング時間を含むサービスデータを、ブロックチェーン内の別のノードにブロードキャストするように構成される。

【0076】

本出願の別の実施形態では、決定モジュール201が、サービスデータを受信して、そのサービスデータのハンドリング時間を決定することであって、ブロックチェーン内の別のノードによって送信されたサービスデータをブロードキャスト方式で受信することと、そのサービスデータ内に含まれるハンドリング時間を、そのサービスデータのハンドリング時間として決定することとを含む、サービスデータを受信して、そのサービスデータのハンドリング時間を決定するように構成される。

【0077】

本出願の別の実施形態では、選択モジュール203が、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択することであって、ハンドリング時間の時間シーケンスに基づいて、コンセンサス形成を実施すべき対象となるとともにサービスデータが中に格納されるブロックのブロック容量を満足させるサービスデータを選択することを含む、ハンドリング時間に基づいて、コンセンサス形成を実施すべき対象となるサービスデータを選択するように構成される。

【0078】

図2に示すように、ブロックチェーンコンセンサス形成装置は、サーバ内に位置付けることができ、サーバは、単独のデバイスであってもよく、複数のデバイスを含むシステムであってもよい。あるいは、コンセンサス形成装置は、モバイル電話、タブレットコンピュータ、およびパーソナルコンピュータなどの端末デバイス内に位置付けることもできる。

【0079】

1990年代には、技術の向上がハードウェアの向上(例えば、ダイオード、トランジスタ、またはスイッチなどの回路構造の向上)であるか、それともソフトウェアの向上(方法手順の向上)であるかを、容易に区別することができている。しかし、技術の発展に伴い、多くの方法手順に関する現在の向上は、ハードウェア回路構造の直接的な向上と見なすことができる。設計者は通常、向上された方法手順をハードウェア回路に対してプログラムして、対応するハードウェア回路構造を取得する。したがって、方法手順は、ハードウェアエンティティモジュールを使用して向上させることができる。例えば、プログラマブル論理デバイス(PLD)(例えばフィールドプログラマブルゲートアレイ(FPGA))がそのような集積回路であり、プログラマブル論理デバイスの論理機能は、ユーザによってデバイスプログラミングを通じて決定される。設計者は、チップ製造業者に特定用途向け集積回路チップを設計および製造するように依頼することなく、プログラミングを実施してデジタルシステムをPLDに「集積する」。加えて、このプログラミングはたいてい、集積回路チップを手作業で作成するのではなく、「論理コンパイラ」ソフトウェアに手を加えることによって実施される。これは、プログラムの開発およびコンパイルに使用されるソフトウェアコンパイラに類似している。ただし、コンパイル前のオリジナルコードはやはり、特定のプログラミング言語で記述され、それはハードウェア記述言語(HDL)と呼ばれている。アドバンストブール演算式言語(Advanced Boolean Expression Language)(ABEL)、Alteraハードウェア記述言語(AHDL)、Confluence、コーネル大学プログラミング言語(CUPL)、HDCal、Java(登録商標)ハードウェア記述言語(JHDL)、Lava、Lola、MyHDL、PALASM、およびRubyハードウェア記述言語(RHDL)など、多くのHDLがある。現在、超高速集積回路ハードウェア記述言語(VHDL)およびVerilogが、最も一般に使用されている。方法手順が、説明したいくつかのハードウェア記述言語を使用して論理的にプログラムされ、かつ集積回路にプログラムされると、論理的方法手順を実装したハードウェア回路を容易に取得することが可能であることも、当業者なら理解するであろう。

【0080】

コントローラを、任意の適切な方法を使用して実装することができる。例えば、コントローラは、マイクロプロセッサ、プロセッサ、もしくはコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブル論理コントローラ、またはプロセッサ(もしくはマイクロプロセッサ)によって実行することのできるコンピュータ可読プログラムコード(例えばソフトウェアもしくはファームウェア)を格納する組込みマイクロコントローラとすることができる。コントローラの例としては、それらに限定されないが、次のマイクロコントローラ、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、またはSilicon Labs C8051F320がある。メモリコントローラも、メモリの制御論理回路の一部として実装することができる。当業者であれば、コントローラを、純粋なコンピュータ可読プログラムコード方法を使用して実装できること、および方法のステップを論理的にプログラムして、コントローラが同一機能を論理ゲート、スイッチ、特定用途向け集積回路、プログラマブル論理コントローラ、組込みマイクロコントローラなどの形で実装できるようにすることができることも分かっていよう。したがって、コントローラはハードウェアコンポーネントと見なすことができ、コントローラ内に含まれ、コントローラ内でさまざまな機能を実装するように構成された装置も、ハードウェアコンポーネント内の構造と見なすことができる。あるいは、さまざまな機能を実装するように構成された装置は、方法を実装することのできるソフトウェアモジュールと見なすこともでき、ハードウェアコンポーネント内の構造と見なすこともできる。

【0081】

先の実施形態において示したシステム、装置、モジュール、またはユニットは、コンピュータチップまたはエンティティを使用して実装することもでき、ある種の機能を有する製品を使用して実装することもできる。典型的な実装デバイスが、コンピュータである。コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、セルラー電話、カメラ付き電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲームコンソール、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスのいずれかの組合せとすることができる。

【0082】

説明しやすくするために、先の装置は、機能をさまざまなユニットに分割することによって説明される。本出願を実装するとき、ユニットの機能は、1つまたは複数のソフトウェアおよび/またはハードウェアとして実装することができる。

【0083】

本開示の実施形態を、方法、システム、またはコンピュータプログラム製品として提供できることを、当業者なら理解するであろう。したがって、本開示は、ハードウェアのみの実施形態の形を使用してもよく、ソフトウェアのみの実施形態の形を使用してもよく、ソフトウェアとハードウェアの組合せを用いた実施形態の形を使用してもよい。加えて、本開示は、コンピュータが使用可能なプログラムコードを含む、(磁気ディスクメモリ、コンパクトディスク読出し専用メモリ(CD-ROM)、および光メモリを含むがそれらに限定されない)コンピュータが使用可能な1つまたは複数の記憶媒体上に実装された、コンピュータプログラム製品の形を使用することができる。

【0084】

本開示については、本開示の実施形態に基づく方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明されている。フローチャートおよび/またはブロック図内の各プロセスおよび/または各ブロック、ならびにフローチャートおよび/またはブロック図内のプロセスおよび/またはブロックの組合せを実装するためにコンピュータプログラム命令を使用することができることに留意されたい。これらのコンピュータプログラム命令を、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または別のプログラマブルデータ処理デバイスのプロセッサに提供して、マシンを生成することができ、したがって、コンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行された命令は、フローチャート内の1つもしくは複数のプロセスにおける、かつ/またはブロック図内の1つもしくは複数のブロックにおける特定の機能を実装するための装置を生成する。

【0085】

これらのコンピュータプログラム命令を、コンピュータ可読メモリ内に記憶することができ、それがコンピュータまたは別のプログラマブルデータ処理デバイスに、特定の方式で機能するように命令することができ、したがって、コンピュータ可読メモリ内に記憶された命令は、命令装置を含む人工物を生成する。この命令デバイスは、フローチャート内の1つもしくは複数のプロセスにおける、かつ/またはブロック図内の1つもしくは複数のブロックにおける特定の機能を実装する。

【0086】

これらのコンピュータプログラム命令を、コンピュータまたは別のプログラマブルデータ処理デバイス上にロードすることができ、それによって、コンピュータまたは別のプログラマブルデバイス上で一連の動作およびステップが実施され、それにより、コンピュータ実装処理が生じる。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャート内の1つもしくは複数のプロセスにおける、かつ/またはブロック図内の1つもしくは複数のブロックにおける特定の機能を実施するためのステップを提供する。

【0087】

典型的な構成では、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入力/出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。

【0088】

メモリは、非永続的メモリ、ランダムアクセスメモリ(RAM)、および/またはコンピュータ可読媒体としての不揮発性メモリ、例えば読出し専用メモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)を含んでよい。メモリは、コンピュータ可読媒体の一例である。

【0089】

コンピュータ可読媒体としては、任意の方法または技術を使用して情報を記憶することのできる、永続的、非永続的、移動可能、および移動不能な媒体がある。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータとすることができる。コンピュータ記憶媒体の例としては、それらに限定されないが、パラメータランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、読出し専用メモリ(ROM)、電気的消去可能プログラマブル読出し専用メモリ(EEPROM)、フラッシュメモリもしくは別のメモリ技術、コンパクトディスク読出し専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)もしくは別の光記憶装置、カセット、カセット磁気ディスク記憶装置もしくは別の磁気記憶デバイス、または他の任意の非伝送媒体がある。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセスすることのできる情報を記憶するために使用することができる。本明細書において説明するように、コンピュータ可読媒体は、変調データ信号や搬送波などのコンピュータ可読一時的媒体(一時的媒体)を含まない。

【0090】

「含む」、「具備する」という用語、またはそれらの他の任意の変形は、非排他的包含をカバーすることが意図されており、したがって、一連の要素を含むプロセス、方法、製品、またはデバイスは、それらの要素を含むのみならず、明示的に列記されていない他の要素も含み、またはそのようなプロセス、方法、製品、もしくはデバイスに固有の要素をさらに含むことに留意されたい。要素が「1つの〜を含む(includes a …)」に先行される場合、それは、それ以上の制約がなければ、その要素を含むプロセス、方法、物品、またはデバイス内に追加の同一要素が存在することを妨げるものではない。

【0091】

本出願の実施形態を、方法、システム、またはコンピュータプログラム製品として提供できることを、当業者なら理解するであろう。したがって、本出願は、ハードウェアのみの実施形態の形を使用してもよく、ソフトウェアのみの実施形態の形を使用してもよく、ソフトウェアとハードウェアの組合せを用いた実施形態の形を使用してもよい。加えて、本出願は、コンピュータが使用可能なプログラムコードを含む、(磁気ディスクメモリ、コンパクトディスク読出し専用メモリ(CD-ROM)、および光メモリを含むがそれらに限定されない)コンピュータが使用可能な1つまたは複数の記憶媒体上に実装された、コンピュータプログラム製品の形を使用することができる。

【0092】

本出願は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈の中で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本出願は、分散コンピューティング環境において実践することもできる。これらの分散コンピューティング環境では、タスクは、通信ネットワークを使用して接続されるリモート処理デバイスによって実行される。分散コンピューティング環境では、プログラムモジュールは、記憶デバイスを含むローカルおよびリモートのコンピュータ記憶媒体内に位置付けることができる。

【0093】

本明細書の実施形態については、段階的に説明されている。実施形態における同一または類似の部分については、それらの実施形態を参照することができる。各実施形態は、他の実施形態との差異に焦点を当てている。特に、システムの実施形態は、方法の実施形態に基本的に類似しており、したがって簡潔に説明されている。関連する部分については、方法の実施形態における説明を一部参照することができる。

【0094】

先の説明は、本出願の単なる実施形態であり、本出願を限定するように意図されてはいない。当業者なら、本出願にさまざまな修正および変更を行うことができる。本出願の趣旨および原理から逸脱することなく行われるいかなる修正、等価な置換、または改良も、本出願における特許請求の範囲に含まれるものとする。

【符号の説明】

【0095】

201 決定モジュール
202 格納モジュール
203 選択モジュール
204 コンセンサス形成モジュール
205 ブロードキャストモジュール

【図1】

【図2】