Apparatus and method for integrating serialized tokens - Patent Application 20070122997

Abstract

A method and computing device for merging tokens in a token system. The method may include receiving an instruction to merge two or more serialized tokens, each token having a respective serial number including a root identifier, a denomination code, and a leaf identifier assigned to the denomination code. The tokens are of denominations that, when summed, equal a larger denomination. The method may include identifying candidate root identifiers and candidate leaf identifiers, where the candidate leaf identifiers are assigned to the larger denomination, determining that the candidate root identifiers and candidate leaf identifiers are available for use, generating a new token having a new serial number including the candidate root identifiers, the candidate leaf identifiers, and the denomination code corresponding to the larger denomination, and notifying an issuer computing device of the merger and deactivation of the two or more serialized tokens resulting in the new token.

Description

[Technical Field]

[0001] The present disclosure relates to token networks, and in particular to methods and systems for serializing tokens, tracking serialized tokens, transferring serialized tokens, or combining serialized tokens. [Background technology]

[0002] Token systems are gaining increasing interest in the world of computer networking. Many real-world objects, such as works of art, company shares, or tweets, are being “tokenized.” In some cases, what is tokenized is a non-fungible good, such as a single work of art or other object, and the token associated with that item can represent “ownership” of that non-fungible item. This has led to the recent popularity of non-fungible tokens (NFTs). Tokens can be issued, transferred, or stored on a token network. A token network may be established on an underlying computing network, which may or may not include a blockchain layer to maintain a distributed ledger of token ownership.

[0003] Fungible tokens may be generated in some token systems, such as tokens representing quantities of fungible goods, banknotes, or other non-unique items. Tracking individual tokens in a fungible token system can be costly in terms of storage space. For example, considering the number of banknotes in active circulation in a sizable country such as Australia, the United Kingdom, or the United States, issuing a unique token with a unique serial number for each banknote would result in very large token database storage requirements.

[0004] It would be advantageous to have a method and system for issuing, storing, transferring, dividing, and combining fungible serialized tokens that at least partially addresses the storage space problem. [Brief explanation of the drawings]

[0005] Reference will now be made to the accompanying drawings, which show, by way of example, exemplary embodiments of the present application. [Figure 1] FIG. 1 shows an exemplary token system. [Figure 2] FIG. 2 illustrates an exemplary data structure for a token serial number constructed in accordance with an embodiment of the present application. [Figure 3] FIG. 3 shows an exemplary root denomination tree for a 2n series of denominations. [Figure 4] FIG. 4 shows an exemplary root denomination tree for the 5-2-1 series of denominations. [Figure 5] FIG. 5 illustrates, in flow chart form, one exemplary method for generating a serialization token. [Figure 6] FIG. 6 illustrates a schematic diagram of an exemplary token system and token transfer example. [Figure 7] FIG. 7 illustrates, in flow chart form, one exemplary method for splitting serialized tokens. [Figure 8] FIG. 8 illustrates, in flow chart form, one exemplary method for merging tokens. [Figure 9] FIG. 9 illustrates, in flow chart form, another exemplary method for merging tokens.

[0006] Like reference numbers used in the drawings indicate like elements and features. DETAILED DESCRIPTION OF THE INVENTION

[0007] In one aspect, a computer-implemented method for merging tokens by a computing device in a token system may be provided, the method including receiving an instruction to merge two or more serialized tokens, each token having a respective serial number, each serial number including a respective root identifier, a denomination code, and a leaf identifier assigned to the denomination code, the denomination codes for the two or more serialized tokens representing denominations selected from a set of defined, ordered denominations, and summing to equal a larger denomination from the set of defined, ordered denominations. The method may further include identifying candidate root identifiers and candidate leaf identifiers, the candidate leaf identifiers being assigned to the larger denomination; determining that the candidate root identifiers and the candidate leaf identifiers are combined and available for use; generating a new token having a new serial number that includes the candidate root identifier, the candidate leaf identifier, and a denomination code corresponding to the larger denomination; and notifying an issuer computing device of the consolidation and deactivation of the two or more serialized tokens resulting in the new token.

[0008] In some implementations, the bit space for root identifiers is divided into a first bit space for root identifiers associated with issued tokens and a second bit space for root identifiers associated with consolidated tokens, and identifying candidate root identifiers may include selecting the candidate root identifier from the second bit space. In some cases, the selecting step includes generating the candidate root identifier using a hash function. Using a hash function includes concatenating respective root identifiers of the two or more serialized tokens and hashing the result. In some cases, if the hashing step generates a first root identifier within the first bit space, the first root identifier may be rehashed until the candidate root identifier is generated.

[0009] In some implementations, determining that the candidate route identifier is available includes sending a message regarding the candidate route identifier to an issuer computing device and receiving a response message confirming that the candidate route identifier is available.

[0010] In some implementations, determining that the candidate route identifier is available includes querying a token database and receiving a query result indicating that the token database does not contain the candidate route identifier.

[0011] In some implementations, identifying candidate root identifiers and candidate leaf identifiers includes selecting one of the respective root identifiers and selecting a leaf identifier designated for a consolidated token at a higher denomination. In some cases, selecting the leaf identifier designated for a consolidated token at a higher denomination includes selecting a first leaf identifier, determining that the first leaf identifier is unavailable, selecting the candidate leaf identifier, and determining that the candidate leaf identifier is available. In some cases, selecting the leaf identifier includes sending a message to a publisher computing device and receiving a response indicating the candidate leaf identifiers are available.

[0012] In some implementations, each leaf identifier indicates a unique path from a root denomination within the defined, ordered set of denominations to a respective node in a root denomination tree that corresponds to the leaf identifier, the root denomination tree mapping a partition of the root denomination into successively smaller denominations within the defined, ordered set of denominations. In some cases, the candidate leaf identifier is a leaf identifier that is not included in the root denomination tree and that has been assigned to a consolidated token.

[0013] In some implementations, the method may further include, at the issuer computing device, removing the respective serial numbers of the two or more serialized tokens from a token database and storing a new serial number of the new token in the token database.

[0014] In another aspect, a computing device may be provided that implements a node on a token network, which in some implementations may be a distributed ledger network. The computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0015] In yet another aspect, a computer-readable medium may be provided having processor-executable instructions stored thereon, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processors to perform at least one of the methods described herein.

[0016] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art from a consideration of the following detailed description in conjunction with the drawings.

[0017] In this application, the term "and / or" is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and does not necessarily exclude additional elements.

[0018] In this application, the phrase "at least one of...or..." is intended to cover any one or more of the listed elements, including only any one of the listed elements, any subcombination, or all of the elements, and does not necessarily exclude additional elements and does not necessarily require all of the elements.

[0019] FIG. 1 illustrates one exemplary system 100 for implementing a token network. System 100 can facilitate the creation, tracking, storage, and transfer of tokens. The tokens themselves can be representative of any real-world item. Examples include property interests, stocks, currencies, cryptocurrencies, loyalty points, credits, or anything else that can be quantified.

[0020] Tokens can be non-fungible or fungible. A non-fungible token (NFT) can be specific to a unique real-world item. A fungible token represents something that can be at least partially exchanged. As an example, a fungible token system can be created in which apples are tokenized to represent a predetermined quantity of apples, such as a bushel. Each token represents ownership of a quantity of apples and not a specific bushel of apples. Tokens can be mapped to denominations, such as different amounts or partial amounts of apples. In another example, a token system tokenizes fiat currency, with each token representing a predetermined denomination of a banknote, such as $20, $10, or $5, as defined by the currency's denomination. Other systems can include denominations for any other fungible item, such as oranges, memory storage, CPU time, etc.

