(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-04-19
(54)【発明の名称】シリアル化トークンを分割するための装置および方法
(51)【国際特許分類】
G06Q 20/38 20120101AFI20240412BHJP
【ＦＩ】
G06Q20/38 310
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023566424
(86)(22)【出願日】2022-04-26
(85)【翻訳文提出日】2023-12-11
(86)【国際出願番号】 EP2022060985
(87)【国際公開番号】W WO2022229145
(87)【国際公開日】2022-11-03
(31)【優先権主張番号】2106207.0
(32)【優先日】2021-04-30
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】コグラン，スティーヴン，パトリック
(72)【発明者】
【氏名】ジャーン，ウエイ
(72)【発明者】
【氏名】タータン，クローイー
(57)【要約】
シリアル化トークンを分割するために方法および装置。本方法は、選択されたデノミネーショントークンを第２コンピューティングデバイスに移転する命令を受信することによってトリガされ得る。本方法は、選択されたデノミネーションよりも大きい第１デノミネーションを有している第１トークンを識別すること、を含み得る。第１トークンは、第１デノミネーションコード、一意のルート識別子、および、ルートデノミネーションツリーにおいて前記一意のルート識別子から前記第１デノミネーションへの分割の経路を一意に識別するリーフ識別子、から形成された、第１シリアル番号を有する。次に、選択されたデノミネーションの第２デノミネーションコード、一意のルート識別子、および、拡張リーフ識別子を連結することによって第２トークンについて第２シリアル番号を生成することにより、第１トークンを分割すること、を含み得る。ここで、拡張リーフ識別子は、ルートデノミネーションツリーにおける第１デノミネーションから選択されたデノミネーションへのさらなる分割経路を一意に識別する。
【特許請求の範囲】
【請求項1】
シリアル化トークンを分割するためのコンピュータで実装される方法であって、各トークンは、定義されたデノミネーションの順序付きセットの中から選択されたデノミネーションであり、
前記デノミネーションの順序付きセットにおける第１デノミネーションがルートデノミネーションであり、かつ、前記順序付きセットにおける後続のデノミネーションそれぞれは、前記順序付きのセットにおける前のデノミネーションよりも小さく、本方法は、
第１コンピューティングデバイスにおいて、選択されたデノミネーショントークンを第２コンピューティングデバイスに移転する命令を受信するステップと、
前記選択されたデノミネーションよりも大きい第１デノミネーションを有する前記第１コンピューティングデバイスに関連付けられた第１トークンを識別するステップであり、
前記第１トークンは、前記第１デノミネーションに対応する第１デノミネーションコードと、一意のルート識別子と、ルートデノミネーションツリーにおいて前記一意のルート識別子から前記第１デノミネーションへの分割の経路を一意に識別するリーフ識別子との連結から形成された、第１シリアル番号を有している、
ステップと、
前記選択されたデノミネーションに対応する第２デノミネーションコードと、前記一意のルート識別子と、拡張リーフ識別子とを連結することによって、第２トークンについて第２シリアル番号を生成することにより、前記第１トークンを分割するステップであり、
前記拡張リーフ識別子は、前記ルートデノミネーションツリーにおける前記第１デノミネーションから前記選択されたデノミネーションへのさらなる分割経路を一意に識別する、
ステップと、
トランザクションにおいて、前記第２トークンを前記第２コンピューティングデバイスに移転するステップと、
を含む、方法。
【請求項2】
前記分割するステップは、前記第１デノミネーションよりも小さいデノミネーションを有している、前記第２トークンを含む、１つ以上の子トークンを生成することを含み、前記１つ以上の子トークンの前記デノミネーション、および、前記選択されたデノミネーションは、合計して前記第１デノミネーションになる、
請求項１に記載の方法。
【請求項3】
前記１つ以上の子トークンそれぞれは、前記一意のルート識別子と、それぞれのデノミネーションコードと、それぞれの拡張リーフ識別子とを連結することによって形成された、それぞれのシリアル番号を有し、前記拡張リーフ識別子それぞれは、前記ルートデノミネーションツリーにおける、前記第１デノミネーションから前記子トークンのそれぞれのデノミネーションへの分割に係る子経路を識別する、
請求項２に記載の方法。
【請求項4】
前記分割するステップは、前記ルートデノミネーションツリーの孫レベルにおいて剰余トークンを生成することを含み、前記剰余トークンは、前記一意のルート識別子と、孫デノミネーションコードと、前記それぞれの拡張リーフ識別子よりも長く、かつ、前記孫レベルで前記ルートデノミネーションツリーにおける剰余ノードに割り当てられた、孫リーフ識別子とを連結することによって形成された、剰余シリアル番号を有する、
請求項３に記載の方法。
【請求項5】
前記方法は、さらに、前記第１トークンの分割に関して、発行者コンピューティングデバイスに通知を送信するステップ、
を含む、請求項４に記載の方法。
【請求項6】
前記通知は、前記第２シリアル番号を指定する、請求項５に記載の方法。
【請求項7】
前記分割するステップは、前記発行者コンピューティングデバイスからの事前認可なしに行われる、請求項６に記載の方法。
【請求項8】
前記第２トークンを前記第２コンピューティングデバイスに移転するステップは、前記第２コンピューティングデバイスに関連付けられた公開鍵に対して支払い可能なブロックチェーントランザクション内に、前記第２トークンを含めること、
を含む、請求項７に記載の方法。
【請求項9】
前記ブロックチェーントランザクションは、前記第２トークンが発行され、かつ、アクティブであることを、発行者コンピューティングデバイスが検証するという条件を含む、
請求項８に記載の方法。
【請求項10】
前記識別するステップは、前記第１コンピューティングデバイスが、前記選択されたデノミネーションを用いたトークンを有していないことを、最初に決定すること、
を含む、請求項９に記載の方法。
【請求項11】
最初に決定することは、さらに、追加されると、合計して前記選択されたデノミネーションになる、前記選択されたデノミネーションよりも小さいデノミネーションを有している２つ以上のトークンを、前記第１コンピューティングデバイスが、有していないと決定すること、
を含む、請求項１０に記載の方法。
【請求項12】
前記第１シリアル番号および前記第２シリアル番号は、通貨コードを含む、請求項１１に記載の方法。
【請求項13】
前記第１トークンを分割するステップは、前記第１トークンを非アクティブ化する、
請求項１２に記載の方法。
【請求項14】
コンピューティングデバイスであって、１つ以上のプロセッサと、
メモリと、
前記メモリに保管されたコンピュータ実行可能命令であり、
前記１つ以上のプロセッサによって実行されると、請求項１乃至１３いずれか一項に記載の方法を前記プロセッサに実行させる、
コンピュータ実行可能命令と、
を含む、コンピューティングデバイス。
【請求項15】
プロセッサ実行可能命令を保管しているコンピュータ可読記憶媒体であって、前記プロセッサ実行可能命令は、１つ以上のプロセッサによって実行されると、請求項１乃至１３いずれか一項に記載の方法を、前記プロセッサに実行させる、
コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、トークンネットワークに関する。そして、特には、トークンをシリアル化する（serializing）、シリアル化されたトークン（serialized tokens）を追跡する、シリアル化されたトークンを移転する、または、シリアル化されたトークンを結合するための方法およびシステムに関する。
【背景技術】
【0002】
トークンシステムは、コンピュータネットワーキングの世界において、ますます関心を集めている。芸術作品、会社の株、または「ツイート（“tweet”）」といった、多くの現実世界のオブジェクトが「トークン化（“tokenized”）」されている。場合によっては、トークン化されるものは、単一の芸術作品または他のオブジェクトのような、代替不可能なもの（good）であり、そして、そのアイテムに関連付けられたトークンは、その代替不可能なアイテムの「所有権（“ownership”）」を表すことができる。このことは、非代替トークン(non-fungible token、NFT)の最近の人気をもたらしてきた。トークンは、トークンネットワーク上で、発行され、移転され、または、保管され得る。トークンネットワークは、根底をなす（underlying）コンピューティングネットワーク上に確立されてよく、このことは、トークン所有権の分散台帳（distributed ledger）を維持するためのブロックチェーン層を含んでよく、または、含まなくてもよい。
【0003】
代替可能なトークンは、いくつかのトークンシステムにおいて生成され得る。例えば、代替可能な商品、または紙幣、または他の非一意的なアイテムの量を表すトークンである。代替トークンシステムにおいて個々のトークンを追跡（tracking）することは、ストレージ空間の点でコストがかかる可能性がある。例えば、オーストラリア、英国、または米国といった、かなり大きな国で活発に流通している紙幣（banknote）の数を考慮すると、各紙幣に対して一意のシリアル番号を有する一意のトークンを発行することは、結果として、非常に大きなトークンデータベースのストレージ要件をもたらす。
【0004】
少なくとも部分的に保管スペースの問題に対処する、代替可能なシリアル化トークンを発行、保管、移転、分割、および結合するための方法およびシステムを有することは有利だろう。
【図面の簡単な説明】
【0005】
これから、例として、本出願の例示的な実施形態を示す、添付の図面を参照する。
【0006】
図面において使用されている類似の参照番号は、類似の要素および特徴を示している。
【発明を実施するための形態】
【0007】
一つの態様においては、シリアル化トークンを分割するためのコンピュータで実装される方法が提供され得る。ここで、各トークンは、定義されたデノミネーションの順序付きセットの中から選択されたデノミネーションであり、ここで、前記デノミネーションの順序付きセットにおける第１デノミネーションがルートデノミネーションであり、かつ、前記順序付きセットにおける後続のデノミネーションそれぞれは、前記順序付きのセットにおける前のデノミネーションよりも小さい。本方法は、第１コンピューティングデバイスにおいて、選択されたデノミネーショントークンを第２コンピューティングデバイスに移転する命令を受信するステップと、前記選択されたデノミネーションよりも大きい第１デノミネーションを有する前記第１コンピューティングデバイスに関連付けられた第１トークンを識別するステップであり、前記第１トークンは、前記第１デノミネーションに対応する第１デノミネーションコードと、一意のルート識別子と、ルートデノミネーションツリーにおいて前記一意のルート識別子から前記第１デノミネーションへの分割の経路を一意に識別するリーフ識別子との連結から形成された、第１シリアル番号を有しているステップと、前記選択されたデノミネーションに対応する第２デノミネーションコードと、前記一意のルート識別子と、拡張リーフ識別子とを連結することによって、第２トークンについて第２シリアル番号を生成することにより、前記第１トークンを分割するステップであり、前記拡張リーフ識別子は、前記ルートデノミネーションツリーにおける前記第１デノミネーションから前記選択されたデノミネーションへのさらなる分割経路を一意に識別するステップと、トランザクションにおいて、前記第２トークンを前記第２コンピューティングデバイスに移転するステップと、を含み得る。
【0008】
いくつかの実装において、分割するステップは、前記第１デノミネーションよりも小さいデノミネーションを有している、前記第２トークンを含む、１つ以上の子トークンを生成することを含み、ここで、前記１つ以上の子トークンの前記デノミネーション、および、前記選択されたデノミネーションは、合計して前記第１デノミネーションになる。いくつかの事例において、前記１つ以上の子トークンそれぞれは、前記一意のルート識別子と、それぞれのデノミネーションコードと、それぞれの拡張リーフ識別子とを連結することによって形成された、それぞれのシリアル番号を有し、そして、前記拡張リーフ識別子それぞれは、前記ルートデノミネーションツリーにおける、前記第１デノミネーションから前記子トークンのそれぞれのデノミネーションへの分割に係る子経路を識別する。
【0009】
いくつかの実装において、分割するステップは、前記ルートデノミネーションツリーの孫レベルにおいて剰余トークンを生成することを含み、そして、ここで、前記剰余トークンは、前記一意のルート識別子と、孫デノミネーションコードと、前記それぞれの拡張リーフ識別子よりも長く、かつ、前記孫レベルで前記ルートデノミネーションツリーにおける剰余ノードに割り当てられた、孫リーフ識別子と、を連結することによって形成された、剰余シリアル番号を有する。
【0010】
いくつかの実装において、本方法は、前記第１トークンの分割に関して、発行者コンピューティングデバイスに通知を送信するステップを含み得る。前記通知は、前記第２シリアル番号を指定し得る。いくつか事例において、前記分割するステップは、前記発行者コンピューティングデバイスからの事前認可なしに行われる。
【0011】
いくつかの実装において、前記第２トークンを前記第２コンピューティングデバイスに移転するステップは、前記第２コンピューティングデバイスに関連付けられた公開鍵に対して支払い可能なブロックチェーントランザクション内に、前記第２トークンを含めることを含む。いくつかの実施形態において、前記ブロックチェーントランザクションは、前記第２トークンが発行され、かつ、アクティブであることを、発行者コンピューティングデバイスが検証するという条件を含む。
【0012】
いくつかの実装において、識別するステップは、前記第１コンピューティングデバイスが、前記選択されたデノミネーションを用いたトークンを有していないことを、最初に決定することを含む。いくつかの事例において、最初に決定することは、さらに、追加されると、合計して前記選択されたデノミネーションになる、前記選択されたデノミネーションよりも小さいデノミネーションを有している２つ以上のトークンを、前記第１コンピューティングデバイスが、有していないと決定することを含む。
【0013】
いくつかの実装において、前記第１シリアル番号および前記第２シリアル番号は、通貨コードを含む。
【0014】
いくつかの実装において、前記第１トークンを分割するステップは、前記第１トークンを非アクティブ化する。
【0015】
別の態様においては、トークンネットワーク上のノードを実装するコンピューティングデバイスが提供され得る。トークンネットワークは、いくつかの実装において、分散型台帳ネットワークであり得る。前記コンピューティングデバイスは、メモリと、１つ以上のプロセッサと、実行されたときに、本明細書で説明される方法のうちの１つ以上を、プロセッサに実行させる、コンピュータ実行可能命令と、を含み得る。
【0016】
さらに別の態様においては、プロセッサ実行可能命令を保管しているコンピュータ可読媒体が提供され得る。前記プロセッサ実行可能命令は、１つ以上のプロセッサによって実行されると、本明細書で説明する方法のうちの少なくとも１つを、プロセッサに実行させる命令を含む。
【0017】
本開示の他の例示的な実施形態は、図面と併せて以下の詳細な説明を検討することから、当業者にとって明らかになるだろう。
【0018】
本出願において、用語「及び／又は（“and/or”）」は、列挙された要素に係る全ての可能な組み合わせ、および、部分的組み合わせ（sub-combinations）をカバーするように意図されており、列挙された要素に係る任意の１つのみ、任意の部分的組み合わせ、または、要素の全てを含んでおり、かつ、必ずしも追加の要素を除外することはない。
【0019】
本出願において、「…または…のうちの少なくとも１つ（“at least one of”）」という語句は、列挙された要素に係る任意の１つ以上をカバーするように意図されており、列挙された要素に係る任意の１つのみ、任意の部分的組合せ、または、要素の全てを含んでおり、かつ、必ずしも追加の要素を除外することはなく、かつ、必ずしも要素の全てを必要とすることはない。
【0020】
図1は、トークンネットワークを実装するための一つの例示的なシステム100を示している。システム100は、トークンの作成、追跡、保管、および、移転を促進することができる。トークン自体は、任意の現実世界のアイテムの代表であり得る。実施例は、財産金利（property interests）、株式、通貨、暗号通貨、ロイヤルティポイント、クレジット、または、定量化され得る任意の他のものである。
【0021】
トークンは、代替不可能または代替可能であり得る。代替不可能なトークン(non-fungible token、NFT)は、一意の現実世界のアイテムに対して固有であり得る。代替トークンは、少なくとも一部が交換可能であり得るものを表している。一つの例として、リンゴが、ブッシェル（bushel）のような、所定の数量のリンゴを表すようにトークン化される、代替トークンシステムが作成され得る。いずれのトークンも、ある量のリンゴの所有権を表しており、かつ、特定のブッシェルのリンゴの所有権を表すものではない。トークンは、デノミネーション（denominations）で構成されたものに対してマッピングされ得る。例えば、異なる量または部分量のリンゴである。別の実施例において、トークンシステムは、不換通貨（fiat currency）をトークン化し、各トークンは、通貨のデノミネーションによって定義されるように、20ドル、10ドル、5ドルのような、紙幣の所定のデノミネーションを表している。他のシステムは、オレンジ、メモリストレージ、CPU時間、等といった、あらゆる他の代替可能なものに係るデノミネーションを含み得る。
【0022】
システム100は、発行者ノード102、および、第１ユーザ104、第２ユーザ106、および第３ユーザ108を含む、複数のユーザノードを含んでおり、これらは全てコンピュータネットワーク112によって相互接続されている。コンピュータネットワークは、インターネットのような広域インターネットワークといった、パケット交換ネットワークを含み得る。各ノード102、104、106、108は、コンピュータネットワーク112を介して、他のノードに接続し、かつ、通信するように構成されたコンピューティングデバイスを含む。コンピューティングデバイスは、いくつかの例において、サーバ、パーソナルコンピュータ、ラップトップ、タブレット、スマートフォン、ウェアラブル技術、などを含み得る。
【0023】
いくつかの実施形態において、システム100は、ビットコインまたは他のプロトコルといった、ブロックチェーン技術を使用して実施され得る。いくつかの実施形態において、システム100は、トランザクションについて非ブロックチェーンのピアツーピアプロトコルを使用して実装され得る。いくつかの実施形態において、システム100は、トランザクションについて非ピアツーピアプロトコルを使用して実施されてよく、そこでは、発行者ノード102または他の中間ノードが、ユーザノード間のトランザクションを認可および促進することに関与している。
【0024】
発行者ノード102は、トークンに関するデータを保管し、かつ、維持する、データストア110に結合されている。発行者ノード102は、その管理プロトコル（governing protocol）に従ってトークンを生成し、そして、生成されたトークンのレコードをデータストア110内に維持する。各トークンは、そのシリアル番号によって一意に識別可能である。データストレージ装置110は、有効に発行された全てのトークンの記録を維持する。このようにして、ユーザノードは、発行者ノード102を介して、そのシリアル番号をクエリする（querying）ことによって、特定のトークンが有効に発行されたトークンであるか否かを判定することが可能である。この意味で、発行者ノードは、トークンシリアル番号の有効性を追跡することに従事する信頼できる第三者である。発行者ノード102は、必ずしも個々のトークンに関する所有権情報を追跡または維持する必要はないことに留意すること。すなわち、いくつかの実装において、データストアは、特定のトークンシリアル番号が発行され、かつ、アクティブであるか否かを追跡するが、それらのトークンの所有権情報は追跡しない。所有権データは、根底をなす（underlying）ブロックチェーン技術または別のトークン移転プロトコルといった、別のメカニズムを使用して追跡され得る。
【0025】
発行者ノード102は、トークンを生成し、そして、発行するように構成されている。発行されたトークンは、データベース、または、データストア110に保管された他のそうした構造化されたデータにおいて追跡される。ユーザノードのうちの１つ、第１ユーザノード104といったものは、複数のトークンの所有（possession）または所有権（ownership）をとることができ、そして、第２ユーザノード106といった、別のユーザノードに対して１つ以上のトークンを移転することができる。根底にある移転プロトコルは、ブロックチェーンベースであるか否かにかかわらず、トークンの所有及び／又は所有権を安全に移転するためのメカニズムを管理することができる。例えば、ブロックチェーンベースのプロトコルにおいて、第１ノード104から第２ノード106へのトークンの移転は、第１ノード104に関連付けられた秘密鍵によって署名され、第２ノード106に関連付けられた公開鍵に対して支払い可能であり、そして、トランザクションにおいてトークンシリアル番号を指定している、トランザクションによって実行され得る。
【0026】
トークンネットワークの課題の１つは、各トークンを一意に識別するために必要とされるデータ空間である。別の言葉で言えば、大量のトークンを用いると、全ての発行されたトークンのシリアル番号を追跡することは、結果としてデータストア110について非常に大きいメモリ要件を生じる可能性がある。比較例として説明するために、所与の通貨で流通している紙幣の数を考える。流通している概ね450億米ドルの紙幣が存在しており、それぞれを個別に表すために十分なシリアル番号空間が必要である。
【0027】
トークンネットワークは、典型的に、より大きなデノミネーションのトークンをより小さいデノミネーションのトークンへと分割する可能性を提供するので、トークンネットワークの場合には、ハード紙幣の番号付けの場合よりも複雑であると考えられ得る。この実施例において、最大デノミネーションのトークンから最小デノミネーションのトークンまでの範囲で定義されたデノミネーションの順序付けられたセット（ordered set）が存在する、トークンシステムが仮定される。いくつかの実施例において、順序付けられたセットは、各トークンが、その最も近い最小の隣接トークンの整数倍となるように構造化されてよい。例えば、1、2、4、8、16、等のデノミネーションを用いる2nパターンである。いくつかの実施例において、順序付けされたセットは、USD、GBP、AUD、CAD、等のような、1:2:5パターンの通貨の場合といった、いくつかの非整数倍を有してよく、ここで、順序付けされたセットは、1ドル、2ドル、5ドル、10ドル、20ドル、50ドル、等を含み得る。通貨の例はさて置き、トークン化されたデータストレージ空間のデノミネーションは、256バイト、1024バイト、4096バイト、65,536バイト、等の量であり得る。または、別の例として、農産物は、パイント、クォート、ガロン、ペック、および、ブッシェルによって、帝国単位（imperial measures）英国ヤードでデノミネーションされてよい。
【0028】
より小さいデノミネーションへとトークンを分割する可能性を考慮するために、トークンをシリアル化するためのビット空間は、そうした分割の可能性に適合すべきである。多くのトークンシステムにおいて、トークンのシリアル化は、最小のデノミネーションから開始するボトムアップアプローチを使用することができる。非トークン化の例として、ビットコインは、最小デノミネーションをサトシ（satoshi）として定義し、そして、トランザクションは、指定された数のサトシを移転するために実行される(しかしながら、ビットコインは、個々のサトシを、それぞれに一意のシリアル番号を割り当てることによって、ネイティブにトークン化しないことに留意すること)。AUDのような、不換通貨の場合に、最小の紙幣は、例えば、5ドルであり得る。他の全ての紙幣は、最小紙幣の整数倍である。流通している所定の不換紙幣の数(約2019)は、デノミネーションによって、以下のようにブレイクダウンされる。
【表1】
【0029】
流通しているAUDのドル価値は、800億ドルをわずかに下回る。5ドルよりも大きい各AUD紙幣（note）が5ドル紙幣の等価数として表される場合に、5ドルのルートデノミネーションを使用して表される、流通している紙幣の量は160億である。このことは、流通している実際のAUD紙幣の数の10倍である。
【0030】
最小デノミネーションに基づいてトークン化された紙幣のボリュームVをシリアル化するために必要なビット空間は、log2(V)+1である。約160億の5ドル紙幣について、約34ビットのシリアル番号が必要である。従って、AUDの各デノミネーションに対する結果としてのストレージ要件は、以下のようである。
【数1】
【0031】
GBP紙幣のシリアル化は、約34ビットのシリアル番号を必要とし、そして、USD紙幣のシリアル化は、約41ビットのシリアル番号を必要とするだろう。これらのビット空間およびストレージ要件表現を使用して、上の表で与えられた流通番号を仮定した場合の、シリアル化された（serializes）紙幣のストレージ要件を決定することができる。
【表2】
【0032】
トークンデノミネーションの順序付けられたセットのボトムアップシリアル化に関連するストレージ要件について改善するやり方でトークンをシリアル化することが可能であり得る。本出願の一つの態様に従って、シリアル化は、トップダウンアプローチを使用することができ、それによって、発行される基本トークンは最大デノミネーショントークンである。そうしたシステムにおいて、ストレージ要件は動的であり、そして、トークンの細分（subdivision）に基づいて変化することができる。シリアル番号の長さは動的であり、そして、より小さいデノミネーションについて、より大きいデノミネーショントークンから、より小さいデノミネーショントークンの分割を表すために、より長くすることができる。
【0033】
本出願において、各最大デノミネーショントークンには、一意のルート識別子が割り当てられている。デノミネーションの順序付けられたセットのうちどれをトークンに適用するかを指定するために、デノミネーションフィールドがルート識別子に追加されている。指定されたデノミネーションが非ルート（non-root）デノミネーションである場合に、トークンのシリアル番号は、１つ以上のリーフ識別子を含んでいる。各リーフは、トークンを一意に識別するために十分なビット空間を提供する。各リーフ識別子の長さは、そのレベルにおいてトークンが分割可能な「子（“children”）」の数に依存し得る。
【0034】
図2は、本出願の一つの態様に従って構築されたトークンシリアル番号について、一つの例示的なデータ構造200を示している。この例において、シリアル番号は、デノミネーションコード204および１つ以上のフラグ206を含む、プレフィックス部分202を含んでいる。フラグ206は、トークンまたはトークン方式に関するメタデータをシグナリング（signal）する。例えば、トークンが通貨のトークン化に関連する場合に、フラグ206は、そのトークンが、どの通貨に関連するか、すなわち、通貨コード、シグナリングすることができる。トークンが農産物に関連する場合に、フラグ206は、製品タイプまたはクラス、及び／又は、原産地をシグナリングすることができる。この例において、フィールドは、4ビットの長さに設定されるが、フラグ206を用いてどのデータがシグナリングされているかに応じて、他の実施形態においては、他のサイズが使用され得る。デノミネーションコード204フィールドのサイズは、順序付けられたデノミネーションのセット内のデノミネーションの数に依存する。50ドル、20ドル、10ドル、5ドル、2ドル、1ドルのデノミネーションを有する通貨の場合に、デノミネーションコード204をシグナリングするためには3ビットのフィールドで十分である。
【0035】
シリアル番号は、次いで、ルート識別子208フィールド、および、リーフ識別子210フィールドを含んでいる。ルート識別子208フィールドは、発行されたトークンを全て表すために、最大デノミネーションのトークンの全範囲をトークン化するのに十分な長さである。リーフ識別子210フィールドは、可変サイズである。ルートデノミネーションの場合に、リーフ識別子210は、存在しなくてよい。いくつかの事例において、ルートデノミネーションは、後でさらに説明されるように、場合によっては、発行者生成シリアル番号対（versus）ユーザ生成シリアル番号をシグナリングする可能性を残しておく、0にデフォルト設定される単一ビットリーフ識別子210を含み得る。
【0036】
例として紙幣の不換通貨を使用して、説明を続けるために、50枚の紙幣(ドルまたはポンド（“$ or ￡”)が最大デノミネーションとして指定されていると仮定する。この説明のためにAUD番号を使用すると、流通している様々な紙幣によって表される50ドルの紙幣の量は、以下の通りである。
【表3】
【0037】
上記の式では、8350万（83.5million）の50ドル紙幣は、1億7600万（1765million）の20ドル紙幣の量に8350万の10ドル紙幣を加えたものを表すことができる。50ドルそれぞれは、2枚の20ドル紙幣および1枚の10ドル紙幣を費やすからである。同様に、1億3400万（134million）の10ドル紙幣が流通しているが、そのうち8350万（83.5million）は20ドル紙幣に関連して計上された50ドル紙幣によって既に表されている。従って、残りの5050万（50.5million）の10ドル紙幣を表すためには、1010万（(134-83.5)/5=10.1million）の50ドル紙幣だけが必要とされる。従って、50ドルトークンで全ての紙幣を表すためには、約16億（1.6billion）のそうしたトークンが必要とされるだろう。
【0038】
16億のトークンをシリアル化するためには、約31ビットのビット空間が必要である。同様に、GBPを約31ビットとして、および、USDを約36ビットとして、シリアル化するためのトークン空間を決定することができる。
ルート識別子(root ID)に1ビットを加えたものを使用して50ドルAUDが表され、かつ、ルートIDに5ビットを加えたものを使用して5ドルAUDが表されると仮定した場合に、シリアル化されたAUDトークンは、従って、ルート識別子208について約31ビットの最小ビット空間、および、0ビットから5ビットまでの範囲の可変長リーフ識別子210を有している。
ルート識別子(root ID)に1ビットを加えたものを使用して50ドルAUDが表され、かつ、ルートIDに5ビットを加えたものを使用して5ドルAUDが表されると仮定した場合に、シリアル化されたAUDトークンは、従って、ルート識別子208について約31ビットの最小ビット空間、および、0ビットから5ビットまでの範囲の可変長リーフ識別子210を有している。
【0039】
当面、プレフィックス202を無視すると、最高デノミネーション(この例において50ドル)について31ビットのルート識別子208を仮定し、かつ、その最高デノミネーションの約16億（1.6billion）ロット(約800億（80billion）ドルの合計通貨)を仮定すると、全てのトークンを追跡するための最小ストレージ要件は、以下のようになる。
【数2】
【0040】
800億ドルの全てが5ドルトークンを使用して表されると仮定する場合に、最大ストレージ要件は、以下のようになる。
【数3】
【0041】
従って、完全なトークン空間を表すためのストレージ要件は、全ての50ドルトークンについての5.77GBの最適値から、全ての5ドルトークンについての65.2GBの最悪の場合までの範囲になり、このことは、AUDトークンについての63.32GBの固定されたストレージ要件の静的な事例に比べて有利である。
【0042】
800億ドルの全てが1ドルトークンを使用して表されると仮定する場合に、最大ストレージ要件は、また、以下のように決定することもできる。
【数4】
【0043】
紙幣のありそうな分布に対するガイダンスのために、流通しているAUD紙幣の実際の量を見る場合には、現在のAUDキャッシュ量を表すために概ね7.35GBが必要とされるだろう。従って、最小デノミネーションではなく、むしろ、最大デノミネーションで開始するトークン化システムを設計することが有利であり得る。さらに、以下で説明されるように、トークン化システムにおいては、より小さいデノミネーションをより大きいデノミネーションに統合することが、より容易であり、それによって、システム全体をより大きいデノミネーションおよびより小さいストレージ要件にバイアスしている。
【0044】
最も効率的で、かつ、直接的なシリアル化スキームは、デノミネーションを指定する際に2の累乗を使用することだろう。しかしながら、除算からの剰余を結果としてもたらす、可能なバリエーションを示すために、5-2-1シリーズのデノミネーション(例えば、1、2、5、10、20、50)に基づく一つの例が以下に提供されている。
【0045】
それぞれの子のデノミネーションについて、フラグまたはビットは、それぞれの子を一意に識別するように、親を分割することができる子の整数をエンコーディングする。2nシリーズにおいて、このことは簡単（straightforward）である。しかしながら、5-2-1シリーズにおいて、このことは、「5」が2個の「2」子トークンへと分割される剰余（remainder）を結果として生じ得る。「1」トークンも生成しなければならないからである。原則として、除算から単一の剰余トークンのみが存在し得る。従って、この剰余をシグナリングするために、次のデノミネーションの最初に利用可能なリーフIDが使用され得る。孫（grandchild）トークンが親トークンの剰余除算から生じるか否かは、従って、シリアル番号によって本質的に示される。
【0046】
実施例によって、かつ、図2に示されたデータ構造を使用して、説明すると、この実施例におけるフラグ206フィールドは、4ビットに設定され得る。例示の目的で、フラグ206は、AUDといった、フラグ206に「0001」を割り当てる、この例における不換通貨を指定するためのものであり得る。
【0047】
デノミネーションコード204は、通貨のデノミネーションをシグナリングするために使用されてもよく、この例においては、50、20、10、5、2、および1のデノミネーションを含んでいる。これらは、以下のような、3ビットフラグを使用して表され得る。
【0048】
【表4】
【0049】
この例においては簡単にするために、より現実的な30－36ビットではなく、むしろ、4ビットだけのルート識別子208を仮定している。ルート識別子208は、発行者ノードによって元々は生成された50ドルのデノミネーションを表している。
【0050】
50ドルのデノミネーションのトークンは、最大で、2個の20ドルトークン、5個の10ドルトークン、10個の5ドルトークン、20個の2ドルトークン、または、50個の1ドルトークンへと分割され得ることができることが理解されだろう。それぞれ導出された子のデノミネーションについて、それぞれの親から導出可能な最大で２つの子の間を一意に区別するために、少なくとも1ビットが必要である。いくつかの事例においては、親から派生した子と、祖父母を分割した剰余として生成された子とを区別するために、別のビットが必要である。
【0051】
実施例として説明するために、ルートIDが「0111」である50ドルのデノミネーション(デノミネーションコード000)を仮定する。元の50ドルのデノミネーショントークンの分割を通じて生成される様々なトークンのシリアル番号の可能性は、以下の通りである。
【表5】
【0052】
50ドルトークンは、0の固定リーフIDを有している。場合によって、このリーフIDは、50ドルトークンをシリアル化するときに省略され得る。しかしながら、いくつかの目的のために有用であり得る。50ドルから20ドルへの分割の場合に、リーフID00および01は、分割から結果として生じる2個の20ドルトークン間を区別するのに十分であることに留意すること。さらに、これら2個の20ドルトークンがそれぞれ10ドルトークンへと分割される場合には、10ドルトークンによって占有されるリーフID空間は0xxに制限され、50ドルが2個の20ドルトークンへと分割される場合に結果として生じる10ドル剰余トークンに対して割り当てられるように、100の次のリーフIDが利用可能であることを意味している。
【0053】
50ドルのデフォルト0リーフIDから結果として生じる追加の（extra）識別子空間が既に使用されているので、剰余リーフIDの割り当ては、より低いレベルでより複雑になる。5ドルトークンを2ドルトークンへと分割した結果として生じる1ドルの剰余トークンに対してリーフIDを割り当てるとき、最初に利用可能なリーフIDは「101000」である。従って、1ドルレベルでの剰余トークンは、101000から110001までのID空間に及ぶ。
【0054】
より小さいデノミネーションへのルートトークンの分割は、デノミネーションが2nシリーズを形成する一つの例について図3で示されるように、ルートデノミネーションツリー300によって示され得る。この単純な実施例において、各トークンは、正確に2個の子トークンへと分割され、それによって、図示のように、バイナリフラグを使用して、それぞれ一意のトークンをシグナリングすることを簡単にしている。ツリーにおける各連続レベルにおいて、リーフ識別子は、ビットを追加することによって拡張されることに留意すること。このビットは、左側の子または右側の子のいずれかをシグナリングする。
【0055】
5-2-1シリーズのデノミネーションのより複雑なシリアル化が図4に示されており、このことは、別の例示的なルートデノミネーションツリー400を示す。再び、各連続レベルにおいて、リーフ識別子は、親と比較して拡張されたリーフ識別子であることに留意すること。直接的な子ノードに関して言えば、子ノードの拡張リーフ識別子は、親に基づいているが、左側の子または右側の子をシグナリングするための追加のビットを有し得る。しかしながら、剰余ノードの拡張リーフ識別子は、必ずしも親のリーフ識別子を単純に拡張することによって得られるとは限らない。
【0056】
図3で見られるように、2nシリーズのデノミネーションのためのルートデノミネーションツリー300は、結果として対称ツリーを生じ、それぞれ親は、2個の子ノードを有しており、そして、リーフ識別子は、その対称バイナリ分割を反映している。
【0057】
図4においては、ルートデノミネーションツリー400が、剰余トークンのための別個の導出経路（derivation path）を含んでいることに留意すること。剰余トークンには、孫レベルから最初の利用可能なリーフ識別子が割り当てられる。1ドルトークンの例示的なケースにおいては、2ドルトークンを分割することから導出される1ドルトークンが0000000(0)から100111(39)までの範囲を占めるので、そのレベルにおける剰余トークンは、101000(40)で始まり、110001(49)までの範囲のリーフ識別子を有する。剰余ノードは、「1」が前に置かれたリーフ識別子を有する。また、剰余トークンの分割を通じて得られたデノミネーションは、「0」ではなく「1」が前に置かれたリーフ識別子を有することにも留意すること。
【0058】
ルートデノミネーションツリー300および400のうちの１つのブランチに沿った１つのノードだけが、任意の一時点でアクティブであり得る。例えば、リーフ識別子「001」に関連付けられた10ドルトークンがアクティブである場合、その親ノード(20ドルトークン「00」および50ドルトークン「0」)はアクティブであることができない。同様に、その子10ドルノード「0010」および「0011」は、20ドルトークンが分割されたことを示すので、アクティブであることができない。しかしながら、同じ親を共有する20ドルトークン「000」がアクティブであるか、または、その子ノードまたは孫ノードのいずれかがアクティブであり得る。
【0059】
アクティブトークンを保管するトークンデータベースは、いくつかの方法で構成することができる。一つの実施形態において、データベースは、全てのアクティブトークンの完全なシリアル番号をリストしている。別の実施形態において、データベースは、フラグおよびルートIDを保管し、そして、そのデータ構造内で、次いで、任意のアクティブなデノミネーションコード、および、各アクティブなデノミネーションコードについて、そのデノミネーションコードに対してアクティブな任意のリーフ識別子を保管すること、などによって、シリアル番号を部分的にリストする構造である。
【0060】
発行者ノードは、トークンデータベースを管理することができ、そして、トークンが分割されるか、または、統合される場合、などに、新たに発行されたシリアル番号を追加し、または、非アクティブ化されたシリアル番号を除去することができる。シリアル化トークンの分割または統合は、以下でさらに説明される。発行者ノードは、トークンデータベースを維持し、そして、更新を行う前に変更の有効性を検証することができる。ルートからリーフへの経路上の１つのノードのみが任意の一時点でアクティブであることを確認する、といったことである。発行されたノードは、さらに、検索またはクエリインターフェイスを提供し得る。それを通じて、第三者またはノードは、所定のシリアル番号がアクティブであるか否かをクエリし、もしくは、非アクティブまたは利用可能なリーフ識別子またはルートIDの識別を捜し求めることができる。
【0061】
いくつかの事例において、トークンデータベースは、トークンシリアル番号に加えてトークンデータを保管する。いくつかの事例において、トークンデータベースは、トークンシリアル番号のみを保管する。いくつかの実装において、データベースは、トークンまたはシリアル番号が「アクティブ（“active”）」であるか、または、「非アクティブ（“inactive”）」であるかを示すフィールドまたはフラグを含み得る。いくつかの実装において、データベースは、アクティブなシリアル番号またはトークンのみを保管することができ、その結果、データベース内の任意のトークンまたはシリアル番号は、データベース内にあることによって暗黙的に「アクティブ」であり、そして、トークンまたはシリアル番号の非アクティブ化は、データベースからのそのトークンまたはシリアル番号の除去を通して達成される。
【0062】
いくつか事例において、トークン発行者は、トランザクションのコンテキストにおいて、シリアル番号がアクティブトークンに対応するか否かを検証または認証する役割を果たし得る。すなわち、トークン発行者からの認証は、いくつかの実装において、トークントランザクションの実行の条件であり得る。トークンが、例えば、ブロックチェーンネットワーク上で使用される場合、トークン発行者は、いくつかの実装において、シリアル化されたトークンを含むトランザクションの検証において役割を果たし得る。発行者ノードは、場合によって、トランザクションへの署名者（signatory）であり得る。
【0063】
これから、フローチャート形式で、シリアル化トークンを生成するための一つの例示的な方法500を示す、図5を参照する。方法500は、発行者ノードによって実施され得る。発行者ノードは、１つ以上のプロセッサ、および、メモリであり、１つ以上のプロセッサによって実行されると、説明される動作をコンピューティングデバイスに実行させる、プロセッサ実行可能命令を保管するメモリ、をしている、１つ以上のコンピューティングデバイスを含み得る。
【0064】
方法500は、動作502において、指定されたデノミネーションのトークンを生成するために要求を受信することを伴うことができる。要求は、要求ノード（requesting node）に関連付けられ得る。要求は、例えば、発行者管理者デバイスから、または、管理者インターフェイスから受信されてよく、そして、発行者のインスタンスにおけるトークン生成を反映し得る。いくつか事例において、要求は、ユーザデバイスといった、外部デバイスから受信されてよく、そして、要素をトークン化する要求の一部であり得る。要素は、通貨、ある製品の量、または、他の代替可能なアイテムであり得る。
【0065】
動作504において、発行者ノードは、一意のルートIDを割り当てる。ルートIDの選択は、場合によっては、ランダムであり得る。ハッシュ関数または他のランダム化関数を使用して、発行者ノードは、ルートIDを生成し、かつ、それがデータベース内の任意の他のルートIDと衝突しないことを迅速に確認し得る。いくつかの実施形態において、ルートIDは、非ランダムであってよく、そして、生成された最後のルートIDを1だけインクリメントすることによって生成され得る。
【0066】
発行者ノードは、次いで、動作506において、そのシリアル番号を含んでいる、要求されたトークンを生成する。トークン自体は、シリアル番号に加えて、そのデータ構造内に他の特徴またはデータを有し得る。本出願のフォーカスは、シリアル番号の生成および管理に向けられており、その結果、トークンの他の詳細は、さらに詳細には説明されない。シリアル番号は、任意のプレフィックスフィールドを、もしあれば、ルートIDおよびリーフ識別子と連結することによって生成される。リーフ識別子は、最大デノミネーションの場合には、固定またはデフォルトのリーフ識別子であってよく、または、最大デノミネーションのリーフ識別子が存在しなくてよい。
【0067】
要求されたデノミネーションが最大デノミネーション以外のデノミネーションである場合に、発行者ノードは、合計すると最大デノミネーションになる、要求されたデノミネーションのトークンの量を生成することができる。これらのトークンのうちの１つだけが要求ノードに対して意図され、そして、剰余トークンは発行者ノードで保管されてよい。いくつかの事例において、トークンを保管することは、それらをトークンストレージまたはデータベースに保管すること、を含んでいる。場合によって、剰余トークンは、トークンデータベース内で非アクティブまたは未発行（unissued）としてマーク付けされる。要求ノードに対して意図されたトークンは、トークンデータベースに保管され、そして、アクティブとしてマーク付けされる(508)。場合によっては、トークンをアクティブにマーク付けすることは、データベースにおける、そのトークンのシリアル番号の保管に、暗黙的に含まれている。
【0068】
要求ノードのために生成されたトークンは、要求に応答して、動作510において、要求ノードに送信される。
【0069】
これから、図6を参照すると、一つの例示的なトークンシステム600が概略的に示されている。例示的なシステムは、トークンネットワーク604を介して第１ノード608と通信する発行者ノード602を含んでいる。トークンネットワーク604は、有線、または無線、または両方のいずれかで、１つ以上のコンピューティングネットワークであってよく、そして、インターネットといった、プライベートおよびパブリックコンピューティングネットワークを含み得る。トークンネットワーク604は、パケットベースのネットワーク上で動作するトークンシステム通信プロトコルとして実装され得る。第１ノード608は、パーソナルコンピュータ、ラップトップ、スマートフォン、タブレット、または他のモバイルコンピューティングデバイスといった、ネットワーク対応コンピューティングデバイスによって実装され得る。コンピューティングデバイスは、トークンデータのストレージを管理し、トークンに関するトランザクションを実行し、そして、トークンネットワーク604を介して発行者ノード602と通信を交換するためのトークンアプリケーションまたはモジュールを含み得る。
【0070】
発行者ノード602は、トークンデータベース606を含むか、または、トークンアクセスし、かつ、それを維持することができる。トークンデータベース606は、発行されたトークンおよびアクティブトークンのシリアル番号を追跡する。発行者ノード602は、データベース606を維持し、そして、クエリに応答してトークンシリアル番号がアクティブであるか否かを判定し、非アクティブ化通知に応答してデータベース606内でトークンシリアル番号を非アクティブにするようにトークンシリアル番号を更新し、または、データベース606内に新しいアクティブシリアル番号を保管することができる。
【0071】
トークンシステム600は、さらに、第２ノード610を含み得る。第２ノード610は、パーソナルコンピュータ、ラップトップ、スマートフォン、タブレット、または他のモバイルコンピューティングデバイスといった、ネットワーク対応コンピューティングデバイスとして実装され得る。
【0072】
図6に示されるように、発行者ノード602は、数字612で指示されるように第１ノード608にトークンを提供することができる。トークンは、この実施例において最大デノミネーションであってよく、50ドルである。一方、発行者ノード602は、配布されたトークンがアクティブであることを示すために、トークンデータベース606を更新することができる。
【0073】
この実施例における発行者ノード602は、トークンの所有権を追跡または記録することに必ずしも関与していないことに留意すること。トークンデータベース606は、どのトークンがアクティブであるかを示すだけであり、そして、トークンの所有者または保持者の身元（identity）を示すものではない。所有権または所有に関するデータは、ブロックチェーンシステム、または、所有権を追跡し、かつ、トランザクションを促進するための別のそうしたシステムまたは台帳といった、別のシステムによって管理され得る。
【0074】
第１ノード608は、第２ノード610との見込みトランザクション（prospective transaction）へと入ることができ、そこで、第１ノード608は、20ドルトークンを第２ノード610に移転することになる。第１ノード608が20ドルデノミネーションのトークンを有していない場合に、第１ノード608は、より大きなトークンをより小さなトークンへと分割する必要があり得る。いくつかのトークンシステムにおいて、このことは、より大きなトークンを受信し、かつ、より小さなトークンのセットを発行するために、トークン発行者の関与を必要とすることがあり、または、トランザクションプロセスにおけるトークン発行者の関与を必要とすることがある。そうしたシステムは、プライバシーの喪失およびセキュリティ問題の可能性に加えて、遅延および複雑性の点で欠点を有し得る。
【0075】
本出願の一つの態様に従って、第１ノード608は、発行者ノード602が分割を行うことを必要とすることなく、有効なシリアル番号を用いて、より大きいデノミネーションのトークンをより小さいデノミネーションのトークンへと分割することが可能であり得る。特に、第１ノード608は、50ドルトークンのシリアル番号から導出されたシリアル番号を有するトークンを生成することによって、50ドルトークンを2個の20ドルトークンおよび１個の10ドル剰余トークンへと分割することができる。導出されたシリアル番号は、同じルートIDを有すること、場合によっては、デノミネーションコードを20ドルまたは10ドルに更新すること、および、適切なリーフ識別子を付加することによって、生成される。20ドルのデノミネーショントークンの１つは、次いで、数字614で指示されるように、第２ノード610に移転され得る。剰余20ドルトークンおよび10ドルトークンは、数字616および618によって指示されるように、第１ノード608によって維持され、そして、保管される。
【0076】
流通しているトークンのステータスを追跡するために、発行者ノード602は、トークンの分割を通知される必要がある。
【0077】
この実施例において、第１ノード608は、分割動作に関する通知を発行者ノード602に送信することができる。いくつかの実施態様において、通知は、50ドルトークンのシリアル番号を指定することができ、そして、50ドルトークンがどのデノミネーションへと分割されたかを指定することができる。発行者ノード602は、50ドルトークンがアクティブであったこと、および、分割が、適当な数の子トークンまたは孫トークンへのデノミネーションの分割を適切に反映していることを検証し得る。次いで、生成された子トークンまたは孫トークンのアクティブステータスを保管すること、および、親50ドルトークンを非アクティブ化することによって、トークンデータベース606を更新し得る。いくつかの事例において、50ドルトークンを非アクティブ化することは、新たに生成された子トークンまたは孫トークンのシリアル番号を保管することを支持（in favor of）して、データベース606からそのシリアル番号を削除することを意味する。場合によっては、非アクティブ化は、データベース606のデータ構造に応じて、ルートIDに関連して保管されたデノミネーションコードおよびリーフ識別子を変更することによって、データベース606を更新することを含む。
【0078】
第１ノード608からの通知は、場合によっては、新しいトークンのシリアル番号を含み得る。いくつか事例において、それは、新しいシリアル番号を含まなくてよく、そして、シリアル番号は、親トークンシリアル番号、および、それが分割された指定されたデノミネーションに基づいて、発行者ノード602によって決定され得る。
【0079】
別の実施形態において、発行者ノード602は、第２ノード610から分割の通知を受信し得る。第２ノード610からの通知は、第１ノード608からの通知の代わりであり、または、追加であり得る。第２ノード610は、第１ノード608から受信した20ドルトークンのシリアル番号を提供することができ、そして、そのシリアル番号から、発行者ノード602は、データベース606内に記録されたアクティブな50ドルノードが2個の20ドルトークンおよび１個の10ドルトークンへと分割されたことを判定し得る。次いで、データベース606内のアクティブトークン情報を更新し得る。
【0080】
いくつかの実施態様において、第２ノード610は、発行者ノード602からの20ドルトークンの有効性の認証を求める（seek）ことができる。認証クエリは、第１ノード608と第２ノード610との間のトランザクションプロセスの一部であってよく、または、そのプロセスとは別個であってよい。第２ノード610からのクエリに応答して、発行者ノード602は、提供されたシリアル番号がアクティブであるか否かを判定するために、データベース606を調べることができる。第１ノード608が、認証要求の受信前に分割の通知を提供していない場合に、発行者ノード602は、シリアル番号が無効であるという指示で応答することができる。従って、第１ノード608は、任意の有効性または真正性チェックに合格することを確実にするように、20ドルトークンを第２ノード610に移転する前に、分割の通知を発行者ノード602に送信するように構成され得る。
【0081】
これから、図7を参照すると、フローチャート形式で、シリアル化されたトークンを分割する一つの例示的な方法700を示している。方法700は、この実施例において、第１ノード608(図6)といった、トークンネットワークのノードにおいて実施され得る。ノードは、プロセッサ、および、プロセッサによって実行されると、説明される動作をコンピューティングデバイスに実行させる好適なプログラム命令を有している、ネットワーク接続されたコンピューティングデバイスを含む。いくつかの実施例において、プログラム命令は、シリアル化されたトークンを管理すること、および、シリアル化されたトークンに関わる他のノードとのトランザクションを構築し、かつ、実行することのために、コンピューティングデバイスに保管された専用のウォレットアプリケーションまたはプログラムにおいて具現化され得る。いくつかの事例において、ウォレットアプリケーションは、暗号通貨ウォレットであり得る。
【0082】
動作702において、ノードは、選択されたトークン量を受信者ノードに送信するための命令を受信する。選択されたトークン量は、シリアル化されたトークンに対して定義された最大デノミネーションより、大きくても、または、小さくてもよい。命令は、ウォレットアプリケーションに関連付けられたユーザインターフェイスを介して受信されてよく、もしくは、別のアプリケーションまたはAPIからコマンドメッセージとして受信され得る。
【0083】
動作704において、ノードは、選択されたトークン量を「正確な（“exact”）」デノミネーションでノードに保管したか否かを判定することができる。すなわち、指定された選択されたトークン量が、20ドルといった、特定のデノミネーションであり、かつ、ノードが20ドルトークンを保管している場合には、動作706で、ノードは、そのトークンを受信者ノードに移転するためのトランザクションを準備し、そして、送信する。トランザクションは、トークンにおいてトランザクションを実行するために使用されているプロトコルによって指定される、どのようなフォーマットおよび構造でも有している。いくつかの事例において、プロトコルは、ビットコインといった、暗号通貨プロトコルであるが、他の実装においては、他のトークン移転プロトコルが使用されてよい。
【0084】
選択されたトークン量が「正確な」形式で利用可能でない場合には、動作708において、ノードは、選択されたトークン量に達するように２つ以上の利用可能なトークンを合計してよいか否かを評価する。例えば、選択されたトークン量が30ドルである場合に、ノードは、合計して30ドルに等しくなるだろう、20ドル、10ドル、及び／又は、5ドルのデノミネーションで利用可能なトークンを有するか否かを評価することができる。別の例として、選択されたトークン量が、175ドルといった、最大デノミネーションよりも大きい場合に、ノードは、合計して選択されたトークン量になるだろう、50ドル、20ドル、10ドル、及び／又は、5ドルのデノミネーションで利用可能なトークンを有するか否かを評価することができる。そうである場合には、動作710において、ノードは、それらのトークンを移転するためのトランザクションを準備し、そして、送信する。いくつかの事例において、選択されたトークン量に到達するようにトークンを合計するための複数のオプションが存在する場合に、ノードは、ユーザがオプションのうちの１つを選択することを可能にするために、ユーザインターフェイスに対してオプションを出力し得る。すなわち、ユーザは、どのデノミネーションの組み合わせが、選択されたトークン量を移転するために使用されるかについて、選択を与えられ得る。
【0085】
動作712において、合計して選択されたトークン量に正確になる、利用可能なトークンを、ノードが有していない場合には、ノードは、利用可能なトークンが合計して選択されたトークン量を超えるか否か、すなわち、選択されたトークン量によって指定されるよりも多くのトークンを有するか否かを判定する。そうでない場合に、ノードは、移転命令を満たすのには不十分なトークンを有しており、そして、動作714において、ユーザインターフェイスに対して、または、送信されたメッセージによって、エラーメッセージを出力することができる。
【0086】
ノードが移転命令を満たすのに十分なトークンを有しているが、選択されたトークン量に一致するように利用可能なトークンを合計することができない場合には、トークンの１つをより小さいデノミネーションに分割する必要がある。一つの例として、選択されたトークン量が20ドルであり、ノードが50ドルのデノミネーションのトークンしか有していない場合に、ノードは、それらのトークンのうちの１つを２個の20ドルトークンおよび１個の10ドルトークンへと分割しなければならない。別の例として、選択されたトークン量が75ドルであり、ノードが20ドルトークンしか有していない場合、20ドルトークンのうちの１つを4個へと5ドルトークンに分割しなければならない。従って、動作716において、ノードは、利用可能なトークンのうちの１つ(「第１」トークン)をより小さいデノミネーションの２つ以上のトークンへと分割する。ノードは、第１トークンのシリアル番号に基づいて、より小さいデノミネーションの２つ以上のトークンの新しいシリアル番号を生成することによって、そのように動作する。すなわち、より小さいデノミネーションの２つ以上のトークンは、第１トークンからの同じフラグ、および、もしあれば、同じルートIDおよびリーフ識別子を共有している。より小さいデノミネーションのトークンのシリアル番号は、異なるデノミネーションを反映するために異なるデノミネーションコードを有しており、そして、ルートデノミネーションツリーの構造によってそのより小さいデノミネーションに割り当てられたリーフ識別子に基づいて、１つ以上の追加のリーフ識別子がさらに付加される。
【0087】
第１トークンをより小さいデノミネーションへと分割することは、所望のより小さいデノミネーションのサイズを決定することを含んでいる。すなわち、分割は必ずしも子ノードを生成するとは限らない。例えば、必要とされるトークンデノミネーションが5ドルであり、かつ、利用可能な第１トークンが50ドルデノミネーションである場合に、50ドルトークンは、10個の5ドルトークン(ひ孫、great-grandchildren)へと分割され得る。
【0088】
動作718によって示されるように、ノードは、さらに、第１トークンを２つ以上のより小さいデノミネーションに分割することが、別のデノミネーションの剰余トークンを結果として生じるか否かを判定する。5-2-1シリーズの場合に、「5」デノミネーションを２つの「2」デノミネーションへと分割すると、必然的に剰余「1」デノミネーションが生じる。従って、この場合、ノードは、そのデノミネーションの剰余トークンをさらに生成する。剰余トークンのシリアル番号は、第１トークンのシリアル番号に基づいている。すなわち、第１トークンのフラグおよびルートidを含んでいる。しかしながら、必ずしも第１トークンのリーフ識別子の任意の部分も含まない。代わりに、剰余トークンは、ルートデノミネーションツリーのそのブランチにおける、そのデノミネーションの剰余トークンに割り当てられたリーフ識別子を受け取る。
【0089】
例えば、図4および上記の表1を参照すると、シリアル番号[flags][denom][root ID][0000]を有する5ドルトークンが２つの2ドルトークンへと分割されるとき、2ドルトークンは、リーフ識別子[0000]を含んでいる同じ基本シリアル番号を継承し、結果として[flags][denom][root ID][00001]および[flags][denom][rootID][00001]をもたらすように、１つのさらなるリーフ識別子ビットが付加される。逆に、この分割動作からの1ドル剰余トークンは、結果として同じルートIDを有する剰余トークンシリアル番号を生じるが、異なるリーフ識別子、[flags][denom][root ID][101000]である。それが、ルートデノミネーションツリーのそのブランチから1ドル剰余トークンに割り当てられたリーフ識別子だからである。
【0090】
一旦、第１トークンの分割によって新しいトークンが生成され、そして、ノードに保存されると、動作720において、ノードは、トークンを移転するトランザクションを準備し、そして、受信者ノードに送信する。トークンは、新しいトークンのうちの１つ以上を含んでおり、その合計は選択されたトークン量になる。上述のように、トランザクションの構造およびフォーマット、並びに、トランザクションを実施するためのプロセスは、トークンの移転のためにトークンシステムによって使用される適用可能なプロトコルによって支配されている。
【0091】
別の実施例として、ノード(「アリス（“Alice”）」)が50ドルトークンを保持しており、そして、20ドルトークンを受信者ノード(「ボブ（“Bob”）」)に移転しようとする事例を考える。関与するトランザクションプロトコルは、ビットコイントランザクションであってよい。50ドルトークンは、次のように表される。
【表6】
【0092】
ここで、表記i(denm)は、デノミネーションのRDTインデックスレベルを示している。出力は、同じトークンであるか、または、入力から分割されたトークンのセットであり得る。
【表7】
【0093】
値およびシリアル番号の両方において入力が出力と一致することが検証可能である。アリスとボブとの間の上記の交換は、PKiがノードiの公開鍵を参照するビットコインのUTXOトランザクションモデルによって実施され得る。
【表8】
【0094】
上記の実施例において、TxIDissueは、アリスがルートID0111(「7」)およびルートID1000(「8」)の２つの元の50ドルトークンを受信したトランザクションを指し示している。<AUD(7;8)>という表記は、これらが、そうしたルートIDを有している50ドルAUDトークンであることを示している。<AUD(8)>トークンは、アリスの公開鍵に返され、一方で、<AUD(7)>トークンは、2個の20ドルトークンおよび１個の10ドルトークンへと分割される。すなわち、<AUD(7:1)>、<AUD(7:2)>、および<AUD(7:0:1)>である。20ドルトークンの１つ、<AUD(7:1)>は、出力においてボブの公開鍵(PKB)に送付される。
【0095】
いくつかの実装においては、トランザクション内に、または、トランザクション検証の一部として、条件が課され得る。ルートIDが有効であること、および、入力トークンがアクティブであること、または、分割出力トークンがアクティブであることを、発行者ノードが検証するというものである(例えば、送信ノードが、トークンを分割するその意図を発行者ノードに既に通知している場合)。発行者ノードが軽量トークンデータベースを使用して全てのトークン(RDT内の非アクティブノード／ブランチ)のステータスを追跡し得るので、これらのチェックは、実行するのに高速かつ低コストであり得る。
【0096】
いくつか事例において、トークンのエンドポイント始めの（endpoint-initiated）再結合または統合を促進することが有利であり得る。すなわち、一つの態様において、本出願は、より大きいデノミネーションの新たなトークンを生成するために、２つ以上のトークンを結合する方法およびシステムを提供する。
【0097】
ビットコイントランザクションに埋め込まれたシリアル化トークンについて、再組み合わせのプロセスは、トランザクションにおけるUTXOの数を低減することによってトランザクション料金（fee）を低減することができる。より小さいデノミネーションのトークンを再結合するようにノードに奨励することは、より小さいデノミネーションのトークンを排除することによって、さらに、トークンデータベースのストレージ要件を最適化することができる。例えば、様々なユーザがより小さいデノミネーションを組み合わせ、その結果、単一のルートIDに属する異なるユーザからのリーフIDが再結合動作を通じて非アクティブ化されたと、発行者ノードが判定する場合に、非アクティブなルートIDは、新しいルートデノミネーションを導出しなければならない以前に復帰（reinstate）されるように利用可能であり得る。
【0098】
単一のノードによって保持される子または孫のデノミネーションを親のデノミネーションへと再結合することは、比較的に簡単である。すなわち、第１ノードがルートデノミネーションツリーにおける特定のデノミネーションの全てのリーフノードを保持している場合、すなわち、組み合わされるトークンが全て同じ親を共有する場合に、それらを再結合することは、同じルートIDを有し、かつ、親のリーフ識別子を有している、より大きいデノミネーションのトークンを生成することを含む。より大きいデノミネーションは、組み合わされる、より小さい方のデノミネーションのトークンの合計である。例えば、全てが同じルートIDを有する20ドルトークンおよび6個の5ドルトークンを、同じルートIDの単一の50ドルトークンへと結合することができる。
【0099】
結合トークンを保持してるノードは、再結合を実行し、そして、再結合に関する通知を発行者ノードに送信することができる。発行者ノードは、次いで、より大きいデノミネーションがアクティブであり、より小さいデノミネーションが非アクティブであることを反映するようにデータベースを更新することができる。いくつかの事例において、発行者ノードは、結合されているトークンの所有権を検証し得る。ブロックチェーン、または、所有権を追跡するための他の検索可能な公開またはプライベート台帳に記録された所有権を検証することを通じて、といったものである。
【0100】
異なる親を有するシリアル化トークンを結合することは、より複雑であり得る。このことは、異なるルートIDからのトークン、または、異なる親を有する同じルートIDからのトークンを含んでいる。例えば、２つの5ドルトークンは、同じルートIDを有するが、同じルートデノミネーションツリー内の異なる20ドルトークンから導出されてよい。いくつかの事例において、トークンを保持しているノードは、発行者ノードが統合を実行し、そして、結合トークン（combined token）を返信することを要求し得る。従って、発行者ノードは、結合されているトークンを非アクティブ化することができ、そして、結合トークンを生成するために利用可能なルートIDを選択し得る。結合トークンのルートIDは、結合トークンのルートIDのうちの１つであってもよく、それらのルートIDのルートデノミネーションツリーが正しいデノミネーションの利用可能な非アクティブな分岐を有する場合、または異なるルートIDであってもよい。
【0101】
別の事例において、トークンを保持しているノードは、決定論的に導出されたシリアル番号を有している新しい結合トークンを生成することができ、そして、新しい結合トークンを発行者ノードに通知することができる。このアプローチは、発行者ノードが必ずしも結合トークンの事前生成に関与しないという点で、より大きな自律性をノードに与えることができる。とはいえ、場合によって、発行者ノードは、事実の後に結合動作の発生を記録し、そして、シリアル番号衝突があればそれを解決する役割を有し得る。
【0102】
本出願は、トークンを再結合するための２つの例示的なメカニズムを提示している。すなわち、ハッシュ法（hashing method）およびシャッフリング法（shuffling method）である。
【0103】
ハッシュ法は、ルートIDビット空間を２つのセグメントへと分割することによって実施され得る。第１セグメントは、発行者が生成したトークンに割り当てられたルートID空間である。このルートID空間は、ゼロから、発行される最大デノミネーショントークンの最大数までのルートIDを含み得る。ルートIDは、トークンを生成する際にトークンを順次に発行するときに、発行者ノードによって消費され得る。
【0104】
ルートIDビット空間の第２セグメントは、再結合トークンに割り当てられ得る。いくつかの実装において、セグメンテーションは、ルートIDの上位ビットを使用して実装され得る。すなわち、ビット空間の0xxx…xx部分は、発行者生成トークン用であり、そして、ビット空間の1xxx…xx部分は、再結合トークン用である。
【0105】
２つ以上のトークンの結合に対して新しいルートIDを導出するための１つの決定論的な方式は、結合トークンからのルートIDのハッシュとしてルートIDを生成することである。ルートIDは、最小から最大へ、または、最大から最小へ、整数値によってソートされ得る。いくつかの実装において、次いで、結合がハッシュされ得る。いくつかの実装において、それらは、順次にハッシュされ、そして、ビット空間を制限するためにモジュロがとられ得る。
【0106】
上位ビットが「1」に設定されることを、再結合トークンルートIDビット空間が必要とする場合に、ハッシュから導出された再結合ルートIDは、その上位ビットが設定されているかを確認するために評価されてよく、そして、そうでない場合、再結合されたルートIDが上位ビット設定で獲得されるまで、再ハッシュされる。
【0107】
いくつか事例において、トークンシステムがビットコインネットワークを使用する場合に、結合は、ビットコイントランザクションといった、トランザクションレコードに記録され得る。結合されるトークンは、ノードの公開鍵によって署名された入力の一部を形成し、かつ、結合トークンは出力であり、そして、ノードの公開鍵に移転される。
【0108】
ハッシュ衝突が起こり得るので、ハッシュ法は、ルートIDのためのビット空間のサイズの考慮を必要とし得ることが理解されるだろう。いくつか事例においては、衝突を低減するために、ビット空間は、ストレージコストを犠牲として拡大され得る。別の実装においては、再結合されたコインに対して、代わりのより大きなルートID空間が指定され得る。例えば、1に設定された高位ビットがルートIDをシグナリングする場合に、ルートIDの長さは、発行者が生成したトークンよりも、再結合トークンの方が長くなり得る。このことは、ノード自体による結合トークンの生成ではなく、むしろ、発行者による結合トークンの生成のために、トークンを発行者に返すようにノードに促進（incentivize）し得る。別の実装において、トークンデータベースは、トークンネットワークに公開されてよく、そして、ノードは、衝突を検出するためにトークンデータベースをクエリすることが可能であり得る。従って、一旦ノードがハッシュ法を使用して再結合IDを生成すると、次いで、トークンデータベースのクエリを使用して、再結合IDが使用前に利用可能であることを検証することができる。場合によっては、再結合されたIDが利用可能であるか否かを評価するために、ブルームフィルタまたは他の高速検索機構が使用され得る。
【0109】
ハッシュ法の代替は、シャッフリング法である。この方法は、各ルートのデノミネーションのツリーに未使用のリーフ識別子が存在するという事実に依存する。図3に示すような、2nツリーの例実施においては、最大デノミネーションについて第１リーフがデフォルトで「0」になるので、「1」に設定された第１リーフについて右側にツリーの未使用の鏡像が存在している。「1」で始まるリーフ識別子は、未使用であり、そして、「再結合された（“recombined”）」トークンをシグナリングするために利用可能である。このことは、ハッシュの実施例において、再結合されたルートIDをシグナリングするために上位ビットを使用することを通じたルートID空間の拡張と原理的に同様である。ここでは、トークンが再結合トークンであることをシグナリングするために、ノードが、ルート決定ツリーの右側で利用可能なリーフ識別子空間を使用するのを除いている。
【0110】
図4に示されるように、5-2-1シリーズのより複雑な実施例においては、ツリーの右側に、未使用である「1」で始まるリーフ識別子のセットが存在する。しかしながら、この場合、「剰余（“remainder”）」トークンをおそらく表すように既に割り当てられており、かつ、従って、ツリーの左側の部分と考えられる、所定の数のリーフ識別子が存在していることに留意すること。
【0111】
ノードが、より大きいデノミネーションを形成するために、２つ又はより小さいデノミネーションを結合するとき、それらの２つ又はより小さいデノミネーションそれぞれは、それぞれのルートIDを有する。ルートIDのうちの１つから開始して、ノードは、次いで、そのツリーの右側から、より大きいデノミネーションのレベルでの再結合リーフ識別子を通して検索を開始し、そのより大きいデノミネーションで利用可能な未使用の再結合リーフ識別子を識別する。このことは、利用可能なものを見つけるために、ノードが、より大きいデノミネーションの右側リーフ識別子を通じてシャッフルするので、「シャッフル（“shuffle”）」と呼ばれ得る。ルートIDのうち最初のものについてルートデノミネーションツリーの右側で利用可能なものがない場合に、ノードは、結合されているトークンのために別のルートIDに移動する。
【0112】
利用可能なリーフ識別子に対する検索は、それらのシリアル番号がアクティブであるか非アクティブであるかについて、ノードがトークンデータベースにクエリすることを含み得る。例えば、トークンデータベースが全てのアクティブなシリアル番号のリストを維持している場合、クエリは、ブルームフィルタベースのデータベースの検索であってよく、シリアル番号のうちの１つとして、ルートIDと組み合わせて、予想される右側リーフ識別子を含んでいるかを確認する。そうである場合に、ノードは、右側リーフ識別子のうち次の識別子のテストに移動する。このようにして、ノードは、より大きいデノミネーションのレベルで利用可能なリーフ識別子についてトークンデータベースを検索する。一旦、それを発見すると、利用可能なリーフ識別子を伴う対応するシリアル番号を有しているより大きなデノミネーショントークンを生成し、そして、再結合動作に関して発行者ノードに通知する。
【0113】
一旦、発行者ノードが結合について通知されると、発行者ノードは、ルートデノミネーションツリーの右側にあるより大きいデノミネーションが現在アクティブであること、および、左側のより小さいデノミネーションは現在非アクティブであることを示すように、データベースを更新することが理解されるだろう。このことは、左側のブランチまたはブランチの部分を非アクティブにする。従って、ルートデノミネーションツリーの左側の部分は、今では、再結合動作に利用可能なリーフ識別子を有している。従って、いくつかの実装においては、さらなる再結合動作において、利用可能な右側リーフ識別子を見つけることなく、ノードが右側リーフ識別子を循環する場合に、ノードは、利用可能なリーフ識別子を求めて左側識別子を循環し得る。
【0114】
ルートデノミネーションツリー(RDT)データ構造の決定論的特性は、再結合トークンは、大部分が左側のシリアル番号と同じ方法で処理され得ること、すなわち、RDTの両側に対して同じ導出および分割ルールが適用され得ることを意味する。このルールに対する警告（caveat）は、左側と右側のノード数の間の非対称性に起因して現れる。この非対称性は、左側の剰余トークンの結果である。
【0115】
この非対称性は、右側における所定の子デノミネーション、すなわち、「20」または「2」の親デノミネーションから導出されたもの、の導出に影響を及ぼす。例えば、右側にリーフID10を有する親「20」は、左側にリーフID100を有する剰余トークンが存在するため、１つの子デノミネーション(リーフID101)しか導出することができない。同様に、リーフID10100、10101を有する最初の２つの親「2」のデノミネーションは、LHSにおける剰余トークンのため子デノミネーションへと分割されない。この非対称性は、トークンシステムにとって問題にならないだろう。データベースは、左側と右側の両方に対して正しいデータ構造を有しており、かつ、新しいトークンが正しく導出または再結合されると、自動的に更新するからである。しかしながら、再結合トークンのいくつかのデノミネーションの制限的な性質は、右側のリーフ識別子を扱う場合に、ウォレットアプリケーションによる分割または統合の異なる処理を結果として生じ得る。
【0116】
ここで図8を参照すると、フローチャートの形式で、トークンを統合するための一つの例示的な方法800が示されている。方法800は、この例において、第１ノード608(図6)といった、トークンネットワークのノードにおいて実施され得る。ノードは、プロセッサ、および、プロセッサによって実行されると、説明される動作をコンピューティングデバイスに実行させる、好適なプログラム命令を有している、ネットワーク接続されたコンピューティングデバイスを含む。いくつかの実施例において、プログラム命令は、シリアル化されたトークンを管理すること、および、シリアル化されたトークンを伴う他のノードとのトランザクションを構築し、かつ、実行することのために、コンピューティングデバイスに保管された専用のウォレットアプリケーションまたはプログラムに具現化されて得る。いくつかの事例において、ウォレットアプリケーションは、暗号通貨ウォレットであり得る。
【0117】
方法800は、動作802によって示されるように、２つ以上のトークンがより大きいデノミネーションの単一トークンへと統合されることを決定することを含み得る。２つ以上のトークンは、同一のより小さいデノミネーションであってよく、または、異なるより小さいデノミネーションであってもよい。例えば、トークンは、単一の50ドルトークンへと統合された、2個の20ドルトークンおよび2個の5ドルトークンを含むことができる。別の実施例において、トークンは、単一の20ドルトークンへと統合された、4個の5ドルトークンを含むことができる。
【0118】
統合が行われるべきであるとの決定は、ユーザインターフェイスからの、もしくは、外部システムまたはAPIからの命令に基づき得る。すなわち、ノードは、トークンを統合するためのコマンドを受信することができる。別の実装において、ノードは、トークンを統合するための機会を積極的（proactively）に識別することができる。すなわち、ノードは、ノードに関連付けられた(例えば、ローカルウォレットに保管された)トークンに基づいて、より大きいデノミネーショントークンを作成するために、トークンのうちの２つ以上が結合され得ると判定することができる。ノードは、いくつかの事例において、そうしたノードによって開始される結合のユーザ確認を求めることができるが、他の実装において、ノードは、トークンのご都合主義の（opportunistic）統合を自動的に開始することができる。
【0119】
動作804において、ノードは、２つ以上のトークンが同じ親(または、祖父母又はより高いレベルのデノミネーショントークンを形成するために組み合わされる場合には、例えば、祖父母、等)を共有するか否かを判定する。もし、そうであれば、再結合が親(または祖父母)の活性化を結果として生じるように、次いで、動作806において、ノードは、場合によっては、親または祖父母のシリアル番号を有する新しく、より大きいデノミネーショントークンを生成する。動作808において、ノードは、発行者ノードがデータベース内のより大きいデノミネーショントークンをアクティブ化し、そして、結合された、より小さいトークンを非アクティブ化することができるように、発行者ノードに統合を通知する。通知は、いくつかの事例において、発行者ノードへのメッセージによるものであってよい。通知は、例えば、トークンネットワーク上で統合トランザクションを伝播することを通じて、といった、結合を公開することに基づいてよい。発行者ノードは、統合トランザクションを確認及び／又は検証すると、トークンデータベースを更新し得る。
【0120】
トークンがルートデノミネーションツリーの同じ分岐を共有するという自明なケースを統合が含まない場合には、動作810において、ノードは、統合されているトークンのルートIDを連結し、そして、候補ルートIDを獲得するためにそれらをハッシュする。統合およびハッシュ演算は、異なる実装において多くの形態をとり得るが、統合されたトークンルートIDのビット空間内に制約された、決定論的ランダム化ルートIDを生成することが意図されている。一つの例において、統合は、トークンのルートIDを最初に順序付けることを含む。順序付けは、最小から最大まで、または、最大から最小まで、であってよい。一旦、順序付けされると、連結されたルートIDは、ランダム化された数を生成するために、ハッシュ関数を使用してハッシュされる。ハッシュ関数は、場合によっては、ルートIDについてビット空間の長さを有しているハッシュを生成するように選択され得る。ハッシュ関数は、ビット空間よりも大きくてよく、そして、正しい長さを有している候補ルートIDに到達するように切り捨てられ（truncated）てよい。いくつか事例においては、正しい長さを有する候補ルートIDに到達するために、モジュロ演算が使用され得る。一つの例において、候補ルートIDの生成は、以下の形式をとる。
【数5】
【0121】
上記の式において、候補ルートIDは、RootIDrecombである。ここで、ハッシュ関数はH(・)であり、Nは統合されるトークンの数である。RootIDiはi番目のトークンのルートIDを指し、そして、nはルートIDビット空間の長さである。
【0122】
一旦、動作810において候補ルートIDが決定されると、次いで、動作812において、ノードは、統合ルートIDについて割り当てられたビット空間のセグメント内に、候補ルートIDがあるか否かを評価する。例えば、ビット空間のセグメント化が、先頭（leading）の「1」を有している統合ルートIDに基づく場合に、ノードは、候補が先頭の「1」を有するか否かを評価する。そうでない場合に、ノードは、動作814によって示されるように、ハッシュ動作を再実行し得る。このことは、後続の候補ルートIDを生成するために、候補ルートIDを再ハッシュすること(および、切り捨てまたはmod n演算を適用すること)を含み得る。これは、適切な候補が見つかるまで続く。
【0123】
一旦、候補が見つかると、ノードは、候補ルートIDが利用可能であるか否か、すなわち、既存の、アクティブなルートIDとの衝突が存在するか否かを判定することができる。この判定は、トークンデータベースにクエリすることに基づいてよい。いくつかの事例において、トークンデータベースは、ノードが、データベースに対して利用可能性クエリを生成して、送信し、そして、候補が利用可能であるか否かを示す応答を受信することを可能にする、クエリインターフェイスを含んでいる。いくつか事例において、クエリは、発行者ノードを介してルーティングされる。いくつか事例においては、トークンデータベースのコピーが、トークンネットワーク内の他の場所にミラーリングされてよく、そして、発行者ノードに直接連絡することなく、検索可能であり得る。
【0124】
候補ルートIDが利用可能でない場合には、動作814において、ノードは、候補を再ハッシュして、次の候補を見つけるために戻る。候補が利用可能である場合には、動作818において、ノードは、利用可能な候補ルートIDを組み込んだシリアル番号を有している、より大きいデノミネーショントークンを生成し、そして、動作820において、発行者ノードに通知される。次いで、統合された、より小さいトークンが現在非アクティブであり、かつ、新しい候補ルートIDを有している、より大きいトークンが現在アクティブであることを反映するように、トークンデータベースが更新される。
【0125】
トークンを統合する別の例示的な方法900が、フローチャートの形式で、図9に示されている。方法900は、利用可能なリーフ識別子を識別するためにシャッフリング動作を使用する。方法900は、この例において、第１ノード608(図6)といった、トークンネットワークのノードで実施され得る。ノードは、プロセッサ、および、プロセッサによって実行されると、説明される動作をコンピューティングデバイスに実行させる、好適なプログラム命令を有している、ネットワーク接続されたコンピューティングデバイスを含んでいる。いくつかの実施例において、プログラム命令は、シリアル化されたトークンを管理し、そして、シリアル化されたトークンを伴う他のノードを用いてトランザクションを構築し、かつ、実行するために、コンピューティングデバイス上に保管された専用のウォレットアプリケーションまたはプログラムにおいて具現化され得る。いくつかの事例において、ウォレットアプリケーションは、暗号通貨ウォレットであり得る。
【0126】
方法900は、動作902によって示されるように、２つ以上のトークンが、より大きいデノミネーションの単一トークンへと統合されるのを決定すること、を含み得る。２つ以上のトークンは、同一の、より小さいデノミネーションであってよく、または、異なる、より小さいデノミネーションであってもよい。図8に関連して説明したように、統合を行うとの決定は、ユーザインターフェイスからの、もしくは、外部システムまたはAPIからの命令に基づいてよい。すなわち、ノードは、トークンを統合するためのコマンドを受信し得る。別の実装において、ノードは、トークンを統合する機会を積極的に識別することができる。すなわち、ノードは、ノードに関連付けられた(例えば、ローカルウォレットに保管された)トークンに基づいて、より大きいデノミネーショントークンを作成するために、トークンのうちの２つ以上が結合され得ることを判定することができる。ノードは、いくつかの事例において、そうしたノードにより開始される結合のユーザ確認を求めることができるが、一方で、他の実装において、ノードは、トークンのご都合主義の統合を自動的に開始することができる。
【0127】
動作904において、ノードは、２つ以上のトークンが、ルートデノミネーションツリーの同一ブランチ上にあるか否か、すなわち、それらが同じ親または祖父母、等を共有するか否かを判定する。そうである場合には、再結合が、親または祖父母、等の(再)アクティブ化を結果としてもたらすように、動作906において、ノードは、場合によっては、親または祖父母のシリアル番号を用いて、新しい、より大きいデノミネーショントークンを生成する。動作908において、ノードは、発行者ノードがデータベース内のより大きいデノミネーショントークンをアクティブ化し、そして、結合された、より小さいトークンを非アクティブ化することができるように、発行者ノードに統合を通知する。通知は、いくつかの事例において、発行者ノードへのメッセージによるものであってよい。通知は、例えば、トークンネットワーク上で統合トランザクションを伝播することを通じて、といった、結合を公開することに基づいてよい。発行者ノードは、統合トランザクションを確認及び／又は検証すると、トークンデータベースを更新し得る。
【0128】
トークンがルートデノミネーションツリーの同じ分岐を共有するという自明なケースを統合が含まない場合には、動作910において、ノードは、ルートデノミネーションツリーのうちの１つの中の候補リーフ識別子を識別する。ルートデノミネーションツリーは、場合によっては、統合されているトークンのルートIDから選択されてよい。トークンのルートIDは、例えば、最小から最大まで、順序付けられてよく、そして、ノードは、ルートIDの最初のもので始まってよい。ツリーの右側の候補リーフ識別子は、所定のデノミネーションシリーズについて固定された、ツリー構造によって定義される。例えば、5-2-1シリーズの場合に、ツリーは非対称である。右側は、「1」で始まる全てのリーフ識別子を含むが、剰余トークン、または、そうした剰余トークンの子/孫に割り当てられる、あらゆるリーフ識別子を除外している。例えば、左側の10ドルデノミネーションのレベルは、50ドルトークンを２つの20ドルトークンに分割することから生じる、剰余10ドルに対して指定された「100」のリーフ識別子を含んでいる。その剰余10ドルは、２つの5ドルトークンに分割された場合、結果として「1000」および「1001」のリーフ識別子をもたらす。従って、各単位レベルには、そのシリーズのツリー構造によって定義される潜在的な候補である、所定の右側リーフ識別子が存在している。
【0129】
動作910は、いくつかの実装においては、ルートデノミネーションツリーの右側に属する最も左の(または、最小の)リーフ識別子から開始することを含み得る。
【0130】
動作912において、ノードは、候補リーフ識別子が利用可能であるか否かを判定する。このことは、そのルートIDおよびリーフ識別子を有しているシリアル番号が既に存在するか否かを判定するために、トークンデータベースにクエリすることを含み得る。いくつかの事例において、トークンデータベースは、ノードが、データベースに対して利用可能性クエリを生成して、送信し、そして、候補が利用可能であるか否かを示す応答を受信することを可能にする、クエリインターフェイスを含んでいる。いくつか事例において、クエリは、発行者ノードを介してルーティングされる。いくつか事例においては、トークンデータベースのコピーが、トークンネットワーク内の他の場所にミラーリングされてよく、そして、発行者ノードに直接連絡することなく、検索可能であり得る。
【0131】
利用可能である場合、動作914において、ノードは、統合トークンを表している、より大きいデノミネーショントークンを生成し、そして、ルートIDおよび候補リーフ識別子を使用して形成されたシリアル番号をそれに割り当てる。発行者ノードは、次いで、動作916において、トークンデータベースを更新することができるように、統合について通知される。
【0132】
動作912で候補リーフ識別子が利用可能でない場合には、動作912において、ノードは、同一のルートデノミネーションツリー内にさらなる候補が存在するか否かを評価する。そうである場合には、動作914において、ノードは、次の候補に対して「シャッフル（“shuffles”）」する。別の言葉で言えば、別の候補リーフ識別子を識別する。いくつかのインスタンスにおいて、ノードは、ルートデノミネーションツリーの右側における全ての可能な候補リーフ識別子を循環するように構成されている。いくつかのインスタンスおいては、ノードは、一旦、ルートデノミネーションツリーの右側における全ての候補リーフ識別子を循環すると、ルートデノミネーションツリーの左側における候補リーフ識別子を循環する。いくつかの事例において、左側のリーフ識別子は、例えば、左側の１つ以上のトークンが別のルートIDからの１つ以上のトークンと統合され、ツリーの左側の一部分を非アクティブのままにしている、別の以前の統合動作の結果として、そのブランチの非アクティブ化を通して利用可能になり得る。このことは、左側のいくつかのリーフ識別子を「再活性化（“re-activation”）」について利用可能にすることができる。すなわち、統合トークンを表すためにそれらの再使用を可能にしている。
【0133】
利用可能なリーフ識別子が第１ルートデノミネーションツリー内で見つからない場合には、次いで、動作922において、ノードは、次のルートデノミネーションツリーを選択することができる。次のルートデノミネーションツリーは、統合されているトークンの中から、ルートIDのうち次の１つであり得る。いくつかのインスタンスにおいて、ノードが、利用可能なリーフ識別子を識別することなく、統合されているトークンの中から、全てのルートID形式を使い尽くした場合には、その所有するトークンに基づいて、もしくは、発行者ノードによって発行された統合動作に適したルートIDのリストまたはデータベースに基づいて、ルートIDをランダムに選択することができる。
【0134】
上述の方法900の一つの変形例においては、リーフ識別子が利用可能であるか否かに関して、発行者ノードまたはトークンデータベースに対して周期的にクエリを送信する代わりに、ノードは、ルートIDおよびデノミネーションを含む利用可能性クエリを送信してもよく、そして、発行者ノードからの応答において、利用可能なリーフ識別子を受信し得る。利用可能なリーフ識別子は、ツリーの右側、すなわち、ルートデノミネーションツリーの再結合セグメントからのもの、または、そのデノミネーションで利用可能なリーフ識別子を右側が有していない場合には、左側からのものであってよい。利用可能なリーフ識別子がない場合には、発行者ノードは、失敗通知を返すことができ、それに応答して、ノードは、別のルートIDを用いてさらなる可用性クエリを生成し、そして、送信することができる。
【0135】
上記に提示された様々な実施形態は、単なる実施例に過ぎず、そして、本出願の範囲を限定することを、決して意味するものではない。本明細書に記載された革新の変形は、当業者にとっては明らかであり、そうした変形は、本出願の意図された範囲内にある。特に、上述の例示的な実施形態のうちの１つ以上からの特徴は、明示的には上述されていない特徴の部分的組合せ（sub-combination）を含んでいる、代替の例示的な実施形態を作成するために選択され得る。加えて、明示的には上述されていない特徴の組み合わせを含んでいる代替の例示的な実施形態を作成するために、上述の例示的な実施形態のうちの１つ以上からの特徴が選択され、そして、組み合わされてよい。そうした組み合わせ及び部分的組み合わせに適した特徴は、本出願を全体として検討することにより、当業者には容易に明らかであろう。本明細書および列挙された請求項に記載された技術的事項（subject matter）は、技術における全ての適切な変更をカバーし、かつ、包含することを意図している。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】