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

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

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

(11)【特許番号】6692561

(24)【登録日】2020年4月17日

(45)【発行日】2020年5月13日

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

(51)【国際特許分類】

   G06F 16/182 20190101AFI20200427BHJP

   G06Q 20/40 20120101ALI20200427BHJP

【ＦＩ】

   G06F16/182

   G06Q20/40

【請求項の数】17

【全頁数】21

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

(86)(22)【出願日】2018年5月30日

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

(43)【公表日】2020年4月9日

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

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

(87)【国際公開日】20181206

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

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

(32)【優先日】2017年5月31日

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

【早期審査対象出願】

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100188558

【弁理士】

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

(74)【代理人】

【識別番号】100205785

【弁理士】

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

(72)【発明者】

【氏名】シフェン・ワン

【審査官】 甲斐 哲雄

(56)【参考文献】

【文献】 中国特許出願公開第１０８７１７４６０（ＣＮ，Ａ）

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

【文献】 韓国登録特許第１０−１７２７５２５（ＫＲ，Ｂ１）

【文献】 国際公開第２０１６／１６４４９６（ＷＯ，Ａ１）

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

Ｇ０６Ｆ １６／１０−１６／１８８

Ｇ０６Ｑ ２０／４０

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

【請求項1】

ブロックチェーンコンセンサス方法であって、
ブロックチェーンノードにより、コンセンサス手順が行われることになるサービスデータを入手するステップと、
前記サービスデータのサービスタイプを決定するステップと、
前記ブロックチェーンノードにより、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択するステップと、
前記選択されたコンセンサスノードが前記サービスデータに対するコンセンサス処理を行うように、前記ブロックチェーンノードにより、前記選択されたコンセンサスノードに前記サービスデータを送るステップと、
を含む、ブロックチェーンコンセンサス方法。

【請求項2】

前記ブロックチェーンノードにより、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択する前記ステップが、
前記コンセンサスノードにより、受け取られたサービスデータの前記サービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定するステップであって、前記コンセンサスポリシーがコンセンサスアルゴリズムを含む、ステップと、
前記ブロックチェーンノードにより、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択するステップと、
を含む、請求項1に記載のブロックチェーンコンセンサス方法。

【請求項3】

前記ブロックチェーンノードにより、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択する前記ステップが、
前記ブロックチェーンノードにより、前記コンセンサス処理に参加することになるコンセンサスノードの数量を、前記コンセンサスアルゴリズムに基づいて決定するステップであって、前記数量が、前記コンセンサスアルゴリズムの所定の数量を満たす、ステップと、
前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択するステップと、
を含む、請求項2に記載のブロックチェーンコンセンサス方法。

【請求項4】

前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択する前記ステップが、
前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量をランダムに選択するステップ、または
前記ブロックチェーンノードにより、前記コンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択するステップ
を含む、請求項3に記載のブロックチェーンコンセンサス方法。

【請求項5】

前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択する前記ステップが、
前記ブロックチェーンノードにより、前記コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定するステップと、
前記ブロックチェーンノードにより、前記コンセンサスポリシーに含まれる前記コンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされる前記コンセンサスアルゴリズムに基づいて決定するステップと、
前記決定されたコンセンサスノードからコンセンサスノードの前記数量を選択するステップと、
を含む、請求項3に記載のブロックチェーンコンセンサス方法。

【請求項6】

前記ブロックチェーンノードにより、前記選択されたコンセンサスノードに前記サービスデータを送る前記ステップの前に、前記方法が、
前記選択されたコンセンサスノードが前記コンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、前記ブロックチェーンノードにより、前記選択されたコンセンサスノードを前記他のブロックチェーンノードにブロードキャストするステップをさらに含み、
前記ブロックチェーンノードにより、前記選択されたコンセンサスノードに前記サービスデータを送る前記ステップが、
前記ブロックチェーンノードにより、前記他のブロックチェーンノードによって送られたコンセンサス到達メッセージの受け取りに応答して、前記選択されたコンセンサスノードに前記サービスデータを送るステップを含む、請求項1から5のいずれか一項に記載のブロックチェーンコンセンサス方法。

【請求項7】

前記ブロックチェーンノードにより、前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果の受け取りに応答して、および前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要があるという判断に応答して、前記コンセンサス処理に参加していない、前記コンセンサスネットワーク内のコンセンサスノードに前記サービスデータに対する前記コンセンサス結果を送り、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納するステップをさらに含む、請求項6に記載のブロックチェーンコンセンサス方法。

【請求項8】

前記ブロックチェーンノードにより、前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果の受け取りに応答して、前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要がないという判断に応答して、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納するステップをさらに含む、請求項6に記載のブロックチェーンコンセンサス方法。

【請求項9】

ブロックチェーンコンセンサスデバイスであって、
取得ユニット、選択ユニット、および送信ユニットを備え、
前記取得ユニットが、コンセンサス手順が行われることになるサービスデータを入手し、前記サービスデータのサービスタイプを決定し、
前記選択ユニットが、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択し、
前記送信ユニットが、前記選択されたコンセンサスノードが前記サービスデータに対するコンセンサス処理を行うように、前記選択されたコンセンサスノードに前記サービスデータを送る、ブロックチェーンコンセンサスデバイス。

【請求項10】

前記選択ユニットが、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいて前記コンセンサスネットワークから選択することが、
受け取られたサービスデータの前記サービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定することであって、前記コンセンサスポリシーがコンセンサスアルゴリズムを含む、前記決定することと、
前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択することと、
を含む、請求項9に記載のブロックチェーンコンセンサスデバイス。

【請求項11】