[0021] The system 100 includes an issuer node 102 and multiple user nodes, including a first user 104, a second user 106, and a third user 108, all interconnected by a computer network 112. The computer network may include a packet-switched network, such as a wide area internetwork like the Internet. Each node 102, 104, 106, 108 includes a computing device configured to connect to and communicate with other nodes via the computer network 112. The computing devices may include, in some examples, servers, personal computers, laptops, tablets, smartphones, wearable technology, etc.

[0022] In some embodiments, system 100 may be implemented using blockchain technology, such as Bitcoin or other protocols. In some embodiments, system 100 may be implemented using a non-blockchain peer-to-peer protocol for transactions. In some embodiments, system 100 may be implemented using a non-peer-to-peer protocol for transactions, in which issuer node 102 or other intermediary nodes are involved in authorizing and facilitating transactions between user nodes.

[0023] The issuer node 102 is coupled to a data store 110 that stores and maintains data about tokens. The issuer node 102 generates tokens according to its governing protocol and maintains records of the generated tokens in the data store 110. Each token is uniquely identifiable by its serial number. The data storage device 110 maintains a record of all validly issued tokens. In this manner, a user node can determine whether a particular token is validly issued by querying its serial number via the issuer node 102. In this sense, the issuer node is a trusted third party engaged in tracking the validity of token serial numbers. Note that the issuer node 102 does not necessarily track or maintain ownership information about individual tokens. That is, in some implementations, the data store tracks whether particular token serial numbers have been issued and are active, but does not track ownership information for those tokens. Ownership data may be tracked using another mechanism, such as the underlying blockchain technology or another token transfer protocol.

[0024] The issuer node 102 is configured to generate and issue tokens. Issued tokens are tracked in a database or other such structured data stored in the data store 110. One of the user nodes, such as the first user node 104, can take possession or ownership of multiple tokens and transfer one or more tokens to another user node, such as the second user node 106. The underlying transfer protocol, whether blockchain-based or not, can manage mechanisms for securely transferring token possession and / or ownership. For example, in a blockchain-based protocol, a transfer of a token from the first node 104 to the second node 106 can be performed by a transaction signed with a private key associated with the first node 104, payable to a public key associated with the second node 106, and specifying the token serial number in the transaction.

[0025] One of the challenges of token networks is the data space required to uniquely identify each token. In other words, with a large number of tokens, keeping track of the serial numbers of all issued tokens can result in very large memory requirements for the data store 110. To illustrate as a comparative example, consider the number of banknotes in circulation for a given currency. There are roughly 45 billion US dollars of banknotes in circulation, and enough serial number space is needed to represent each one individually.

[0026] Token networks can be considered more complex than hard banknote numbering, since token networks typically offer the possibility of splitting tokens of larger denominations into tokens of smaller denominations. In this example, a token system is assumed in which there is an ordered set of denominations defined ranging from the largest denomination token to the smallest denomination token. In some examples, the ordered set may be structured so that each token is an integer multiple of its nearest smallest neighboring token. For example, a 2-digit number system using denominations 1, 2, 4, 8, 16, etc. n In some embodiments, the ordered set may have several non-integer multiples, such as in the case of currencies in a 1:2:5 pattern, such as USD, GBP, AUD, CAD, etc., where the ordered set may include $1, $2, $5, $10, $20, $50, etc. Aside from the currency example, denominations of tokenized data storage space may be in amounts of 256 bytes, 1024 bytes, 4096 bytes, 65,536 bytes, etc. Or, as another example, agricultural products may be denominated in imperial measures, British yards, by pints, quarts, gallons, pecks, and bushels.

[0027] To account for the possibility of splitting a token into smaller denominations, the bit space for serializing the token should accommodate such splitting. In many token systems, token serialization can use a bottom-up approach, starting with the smallest denomination. As an example of non-tokenization, Bitcoin defines the smallest denomination as a satoshi, and transactions are executed to transfer a specified number of satoshis (note, however, that Bitcoin does not natively tokenize individual satoshis by assigning each a unique serial number). In the case of a fiat currency such as AUD, the smallest denomination could be, for example, $5. All other denominations are integer multiples of the smallest denomination. The number of fiat currencies in circulation (approximately 2019) breaks down by denomination as follows: [Table 1]

[0028] The dollar value of AUD in circulation is just under $80 billion. If each AUD note larger than $5 is represented as the equivalent number of $5 notes, the amount of notes in circulation, represented using the $5 root denomination, is 16 billion. This is 10 times the number of physical AUD notes in circulation.

[0029] The bit space required to serialize a volume V of tokenized banknotes based on the minimum denomination is log2(V)+1. For approximately 16 billion $5 banknotes, approximately 34 bits of serialization are required. Therefore, the resulting storage requirements for each denomination of AUD are:

number

[0030] Serializing a GBP note would require a serial number of approximately 34 bits, and serializing a USD note would require a serial number of approximately 41 bits. Using these bit space and storage requirement expressions, we can determine the storage requirements for a serialized note given the circulation number given in the table above. [Table 2]

[0031] It may be possible to serialize tokens in a manner that improves on the storage requirements associated with bottom-up serialization of an ordered set of token denominations. In accordance with one aspect of the present application, serialization can use a top-down approach, whereby the base token issued is the largest denomination token. In such a system, storage requirements are dynamic and can vary based on the subdivision of the token. The length of the serial number is dynamic and can be longer for smaller denominations to represent the division of the smaller denomination token from the larger denomination token.

[0032] In this application, each maximum denomination token is assigned a unique root identifier. A denomination field is added to the root identifier to specify which of an ordered set of denominations applies to the token. If the specified denomination is a non-root denomination, the token's serial number contains one or more leaf identifiers. Each leaf provides enough bit space to uniquely identify the token. The length of each leaf identifier may depend on the number of "children" into which the token can be divided at that level.

[0033] FIG. 2 illustrates an exemplary data structure 200 for a token serial number constructed in accordance with an aspect of the present application. In this example, the serial number includes a prefix portion 202 that includes a denomination code 204 and one or more flags 206. The flags 206 signal metadata about the token or token scheme. For example, if the token is associated with a currency tokenization, the flags 206 may signal which currency the token is associated with, i.e., the currency code. If the token is associated with an agricultural product, the flags 206 may signal the product type or class and / or the country of origin. In this example, the field is set to a length of 4 bits, but other sizes may be used in other embodiments depending on what data is being signaled using the flags 206. The size of the denomination code 204 field depends on the number of denominations in the set of ordered denominations. For a currency with denominations of $50, $20, $10, $5, $2, and $1, a 3-bit field is sufficient to signal the denomination code 204.

[0034] The serial number, in turn, includes a root identifier 208 field and a leaf identifier 210 field. The root identifier 208 field is long enough to tokenize the entire range of tokens of the largest denomination to represent all issued tokens. The leaf identifier 210 field is variable-sized. In the case of a root denomination, the leaf identifier 210 may not be present. In some cases, the root denomination may include a single-bit leaf identifier 210 that defaults to 0, potentially leaving open the possibility of signaling an issuer-generated serial number versus a user-generated serial number, as described further below.

