(57)【特許請求の範囲】
【請求項１】
ブロックチェーンコンセンサス方法であって、
ブロックチェーンノードにより、コンセンサス手順が行われることになるサービスデータを入手するステップと、
前記サービスデータのサービスタイプを決定するステップと、
前記ブロックチェーンノードにより、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択するステップと、
前記選択されたコンセンサスノードが前記サービスデータに対するコンセンサス処理を行うように、前記ブロックチェーンノードにより、前記選択されたコンセンサスノードに前記サービスデータを送るステップと、
を含む、ブロックチェーンコンセンサス方法。
【請求項２】
前記ブロックチェーンノードにより、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択する前記ステップが、
前記コンセンサスノードにより、受け取られたサービスデータの前記サービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定するステップであって、前記コンセンサスポリシーがコンセンサスアルゴリズムを含む、ステップと、
前記ブロックチェーンノードにより、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択するステップと、
を含む、請求項1に記載のブロックチェーンコンセンサス方法。
【請求項３】
前記ブロックチェーンノードにより、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択する前記ステップが、
前記ブロックチェーンノードにより、前記コンセンサス処理に参加することになるコンセンサスノードの数量を、前記コンセンサスアルゴリズムに基づいて決定するステップであって、前記数量が、前記コンセンサスアルゴリズムの所定の数量を満たす、ステップと、
前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択するステップと、
を含む、請求項2に記載のブロックチェーンコンセンサス方法。
【請求項４】
前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択する前記ステップが、
前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量をランダムに選択するステップ、または
前記ブロックチェーンノードにより、前記コンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択するステップ
を含む、請求項3に記載のブロックチェーンコンセンサス方法。
【請求項５】
前記ブロックチェーンノードにより、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択する前記ステップが、
前記ブロックチェーンノードにより、前記コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定するステップと、
前記ブロックチェーンノードにより、前記コンセンサスポリシーに含まれる前記コンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされる前記コンセンサスアルゴリズムに基づいて決定するステップと、
前記決定されたコンセンサスノードからコンセンサスノードの前記数量を選択するステップと、
を含む、請求項3に記載のブロックチェーンコンセンサス方法。
【請求項６】
前記ブロックチェーンノードにより、前記選択されたコンセンサスノードに前記サービスデータを送る前記ステップの前に、前記方法が、
前記選択されたコンセンサスノードが前記コンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、前記ブロックチェーンノードにより、前記選択されたコンセンサスノードを前記他のブロックチェーンノードにブロードキャストするステップをさらに含み、
前記ブロックチェーンノードにより、前記選択されたコンセンサスノードに前記サービスデータを送る前記ステップが、
前記ブロックチェーンノードにより、前記他のブロックチェーンノードによって送られたコンセンサス到達メッセージの受け取りに応答して、前記選択されたコンセンサスノードに前記サービスデータを送るステップを含む、請求項1から5のいずれか一項に記載のブロックチェーンコンセンサス方法。
【請求項７】
前記ブロックチェーンノードにより、前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果の受け取りに応答して、および前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要があるという判断に応答して、前記コンセンサス処理に参加していない、前記コンセンサスネットワーク内のコンセンサスノードに前記サービスデータに対する前記コンセンサス結果を送り、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納するステップをさらに含む、請求項6に記載のブロックチェーンコンセンサス方法。
【請求項８】
前記ブロックチェーンノードにより、前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果の受け取りに応答して、前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要がないという判断に応答して、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納するステップをさらに含む、請求項6に記載のブロックチェーンコンセンサス方法。
【請求項９】
ブロックチェーンコンセンサスデバイスであって、
取得ユニット、選択ユニット、および送信ユニットを備え、
前記取得ユニットが、コンセンサス手順が行われることになるサービスデータを入手し、前記サービスデータのサービスタイプを決定し、
前記選択ユニットが、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択し、
前記送信ユニットが、前記選択されたコンセンサスノードが前記サービスデータに対するコンセンサス処理を行うように、前記選択されたコンセンサスノードに前記サービスデータを送る、ブロックチェーンコンセンサスデバイス。
【請求項１０】
前記選択ユニットが、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいて前記コンセンサスネットワークから選択することが、
受け取られたサービスデータの前記サービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定することであって、前記コンセンサスポリシーがコンセンサスアルゴリズムを含む、前記決定することと、
前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択することと、
を含む、請求項9に記載のブロックチェーンコンセンサスデバイス。
【請求項１１】
前記選択ユニットが、前記コンセンサスサービスを提供する前記少なくとも1つのコンセンサスノードを、前記コンセンサスアルゴリズムに基づいて前記コンセンサスネットワークから選択することが、
前記コンセンサス処理に参加することになるコンセンサスノードの数量を、前記コンセンサスアルゴリズムに基づいて決定することであって、前記数量が、前記コンセンサスアルゴリズムの所定の数量を満たす、前記決定することと、
前記コンセンサスネットワークからコンセンサスノードの前記数量を選択することと、
を含む、請求項10に記載のブロックチェーンコンセンサスデバイス。
【請求項１２】
前記選択ユニットが、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択することが、
前記コンセンサスネットワークからコンセンサスノードの前記数量をランダムに選択すること、または
前記コンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択すること、
を含む、請求項11に記載のブロックチェーンコンセンサスデバイス。
【請求項１３】
前記選択ユニットが、前記コンセンサスネットワークからコンセンサスノードの前記数量を選択することが、
前記コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定することと、
前記コンセンサスポリシーに含まれる前記コンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされる前記コンセンサスアルゴリズムに基づいて決定することと、
前記決定されたコンセンサスノードから前記コンセンサスノードの数量を選択することと、
を含む、請求項11に記載のブロックチェーンコンセンサスデバイス。
【請求項１４】
処理ユニットをさらに含み、
前記処理ユニットが、前記選択されたコンセンサスノードが前記コンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、前記選択されたコンセンサスノードに前記サービスデータが送られる前に、前記選択されたコンセンサスノードを前記他のブロックチェーンノードにブロードキャストすることを含み、
前記送信ユニットが、前記選択されたコンセンサスノードに前記サービスデータを送ることが、
前記他のブロックチェーンノードによって送られたコンセンサス到達メッセージの受け取りに応答して、前記選択されたコンセンサスノードに前記サービスデータを送ることを含む、請求項9から13のいずれか一項に記載のブロックチェーンコンセンサスデバイス。
【請求項１５】
判断ユニットをさらに備え、
前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果が受け取られたという判断に応答して、および前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要があるという判断に応答して、前記判断ユニットが、前記コンセンサス処理に参加していない、前記コンセンサスネットワーク内のコンセンサスノードに、前記サービスデータに対する前記コンセンサス結果を送り、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納する、請求項14に記載のブロックチェーンコンセンサスデバイス。
【請求項１６】
格納ユニットをさらに備え、
前記選択されたコンセンサスノードによって送られた、前記サービスデータに対するコンセンサス結果が受け取られたという判断に応答して、前記格納ユニットが、前記サービスデータに対する前記コンセンサス結果が全体的に共有される必要がないという判断に応答して、前記サービスデータに対する前記コンセンサス結果をブロックチェーンに格納する、請求項14に記載のブロックチェーンコンセンサスデバイス。
【請求項１７】
ブロックチェーンコンセンサスデバイスであって、
メモリおよび少なくとも1つのプロセッサを備え、前記メモリが、プログラムを格納し、前記少なくとも1つのプロセッサが、
コンセンサス手順が行われることになるサービスデータを入手し、前記サービスデータのサービスタイプを決定するステップと、
コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、前記サービスタイプに基づいてコンセンサスネットワークから選択するステップと、
前記選択されたコンセンサスノードが前記サービスデータに対するコンセンサス処理を行うように、前記選択されたコンセンサスノードに前記サービスデータを送るステップと、
を行うように構成された、ブロックチェーンコンセンサスデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、インターネット情報処理技術の分野、およびコンピュータ技術の分野に関し、詳細には、ブロックチェーンコンセンサス方法およびデバイスに関する。
【背景技術】
【０００２】
分散型台帳技術とも呼ばれるブロックチェーン技術は、分散型インターネットデータベース技術である。ブロックチェーン技術に基づいて構築されたネットワークは、ブロックチェーンネットワークと呼ばれることが可能である。ブロックチェーンネットワークは、ネットワークノード(ブロックチェーンノードと呼ばれることも可能であり、以下では略してノードと呼ばれる)を含む。各ノードは、少なくとも1つのブロックチェーンに対応し、各ブロックチェーンは、少なくとも1つのブロックを含む。ブロックチェーンネットワーク(またはブロックチェーン技術)には、非集中化、透明性、改ざん耐性、および信用性という特徴がある。これらの特徴に基づいて、ブロックチェーン技術は、ますます多くの分野において利用される。
【０００３】
サービスデータをブロックチェーンに記録する処理(すなわち、サービスデータをブロックチェーンネットワークに格納する処理)は、取扱フェーズ、コンセンサスフェーズ、および格納フェーズという3つのフェーズを含む。取扱フェーズは、ブロックチェーンネットワーク内の一定のブロックチェーンノードが、ブロックチェーンに記録されることになるサービスデータを受け取ること、およびブロックチェーンノードが、サービスデータを取り扱うこととして理解されることが可能である。コンセンサスフェーズは、ブロックチェーンノードがサービスデータを取り扱った後、ブロックチェーンネットワーク内の別のブロックチェーンノードが、サービスデータに対するコンセンサス処理に参加する必要があることとして理解されることが可能である。格納フェーズは、サービスデータに対するコンセンサスが得られた後に始まる。格納フェーズは、コンセンサスが得られたサービスデータをブロックチェーンノードがブロックチェーンに記録することとして理解されることが可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
サービスデータをブロックチェーンに記録する処理に含まれる3つのフェーズの中でも、コンセンサスフェーズは、ブロックチェーンネットワーク内の別のブロックチェーンノードの参加を必要とする。コンセンサス処理がサービスデータに対して行われているとき、コンセンサス処理に参加するブロックチェーンノードが多くなると、コンセンサス処理時間が長くなるということが研究で発見された。必然的に、サービスデータに対して行われるコンセンサス処理の効率は低下する。
【課題を解決するための手段】
【０００５】
したがって、本出願の実装形態は、既存技術における低いコンセンサス処理効率の問題を軽減させるためのブロックチェーンコンセンサス方法およびデバイスを提供する。
【０００６】
本出願の実装形態において、以下の技術的解決策が採用される。
【０００７】
本出願の1つの実装形態は、ブロックチェーンコンセンサス方法を提供し、ブロックチェーンノードにより、コンセンサス手順が行われることになるサービスデータを入手するステップと、サービスデータのサービスタイプを決定するステップと、ブロックチェーンノードにより、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択するステップと、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、ブロックチェーンノードにより、選択されたコンセンサスノードにサービスデータを送るステップと、を含む。
【０００８】
本出願の1つの実装形態は、ブロックチェーンコンセンサスデバイスをさらに提供し、取得ユニット、選択ユニット、および送信ユニットを含み、取得ユニットが、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定し、選択ユニットが、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択し、送信ユニットが、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送る。
【０００９】
本出願の1つの実装形態は、ブロックチェーンコンセンサスデバイスをさらに提供し、メモリおよび少なくとも1つのプロセッサを含み、メモリが、プログラムを格納し、少なくとも1つのプロセッサが、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定するステップと、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択するステップと、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送るステップと、を行うように構成される。
【００１０】
本出願の実装形態において採用される前述の技術的解決策のうちの少なくとも1つは、本出願の実装形態において、コンセンサス手順が行われることになるサービスデータのサービスタイプに基づいて、コンセンサスサービスを提供するコンセンサスノードが選択されることが可能であること、およびサービスデータに対するコンセンサス処理を、選択されたコンセンサスノードが行うこと、という有益な効果をもたらすことができる。このようにして、様々なサービスに対するコンセンサス処理を行うために、いくつかのコンセンサスノードがコンセンサスネットワークから選択され、このことにより、コンセンサス処理に参加する大きな数量のコンセンサスノードによって引き起こされる長いコンセンサス処理時間の問題を軽減させる。このことは、コンセンサス処理時間を短縮するだけでなく、コンセンサス処理結果の正当性も保証することができ、このことにより、ブロックチェーンネットワークのサービスデータ処理効率を効果的に改善する。
【００１１】
ここで説明される添付の図面は、本出願についてさらに理解することを意図するものであり、本出願の一部である。本出願の例証的な実装形態およびこれらの説明は、本出願を説明することを意図するものであり、本出願に対する限定ではない。
【図面の簡単な説明】
【００１２】
【図１】本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。
【図２】本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。
【図３】本出願の1つの実装形態による、ブロックチェーンコンセンサスデバイスを示す概略構造図である。
【発明を実施するための形態】
【００１３】
本出願の目的、技術的解決策、および長所を明らかにするために、以下は、本出願の特定の実装形態および添付の図面を参照しながら、本出願の技術的解決策を明確かつ包括的に説明する。明らかに、説明される実装形態は、本出願の実装形態のすべてではなく、いくつかにすぎない。創造的な努力なく、本出願の実装形態に基づいて当業者によって得られた他のすべての実装形態は、本出願の保護範囲に含まれる。
【００１４】
本出願の実装形態において提供される技術的解決策が、添付の図面を参照しながら下記で詳細に説明される。
【００１５】
本出願の実装形態において説明されるブロックチェーンネットワークおよびコンセンサスネットワークは、同じネットワークであることが可能である。言い換えると、ネットワーク内のブロックチェーンノードは、コンセンサスノードと呼ばれることも可能である。ネットワーク内でサービスデータを取り扱うノードは、サービス取扱ノードと呼ばれることが可能であり、サービスデータに対するコンセンサス処理を始める。ネットワークは、このノードの他に複数のノードを含む。これらのノードは、これらのノードがサービスデータに対するコンセンサス処理に参加すると、コンセンサスノードと呼ばれることが可能である。さらに、これらのノードは、サービス取扱ノードとして機能することもできる。例えば、ブロックチェーンネットワークは、5つのノード(ノード1、ノード2、ノード3、ノード4、およびノード5)を含み、各ノードは、サービス取扱ノードとコンセンサスノードの両方として機能することができる。ノード1がサービスデータを取り扱う場合、ノード1は、サービス取扱ノードとして機能し、ノード2、ノード3、ノード4、およびノード5は、サービスデータのためのコンセンサスノードとして機能し、サービスデータに対するコンセンサス処理に参加する。
【００１６】
本出願の実装形態において説明されるブロックチェーンネットワークには、コンセンサスネットワークを含むことができる。この場合、コンセンサスネットワークに含まれるコンセンサスノードは、ブロックチェーンネットワーク内のブロックチェーンノードによって始められたコンセンサス要求に対するコンセンサス処理を行うことができる。例えば、ブロックチェーンネットワークは、5つのノード(ノード1、ノード2、ノード3、ノード4、およびノード5)を含み、ここで、ノード2、ノード4、およびノード5は、コンセンサスネットワーク内のコンセンサスノードである。この場合、ノード2、ノード4、およびノード5は、ノード1またはノード3によって始められたコンセンサス要求に対するコンセンサス処理を行うことができる。ノード1およびノード3は、ここでは、サービスデータを取り扱うためのノードとして機能し、取り扱われるサービスデータに対するコンセンサス処理を行うことを、コンセンサスネットワーク内のコンセンサスノードにリクエストすることができる。すなわち、コンセンサスノードは、サービスデータの取扱いに参加しなくてよい。
【００１７】
本出願の実装形態において、コンセンサスノードにコンセンサス結果が格納されるかどうかは限定されず、実際の要求に基づいて判断されてよい。コンセンサスノードにコンセンサス結果が格納される場合と、コンセンサスノードにコンセンサス結果が格納されない場合の両方が、本出願の実装形態の保護範囲に含まれる。
【００１８】
図1は、本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。方法は、以下のように説明されることが可能である。
【００１９】
ステップ101。ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定する。
【００２０】
本出願の本実装形態において、ブロックチェーンノードは、サービスデータを取り扱うためのノード、コンセンサス処理を始めるためのノード、または本コンセンサス処理のための1次ノードとして機能することができ、このことは、ここでは限定されない。
【００２１】
ブロックチェーンノードが、サービスデータを取り扱うためのノードとして機能する場合、ブロックチェーンノードは、取り扱われてローカルに格納されたサービスデータから、コンセンサス手順が行われることになるサービスデータとしていくつかのサービスデータを取得し、取得されたサービスデータに対してその後始められるコンセンサス処理を容易にすることができる。
【００２２】
ブロックチェーンノードが、サービスデータを取り扱うためのノードではなく、本コンセンサス処理のための1次ノードとして機能する場合、ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータのリソースプールからいくつかのサービスデータを取得し、コンセンサス手順が行われることになるサービスデータとして取得されたサービスデータを使用して、取得されたサービスデータに対してその後始められるコンセンサス処理を容易にすることができる。
【００２３】
コンセンサス手順が行われることになるサービスデータを入手した後、ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを生成するサービスを決定し、コンセンサス手順が行われることになるサービスデータに対応するサービスタイプをさらに決定する。
【００２４】
サービスは、様々なサービス機能に基づいて様々なタイプに分類されることが可能である。例えば、サービスは、順序タイプ(順序生成フェーズにおいて生成されたサービスデータに対応するサービスタイプは順序タイプである)、または支払タイプ(支払情報を含むサービスデータに対応するサービスタイプは支払タイプである)のものであることが可能である。サービスは一方、異なるサービス内容に基づいて分類されることが可能である。例えば、サービスは、カード発行タイプ(カード発行情報を含むサービスデータに対応するサービスタイプはカード発行タイプである)、または取引タイプ(取引情報を含むサービスデータに対応するサービスタイプは取引タイプである)のものであることが可能である。サービスタイプの分類原理は、ここでは限定されない。
【００２５】
ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを入手した後に、各サービスデータに対応するサービスタイプを決定する。実際には、サービスタイプの適用範囲の中には重複するものもあるので、各サービスデータに対応するサービスタイプを決定するときに、ブロックチェーンノードは、コンセンサス手順が行われることになる入手されたサービスデータに対応するサービスタイプとして、クラスタ方式で(または、ここでは限定されない別の方式で)、より広い適用範囲を有するサービスタイプを決定することができる。
【００２６】
例えば、コンセンサス手順が行われることになる入手されたサービスデータに対応するサービスタイプは、順序タイプおよび支払タイプを含む。順序タイプのサービスデータ、および支払タイプのサービスデータの両方が、サービス内容に基づく取引タイプに属するので、コンセンサス手順が行われることになるサービスデータに対応するサービスタイプは、取引タイプとして判断される。
【００２７】
1つまたは複数のサービスタイプが、ここで決定されることが可能であるということに留意する価値がある。複数のサービスタイプが決定される場合、その後のステップにおける1つのコンセンサスアルゴリズムに複数のサービスタイプが対応することが可能である。または複数のサービスタイプが複数のコンセンサスアルゴリズムに対応することが可能であるが、複数のサービスタイプに適用可能な1つのコンセンサスアルゴリズムは、複数のコンセンサスアルゴリズムから決定されることが可能である。
【００２８】
ステップ102。ブロックチェーンノードは、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択する。
【００２９】
本出願の本実装形態において、ブロックチェーンノードはまず、受け取られたサービスデータのサービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定し、ここでコンセンサスポリシーは、コンセンサスアルゴリズムを含む。
【００３０】
コンセンサスポリシーは、一定のサービスまたはいくつかのサービスによって生成されたサービスデータに対するコンセンサス処理を行う方法である。具体的に言うと、コンセンサスポリシーは、指定のサービスタイプに対応するサービスによって生成されるサービスデータに対するコンセンサス処理を行うために使用されるコンセンサスアルゴリズムを指定する。
【００３１】
コンセンサスポリシーは、ここでは、使用されるコンセンサスアルゴリズムを含むことができ、コンセンサスメカニズムをさらに含むことができる。コンセンサスメカニズムは、ここでは、コンセンサスネットワーク内のコンセンサスノードが、全体的なコンセンサス処理を行う必要があるかどうかを含む。全体的なコンセンサス処理を行う必要がある場合、コンセンサスポリシーに含まれるコンセンサスメカニズムは、全体的なコンセンサスメカニズムである。全体的なコンセンサス処理を行う必要がない場合、コンセンサスポリシーに含まれるコンセンサスメカニズムは、局所的なコンセンサスメカニズムである。
【００３２】
本出願の本実装形態におけるコンセンサスポリシーに含まれるコンセンサスアルゴリズムは、プルーフ・オブ・ワーク(PoW:Proof of Work)アルゴリズム、プルーフ・オブ・ステーク(PoS:Proof of Stake)アルゴリズム、デリゲーテッド・プルーフ・オブ・ステーク(DPoS:Delegated Proof of Stake)アルゴリズム、プラクティカル・ビザンチン・フォールト・トレランス(PBFT:Practical Byzantine Fault Tolerance)アルゴリズム、およびデリゲーテッド・ビザンチン・フォールト・トレランス(DBFT:Delegated Byzantine Fault Tolerance)アルゴリズムを含むがこれらに限定されない。
【００３３】
同じコンセンサスポリシーまたは異なるコンセンサスポリシーに、様々なサービスタイプが対応することが可能であるということに留意する価値がある。本出願の本実装形態において、サービスデータ処理効率を保証するために、様々なコンセンサスアルゴリズムが、様々なサービスタイプのサービスデータに対して使用されることが可能である。様々なサービスタイプおよび動作原理の特徴、ならびに様々なコンセンサスアルゴリズムの長所および短所に基づいて、比較的適用可能で、処理効率を保証できるコンセンサスアルゴリズムが様々なサービスタイプに対して決定されることが可能である。マッピング関係は、サービスタイプとコンセンサスアルゴリズムの間で確立されることが可能である。
【００３４】
例えばPBFTアルゴリズムは、比較的大量のデータを含み、攻撃に対して脆弱ではない順序タイプのサービスデータに対するコンセンサス処理を行うために使用されることが可能であり、PoWアルゴリズムは、攻撃に対して脆弱な支払タイプのサービスデータに対するコンセンサス処理を行うために使用されることが可能である。サービスタイプに対するコンセンサスアルゴリズムは、ここでは限定されない。
【００３５】
さらにブロックチェーンノードは、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択する。
【００３６】
ブロックチェーンノードは、コンセンサス処理に参加することになるコンセンサスノードの数量を、コンセンサスアルゴリズムに基づいて決定し、この数量が、コンセンサスアルゴリズムの所定の数量を満たし、コンセンサスネットワークからコンセンサスノードの数量を選択する。
【００３７】
様々なコンセンサスアルゴリズムが様々な動作原理を有するので、コンセンサス処理に参加することが許されるコンセンサスノードの数量は、コンセンサスアルゴリズムに応じて変化する。例えば、PoWアルゴリズムに対して、ネットワーク内のすべてのノードは、1回のコンセンサス処理に参加するコンセンサスノードとして機能する必要がある。別の例として、PBFTアルゴリズムに対して、最低4つのノードが、1回のコンセンサス処理に参加するコンセンサスノードとして機能する必要がある。
【００３８】
したがって、本出願の本実装形態において、コンセンサス処理に参加することになるコンセンサスノードは、コンセンサスアルゴリズムの最低投票設定によって必要とされるコンセンサスノードの数量に基づいて選択されることが可能である。
【００３９】
一方、本出願の本実装形態において、コンセンサス処理に参加することになるコンセンサスノードの数量は、(ランダム化アルゴリズムなどの)指定のアルゴリズムに基づいて決定されることが可能である。
【００４０】
例えば、コンセンサス処理に参加することになるコンセンサスノードの数量は次のように決定される。
【００４１】
R=ノード番号%ノードの数量。すなわち、Rは、ノード番号がノードの数量で割られるときの余りを計算することによって得られることが可能である。
【００４２】
Rは、コンセンサス処理に参加することになるコンセンサスノードの決定された数量である。ノード番号は、ステップ101において説明された、コンセンサス手順が行われることになるサービスデータを得るブロックチェーンノードの番号である。ノードの数量は、ブロックチェーンネットワークに含まれるブロックチェーンノードの数量(またはコンセンサスネットワークに含まれるコンセンサスノードの数量)である。
【００４３】
ブロックチェーンネットワーク内の各ブロックチェーンノードは、予め番号を付けられることが可能であるということに留意する価値がある。このようにして、ステップ101において説明された、コンセンサス手順が行われることになるサービスデータを得るブロックチェーンノードの番号は、迅速に決定されることが可能である。コンセンサス処理に参加することになるコンセンサスノードの数量が先の方程式を使用することによって決定されると、コンセンサス処理に参加することになるコンセンサスノードの決定された数量は、サービスデータを取り扱うためのノードの番号に応じて、同じサービスタイプのサービスデータに対して変化する。または様々なサービスタイプのサービスデータを取り扱うためのノードが、予め決定されることが可能である。言い換えると、サービスタイプのサービスデータを取り扱うためのノードは、ブロックチェーンネットワーク内の指定されたブロックチェーンノードである。この場合、上記で決定されたような、コンセンサス処理に参加するコンセンサスノードの数量は、同じサービスタイプのサービスデータに対して同じであることが可能である。
【００４４】
さらに、方程式におけるノード番号は一方、サービスタイプ番号であることが可能である。様々なサービスタイプの番号が予め決定されることが可能である。この場合、同じサービスタイプのサービスデータに対して、コンセンサス手順が行われることになるサービスデータに対応するサービスタイプが、ステップ101において決定された後、サービスタイプに対応するサービスタイプ番号がさらに決定されることが可能であり、その後、コンセンサス処理に参加することになるコンセンサスノードの数量は、先の方程式に基づいて決定されることが可能である。
【００４５】
コンセンサス処理に参加することになるコンセンサスノードの数量が決定された後、次のように、コンセンサスノードの数量がコンセンサスネットワークから選択されることが可能である。
【００４６】
ブロックチェーンノードがコンセンサスネットワークからコンセンサスノードの数量をランダムに選択するか、コンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、ブロックチェーンノードがコンセンサスネットワークからコンセンサスノードの数量を選択する。
【００４７】
例えば、コンセンサス処理に参加することになるコンセンサスノードの数量が4と決定される。この場合、4つのコンセンサスノードは、コンセンサスネットワークからランダムに選択されることが可能であり、4つの選択されたコンセンサスノードは、本コンセンサス処理のためのコンセンサスサービスを提供する。一方、サービスデータ処理効率を改善するために、コンセンサスネットワーク内のコンセンサスノードの負荷状況が判断されることが可能であり、コンセンサスネットワーク内のコンセンサスノードが負荷状況に基づいて順番に並べられ、順番の中の最後の4つのコンセンサスノードがコンセンサスネットワークから選択され、4つの選択されたコンセンサスノードが本コンセンサス処理のためのコンセンサスサービスを提供する。
【００４８】
さらに、本出願の本実装形態において、少なくとも1つのコンセンサスアルゴリズムが、コンセンサスネットワーク内の各コンセンサスノードに対して構成されることが可能である。この場合、ブロックチェーンノードは、コンセンサス処理に参加することになるコンセンサスノードの数量を決定した後、コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定する。
【００４９】
ブロックチェーンノードは、コンセンサスポリシーに含まれるコンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされるコンセンサスアルゴリズムに基づいて決定し、決定されたコンセンサスノードからコンセンサスノードの数量を選択する。
【００５０】
好ましくは、本出願の本実装形態において、ブロックチェーンノードがコンセンサスノードを選択した後、特に、決定されたコンセンサスポリシーに含まれるコンセンサスメカニズムが局所的なコンセンサスメカニズムであるとき、本コンセンサス結果の正当性を保証するために、ブロックチェーンノードは、選択されたコンセンサスノードがコンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、選択されたコンセンサスノードを他のブロックチェーンノードにブロードキャストする。ブロックチェーンノードが他のブロックチェーンノードからコンセンサス到達メッセージを受け取ると、このことは、選択されたコンセンサスノードがコンセンサス処理に参加することになるということに他のブロックチェーンノードが合意することを示し、コンセンサスノードによって得られたコンセンサス結果が正当であるとみなされることを意味する。そうでなければ、ブロックチェーンノードは、コンセンサスノードを再び選択する動作を行う必要がある。
【００５１】
ステップ103。ブロックチェーンノードは、コンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送る。
【００５２】
ブロックチェーンノードは、コンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータをブロードキャストする。
【００５３】
好ましくは、本出願の本実装形態において、ブロックチェーンノードは、他のブロックチェーンノードによって送られたコンセンサス到達メッセージを受け取ると、選択されたコンセンサスノードにサービスデータを送る。
【００５４】
サービスデータに対するコンセンサス処理が完了すると、ブロックチェーンノードは、選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果を受け取り、サービスデータに対するコンセンサス結果が全体的に共有される必要があると判断すると、ブロックチェーンノードは、コンセンサス処理に参加していない、コンセンサスネットワーク内のコンセンサスノードに、サービスデータに対するコンセンサス結果を送り、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。
【００５５】
選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果を受け取ると、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要がないと判断すると、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。
【００５６】
ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要があるかどうかについて、ステップ102において決定されたコンセンサスポリシーに含まれるデータ共有メカニズムに基づいて判断することができるということに留意する価値がある。データ共有メカニズムが全体的な共有メカニズムである場合、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要があると判断する。データ共有メカニズムが局所的な共有メカニズムである場合、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要がないと判断する。
【００５７】
すなわち、ステップ102において決定されたコンセンサスポリシーは、コンセンサスアルゴリズムおよびコンセンサスメカニズムの他にデータ共有メカニズムを含む。コンセンサスメカニズムが全体的なコンセンサスメカニズムであるサービスデータに対応するデータ共有メカニズムは、全体的な共有メカニズムである。コンセンサスメカニズムが局所的なコンセンサスメカニズムであるサービスデータに対応するデータ共有メカニズムは、全体的な共有メカニズムまたは局所的な共有メカニズムであることが可能である。詳細は、ここでは省略される。
【００５８】
本出願の本実装形態において提供される技術的解決策によれば、コンセンサスサービスを提供するコンセンサスノードは、コンセンサス手順が行われることになるサービスデータのサービスタイプに基づいて選択されることが可能であり、選択されたコンセンサスノードは、サービスデータに対するコンセンサス処理を行う。このようにして、様々なサービスに対するコンセンサス処理を行うために、いくつかのコンセンサスノードがコンセンサスネットワークから選択され、このことにより、コンセンサス処理に参加する大きな数量のコンセンサスノードによって引き起こされる長いコンセンサス処理時間の問題を軽減させる。このことは、コンセンサス処理時間を短縮するだけでなく、コンセンサス処理結果の正当性も保証することができ、このことにより、ブロックチェーンネットワークのサービスデータ処理効率を効果的に改善する。
【００５９】
図2は、本出願の1つの実装形態による、ブロックチェーンコンセンサス方法を示す概略流れ図である。方法は、以下のように説明されることが可能である。
【００６０】
ステップ201。ブロックチェーンノードは、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定する。
【００６１】
本ステップの実装形態は、ステップ101の実装形態と同じであるか類似している。詳細は、ここでは省略される。
【００６２】
ステップ202。ブロックチェーンノードは、受け取られたサービスデータのサービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定し、コンセンサスポリシーは、コンセンサスアルゴリズムまたはコンセンサスメカニズムのうちの少なくとも1つを含む。
【００６３】
ステップ203。ブロックチェーンノードは、本コンセンサス処理が全体的に行われる必要があるかどうかを、コンセンサスポリシーに含まれるコンセンサスメカニズムに基づいて判断し、必要ならステップ204を行い、不要ならステップ206を行う。
【００６４】
ステップ204。ブロックチェーンノードは、コンセンサスノードがサービスデータに対する全体的なコンセンサス処理を行うように、コンセンサスネットワーク内のコンセンサスノードにサービスデータをブロードキャストする。
【００６５】
ステップ205。ブロックチェーンノードは、サービスデータに対するコンセンサス結果を受け取ると、サービスデータに対するコンセンサス結果をブロックチェーンに格納し、ここで、コンセンサス結果はコンセンサスノードによって送られる。
【００６６】
ステップ206。ブロックチェーンノードは、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択する。
【００６７】
ステップ207。ブロックチェーンノードは、選択されたコンセンサスノードがコンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、選択されたコンセンサスノードを他のブロックチェーンノードにブロードキャストする。
【００６８】
ステップ208。ブロックチェーンノードは、他のブロックチェーンノードによって送られたコンセンサス到達メッセージを受け取ると、選択されたコンセンサスノードにサービスデータを送る。
【００６９】
ステップ209。選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果を受け取ると、ブロックチェーンノードは、サービスデータに対するコンセンサス結果が全体的に共有される必要があるかどうかを判断し、必要ならステップ210を行い、不要ならをステップ211を行う。
【００７０】
ステップ210。ブロックチェーンノードは、コンセンサス処理に参加していない、コンセンサスネットワーク内のコンセンサスノードに、サービスデータに対するコンセンサス結果を送り、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。
【００７１】
ステップ211。ブロックチェーンノードは、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。
【００７２】
図3は、本出願の1つの実装形態による、ブロックチェーンコンセンサスデバイスを示す概略構造図である。ブロックチェーンコンセンサスデバイスは、取得ユニット301、選択ユニット302、および送信ユニット303を含む。
【００７３】
取得ユニット301は、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定する。
【００７４】
選択ユニット302は、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択する。
【００７５】
送信ユニット303は、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送る。
【００７６】
本出願の別の実装形態において、選択ユニット302は、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択し、受け取られたサービスデータのサービスタイプに対応するコンセンサスポリシーを、サービスタイプとコンセンサスポリシーの間の所定のマッピング関係に基づいて決定することであって、コンセンサスポリシーがコンセンサスアルゴリズムを含む、決定することと、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択することと、を含む。
【００７７】
本出願の別の実装形態において、選択ユニット302は、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、コンセンサスアルゴリズムに基づいてコンセンサスネットワークから選択し、コンセンサス処理に参加することになるコンセンサスノードの数量を、コンセンサスアルゴリズムに基づいて決定することであって、数量が、コンセンサスアルゴリズムの所定の数量を満たす、決定することと、コンセンサスネットワークからコンセンサスノードの数量を選択することと、を含む。
【００７８】
本出願の別の実装形態において、選択ユニット302は、コンセンサスネットワークからコンセンサスノードの数量を選択し、以下、すなわち、コンセンサスネットワークからコンセンサスノードの数量をランダムに選択すること、またはコンセンサスネットワーク内のコンセンサスノードの負荷に基づいて、コンセンサスネットワークからコンセンサスノードの数量を選択すること、を含む。
【００７９】
本出願の別の実装形態において、選択ユニット302は、コンセンサスネットワークからコンセンサスノードの数量を選択し、コンセンサスネットワーク内の各コンセンサスノードによってサポートされるコンセンサスアルゴリズムを決定することと、コンセンサスポリシーに含まれるコンセンサスアルゴリズムをサポートするコンセンサスノードを、各コンセンサスノードによってサポートされるコンセンサスアルゴリズムに基づいて決定することと、決定されたコンセンサスノードからコンセンサスノードの数量を選択することと、を含む。
【００８０】
本出願の別の実装形態において、ブロックチェーンコンセンサスデバイスは、処理ユニット304をさらに含む。
【００８１】
処理ユニット304は、選択されたコンセンサスノードがコンセンサスサービスを提供することに合意すべきかどうかについて他のブロックチェーンノードが投票するように、選択されたコンセンサスノードにサービスデータが送られる前に、選択されたコンセンサスノードを他のブロックチェーンノードにブロードキャストする。
【００８２】
送信ユニット303は、選択されたコンセンサスノードにサービスデータを送り、他のブロックチェーンノードによって送られたコンセンサス到達メッセージを受け取ると、選択されたコンセンサスノードにサービスデータを送ることを含む。
【００８３】
本出願の別の実装形態において、ブロックチェーンコンセンサスデバイスは、判断ユニット305をさらに含む。
【００８４】
選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果が受け取られるとき、サービスデータに対するコンセンサス結果が全体的に共有される必要があると判断すると、判断ユニット305は、コンセンサス処理に参加していない、コンセンサスネットワーク内のコンセンサスノードに、サービスデータに対するコンセンサス結果を送り、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。
【００８５】
本出願の別の実装形態において、ブロックチェーンコンセンサスデバイスは、格納ユニット306をさらに含む。
【００８６】
選択されたコンセンサスノードによって送られた、サービスデータに対するコンセンサス結果が受け取られるとき、格納ユニット306は、サービスデータに対するコンセンサス結果が全体的に共有される必要がないということが判断されると、サービスデータに対するコンセンサス結果をブロックチェーンに格納する。
【００８７】
本出願の本実装形態において提供されるブロックチェーンコンセンサス処理デバイスは、ハードウェアまたはソフトウェアを使用することによって実装されることが可能であるということに留意する価値がある。このことは、ここでは限定されない。ブロックチェーンコンセンサス処理デバイスは、コンセンサス手順が行われることになるサービスデータのサービスタイプに基づいて、コンセンサスサービスを提供するコンセンサスノードを選択することができ、選択されたコンセンサスノードは、サービスデータに対するコンセンサス処理を行う。このようにして、様々なサービスに対するコンセンサス処理を行うために、いくつかのコンセンサスノードがコンセンサスネットワークから選択され、このことにより、コンセンサス処理に参加する大きな数量のコンセンサスノードによって引き起こされる長いコンセンサス処理時間の問題を軽減させる。このことは、コンセンサス処理時間を短縮するだけでなく、コンセンサス処理結果の正当性も保証することができ、このことにより、ブロックチェーンネットワークのサービスデータ処理効率を効果的に改善する。
【００８８】
本出願の1つの実装形態は、ブロックチェーンコンセンサスデバイスをさらに提供し、メモリおよび少なくとも1つのプロセッサを含み、メモリがプログラムを格納し、少なくとも1つのプロセッサが、コンセンサス手順が行われることになるサービスデータを入手し、サービスデータのサービスタイプを決定するステップと、コンセンサスサービスを提供する少なくとも1つのコンセンサスノードを、サービスタイプに基づいてコンセンサスネットワークから選択するステップと、選択されたコンセンサスノードがサービスデータに対するコンセンサス処理を行うように、選択されたコンセンサスノードにサービスデータを送るステップと、を行うように構成される。
【００８９】
プログラムによって実装される他の内容に対して、先の実装形態において説明された内容への参照が行われる。詳細は、ここでは省略される。
【００９０】
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が最も一般的に使用される。いくつかの説明されたハードウェア記述言語を使用することによって方法手順が論理的にプログラムされ、集積回路にプログラムされると、論理的な方法手順を実装するハードウェア回路が容易に得られることが可能であるということも当業者は理解するはずである。
【００９１】
コントローラは、任意の妥当な方法を使用することによって実装されることが可能である。例えば、コントローラは、マイクロプロセッサもしくはプロセッサ、あるいはマイクロプロセッサもしくはプロセッサ、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブルロジックコントローラ、またはビルトインマイクロプロセッサによって実行されることが可能な(ソフトウェアもしくはファームウェアなどの)コンピュータ可読プログラムコードを格納するコンピュータ可読媒体であることが可能である。コントローラの例は、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、およびSilicone Labs C8051F320などのマイクロプロセッサを含むがこれらに限定されない。メモリコントローラは、メモリの制御ロジックの一部として実装されることも可能である。コンピュータ可読プログラムコードを使用することによってコントローラを実装することの他に、ロジックプログラミングは、論理ゲート、スイッチ、特定用途向け集積回路、プログラマブルロジックコントローラ、およびビルトインマイクロコントローラの形で同じ機能をコントローラが実装できるようにするための方法ステップに対して行われることが可能であるということも当業者は知っている。したがってコントローラは、ハードウェア構成要素とみなされることが可能であり、コントローラに様々な機能を実装するように構成された装置は、ハードウェア構成要素内の構造とみなされることも可能である。または様々な機能を実装するように構成された装置は、方法を実装するソフトウェアモジュールと、ハードウェア構成要素内の構造の両方とみなされることさえ可能である。
【００９２】
先の実装形態において示されたシステム、装置、モジュール、またはユニットは、コンピュータチップまたはエンティティを使用することによって実装されることが可能であり、また一定の機能を有する製品を使用することによって実装されることが可能である。典型的な実行デバイスはコンピュータである。コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、セルラー電話、カメラフォン、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、eメールデバイス、ゲーム機、タブレット型コンピュータ、もしくはウェアラブルデバイス、またはこれらのデバイスのいずれかの組合せであることが可能である。
【００９３】
説明の容易性のために、上記の装置は、様々なユニットに機能を分割することによって説明される。間違いなく、本出願が実装されるとき、各ユニットの機能は、1つまたは複数のソフトウェアおよび/またはハードウェアの中に実装されることが可能である。
【００９４】
本開示の実装形態は、方法、システム、またはコンピュータプログラム製品として提供されることが可能であるということを当業者は理解するはずである。したがって本開示は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアの組合せによる実装形態の形式を使用することができる。さらに本開示は、コンピュータ使用可能プログラムコードを含む(ディスクメモリ、CD-ROM、光メモリ、等を含むがこれらに限定されない)1つまたは複数のコンピュータ使用可能ストレージ媒体上に実装されるコンピュータプログラム製品の形式を使用することができる。
【００９５】
本開示は、本開示の実装形態に基づいて、方法、デバイス(システム)、およびコンピュータプログラム製品の流れ図および/またはブロック図を参照しながら説明される。コンピュータプログラム命令は、流れ図および/またはブロック図における各処理および/または各ブロック、ならびに流れ図および/またはブロック図における処理および/またはブロックの組合せを実行するために使用されることが可能であるということに留意する価値がある。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または機械を生成するための別のプログラマブルデータ処理デバイスのプロセッサに提供されることが可能であり、その結果、コンピュータ、または別のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行するためのデバイスを生成する。
【００９６】
コンピュータまたは別のプログラマブルデータ処理デバイスに、特定の方式で動くように命令することができる、これらのコンピュータプログラム命令は、コンピュータ可読メモリに格納されることが可能であり、その結果、コンピュータ可読メモリに格納された命令は、命令デバイスを含むアーチファクトを生成する。命令デバイスは、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行する。
【００９７】
これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイス上にロードされることが可能であり、その結果、コンピュータまたは別のプログラマブルデバイス上で一連の動作ならびに動作およびステップが行われ、このことにより、コンピュータ実行処理を生成する。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行するためのステップを提供する。
【００９８】
典型的な構成において、計算デバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。
【００９９】
メモリは、非持続的メモリ、ランダムアクセスメモリ(RAM)、不揮発性メモリ、および/または例えばリードオンリメモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)といった、コンピュータ可読媒体内にある別の形式を含むことができる。メモリは、コンピュータ可読媒体の例である。
【０１００】
コンピュータ可読媒体は、任意の方法または技術を使用することによって情報を格納することができる持続的媒体、非持続的媒体、可動媒体、および非可動媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであることが可能である。コンピュータストレージ媒体の例は、パラメータランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、電気的消去可能プログラマブルリードオンリメモリ(EEPROM)、フラッシュメモリまたは別のメモリ技術、コンパクトディスクリードオンリメモリ(CD-ROM)、デジタル多用途ディスク(DVD)または別の光ストレージ、カセット磁気テープ、磁気テープ/磁気ディスクストレージまたは別の磁気ストレージデバイスを含むがこれらに限定されない。コンピュータストレージ媒体は、計算デバイスによってアクセス可能な情報を格納するために使用されることが可能である。本明細書における定義に基づくと、コンピュータ可読媒体は、変調されたデータ信号および担体などの一時コンピュータ可読媒体(一時媒体)を含まない。
【０１０１】
用語「含む(include)」、「備える(comprise)」、またはこれらの他の任意の変形物は、非排他的な包含をカバーすることを意図するものであるので、要素の一覧を含む処理、方法、製品、もしくはデバイスは、これらの要素を含むだけでなく、明確に挙げられていない他の要素も含むということ、またはこのような処理、方法、製品、もしくはデバイスに固有の要素をさらに含むということにさらに留意する価値がある。さらなる制限なく、「〜を含む(includes a ...)」の前にある要素は、要素を含む処理、方法、製品、またはデバイスにおけるさらなる同一要素の存在を排除しない。
【０１０２】
本出願は、例えばプログラムモジュールといった、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明されることが可能である。一般に、プログラムモジュールは、特定のタスクを実行するか、特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。本出願は、分散コンピューティング環境において実践されることも可能である。分散コンピューティング環境において、タスクは、通信ネットワークを通じて接続されたリモート処理デバイスによって行われる。分散コンピューティング環境において、プログラムモジュールは、ストレージデバイスを含む、ローカルとリモート両方のコンピュータストレージ媒体に配置されることが可能である。
【０１０３】
本明細書における実装形態は漸進的な方式で説明される。実装形態の同じまたは類似の部分に対して、実装形態に対する参照が行われることが可能である。各実装形態は、他の実装形態との相違を重点的に取り扱う。特に、システムの実装形態は、方法の実装形態に基本的に類似しており、したがって簡単に説明される。関連部分に対しては、方法の実装形態における関連説明を参照されたい。
【０１０４】
先の実装形態は本出願の実装形態であり、本出願を限定することを意図するものではない。当業者は、本出願に対する様々な修正および変更を行うことができる。本出願の精神および原理から逸脱することなく行われる任意の修正、同等の置換、または改良は、本出願における特許請求の範囲の範囲に含まれる。
【符号の説明】
【０１０５】
301  取得ユニット
302  選択ユニット
303  送信ユニット
304  処理ユニット
305  判断ユニット
306  格納ユニット
【図１】
0006692561.tif 000002
【図２】
0006692561.tif 000003
【図３】
0006692561.tif 000004