前記選択ユニットが、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択することが、
前記コンセンサス処理に参加することになるコンセンサスノードの数量を、前記コンセンサスアルゴリズムに基づいて決定することであって、前記数量が、前記コンセンサスアルゴリズムの所定の数量を満たす、前記決定することと、
前記コンセンサスネットワークからコンセンサスノードの前記数量を選択することと、
を含む、請求項10に記載のブロックチェーンコンセンサスデバイス。

【請求項12】

前記選択ユニットが、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択することが、
前記コンセンサスネットワークからコンセンサスノードの前記数量をランダムに選択すること、または
前記コンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択すること、
を含む、請求項11に記載のブロックチェーンコンセンサスデバイス。

【請求項13】

前記選択ユニットが、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択することが、
前記コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定することと、
前記コンセンサスポリシーに含まれる前記コンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされる前記コンセンサスアルゴリズムに基づいて決定することと、
前記決定されたコンセンサスノードから前記コンセンサスノードの数量を選択することと、
を含む、請求項11に記載のブロックチェーンコンセンサスデバイス。

【請求項14】

処理ユニットをさらに含み、
前記処理ユニットが、前記選択されたコンセンサスノードが前記コンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、前記選択されたコンセンサスノードに前記サービスデータが送られる前に、前記選択されたコンセンサスノードを前記他のブロックチェーンノードにブロードキャストすることを含み、
前記送信ユニットが、前記選択されたコンセンサスノードに前記サービスデータを送ることが、
前記他のブロックチェーンノードによって送られたコンセンサス到達メッセージの受け取りに応答して、前記選択されたコンセンサスノードに前記サービスデータを送ることを含む、請求項9から13のいずれか一項に記載のブロックチェーンコンセンサスデバイス。

【請求項15】

判断ユニットをさらに備え、
前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果が受け取られたという判断に応答して、および前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要があるという判断に応答して、前記判断ユニットが、前記コンセンサス処理に参加していない、前記コンセンサスネットワーク内のコンセンサスノードに、前記サービスデータに対する前記コンセンサス結果を送り、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納する、請求項14に記載のブロックチェーンコンセンサスデバイス。

【請求項16】

格納ユニットをさらに備え、
前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果が受け取られたという判断に応答して、前記格納ユニットが、前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要がないという判断に応答して、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納する、請求項14に記載のブロックチェーンコンセンサスデバイス。

【請求項17】

ブロックチェーンコンセンサスデバイスであって、
メモリおよび少なくとも1つのプロセッサを備え、前記メモリが、プログラムを格納し、前記少なくとも1つのプロセッサが、
コンセンサス手順が行われることになるサービスデータを入手し、前記サービスデータのサービスタイプを決定するステップと、
コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択するステップと、
前記選択されたコンセンサスノードが前記サービスデータに対するコンセンサス処理を行うように、前記選択されたコンセンサスノードに前記サービスデータを送るステップと、
を行うように構成された、ブロックチェーンコンセンサスデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

分散型台帳技術とも呼ばれるブロックチェーン技術は、分散型インターネットデータベース技術である。ブロックチェーン技術に基づいて構築されたネットワークは、ブロックチェーンネットワークと呼ばれることが可能である。ブロックチェーンネットワークは、ネットワークノード(ブロックチェーンノードと呼ばれることも可能であり、以下では略してノードと呼ばれる)を含む。各ノードは、少なくとも1つのブロックチェーンに対応し、各ブロックチェーンは、少なくとも1つのブロックを含む。ブロックチェーンネットワーク(またはブロックチェーン技術)には、非集中化、透明性、改ざん耐性、および信用性という特徴がある。これらの特徴に基づいて、ブロックチェーン技術は、ますます多くの分野において利用される。

【0003】

サービスデータをブロックチェーンに記録する処理(すなわち、サービスデータをブロックチェーンネットワークに格納する処理)は、取扱フェーズ、コンセンサスフェーズ、および格納フェーズという3つのフェーズを含む。取扱フェーズは、ブロックチェーンネットワーク内の一定のブロックチェーンノードが、ブロックチェーンに記録されることになるサービスデータを受け取ること、およびブロックチェーンノードが、サービスデータを取り扱うこととして理解されることが可能である。コンセンサスフェーズは、ブロックチェーンノードがサービスデータを取り扱った後、ブロックチェーンネットワーク内の別のブロックチェーンノードが、サービスデータに対するコンセンサス処理に参加する必要があることとして理解されることが可能である。格納フェーズは、サービスデータに対するコンセンサスが得られた後に始まる。格納フェーズは、コンセンサスが得られたサービスデータをブロックチェーンノードがブロックチェーンに記録することとして理解されることが可能である。

【発明の概要】

【発明が解決しようとする課題】

【0004】

サービスデータをブロックチェーンに記録する処理に含まれる3つのフェーズの中でも、コンセンサスフェーズは、ブロックチェーンネットワーク内の別のブロックチェーンノードの参加を必要とする。コンセンサス処理がサービスデータに対して行われているとき、コンセンサス処理に参加するブロックチェーンノードが多くなると、コンセンサス処理時間が長くなるということが研究で発見された。必然的に、サービスデータに対して行われるコンセンサス処理の効率は低下する。

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

【0005】

したがって、本出願の実装形態は、既存技術における低いコンセンサス処理効率の問題を軽減させるためのブロックチェーンコンセンサス方法およびデバイスを提供する。

【0006】

本出願の実装形態において、以下の技術的解決策が採用される。

【0007】

本出願の1つの実装形態は、ブロックチェーンコンセンサス方法を提供し、ブロックチェーンノードにより、コンセンサス手順が行われることになるサービスデータを入手するステップと、サービスデータのサービスタイプを決定するステップと、ブロックチェーンノードにより、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択するステップと、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、ブロックチェーンノードにより、選択されたコンセンサスノードにサービスデータを送るステップと、を含む。

