(57)【特許請求の範囲】
【請求項１】
第１のアセットを管理する第１の台帳データベースに対して前記第１のアセットに対する第１の操作を行うとともに、第２のアセットを管理する第２の台帳データベースに対して前記第２のアセットに対する第２の操作を行う場合に、
コンピュータが、
前記第１の台帳データベースにおいて前記第１のアセットをロックし、
前記第２の台帳データベースに対して前記第２の操作を行うトランザクションを送信し、
前記トランザクションが成功した場合に、前記第１のアセットのロックを解除し、前記第１の操作を行うこと、
を特徴とする情報処理方法。
【請求項２】
請求項１に記載の情報処理方法であって、
前記コンピュータが、
前記第２の操作の完了前に、前記第２の操作を中止する中止トランザクションを前記第２の台帳データベースに送信し、
前記中止トランザクションが成功したときに、前記第１の操作を中止して前記ロックを解除すること、
を特徴とする情報処理方法。
【請求項３】
請求項２に記載の情報処理方法であって、
前記コンピュータが、
前記中止トランザクションが失敗したときには、前記ロックを解除して前記第１の操作を完了すること、
を特徴とする情報処理方法。
【請求項４】
請求項１に記載の情報処理方法であって、
前記コンピュータが、
前記トランザクションが失敗したときには、前記第１の操作を中止して前記ロックを解除すること、
を特徴とする情報処理方法。
【請求項５】
第１のアセットを管理する第１の台帳データベースに対して前記第１のアセットに対する第１の操作を行うとともに、第２のアセットを管理する第２の台帳データベースに対して前記第２のアセットに対する第２の操作を行う場合に、
コンピュータに、
前記第１のアセットをロックするステップと、
前記第２の台帳データベースに対して前記第２の操作を行うトランザクションを送信するステップと、
前記トランザクションが成功した場合に、前記第１のアセットのロックを解除し、前記第１の操作を行うステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
複数のブロックチェーン間で通信を行うクロスチェーン通信が検討されている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２０１９−５３６３８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載のシステムでは複数のブロックチェーンに跨がる状態遷移についてアトミック性を担保することができない。
【０００５】
本発明はこのような背景を鑑みてなされたものであり、複数台帳間での状態遷移についてのアトミック性を担保することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するための本発明の主たる発明は、情報処理方法であって、第１のアセットを管理する第１の台帳データベースに対して前記第１のアセットに対する第１の操作を行うとともに、第２のアセットを管理する第２の台帳データベースに対して前記第２のアセットに対する第２の操作を行う場合に、前記第１の台帳データベースにおいて前記第１のアセットをロックし、前記第２の台帳データベースに対して前記第２の操作を行うトランザクションを送信し、前記トランザクションが成功した場合に、前記第１のアセットのロックを解除し、前記第１の操作を行うこと、を特徴とする。
【０００７】
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。
【発明の効果】
【０００８】
本発明によれば、複数台帳間での状態遷移についてのアトミック性を担保することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態の取引管理システムの構成例を示す図である。
【図２】ブロックチェーンＡの構成例を示す図である。
【図３】本実施形態の取引管理システムにおける取引を説明する図である。
【図４】ブロックチェーンＡ及びＢを構成するノード２０のハードウェア構成例を示す図である。
【図５】ノード２０のソフトウェア構成例を示す図である。
【図６】ユーザ端末１３のソフトウェア構成例を示す図である。
【図７】クロスチェーンでのカードの操作が正常に終了した場合の動作を説明する図である。
【図８】クロスチェーンでのカードの移転がブロックチェーンＡで失敗した場合の動作を説明する図である。
【図９】クロスチェーンでの騎士のカードの移転操作がブロックチェーンＢで失敗した場合の動作を説明する図である。
【図１０】クロスチェーンでのカードの操作中に取引の中止が指示された場合の動作を説明する図である。
【図１１】クロスチェーンでのアセットの操作中に中止が指示されたが中止できなかった場合の動作を説明する図である。
【発明を実施するための形態】
【００１０】
＜発明の概要＞
本発明の実施形態の内容を列記して説明する。本発明は、たとえば、以下のような構成を備える。
［項目１］
第１のアセットを管理する第１の台帳データベースに対して前記第１のアセットに対する第１の操作を行うとともに、第２のアセットを管理する第２の台帳データベースに対して前記第２のアセットに対する第２の操作を行う場合に、
前記第１の台帳データベースにおいて前記第１のアセットをロックし、
前記第２の台帳データベースに対して前記第２の操作を行うトランザクションを送信し、
前記トランザクションが成功した場合に、前記第１のアセットのロックを解除し、前記第１の操作を行うこと、
を特徴とする情報処理方法。
［項目２］
項目１に記載の情報処理方法であって、
前記第２の操作の完了前に、前記２の操作を中止する中止トランザクションを前記第２の台帳データベースに送信し、
前記中止トランザクションが成功したときに、前記第１の操作を中止して前記ロックを解除すること、
を特徴とする情報処理方法。
［項目３］
項目２に記載の情報処理方法であって、
前記中止トランザクションが失敗したときには、前記ロックを解除して前記第１の操作を完了すること、
を特徴とする情報処理方法。
［項目４］
項目１に記載の情報処理方法であって、
前記トランザクションが失敗したときには、前記第１の操作を中止して前記ロックを解除すること、
を特徴とする情報処理方法。
［項目５］
第１のアセットを管理する第１の台帳データベースに対して前記第１のアセットに対する第１の操作を行うとともに、第２のアセットを管理する第２の台帳データベースに対して前記第２のアセットに対する第２の操作を行う場合に、
コンピュータに、
前記第１のアセットをロックするステップと、
前記第２の台帳データベースに対して前記第２の操作を行うトランザクションを送信するステップと、
前記トランザクションが成功した場合に、前記第１のアセットのロックを解除し、前記第１の操作を行うステップと、
を実行させるためのプログラム。
【００１１】
＜システムの概要＞
以下、本発明の一実施形態に係る取引管理システムについて説明する。図１は、本実施形態の取引管理システムの構成例を示す図である。本実施形態の取引管理システムは、２つのブロックチェーンＡ及びブロックチェーンＢを含んで構成される。なお、取引管理システムは２つ以上のブロックチェーンを含むようにすることもできる。ブロックチェーンとは、複数のノードの間で、取り扱う台帳データをセキュアに共有する分散データベースである。本実施形態では、ブロックチェーンを一例として取り上げるが、本実施形態の思想は、ブロックチェーンではない分散台帳技術を用いた任意の台帳管理システムについて適用可能である。また、ブロックチェーンＡ及びＢに代えて、分散型でない台帳データベースを採用することもできる。例えば、ブロックチェーンＡ及び／又はＢは、リレーショナルデータベースやオブジェクトデータベース、キーバリューストアなどのデータベースシステムにより台帳を管理することも可能である。
【００１２】
ブロックチェーンＡ及びブロックチェーンＢはそれぞれ、ユーザ端末１３と通信可能に接続される。ユーザ端末１３は、例えば、パーソナルコンピュータやスマートフォン、タブレットコンピュータなどのコンピュータである。システムの利用者はユーザ端末１３を操作して、ブロックチェーンＡ及びＢで管理されるアセット（本実施形態では、トレーディングカードゲームに用いられるカードを想定するが、これに限らず、電子的なアセットとして管理できるものであればよい。）の操作を行うことができる。
【００１３】
図２は、ブロックチェーンＡの構成例を示す図である。なお、ブロックチェーンＢについても同様の構成を備えることができる。ブロックチェーンＡは、複数のノード２０により構成されうる。各ノード２０は分散台帳３１を備えることができる。この分散台帳３１の内容がいわゆるブロックチェーンの仕組みにより改ざん困難に管理されうる。なお、ブロックチェーンによる分散台帳管理の仕組みについては一般的なものを採用するものとしてここでは詳細な説明を省略する。
【００１４】
＜アセット操作の概要＞
本実施形態では、２つのブロックチェーンＡ及びＢに跨がる、いわゆるクロスチェーンでのカードの操作を行う。カードの操作には、例えば、カードの生成、削除、移転、ロックなど、アセットの状態を変化させる任意の操作が含まれる。また、カードがファンジブル（代替可能）である場合などには、カードの種類毎にユーザが何枚のカードを所有しているかを管理するべく、カード枚数の加算や減算などの操作も含まれうる。カードの操作は、トランザクションとして分散台帳３１に登録される。以下の説明において、ブロックチェーンＡでは、「ドラゴン」のカードを管理しており、ブロックチェーンＢでは、「騎士」のカードを管理しているものとし、カードはいずれも代替可能なファンジブルトークン（ＦＴ）として管理されているものとする。
【００１５】
本実施形態の取引管理システムでは、ブロックチェーンＡ上でドラゴンのカードをロックし、このロックを確認したのち、ブロックチェーンＢにおいて騎士のカードの所有権を移転する。また、ブロックチェーンＡでは、ブロックチェーンＢでの移転完了を確認したのち、ドラゴンのカードのロックを解除し、ドラゴンのカードの所有権を移転する。取引が完了する前に取引を中止する場合には、取引中止をブロックチェーンＢに伝達し、ブロックチェーンＢで対応する取引の中止を記録する。取引中止の記録が完了したことが確認された場合にのみ、ロックしてあるドラゴンのカードを持ち主に返却する。以上のようにして、クロスチェーンでのカード所有権の操作をアトミックに行うことができる。アトミックな操作（原子操作）とは、複数の操作が全て成功するか、あるいは全て失敗するかが保証されるように操作が行われることをいう。本実施形態の取引管理システムでは、上述のドラゴン及び騎士のカードについて、ドラゴン及び騎士のカードが全て移転するか、いずれも移転しないかの何れかとなるように保証されている。
【００１６】
図３は、本実施形態の取引管理システムにおける取引を説明する図である。例えば、ブロックチェーンＡにおいてアカウント（図３の例ではＡｌｉｃｅとＢｏｂ）ごとにドラゴンのカードの所有枚数が管理されており、ブロックチェーンＢにおいてはアカウントごとに騎士のカードの所有枚数が管理されている。図３の例では、Ａｌｉｃｅはドラゴンのカードを１枚、騎士のカードを０枚有しており、Ｂｏｂはドラゴンのカードを０枚、騎士のカードを２枚有している。ここでドラゴンのカードの１枚と騎士のカード２枚とが同価値であり、Ａｌｉｃｅの１枚のドラゴンのカードと、Ｂｏｂの２枚の騎士のカードとを交換することを考える。これは、ＡｌｉｃｅからＢｏｂに１枚のドラゴンのカードの譲渡があり、同時に、ＢｏｂからＡｌｉｃｅに２枚の騎士のカードの譲渡があることになる。この取引にはアトミック性が求められる。すなわち、ブロックチェーンＡにおいてＡｌｉｃｅのドラゴンのカードの所有枚数を１減らし、Ｂｏｂのドラゴンのカードの所有枚数を１増やすとともに、ブロックチェーンＢにおいてＢｏｂの騎士のカードの所有枚数を２減らし、Ａｌｉｃｅの騎士のカードの所有枚数を２増やすという状態遷移の全てが成功するか、全てが失敗するかのいずれかであることが担保される必要がある。
【００１７】
ここでブロックチェーンＡ及びＢのそれぞれにおいて、カードの移動（所有枚数の変更）の前にアセットをロックすることでアトミック性を担保することができる。本実施形態の取引管理システムではさらに、一方のブロックチェーン（本実施形態ではブロックチェーンＡ）におけるアセット（本実施形態ではドラゴンのカード）のみをロックすることによって、アトミック性を担保するとともに、ブロックチェーンＢにおけるアセット（騎士のカード）の流動性をなるべく阻害しないようにすることができる。以下、詳細について説明する。
【００１８】
＜ノード２０＞
図４は、ブロックチェーンＡ及びＢを構成するノード２０のハードウェア構成例を示す図である。なお、図示された構成は一例であり、これ以外の構成を有していてもよい。ノード２０は、ＣＰＵ２０１、メモリ２０２、記憶装置２０３、通信インタフェース２０４、入力装置２０５、出力装置２０６を備える。記憶装置２０３は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。通信インタフェース２０４は、通信ネットワークに接続するためのインタフェースであり、例えばイーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのＵＳＢ（Universal Serial Bus）コネクタやＲＳ２３２Ｃコネクタなどである。入力装置２０５は、データを入力する、例えばキーボードやマウス、タッチパネル、ボタン、マイクロフォンなどである。出力装置２０６は、データを出力する、例えばディスプレイやプリンタ、スピーカなどである。なお、入力装置２０５及び出力装置２０６は省略することもできる。
【００１９】
図５は、ノード２０のソフトウェア構成例を示す図である。なお、ノード２０には、全てのブロックを記憶して検証するフルノード、ブロックのヘッダのみを管理するライトクライアント、特定のフルノードに依存し、トランザクションの検証を行わないカストディアルウォレットなどの種類がある。図５に示すノード２０の構成は、フルノードを想定する。ライトクライアントなどでは、不要な機能部又は記憶部を省略することができる。
【００２０】
ノード２０は、トランザクション受付部２１１、ロック処理部２１２、ブロック登録部２１４及び分散台帳３１を備える。なお、トランザクション受付部２１１、ロック処理部２１２、及びブロック登録部２１４は、ノード２０が備えるＣＰＵ２０１が記憶装置２０３に記憶されているプログラムをメモリ２０２に読みだして実行することにより実現することができ、分散台帳３１は、メモリ２０２及び記憶装置２０３が提供する記憶領域の一部として実現することができる。
【００２１】
トランザクション受付部２１１は、トランザクションを受け付ける。トランザクションとは、アセットの所有権の移動などの取引を示すデータである。トランザクションには、アセットの指定と、２つのアカウント（図３の例ではＡｌｉｃｅ及びＢｏｂ）の指定と、それぞれアカウントの残高（カードの所有枚数）に対して加減算が行われる値とが含まれうる。
【００２２】
ロック処理部２１２は、アセットのロックを行う。ロック処理部２１２は、操作対象となるアセットをエスクローアカウントに一時的に移転させる、いわゆるエスクロー処理により、カードのロックを実現することができる。なお、ロック処理には、上記のようなエスクロー処理に限らず、一般的な各種の手法を採用することが可能であり、ロック処理の詳細についての説明は省略する。
【００２３】
ブロック登録部２１４は、トランザクションのブロックへの取り込みを行う。ブロック登録部２１４は、トランザクションをブロックに取り込むとともに、一般的なブロックチェーンの手法を用いてコンセンサスを取り、分散台帳３１を構成するチェーンにブロックを連結する。本実施形態では、コンセンサスは、所定数のコンセンサスノードによる署名がなされたことにより成立するものとする。後述するように、本実施形態では、他のブロックチェーンにおけるトランザクションが正しく分散台帳に登録されたことを条件として、自身のブロックチェーンにおけるトランザクションの実行結果を分散台帳３１に反映させるようにすることができる。例えば、ブロックチェーンＡを構成するノード２０のブロック登録部２１４は、ブロックチェーンＢにおいてＢｏｂからＡｌｉｃｅにカードが移転したトランザクションが登録されたことを条件として、ブロックチェーンＡにおいてＡｌｉｃｅからＢｏｂにカードを移転させることができる。他のブロックチェーンにおいてトランザクションが登録されたことは、例えば、ブロックチェーンＢから取得したブロックを与え、このブロックに対象のトランザクションが含まれており、ブロックに対する署名が存在し、当該署名の検証に成功するとともに、検証に成功した署名の数が所定数以上あるか否かにより確認することができる。
【００２４】
分散台帳３１は、ブロックチェーンで管理される分散台帳であり、ブロックを記録する。なお、分散台帳３１の構成は、一般的なブロックチェーンにおける台帳の構成を採用するものとする。
【００２５】
＜ユーザ端末１３＞
図６は、ユーザ端末１３のソフトウェア構成例を示す図である。なお、ユーザ端末１３のハードウェア構成は、図４に示すノード２０の構成と同様のものとすることができるので、ここでは説明を省略する。ユーザ端末１３は、トランザクション送信部１３１を備える。トランザクション送信部１３１は、ユーザ端末１３が備えるＣＰＵが記憶装置に記憶されているプログラムをメモリに読み出して実行することにより実現される。
【００２６】
トランザクション送信部１３１は、トランザクションを送信する。本実施形態では、ユーザからの操作に応じて、ブロックチェーンＡ又はＢに対して、そのブロックチェーンが管理しているカードの所有者を移転させるトランザクションや、ブロックチェーンで管理されているカードのロックを指示するトランザクションを送信することができる。
【００２７】
＜動作＞
以下、本実施形態の取引管理システムの動作を説明する。以下は、図３の例に示すＡｌｉｃｅとＢｏｂとの間のカードの交換が行われる場合の動作を説明したものである。
【００２８】
＜正常系＞
図７は、クロスチェーンでのカードの操作が正常に終了した場合の動作を説明する図である。
【００２９】
正常時には、Ａｌｉｃｅのドラゴンのカードを１枚ロックするトランザクションがＡｌｉｃｅのユーザ端末１３からブロックチェーンＡのノード２０に送信される（Ｓ３０１）。ノード２０は、移転が可能であること（Ａｌｉｃｅの所有枚数が足りていることや、取引制限がかかっていないことなど）を確認したうえで、ブロックチェーンＡにおいて操作の対象となるＡｌｉｃｅのドラゴンのカード１枚ををロックする（Ｓ３０２）。ノード２０は、Ａｌｉｃｅのアカウントをロックしてもよいし、Ａｌｉｃｅの所有しているドラゴンのカード１枚分を移転できないように取り出すエスクロー管理を行うようにしてもよい。
【００３０】
Ｂｏｂのユーザ端末１３が、ブロックチェーンＡでのＡｌｉｃｅのドラゴンのカードのロック成功を確認すると（Ｓ３０３）、騎士のカードをＢｏｂからＡｌｉｃｅに２枚移転するトランザクションをブロックチェーンＢに送信する（Ｓ３０４）。
【００３１】
ブロックチェーンＢにおいてノード２０は、受信したトランザクションをブロックに追加し、トランザクションを取り込んだブロック（以下、取引ブロックという。）についてのコンセンサスを取り、コンセンサスに成功した場合に、取引ブロックをブロックチェーンに追加し、分散台帳３１を更新する（Ｓ３０５）。なお、本実施形態では、ブロックチェーンＡ及びＢでは、カードの所有枚数管理は、アカウント型、すなわち、Ｂｏｂ及びＡｌｉｃｅのカードに対する所有枚数がアカウントに管理されているものとする。また、本実施形態では、取引ブロックを追加するコンセンサスは、所定数以上のノード２０により署名がなされたか否かにより成否が判断されるものとする。
【００３２】
Ｂｏｂのユーザ端末１３は、ブロックチェーンＢにおける対象ブロックの取り込み成功を確認すると（Ｓ３０６）、Ａｌｉｃｅのドラゴンのカード１枚のロックを解除し、ＡｌｉｃｅからＢｏｂに移転するトランザクションをブロックチェーンＡのノード２０に送信する（Ｓ３０７）。トランザクションを受信したノード２０は、トランザクションをブロックに組み込み、トランザクションが取り込まれた取引ブロックのコンセンサスを取ってブロックチェーンに登録する（Ｓ３０８）。ここでノード２０は、ブロックチェーンＢにおけるＢｏｂからＡｌｉｃｅへの「騎士」のカードの移転が成功したことを条件として、「ドラゴン」のカードの所有枚数を変動させるようにすることができる。Ｂｏｂのユーザ端末１３は、ＢｏｂからＡｌｉｃｅへの騎士のカードのトランザクションが登録された取引ブロックを取得して、ブロックチェーンＡのノード２０にトランザクションに付帯させて渡すことができる。ノード２０は、渡された取引ブロックに、ＢｏｂからＡｌｉｃｅへの騎士のカードの移転トランザクションが含まれていること、また、当該取引ブロックに所定数以上の署名が付されていること（すなわち、トランザクションが成功したこと）を検証し、当該検証に成功した場合に、ＡｌｉｃｅからＢｏｂへのドラゴンのカードの移転トランザクションに係る所有枚数を変動させることができる。
【００３３】
＜ロックの失敗（Ａ）＞
図８は、クロスチェーンでのカードの移転がブロックチェーンＡで失敗した場合の動作を説明する図である。
【００３４】
Ａｌｉｃｅのユーザ端末１３からＡｌｉｃｅのドラゴンのカードを１枚ロックするためのトランザクションがブロックチェーンＡのノード２０に送信され（Ｓ３２１）、ノード２０において当該トランザクションに係るカードのロックに失敗した場合（例えば、Ａｌｉｃｅの所有枚数不足している場合など）には（Ｓ３２２）、Ｂｏｂのユーザ端末１３は、ロックが失敗したことを検知し（Ｓ３２３）、以降の処理を行わないようにする。ここでＡｌｉｃｅのユーザ端末１３も、ロックが失敗したことを検知して処理を中止するようにしてもよい。
【００３５】
＜移転の失敗（Ｂ）＞
図９は、クロスチェーンでの騎士のカードの移転操作がブロックチェーンＢで失敗した場合の動作を説明する図である。
【００３６】
Ａｌｉｃｅのユーザ端末１３からＡｌｉｃｅのドラゴンのカードを１枚ロックするように指示するトランザクションがブロックチェーンＡのノード２０に送信される（Ｓ３４１）。ブロックチェーンＡのノード２０はＡｌｉｃｅのドラゴンのカードを１枚ロックする（Ｓ３４２）。
【００３７】
Ｂｏｂのユーザ端末１３は、ブロックチェーンＡにおけるドラゴンのカードのロックが成功したことを確認すると（Ｓ３４３）、ＢｏｂからＡｌｉｃｅに騎士のカードを２枚移転するトランザクションをブロックチェーンＢに送信する（Ｓ３４４）。ブロックチェーンＢのノード２０は、トランザクションに応じて騎士のカードの移転を試行するも、例えば所有枚数不足（Ｂｏｂのアカウントの所有枚数が２枚未満）などにより取引が失敗することがある（Ｓ３４５）。ここで、ブロックチェーンＢが、所有枚数不足により取引に失敗した記録を残さない実装である場合には、Ａｌｉｃｅのユーザ端末１３は、騎士のカードの移転失敗を検知し、取引中止を示すトランザクションを作成してブロックチェーンＢの台帳に登録するようにしてもよい。
【００３８】
Ａｌｉｃｅのユーザ端末１３は、ブロックチェーンＢにおける騎士のカードの移転トランザクションが失敗したことを検知すると（Ｓ３４６）、Ａｌｉｃｅの１枚のドラゴンのカードのロックを解除する旨の操作命令をブロックチェーンＡに送信し（Ｓ３４７）、ブロックチェーンＡのノード２０は、Ａｌｉｃｅの１枚のドラゴンのカードのロックを解除する（Ｓ３４８）。この際、Ａｌｉｃｅのユーザ端末１３は、ブロックチェーンＢにおける騎士のカードの移転トランザクションを含むブロック、または、所有枚数不足によりトランザクションが無効化した記録を含むブロックを取得して、ノード２０に渡すことができる。ノード２０は、取引が失敗した又は取引が中止された記録を含むブロックに所定数以上の署名が付されていることを検証し、検証に成功した場合に、ロックの解除を行うようにすることができる。このようにして、Ｂｏｂの騎士のカードが移転に失敗した場合には、ドラゴンのカードはＡｌｉｃｅに返却される。なお、Ｂｏｂのユーザ端末１３が、ドラゴンのカードに関するトランザクションをブロックチェーンＡのノード２０に送信したとしても、ブロックチェーンＢにおける騎士のカードのトランザクション移転トランザクションが失敗していることから、ブロックチェーンＡでのトランザクションの成功を検証することができず、ドラゴンのカードに関するトランザクションも失敗することになる。
【００３９】
＜取引の中止＞
図１０は、クロスチェーンでのカードの操作中に取引の中止が指示された場合の動作を説明する図である。
【００４０】
Ａｌｉｃｅのユーザ端末１３からＡｌｉｃｅのドラゴンのカードを１枚ロックするトランザクションがブロックチェーンＡのノード２０に送信され（Ｓ３６１）、トランザクションを受信したノード２０はＡｌｉｃｅのドラゴンのカードを１枚ロックする（Ｓ３６２）。
【００４１】
Ｂｏｂのユーザ端末１３は、ブロックチェーンＡにおけるドラゴンのカードのロックトランザクションが成功したことを確認した後（Ｓ３６３）、騎士のカードをＢｏｂからＡｌｉｃｅに２枚移転するトランザクションをブロックチェーンＢに送信する（Ｓ３６４）。ここでＡｌｉｃｅのユーザ端末１３が、取引中止命令をブロックチェーンＢに送信した場合（Ｓ３６５）、ブロックチェーンＢにおいて取引中止が可能であったとき（例えば、まだ騎士のカードの移転に係るトランザクションがブロックに取り込まれていないとき）には、例えば取引中止のトランザクションを発行することにより取引を中止することができる（Ｓ３６６）。取引中止のトランザクションが、アセットの移転に係る正常系のトランザクションよりも先にブロックに取り込まれることにより、正常系のトランザクションが後から処理されても無効になるようにすることができる。
【００４２】
Ａｌｉｃｅのユーザ端末１３は、ブロックチェーンＢにおける取引中止の成功を確認し（Ｓ３６７）、ロックしていた１枚のＡｌｉｃｅのドラゴンのカードのロックを解除するトランザクションをブロックチェーンＡに送信する（Ｓ３６８）。ブロックチェーンＡのノード２０は、Ａｌｉｃｅの１枚のドラゴンのカードのロックを解除する（Ｓ３６９）。なお、ロック解除のトランザクションについても、ブロックチェーンＡにおける取引中止のトランザクションの検証（移転トランザクションと同様に、ブロックチェーンＡから取得したブロックに取引中止のトランザクションが含まれ、検証された署名が所定数以上付されているか否かにより行うことができる。）を行い、取引中止の検証に成功したことを条件として、ロック解除を行うようにすることができる。
【００４３】
＜取引の中止の失敗＞
図１１は、クロスチェーンでのアセットの操作中に中止が指示されたが中止できなかった場合の動作を説明する図である。
【００４４】
Ａｌｉｃｅのユーザ端末１３からＡｌｉｃｅのドラゴンのカードを１枚ロックするトランザクションがブロックチェーンＡのノード２０に送信され（Ｓ３８１）、トランザクションを受信したノード２０はＡｌｉｃｅのドラゴンのカードを１枚をロックする（Ｓ３８２）。
【００４５】
Ｂｏｂのユーザ端末１３は、ブロックチェーンＡにおけるドラゴンのカードのロックが成功したことを確認した後（Ｓ３８３）、騎士のカードをＢｏｂからＡｌｉｃｅに２枚移転するトランザクションをブロックチェーンＢに送信する（Ｓ３８４）。そして、ブロックチェーンＢのノード２０は、当該トランザクションをブロックに取り込んで、Ｂｏｂの騎士のカードが２枚Ａｌｉｃｅに移転する（Ｓ３８５）。移転後に、Ａｌｉｃｅのユーザ端末１３から取引中止命令がブロックチェーンＢに送信された場合（Ｓ３８６）、ブロックチェーンＢのノード２０は、取引中止のトランザクションを取り込むことができない。このようにブロックチェーンＢにおいて取引中止のトランザクションが失敗した場合には（Ｓ３８７）、Ａｌｉｃｅはドラゴンのカードは取り返すことができない。
【００４６】
一方、Ｂｏｂのユーザ端末１３は、騎士のカードの移転トランザクションが成功したことを確認した後（Ｓ３８８）、当初の予定どおり、ＡｌｉｃｅからＢｏｂにドラゴンのカードを１枚移転するトランザクションをブロックチェーンＡに送信する（Ｓ３８９）。上述したように、ここでＢｏｂのユーザ端末１３からは、ブロックチェーンＢにおいてＢｏｂからＡｌｉｃｅへの騎士のカードの移転トランザクションが含まれる取引ブロックがブロックチェーンＡのノード２０に提供され、このブロックチェーンＢでの取引ブロックについては上述した検証が成功するため、ブロックチェーンＡのノード２０は、１枚のＡｌｉｃｅのドラゴンのカードのロックを解除してＡｌｉｃｅからＢｏｂにドラゴンのカードを１枚移転するトランザクションを登録して移転操作を行うことができる（Ｓ３９０）。これにより、騎士カードの移転に係る取引中止が要求された場合でも、取引中止に失敗したときには、対応するドラゴンの移転が予定どおり行われ、取引全体をアトミックに行うことができる。
【００４７】
以上のようにして、本実施形態の取引管理システムでは、複数のブロックチェーンＡ及びＢに亘る一連のアセットの操作をアトミックに行うことができる。また、本実施形態の取引管理システムによれば、アトミック性を保ちながら途中で取引を中止することもできる。また、本実施形態の取引管理システムによれば、ブロックチェーンＡ又はＢにそれぞれに閉じていたカードの取引を、ブロックチェーンＡ及びＢの両方で行うことができるので、カードの流動性を向上させることができる。また、本実施形態の取引管理システムによれば、必要なカードをロックしながら、他のカードは取引可能とすることができるので、カードの流動性を損なわずにアトミックな取引を実現することができる。また、本実施形態の取引管理システムによれば、ブロックチェーンＢでは騎士のカードのロックを行う必要がないので、カードの流動性を損なわずにアトミックな取引を実現することができる。
【００４８】
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。
【００４９】
例えば、本実施形態では、ユーザ端末１３からブロックチェーンＡ及びＢに直接トランザクションが送信されていたが、ユーザ端末１３とブロックチェーンＡ及びＢとの間に、信頼できる第三者（trusted third party）が運用するサーバ装置を配置し、このサーバ装置がトランザクションの送信先を決定するようにしてもよい。この場合、ブロックチェーンＡ及びＢにおいてトランザクションが成功したかどうか（残高不足等で失敗したり、取引中止命令によりトランザクションが登録されなかったしなかったかどうか）を、サーバ装置が検知して、ユーザ装置１３に通知することができる。
【００５０】
また、トランザクション自体は、ユーザ端末１３からブロックチェーンＡ及びＢに送信しつつ、各ブロックチェーンＡ及びＢにおけるトランザクションの成否は、上記信頼できる第三者のサーバ装置が確認して、ユーザ端末１３に伝達するようにしてもよい。この場合、サーバ装置がブロックチェーンＡ及びＢの分散台帳を構成しているブロックにアクセスし、ブロックに対象取引に係るトランザクションが含まれ、当該ブロックに署名が付されており、当該署名の検証に成功し、かつ、検証に成功した署名が所定数以上存在するか否かにより、対象取引に係るトランザクションの成否を確認することができる。そして、サーバ装置が、対象取引のトランザクション又は当該トランザクションを含むブロックに署名し、署名したトランザクション又はブロックをユーザ装置１３に送信する。例えば、Ｂｏｂのユーザ装置１３は、このサーバ装置により署名されたブロックを付帯させてトランザクションをブロックチェーンＡに送信することにより、ブロックチェーンＡのノード２０は、この署名を検証し、検証に成功したことを条件として、Ｂｏｂからの指示に応じて、ＡｌｉｃｅからＢｏｂへのドラゴンのカードの移転トランザクションを登録することができる。
【００５１】
また、本実施形態では、他のブロックチェーンにおいてトランザクションが登録されたことは、一例として、対象のトランザクションが含まれるブロックについて、署名が所定数以上存在するか否かに応じて検証するものとしたが、これに限らず、例えば、対象のトランザクションが含まれるブロックが繋がっているチェーンの長さに応じて検証することもできる。例えば、チェーンの長さが所定数以上であることを確認することができる。この場合、例えば、ユーザ端末１３は、ブロックのヘッダのみを連続させたチェーンを取得してノード２０に与え、ノードがこのチェーンの連続性を検証してチェーンの長さを確認することができる。また、信頼できる第三者であるサーバ装置を用いる場合には、サーバ装置がブロックチェーンＡ又はＢにおけるチェーンの長さを確認することができる。この場合に、サーバ装置は、このチェーンの長さが、ブロックチェーンＡ又はＢにおいて最長であることにより、ブロックの正当性を検証するようにすることもできる、
【００５２】
また、本実施形態では、カードの所有枚数管理は、アカウント型、すなわち、Ｂｏｂ及びＡｌｉｃｅの所有枚数がアカウントに管理されているものとしたが、これに限らず、ＵＴＸＯ（Unspent Transaction Output）型で管理されるようにしてもよい。ＵＴＸＯ型の場合、ＢｏｂからＡｌｉｃｅにカードが移転したトランザクションが分散台帳に管理され、トランザクションの履歴を合計することでアカウントの所有枚数が算出される。
【００５３】
アカウント型の場合、ブロックチェーンＡにおけるエスクロー機能、ならびに、ブロックチェーンＢにおける取引（カードの移転）及び取引中止の機能を、スマートコントラクトとしてデプロイすることで、グローバルに機能させ、どのようなユーザ間の処理であっても使えるようにすることができる。これに対して、ＵＴＸＯ型の場合、グローバルな機能としてデプロイすることが難しい。
【００５４】
そこで、ＵＴＸＯ型の場合には、消費条件及びダミーＵＴＸＯを用いることにより追加機能を実装することができる。
【００５５】
具体的には、ブロックチェーンＡがＵＴＸＯ型である場合に、消費条件を実装する。すなわち、ブロックチェーンＡは消費条件を実装可能なブロックチェーンである必要がある。消費条件を設定することにより、エスクロー機能を実装することができる。
【００５６】
また、ブロックチェーンＢがＵＴＸＯ型である場合には、ダミーＵＴＸＯを用いることにより取引の実行又は中止を確定させることができる。この場合、Ａｌｉｃｅのユーザ端末１３が、ブロックチェーンＡにおけるＡｌｉｃｅの「ドラゴン」のカードのロックを行うことに先立って、Ｂｏｂのユーザ端末１３は、ブロックチェーンＢに対し、例えば、Ｂｉｔｃｏｉｎでは、非常に小さな額の送金を行うダミーＵＴＸＯを作成することができる。Ａｌｉｃｅのユーザ端末１３は、ダミーＵＴＸＯが登録され次第、ブロックチェーンＡに対して「ドラゴン」のカードのロックを命令することができる。次に、Ｂｏｂのユーザ端末１３は、ドラゴンのロックを確認した後に、ブロックチェーンＢにおいて、上記ダミーＵＴＸＯをインプットとしたトランザクションにより、「騎士」のカードをＢｏｂからＡｌｉｃｅに移転するように命令する。このようなトランザクションのチェーンにより、ＢｏｂからＡｌｉｃｅへの「騎士」のカードの移転が成功する。当該トランザクションの完了後、Ｂｏｂのユーザ端末１３から、ブロックチェーンＡにおいて「ドラゴン」のカードをＡｌｉｃｅからＢｏｂに移転するトランザクションが作成されて、アトミックな取引が完了する。
【００５７】
一方で、ＢｏｂからＡｌｉｃｅへの「騎士」のカードの移転の前に、Ａｌｉｃｅが取引中止を指示した場合には、Ａｌｉｃｅのユーザ端末１３は、ブロックチェーンＢにおいて、ダミーＵＴＸＯをインプットとする他のトランザクションを生成することにより、上記ダミーＵＴＸＯをインプットとして、ＢｏｂからＡｌｉｃｅに「騎士」のカードを移転するトランザクションが作成されても、この移転トランザクションを無効化することができる。その後、Ａｌｉｃｅのユーザ端末１３は、ブロックチェーンＡにおいて「ドラゴン」のカードをＡｌｉｃｅに戻すトランザクション（例えば、エスクローアカウントからＡｌｉｃｅのアカウントへの移転）を生成して、取引を全体として中止させることができる。この際、ブロックチェーンＡのノード２０では、ブロックチェーンＢにおいてダミーＵＴＸＯをインプットとする他のトランザクションについての検証を、例えば、当該他のトランザクションが含まれるブロックに、検証された署名が所定数以上の付されているか否かにより行うことができ、この検証に成功したことを条件として、ドラゴンのカードをＡｌｉｃｅに戻す取引を行うようにすることができる。
【００５８】
また、本実施形態では、ブロックチェーンを構成する全てのノード２０が分散台帳３１を備えるものとしたが、分散台帳３１を備えないノード２０もブロックチェーンＡを構成するノード２０に含めるようにしてもよい。分散台帳３１を備えないノード２０には、例えば、カストディアルウォレットがある。合意形成（コンセンサス）処理にのみ参加する、いわゆるマイナーノードも、分散台帳３１を備えずに、合意形成処理を行う機能のみを備えるようにしてもよい。
【符号の説明】
【００５９】
Ａ      ブロックチェーン
Ｂ      ブロックチェーン
１３    ユーザ端末
２０    ノード
３１    分散台帳
１３１  トランザクション送信部
２１１  トランザクション受付部
２１２  ロック処理部
２１４  ブロック登録部
【要約】
【課題】複数台帳間での状態遷移についてのアトミック性を担保することができるようにする。
【解決手段】情報処理方法であって、第１のアセットを管理する第１の台帳データベースに対して第１のアセットに対する第１の操作を行うとともに、第２のアセットを管理する第２の台帳データベースに対して第２のアセットに対する第２の操作を行う場合に、第１の台帳データベースにおいて第１のアセットをロックし、第２の台帳データベースに対して第２の操作を行うトランザクションを送信し、トランザクションが成功した場合に、第１のアセットのロックを解除し、第１の操作を行うこと、を特徴とする。
【選択図】図１【図１】
0006767022.tif 000002
【図２】
0006767022.tif 000003
【図３】
0006767022.tif 000004
【図４】
0006767022.tif 000005
【図５】
0006767022.tif 000006
【図６】
0006767022.tif 000007
【図７】
0006767022.tif 000008
【図８】
0006767022.tif 000009
【図９】
0006767022.tif 000010
【図１０】
0006767022.tif 000011
【図１１】
0006767022.tif 000012