[0035] Using paper fiat currency as an example, for the purposes of explanation, let's assume that 50 banknotes (dollars or pounds (“$ or £”)) are designated as the maximum denomination. Using AUD numbers for the purposes of this explanation, the amount of $50 banknotes represented by the various banknotes in circulation is as follows: [Table 3]

[0036] In the above formula, 83.5 million (83.5 million) $50 bills can represent 176 million (1,765 million) $20 bills plus 83.5 million $10 bills, because each $50 requires two $20 bills and one $10 bill. Similarly, there are 134 million (134 million) $10 bills in circulation, of which 83.5 million (83.5 million) are already represented by $50 bills associated with the $20 bills. Therefore, only 10.1 million ((134 - 83.5) / 5 = 10.1 million) $50 bills are needed to represent the remaining 50.5 million (50.5 million) $10 bills. Therefore, to represent all banknotes with $50 tokens, approximately 1.6 billion such tokens would be required.

[0037] To serialize 1.6 billion tokens, a bit space of approximately 31 bits is required. Similarly, we can determine the token space for serialization as approximately 31 bits for GBP and approximately 36 bits for USD. Assuming $50 AUD is represented using the root identifier (root ID) plus 1 bit, and $5 AUD is represented using the root ID plus 5 bits, the serialized AUD token therefore has a minimum bit space of approximately 31 bits for the root identifier 208, and a variable length leaf identifier 210 ranging from 0 to 5 bits.

[0038] Ignoring prefix 202 for the time being, assuming a 31-bit root identifier 208 for the highest denomination ($50 in this example), and assuming approximately 1.6 billion lots of that highest denomination (approximately $80 billion in total currency), the minimum storage requirements to track all tokens are as follows:

number

[0039] Assuming all $80 billion is represented using $5 tokens, the maximum storage requirements are:

number

[0040] Thus, the storage requirements to represent the complete token space range from an optimum of 5.77GB for all $50 tokens to a worst case of 65.2GB for all $5 tokens, which compares favorably to the static case of a fixed storage requirement of 63.32GB for AUD tokens.

[0041] Assuming all $80 billion is represented using $1 tokens, the maximum storage requirement can also be determined as follows:

number

[0042] If one looks at the actual amount of AUD banknotes in circulation for guidance on the likely distribution of banknotes, roughly 7.35 GB would be required to represent the current amount of AUD cash. Therefore, it may be advantageous to design a tokenization system that starts with the maximum denomination, rather than the minimum denomination. Furthermore, as explained below, it is easier in a tokenization system to integrate smaller denominations into larger denominations, thereby biasing the overall system toward larger denominations and smaller storage requirements.

[0043] The most efficient and straightforward serialization scheme would be to use powers of 2 when specifying the denominations. However, to illustrate the possible variations that result in remainders from division, an example based on a 5-2-1 series of denominations (e.g., 1, 2, 5, 10, 20, 50) is provided below.

[0044] For each child denomination, a flag or bit encodes the child's integer into which the parent can be divided, uniquely identifying each child. n In a series, this is straightforward. However, in a 5-2-1 series, this can result in a remainder where the "5" is divided into two "2" child tokens, because a "1" token must also be generated. In principle, there can be only a single remainder token from the division. Therefore, the first available leaf ID of the next denomination can be used to signal this remainder. Whether a grandchild token results from a remainder division of a parent token is therefore inherently indicated by the serial number.

[0045] By way of example, and using the data structure shown in Figure 2, the flags 206 field in this example may be set to 4 bits. For purposes of illustration, flags 206 may be to designate a fiat currency in this example, such as AUD, which assigns "0001" to flags 206.

[0046] The denomination code 204 may be used to signal the denomination of the currency, which in this example includes denominations of 50, 20, 10, 5, 2, and 1. These may be represented using a 3-bit flag as follows:

[0047] [Table 4]

[0048] For simplicity in this example, we assume a root identifier 208 of only 4 bits, rather than a more realistic 30-36 bits. The root identifier 208 represents a denomination of $50 originally generated by the issuer node.

[0049] It will be appreciated that a $50 denomination token can be divided into a maximum of two $20 tokens, five $10 tokens, ten $5 tokens, twenty $2 tokens, or fifty $1 tokens. For each derived child denomination, at least one bit is required to uniquely distinguish between the maximum two children that can be derived from each parent. In some cases, another bit is required to distinguish between children derived from a parent and children generated as a remainder from dividing a grandparent.

[0050] To illustrate, let's assume a $50 denomination (denomination code 000) with a root ID of "0111". The serial number possibilities for the various tokens generated through splitting the original $50 denomination token are as follows: [Table 5]

[0051] A $50 token has a fixed leaf ID of 0. In some cases, this leaf ID may be omitted when serializing a $50 token. However, it may be useful for some purposes. Note that in the case of a split of $50 into $20, leaf IDs 00 and 01 are sufficient to distinguish between the two $20 tokens resulting from the split. Furthermore, if these two $20 tokens are each split into $10 tokens, the leaf ID space occupied by the $10 tokens is limited to 0xx, meaning that the next 100 leaf IDs are available to be assigned to the $10 remainder tokens resulting when $50 is split into two $20 tokens.

[0052] Allocation of surplus leaf IDs becomes more complex at lower levels because the extra identifier space resulting from the $50 default 0 leaf ID is already in use. When assigning leaf IDs to the $1 surplus token resulting from splitting the $5 token into $2 tokens, the first available leaf ID is "101000." Thus, surplus tokens at the $1 level span the ID space from 101000 to 110001.

[0053] The division of the root token into smaller denominations will occur when the denomination is 2 nOne example of forming a series can be represented by a root denomination tree 300, as shown in Figure 3. In this simple example, each token is split into exactly two child tokens, making it easy to signal each unique token using a binary flag as shown. Note that at each successive level in the tree, the leaf identifier is extended by adding a bit. This bit signals either the left child or the right child.

[0054] A more complex serialization of the 5-2-1 series of denominations is shown in FIG. 4, which shows another exemplary root denomination tree 400. Note again that at each successive level, the leaf identifiers are extended leaf identifiers compared to their parent. With respect to direct child nodes, the extended leaf identifiers of the child nodes are based on the parent but may have additional bits to signal left or right children. However, the extended leaf identifiers of remainder nodes are not necessarily obtained by simply extending the leaf identifiers of their parents.

[0055] As can be seen in Figure 3, 2 n The root denomination tree 300 for the denomination of a series results in a symmetric tree, with each parent having two child nodes and the leaf identifiers reflecting that symmetric binary division.

[0056] Note that in FIG. 4 , the root denomination tree 400 includes a separate derivation path for remainder tokens. The remainder token is assigned the first available leaf identifier from the grandchild level. In the exemplary case of a $1 token, since the $1 token derived from splitting a $2 token ranges from 0000000 (0) to 100111 (39), the remainder tokens at that level have leaf identifiers starting with 101000 (40) and ranging to 110001 (49). The remainder nodes have leaf identifiers prefixed with a "1." Also note that denominations obtained through splitting a remainder token have leaf identifiers prefixed with a "1" rather than a "0."

[0057] Only one node along one branch of root denomination trees 300 and 400 can be active at any one time. For example, if the $10 token associated with leaf identifier "001" is active, its parent nodes (the $20 token "00" and the $50 token "0") cannot be active. Similarly, its child $10 nodes "0010" and "0011" cannot be active because they indicate that the $20 token has been split. However, the $20 token "000," which shares the same parent, can be active, or any of its child or grandchild nodes can be active.