【0008】

本出願の1つの実装形態は、ブロックチェーンコンセンサスデバイスをさらに提供し、取得ユニット、選択ユニット、および送信ユニットを含み、取得ユニットが、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定し、選択ユニットが、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択し、送信ユニットが、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送る。

【0009】

本出願の1つの実装形態は、ブロックチェーンコンセンサスデバイスをさらに提供し、メモリおよび少なくとも1つのプロセッサを含み、メモリが、プログラムを格納し、少なくとも1つのプロセッサが、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定するステップと、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択するステップと、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送るステップと、を行うように構成される。

【0010】

本出願の実装形態において採用される前述の技術的解決策のうちの少なくとも1つは、本出願の実装形態において、コンセンサス手順が行われることになるサービスデータのサービスタイプに基づいて、コンセンサスサービスを提供するコンセンサスノードが選択されることが可能であること、およびサービスデータに対するコンセンサス処理を、選択されたコンセンサスノードが行うこと、という有益な効果をもたらすことができる。このようにして、様々なサービスに対するコンセンサス処理を行うために、いくつかのコンセンサスノードがコンセンサスネットワークから選択され、このことにより、コンセンサス処理に参加する大きな数量のコンセンサスノードによって引き起こされる長いコンセンサス処理時間の問題を軽減させる。このことは、コンセンサス処理時間を短縮するだけでなく、コンセンサス処理結果の正当性も保証することができ、このことにより、ブロックチェーンネットワークのサービスデータ処理効率を効果的に改善する。

【0011】

ここで説明される添付の図面は、本出願についてさらに理解することを意図するものであり、本出願の一部である。本出願の例証的な実装形態およびこれらの説明は、本出願を説明することを意図するものであり、本出願に対する限定ではない。

【図面の簡単な説明】

【0012】

【図1】本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。

【図2】本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。

【図3】本出願の1つの実装形態による、ブロックチェーンコンセンサスデバイスを示す概略構造図である。

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

【0013】

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

【0014】

本出願の実装形態において提供される技術的解決策が、添付の図面を参照しながら下記で詳細に説明される。

【0015】

本出願の実装形態において説明されるブロックチェーンネットワークおよびコンセンサスネットワークは、同じネットワークであることが可能である。言い換えると、ネットワーク内のブロックチェーンノードは、コンセンサスノードと呼ばれることも可能である。ネットワーク内でサービスデータを取り扱うノードは、サービス取扱ノードと呼ばれることが可能であり、サービスデータに対するコンセンサス処理を始める。ネットワークは、このノードの他に複数のノードを含む。これらのノードは、これらのノードがサービスデータに対するコンセンサス処理に参加すると、コンセンサスノードと呼ばれることが可能である。さらに、これらのノードは、サービス取扱ノードとして機能することもできる。例えば、ブロックチェーンネットワークは、5つのノード(ノード1、ノード2、ノード3、ノード4、およびノード5)を含み、各ノードは、サービス取扱ノードとコンセンサスノードの両方として機能することができる。ノード1がサービスデータを取り扱う場合、ノード1は、サービス取扱ノードとして機能し、ノード2、ノード3、ノード4、およびノード5は、サービスデータのためのコンセンサスノードとして機能し、サービスデータに対するコンセンサス処理に参加する。

【0016】

本出願の実装形態において説明されるブロックチェーンネットワークには、コンセンサスネットワークを含むことができる。この場合、コンセンサスネットワークに含まれるコンセンサスノードは、ブロックチェーンネットワーク内のブロックチェーンノードによって始められたコンセンサス要求に対するコンセンサス処理を行うことができる。例えば、ブロックチェーンネットワークは、5つのノード(ノード1、ノード2、ノード3、ノード4、およびノード5)を含み、ここで、ノード2、ノード4、およびノード5は、コンセンサスネットワーク内のコンセンサスノードである。この場合、ノード2、ノード4、およびノード5は、ノード1またはノード3によって始められたコンセンサス要求に対するコンセンサス処理を行うことができる。ノード1およびノード3は、ここでは、サービスデータを取り扱うためのノードとして機能し、取り扱われるサービスデータに対するコンセンサス処理を行うことを、コンセンサスネットワーク内のコンセンサスノードにリクエストすることができる。すなわち、コンセンサスノードは、サービスデータの取扱いに参加しなくてよい。

【0017】

本出願の実装形態において、コンセンサスノードにコンセンサス結果が格納されるかどうかは限定されず、実際の要求に基づいて判断されてよい。コンセンサスノードにコンセンサス結果が格納される場合と、コンセンサスノードにコンセンサス結果が格納されない場合の両方が、本出願の実装形態の保護範囲に含まれる。

【0018】

図1は、本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。方法は、以下のように説明されることが可能である。

【0019】

ステップ101。ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定する。

【0020】

本出願の本実装形態において、ブロックチェーンノードは、サービスデータを取り扱うためのノード、コンセンサス処理を始めるためのノード、または本コンセンサス処理のための1次ノードとして機能することができ、このことは、ここでは限定されない。

【0021】

ブロックチェーンノードが、サービスデータを取り扱うためのノードとして機能する場合、ブロックチェーンノードは、取り扱われてローカルに格納されたサービスデータから、コンセンサス手順が行われることになるサービスデータとしていくつかのサービスデータを取得し、取得されたサービスデータに対してその後始められるコンセンサス処理を容易にすることができる。

【0022】

ブロックチェーンノードが、サービスデータを取り扱うためのノードではなく、本コンセンサス処理のための1次ノードとして機能する場合、ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータのリソースプールからいくつかのサービスデータを取得し、コンセンサス手順が行われることになるサービスデータとして取得されたサービスデータを使用して、取得されたサービスデータに対してその後始められるコンセンサス処理を容易にすることができる。

