(57)【特許請求の範囲】
【請求項１】
１つ又は複数のブロックチェーンを含むブロックチェーン・システムに取引データを書き込むためのリクエストを受信するステップであって、前記取引データは、前記取引データの第１の取引種別を反映する取引特徴情報を含む、ステップと、
ブロックチェーン・データ・レコード・テーブル及び前記取引特徴情報に従い、前記取引データにマッチするブロックチェーンの第１のブロックチェーンを決定するステップであって、前記ブロックチェーン・データ・レコード・テーブルは、（i）１つ又は複数の取引種別識別子と１つ又は複数のブロックチェーンとの間の１つ又は複数の対応、（ii）前記第１のブロックチェーンの最新のブロックの第１のハッシュ値である第１のレコード、及び（iii）前記最新のブロックに対応する第１のタイム・スタンプである第２のレコード、を含む、ステップと、
前記第１のブロックチェーンを決定した後に、
前記第１のハッシュ値と前記第１のタイム・スタンプを抽出するステップと、
前記取引データの実行結果、前記第１のハッシュ値、及び前記第１のタイム・スタンプを前記第１のブロックチェーンの新しいブロックに書き込むステップと、
前記第１のレコードを前記新しいブロックの第２のハッシュ値で更新するステップと、
前記第２のレコードを前記新しいブロックに対応する第２のタイム・スタンプで更新するステップと、
を有する方法。
【請求項２】
前記第１のブロックチェーンを決定するステップは、前記１つ又は複数の対応に基づいて、前記第１の取引種別が、前記１つ又は複数の取引種別識別子の第１の取引種別識別子に対応することを決定するステップを有する、請求項１に記載の方法。
【請求項３】
前記取引特徴情報は２のＮ乗であり、Ｎは０又は正の整数である、請求項２に記載の方法。
【請求項４】
前記１つ又は複数のブロックチェーンは、メイン・チェーンを含み、前記方法は、前記リクエストを受信した後、
事前設定条件が満たされると判定することに応じて、前記ブロックチェーン・システムにサイド・チェーン・ブロックチェーンを追加するステップと、
前記ブロックチェーン・データ・レコード・テーブルに、前記サイド・チェーンに対応するレコードと、前記サイド・チェーンの第２の取引種別識別子とを追加するステップと、
を更に有する、請求項１に記載の方法。
【請求項５】
前記事前設定条件は、前記取引特徴情報が事前設定された取引特徴情報とマッチすることを含む、請求項４に記載の方法。
【請求項６】
前記事前設定条件は、同時に受信されたブロックチェーン取引データ書込みリクエストの個数が事前設定された閾値に達することを含む、請求項４に記載の方法。
【請求項７】
前記事前設定条件は、前記サイド・チェーンを加えるための事前設定された時間に到達することを含む、請求項４に記載の方法。
【請求項８】
. 前記１つ又は複数のブロックチェーンは、メイン・チェーン及びサイド・チェーンを含み、前記方法は、事前設定条件が満たされる場合、
前記第１のブロックチェーンをサイド・チェーンとして終了するステップと、
前記サイド・チェーンが終了したことを示すために前記サイド・チェーンに対応する前記ブロックチェーン・データ・レコード・テーブル内の第３のレコードを更新するステップと、
を更に有する請求項１に記載の方法。
【請求項９】
前記事前設定条件は、受信されたブロックチェーン取引データ書込みリクエストの同時個数が事前設定された閾値よりも小さいことを含む、請求項８に記載の方法。
【請求項１０】
前記事前設定条件は、前記サイド・チェーンの有効期限に到達したことを含む、請求項８に記載の方法。
【請求項１１】
前記第３のレコードを更新することは、前記第３レコードを削除することを含む、請求項８に記載の方法。
【請求項１２】
前記第３のレコードを更新することは、前記サイド・チェーンの状態情報を無効に変更することを含む、請求項８に記載の方法。
【請求項１３】
プロセッサによって実行される方法であって、
１つ又は複数のブロックチェーンを含むブロックチェーン・システムに取引データを書き込むためのリクエストを受信するステップであって、前記取引データは、前記取引データの第１の取引種別を反映する取引特徴情報を含む、ステップと、
ブロックチェーン・データ・レコード・テーブル及び前記取引特徴情報に従い、前記取引データにマッチするブロックチェーンの第１のブロックチェーンを決定するステップであって、前記ブロックチェーン・データ・レコード・テーブルは、（i）１つ又は複数の取引種別識別子と１つ又は複数のブロックチェーンとの間の１つ又は複数の対応、（ii）前記第１のブロックチェーンの最新のブロックの第１のハッシュ値である第１のレコード、及び（iii）前記最新のブロックに対応する第１のタイム・スタンプである第２のレコード、を含む、ステップと、
前記第１のブロックチェーンを決定した後に、
前記第１のハッシュ値と前記第１のタイム・スタンプを抽出するステップと、
前記取引データの実行結果、前記第１のハッシュ値、及び前記第１のタイム・スタンプを前記第１のブロックチェーンの新しいブロックに書き込むステップと、
第１のレコードを前記新しいブロックの第２のハッシュ値で更新するステップと、
第２のレコードを前記新しいブロックに対応する第２のタイム・スタンプで更新するステップと、
を有する方法を前記プロセッサに実行させる命令を記憶する非一時的なコンピュータ可読記憶媒体。
【請求項１４】
前記第１のブロックチェーンを決定するステップは、前記１つ又は複数の対応に基づいて、前記第１の取引種別が、前記１つ又は複数の取引種別識別子の第１の取引種別識別子に対応することを決定するステップを有する、請求項１３に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１５】
前記取引特徴情報は２のＮ乗であり、Ｎは０又は正の整数である、請求項１４に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１６】
前記１つ又は複数のブロックチェーンは、メイン・チェーンを含み、前記方法は、前記リクエストを受信した後、
事前設定条件が満たされると判定することに応じて、前記ブロックチェーン・システムにサイド・チェーン・ブロックチェーンを追加するステップと、
前記ブロックチェーン・データ・レコード・テーブルに、前記サイド・チェーンに対応するレコードと、前記サイド・チェーンの第２の取引種別識別子とを追加するステップと、
を更に有する、請求項１３に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１７】
前記事前設定条件は、前記取引特徴情報が事前設定された取引特徴情報とマッチすることを含む、請求項１６に記載の非一時的なコンピュータ可読記憶媒体。
【請求項１８】
１つ又は複数のプロセッサと、
前記１つ又は複数のプロセッサによって実行されるとき、前記１つ又は複数のプロセッサに方法を実行させる命令を記憶する１つ又は複数の非一時的なコンピュータ可読記憶媒体を有し、前記方法は、
１つ又は複数のブロックチェーンを含むブロックチェーン・システムに取引データを書き込むためのリクエストを受信するステップであって、前記取引データは、前記取引データの第１の取引種別を反映する取引特徴情報を含む、ステップと、
ブロックチェーン・データ・レコード・テーブル及び前記取引特徴情報に従い、前記取引データにマッチするブロックチェーンの第１のブロックチェーンを決定するステップであって、前記ブロックチェーン・データ・レコード・テーブルは、（i）１つ又は複数の取引種別識別子と１つ又は複数のブロックチェーンとの間の１つ又は複数の対応、（ii）前記第１のブロックチェーンの最新のブロックの第１のハッシュ値である第１のレコード、及び（iii）前記最新のブロックに対応する第１のタイム・スタンプである第２のレコード、を含む、ステップと、
前記第１のブロックチェーンを決定した後に、
前記第１のハッシュ値と前記第１のタイム・スタンプを抽出するステップと、
前記取引データの実行結果、前記第１のハッシュ値、及び前記第１のタイム・スタンプを前記第１のブロックチェーンの新しいブロックに書き込むステップと、
第１のレコードを前記新しいブロックの第２のハッシュ値で更新するステップと、
第２のレコードを前記新しいブロックに対応する第２のタイム・スタンプで更新するステップと、
を有する方法である、システム。
【請求項１９】
前記第１のブロックチェーンを決定するステップは、前記１つ又は複数の対応に基づいて、前記第１の取引種別が、前記１つ又は複数の取引種別識別子の第１の取引種別識別子に対応することを決定するステップを有する、請求項１８に記載のシステム。
【請求項２０】
前記取引特徴情報は２のＮ乗であり、Ｎは０又は正の整数である、請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、コンピュータ技術の分野に関し、詳細には、取引データをブロックチェーン・システムに書き込むための方法およびデバイスに関する。
【背景技術】
【０００２】
コンピュータ技術の発展に伴い、（分散型台帳ネットワークとも呼ばれる）ブロックチェーン技術は、スマート・コントラクト、有価証券取引、ｅコマース、モノのインターネット、社会的コミュニケーション、文書格納、存在証明、本人確認、およびエクイティ・クラウド・ファンディングなどの様々な分野において、非集中化、開放性および透明性、不変性、ならびに信用性などの長所により、広く使用されてきている。
【０００３】
ブロックチェーン技術に基づいて取引システムが実装されるとき、（ブロックチェーン技術を使用してシステムが実装されるときにブロックチェーン・システムと呼ばれることもある）取引システムは、取引データをブロックチェーンに書き込む必要がある。（ブロックチェーン技術において取引と呼ばれることもある、）ブロックチェーンに追加されることになる取引データをブロックチェーン・システムが受け取るとき、ブロックチェーン・システムは、ファースト・イン・ファースト・アウトのシーケンスを使用して、これらの取引を時系列に実行し、このことにより、取引の検証、実行、データをブロックチェーンに書き込むこと、等などの動作を完了させる。
【発明の概要】
【０００４】
現在の技術において、ブロックチェーン・システムの計算リソースを完全かつ適度に使用するために、ブロックチェーン・システムは、多くの様々な種類の取引を含み、これらの様々な種類の取引データを時系列に等しく扱うことができる。しかし、場合によっては、取引が時系列に実行される手法は、利用の要求を満たすことができない。例えば、様々な守秘義務レベルを有する様々な種類の情報が処理されるとき、ブロックチェーン・システムは、様々な守秘義務レベルの情報を処理するための取引を受け取ることがある。この時点で、様々な守秘義務レベルの情報は、より高い守秘義務レベルの情報を漏らさないようにするために隔離され、情報セキュリティを保証する必要があることがある。したがって、特殊な制御が取引に対して行われる必要があるとき、現在の技術におけるブロックチェーンの取引データを書き込む手法は、利用の要求を満たすことができない。
【０００５】
したがって、様々な種類の取引データを有するブロックチェーン・システム内の様々な種類の取引データに対する取引処理のニーズを満たすことができる、取引データを書き込むための方法に対する差し迫ったニーズがある。
【０００６】
本出願の実施形態は、ブロックチェーン・システム内の様々な種類の取引データを処理するニーズを満たす、取引データをブロックチェーン・システムに書き込むための方法およびデバイスを提供する。
【０００７】
本出願の実施形態は、以下の技術的解決策を採用することができる。
【０００８】
本出願の実施形態は、取引データをブロックチェーン・システムに書き込むための方法を示し、ブロックチェーン・システムは、少なくとも１つのブロックチェーンを含み、方法は、
ブロックチェーンに追加されることになる取引データの取引特徴情報を含むブロックチェーン取引データ書込みリクエストを受け取ることと、
ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断することであって、ブロックチェーン・データ・レコード・テーブルが、ブロックチェーン内の取引データの取引特徴情報を表すための、ブロックチェーンと関連付けられた取引種別識別情報を記録する、判断することと、
ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに、ブロックチェーンに追加されることになる取引データの実行結果を書き込むことと、
を含む。
【０００９】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断することは、
第１の事前設定条件を満たす第１の取引種別識別情報がブロックチェーン・データ・レコード・テーブル内で発見されるとき、第１の取引種別識別情報に対応するブロックチェーンを、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンであると判断すること
を含み、
第１の事前設定条件を満たすことは、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチすることを含む。
【００１０】
好ましくは、本出願の実施形態による方法において、取引特徴情報は２のＮ乗であり、Ｎは０または正の整数であり、
ブロックチェーンの取引種別識別情報は、ブロックチェーン内の取引データの様々な取引特徴情報の合計である。
【００１１】
好ましくは、本出願の実施形態による方法において、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチすることは、
第１の取引種別識別情報の値と、ブロックチェーンに追加されることになる取引データの取引特徴情報の値とに対する「＆」論理演算が、ブロックチェーンに追加されることになる取引データの取引特徴情報の値に等しい場合、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチすること
を含む。
【００１２】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断することは、
第１の事前設定条件を満たす第１の取引種別識別情報がブロックチェーン・データ・レコード・テーブル内で発見されないとき、事前設定された第２の取引種別識別情報に対応するブロックチェーンを、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンであると判断すること
をさらに含む。
【００１３】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・データ・レコード・テーブルは、ブロックチェーンと関連付けられた状態情報をさらに記録し、第１の取引種別識別情報が第１の事前設定条件を満たすことは、
第１の取引種別識別情報に対応するブロックチェーンと関連付けられた状態情報が有効な状態であること
をさらに含む。
【００１４】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・データ・レコード・テーブルは、ブロックチェーンの最後のブロックのハッシュ値および対応するタイム・スタンプをさらに記録し、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに、ブロックチェーンに追加されることになる取引データの実行結果を書き込むことは、
ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに対応する最後のブロック・ハッシュ値、および対応するタイム・スタンプを抽出することと、
ブロックチェーンに追加されることになる取引データの実行結果、最後のブロック・ハッシュ値、および対応するタイム・スタンプを、ブロックチェーンの新しいブロックに書き込むことと、
新しい最後のブロック・ハッシュの値および対応するタイム・スタンプとして、新しいブロックのハッシュ値および対応するタイム・スタンプで、ブロックチェーン・データ・レコード・テーブルを更新することと
を含む。
【００１５】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・システムは、メイン・チェーンとしてのブロックチェーンを含み、ブロックチェーン取引データ書込みリクエストを受け取ることの後、方法は、
第２の事前設定条件が満たされるとき、サイド・チェーンとして新しいブロックチェーンをブロックチェーン・システムに追加すること、ならびに新しいブロックチェーンに対応するレコード、および新しいブロックチェーンの取引種別識別情報を、ブロックチェーン・データ・レコード・テーブルに追加すること
をさらに含む。
【００１６】
好ましくは、本出願の実施形態による方法において、第２の事前設定条件を満たすことは、
ブロックチェーン取引データ書込みリクエストに含まれるブロックチェーンに追加されることになる取引データの取引特徴情報が、事前設定された取引特徴情報にマッチすること、および／または
受け取ったブロックチェーン取引データ書込みリクエストの同時発生数が、事前設定された閾値に達すること、および／または
新しいブロックチェーンをサイド・チェーンとして追加するための事前設定された時間が達せられること
を含む。
【００１７】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・システムは、メイン・チェーンとしてブロックチェーンを、また、サイド・チェーンとして少なくとも１つのブロックチェーンを含み、ブロックチェーン取引データ書込みリクエストを受け取ることの後、方法は、
第３の事前設定条件が満たされるとき、ブロックチェーン・システム内のサイド・チェーンとしてブロックチェーンを終了させること、およびブロックチェーン・データ・レコード・テーブル内の終了したブロックチェーンに対応するレコードを更新すること
をさらに含む。
【００１８】
好ましくは、本出願の実施形態による方法において、第３の事前設定条件を満たすことは、
受け取ったブロックチェーン取引データ書込みリクエストの同時発生数が、事前設定された閾値より少ないこと、および／または
サイド・チェーンの有効時間が達せられること
を含む。
【００１９】
好ましくは、本出願の実施形態による方法において、ブロックチェーン・データ・レコード・テーブル内の終了したブロックチェーンに対応するレコードを更新することは、
終了したブロックチェーンに対応するレコードを削除すること、または
終了したブロックチェーンの状態情報がブロックチェーン・データ・レコード・テーブルに記録されるとき、終了したブロックチェーンの状態情報を無効な状態に変更すること
を含む。
【００２０】
本出願の実施形態は、取引データをブロックチェーン・システムに書き込むためのデバイスをさらに提供し、ブロックチェーン・システムは、少なくとも１つのブロックチェーンを含み、デバイスは、
ブロックチェーンに追加されることになる取引データの取引特徴情報を含むブロックチェーン取引データ書込みリクエストを受け取るように構成されたリクエスト受取モジュールと、
ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断するように構成されたブロックチェーン判断モジュールであって、ブロックチェーン・データ・レコード・テーブルが、ブロックチェーン内の取引データの取引特徴情報を表すための、ブロックチェーンと関連付けられた取引種別識別情報を記録する、ブロックチェーン判断モジュールと、
ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに、ブロックチェーンに追加されることになる取引データの実行結果を書き込むように構成されたブロックチェーン・データ追加モジュールと
を備える。
【００２１】
本出願の実施形態によって採用される上記の技術的解決策のうちの少なくとも１つは、以下の有利な効果を実現することができる。
【００２２】
本出願の実施形態において、ブロックチェーン・システムは、ブロックチェーンに追加されることになる取引データの取引特徴情報を含むブロックチェーン取引データ書込みリクエストを受け取る。ブロックチェーンと関連付けられた取引種別識別情報は、ブロックチェーン・データ・レコード・テーブルに記録され、識別情報は、ブロックチェーン内の取引データの取引特徴情報を表すことができるので、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンは、ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って判断されることが可能であり、したがって、ブロックチェーンに追加されることになる取引データの実行結果は、マッチするブロックチェーンに書き込まれることが可能である。本出願の実施形態による技術的解決策を採用することによって、マッチするブロックチェーンは、データをブロックチェーンに書き込む処理を完了させるために、ブロックチェーンに追加されることになる取引データの取引特徴情報に従って選択されることが可能であり、取引種別に対応するブロックチェーンを記録することができるブロックチェーン・データ・レコード・テーブルが作り出される。したがって、様々な種類の取引データを区別して処理することが可能であり、ブロックチェーン・システム内の様々な種類の取引データに対する処理要求が満たされることが可能である。
【００２３】
本明細書の中で説明されることになる添付の図面は、本出願のさらなる理解をもたらすために使用され、本出願の一部とみなされる。本出願の例示的な実施形態および例示的な実施形態の説明が、本出願を説明するために使用されるが、本出願に対する誤った限定とはみなされない。
【図面の簡単な説明】
【００２４】
【図１】本出願のいくつかの実施形態による、取引データをブロックチェーン・システムに書き込むための方法の流れ図である。
【図２】本出願のいくつかの実施形態による、取引データをブロックチェーン・システムに書き込むための別の方法の流れ図である。
【図３】本出願のブロックチェーン・システムにおける、サイド・ブロックチェーンの分岐の概略図である。
【図４】本出願のブロックチェーン・システムにおける、サイド・ブロックチェーンの分岐の別の概略図である。
【図５】本出願のブロックチェーン・システムにおける、サイド・ブロックチェーンが終了されることについての概略図である。
【図６】本出願のいくつかの実施形態による、取引データをブロックチェーン・システムに書き込むためのデバイスの概略構造図である。
【発明を実施するための形態】
【００２５】
本出願の目的、技術的解決策、および長所をより明確にするために、本出願の技術的解決策は、本出願の実施形態および添付の図面を参照しながら、下記で明確かつ完全に説明されることになる。説明される実施形態は、本出願の全てではなく、いくつかの実施形態にすぎないということが明らかである。本出願の実施形態に基づいて、創造的な努力なく当業者によって得ることができる他の全ての実施形態は、本出願の範囲に含まれる。
【００２６】
本出願の実施形態において示される技術的解決策は、添付の図面を参照しながら下記で詳細に説明されることになる。
【００２７】
本出願の実施形態は、取引データをブロックチェーン・システムに書き込むための方法を示し、ブロックチェーン・システムは、少なくとも１つのブロックチェーンを含む。ブロックチェーン・システムがただ１つのブロックチェーンを含む場合、ブロックチェーンは、ブロックチェーン・システムのメイン・チェーンとみなされることが可能であり、ブロックチェーン・システムに書き込まれる様々な種類の取引データの全ての実行結果は、メイン・チェーンにデフォルトで書き込まれる。例示的な実装形態において、ブロックチェーンに追加されることになる取引データは、ブロックチェーン取引データ書込みリクエストが受け取られる時間的順序で、ブロックチェーン・システムの取引処理要件に従って実行され、この時間的順序でメイン・チェーンに書き込まれる。
【００２８】
ブロックチェーン・システムが複数のブロックチェーンを含む場合、ブロックチェーンのうちの１つがブロックチェーン・システムのメイン・チェーンと呼ばれる一方で、他のブロックチェーンは、ブロックチェーン・システムのサイド・チェーンと呼ばれる。本出願のいくつかの実施形態において、ブロックチェーン・システムに１つのメイン・チェーンが存在することが可能である。特殊構成がないとき、ブロックチェーン・システムに書き込まれる様々な種類の取引データの全ての実行結果は、メイン・チェーンにデフォルトで書き込まれることが可能である。必要であれば、１つまたは複数のサイド・チェーンが、ブロックチェーン・システムの中で分離されることが可能である。サイド・チェーンのそれぞれは、１つまたは複数の異なる取引種別の取引データを同様に処理する。次に、取引データの取引特徴情報に従って、特殊な処理要件を有する１つまたは複数の種類の取引データは、メイン・チェーンに、また（もしあれば）他のサイド・チェーンに書き込まれる他の取引種別の取引データの処理に影響を及ぼさずに処理するために、サイド・チェーンに割り振られることが可能である。したがって、様々な種類の取引データに対する取引処理要求が満たされることが可能である。本出願の実施形態の実行処理は、例を通じて詳細に説明されることになる。
【００２９】
図１を参照すると、本出願の実施形態による、取引データをブロックチェーン・システムに書き込むための方法は、例えば、
Ｓ１０１：ブロックチェーンに追加されることになる取引データの取引特徴情報を含むブロックチェーン取引データ書込みリクエストを受け取ること、
Ｓ１０２：ブロックチェーン・データ・レコード・テーブル、およびブロックチェーン取引データ書込みリクエスト内の取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断することであって、ブロックチェーン・データ・レコード・テーブルが、ブロックチェーン内の取引データの取引特徴情報を表すための、ブロックチェーンと関連付けられた取引種別識別情報を記録する、判断すること、ならびに
Ｓ１０３：ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに、ブロックチェーンに追加されることになる取引データの実行結果を書き込むこと
を含んでよい。
【００３０】
ブロックチェーン・システムがステップＳ１０１を実行した結果として受け取られる（ブロックチェーン技術システムにおいて取引と呼ばれることもあり、英語名はトランザクションであり、省略形がｔｘである、）ブロックチェーン取引データ書込みリクエストは、ブロックチェーンに追加されることになる取引データの実行結果を、ブロックチェーン・システム内のブロックチェーンに書き込むための、ブロックチェーンに追加されることになる取引データの実行をリクエストするために使用される。リクエストは、ブロックチェーンに追加されることになる取引データの取引特徴情報および同様のものなどの、ブロックチェーンに追加されることになる取引データに関する情報を含む。ブロックチェーンに追加されることになる取引データの取引特徴情報は、様々な種類の取引データを区別するために、ブロックチェーンに追加されることになる取引データがどの種類の取引データに属するかを表すために使用される。本出願の実施形態において、取引データの種類は、様々な観点に従って分類されることが可能である。例えば、取引データの種類は、取引データ処理手法に従って、契約取引、振替取引、および同様のものに分類されることが可能であり、または、取引データの情報守秘義務レベルに従って、極秘、秘密、機密、等に分類されることが可能である。
【００３１】
本出願の実施形態において、Ａ、Ｂ、Ｃ、およびＤなどの文字形式は、様々な種類の取引データが区別されることが可能な限り、取引データの取引特徴情報を表すために使用されることが可能である。（［Ａ，Ｄ］によって表されることが可能な）種類Ａおよび種類Ｄの取引、（［Ｂ，Ｃ］によって表されることが可能な）種類Ｂおよび種類Ｃの取引、ならびに（［Ｄ］によって表されることが可能な）種類Ｄの取引を処理するためにそれぞれ使用される３つのサイド・チェーンをブロックチェーン・システムが含むと仮定すると、（実施形態においてＡ、Ｂ、Ｃ、およびＤなどの文字形式で表されることが可能な、）ブロックチェーンに追加されることになる取引データの取引特徴情報と、（［Ａ，Ｄ］、［Ｂ，Ｃ］、および［Ｄ］などの形式で表されることが可能な、）ブロックチェーン・データ・レコード・テーブルに記録された、ブロックチェーンと関連付けられた取引種別識別情報との間の文字列のマッチングを行うために、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンが判断されるときに、ブロックチェーン・データ・レコード・テーブルは詳細に検討されることが可能であり、このことにより、ブロックチェーンに追加されることになる取引データが書き込まれるべきブロックチェーンを判断し、データをブロックチェーンに書き込むその後の動作を実行する。
【００３２】
本出願の１つの好ましい実施形態において、取引特徴情報は２のＮ乗の形式で表現され、パラメータＮは０または正の整数である。本形式での取引データの取引特徴情報の表現は、様々な取引種別の取引データがサイド・チェーンに同時に書き込まれるとき、２のＮ乗の形式、すなわち２Ｎ（Ｎ≧０）の形式での取引特徴情報の表現は、取引種別識別情報の計算、およびサイド・チェーンに対応するその後の論理演算をさらに容易にすることが可能である、という長所を有する。取引種別識別情報の計算の処理、および論理演算の処理は、下記の例を通じてさらに説明されることになる。
【００３３】
ブロックチェーンに追加されることになる取引データの取引特徴情報に加えて、ブロックチェーン取引データ書込みリクエストは、秘密鍵を使用して（トランザクション・イニシエータと呼ばれることもある）トランザクション・イニシエータによって署名された情報をさらに含むことができ、情報は、リクエストに対応する取引データをブロックチェーン・システムが処理するときの公開鍵による検証のために使用され、検証が成功した場合、これは、取引が有効であることを示し、データをブロックチェーンに書き込むその後のステップのために現在のブロックチェーン・システムに書き込まれることを許可され、そうでない場合、取引の実行は拒絶される。
【００３４】
ブロックチェーン取引データ書込みリクエストをブロックチェーン・システムが受け取った後、ブロックチェーン・システムは、リクエストに対応する（取引と呼ばれることもある）ブロックチェーンに追加されることになる取引データを、その後の処理のために（ブロックチェーン・システムのトランザクション・プールと解釈されることがある）ローカル・キャッシュに保存することができる。テーブル１に示された取引モデル・テーブルのテーブル構造は、ブロックチェーンに追加されることになる取引データに関する情報をキャッシュに記録するために使用されることが可能である。
【００３５】
【表１】
0006875557.tif 000002
【００３６】
ブロックチェーン取引データ書込みリクエストをブロックチェーン・システムが受け取った後、ブロックチェーン・システムはステップＳ１０２を実行して、ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断する。ブロックチェーン・システム内のサイド・チェーンについて、ブロックチェーン・データ・レコード・テーブルに記録されたサイド・チェーンの取引種別識別情報は、サイド・チェーンに書き込まれた１つまたは複数の種類の取引データの取引特徴情報に従って、判断され、入手されることが可能である。したがって、サイド・チェーンの取引種別識別情報は、サイド・チェーン内の取引データの取引特徴情報を表すことができる。ブロックチェーン・システム内のメイン・チェーンの取引種別識別情報は、サイド・チェーンの取引種別識別情報から識別子が容易に区別されることが可能な限り、「＊」等などの事前設定された識別子によって示されることが可能であり、その後の論理演算において結果が、ブロックチェーンに追加されることになる取引データの取引特徴情報の値と混同されることはない。
【００３７】
２のＮ乗の形式、すなわち２Ｎ（Ｎ≧０）の形式で示される上記の取引特徴情報を例として用いる。１つのサイド・チェーンＡが２種類の取引データを含む場合、サイド・チェーンＡの取引種別識別情報は、これらの２種類の取引データの取引特徴情報に従って判断されることが可能である。例えば、売り手取引に対応する第１の種類の取引データの取引特徴情報の値が２０である（この時点でＮの値は０である）こと、および携帯電話認証取引に対応する第２の種類の取引データの取引特徴情報の値が２１である（この時点でＮの値は１である）ことを仮定する。次に、この例におけるサイド・チェーンＡの取引種別識別情報は、サイド・チェーンＡに書き込まれた２種類の取引データの取引特徴情報の値の合計、すなわち、１０進数で表現され、３としてレポートされることが可能な２０＋２１であることが可能である。
【００３８】
ブロックチェーン・データ・レコード・テーブルは、ブロックチェーンとブロックチェーンに書き込まれる取引データの取引種別（ブロックチェーンに書き込まれる取引データの取引特徴情報を表すことができる取引種別識別情報によって表される取引種別）との間の対応関係を示すので、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンは、ステップＳ１０２を実行することによって、ブロックチェーンに追加されることになる取引データの取引特徴情報（ブロックチェーンに追加されることになる取引データの取引種別を表すことができる取引特徴情報）に従って、ブロックチェーン・データ・レコード・テーブルの中で発見され、判断されることが可能であり、次に、ステップＳ１０３が実行され、ブロックチェーンに追加されることになる取引データのブロックチェーンへの書込みを完了させる。
【００３９】
例えば、ステップＳ１０２が実行されるときに、好ましくは、
第１の事前設定条件を満たす第１の取引種別識別情報がブロックチェーン・データ・レコード・テーブル内で発見されるとき、第１の取引種別識別情報に対応するブロックチェーンを、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンであると判断すること
という方法が採用されることが可能であり、
第１の取引種別識別情報が第１の事前設定条件を満たすことは、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチすることを含む。
【００４０】
対応関係は、ブロックチェーンと、ブロックチェーン・データ・レコード・テーブル内の取引種別識別情報との間で確立されているので、何の種類の取引データがブロックチェーンに含まれているかが表されることが可能であり、マッチするブロックチェーンは、ブロックチェーンに追加されることになる取引データの取引特徴情報が、ブロックチェーン・データ・レコード・テーブルに記録された第１の取引種別識別情報にマッチするかどうかを、ブロックチェーンに追加されることになる取引データに対して判断されること、すなわち、ブロックチェーンに追加されることになる取引データの種類を有する取引データが、どのブロックチェーンに書き込まれるべきかを判断することが可能である。
【００４１】
さらに、上記の第１の事前設定条件が満たされるかどうか、すなわち、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチするかどうかが判断されるとき、第１の取引種別識別情報の値およびブロックチェーンに追加されることになる取引データの取引特徴情報の値に対する「＆」論理演算が、ブロックチェーンに追加されることになる取引データの取引特徴情報の値に等しい場合、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチする、という手法が使用されることが可能である。演算の例において、「＆」論理演算は、「＆」論理演算の値が上記の取引特徴情報の値に等しくなる第１の取引種別識別情報を発見するまで、ブロックチェーンに追加されることになる取引データの取引特徴情報の値、およびブロックチェーン・データ・レコード・テーブルに記録された取引種別識別子のそれぞれに対して行われることが可能である。一方、「取引特徴情報の値＆第１の取引種別識別情報の値＝＝取引特徴情報の値」という論理式の結果が真であるかどうかは計算されることが可能であり、論理式の値が「真」になる第１の取引種別識別情報は、ブロックチェーンに追加されることになる取引データの取引特徴情報にマッチするものとして判断されることが可能である。
【００４２】
上記の例を引き続き使用して、ブロックチェーンに追加されることになる受け取った取引データが携帯電話認証種別であると仮定すると、ブロックチェーンに追加されることになる取引データに対応する取引特徴情報の値は２１である（この時点でＮの値は１である）。２１という取引特徴情報の値、およびブロックチェーン・データ・レコード・テーブルに記録された取引種別識別情報の値に対して「＆」論理演算を行うことによって、２１という取引特徴情報の値、および３（２０＋２１）というサイド・チェーンＡの取引種別識別情報の値に対する２進「＆」演算の計算結果は２であり、これは、２１という取引特徴情報の値に等しい。次に、サイド・チェーンＡの取引種別識別情報は、ブロックチェーンに追加されることになる取引データの取引特徴情報にマッチする第１の取引種別識別情報として扱われることが可能であり、サイド・チェーンＡは、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンとして判断されることが可能であり、ブロックチェーンに追加されることになる取引データがサイド・チェーンＡに書き込まれるべきであることを示す。
【００４３】
２進「＆」演算の間、１０進数形式の取引種別識別情報は、まず、２進文字列に変換され、次に、０＆０＝０、０＆１＝０、１＆０＝０、１＆１＝１という２進「＆」演算の計算原理に従って演算が行われ、これにより計算結果を得る。例えば、上記の例における演算処理は以下のように表現されることが可能である。
２＆３→１０＆１１＝１０→２＝２１
【００４４】
マッチする第１の取引種別識別情報を検索する上記の処理がコンピュータで実行されるとき、様々な手法がある可能性がある。例えば、ＳＱＬ判断ステートメントは、「取引特徴情報の値＆取引種別識別情報の値＝＝取引特徴情報の値」の値が「真」になる、ブロックチェーン・データ・レコード・テーブルからの第１の取引種別識別情報の選択を実行するために使用されることが可能である。一方、データは、ブロックチェーン・データ・レコード・テーブルからメモリに抽出されることが可能であり、検索は、プログラムを使用する循環比較によって完了する。したがって、循環比較の処理はさらに最適化されることが可能である。例えば、ブロックチェーン・データ・レコード・テーブル内の取引種別識別情報は、「取引種別識別情報の値％２＝＝０」という条件を満たすレコード、すなわち、２の倍数である取引種別識別情報の値を有するレコードをハッシュ・テーブルに入れるため、および２の倍数ではない取引種別識別情報の値を有するレコードを、詳細に検討するために循環待ち行列に入れるために分割され、このことにより、繰返し数を減らし、検索効率を改善させる。
【００４５】
ステップＳ１０２を実行するためにステップの上記の例が使用されるとき、上記の第１の事前設定条件を満たす第１の取引種別識別情報がブロックチェーン・データ・レコード・テーブル内で発見されない状況が発生する可能性がある。この状況は、ブロックチェーン・システムが、ブロックチェーンに追加されることになる取引データのような種類の取引データを組み込むサイド・チェーンを含まないと解釈されることが可能である。次に、事前設定された第２の取引種別識別情報に対応するブロックチェーンは、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンとして直接的に判断されることが可能である。実例の実装形態において、事前設定された第２の取引種別識別情報は、「＊」などのメイン・チェーンに対応する識別子であることが可能であり、このことにより、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンをブロックチェーン・システム内のメイン・チェーンとして判断し、ブロックチェーンに追加されることになるが、処理のためにサイド・チェーンに割り振られなかった取引データの実行結果を上記のメイン・チェーンに書き込む。
【００４６】
本出願の実施形態において、ブロックチェーンに対応する取引種別識別情報に加えて、ブロックチェーンと関連付けられた状態情報も、ブロックチェーン・データ・レコード・テーブルに記録されることが可能である。ブロックチェーンの状態情報は、ブロックチェーンが有効であるかどうか、すなわち、対応するブロックチェーンが新しいブロックを受け入れることができるかどうかを表すために使用されることが可能である。ブロックチェーン・システム内のメイン・チェーンについて、メイン・チェーンの状態情報は常に有効な状態であり、そうでなければ、ブロックチェーン・システムが普通に動作できないようにする可能性がある。ブロックチェーン・システム内のサイド・チェーンについて、サイド・チェーンに対応する取引種別（すなわち、サイド・チェーンの取引種別識別子によって表される取引種別）がサイド・チェーンに組み込まれることを許容されるとき、サイド・チェーンの状態情報は有効な状態であり、サイド・チェーンに対応する取引種別がサイド・チェーンに組み込まれることを許容されないとき、サイド・チェーンの状態情報は無効な状態である。
【００４７】
ブロックチェーン・データ・レコード・テーブルに従ってブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断する処理において、ブロックチェーンの取引種別識別情報と、ブロックチェーンに追加されることになる取引データの取引特徴情報との間のマッチングの問題が検討され、さらに、ブロックチェーン自体の有効性が検討されることもある。ブロックチェーン・データ・レコード・テーブルに記録されたブロックチェーンと関連付けられた状態情報が無効な状態である場合、ブロックチェーンに追加されることになる取引データは、この無効のブロックチェーンに書き込まれるべきではない。したがって、第１の取引種別識別情報が判断されるとき、第１の取引種別識別情報に対応するブロックチェーンと関連付けられた状態情報が有効な状態であることも必要とされる可能性がある。
【００４８】
１つの実装形態の例において、典型的には、２つの条件が同時に満たされることが必要とされ、すなわち、第１の取引種別識別情報が第１の事前設定条件を満たすことは、ブロックチェーンに追加されることになる取引データの取引特徴情報に第１の取引種別識別情報がマッチすること、および第１の取引種別識別情報に対応するブロックチェーンと関連付けられた状態情報が有効な状態であることを含む。判断処理の実行の例において、２つの条件を判断する順序は入替え可能であってよく、これは、本出願の実施形態において限定されない。つまり、ブロックチェーン・データ・レコード・テーブルに記録されたブロックチェーンと関連付けられた状態情報が最初に判断されることが可能であり、次に、状態情報が有効な状態であるブロックチェーンだけが、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを求めて検索され、一方、ブロックチェーン・データ・レコード・テーブルは、ブロックチェーンに追加されることになる取引データの取引特徴情報にマッチする第１の取引種別識別情報を求めて検索されることが可能であり、次に、第１の取引種別識別情報に対応するブロックチェーンと関連付けられた状態情報が有効な状態であるかどうかが判断され、第１の取引種別識別情報に対応するブロックチェーンと関連付けられた状態情報が有効な状態である場合、対応するブロックチェーンは、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンであると判断される。
【００４９】
本出願の実施形態において、ブロックチェーンの最後のブロック・ハッシュ値、および対応するタイム・スタンプは、ブロックチェーン・データ・レコード・テーブルに記録されることも可能である。例えば、下記でテーブル２に示されたテーブル構造が、記録するために使用される。
【００５０】
【表２】
0006875557.tif 000003
【００５１】
テーブル２に示された形式で提供されるブロックチェーン・データ・レコード・テーブルについて、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに、ブロックチェーンに追加されることになる取引データの実行結果を書き込むステップＳ１０３をブロックチェーン・システムが実行するときに、以下のステップが続くことが可能であり、図２を参照されたい。
Ｓ１０３１：ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに対応する最後のブロック・ハッシュ値、および対応するタイム・スタンプを抽出すること、
Ｓ１０３２：ブロックチェーンに追加されることになる取引データの実行結果、最後のブロック・ハッシュ値、および対応するタイム・スタンプを、ブロックチェーンの新しいブロックに書き込むこと、ならびに
Ｓ１０３３：新しい最後のブロックのハッシュ値および対応するタイム・スタンプとして、新しいブロックのハッシュ値および対応するタイム・スタンプで、ブロックチェーン・データ・レコード・テーブルを更新すること
【００５２】
上述の実行処理において、同じ種類の取引データが複数のサイド・チェーンに同時に組み込まれる場合、第１の事前設定条件を満たす複数の取引種別識別情報をブロックチェーン・データ・レコード・テーブルの中で発見することが可能である。次に、ブロックチェーンに追加されることになる取引データは、複数のマッチするブロックチェーンに組み込まれる必要がある可能性があり、これらのブロックチェーンに対応する最後のブロック・ハッシュ値、およびブロックチェーン・データ・レコード・テーブル内の対応するタイム・スタンプは、更新される必要がある可能性がある。
【００５３】
この状況は、例を用いて下記で説明されることになる。多くの種類の取引データがブロックチェーン・システムに組み込まれると仮定する。上記の例において言及された、値２０の取引特徴情報を有する売り手取引、および値２１の取引特徴情報を有する携帯電話認証取引に加えて、値２２の取引特徴情報（この時点でＮの値が２である）を有する携帯電話登録取引、および同様のものもある。ブロックチェーン・システムに組み込まれる全ての取引種別の取引特徴情報の値と、取引種別全てに対応する実際の取引との間の対応関係は、典型的には、テーブル３において示されるようにブロックチェーン・システムの開発者によって事前設定されるということに留意されたい。ブロックチェーン・システムに新しい種別を組み込む必要があるとき、新しい対応関係は、システム拡張の需要を満たすように追加されることが可能である。取引特徴情報が設定されているとき、取引特徴情報の値は、テーブル３に示されるように自然数Ｎを増加させる手法で様々な取引種別に典型的に割り当てられる。
【００５４】
【表３】
0006875557.tif 000004
【００５５】
ブロックチェーン・システムが、売り手取引および携帯電話認証取引をサイド・チェーンＩに組み込み、売り手取引および携帯電話登録取引をサイド・チェーンＩＩに組み込むと仮定すると、ブロックチェーン・データ・レコード・テーブルは、テーブル４において示されるようなものである。
【００５６】
【表４】
0006875557.tif 000005
【００５７】
ブロックチェーンに追加されることになる取引データが売り手取引であり、値１の取引特徴情報を有するとき、取引種別識別情報３および５をそれぞれ有する２つのブロックチェーンが、上記の実施形態における手法に従って、第１の事前設定条件による要件を両方満たす。したがって、売り手取引は、ブロックチェーンに同時に、または取引種別識別情報３および５を有する２つのサイド・チェーンに連続的に追加されることになり、これらの２つのブロックチェーンの最後のブロックのハッシュ値は同様に更新されることになる。例えば、コード３−１のハッシュ値はコード３−２のハッシュ値に更新され、コード５−１のハッシュ値は、コード５−２のハッシュ値に更新される。したがって、ブロック・ハッシュ値に対応するタイム・スタンプは、新しいブロックの生成と共に更新される。
【００５８】
この例において、ブロックチェーンに追加されることになる取引データが返金取引であり、値８（２３）の取引特徴情報を有するとき、上記の実施形態における手法に従って、第１の事前設定条件を満たす取引種別識別情報は、ブロックチェーン・データ・レコード・テーブル内で発見することができず、この種類の取引を処理するためのサイド・チェーンをブロックチェーン・システムが確立しなかったことを示す。したがって、ブロックチェーンに追加されることになる取引データの実行結果は、（取引種別識別情報が「＊」である）メイン・チェーンに書き込まれ、メイン・チェーンの最後のブロックのハッシュ値、および対応するタイム・スタンプは同様に更新される。例えば、コード＊−１は、コード＊−２に更新される。
【００５９】
ブロックチェーン・データ・レコード・テーブルに従ってブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断する方法は、データをブロックチェーンに書き込む様々な実施形態を実行するために、上記で詳細に説明される。下記の説明は、ブロックチェーン・データ・レコード・テーブルに対する様々な状況および影響における、ブロックチェーン・システム内のブロックチェーンのための様々な処理手法にフォーカスすることになる。
【００６０】
ブロックチェーン取引データ書込みリクエストをブロックチェーン・システムが受け取った後、本出願の実施形態による方法は以下をさらに含むことができる。
第２の事前設定条件が満たされるとき、サイド・チェーンとして新しいブロックチェーンをブロックチェーン・システムに追加すること、ならびに新しいブロックチェーンに対応するレコード、および新しいブロックチェーンの取引種別識別情報を、ブロックチェーン・データ・レコード・テーブルに追加すること。図３および図４に示されるように、ブロックチェーン・システムにおいて、サイド・チェーンは、値１および値２の取引特徴情報を有する取引データを処理するために一定の条件の下でブロックチェーンを分岐させることができ、サイド・チェーンの取引種別識別子は３である。例えば、「認証のために携帯電話を使用するためのポイントを稼ぐこと」などの、携帯電話認証を行うことをユーザに促すためのイベントが行われるとき、携帯電話認証取引の同時発生数が非常に多くなることが予測可能である。ブロックチェーン・システム内のメイン・チェーンによって同時発生数が完全に処理されることになる場合、処理が遅れる可能性があるか、処理が、他の種類の取引の処理とリソースを争う可能性がある。この状況において、サイド・チェーンは、実行のために（値２の取引特徴情報を有する）携帯電話認証をサイド・チェーンに組み込むために分離されることが可能であり、このことにより、ブロックチェーン・システム内の様々な種類の取引データによる処理要求、特に、一定の種類の取引データによる特殊な処理要求を満たす。
【００６１】
例えば、第２の事前設定条件は、ブロックチェーン取引データ書込みリクエストに含まれるブロックチェーンに追加されることになる取引データの取引特徴情報が、事前設定された取引特徴情報にマッチするというものであることが可能である。次に、ブロックチェーン・システムは、いくつかの取引種別がサイド・チェーンに書き込まれることを事前設定することができる。ブロックチェーンに追加されることになる新たに受け取った取引データが、これらの種類のうちの１つに属すとき、ブロックチェーンに追加されることになる取引データの取引特徴情報は、事前設定された取引特徴情報にマッチすることになる。したがって、新しいブロックチェーンは、ブロックチェーン・システム内のサイド・チェーンとして追加されることが可能であり、テーブル４に示されるようなブロックチェーン・データ・レコード・テーブル内の、ブロックチェーンに追加されることになる取引データのレコードとして行が追加される。
【００６２】
さらに、サイド・チェーンを追加するための上記の動作は、受け取ったブロックチェーン取引データ書込みリクエストの同時発生数が、事前設定された閾値に達したとき、および／または新しいブロックチェーンをサイド・チェーンとして追加するための事前設定された時間が達せられるときに、実行されることも可能である。
【００６３】
サイド・チェーンを追加するための上記の動作に加えて、サイド・チェーンとしてのブロックチェーンは、例えば、受け取ったブロックチェーン取引データ書込みリクエストの同時発生数が、事前設定された閾値より小さい、および／またはサイド・チェーンの有効時間が達せられる、といった、第３の事前設定条件が満たされるとき、ブロックチェーン・システム内で終了されることも可能である。次に、終了したブロックチェーンに対応するレコードは、ブロックチェーン・データ・レコード・テーブルの中で更新されることが可能である。例えば、図５に示されるように、ブロックチェーン・システムは、一定の条件の下でブロックチェーンのサイド・チェーンを終了させることができる。図５において取引種別識別情報３のサイド・チェーンを例として用いると、このサイド・チェーンが終了された後、取引特徴情報１および２の、２種類の取引データは、もはや、この終了されたサイド・チェーンに書き込まれることはなく、代わりに、２種類の取引データは、メイン・チェーンによって処理するために組み合わされる。
【００６４】
別の例において、ブロックチェーン・データ・レコード・テーブル内の、終了したブロックチェーンに対応するレコードを更新するために、様々な方法が使用されることが可能である。例えば、終了したブロックチェーンに対応するレコードは削除されることが可能であり、また、終了したブロックチェーンの状態情報は、無効な状態に変更されることも可能である。テーブル４において示されたブロックチェーン・データ・レコード・テーブルを例として用い、取引種別識別情報５のブロックチェーンを終了させることが望ましいと仮定すると、ブロックチェーンに対応する状態情報の値は、「０」に正確に設定されることが可能である。
【００６５】
上記で詳細に説明された取引データをブロックチェーン・システムに書き込むための方法に加えて、本出願の実施形態は、取引データをブロックチェーン・システムに書き込むためのデバイスをさらに同様に提供し、ブロックチェーン・システムは、少なくとも１つのブロックチェーンを含み、図６を参照すると、デバイスは以下を備える。
ブロックチェーンに追加されることになる取引データの取引特徴情報を含むブロックチェーン取引データ書込みリクエストを受け取るように構成されたリクエスト受取モジュール１０１、
ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンを判断するように構成されたブロックチェーン判断モジュール１０２であって、ブロックチェーン・データ・レコード・テーブルが、ブロックチェーン内の取引データの取引特徴情報を表すための、ブロックチェーンと関連付けられた取引種別識別情報を記録する、ブロックチェーン判断モジュール１０２、ならびに
ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンに、ブロックチェーンに追加されることになる取引データの実行結果を書き込むように構成されたブロックチェーン・データ追加モジュール１０３。
【００６６】
ブロックチェーン判断モジュール１０２は、ブロックチェーン・データ・レコード・テーブルにおいて表されたルールに従ってチェーンへの書込みを完了させるために、ブロックチェーンに追加されることになる取引データがどのブロックチェーンにルートされるべきかを判断するように構成されたデータ・ルーティング・モジュールと呼ばれることもある。
【００６７】
本出願において示されるブロックチェーン・システムは、暗号法を使用する関連付けを通じて生成された一連のデータ・ブロックとして解釈されることが可能である。各データ・ブロックは、情報の有効性を検証し、次のブロックを生成するためのネットワーク取引の情報を有する。ブロックは、チェーンのように終端間で接続される手法で格納される。チェーン格納の特性に基づいて、取引データは、本出願の実施形態における取引データの取引種別に従って分けられ、収集されることが可能であり、このことにより、様々なストレージおよび計算リソースを活用するか、様々な取引種別の取引データに対する様々な処理要求を満たすように追加のロジックに展開する。
【００６８】
本出願の実施形態による方法およびデバイスにおいて、ブロックチェーン・システムは、ブロックチェーンに追加されることになる取引データの取引特徴情報を含むブロックチェーン取引データ書込みリクエストを受け取ることができる。ブロックチェーンと関連付けられた取引種別識別情報は、ブロックチェーン・データ・レコード・テーブルに記録され、識別情報は、ブロックチェーン内の取引データの取引特徴情報を表すことができるので、ブロックチェーンに追加されることになる取引データにマッチするブロックチェーンは、ブロックチェーン・データ・レコード・テーブル、およびブロックチェーンに追加されることになる取引データの取引特徴情報に従って判断されることが可能であり、したがって、ブロックチェーンに追加されることになる取引データの実行結果は、マッチするブロックチェーンに書き込まれることが可能である。本出願の実施形態による技術的解決策を採用することによって、データをブロックチェーンに書き込む処理を完了させるために、ブロックチェーンに追加されることになる取引データの取引特徴情報に従って、マッチするブロックチェーンが選択されることが可能であり、取引種別に対応するブロックチェーンを記録することができるブロックチェーン・データ・レコード・テーブルが作り出される。したがって、様々な種類の取引データを区別して処理することが可能であり、ブロックチェーン・システム内の様々な種類の取引データに対する処理要求が満たされることが可能である。
【００６９】
本発明の実施形態は、方法、システム、またはコンピュータ・プログラム製品として提供されることが可能であるということを当業者は理解するであろう。したがって、本発明は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはソフトウェアとハードウェアを組み合わせる実施形態として実装されることが可能である。さらに、本発明は、コンピュータ使用可能プログラム・コードを有する（磁気ディスク・メモリ、ＣＤ−ＲＯＭ、光メモリ、等を含むがこれらに限定されない）１つまたは複数のコンピュータ使用可能ストレージ媒体上で実行されるコンピュータ・プログラム製品の形式であることが可能である。
【００７０】
本発明は、本発明の実施形態に従って、方法、デバイス（システム）、およびコンピュータ・プログラム製品の流れ図および／またはブロック図を参照しながら説明される。コンピュータ・プログラム命令は、流れ図および／またはブロック図における各処理および／またはブロック、ならびに流れ図および／またはブロック図における処理および／またはブロックの組合せを実行するために使用されることが可能であるということを理解されたい。これらのコンピュータ・プログラム命令は、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または機械を生成するための他のプログラム可能データ処理デバイスのプロセッサに提供されることが可能であり、流れ図における１つもしくは複数の処理において、および／またはブロック図における１つもしくは複数のブロックにおいて指定された機能を実行するための装置を生成することを、コンピュータまたは、他のプログラム可能データ処理デバイスのプロセッサによって実行される命令に行わせる。
【００７１】
これらのコンピュータ・プログラム命令は、特定の手法で作業するようにコンピュータまたは他のプログラム可能データ処理デバイスに命令することができるコンピュータ可読メモリに格納されることも可能であり、命令装置を含む製品を生成することを、コンピュータ可読メモリに格納された命令に行わせる。命令装置は、流れ図における１つもしくは複数の処理において、および／またはブロック図における１つもしくは複数のブロックにおいて指定された機能を実行する。
【００７２】
これらのコンピュータ・プログラム命令は、コンピュータまたは他のプログラム可能データ処理デバイスにロードされることも可能であり、コンピュータまたは他のプログラム可能デバイス上で一連の動作ステップが行われるようにし、このことにより、コンピュータ実行処理を生成する。したがって、コンピュータまたは他のプログラム可能デバイスで実行される命令は、流れ図における１つもしくは複数の処理において、および／またはブロック図における１つもしくは複数のブロックにおいて指定された機能を実行するためのステップを行う。
【００７３】
典型的な構成において、計算デバイスは、１つまたは複数のプロセッサ（ＣＰＵ）、入力／出力インターフェース、ネットワーク・インターフェース、およびメモリを含む。
【００７４】
メモリは、揮発性メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、および／または例えばリード・オンリ・メモリ（ＲＯＭ）もしくはフラッシュＲＡＭといった不揮発性メモリなどのコンピュータ可読媒体を含むことができる。メモリは、コンピュータ可読媒体の例である。
【００７５】
コンピュータ可読媒体は、任意の方法または技術を通じて情報の格納を実行できる永続的な、揮発性の、携帯型の、および非携帯型の媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータであることが可能である。コンピュータのストレージ媒体の例は、相変化ランダム・アクセス・メモリ（ＰＲＡＭ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、他の種類のランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、電気的消去可能プログラム可能リード・オンリ・メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリもしくは他のメモリ技術、コンパクトディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学メモリ、カセット、カセットおよびディスク・メモリもしくは他の磁気メモリ・デバイス、または計算デバイスにアクセス可能な情報を格納するために使用されることが可能な他の任意の非送信媒体を含むが、これらに限定されない。本明細書における定義によれば、コンピュータ可読媒体は、変調データ信号およびキャリアなどの一時的な媒体を含まない。
【００７６】
「含む（ｉｎｃｌｕｄｉｎｇ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」という用語、またはこれらの用語の他の任意の変形表現は非排他的な含有状況を包含し、それにより、一連の要素を含む処理、方法、物品、またはデバイスが、それら一連の要素を含むだけでなく、明確に挙げられていない他の要素も含むか、該処理、方法、物品、またはデバイスに固有の要素をさらに含むことになることを意図することにさらに留意されたい。さらなる制約がないとき、ステートメント「１つを備える（ｃｏｍｐｒｉｓｉｎｇ  ｏｎｅ  ．．．）」によって定義される要素は、上記の要素を含む処理、方法、物品、またはデバイスがさらなる同一の要素をさらに含むことを除外しない。
【００７７】
本出願の実施形態は、方法、システム、またはコンピュータ・プログラム製品として提供されることが可能であるということを当業者は理解するであろう。したがって、本出願は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはソフトウェアとハードウェアを組み合わせる実施形態として実装されることが可能である。さらに、本出願は、コンピュータ使用可能プログラム・コードを有する（磁気ディスク・メモリ、ＣＤ−ＲＯＭ、光学メモリ、等を含むがこれらに限定されない）１つまたは複数のコンピュータ使用可能ストレージ媒体上で実行されるコンピュータ・プログラム製品の形式であることが可能である。
【００７８】
上述は本出願の実施形態にすぎず、本出願を限定するために使用されるものではない。当業者にとって、本出願は、様々な修正および変形を有することが可能である。本出願の精神および原理の中で行われる任意の修正、同等の代用、または改善は、本出願の特許請求の範囲によって包含される。
【図１】
0006875557.tif 000006
【図２】
0006875557.tif 000007
【図３】
0006875557.tif 000008
【図４】
0006875557.tif 000009
【図５】
0006875557.tif 000010
【図６】
0006875557.tif 000011