[0058] The token database that stores active tokens can be configured in several ways. In one embodiment, the database lists the complete serial numbers of all active tokens. In another embodiment, the database is a structure that lists the serial numbers partially, such as by storing a flag and root ID, and then within the data structure storing any active denomination codes, and for each active denomination code, any leaf identifiers that are active for that denomination code.

[0059] The issuer node may manage the token database and add newly issued serial numbers or remove deactivated serial numbers, such as when tokens are split or merged. Splitting or merging serialized tokens is described further below. The issuer node may maintain the token database and verify the validity of changes before making updates, such as ensuring that only one node on the path from root to leaf is active at any one time. The issuing node may also provide a search or query interface, through which a third party or node can query whether a given serial number is active or seek the identification of inactive or available leaf identifiers or root IDs.

[0060] In some cases, the token database stores token data in addition to token serial numbers. In some cases, the token database stores only token serial numbers. In some implementations, the database may include a field or flag that indicates whether a token or serial number is "active" or "inactive." In some implementations, the database may store only active serial numbers or tokens, such that any token or serial number in the database is implicitly "active" by virtue of being in the database, and deactivation of a token or serial number is achieved through removal of that token or serial number from the database.

[0061] In some cases, a token issuer may play a role in verifying or authenticating whether a serial number corresponds to an active token in the context of a transaction. That is, authentication from a token issuer may be a condition for the execution of a token transaction in some implementations. When tokens are used on a blockchain network, for example, a token issuer may play a role in validating transactions that include serialized tokens in some implementations. An issuer node may, in some cases, be a signatory to a transaction.

[0062] Reference is now made to Figure 5, which illustrates, in flowchart form, one exemplary method 500 for generating a serialized token. Method 500 may be performed by an issuer node. The issuer node may include one or more computing devices having one or more processors and memory that stores processor-executable instructions that, when executed by the one or more processors, cause the computing device to perform the described operations.

[0063] Method 500 may involve, at operation 502, receiving a request to generate a token of a specified denomination. The request may be associated with a requesting node. The request may be received, for example, from an issuer administrator device or from an administrator interface and may reflect token generation at the issuer's instance. In some cases, the request may be received from an external device, such as a user device, and may be part of a request to tokenize an element. The element may be currency, an amount of a product, or other fungible item.

[0064] In operation 504, the publisher node assigns a unique root ID. The selection of the root ID may be random in some cases. Using a hash function or other randomizing function, the publisher node may generate the root ID and quickly verify that it does not collide with any other root ID in the database. In some embodiments, the root ID may be non-random and may be generated by incrementing the last root ID generated by one.

[0065] The issuer node then generates the requested token, including the serial number, in operation 506. The token itself may have other features or data in its data structure in addition to the serial number. The focus of this application is on the generation and management of serial numbers, and as a result, other details of the token will not be described in further detail. The serial number is generated by concatenating an optional prefix field with the root ID and leaf identifier, if any. The leaf identifier may be a fixed or default leaf identifier in the case of maximum denomination, or there may be no leaf identifier for maximum denomination.

[0066] If the requested denomination is a denomination other than the maximum denomination, the issuer node may generate an amount of tokens of the requested denomination that add up to the maximum denomination. Only one of these tokens may be intended for the requesting node, and any remaining tokens may be stored at the issuer node. In some cases, storing the tokens includes storing them in a token storage or database. In some cases, the remaining tokens are marked as inactive or unissued in the token database. The tokens intended for the requesting node are stored in the token database and marked as active (508). In some cases, marking a token as active is implicit in storing the token's serial number in the database.

[0067] The token generated for the requesting node is transmitted to the requesting node in operation 510 in response to the request.

[0068] Referring now to FIG. 6, one exemplary token system 600 is illustrated schematically. The exemplary system includes an issuer node 602 that communicates with a first node 608 via a token network 604. The token network 604 may be one or more computing networks, either wired or wireless, or both, and may include private and public computing networks, such as the Internet. The token network 604 may be implemented as a token system communication protocol operating on a packet-based network. The first node 608 may be implemented by a network-enabled computing device, such as a personal computer, laptop, smartphone, tablet, or other mobile computing device. The computing device may include a token application or module for managing storage of token data, performing transactions related to tokens, and exchanging communications with the issuer node 602 via the token network 604.

[0069] The issuer node 602 may include or have access to and maintain a token database 606. The token database 606 tracks issued tokens and active token serial numbers. The issuer node 602 maintains the database 606 and may respond to queries to determine whether a token serial number is active, update the token serial number in the database 606 to deactivate the token serial number, or store a new active serial number in the database 606 in response to a deactivation notification.

[0070] The token system 600 may further include a second node 610. The second node 610 may be implemented as a network-enabled computing device, such as a personal computer, a laptop, a smartphone, a tablet, or other mobile computing device.

[0071] 6, the issuer node 602 can provide the token to the first node 608 as indicated by the number 612. The token can be of the maximum denomination, which in this example is $50. Meanwhile, the issuer node 602 can update the token database 606 to indicate that the distributed token is active.

[0072] Note that the issuer node 602 in this example is not necessarily involved in tracking or recording ownership of the tokens. The token database 606 only indicates which tokens are active and does not indicate the identity of the token owners or holders. Ownership or ownership data may be managed by another system, such as a blockchain system or another such system or ledger for tracking ownership and facilitating transactions.

[0073] The first node 608 may enter into a prospective transaction with the second node 610, in which the first node 608 will transfer a $20 token to the second node 610. If the first node 608 does not have a token in the $20 denomination, the first node 608 may need to split the larger token into smaller tokens. In some token systems, this may require the involvement of a token issuer to receive the larger token and issue a set of smaller tokens, or may require the involvement of a token issuer in the transaction process. Such systems may have drawbacks in terms of delay and complexity, as well as potential loss of privacy and security issues.

[0074] According to one aspect of the present application, the first node 608 may be able to split a larger denomination token into smaller denomination tokens using valid serial numbers without requiring the issuer node 602 to perform the split. In particular, the first node 608 may split a $50 token into two $20 tokens and one $10 remainder token by generating tokens with serial numbers derived from the $50 token's serial number. The derived serial numbers are generated by having the same root ID, possibly updating the denomination code to $20 or $10, and appending the appropriate leaf identifier. One of the $20 denomination tokens may then be transferred to the second node 610, as indicated by numeral 614. The remainder $20 token and $10 token are maintained and stored by the first node 608, as indicated by numerals 616 and 618.

[0075] In order to track the status of the tokens in circulation, the issuer node 602 needs to be notified of the token split.

[0076] In this example, the first node 608 can send a notification to the issuer node 602 regarding the split operation. In some embodiments, the notification can specify the serial number of the $50 token and the denomination into which the $50 token was split. The issuer node 602 can verify that the $50 token was active and that the split properly reflects the division of the denomination into the appropriate number of child or grandchild tokens. The issuer node 602 can then update the token database 606 by storing the active status of the generated child or grandchild tokens and deactivating the parent $50 token. In some cases, deactivating the $50 token means removing its serial number from the database 606 in favor of storing the serial number of the newly generated child or grandchild token. In some cases, deactivation includes updating the database 606 by changing the denomination code and leaf identifier stored in association with the root ID, depending on the data structure of the database 606.

[0077] The notification from the first node 608 may optionally include the serial number of the new token. In some cases, it may not include the new serial number, and the serial number may be determined by the issuer node 602 based on the parent token serial number and the specified denomination into which it was divided.