【0023】

コンセンサス手順が行われることになるサービスデータを入手した後、ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを生成するサービスを決定し、コンセンサス手順が行われることになるサービスデータに対応するサービスタイプをさらに決定する。

【0024】

サービスは、様々なサービス機能に基づいて様々なタイプに分類されることが可能である。例えば、サービスは、順序タイプ(順序生成フェーズにおいて生成されたサービスデータに対応するサービスタイプは順序タイプである)、または支払タイプ(支払情報を含むサービスデータに対応するサービスタイプは支払タイプである)のものであることが可能である。サービスは一方、異なるサービス内容に基づいて分類されることが可能である。例えば、サービスは、カード発行タイプ(カード発行情報を含むサービスデータに対応するサービスタイプはカード発行タイプである)、または取引タイプ(取引情報を含むサービスデータに対応するサービスタイプは取引タイプである)のものであることが可能である。サービスタイプの分類原理は、ここでは限定されない。

【0025】

ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを入手した後に、各サービスデータに対応するサービスタイプを決定する。実際には、サービスタイプの適用範囲の中には重複するものもあるので、各サービスデータに対応するサービスタイプを決定するときに、ブロックチェーンノードは、コンセンサス手順が行われることになる入手されたサービスデータに対応するサービスタイプとして、クラスタ方式で(または、ここでは限定されない別の方式で)、より広い適用範囲を有するサービスタイプを決定することができる。

【0026】

例えば、コンセンサス手順が行われることになる入手されたサービスデータに対応するサービスタイプは、順序タイプおよび支払タイプを含む。順序タイプのサービスデータ、および支払タイプのサービスデータの両方が、サービス内容に基づく取引タイプに属するので、コンセンサス手順が行われることになるサービスデータに対応するサービスタイプは、取引タイプとして判断される。

【0027】

1つまたは複数のサービスタイプが、ここで決定されることが可能であるということに留意する価値がある。複数のサービスタイプが決定される場合、その後のステップにおける1つのコンセンサスアルゴリズムに複数のサービスタイプが対応することが可能である。または複数のサービスタイプが複数のコンセンサスアルゴリズムに対応することが可能であるが、複数のサービスタイプに適用可能な1つのコンセンサスアルゴリズムは、複数のコンセンサスアルゴリズムから決定されることが可能である。

【0028】

ステップ102。ブロックチェーンノードは、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択する。

【0029】

本出願の本実装形態において、ブロックチェーンノードはまず、受け取られたサービスデータのサービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定し、ここでコンセンサスポリシーは、コンセンサスアルゴリズムを含む。

【0030】

コンセンサスポリシーは、一定のサービスまたはいくつかのサービスによって生成されたサービスデータに対するコンセンサス処理を行う方法である。具体的に言うと、コンセンサスポリシーは、指定のサービスタイプに対応するサービスによって生成されるサービスデータに対するコンセンサス処理を行うために使用されるコンセンサスアルゴリズムを指定する。

【0031】

コンセンサスポリシーは、ここでは、使用されるコンセンサスアルゴリズムを含むことができ、コンセンサスメカニズムをさらに含むことができる。コンセンサスメカニズムは、ここでは、コンセンサスネットワーク内のコンセンサスノードが、全体的なコンセンサス処理を行う必要があるかどうかを含む。全体的なコンセンサス処理を行う必要がある場合、コンセンサスポリシーに含まれるコンセンサスメカニズムは、全体的なコンセンサスメカニズムである。全体的なコンセンサス処理を行う必要がない場合、コンセンサスポリシーに含まれるコンセンサスメカニズムは、局所的なコンセンサスメカニズムである。

【0032】

本出願の本実装形態におけるコンセンサスポリシーに含まれるコンセンサスアルゴリズムは、プルーフ・オブ・ワーク(PoW:Proof of Work)アルゴリズム、プルーフ・オブ・ステーク(PoS:Proof of Stake)アルゴリズム、デリゲーテッド・プルーフ・オブ・ステーク(DPoS:Delegated Proof of Stake)アルゴリズム、プラクティカル・ビザンチン・フォールト・トレランス(PBFT:Practical Byzantine Fault Tolerance)アルゴリズム、およびデリゲーテッド・ビザンチン・フォールト・トレランス(DBFT:Delegated Byzantine Fault Tolerance)アルゴリズムを含むがこれらに限定されない。

【0033】

同じコンセンサスポリシーまたは異なるコンセンサスポリシーに、様々なサービスタイプが対応することが可能であるということに留意する価値がある。本出願の本実装形態において、サービスデータ処理効率を保証するために、様々なコンセンサスアルゴリズムが、様々なサービスタイプのサービスデータに対して使用されることが可能である。様々なサービスタイプおよび動作原理の特徴、ならびに様々なコンセンサスアルゴリズムの長所および短所に基づいて、比較的適用可能で、処理効率を保証できるコンセンサスアルゴリズムが様々なサービスタイプに対して決定されることが可能である。マッピング関係は、サービスタイプとコンセンサスアルゴリズムの間で確立されることが可能である。

【0034】

例えばPBFTアルゴリズムは、比較的大量のデータを含み、攻撃に対して脆弱ではない順序タイプのサービスデータに対するコンセンサス処理を行うために使用されることが可能であり、PoWアルゴリズムは、攻撃に対して脆弱な支払タイプのサービスデータに対するコンセンサス処理を行うために使用されることが可能である。サービスタイプに対するコンセンサスアルゴリズムは、ここでは限定されない。

【0035】

さらにブロックチェーンノードは、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択する。

【0036】

