JP7190404B2 - 計算機システムおよびリクエスト処理方法 - Google Patents

計算機システムおよびリクエスト処理方法 Download PDF

Info

Publication number
JP7190404B2
JP7190404B2 JP2019142881A JP2019142881A JP7190404B2 JP 7190404 B2 JP7190404 B2 JP 7190404B2 JP 2019142881 A JP2019142881 A JP 2019142881A JP 2019142881 A JP2019142881 A JP 2019142881A JP 7190404 B2 JP7190404 B2 JP 7190404B2
Authority
JP
Japan
Prior art keywords
request
blockchain
computers
transaction
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019142881A
Other languages
English (en)
Other versions
JP2021027443A5 (ja
JP2021027443A (ja
Inventor
大介 鬼頭
祐介 神
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2019142881A priority Critical patent/JP7190404B2/ja
Publication of JP2021027443A publication Critical patent/JP2021027443A/ja
Publication of JP2021027443A5 publication Critical patent/JP2021027443A5/ja
Application granted granted Critical
Publication of JP7190404B2 publication Critical patent/JP7190404B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明は、様々なデータを複数の機関で共有するブロックチェーンに関し、特に、ブロックチェーン間での認証方法に関する。
ブロックチェーンは、データの改ざんが困難で、仲介者無しの直接取引を可能にする特性を持っており、近年、仮想通貨を実現するシステムでの利用以外に、企業活動の基盤としての応用に注目が集まっている。
広くデータを公開するパブリックなブロックチェーンに加えて、同じコミュニティ内のメンバのみがデータを共有するプライベートなブロックチェーンが存在する。様々な団体がそれぞれのブロックチェーンを構築していく中で、各ブロックチェーン内に閉じて企業活動が行われていくケースも考えられるが、様々なコミュニティのブロックチェーンをつなぐことによって、企業活動の効率化を図れる可能性がある。
一方で、異なるブロックチェーン、特にプライベートなブロックチェーンに関しては、関係者以外にはデータを開示しないことが基本的な考え方であるため、異なるブロックチェーン間でのデータのやり取りを行うにあたっては、要求元や要求内容を正しく検証する必要がある。
ブロックチェーンを用いたシステムの連携に関する公知技術として、特許文献1に記載の技術がある。特許文献1には、「モノ4の所有権を管理する台帳管理部と、電子的な処理により開閉される鍵31が付され、モノ4を物理的に格納することができる物体格納器3と、鍵31を開けるまたは閉じることを実行可能である鍵管理部と、鍵31を開錠する要求を受けた場合に、要求をしたユーザと、台帳管理部に記録された所有権を有するユーザが一致するかを判定する判定部とを備える。鍵管理部は、判定部により、要求をしたユーザと、台帳管理部に記録された所有権を有するユーザとが一致すると判定されたときに、鍵31を開けて物体格納器3からモノ4を取り出し可能にするとともに、鍵31を開けたことを台帳管理部に通知する。」ことが記載されている。
特開2019-016342号公報
特許文献1に記載の技術では、ユーザからの要求を受付けるサーバは、自身が管理する商品およびユーザについては要求操作の正当性を判定できるが、他システムの管理下にある商品およびユーザについては要求の正当性を判定することができない。そのため、ブロックチェーン間の連携のユースケースにおいて、従来技術では連携先のブロックチェーンに対するリクエストの正当性を正しく判定することができない。
本発明は、ブロックチェーンの連携を実現するシステムにおいて、連携元ブロックチェーンが連携先ブロックチェーンにて管理されるユーザの情報等がわからないような場合でも、ユーザを適切に認証し、連携先のブロックチェーンへの不正なリクエストの送信または実行を防止する技術を提供する。
本発明の代表的な一例を示せば以下の通りである。すなわち、ブロックチェーンを構成する複数の計算機を備える計算機システムであって、前記複数の計算機は、第1ブロックチェーンを構成する複数の計算機と、第2ブロックチェーンを構成する複数の計算機とを含み、前記第1ブロックチェーンを構成する複数の計算機は、前記第1ブロックチェーン用の署名を含む、トランザクションを実行するためのリクエストを受信した場合、前記第1ブロックチェーン用の署名を用いた第1検証処理を実行し、前記第1検証処理の結果が検証成功である場合、前記リクエストが前記第2ブロックチェーンに関連するトランザクションを実行するためのリクエストであるか否かを判定し、前記リクエストが前記第2ブロックチェーンに関連するトランザクションを実行するためのリクエストであると判定された場合、前記リクエストが前記第2ブロックチェーン用の署名を含むか否かを判定し、前記リクエストが前記第2ブロックチェーン用の署名を含むと判定された場合、前記第2ブロックチェーンを構成する複数の計算機に前記リクエストを送信する。
本発明によれば、ブロックチェーンの連携を実現するシステムにおいて、連携先のブロックチェーンへの不正なリクエストの送信または実行を防止できる。上記した以外の課題、構成および効果は、以下の実施例の説明により明らかにされる。
実施例1の計算機システムのハードウェア構成およびソフトウェア構成の一例を示すブロック図である。 実施例1の計算機が保持するプログラム管理情報のデータ構造の一例を示す説明図である。 実施例1の計算機が保持する連携先情報のデータ構造の一例を示す説明図である。 実施例1の計算機が保持する台帳のデータ構造の一例を示す説明図である。 実施例1の計算機が保持する台帳のデータ構造の一例を示す説明図である。 実施例1の計算機が保持する連携制御情報のデータ構造の一例を示す説明図である。 実施例1の計算機が保持する連携制御情報のデータ構造の一例を示す説明図である。 実施例1の計算機が保持する状態管理情報のデータ構造の一例を示す説明図である。 実施例1の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。 実施例1の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。 実施例1のクライアント端末がBC間連携処理において実行する処理の一例を説明するフローチャートである。 実施例2の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。 実施例2の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。 実施例2の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。 実施例2の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。 実施例3の連携先BCに属する計算機が、連携元BCに属する計算機からリクエストを受信した場合に実行する処理の一例を示すフローチャートである。
以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
以下に説明する発明の構成において、同一または類似する構成または機能には同一の符号を付し、重複する説明は省略する。
図1は、実施例1の計算機システムのハードウェア構成およびソフトウェア構成の一例を示すブロック図である。
複数のブロックチェーン(以下、BCと記載する)の連携を実現する計算機システムは、1つ以上の連携元の計算機101と、1つ以上の連携先の計算機102と、1つ以上のクライアント端末103と、1つ以上のBC認証機関サーバ104とを備える。
BC認証機関サーバ104は、独立に存在する複数のBCの各々に、各BCを識別するためのIDおよび証明書等の情報を登録する。BC認証機関サーバ104は、例えば、あるBCに所属する連携先の計算機が、連携元の計算機のBCを識別する等に使用することを意図したものである。
計算機101、102およびクライアント端末103は、それぞれI/F112、182を介してネットワーク105に接続される。計算機101は、I/F112を介して、クライアント端末103等の外部機器に対して、操作リクエストの受付けおよび操作結果の応答等を行う。
計算機101、102は、BCを構成する計算機であり、CPU111、I/F112、メモリ113、およびHDD(Hard Disk Drive)114を備える。CPU111、I/F112、メモリ113、およびHDD114は内部バス等を介して互いに接続される。
CPU111は、メモリ113に格納されるプログラムにしたがって処理を実行することによって、I/F112を介してクライアント端末103等の外部機器からの操作リクエストの受信、操作リクエストに基づく操作の実行、外部機器に対する処理結果の送信等を実行する。
I/F112は、外部機器と接続するためのインタフェースである。I/F112は、例えば、ネットワークインタフェースである。
メモリ113は、CPU111が実行するプログラムおよびプログラムが使用する情報を格納する。
HDD114は、データを永続的に格納する。なお、計算機101は、HDD114の代わりにSSD(Solid State Drive)を備えてもよい。また、計算機101は、HDD114およびSSDの両方を備えてもよい。
クライアント端末103は、CPU181、I/F182、およびメモリ183を備える。CPU181、I/F182、およびメモリ183は内部バス等を介して互いに接続される。なお、クライアント端末103は、キーボード、マウス、およびタッチパネル等の入力装置、ならびに、ディスプレイ等の出力装置を備えてもよい。
CPU181は、メモリ183に格納されるプログラムにしたがって処理を実行することによって、I/F182を介した計算機101、102への操作リクエストの送信、計算機101、102からの処理結果の受信等を実行する。
I/F182は、外部機器と接続するためのインタフェースである。I/F182は、例えば、ネットワークインタフェースである。
メモリ183は、CPU181が実行するプログラムおよびプログラムが使用する情報を格納する。
以下の説明では、機能部を主語に処理を説明する場合、CPU111、181が当該機能部を実現するプログラムを実行していることを示す。
計算機101のメモリ113は、連携部121、トランザクション管理部122、合意形成部123、および認証部124を実現するプログラムを格納し、また、プログラム管理情報131および連携先情報132を格納する。また、計算機101のHDD114は、台帳(台帳情報)141を格納する。
プログラム管理情報131は、計算機101が、クライアント端末103等から要求されたトランザクションが、自BC内の台帳141の更新および自BC内の他の計算機101とのやり取り等、自BC内に閉じるトランザクションであるか、または、他BCへのリクエストの送信等、他BCと連携したトランザクション(他BCに関連するトランザクション)であるかを判定するために使用する情報である。プログラム管理情報131のデータ構造の詳細は図2を用いて説明する。
連携先情報132は、計算機102が属するBCと連携するBC等の連携先に関する情報を管理するための情報である。連携先情報132のデータ構造の詳細は図3を用いて説明する。
台帳141は、BC上で行われた取引等、トランザクションに関するデータ(トランザクションデータ)を管理するための情報である。台帳141のデータ構造の詳細は図4Aを用いて説明する。
連携部121は、自BCに属す計算機、他のBCに属す計算機、およびクライアント端末103等とデータの送受信を行う。
トランザクション管理部122は、クライアント端末103等から送信されたリクエストに基づいて、台帳141へのデータの記入および台帳141の参照等の処理をトランザクションとして実行し、また、トランザクションに関するデータ(トランザクションデータ)を管理する。
合意形成部123は、例えば、台帳141を更新するためのリクエストを受信した場合、更新を行う前に当該リクエストを事前検証し、自BC内の他の計算機101の事前検証結果を考慮して、台帳141を更新するか否かを判定し、判定結果に基づく処理を実行する。
認証部124は、クライアント端末103等からリクエストを受信した場合、クライアント端末103の認証およびデータに付与された署名の検証等を行う。
計算機102のメモリ113は、連携部151、トランザクション管理部152、合意形成部153、および認証部154を実現するプログラムを格納し、また、連携制御情報161および状態管理情報162を格納する。また、計算機102のHDD114は台帳171を格納する。
連携制御情報161は、他のBCに属す計算機等からのリクエストを受信した場合に、リクエストの送信元を制限するための方式およびリクエストの送信元に課す制約を管理するための情報である。連携制御情報161のデータ構造の詳細は図5Aおよび図5Bを用いて説明する。
状態管理情報162は、連携先BCにおいて、BC間の連携での整合性確保のために保有するトランザクションの実行状況を管理するための情報である。状態管理情報162のデータ構造の詳細は図6を用いて説明する。なお、状態管理情報162を用いた処理については実施例2にて説明する。
連携部151、トランザクション管理部152、合意形成部153、および認証部154は、連携部121、トランザクション管理部122、合意形成部123、および認証部124と同一の機能である。
クライアント端末103のメモリ183は、トランザクション要求部191、署名生成部192、および連携管理部193を実現するプログラムを格納する。
トランザクション要求部191は、連携元BCに属する計算機101および連携先BCに属する計算機102等の外部の計算機と連携し、トランザクションの実行等を指示するリクエストを外部の計算機に送信する。また、トランザクション要求部191は、外部の計算機からの応答の受信等を行う。
署名生成部192は、トランザクションのリクエストを送信するにあたって、当該トランザクションの正当性およびリクエストの送信元の正当性を保証するための署名を生成する。
連携管理部193は、BC間の連携にあたって、連携元BCに属する計算機および連携先BCに属する計算機等とやり取りして、双方のBCで管理するトランザクションの整合性を確保する。
なお、計算機101は連携制御情報161および状態管理情報162を保持してもよい。また、計算機102はプログラム管理情報131および連携先情報132を保持してもよい。
次に、実施例1の計算機システムが保持する情報のデータ構造について説明する。
まず、計算機101のメモリ113に格納されるプログラム管理情報131および連携先情報132、ならびにHDD114に格納される台帳141について説明する。
図2は、実施例1の計算機101が保持するプログラム管理情報131のデータ構造の一例を示す説明図である。
プログラム管理情報131は、ID201、プログラム名202、連携有無203、指定方法204、および連携先205の5つのフィールドから構成されるエントリを格納する。
ID201は、計算機101が管理するプログラムを識別するための識別情報を格納するフィールドである。プログラム名202は、プログラムの名称を格納するフィールドである。
連携有無203は、エントリに対応するプログラムが他のBC等、外部システムと連携した処理を行うか否かを示す情報を格納するフィールドである。連携有無203には、外部システムと連携した処理を行わないことを示す「無」または外部システムと連携した処理を行うことを示す「有」のいずれかが格納される。
指定方法204は、連携する外部システムが変更不変の固定的なものか、またはクライアント端末103からの引数等により指定可能なものかを示す情報を格納するフィールドである。なお、連携有無203が「無」の場合、指定方法204は空欄となる。
連携先205は、連携先を特定するための情報を格納するフィールドである。図2に示す例では、「1001」は、図3で説明する連携先情報132のID301が「1001」である連携先を示し、「param ext」は、クライアント端末103により指定された引数extが、連携先を示すことを意味する。
図3は、実施例1の計算機101が保持する連携先情報132のデータ構造の一例を示す説明図である。
連携先情報132は、ID301、名前302、および宛先情報303の3つのフィールドから構成されるエントリを格納する。
ID301は、連携先を識別するための識別情報を格納するフィールドである。名前302は、連携先の名称を格納するフィールドである。宛先情報303は、連携先の宛先の詳細情報を格納するフィールドである。宛先情報303には、URLおよびIPアドレス等が格納される。
図4Aは、実施例1の計算機101が保持する台帳141のデータ構造の一例を示す説明図である。
図4Aでは、一例として、商品売買に関するトランザクションに関するデータを管理する台帳141を示す。台帳141は、ID401、購入者402、販売者403、商品名404、数量405、価格406、日時407、およびtx_ID408の8つのフィールドから構成されるエントリを格納する。1つのデータが1つのトランザクションデータに対応する。
ID401は、台帳141に記録されたトランザクションデータを識別するための識別情報を格納するフィールドである。購入者402は、エントリに対応するトランザクションにおける購入者の情報を格納するフィールドである。販売者403は、エントリに対応するトランザクションにおける販売者の情報を格納するフィールドである。商品名404は、エントリに対応するトランザクションにおいて購入された商品の名称を格納するフィールドである。数量405は、購入された商品の数量を格納するフィールドである。価格406は、購入された商品価格を格納するフィールドである。日時407は、エントリに対応するトランザクションが行われた日時を格納するフィールドである。tx_ID408は、エントリに対応するトランザクションを識別するための識別情報(トランザクションID)を格納するフィールドである。
次に計算機102のメモリ113に格納される連携制御情報161および状態管理情報162、ならびにHDD114に格納される台帳171について説明する。
図5Aおよび図5Bは、実施例1の計算機102が保持する連携制御情報161のデータ構造の一例を示す説明図である。
連携制御情報161は制御定義情報500および制約情報510を含む。
制御定義情報500は、制御タイプ501、認証粒度502、認証方法503、制約情報ID504、適用先BC_ID505の5つのフィールドから構成されるエントリを格納する。
制御タイプ501は、連携制御方法のタイプを識別するための識別情報を格納するフィールドである。
認証粒度502は、リクエストの送信元の認証処理の粒度を示す情報を格納するフィールドである。例えば、認証粒度502が「機器」の場合、IPアドレス等を用いて機器単位でリクエストの送信元の認証が行われ、認証粒度502が「ユーザ」の場合、ユーザ名等を用いてユーザ単位でリクエストの送信元の認証が行われ、認証粒度502が「BC」の場合、リクエストの送信元が属すBCの識別情報等を用いてBC単位でリクエストの送信元の認証が行われる。
なお、認証粒度502には、複数の認証粒度を組み合わせた値を設定することもできる。例えば、「機器、BC」であれば、機器単位およびBC単位の認証が行われる。この場合、機器単位の認証に加えて、リクエストの送信元が属するBCの情報が加味された認証が行われる。
認証方法503は、リクエストの送信元の認証方法の詳細を示す情報を格納するフィールドである。例えば、認証方法503が「パスワード」の場合、ID/パスワード形式の認証が行われ、認証方法503が「署名(機器)」の場合、機器の署名を用いた認証が行われ、認証方法503が「署名(ユーザ)」の場合、ユーザの署名を用いた認証が行われ、認証方法503が「BC識別」の場合、リクエストの送信元が属するBCの情報を用いた認証が行われる。
制約情報ID504は、リクエストの送信元に課す制約を特定するための情報を格納するフィールドである。制約情報ID504には、後述する制約情報510のエントリの識別情報(制約ID510)が格納される。例えば、制約情報ID504が「2、3、4」の場合、制約ID511が「2」、「3」、「4」である3つの制約を課してリクエストの送信元の認証が行われる。
適用先BC_ID505は、エントリに対応する制御を適用するBCの識別情報を格納するフィールドである。例えば、「BC1」に属す計算機に対しては、連携にあたり、制御タイプ501が「1」である連携制御方法に基づいて連携制御が行われる。
制約情報510は、制約ID511およびスコア512の2つのフィールドから構成されるエントリを格納する。
制約ID511は、制約を識別するための識別情報を格納するフィールドである。スコア512は、制約の詳細を示す情報を格納するフィールドである。
ここで、実施例1において定義される制約について説明する。
制約ID511が「1」の制約では、計算機は、署名の実施者と、リクエスト内容の主体とが一致する場合に限り、リクエストを受付け、リクエストに基づいてトランザクションを実行する。
例えば、ユーザAが署名を行い、ユーザAからユーザBに支払うというリクエストの場合、当該リクエストは受付けられる。一方、ユーザAが署名を行い、ユーザBからユーザAに支払うというリクエストは、署名の実施者とリクエスト内容の主体とが一致しないため受付けられない。
制約ID511が「2」の制約では、計算機は、複数の異なる計算機(リクエストの送信元)から同一のトランザクションIDを含むリクエストを受信した場合に限り、リクエストを受付け、リクエストに基づいてトランザクションを実行する。
BCによっては、複数の計算機が台帳の更新等の処理にあたって、同一の処理の検証を行い、それに伴って重複する複数のリクエストが連携先のBCに属する計算機に送信されることを想定した制約である。
なお、単に、複数のリクエストを受信したことを判定することに加えて、所定のアドレスから送信されたリクエストであることも制約に加味してもよい。複数のリクエストを受信したことは、あるBCに属す計算機が独自にリクエストを送ってきたわけではないことを保証する一因となる。
制約ID511が「3」の制約では、計算機は、受信したリクエストに対して、誰もが閲覧可能な情報のみを提供する。
制約ID511が「4」の制約では、計算機は、受信したリクエストがリクエストの送信元の計算機が属するBCに関する情報に関するリクエストの場合情報を提供するが、そうでない場合には情報を提供しない。
例えば、リクエストの送信元の計算機が複数のBC(BC1、BC2)に属し、これらのBC上の取引に関する情報(例えば、支払い情報)を連携先のBC(BC3)が管理している場合、BC2にはBC1とは異なる組織が含まれるケースが想定される。このようなケースの場合、BC2上での取引に関する情報は、BC1のメンバには公開すべきではないと考えられる。そのため、BC1、BC2の両方に属する組織の計算機からリクエストを受信した場合に、連携先のBCに属する計算機が、BC1に属する計算機としてのリクエストに対してはBC1に関連する情報のみを提供し、それ以外は提供しない制御を実現する必要がある。制約ID511が「4」の制約は、前述の制御を実現するためのものである。
制約ID511が「4」の制約に基づく制御によって、連携先のBCまたは連携元のBCに属する計算機に対して、公開すべきでない情報が誤って提供されることを防止できる。
なお、計算機が複数のBCに属するか否かを判定する方法としては、連携先BCに属する計算機がそのような対応付け情報を管理し、当該情報に基づいて判定する方法が考えられる。また、IPアドレス等の計算機の識別情報を記録し、連携先のBCの台帳に記録されたトランザクションデータを参照して、一つの計算機が関与する異なるBCに関するトランザクションデータが記録されている否かを判定する方法が考えられる。
以上が連携制御情報161の説明である。
図6は、実施例1の計算機102が保持する状態管理情報162のデータ構造の一例を示す説明図である。
状態管理情報162は、tx_ID601、主体602、状態603、外部tx_ID604、開始時刻605、終了時刻606、および実行期限607の7つのフィールドから構成されるエントリを格納する。
tx_ID601は、トランザクションを識別するための識別情報を格納するフィールドである。
主体602は、トランザクションの実行者に関する情報を格納するフィールドである。
状態603は、トランザクションの実行状況を示す情報を格納するフィールドである。状態603には、トランザクションが終了していることを示す「済」、トランザクションが開始されずに待機していることを示す「待機」、トランザクションが実行中であることを示す「実行中」等が格納される。
外部tx_ID604は、連携元BCに属する計算機から送信された外部のtx_IDを格納するフィールドである。外部tx_ID604は、連携先BCのトランザクションが、連携元BCのトランザクションに紐づいて実行されていることを特定するための情報である。外部tx_ID604が空欄の場合、外部のBCからのリクエストに起因して発生したトランザクションではなく、自BC内で発生したトランザクションであることを示す。
開始時刻605は、トランザクションの開始時刻を格納するフィールドである。開始時刻605が空欄の場合、トランザクションが開始前であることを示す。
終了時刻606は、トランザクションの終了時刻を格納するフィールドである。終了時刻606が空欄の場合、トランザクションが実行中であることを示す。
実行期限607は、トランザクションの実行期限を格納するフィールドである。例えば状態603が「待機」であるエントリに対応するトランザクションにおいて、実行期限607に設定された時刻を経過した場合、当該トランザクションに対応するリクエストは削除される。
図4Bは、実施例1の計算機102が保持する台帳171のデータ構造の一例を示す説明図である。
図4Bでは、一例として、商品の支払いに関するトランザクションに関するデータを管理する台帳171を示す。台帳171は、ID411、支払者412、支払先413、金額414、日時415、BC_ID416、外部tx_ID417、およびtx_ID418の8つのフィールドから構成されるエントリを格納する。
ID411は、台帳171に記録されたトランザクションデータを識別するための識別情報を格納するフィールドである。支払者412は、エントリに対応するトランザクションにおける支払者の情報を格納するフィールドである。支払先413は、エントリに対応するトランザクションにおける支払先の情報を格納するフィールドである。金額414は、エントリに対応するトランザクションにおいて支払われた金額を格納するフィールドである。日時415は、エントリに対応するトランザクションの実行日時を格納するフィールドである。BC_ID416は、エントリに対応するトランザクションを実行するためのリクエストの送信元のBCの識別情報を格納するフィールドである。これによって、どのBCに属す計算機からのリクエストであるかを特定できる。外部tx_ID417は、連携元のBCに属する計算機から送信された、連携元BCにおけるトランザクションの識別情報を格納するフィールドである。tx_ID418は、連携先のBCにおいて記録されたトランザクションの識別情報を格納するフィールドである。
外部tx_ID417およびtx_ID418に基づいて、連携元BCのトランザクションと紐づく連携先BCのトランザクションを特定することができる。
以上が実施例1の計算機システムが保持する情報のデータ構造の説明である。
次に、実施例1のBCに属する計算機が実行するBC間連携処理について説明する。BC間連携処理は、連携元BCおよび連携先BCが連携して実行される。
図7Aおよび図7Bは、実施例1の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。ここでは、計算機101が属するBCを連携元BCと仮定し、計算機102が属するBCを連携先BCと仮定する。
<連携元BCに属する計算機の処理>
図7Aは、連携元BCに属する計算機101が実行する処理の一例を示すフローチャートである。
計算機101は、クライアント端末103から任意のトランザクションを実行するためのリクエストを受信する(ステップS701)。
例えば、ユーザが商品の購入等のトランザクションを実行するためのリクエストを送信した場合、リクエストには、購入手続に関する台帳の参照および更新等の操作情報が含まれる。
操作情報には、呼び出すプログラムおよび処理を実行するプログラム等を特定するための情報が含まれる。一つのプログラムが関与するトランザクションに対して一つのリクエストが発行されてもよし、複数のプログラムが関与するトランザクションに対して一つのリクエストが発行されてもよい。この場合、リクエスト毎に関与するプログラムを特定するための情報を別途管理すればよい。
なお、クライアント端末103は、連携元BC用の鍵を用いて署名を生成し、当該署名が付されたリクエストを連携元BCに属する計算機101に送信する。計算機101の認証部124は、リクエストを受信した場合、リクエストに含まれる署名の正当性を検証するための認証処理を実行する。正当な署名である場合、計算機101は当該リクエストを実行対象のリクエストとして受付ける。以下の説明では、前述した認証処理の結果が認証成功であるものとして処理を説明する。
次に、計算機101は、リクエストに対応したトランザクションを実行する場合に呼出されるプログラムを特定し(ステップS702)、特定されたプログラムの中に、BC間連携を行うプログラムが含まれるか否かを判定する(ステップS703)。すなわち、他BCに関連するトランザクションを実行するためのリクエストであるか否かが判定される。
具体的には、連携部121は、特定されたプログラムの名称がプログラム名202と一致するエントリを検索し、検索されたエントリの中に、連携有無203に「有」が設定されたエントリが少なくとも1つ以上存在するか否かを判定する。連携有無203に「有」が設定されたエントリが少なくとも1つ以上存在する場合、連携部121は、特定されたプログラムの中に、BC間連携を行うプログラムが含まれると判定する。
BC間連携を行うプログラムが含まれないと判定された場合、計算機101は、他BCと連携したリクエストではなく、ローカルなBCに閉じるリクエストと判定し、通常のBCにおけるトランザクションを実行する(ステップS704)。さらに、計算機101は、トランザクションの実行結果をクライアント端末103に送信し(ステップS709)、その後、処理を終了する。
BC間連携を行うプログラムが含まれると判定された場合、計算機101は、受信したリクエストに連携先BC用の署名が含まれるか否かを判定する(ステップS705)。
例えば、連携部121は、リクエストにローカルのBC用の署名とは異なる署名が含まれているかを確認する。なお、連携部121は、連携先BC用の認証局の証明書を事前に入手する等して、リクエストに含まれる署名が連携先BC用の署名であるか否かを判定してもよい。
受信したリクエストに連携先BC用の署名が含まれていないと判定された場合、計算機101は、連携先BCに送信するリクエストのデータに基づいてハッシュを生成し、クライアント端末103に当該ハッシュを含むリクエストの再送信依頼を送信し(ステップS706)、その後、処理を終了する。
クライアント端末103は、当該依頼を受信した場合、ハッシュを用いて連携先BC用の鍵を用いて署名を生成し、当該署名を含むリクエストを、再度、連携元BCに属する計算機101に送信する。これによって、連携先BCへのリクエストの送信が可能となる。すなわち、BCが連携したリクエストの処理を実現できる。
受信したリクエストに連携先BC用の署名が含まれると判定された場合、計算機101は、署名を含むリクエストを連携先BCに属する計算機102に送信する(ステップS707)。
このとき、連携部121は、連携元BCにおけるトランザクションの識別情報を連携先BCに属する計算機に送信する。具体的には、計算機101は、連携元BCで管理している台帳141のtx_ID408の値を、トランザクションの識別情報として連携先BCに属する計算機102に送信する。これによって、連携先BCにおいて実行されるトランザクションと、連携元BCにおいて実行されるトランザクションとを紐づけて管理することができる。
連携先BCに属する計算機102は、トランザクションの実行に伴って、台帳171のエントリを追加し、追加されたエントリの外部tx_ID417に受信したトランザクションの識別情報を設定し、tx_ID418に連携先BCにおけるトランザクションの識別情報を設定する。
計算機101は、連携先BCに属する計算機102から応答を受信した場合(ステップS708)、応答に含まれるトランザクションの実行結果をクライアント端末103に送信し(ステップS709)、その後、処理を終了する。
このとき、計算機101は、計算機102から受信したトランザクションの実行結果を台帳141に追加してもよい。
<連携先BCに属する計算機の処理>
図7Bは、連携先BCに属する計算機102が、連携元BCに属する計算機101からリクエストを受信した場合に実行する処理の一例を示すフローチャートである。
計算機102は、連携元BCに属する計算機101から連携先BC用の署名を含むリクエストを受信し(ステップS721)、連携先BC用の署名およびリクエスト内容に基づいて、受信したリクエストの正当性を検証する(ステップS722)。
本実施例では、連携制御情報161に基づいてリクエストの正当性が検証される。
署名の正当性の検証は、連携先BCで使用されている認証局の証明書等を用いて行われる。例えば、制約ID511が「1」の制約が適用されたBCに属する計算機からリクエストを受信した場合、計算機102は、署名の実施者およびリクエストの主体が一致するか否かを判定する。この場合、ユーザAが署名を行い、ユーザAからユーザBに支払うというリクエストは許可されるが、ユーザAが署名を行いユーザBからユーザAに支払うというリクエストは許可されない。なぜならば、署名の実施者とリクエストの主体とが一致しないためである。
連携先BCに属する計算機102において、連携先BCで使用する公開鍵証明書に含まれる主体者の名前を、連携先BCにおけるアカウント情報として設定し、署名の実施者とリクエストの主体とが一致するか否かを判定するようにしてもよい。
計算機102は、検証の結果に基づいて、検証が成功したか否かを判定する(ステップS723)。
検証が成功したと判定された場合、計算機102は、受信したリクエストに基づいてトランザクションを実行し、連携元BCに属する計算機101にトランザクションの実行結果を含む応答を送信する(ステップS724)。その後、計算機102は処理を終了する。
検証が失敗したと判定された場合、計算機102は、トランザクションを実行せずに、連携元BCに属する計算機101に、検証失敗等を示す実行結果を含む応答を送信する(ステップS725)。その後、計算機102は処理を終了する。
実施例1によれば、連携元BCが連携先BCにおけるユーザの情報等を把握していない場合でも、適切なユーザの認証を実現できる。これによって、連携先BCへの不正なリクエストの送信および実行を防止することができる。
(変形例)
次に、BC間連携処理の変形例について説明する。変形例では、クライアント端末103がBC間の連携の有無を判定する。したがって、クライアント端末103がプログラム管理情報131および連携先情報132を保持する。この場合、計算機101は、プログラム管理情報131および連携先情報132を保持していなくてもよい。
図8は、実施例1のクライアント端末がBC間連携処理において実行する処理の一例を説明するフローチャートである。
クライアント端末103は、連携元BCにトランザクションを実行させるためのリクエストを生成する(ステップS801)。具体的にはトランザクション要求部191がリクエストを生成する。リクエストには連携元BC用の署名が含まれる。
次に、クライアント端末103は、生成されたリクエストに対応したトランザクションを実行する場合に呼出されるプログラムを特定し(ステップS802)、特定されたプログラムの中に、BC間連携を行うプログラムが含まれるか否かを判定する(ステップS803)。
具体的には、連携管理部193がステップS702およびステップS703と同様の処理を実行する。
特定されたプログラムの中に、BC間連携を行うプログラムが含まれないと判定された場合、クライアント端末103は、連携元BCに属する計算機101に、生成されたリクエストを送信する(ステップS804)。その後、クライアント端末103は処理を終了する。
特定されたプログラムの中に、BC間連携を行うプログラムが含まれると判定された場合、クライアント端末103は、連携先BCに送信するリクエストのデータに基づいてハッシュを生成し、当該ハッシュを用いて連携先BC用の鍵を用いて署名を生成する(ステップS805)。
次に、クライアント端末103は、連携元BCに属する計算機101に、連携元BC用の署名および連携先BC用の署名を含むリクエストを送信する(ステップS806)。その後、クライアント端末103は処理を終了する。
図8に示すような処理が実行される場合、連携元BCに属する計算機101は、ステップS701からステップS706の処理と、ステップS708、ステップS709の処理を実行する。連携先BCに属する計算機101が実行する処理は特に変更がない。
実施例1の変形例によれば、クライアント端末103が事前に連携先BC用の署名要否を判定することによって、BCに属する計算機101、102とのインタラクションを低減することができる。
以上が、変形例の説明である。
次に、本発明の実施例2を説明する。実施例2では、BC間連携において、一つのBCの台帳のみが更新され、他のBCの台帳が更新されないといった状態の不整合を防止する。
具体的には、連携先BCに属する計算機は、連携元BCに属する計算機から要求されたトランザクションをすぐに実行させるのではなく待機させ、再度クライアント端末103から待機しているトランザクションのリクエストを受付けた場合、トランザクションを実行する。以下、実施例1との差異を中心に実施例2について説明する。
実施例2の計算機システムの構成は実施例1と同一である。実施例2のBCに属する計算機101、102のハードウェア構成およびソフトウェア構成は実施例1と同一である。また、実施例2のクライアント端末103のハードウェア構成およびソフトウェア構成は実施例1と同一である。
実施例2のBC間連携処理における連携元BCに属する計算機が実行する署名の要否に関する処理は実施例1と同一である。ただし、実施例2では、連携元BCに属する計算機が実施例1とは異なる処理を実行する。実施例2では、連携先BCに属する計算機が実行する処理が異なる。また、実施例2では、クライアント端末103が実施例1とは異なる処理を実行する。
図9A、図9B、図9C、および図9Dは、実施例2の計算機システムにおいて実行されるBC間連携処理の一例を説明するフローチャートである。ここでは、計算機101が属するBCを連携元BCと仮定し、計算機102が属するBCを連携先BCと仮定する。
<連携元BCに属する計算機の処理>
図9Aおよび図9Bは、連携元BCに属する計算機101が実行する処理の一例を示すフローチャートである。
ステップS701からステップS707、およびステップS709の処理は実施例1と同一である。
ステップS707の処理の後、計算機101は、連携先BCに属する計算機102から応答を受信する(ステップS901)。
計算機101は、応答に含まれる検証結果に基づいて、連携が成功か否かを判定する(ステップS902)。検証成功を示す検証結果の場合、計算機101は、連携が成功したと判定する。
連携が失敗したと判定された場合、計算機101は、クライアント端末103に連携の失敗を示す応答を送信し(ステップS903)、処理を終了する。
連携が成功したと判定された場合、計算機101は、トランザクションを実行し(S904)、トランザクションが成功したか否かを判定する(ステップS905)。
トランザクションの実行では、計算機101は、台帳141の更新または参照等の処理を実行する。例えば、計算機101は、連携先BCでの支払い処理の検証成功を受けて、連携元BCで当該処理に対応する商取引情報を台帳141に追加する。
トランザクションが成功したと判定された場合、計算機101は、クライアント端末103に、リクエストに対応するトランザクションの識別情報および連携先BCに属する計算機102の宛先情報とともに、トランザクションの成功を示す応答を送信する(ステップS906)。その後、計算機101は処理を終了する。
クライアント端末103に送信された応答に含まれるトランザクションの識別情報は、計算機101側で管理する識別情報(tx_ID408)である。
トランザクションが失敗したと判定された場合、計算機101は、クライアント端末103にリクエストの失敗を示す応答を送信し(ステップS907)、処理を終了する。この場合、連携先BCでは、トランザクションは実行されず、実行期限が経過した後にリクエストが削除される。
<連携先BCに属する計算機の処理>
図9Cは、連携先BCに属する計算機102が、連携元BCに属する計算機101からリクエストを受信した場合に実行する処理の一例を示すフローチャートである。
計算機102は、連携元BCに属する計算機101から連携先BC用の署名を含むリクエストを受信する(ステップS721)。
このとき、計算機102は状態管理情報162を更新する。具体的には、計算機102は、状態管理情報162にエントリを追加し、追加されたエントリのtx_ID601に連携先BCにおける識別情報を設定し、また外部tx_ID604にリクエストに含まれる識別情報をする。計算機102は、追加されたエントリの状態603に「待機」を設定する。また、計算機102は、追加されたエントリの主体602および実行期限607に、リクエストに含まれる値を設定する。
例えば、tx_ID601が「dk34kfa」のトランザクションは、待機中であり、連携元BCの識別情報が「AAA1」であるトランザクションと紐づけられていることが分かる。
次に、計算機102は、連携先BC用の署名およびリクエスト内容に基づいて、受信したリクエストの正当性を検証する(ステップS722)。
計算機102は、検証の結果に基づいて、検証が成功したか否かを判定する(ステップS723)。
検証が成功したと判定された場合、計算機102は、トランザクションを待機させ、連携元BCに属する計算機101に検証結果等を含む応答を送信する(ステップS911)。その後、計算機102はステップS913に進む。
検証が失敗したと判定された場合、計算機102は、トランザクションを実行せずに、連携元BCに属する計算機101に、検証失敗等を示す実行結果を含む応答を送信する(ステップS912)。その後、計算機102はステップS913に進む。
ステップS913では、計算機102は、クライアント端末103から待機中のトランザクションに対応するリクエストを受信する(ステップS913)。当該リクエストには連携元BC側のトランザクションの識別情報(tx_ID408)が含まれる。計算機102は、外部tx_ID604がリクエストに含まれるトランザクションの識別情報と一致するエントリを検索することによって、実行対象のトランザクションを特定できる。
計算機102は、受信したリクエストに含まれる署名等に基づいて、受信したリクエストの正当性を検証する(ステップS914)。
計算機102は、検証の結果に基づいて、検証が成功したか否かを判定する(ステップS915)。
検証が失敗したと判定された場合、計算機102はリクエストを受付けず、処理を終了する。
検証が成功したと判定された場合、計算機102は、トランザクションを実行し(ステップS916)、処理を終了する。なお、実施例2では、正当なクライアント端末103から必ずリクエストが送信されることを想定している。そのため、台帳の状態の不整合は起きない。
このとき、計算機102は状態管理情報162を更新する。具体的には、計算機102は、実行対象のトランザクションに対応するエントリの状態603を「実行中」に更新し、開始時刻605に時刻を設定する。トランザクションが完了した場合、計算機102は、エントリの状態603に「済」を設定し、終了時刻606に時刻を設定する。
<クライアント端末103の処理>
図9Dは、クライアント端末103が連携元BCに属する計算機101から応答を受信した場合に実行する処理の一例を示すフローチャートである。
クライアント端末103は、連携元BCに属する計算機101から応答を受信する(ステップS921)。
クライアント端末103は、受信した応答が連携成功を示す応答である否かを判定する(ステップS922)。
受信した応答が連携成功を示す応答でないと判定された場合、クライアント端末103は処理を終了する。受信する応答としては、連携失敗を示す応答、トランザクション成功を示す応答、およびトランザクション失敗を示す応答のいずれかである。
受信した応答が連携成功を示す応答であると判定された場合、クライアント端末103は、連携先BCに属する計算機102に、当該応答に含まれるトランザクションの識別情報を含むトランザクションのリクエストを送信し(ステップS923)、その後、処理を終了する。
実施例2によれば、BC間の連携において台帳の状態の不整合を防止することができる。
次に、本発明の実施例3を説明する。実施例1では、主に連携を要求するクライアント端末103の認証に関する処理が実行される。実施例3では、トランザクションの結果を連携先BCに属する計算機から連携元BCに属する計算機に送信する場合に、誤って連携元BCに関係しない情報が送信されることを防止する。
具体的には、連携先BCに属する計算機は、連携のリクエスト内容の検証に加えて、応答する内容の制御を行う。以下、実施例1との差異を中心に実施例3について説明する。
実施例3の計算機システムの構成は実施例1と同一である。実施例3のBCに属する計算機101、102のハードウェア構成およびソフトウェア構成は実施例1と同一である。また、実施例3のクライアント端末103のハードウェア構成およびソフトウェア構成は実施例1と同一である。
実施例3のBC間連携処理における連携元BCに属する計算機が実行する署名の要否に関する処理は実施例1と同一である。ただし、ステップS707において、連携元BCに属する計算機は、署名および連携元BCの識別情報とともに、リクエストを送信する。実施例3では、連携先BCに属する計算機が実行する処理が異なる。
<連携先BCに属する計算機の処理>
図10は、実施例3の連携先BCに属する計算機102が、連携元BCに属する計算機101からリクエストを受信した場合に実行する処理の一例を示すフローチャートである。
ステップS721からステップS725の処理は実施例1と同一である。
ステップS723において検証が成功したと判定された場合、計算機102は、連携元BCの識別情報およびクライアント端末103の署名等のクライアント端末103の識別情報を用いて、トランザクションの実行結果の送信先となるBCの正当性を検証する(ステップS1001)。なお、連携元BCの識別情報は、例えば、BC認証機関サーバ104等の認定機関によって各BCに対して発行/署名された識別情報、または、各BC間で予め取り決めた値等を用いる方法が考えられる。
例えば、計算機102は、台帳171のBC_ID416と、リクエストに含まれるBCの識別情報とが一致するか否かを判定する。台帳171のBC_ID416と、リクエストに含まれるBCの識別情報とが一致する場合、検証が成功したと判定される。
計算機102は、検証の結果に基づいて、検証が成功したか否かを判定する(ステップS1002)。
検証が成功したと判定された場合、計算機102はステップS724に進む。検証が失敗したと判定された場合、計算機102はステップS725に進む。
例えば、図4BのID411が「1」であるトランザクションデータの場合、BC_ID416は「BC1」である。連携元BCに属する計算機からリクエストとともに送信されたBCの識別情報が「BC1」である場合、検証が成功となり、連携元BCへの当該トランザクションデータの提供が許可される。一方、連携元BCに属する計算機から送信されたリクエストに含まれるBCの識別情報が「BC1」でない場合、検証が失敗となり、連携元BCへの当該トランザクションデータの提供が許可されない。
実施例3によれば、トランザクションの結果を連携先BCに属する計算機から連携元BCに属する計算機に送信する場合に、誤って連携元BCに関係しない情報が送信されることを防止できる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、およびそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、CD-ROM、DVD-ROM、ハードディスク、SSD(Solid State Drive)、光ディスク、光磁気ディスク、CD-R、磁気テープ、不揮発性のメモリカード、ROMなどが用いられる。
また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、C/C++、perl、Shell、PHP、Python、Java(登録商標)等の広範囲のプログラムまたはスクリプト言語で実装できる。
さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段またはCD-RW、CD-R等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
101、102 計算機
103 クライアント端末
104 BC認証機関サーバ
105 ネットワーク
111、181 CPU
112、182 I/F
113、183 メモリ
114 HDD
121、151 連携部
122、152 トランザクション管理部
123、153 合意形成部
124、154 認証部
131 プログラム管理情報
132 連携先情報
141、171 台帳
161 連携制御情報
162 状態管理情報
191 トランザクション要求部
192 署名生成部
193 連携管理部

Claims (12)

  1. ブロックチェーンを構成する複数の計算機を備える計算機システムであって、
    前記複数の計算機は、第1ブロックチェーンを構成する複数の計算機と、第2ブロックチェーンを構成する複数の計算機とを含み、
    前記第1ブロックチェーンを構成する複数の計算機は、
    前記第1ブロックチェーン用の署名を含む、トランザクションを実行するためのリクエストを受信した場合、前記第1ブロックチェーン用の署名を用いた第1検証処理を実行し、
    前記第1検証処理の結果が検証成功である場合、前記リクエストが前記第2ブロックチェーンに関連するトランザクションを実行するためのリクエストであるか否かを判定し、
    前記リクエストが前記第2ブロックチェーンに関連するトランザクションを実行するためのリクエストであると判定された場合、前記リクエストが前記第2ブロックチェーン用の署名を含むか否かを判定し、
    前記リクエストが前記第2ブロックチェーン用の署名を含むと判定された場合、前記第2ブロックチェーンを構成する複数の計算機に前記リクエストを送信することを特徴とする計算機システム。
  2. 請求項1に記載の計算機システムであって、
    前記第1ブロックチェーンを構成する複数の計算機は、前記リクエストに前記第2ブロックチェーン用の署名が含まれないと判定された場合、前記リクエストの送信元に、前記第2ブロックチェーン用の署名の生成を指示するリクエストの再送信依頼を送信し、
    前記第2ブロックチェーンを構成する複数の計算機は、
    前記第1ブロックチェーンを構成する複数の計算機から前記リクエストを受信した場合、前記リクエストに含まれる第2ブロックチェーン用の署名を用いて前記リクエストの正当性を検証する第2検証処理を実行し、
    前記第2検証処理の結果が検証成功である場合、前記リクエストに対応するトランザクションを実行することを特徴とする計算機システム。
  3. 請求項2に記載の計算機システムであって、
    前記第2ブロックチェーンを構成する複数の計算機は、前記第2検証処理において、前記第2ブロックチェーン用の署名が正当であり、かつ、前記リクエストにおけるトランザクションの主体となるユーザと前記第2ブロックチェーン用の署名を行ったユーザとが一致する場合、検証成功と判定することを特徴とする計算機システム。
  4. 請求項2に記載の計算機システムであって、
    前記第1ブロックチェーンを構成する複数の計算機は、前記リクエストが前記第2ブロックチェーン用の署名を含むと判定された場合、前記第2ブロックチェーンを構成する複数の計算機に前記第1ブロックチェーンの識別情報とともに、前記リクエストを送信し、
    前記第2ブロックチェーンを構成する複数の計算機は、
    前記第2検証処理の結果が検証成功である場合、前記リクエストとともに送信された前記第1ブロックチェーンの識別情報を用いて、前記リクエストに対応するトランザクションの実行結果の送信先のブロックチェーンの正当性を検証する第3検証処理を実行し、
    前記第3検証処理の結果が検証成功である場合、前記リクエストに対応するトランザクションを実行することを特徴とする計算機システム。
  5. 請求項1に記載の計算機システムであって、
    前記第2ブロックチェーンを構成する複数の計算機は、
    前記第1ブロックチェーンを構成する複数の計算機から前記リクエストを受信した場合、前記リクエストに含まれる前記第2ブロックチェーン用の署名を用いて前記リクエストの正当性を検証する第2検証処理を実行し、
    前記第2検証処理の結果が検証成功である場合、前記第1ブロックチェーンを構成する複数の計算機に、前記第2検証処理の結果を含む応答を送信し、
    前記第1ブロックチェーンを構成する複数の計算機は、
    前記応答を受信した場合、前記リクエストに対応するトランザクションを実行し、
    前記リクエストに対応するトランザクションの実行が成功した場合、前記リクエストの送信元にトランザクションの成功を通知することによって、前記リクエストの送信元が、前記第2ブロックチェーンを構成する複数の計算機に前記リクエストを送信するように制御し、
    前記第2ブロックチェーンを構成する複数の計算機は、前記リクエストの送信元から前記リクエストを受信した場合、前記リクエストに対応するトランザクションを実行することを特徴とする計算機システム。
  6. 請求項1に記載の計算機システムであって、
    前記第1ブロックチェーンを構成する複数の計算機および前記第2ブロックチェーンを構成する複数の計算機は、前記第1ブロックチェーンおよび前記第2ブロックチェーン間で送受信されるリクエストに対応するトランザクションを、自ブロックチェーンにおける識別情報と他ブロックチェーンにおける識別情報とを対応づけて管理することを特徴とする計算機システム。
  7. ブロックチェーンを構成する複数の計算機を有する計算機システムが実行するリクエスト処理方法であって、
    前記複数の計算機は、第1ブロックチェーンを構成する複数の計算機と、第2ブロックチェーンを構成する複数の計算機とを含み、
    前記リクエスト処理方法は、
    前記第1ブロックチェーンを構成する複数の計算機が、前記第1ブロックチェーン用の署名を含む、トランザクションを実行するためのリクエストを受信した場合、前記第1ブロックチェーン用の署名を用いた第1検証処理を実行する第1のステップと、
    前記第1ブロックチェーンを構成する複数の計算機が、前記第1検証処理の結果が検証成功である場合、前記リクエストが前記第2ブロックチェーンに関連するトランザクションを実行するためのリクエストであるか否かを判定する第2のステップと、
    前記第1ブロックチェーンを構成する複数の計算機が、前記リクエストが前記第2ブロックチェーンに関連するトランザクションを実行するためのリクエストであると判定された場合、前記リクエストが前記第2ブロックチェーン用の署名を含むか否かを判定する第3のステップと、
    前記第1ブロックチェーンを構成する複数の計算機が、前記リクエストが前記第2ブロックチェーン用の署名を含むと判定された場合、前記第2ブロックチェーンを構成する複数の計算機に前記リクエストを送信する第4のステップと、を含むことを特徴とするリクエスト処理方法。
  8. 請求項7に記載のリクエスト処理方法であって、
    前記第1ブロックチェーンを構成する複数の計算機が、前記リクエストに前記第2ブロックチェーン用の署名が含まれないと判定された場合、前記リクエストの送信元に、前記第2ブロックチェーン用の署名の生成を指示するリクエストの再送信依頼を送信する第5のステップと、
    前記第2ブロックチェーンを構成する複数の計算機が、前記第1ブロックチェーンを構成する複数の計算機から前記リクエストを受信した場合、前記リクエストに含まれる第2ブロックチェーン用の署名を用いて前記リクエストの正当性を検証する第2検証処理を実行する第6のステップと、
    前記第2ブロックチェーンを構成する複数の計算機が、前記第2検証処理の結果が検証成功である場合、前記リクエストに対応するトランザクションを実行する第7のステップと、を含むことを特徴とするリクエスト処理方法。
  9. 請求項8に記載のリクエスト処理方法であって、
    前記第6のステップは、前記第2ブロックチェーンを構成する複数の計算機が、前記第2ブロックチェーン用の署名が正当であり、かつ、前記リクエストにおけるトランザクションの主体となるユーザと前記第2ブロックチェーン用の署名を行ったユーザとが一致する場合、検証成功と判定するステップを含むことを特徴とするリクエスト処理方法。
  10. 請求項8に記載のリクエスト処理方法であって、
    前記第4のステップは、前記第1ブロックチェーンを構成する複数の計算機が、前記第2ブロックチェーンを構成する複数の計算機に、前記第1ブロックチェーンの識別情報とともに前記リクエストを送信するステップを含み、
    前記第7のステップは、
    前記第2ブロックチェーンを構成する複数の計算機が、前記リクエストとともに送信された前記第1ブロックチェーンの識別情報を用いて、前記リクエストに対応するトランザクションの実行結果の送信先のブロックチェーンの正当性を検証する第3検証処理を実行するステップと、
    前記第2ブロックチェーンを構成する複数の計算機が、前記第3検証処理の結果が検証成功である場合、前記リクエストに対応するトランザクションを実行するステップと、を含むことを特徴とするリクエスト処理方法。
  11. 請求項7に記載のリクエスト処理方法であって、
    前記第2ブロックチェーンを構成する複数の計算機が、前記第1ブロックチェーンを構成する複数の計算機から前記リクエストを受信した場合、前記リクエストに含まれる前記第2ブロックチェーン用の署名を用いて前記リクエストの正当性を検証する第2検証処理を実行するステップと、
    前記第2ブロックチェーンを構成する複数の計算機が、前記第2検証処理の結果が検証成功である場合、前記第1ブロックチェーンを構成する複数の計算機に、前記第2検証処理の結果を含む応答を送信するステップと、
    前記第1ブロックチェーンを構成する複数の計算機が、前記応答を受信した場合、前記リクエストに対応するトランザクションを実行するステップと、
    前記第1ブロックチェーンを構成する複数の計算機が、前記リクエストに対応するトランザクションの実行が成功した場合、前記リクエストの送信元にトランザクションの成功を通知することによって、前記リクエストの送信元が、前記第2ブロックチェーンを構成する複数の計算機に前記リクエストを送信するように制御するステップと、
    前記第2ブロックチェーンを構成する複数の計算機が、前記リクエストの送信元から前記リクエストを受信した場合、前記リクエストに対応するトランザクションを実行するステップと、を含むことを特徴とするリクエスト処理方法。
  12. 請求項7に記載のリクエスト処理方法であって、
    前記第1ブロックチェーンを構成する複数の計算機および前記第2ブロックチェーンを構成する複数の計算機は、前記第1ブロックチェーンおよび前記第2ブロックチェーン間で送受信されるリクエストに対応するトランザクションを、自ブロックチェーンにおける識別情報と他ブロックチェーンにおける識別情報とを対応づけて管理することを特徴とするリクエスト処理方法。
JP2019142881A 2019-08-02 2019-08-02 計算機システムおよびリクエスト処理方法 Active JP7190404B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019142881A JP7190404B2 (ja) 2019-08-02 2019-08-02 計算機システムおよびリクエスト処理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019142881A JP7190404B2 (ja) 2019-08-02 2019-08-02 計算機システムおよびリクエスト処理方法

Publications (3)

Publication Number Publication Date
JP2021027443A JP2021027443A (ja) 2021-02-22
JP2021027443A5 JP2021027443A5 (ja) 2022-03-08
JP7190404B2 true JP7190404B2 (ja) 2022-12-15

Family

ID=74664148

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019142881A Active JP7190404B2 (ja) 2019-08-02 2019-08-02 計算機システムおよびリクエスト処理方法

Country Status (1)

Country Link
JP (1) JP7190404B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7354877B2 (ja) * 2020-02-28 2023-10-03 富士通株式会社 制御方法、制御プログラムおよび情報処理装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017038507A1 (ja) 2015-09-03 2017-03-09 日本電信電話株式会社 許諾情報管理システム、利用者端末、権利者端末、許諾情報管理方法、および、許諾情報管理プログラム
JP2017204070A (ja) 2016-05-10 2017-11-16 日本電信電話株式会社 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム
WO2018223995A1 (zh) 2017-06-07 2018-12-13 众安信息技术服务有限公司 实现区块链跨链通信的方法、装置及***
JP2019021296A (ja) 2017-07-11 2019-02-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 電子投票システム、及び、制御方法
WO2019081530A1 (en) 2017-10-26 2019-05-02 Gemalto Sa METHODS OF RECORDING AND SHARING A DIGITAL IDENTITY OF A USER USING DISTRIBUTED REGISTERS
WO2019106006A1 (en) 2017-12-01 2019-06-06 Quant Network Ltd. Blockchain communications and ordering

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017038507A1 (ja) 2015-09-03 2017-03-09 日本電信電話株式会社 許諾情報管理システム、利用者端末、権利者端末、許諾情報管理方法、および、許諾情報管理プログラム
JP2017204070A (ja) 2016-05-10 2017-11-16 日本電信電話株式会社 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム
WO2018223995A1 (zh) 2017-06-07 2018-12-13 众安信息技术服务有限公司 实现区块链跨链通信的方法、装置及***
JP2019021296A (ja) 2017-07-11 2019-02-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 電子投票システム、及び、制御方法
WO2019081530A1 (en) 2017-10-26 2019-05-02 Gemalto Sa METHODS OF RECORDING AND SHARING A DIGITAL IDENTITY OF A USER USING DISTRIBUTED REGISTERS
WO2019106006A1 (en) 2017-12-01 2019-06-06 Quant Network Ltd. Blockchain communications and ordering

Also Published As

Publication number Publication date
JP2021027443A (ja) 2021-02-22

Similar Documents

Publication Publication Date Title
JP7108611B2 (ja) 電子手形管理方法及び装置並びに記憶媒体
US11151623B2 (en) Peer-to-peer trading platform
Baird et al. Hedera: A public hashgraph network & governing council
JP7377312B2 (ja) ブロックチェーンにより実現されるシステム及び方法
JP6389350B2 (ja) トランザクション処理装置、トランザクション処理方法、及びそのためのプログラム
US7958019B2 (en) Peer-to-peer trading platform with roles-based transactions
US7877353B2 (en) Peer-to-peer trading platform with relative reputation-based item search and buddy rating
US8335822B2 (en) Peer-to-peer trading platform with search caching
CN116982033A (zh) 先进的不可替代令牌区块链架构
JP2022520656A (ja) ブロックチェーンネットワークを介した移転を実施するためのコンピュータで実施されるシステムおよび方法
TW201141159A (en) Securing asynchronous client server transactions
US20220156725A1 (en) Cross-chain settlement mechanism
US11627122B2 (en) Inter-system linking method and node
JP7462903B2 (ja) 利用者端末、認証者端末、登録者端末、管理システムおよびプログラム
CN110599264A (zh) 卡券数据处理方法、装置及电子设备
KR20220143879A (ko) 플랫폼 서비스 검증
CN113994628A (zh) 通过侧信道流式传输部分数据
CN116569517A (zh) 用于发布操作***的基于区块链的***和方法
TWI646487B (zh) 具權限分級和避免重複執行的智能合約執行系統及其方法
JP7190404B2 (ja) 計算機システムおよびリクエスト処理方法
JP2023067688A (ja) 取引支援システム、取引支援方法及びプログラム
US20230125507A1 (en) Blockchain transaction double spend proof
KR20220143873A (ko) 블록체인과 연관된 이벤트들의 시퀀스에 대한 이벤트 스트림들
KR102634677B1 (ko) 호환 가능한 블록체인 네트워크 간의 자산 교환 방법
JP2023537698A (ja) ブロックチェーンネットワークとの接続

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220228

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220228

TRDD Decision of grant or rejection written
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221118

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20221122

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221205

R150 Certificate of patent or registration of utility model

Ref document number: 7190404

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150