[0078] In another embodiment, the issuer node 602 may receive notification of the split from the second node 610. The notification from the second node 610 may be in place of or in addition to the notification from the first node 608. The second node 610 may provide the serial number of the $20 token received from the first node 608, and from that serial number, the issuer node 602 may determine that the active $50 token recorded in the database 606 has split into two $20 tokens and one $10 token. The active token information in the database 606 may then be updated.

[0079] In some embodiments, the second node 610 may seek authentication of the validity of the $20 token from the issuer node 602. The authentication query may be part of the transaction process between the first node 608 and the second node 610, or may be separate from that process. In response to the query from the second node 610, the issuer node 602 may consult the database 606 to determine whether the provided serial number is active. If the first node 608 has not provided notification of the split prior to receiving the authentication request, the issuer node 602 may respond with an indication that the serial number is invalid. Thus, the first node 608 may be configured to send notification of the split to the issuer node 602 before transferring the $20 token to the second node 610 to ensure that any validity or authenticity checks are passed.

[0080] Referring now to FIG. 7, one exemplary method 700 for splitting serialized tokens is illustrated in flowchart form. Method 700 may be implemented in a node of a token network, such as first node 608 (FIG. 6), in this example. The node includes a networked computing device having a processor and suitable program instructions that, when executed by the processor, cause the computing device to perform the described operations. In some examples, the program instructions may be embodied in a dedicated wallet application or program stored on the computing device for managing serialized tokens and for structuring and executing transactions with other nodes involving serialized tokens. In some instances, the wallet application may be a cryptocurrency wallet.

[0081] At operation 702, the node receives an instruction to send a selected amount of tokens to a recipient node. The selected amount of tokens may be greater than or less than the maximum denomination defined for the serialized token. The instruction may be received via a user interface associated with a wallet application or may be received as a command message from another application or API.

[0082] At operation 704, the node may determine whether it has stored the selected token amount in the “exact” denomination. That is, if the specified selected token amount is in a particular denomination, such as $20, and the node is storing $20 tokens, then at operation 706, the node prepares and sends a transaction to transfer the tokens to the recipient node. The transaction may have any format and structure specified by the protocol being used to perform transactions on the tokens. In some instances, the protocol is a cryptocurrency protocol, such as Bitcoin, although in other implementations, other token transfer protocols may be used.

[0083] If the selected token amount is not available in the “correct” form, then at operation 708, the node evaluates whether it may combine two or more available tokens to reach the selected token amount. For example, if the selected token amount is $30, the node may evaluate whether it has available tokens in $20, $10, and / or $5 denominations that would add up to $30. As another example, if the selected token amount is greater than the maximum denomination, such as $175, the node may evaluate whether it has available tokens in $50, $20, $10, and / or $5 denominations that would add up to the selected token amount. If so, at operation 710, the node prepares and submits a transaction to transfer those tokens. In some cases, if there are multiple options for combining tokens to reach the selected token amount, the node may output options to a user interface to allow the user to select one of the options. That is, the user may be given a choice as to which denomination combination will be used to transfer the selected token amount.

[0084] If the node does not have available tokens that add up to exactly the selected token amount, then the node determines whether the available tokens add up to more than the selected token amount, i.e., whether it has more tokens than specified by the selected token amount, at operation 712. If not, the node has insufficient tokens to fulfill the transfer order, and may output an error message to a user interface or via a transmitted message at operation 714.

[0085] If a node has enough tokens to fulfill the transfer command but cannot sum up its available tokens to match the selected token amount, it must split one of the tokens into a smaller denomination. As one example, if the selected token amount is $20 and the node only has tokens of a $50 denomination, the node must split one of those tokens into two $20 tokens and one $10 token. As another example, if the selected token amount is $75 and the node only has $20 tokens, it must split one of the $20 tokens into four $5 tokens. Thus, in operation 716, the node splits one of its available tokens (the “first” token) into two or more tokens of a smaller denomination. The node does so by generating new serial numbers for the two or more tokens of the smaller denomination based on the serial number of the first token. That is, the two or more tokens of the smaller denomination share the same flags from the first token and, if any, the same root ID and leaf identifier. The serial numbers of tokens of smaller denominations have different denomination codes to reflect the different denominations, and are further appended with one or more additional leaf identifiers based on the leaf identifier assigned to that smaller denomination by the structure of the root denomination tree.

[0086] Splitting a first token into smaller denominations involves determining the size of the desired smaller denomination. That is, the split does not necessarily create child nodes. For example, if the desired token denomination is $5 and the first available token is a $50 denomination, the $50 token may be split into ten $5 tokens (great-grandchildren).

[0087] As indicated by operation 718, the node further determines whether splitting the first token into two or more smaller denominations results in a remainder token of another denomination. In the case of a 5-2-1 series, splitting the "5" denomination into two "2" denominations necessarily results in a remainder "1" denomination. Therefore, in this case, the node generates a further remainder token of that denomination. The serial number of the remainder token is based on the serial number of the first token; that is, it includes the flags and root ID of the first token, but does not necessarily include any part of the leaf identifier of the first token. Instead, the remainder token receives the leaf identifier assigned to the remainder token of that denomination in that branch of the root denomination tree.

[0088] For example, referring to Figure 4 and Table 1 above, when a $5 token having serial number [flags][denom][root ID]

[0000] is split into two $2 tokens, the $2 tokens inherit the same base serial number, including leaf identifier

[0000] , and one additional leaf identifier bit is added, resulting in [flags][denom][root ID]

[0001] and [flags][denom][root ID]

[0001] . Conversely, the $1 remainder token from this split operation results in a remainder token serial number with the same root ID, but a different leaf identifier, [flags][denom][root ID][101000], because that is the leaf identifier assigned to the $1 remainder token from that branch of the root denomination tree.

[0089] Once the new tokens have been generated by splitting the first token and stored at the node, in operation 720 the node prepares and sends a transaction to transfer the tokens to a recipient node, the transaction including one or more of the new tokens totaling the selected token amount. As noted above, the structure and format of the transaction, as well as the process for conducting the transaction, are governed by the applicable protocol used by the token system for the transfer of tokens.

[0090] As another example, consider the case where a node (“Alice”) holds a $50 token and wishes to transfer a $20 token to a recipient node (“Bob”). The transaction protocol involved may be a Bitcoin transaction. The $50 token is represented as follows: [Table 6]

[0091] Here, the notation i(denm) denotes the RDT index level of the denomination. The output can be the same token or a set of tokens split from the input. [Table 7]

[0092] It is possible to verify that the input matches the output in both value and serial number. The above exchange between Alice and Bob can be implemented via Bitcoin's UTXO transaction model, where PKi references the public key of node i. [Table 8]

[0093] In the above example, TxID issueindicates the transaction in which Alice received two original $50 tokens with root ID 0111 ("7") and root ID 1000 ("8").<AUD(7;8)> indicates that these are $50 AUD tokens with that root ID.<AUD(8)> The token is returned to Alice's public key, while<AUD(7)> The tokens will be split into two $20 tokens and one $10 token, i.e.<AUD(7:1)> ,<AUD(7:2)> , and<AUD(7:0:1)> One of the $20 tokens,<AUD(7:1)> will output Bob's public key (PK B ) will be sent to

[0094] In some implementations, conditions may be imposed within the transaction or as part of transaction validation: the issuer node verifies that the root ID is valid and that the input token is active or that the split output token is active (e.g., if the sending node has already notified the issuer node of its intention to split the token). These checks may be fast and inexpensive to perform, as the issuer node may use a lightweight token database to track the status of all tokens (inactive nodes / branches in the RDT).