ブロックチェーンノードは、コンセンサス処理に参加することになるコンセンサスノードの数量を、コンセンサスアルゴリズムに基づいて決定し、この数量が、コンセンサスアルゴリズムの所定の数量を満たし、コンセンサスネットワークからコンセンサスノードの数量を選択する。

【0037】

様々なコンセンサスアルゴリズムが様々な動作原理を有するので、コンセンサス処理に参加することが許されるコンセンサスノードの数量は、コンセンサスアルゴリズムに応じて変化する。例えば、PoWアルゴリズムに対して、ネットワーク内のすべてのノードは、1回のコンセンサス処理に参加するコンセンサスノードとして機能する必要がある。別の例として、PBFTアルゴリズムに対して、最低4つのノードが、1回のコンセンサス処理に参加するコンセンサスノードとして機能する必要がある。

【0038】

したがって、本出願の本実装形態において、コンセンサス処理に参加することになるコンセンサスノードは、コンセンサスアルゴリズムの最低投票設定によって必要とされるコンセンサスノードの数量に基づいて選択されることが可能である。

【0039】

一方、本出願の本実装形態において、コンセンサス処理に参加することになるコンセンサスノードの数量は、(ランダム化アルゴリズムなどの)指定のアルゴリズムに基づいて決定されることが可能である。

【0040】

例えば、コンセンサス処理に参加することになるコンセンサスノードの数量は次のように決定される。

【0041】

R=ノード番号%ノードの数量。すなわち、Rは、ノード番号がノードの数量で割られるときの余りを計算することによって得られることが可能である。

【0042】

Rは、コンセンサス処理に参加することになるコンセンサスノードの決定された数量である。ノード番号は、ステップ101において説明された、コンセンサス手順が行われることになるサービスデータを得るブロックチェーンノードの番号である。ノードの数量は、ブロックチェーンネットワークに含まれるブロックチェーンノードの数量(またはコンセンサスネットワークに含まれるコンセンサスノードの数量)である。

【0043】

ブロックチェーンネットワーク内の各ブロックチェーンノードは、予め番号を付けられることが可能であるということに留意する価値がある。このようにして、ステップ101において説明された、コンセンサス手順が行われることになるサービスデータを得るブロックチェーンノードの番号は、迅速に決定されることが可能である。コンセンサス処理に参加することになるコンセンサスノードの数量が先の方程式を使用することによって決定されると、コンセンサス処理に参加することになるコンセンサスノードの決定された数量は、サービスデータを取り扱うためのノードの番号に応じて、同じサービスタイプのサービスデータに対して変化する。または様々なサービスタイプのサービスデータを取り扱うためのノードが、予め決定されることが可能である。言い換えると、サービスタイプのサービスデータを取り扱うためのノードは、ブロックチェーンネットワーク内の指定されたブロックチェーンノードである。この場合、上記で決定されたような、コンセンサス処理に参加するコンセンサスノードの数量は、同じサービスタイプのサービスデータに対して同じであることが可能である。

【0044】

さらに、方程式におけるノード番号は一方、サービスタイプ番号であることが可能である。様々なサービスタイプの番号が予め決定されることが可能である。この場合、同じサービスタイプのサービスデータに対して、コンセンサス手順が行われることになるサービスデータに対応するサービスタイプが、ステップ101において決定された後、サービスタイプに対応するサービスタイプ番号がさらに決定されることが可能であり、その後、コンセンサス処理に参加することになるコンセンサスノードの数量は、先の方程式に基づいて決定されることが可能である。

【0045】

コンセンサス処理に参加することになるコンセンサスノードの数量が決定された後、次のように、コンセンサスノードの数量がコンセンサスネットワークから選択されることが可能である。

【0046】

ブロックチェーンノードがコンセンサスネットワークからコンセンサスノードの数量をランダムに選択するか、コンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、ブロックチェーンノードがコンセンサスネットワークからコンセンサスノードの数量を選択する。

【0047】

例えば、コンセンサス処理に参加することになるコンセンサスノードの数量が4と決定される。この場合、4つのコンセンサスノードは、コンセンサスネットワークからランダムに選択されることが可能であり、4つの選択されたコンセンサスノードは、本コンセンサス処理のためのコンセンサスサービスを提供する。一方、サービスデータ処理効率を改善するために、コンセンサスネットワーク内のコンセンサスノードの負荷状況が判断されることが可能であり、コンセンサスネットワーク内のコンセンサスノードが負荷状況に基づいて順番に並べられ、順番の中の最後の4つのコンセンサスノードがコンセンサスネットワークから選択され、4つの選択されたコンセンサスノードが本コンセンサス処理のためのコンセンサスサービスを提供する。

【0048】

さらに、本出願の本実装形態において、少なくとも1つのコンセンサスアルゴリズムが、コンセンサスネットワーク内の各コンセンサスノードに対して構成されることが可能である。この場合、ブロックチェーンノードは、コンセンサス処理に参加することになるコンセンサスノードの数量を決定した後、コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定する。

【0049】

ブロックチェーンノードは、コンセンサスポリシーに含まれるコンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされるコンセンサスアルゴリズムに基づいて決定し、決定されたコンセンサスノードからコンセンサスノードの数量を選択する。

【0050】

好ましくは、本出願の本実装形態において、ブロックチェーンノードがコンセンサスノードを選択した後、特に、決定されたコンセンサスポリシーに含まれるコンセンサスメカニズムが局所的なコンセンサスメカニズムであるとき、本コンセンサス結果の正当性を保証するために、ブロックチェーンノードは、選択されたコンセンサスノードがコンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、選択されたコンセンサスノードを他のブロックチェーンノードにブロードキャストする。ブロックチェーンノードが他のブロックチェーンノードからコンセンサス到達メッセージを受け取ると、このことは、選択されたコンセンサスノードがコンセンサス処理に参加することになるということに他のブロックチェーンノードが合意することを示し、コンセンサスノードによって得られたコンセンサス結果が正当であるとみなされることを意味する。そうでなければ、ブロックチェーンノードは、コンセンサスノードを再び選択する動作を行う必要がある。