[0095] In some cases, it may be advantageous to facilitate endpoint-initiated recombination or merging of tokens. That is, in one aspect, the present application provides methods and systems for combining two or more tokens to create new tokens of larger denominations.

[0096] For serialized tokens embedded in Bitcoin transactions, the recombination process can reduce transaction fees by reducing the number of UTXOs in the transaction. Incentivizing nodes to recombine tokens of smaller denominations can further optimize token database storage requirements by eliminating smaller denomination tokens. For example, if an issuer node determines that various users have combined smaller denominations, resulting in leaf IDs from different users belonging to a single root ID being deactivated through a recombination operation, the inactive root IDs may be available to be reinstated before a new root denomination must be derived.

[0097] Recombining child or grandchild denominations held by a single node into a parent denomination is relatively straightforward. That is, if a first node holds all the leaf nodes of a particular denomination in the root denomination tree, i.e., if the tokens being combined all share the same parent, recombining them involves generating a token of a larger denomination that has the same root ID and the leaf identifier of the parent. The larger denomination is the sum of the tokens of the smaller denominations being combined. For example, a $20 token and six $5 tokens, all with the same root ID, can be combined into a single $50 token with the same root ID.

[0098] The node holding the combined tokens can perform the recombination and send a notification of the recombination to the issuer node. The issuer node can then update its database to reflect that the larger denomination is active and the smaller denomination is inactive. In some cases, the issuer node can verify ownership of the combined tokens, such as through verifying ownership recorded on a blockchain or other searchable public or private ledger for tracking ownership.

[0099] Combining serialized tokens with different parents can be more complex. This includes tokens from different root IDs or tokens from the same root ID with different parents. For example, two $5 tokens may have the same root ID but be derived from different $20 tokens in the same root denomination tree. In some cases, a node holding the tokens may request that the issuer node perform the merge and return a combined token. The issuer node can then deactivate the combined tokens and select an available root ID to generate the combined token. The root ID of the combined token may be one of the root IDs of the combined tokens, if their root denomination tree has an available inactive branch of the correct denomination, or it may be a different root ID.

[0100] In another case, the node holding the token can generate a new combined token having a deterministically derived serial number and communicate the new combined token to the issuer node. This approach can give the nodes greater autonomy in that the issuer node is not necessarily involved in the pre-generation of the combined token. In some cases, however, the issuer node may be responsible for recording the occurrence of the combining operation after the fact and resolving any serial number collisions.

[0101] This application presents two exemplary mechanisms for recombining tokens: a hashing method and a shuffling method.

[0102] Hashing may be implemented by dividing the root ID bit space into two segments. The first segment is the root ID space assigned to tokens generated by the issuer. This root ID space may contain root IDs from zero to the maximum number of maximum denomination tokens issued. Root IDs may be consumed by the issuer node as it issues tokens sequentially as it generates tokens.

[0103] A second segment of the root ID bit space may be allocated to recombination tokens. In some implementations, the segmentation may be implemented using the most significant bits of the root ID. That is, the 0xxx...xx portion of the bit space is for issuer-generated tokens, and the 1xxx...xx portion of the bit space is for recombination tokens.

[0104] One deterministic scheme for deriving a new root ID for the combination of two or more tokens is to generate the root ID as a hash of the root IDs from the combined tokens. The root IDs may be sorted by integer value, from smallest to largest or largest to smallest. In some implementations, the combination may then be hashed. In some implementations, they may be hashed sequentially and then modulo taken to limit the bit space.

[0105] If the recombined token root ID bit space requires the high-order bit to be set to "1", the recombined root ID derived from the hash may be evaluated to see if its high-order bit is set, and if not, it is rehashed until a recombined root ID is obtained with the high-order bit set.

[0106] In some cases, if the token system uses the Bitcoin network, the binding may be recorded in a transaction record, such as a Bitcoin transaction: the token to be bound forms part of the input signed by the node's public key, and the bound token is the output and transferred to the node's public key.

[0107] It will be understood that hashing methods may require consideration of the size of the bit space for the root ID, as hash collisions are possible. In some cases, the bit space may be expanded to reduce collisions, at the expense of storage costs. In another implementation, an alternative, larger root ID space may be specified for recombined coins. For example, if a high-order bit set to 1 signals the root ID, the length of the root ID may be longer in a recombined token than in a token generated by the issuer. This may incentivize nodes to return tokens to the issuer for generation of the combined token by the issuer, rather than generation of the combined token by the node itself. In another implementation, a token database may be published to the token network, and nodes may be able to query the token database to detect collisions. Thus, once a node generates a recombined ID using a hashing method, it can then use a query of the token database to verify that the recombined ID is available before use. In some cases, a Bloom filter or other fast lookup mechanism may be used to evaluate whether the recombined ID is available.

[0108] An alternative to hashing is shuffling, which relies on the fact that there are unused leaf identifiers in the tree for each root denomination. nIn the example implementation of the tree, since the first leaf defaults to "0" for maximum denomination, there is an unused mirror image of the tree to the right with the first leaf set to "1." Leaf identifiers beginning with "1" are unused and available for signaling "recombined" tokens. This is similar in principle to the expansion of the root ID space through using the high order bits to signal recombined root IDs in the hashing implementation, except here the node uses the leaf identifier space available on the right side of the route determination tree to signal that the token is a recombined token.

[0109] In a more complex embodiment of the 5-2-1 series, as shown in Figure 4, there is a set of leaf identifiers on the right side of the tree that are unused and start with "1." Note, however, that in this case there are a certain number of leaf identifiers that have already been assigned to presumably represent "remainder" tokens and are therefore considered part of the left side of the tree.

[0110] When a node combines two or smaller denominations to form a larger denomination, each of those two or smaller denominations has its own root ID. Starting with one of the root IDs, the node then begins searching from the right side of the tree through the recombined leaf identifiers at the level of the larger denomination to identify unused recombined leaf identifiers available in that larger denomination. This may be called a "shuffle" because the node shuffles through the right leaf identifiers of the larger denomination to find one that is available. If none are available on the right side of the root denomination tree for the first of the root IDs, the node moves to another root ID for the token being combined.

[0111] The search for available leaf identifiers may involve the node querying a token database for active or inactive serial numbers. For example, if the token database maintains a list of all active serial numbers, the query may be a Bloom filter-based database search to see if one of the serial numbers contains the expected right leaf identifier in combination with the root ID. If so, the node moves on to testing the next identifier among the right leaf identifiers. In this manner, the node searches the token database for available leaf identifiers at the higher denomination level. Once found, it generates a higher denomination token having a corresponding serial number with the available leaf identifier and notifies the issuer node about the recombination operation.

[0112] It will be appreciated that once the publisher node is notified of the merge, it updates its database to indicate that the larger denomination on the right side of the root denomination tree is now active, and that the smaller denomination on the left side is now inactive. This deactivates the left branch or portion of the branch. Thus, the left portion of the root denomination tree now has leaf identifiers available for a remerge operation. Thus, in some implementations, if a node cycles through right leaf identifiers in a further remerge operation without finding an available right leaf identifier, the node may cycle through left leaf identifiers in search of an available leaf identifier.

[0113] The deterministic properties of the root denomination tree (RDT) data structure mean that recombined tokens can be processed in the same way as the left-hand serial numbers, i.e., the same derivation and splitting rules can be applied to both sides of the RDT. A caveat to this rule arises due to the asymmetry between the number of nodes on the left and right sides. This asymmetry is a result of the left-hand remainder token.

[0114] This asymmetry affects the derivation of certain child denominations on the right side, i.e., those derived from a parent denomination of "20" or "2." For example, a parent "20" with leaf ID 10 on the right side can only derive one child denomination (leaf ID 101) because there is a remainder token with leaf ID 100 on the left side. Similarly, the first two parent "2" denominations with leaf IDs 10100 and 10101 are not split into child denominations due to the remainder tokens on the LHS. This asymmetry should not be a problem for the token system, as the database has the correct data structure for both the left and right sides and automatically updates when new tokens are correctly derived or recombined. However, the restrictive nature of some denominations of recombined tokens may result in different handling of splits or merges by wallet applications when dealing with leaf identifiers on the right side.

[0115] Referring now to FIG. 8, one exemplary method 800 for integrating tokens is illustrated in flowchart form. Method 800 may be implemented in a node of a token network, such as node 1 608 (FIG. 6) in this example. The node includes a network-connected computing device having a processor and suitable program instructions that, when executed by the processor, cause the computing device to perform the described operations. In some embodiments, the program instructions may be embodied in a dedicated wallet application or program stored on the computing device for managing serialized tokens and for structuring and executing transactions with other nodes involving serialized tokens. In some instances, the wallet application may be a cryptocurrency wallet.

[0116] Method 800 may include determining that two or more tokens are to be consolidated into a single token of a larger denomination, as indicated by operation 802. The two or more tokens may be of the same smaller denomination or may be of different smaller denominations. For example, the tokens may include two $20 tokens and two $5 tokens consolidated into a single $50 token. In another example, the tokens may include four $5 tokens consolidated into a single $20 token.

[0117] The determination that a merger should occur may be based on an instruction from a user interface or from an external system or API. That is, the node may receive a command to merge tokens. In another implementation, the node may proactively identify opportunities to merge tokens. That is, the node may determine, based on tokens associated with the node (e.g., stored in a local wallet), that two or more of the tokens can be combined to create a larger denomination token. While the node may, in some cases, require user confirmation of such node-initiated mergers, in other implementations, the node may automatically initiate opportunistic mergers of tokens.

[0118] At operation 804, the node determines whether two or more tokens share the same parent (or grandparent, for example, if combined to form a grandparent or higher-level denomination token). If so, then at operation 806, the node generates a new, larger denomination token having the parent's or grandparent's serial number, as the case may be, so that the recombination results in the activation of the parent (or grandparent). At operation 808, the node notifies the issuer node of the merger so that the issuer node can activate the larger denomination token in its database and deactivate the combined, smaller tokens. The notification may, in some cases, be by message to the issuer node. The notification may be based on publishing the merger, such as, for example, through propagating the merged transaction on the token network. The issuer node may update its token database upon confirming and / or verifying the merged transaction.

[0119] If the merging does not involve the trivial case where the tokens share the same branch of the root denomination tree, then in operation 810, the node concatenates the root IDs of the tokens being merged and hashes them to obtain candidate root IDs. The merging and hashing operations can take many forms in different implementations, but are intended to generate deterministic, randomized root IDs constrained within the bit space of the merged token root IDs. In one example, the merging involves first ordering the root IDs of the tokens. The ordering may be from smallest to largest or from largest to smallest. Once ordered, the concatenated root IDs are hashed using a hash function to generate a randomized number. The hash function may optionally be chosen to generate a hash that has the length of the bit space for the root ID. The hash function may be larger than the bit space and may be truncated to arrive at candidate root IDs with the correct length. In some cases, modulo arithmetic may be used to arrive at candidate root IDs with the correct length. In one example, the generation of the candidate route ID takes the following form:

number

[0120] In the above formula, the candidate root ID is RootID recomb where the hash function is H(·) and N is the number of tokens to be aggregated. i denotes the root ID of the i-th token, and n is the length of the root ID bit space.

[0121] Once the candidate route ID is determined in operation 810, then in operation 812, the node evaluates whether the candidate route ID is within the segment of the bit space allocated for the aggregated route ID. For example, if the segmentation of the bit space is based on the aggregated route ID having a leading "1", the node evaluates whether the candidate has a leading "1". If not, the node may re-perform the hashing operation, as indicated by operation 814. This may include re-hashing the candidate route ID (and applying a truncation or mod n operation) to generate a subsequent candidate route ID. This continues until a suitable candidate is found.

[0122] Once a candidate is found, the node can determine whether the candidate route ID is available, i.e., whether there is a conflict with an existing, active route ID. This determination may be based on querying a token database. In some cases, the token database includes a query interface that allows a node to generate and send an availability query to the database and receive a response indicating whether the candidate is available. In some cases, the query is routed through the issuer node. In some cases, a copy of the token database may be mirrored elsewhere in the token network and may be searchable without directly contacting the issuer node.

[0123] If a candidate route ID is not available, the node rehashes the candidates and returns to find the next candidate in operation 814. If a candidate is available, the node generates a larger denomination token having a serial number incorporating the available candidate route ID in operation 818, and the issuer node is notified in operation 820. The token database is then updated to reflect that the consolidated smaller token is now inactive and that the larger token with the new candidate route ID is now active.

[0124] Another exemplary method 900 for merging tokens is shown in flowchart form in FIG. 9. Method 900 uses a shuffling operation to identify available leaf identifiers. Method 900 may be implemented at a node of a token network, such as the first node 608 (FIG. 6), in this example. The node includes a network-connected computing device having a processor and suitable program instructions that, when executed by the processor, cause the computing device to perform the described operations. In some embodiments, the program instructions may be embodied in a dedicated wallet application or program stored on the computing device to manage serialized tokens and to structure and execute transactions with other nodes involving the serialized tokens. In some instances, the wallet application may be a cryptocurrency wallet.

[0125] Method 900 may include determining that two or more tokens be combined into a single token of a larger denomination, as indicated by operation 902. The two or more tokens may be of the same, smaller denomination, or may be of different, smaller denominations. As described in connection with FIG. 8, the decision to combine may be based on instructions from a user interface or from an external system or API. That is, the node may receive a command to combine the tokens. In another implementation, the node may proactively identify opportunities to combine tokens. That is, the node may determine, based on tokens associated with the node (e.g., stored in a local wallet), that two or more of the tokens can be combined to create a larger denomination token. The node may, in some cases, require user confirmation of such node-initiated combinations, while in other implementations, the node may automatically initiate opportunistic combinations of tokens.

[0126] At operation 904, the node determines whether two or more tokens are on the same branch of the root denomination tree, i.e., whether they share the same parent or grandparent, etc. If so, at operation 906, the node generates a new, larger denomination token, possibly using the parent or grandparent serial number, so that the recombination results in the (re)activation of the parent or grandparent, etc. At operation 908, the node notifies the issuer node of the merger so that the issuer node can activate the larger denomination token in its database and deactivate the merged, smaller tokens. The notification may, in some cases, be by message to the issuer node. The notification may be based on publishing the merge, such as, for example, through propagating the merged transaction on the token network. The issuer node may update its token database upon confirming and / or verifying the merged transaction.