【0051】

ステップ103。ブロックチェーンノードは、コンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送る。

【0052】

ブロックチェーンノードは、コンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータをブロードキャストする。

【0053】

好ましくは、本出願の本実装形態において、ブロックチェーンノードは、他のブロックチェーンノードによって送られたコンセンサス到達メッセージを受け取ると、選択されたコンセンサスノードにサービスデータを送る。

【0054】

サービスデータに対するコンセンサス処理が完了すると、ブロックチェーンノードは、選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果を受け取り、サービスデータに対するコンセンサス結果が全体的に共有される必要があると判断すると、ブロックチェーンノードは、コンセンサス処理に参加していない、コンセンサスネットワーク内のコンセンサスノードに、サービスデータに対するコンセンサス結果を送り、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。

【0055】

選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果を受け取ると、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要がないと判断すると、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。

【0056】

ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要があるかどうかについて、ステップ102において決定されたコンセンサスポリシーに含まれるデータ共有メカニズムに基づいて判断することができるということに留意する価値がある。データ共有メカニズムが全体的な共有メカニズムである場合、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要があると判断する。データ共有メカニズムが局所的な共有メカニズムである場合、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要がないと判断する。

【0057】

すなわち、ステップ102において決定されたコンセンサスポリシーは、コンセンサスアルゴリズムおよびコンセンサスメカニズムの他にデータ共有メカニズムを含む。コンセンサスメカニズムが全体的なコンセンサスメカニズムであるサービスデータに対応するデータ共有メカニズムは、全体的な共有メカニズムである。コンセンサスメカニズムが局所的なコンセンサスメカニズムであるサービスデータに対応するデータ共有メカニズムは、全体的な共有メカニズムまたは局所的な共有メカニズムであることが可能である。詳細は、ここでは省略される。

【0058】

本出願の本実装形態において提供される技術的解決策によれば、コンセンサスサービスを提供するコンセンサスノードは、コンセンサス手順が行われることになるサービスデータのサービスタイプに基づいて選択されることが可能であり、選択されたコンセンサスノードは、サービスデータに対するコンセンサス処理を行う。このようにして、様々なサービスに対するコンセンサス処理を行うために、いくつかのコンセンサスノードがコンセンサスネットワークから選択され、このことにより、コンセンサス処理に参加する大きな数量のコンセンサスノードによって引き起こされる長いコンセンサス処理時間の問題を軽減させる。このことは、コンセンサス処理時間を短縮するだけでなく、コンセンサス処理結果の正当性も保証することができ、このことにより、ブロックチェーンネットワークのサービスデータ処理効率を効果的に改善する。

【0059】

図2は、本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。方法は、以下のように説明されることが可能である。

【0060】

ステップ201。ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定する。

【0061】

本ステップの実装形態は、ステップ101の実装形態と同じであるか類似している。詳細は、ここでは省略される。

【0062】

ステップ202。ブロックチェーンノードは、受け取られたサービスデータのサービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定し、コンセンサスポリシーは、コンセンサスアルゴリズムまたはコンセンサスメカニズムのうちの少なくとも1つを含む。

【0063】

ステップ203。ブロックチェーンノードは、本コンセンサス処理が全体的に行われる必要があるかどうかを、コンセンサスポリシーに含まれるコンセンサスメカニズムに基づいて判断し、必要ならステップ204を行い、不要ならステップ206を行う。

【0064】

ステップ204。ブロックチェーンノードは、コンセンサスノードがサービスデータに対する全体的なコンセンサス処理を行うように、コンセンサスネットワーク内のコンセンサスノードにサービスデータをブロードキャストする。

【0065】

ステップ205。ブロックチェーンノードは、サービスデータに対するコンセンサス結果を受け取ると、サービスデータに対するコンセンサス結果をブロックチェーンに格納し、ここで、コンセンサス結果はコンセンサスノードによって送られる。

【0066】

ステップ206。ブロックチェーンノードは、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択する。

【0067】

ステップ207。ブロックチェーンノードは、選択されたコンセンサスノードがコンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、選択されたコンセンサスノードを他のブロックチェーンノードにブロードキャストする。

【0068】

ステップ208。ブロックチェーンノードは、他のブロックチェーンノードによって送られたコンセンサス到達メッセージを受け取ると、選択されたコンセンサスノードにサービスデータを送る。

【0069】

ステップ209。選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果を受け取ると、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要があるかどうかを判断し、必要ならステップ210を行い、不要ならをステップ211を行う。

【0070】

ステップ210。ブロックチェーンノードは、コンセンサス処理に参加していない、コンセンサスネットワーク内のコンセンサスノードに、サービスデータに対するコンセンサス結果を送り、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。

【0071】

ステップ211。ブロックチェーンノードは、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。

【0072】

図3は、本出願の1つの実装形態による、ブロックチェーンコンセンサスデバイスを示す概略構造図である。ブロックチェーンコンセンサスデバイスは、取得ユニット301、選択ユニット302、および送信ユニット303を含む。

【0073】

取得ユニット301は、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定する。

【0074】

選択ユニット302は、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択する。

【0075】

送信ユニット303は、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送る。

【0076】

本出願の別の実装形態において、選択ユニット302は、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択し、受け取られたサービスデータのサービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定することであって、コンセンサスポリシーがコンセンサスアルゴリズムを含む、決定することと、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択することと、を含む。

【0077】