[0127] If the merge does not involve the trivial case of tokens sharing the same branch of the root denomination tree, then in operation 910, the node identifies candidate leaf identifiers in one of the root denomination trees. The root denomination tree may optionally be selected from the root IDs of the tokens being merged. The tokens' root IDs may be ordered, for example, from smallest to largest, and the node may start with the first root ID. The candidate leaf identifiers on the right side of the tree are defined by a tree structure fixed for a given denomination series. For example, in the case of a 5-2-1 series, the tree is asymmetric. The right side includes all leaf identifiers beginning with "1" but excludes any leaf identifiers assigned to remainder tokens or children / grandchildren of such remainder tokens. For example, the left $10 denomination level includes the leaf identifier "100," designated for the $10 remainder resulting from splitting a $50 token into two $20 tokens. That remainder of $10, when split into two $5 tokens, results in leaf identifiers of "1000" and "1001." Thus, at each unit level, there are predetermined right leaf identifiers that are potential candidates defined by the tree structure of the series.

[0128] Operation 910 may, in some implementations, involve starting with the leftmost (or smallest) leaf identifier belonging to the right side of the root denomination tree.

[0129] At operation 912, the node determines whether the candidate leaf identifier is available. This may include querying a token database to determine whether a serial number with that root ID and leaf identifier already exists. In some cases, the token database includes a query interface that allows the node to generate and send an availability query to the database and receive a response indicating whether the candidate is available. In some cases, the query is routed through the issuer node. In some cases, a copy of the token database may be mirrored elsewhere in the token network and may be searchable without directly contacting the issuer node.

[0130] If so, the node generates a larger denomination token representing the consolidated token and assigns it a serial number formed using the root ID and the candidate leaf identifier in operation 914. The issuer node is then notified of the consolidation in operation 916 so that it can update its token database.

[0131] If no candidate leaf identifiers are available at operation 912, the node evaluates whether there are any more candidates within the same root denomination tree. If so, then at operation 914, the node “shuffles” to the next candidate. In other words, it identifies another candidate leaf identifier. In some instances, the node is configured to cycle through all possible candidate leaf identifiers on the right side of the root denomination tree. In some instances, once the node has cycled through all candidate leaf identifiers on the right side of the root denomination tree, it cycles through candidate leaf identifiers on the left side of the root denomination tree. In some cases, left leaf identifiers may become available through the deactivation of that branch, for example, as a result of another previous merge operation in which one or more tokens on the left side were merged with one or more tokens from another root ID, leaving a portion of the left side of the tree inactive. This may make some left leaf identifiers available for “re-activation,” i.e., allowing them to be reused to represent merged tokens.

[0132] If no available leaf identifiers are found in the first root denomination tree, then in operation 922, the node may select a next root denomination tree, which may be the next one of the root IDs from among the tokens being merged. In some instances, if a node has exhausted all root ID formats from among the tokens being merged without identifying an available leaf identifier, it may randomly select a root ID based on the tokens it owns or based on a list or database of root IDs suitable for the merge operation issued by the issuer node.

[0133] In one variation of the above method 900, instead of periodically sending queries to an issuer node or token database regarding whether leaf identifiers are available, a node may send an availability query that includes a root ID and a denomination, and may receive available leaf identifiers in response from the issuer node. The available leaf identifiers may be from the right side of the tree, i.e., the recombination segment of the root denomination tree, or from the left side if the right side does not have any leaf identifiers available in that denomination. If no leaf identifiers are available, the issuer node may return a failure notification, and in response, the node may generate and send a further availability query using a different root ID.

[0134] The various embodiments presented above are merely examples and are not intended to limit the scope of the present application in any way. Variations of the innovations described herein will be apparent to those skilled in the art, and such variations are within the intended scope of the present application. In particular, features from one or more of the above-described exemplary embodiments may be selected to create alternative exemplary embodiments including sub-combinations of features not explicitly described above. In addition, features from one or more of the above-described exemplary embodiments may be selected and combined to create alternative exemplary embodiments including combinations of features not explicitly described above. Features suitable for such combinations and sub-combinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter set forth in this specification and the enumerated claims is intended to cover and encompass all appropriate modifications in technology.

Claims

1. 1. A computer-implemented method for integrating a token with a computing device in a token system, comprising: receiving an instruction to merge two or more serialized tokens; Each token has its own serial number, Each serial number includes a respective root identifier, a denomination code, and a leaf identifier assigned to the denomination code; the denomination codes for the two or more serialized tokens represent denominations selected from among a set of defined, ordered denominations, and when summed, equal a larger denomination from the set of defined, ordered denominations; Steps and identifying candidate root identifiers and candidate leaf identifiers; the candidate leaf identifiers are assigned to the larger denominations; Steps and determining that the candidate root identifiers and the candidate leaf identifiers are combined and available for use; generating a new token having a new serial number that includes the candidate root identifier, the candidate leaf identifier, and a denomination code corresponding to the larger denomination; notifying an issuer computing device of the consolidation and deactivation of the two or more serialized tokens resulting in the new token; A method comprising:

2. the bit space for root identifiers is divided into a first bit space for root identifiers associated with issued tokens and a second bit space for root identifiers associated with aggregated tokens; and and identifying the candidate route identifier comprises selecting the candidate route identifier from the second bit space. The method of claim 1.

3. the selecting step includes using a hash function to generate the candidate route identifiers. The method of claim 2.

4. The generating step may include the steps of concatenating root identifiers of each of the two or more serialized tokens and hashing the result; The method of claim 3, comprising:

5. the hashing step generates a first root identifier within the first bit space; and rehashing the first route identifier until the candidate route identifier is generated. The method of claim 4.

6. The step of determining that the candidate route identifier is available comprises: sending a message regarding said candidate route identifiers to an issuer computing device; receiving a response message confirming that the candidate route identifier is available; The method of claim 5 , comprising:

7. The step of determining that the candidate route identifier is available comprises: querying a token database; receiving a query result indicating that the token database does not contain the candidate route identifier; The method of claim 5 , comprising:

8. The step of identifying candidate root identifiers and candidate leaf identifiers comprises: selecting one of the respective route identifiers; selecting a leaf identifier designated for the consolidated token in the larger denomination; The method of claim 1 , comprising:

9. The step of selecting the leaf identifier designated for the aggregate token in the larger denomination comprises: selecting a first leaf identifier; determining that the first leaf identifier is unavailable; selecting the candidate leaf identifiers; determining that the candidate leaf identifier is available; The method of claim 8, comprising:

10. The step of selecting a leaf identifier comprises: sending a message to a publisher computing device; receiving a response indicating the available candidate leaf identifiers; The method of claim 8, comprising:

11. each leaf identifier indicates a unique path from a root denomination in said defined ordered set of denominations to a respective node in the root denomination tree corresponding to the leaf identifier; the root denomination tree maps a division of the root denomination into successively smaller denominations within the set of defined ordered denominations; The method of claim 10.

12. The candidate leaf identifiers are: a leaf identifier that is not included in the root denomination tree and is assigned to an integrated token; The method of claim 11.

13. The method further comprises, at the issuer computing device: removing the respective serial numbers of the two or more serialized tokens from a token database; storing a new serial number of the new token in the token database; The method of claim 1 , comprising:

14. 1. A computing device comprising: one or more processors; Memory and computer-executable instructions stored in the memory, When executed by the one or more processors, causes the processors to perform the method of any one of claims 1 to 13. computer-executable instructions; a computing device,

15. A computer-readable storage medium having processor-executable instructions stored thereon, The processor-executable instructions, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 13. A computer-readable storage medium.

Images