本出願の別の実装形態において、選択ユニット302は、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択し、コンセンサス処理に参加することになるコンセンサスノードの数量を、コンセンサスアルゴリズムに基づいて決定することであって、数量が、コンセンサスアルゴリズムの所定の数量を満たす、決定することと、コンセンサスネットワークからコンセンサスノードの数量を選択することと、を含む。

【0078】

本出願の別の実装形態において、選択ユニット302は、コンセンサスネットワークからコンセンサスノードの数量を選択し、以下、すなわち、コンセンサスネットワークからコンセンサスノードの数量をランダムに選択すること、またはコンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、コンセンサスネットワークからコンセンサスノードの数量を選択すること、を含む。

【0079】

本出願の別の実装形態において、選択ユニット302は、コンセンサスネットワークからコンセンサスノードの数量を選択し、コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定することと、コンセンサスポリシーに含まれるコンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされるコンセンサスアルゴリズムに基づいて決定することと、決定されたコンセンサスノードからコンセンサスノードの数量を選択することと、を含む。

【0080】

本出願の別の実装形態において、ブロックチェーンコンセンサスデバイスは、処理ユニット304をさらに含む。

【0081】

処理ユニット304は、選択されたコンセンサスノードがコンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、選択されたコンセンサスノードにサービスデータが送られる前に、選択されたコンセンサスノードを他のブロックチェーンノードにブロードキャストする。

【0082】

送信ユニット303は、選択されたコンセンサスノードにサービスデータを送り、他のブロックチェーンノードによって送られたコンセンサス到達メッセージを受け取ると、選択されたコンセンサスノードにサービスデータを送ることを含む。

【0083】

本出願の別の実装形態において、ブロックチェーンコンセンサスデバイスは、判断ユニット305をさらに含む。

【0084】

選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果が受け取られるとき、サービスデータに対するコンセンサス結果が全体的に共有される必要があると判断すると、判断ユニット305は、コンセンサス処理に参加していない、コンセンサスネットワーク内のコンセンサスノードに、サービスデータに対するコンセンサス結果を送り、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。

【0085】

本出願の別の実装形態において、ブロックチェーンコンセンサスデバイスは、格納ユニット306をさらに含む。

【0086】

選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果が受け取られるとき、格納ユニット306は、サービスデータに対するコンセンサス結果が全体的に共有される必要がないということが判断されると、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。

【0087】

本出願の本実装形態において提供されるブロックチェーンコンセンサス処理デバイスは、ハードウェアまたはソフトウェアを使用することによって実装されることが可能であるということに留意する価値がある。このことは、ここでは限定されない。ブロックチェーンコンセンサス処理デバイスは、コンセンサス手順が行われることになるサービスデータのサービスタイプに基づいて、コンセンサスサービスを提供するコンセンサスノードを選択することができ、選択されたコンセンサスノードは、サービスデータに対するコンセンサス処理を行う。このようにして、様々なサービスに対するコンセンサス処理を行うために、いくつかのコンセンサスノードがコンセンサスネットワークから選択され、このことにより、コンセンサス処理に参加する大きな数量のコンセンサスノードによって引き起こされる長いコンセンサス処理時間の問題を軽減させる。このことは、コンセンサス処理時間を短縮するだけでなく、コンセンサス処理結果の正当性も保証することができ、このことにより、ブロックチェーンネットワークのサービスデータ処理効率を効果的に改善する。

【0088】

本出願の1つの実装形態は、ブロックチェーンコンセンサスデバイスをさらに提供し、メモリおよび少なくとも1つのプロセッサを含み、メモリがプログラムを格納し、少なくとも1つのプロセッサが、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定するステップと、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択するステップと、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送るステップと、を行うように構成される。

【0089】

プログラムによって実装される他の内容に対して、先の実装形態において説明された内容への参照が行われる。詳細は、ここでは省略される。

【0090】

1990年代において、技術的な改良が、ハードウェア改良(例えば、ダイオード、トランジスタ、またはスイッチなどの回路構造に対する改良)であるか、ソフトウェア改良(方法手順に対する改良)であるかは、明確に区別されることが可能である。しかし、技術が発展するにつれて、多くの方法手順に対する現在の改良は、ハードウェア回路構造への直接的な改良とみなされることが可能である。設計者は通常、改良された方法手順をハードウェア回路にプログラムし、対応するハードウェア回路構造を得る。したがって方法手順は、ハードウェアエンティティモジュールを使用することによって改良されることが可能である。例えば、プログラマブルロジックデバイス(PLD:programmable logic device)(例えば、フィールドプログラマブルゲートアレイ(FPGA))はこのような集積回路であり、PLDの論理機能は、デバイスプログラミングを通じてユーザによって決定される。設計者はプログラミングを行い、特定用途向け集積回路チップを設計して生み出すことをチップ製造業者にリクエストすることなく、デジタルシステムをPLDに「統合する」。さらに、現在のところ、集積回路チップを手動で製造する代わりに、「ロジックコンパイラ」ソフトウェアを使用することによって、このようなプログラミングが主として実装される。ロジックコンパイラソフトウェアは、プログラムを開発するため、および書くために使用されるソフトウェアコンパイラに類似している。元のコードは、コンパイルのための特定のプログラミング言語で書かれる必要がある。言語は、ハードウェア記述言語(HDL:hardware description language)と呼ばれる。Advanced Boolean Expression Language(ABEL)、Altera Hardware Description Language(AHDL)、Confluence、Cornell University Programming Language(CUPL)、HDCal、Java(登録商標) Hardware Description Language(JHDL)、Lava、Lola、MyHDL、PALASM、およびRuby Hardware Description Language(RHDL)など、多くのHDLがある。超高速集積回路ハードウェア記述言語(VHDL:very-high-speed integrated circuit hardware description language)およびVerilog2が最も一般的に使用される。いくつかの説明されたハードウェア記述言語を使用することによって方法手順が論理的にプログラムされ、集積回路にプログラムされると、論理的な方法手順を実装するハードウェア回路が容易に得られることが可能であるということも当業者は理解するはずである。

【0091】

コントローラは、任意の妥当な方法を使用することによって実装されることが可能である。例えば、コントローラは、マイクロプロセッサもしくはプロセッサ、あるいはマイクロプロセッサもしくはプロセッサ、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブルロジックコントローラ、またはビルトインマイクロプロセッサによって実行されることが可能な(ソフトウェアもしくはファームウェアなどの)コンピュータ可読プログラムコードを格納するコンピュータ可読媒体であることが可能である。コントローラの例は、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、およびSilicone Labs C8051F320などのマイクロプロセッサを含むがこれらに限定されない。メモリコントローラは、メモリの制御ロジックの一部として実装されることも可能である。コンピュータ可読プログラムコードを使用することによってコントローラを実装することの他に、ロジックプログラミングは、論理ゲート、スイッチ、特定用途向け集積回路、プログラマブルロジックコントローラ、およびビルトインマイクロコントローラの形で同じ機能をコントローラが実装できるようにするための方法ステップに対して行われることが可能であるということも当業者は知っている。したがってコントローラは、ハードウェア構成要素とみなされることが可能であり、コントローラに様々な機能を実装するように構成された装置は、ハードウェア構成要素内の構造とみなされることも可能である。または様々な機能を実装するように構成された装置は、方法を実装するソフトウェアモジュールと、ハードウェア構成要素内の構造の両方とみなされることさえ可能である。

【0092】

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

【0093】

説明の容易性のために、上記の装置は、様々なユニットに機能を分割することによって説明される。間違いなく、本出願が実装されるとき、各ユニットの機能は、1つまたは複数のソフトウェアおよび/またはハードウェアの中に実装されることが可能である。

【0094】

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

【0095】

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

【0096】

コンピュータまたは別のプログラマブルデータ処理デバイスに、特定の方式で動くように命令することができる、これらのコンピュータプログラム命令は、コンピュータ可読メモリに格納されることが可能であり、その結果、コンピュータ可読メモリに格納された命令は、命令デバイスを含むアーチファクトを生成する。命令デバイスは、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行する。

【0097】

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

【0098】

典型的な構成において、計算デバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。

【0099】

メモリは、非持続的メモリ、ランダムアクセスメモリ(RAM)、不揮発性メモリ、および/または例えばリードオンリメモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)といった、コンピュータ可読媒体内にある別の形式を含むことができる。メモリは、コンピュータ可読媒体の例である。

【0100】

コンピュータ可読媒体は、任意の方法または技術を使用することによって情報を格納することができる持続的媒体、非持続的媒体、可動媒体、および非可動媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであることが可能である。コンピュータストレージ媒体の例は、パラメータランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、電気的消去可能プログラマブルリードオンリメモリ(EEPROM)、フラッシュメモリまたは別のメモリ技術、コンパクトディスクリードオンリメモリ(CD-ROM)、デジタル多用途ディスク(DVD)または別の光ストレージ、カセット磁気テープ、磁気テープ/磁気ディスクストレージまたは別の磁気ストレージデバイスを含むがこれらに限定されない。コンピュータストレージ媒体は、計算デバイスによってアクセス可能な情報を格納するために使用されることが可能である。本明細書における定義に基づくと、コンピュータ可読媒体は、変調されたデータ信号および担体などの一時コンピュータ可読媒体(一時媒体)を含まない。

【0101】

用語「含む(include)」、「備える(comprise)」、またはこれらの他の任意の変形物は、非排他的な包含をカバーすることを意図するものであるので、要素の一覧を含む処理、方法、製品、もしくはデバイスは、これらの要素を含むだけでなく、明確に挙げられていない他の要素も含むということ、またはこのような処理、方法、製品、もしくはデバイスに固有の要素をさらに含むということにさらに留意する価値がある。さらなる制限なく、「〜を含む(includes a ...)」の前にある要素は、要素を含む処理、方法、製品、またはデバイスにおけるさらなる同一要素の存在を排除しない。

【0102】

本出願は、例えばプログラムモジュールといった、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明されることが可能である。一般に、プログラムモジュールは、特定のタスクを実行するか、特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。本出願は、分散コンピューティング環境において実践されることも可能である。分散コンピューティング環境において、タスクは、通信ネットワークを通じて接続されたリモート処理デバイスによって行われる。分散コンピューティング環境において、プログラムモジュールは、ストレージデバイスを含む、ローカルとリモート両方のコンピュータストレージ媒体に配置されることが可能である。

【0103】

本明細書における実装形態は漸進的な方式で説明される。実装形態の同じまたは類似の部分に対して、実装形態に対する参照が行われることが可能である。各実装形態は、他の実装形態との相違を重点的に取り扱う。特に、システムの実装形態は、方法の実装形態に基本的に類似しており、したがって簡単に説明される。関連部分に対しては、方法の実装形態における関連説明を参照されたい。

【0104】

先の実装形態は本出願の実装形態であり、本出願を限定することを意図するものではない。当業者は、本出願に対する様々な修正および変更を行うことができる。本出願の精神および原理から逸脱することなく行われる任意の修正、同等の置換、または改良は、本出願における特許請求の範囲の範囲に含まれる。

【符号の説明】

【0105】

301 取得ユニット
302 選択ユニット
303 送信ユニット
304 処理ユニット
305 判断ユニット
306 格納ユニット

【図1】

【図2】

【図3】