Detailed Action
This office action is in response to applicant’s submission filed on January 30, 2026. Claims 1-20 are pending and rejected.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This communication is in response to the amendment filed on January 30, 2026. The Examiner has acknowledged the amended claims 1-4, 6-11, 13-18, and 20. Claims 1-20 are pending and are rejected.
The amendment filed on January 30, 2026 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows: Claim 1 has been amended to recite “encapsulate the container token and the plurality of asset tokens within a container comprising a container control structure restricting a plurality of event logs of the container metadata object and the plurality of asset metadata objects; generate an allocation token compatible with a segmented allocation control structure restricting the plurality of event logs by the container of a first segmented allocation of the plurality of asset tokens based on metadata of a subset of the plurality of asset metadata objects; the plurality of event logs comprising one or more performance metrics of the metadata of the subset of the plurality of asset metadata objects of the first segmented allocation, wherein the metadata of the subset of the plurality of asset metadata objects comprises underlying physical asset information”; Claims 2, 9, and 16 has been amended to recite “generate, by the segmented allocation control structure, a plurality of segmented allocations within the container based on an event log of the container control structure corresponding to access to the plurality of asset metadata objects”; Claims 4, 11, and 18 have been amended to recite “generate an updated allocation token compatible with the segmented allocation control structure restricting the event log by the container of an updated segmented allocation of the plurality of asset tokens based on metadata of an updated subset of the plurality of asset metadata objects, the updated allocation token satisfying the first set of the plurality of parameters”; Claims 8 and 15 contain the same limitations as claim 1; see also Applicant’s claims pages 2-9.
Applicant is required to cancel the new matter in the reply to this Office Action.
Response to Arguments
Applicant’s Arguments (Remarks) filed January 30, 2026 have been fully considered, but are not persuasive. Note that this action is made FINAL. See MPEP § 706.07(a).
The applicant argues that the prior art fails to teach the amendments. Examiner respectfully disagrees. Jakobsson para. 0555 teaches the event logs being tracking records, as they are used to track up to date information about the records. Weldon para. 0038 goes on to disclose the one or more performance metrics comprising a current value of at least one physical asset or a performance of the at least one physical asset. See also 103 rejection below. The rest of the amendments argued on behalf of the applicant have been rejected for basis of new matter.
Therefore, Examiner notes that the amended claim limitations are still taught by Jakobsson, Weldon, and Sinmao.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Applicant indicated in the response that the support for amendment can be found in at least paragraphs [0043], [0101], [0115], [0133], [0142]-[0144], and [0147]. In paragraphs 0043, 0101, 0115, 0133, and 0147 there is no mention of event logs. In paragraphs 0142-0144, the specification states “The API could be configured to subscribe to event logs generated by the container control structure, which detail changes in asset valuations, transaction statuses, and updates to the metadata of the assets”, “Additionally, the event listeners can log these events for audit and compliance purposes, ensuring that all changes are documented and verifiable”, and “Specifically, these event listeners can be configured to monitor a variety of event logs emitted by the container control structure, such as updates in asset valuations or changes in transaction statuses. For example, when an asset within the container undergoes a valuation update (e.g., a process triggered by market fluctuations or asset performance) where the change is captured in an event log generated by the container control structure. The event listener, having subscribed to these specific types of logs, can detect the update and automatically trigger a predefined API call, such as getAssetMetadata(assetId).” Nowhere does it specifically support any of the amendments listed below about a plurality of event logs nor does it say an output is or can be an event log, rendering the amendments to these claims below failing to comply with the written description requirement. It only has backup on an output being encapsuled, restricted, comprising performance metrics, and so forth as the former claim limitation to the claims below have stated.
Claim 1 has been amended to recite “encapsulate the container token and the plurality of asset tokens within a container comprising a container control structure restricting a plurality of event logs of the container metadata object and the plurality of asset metadata objects; generate an allocation token compatible with a segmented allocation control structure restricting the plurality of event logs by the container of a first segmented allocation of the plurality of asset tokens based on metadata of a subset of the plurality of asset metadata objects; the plurality of event logs comprising one or more performance metrics of the metadata of the subset of the plurality of asset metadata objects of the first segmented allocation, wherein the metadata of the subset of the plurality of asset metadata objects comprises underlying physical asset information”. This limitation describes restricting a plurality of event logs, these event logs comprising one or more performance metrics of the asset metadata objects. However, the relevant portion of applicant’s specification (see Applicant’s specification pages 2-6) describes restricting outputs of the container metadata object and the plurality of asset metadata objects; generate an allocation token compatible with a segmented allocation control structure restricting outputs by the container of a first segmented allocation of the plurality of asset tokens based on metadata of a subset of the plurality of asset metadata objects; the outputs comprising one or more performance metrics of the metadata of the subset of the plurality of asset metadata objects of the first segmented allocation, wherein the metadata of the subset of the plurality of asset metadata objects comprises underlying physical asset information. Therefore, the Examiner will interpret these lines as if these amendments did not occur (former claim limitations; replacing event logs back to output as originally stated) which takes out the event log limitations in its entirety in order to create a clear understanding of the actual output and what that output comprises to align with applicant’s specification.
Claims 2, 9, and 16 has been amended to recite “generate, by the segmented allocation control structure, a plurality of segmented allocations within the container based on an event log of the container control structure corresponding to access to the plurality of asset metadata objects.” This limitation describes basing the generated segmented allocations on an event log, not an output. However, the relevant portion of applicant’s specification (see Applicant’s specification page 3) describes basing the generated segmented allocations on an output, not an event log. Therefore, the Examiner will interpret these lines as if these amendments did not occur (former claim limitations; replacing event logs back to output as originally stated) which takes out the event log limitations in its entirety in order to create a clear understanding of the actual output and what that allocations that output is based on to align with applicant’s specification.
Claims 4, 11, and 18 have been amended to recite “generate an updated allocation token compatible with the segmented allocation control structure restricting the event log by the container of an updated segmented allocation of the plurality of asset tokens based on metadata of an updated subset of the plurality of asset metadata objects, the updated allocation token satisfying the first set of the plurality of parameters”. Examiner notes that this claim will be interpreted the same as claim 1 as they both state restricting an event log instead of the output which was not shown in the specification.
Claims 8 and 15 contain the same limitations and therefore, Examiner notes that these claims will be interpreted the same as claim 1 as they all replace output with event logs which was not shown in the specification.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0385815 A1 to Jakobsson et al. (hereinafter, “Jakobsson”) in view of WO 2023/122182 A1 to Weldon et al. (hereinafter, “Weldon”) in further view of US 2023/0076526 A1 to Sinmao et al. (hereinafter, “Sinmao”).
Regarding claim 1, Jakobsson discloses: A system, comprising:
a data processing system comprising memory and one or more processing circuits configured to (“Processing systems are illustrated as CPU A, CPU B, CPU C, and CPU D 525. The CPUs 525 may be personal computers, server computers, mobile devices, edge IoT devices, etc. Pointer A may select one or more processors at random to perform the execution of a given smart contract. The code may be secure or nonsecure and the CPU may be a trusted execution environment (TEE), depending upon the needs of the request. In the example reflected in FIG. 5A, pointer B 513, pointer C 514, and pointer D 515 all point to a decentralized storage network 530 including remote off-ledger resources including storage systems illustrated as Disks A, B, C, and D 535” [0110]):
identify a plurality of asset tokens comprising links to a plurality of asset metadata objects (“Systems and methods in accordance with certain embodiments may establish token hierarchies that allow for tokens to directly control ownership rights. In accordance with some embodiments, meta-tokens may be implemented that allow a token to obtain ownership of another token, thereby tying ownership. Additionally or alternatively, in accordance with many embodiments, smart contracts may be implemented that allow NFTs, through the use of smart contracts, to directly own tokens including but not limited to cryptocurrency and digital fungible tokens” [0068] [Examiner notes that the asset metadata objects are what those tokens reference, such as the ownership in this case]);
generate a container metadata object comprising metadata of the plurality of asset tokens (“In accordance with many embodiments, approach, possession of the digital containers is the same as possession of the physical resource and the digital containers may evolve and/or change their metadata based upon the acquisition of the physical resource, but using another approach, the possession of the digital containers simply allows, including but not limited to by performing payment and the destruction of the digital container, the acquisition of the rights to the physical resource” [0574] [Examiner notes that the evolving metdata is the container metadata object because it stores information about the grouped assets, such as ownership or state changes]);
generate a container token comprising a link with the container metadata object (“In accordance with many embodiments, approach, possession of the digital containers is the same as possession of the physical resource and the digital containers may evolve and/or change their metadata based upon the acquisition of the physical resource, but using another approach, the possession of the digital containers simply allows, including but not limited to by performing payment and the destruction of the digital container, the acquisition of the rights to the physical resource” [0574] [Examiner notes that the digital container here acts as a token itself; holding it grants rights to the underlying assets and since the container token references the metadata object, that shows the link]);
encapsulate the container token and the plurality of asset tokens within a container comprising a container control structure restricting a plurality of event logs of the container metadata object and the plurality of asset metadata objects (“An example NFT which may be associated with specific content in accordance with several embodiments of the invention is illustrated in FIG. 16A. In some embodiments, an NFT 1600 may utilize a vault 1650, which may control access to external data storage areas. Methods of controlling access may include, but are not limited to, user credential information 1350. In accordance with a number of embodiments of the invention, control access may be managed through encrypting content 1640. As such, NFTs 1600 can incorporate content 1640, which may be encrypted, not encrypted, yet otherwise accessible, or encrypted in part. In accordance with some embodiments, an NFT 1600 may be associated with one or more content 1640 elements, which may be contained in or referenced by the NFT. A content 1640 element may include, but is not limited to, an image, an audio file, a script, a biometric user identifier, and/or data derived from an alternative source. An example alternative source may be a hash of biometric information). An NFT 1600 may also include an authenticator 1620 capable of affirming that specific NFTs are valid” [0194] [Examiner notes that the container (vault) holds tokens and content, with rules/controls on access and outputs]);
request and monitor, by the segmented allocation control structure, the plurality of event logs of the container control structure (“In accordance with certain embodiments triggering conversion rules may cause the generation of log entries, which may be implemented as tracking records, as disclosed in co-pending application titled “Managing Watchful Changes” by Markus Jakobsson. The tracking record may be automatically transmitted to an auditing entity, and/or logged on blockchains and/or off-chain databases. The selection of action may depend on one or more conditions associated with the token(s), specifying rules detailing when various actions are taken, where example tracking actions may include but are not limited to the transmission of encrypted data identifying ownership, and/or royalty payments” [0555] [Examiner notes that the event logs are being monitored before being logged onto the blockchain]),
wherein the container control structure generates the plurality of event logs corresponding to updates to records of the at least one physical asset (“In accordance with certain embodiments triggering conversion rules may cause the generation of log entries, which may be implemented as tracking records, as disclosed in co-pending application titled “Managing Watchful Changes” by Markus Jakobsson. The tracking record may be automatically transmitted to an auditing entity, and/or logged on blockchains and/or off-chain databases. The selection of action may depend on one or more conditions associated with the token(s), specifying rules detailing when various actions are taken, where example tracking actions may include but are not limited to the transmission of encrypted data identifying ownership, and/or royalty payments” [0555] [Examiner notes that the event logs are tracking records, as they are used to track up to date information about the records]);
Jakobsson does not disclose: request and monitor, by the segmented allocation control structure, the plurality of event logs of the container control structure, the plurality of event logs comprising one or more performance metrics of the metadata of the subset of the plurality of asset metadata objects of the first segmented allocation, wherein the metadata of the subset of the plurality of asset metadata objects comprises underlying physical asset information, the one or more performance metrics comprising a current value of at least one physical asset or a performance of the at least one physical asset, determine an allocation distribution corresponding to the allocation token based on the one or more performance metrics of the first segmented allocation; and in response to determining the allocation distribution, either: automatically initiate an on-chain exchange of the allocation distribution from an instrument owner’s wallet address to a mobile wallet address of the client system, wherein the instrument owner’s wallet address corresponds to an instrument owner with a security interest in one or more underlying physical assets of the first segmented allocation of the plurality of asset tokens; or automatically process an off-chain exchange from the instrument owner’s wallet address to an account of a user operating the client system.
However, Weldon discloses: request and monitor, by the segmented allocation control structure, the plurality of event logs of the container control structure, the plurality of event logs comprising one or more performance metrics of the metadata of the subset of the plurality of asset metadata objects of the first segmented allocation, wherein the metadata of the subset of the plurality of asset metadata objects comprises underlying physical asset information, the one or more performance metrics comprising a current value of at least one physical asset or a performance of the at least one physical asset (“Blockchain is a technology that uses cryptography to create a secure linkages between records (referred to as “blocks”). Blockchain is a type of distributed database that can record transactions in a public or private peer-to-peer network. In the context of blockchain technologies, a “ledger” refers to a series of interconnected records or blocks; “distributed ledger” is another term for a blockchain. Blockchain technologies distribute a database of transactions (a ledger) to all participants in a network. The participants in a blockchain network are referred to as “peers” or “nodes”. In some examples, the compute nodes 102, app server 120, SP nodes 150, and/or other compute nodes/devices operate as blockchain nodes in a blockchain network. Each node in a blockchain network, including the TBC apps 116b implemented/ operated by the compute devices 102, may also include or otherwise implement the same or similar crypto processor(s) 136c and/or TBC service(s) 136b discussed herein. The ledger is shared, replicated, and synchronized among nodes in the network. In most implementations, a blockchain has no central administrator or centralized data storage system, however, in other implementations a centralized system may be used to validate blocks or perform other functions. Most ledgers are used to track a specific type of information or transactions such as cryptocurrency, securities, asset tokens, smart contracts, and/or the like. Every record in a distributed ledger has transaction data, a timestamp, and a hash of the previous block in the ledger, making it an auditable, permanent record of all transactions. In some implementations, the hash of the previous block may act as a block identifier (ID), or a hash of the block itself (including the hash of the previous block) may act as a block ID. In some implementations, the blocks may be encrypted to enhance security. The nature of the cryptographic linkage makes the series of interconnected records more resistant to spontaneous changes to data in a record because publishing an update to an individual record entry also requires altering the cryptographic hash that was generated as the record was created, and any records added to the ledger after an altered record must be re-validated and re-added to the ledger (also with updated hashes). In a blockchain, a change to a record’s value is typically published as anew ledger entry. When this single blockchain is connected to some kind of network that can handle communication between nodes and provide an agreed upon system for each node to verily changes to network data, then an individual blockchain can be replicated across different nodes in the network. This replication creates multiple blockchain ledgers, containing identical records that have been independently verified. In these ways, a blockchain is provides immutability for the transactions that are tracked” [0038] [Examiner notes that the blockchain's validation process acts as that request step. Each blockchain node continuously monitors the state of the ledger, mirroring what the segmented allocation control structure would do when tracking outputs. The recorded data points in the text are the performance metrics being monitored, the timestamps, transaction data, etc. are the immutable activity indicators. It also states that a blockchain ledger can focus on specific subsets (e.g., only the asset tokens or smart contracts relevant to one allocation). Examiner also notes that the blockchain ledger tracks asset tokens, which correspond to being linked to physical assets, so the ledger preserves the metadata about those real-world items]),
determine an allocation distribution corresponding to the allocation token based on the one or more performance metrics of the first segmented allocation (“Typically, smart contracts include one or more functions that take relevant or desired data (e.g., unique IDs, content items, name, inheritance (if applicable), metadata, and/or any other relevant data structures, variables, parameters, and/or the like) as arguments and assigns it/them to appropriate variables. Smart contracts can also include transfer logic for transferring corresponding assets, such as the cryptocurrency, fungible token, or NFT. This typically involves defining one or more functions that take a new owner's address as an argument and updates the contract's internal state to reflect the transfer. Additionally or alternatively, the smart contracts can include logic for calculating and distributing royalties, which may include one or more functions defined to obtain a sale price as an argument and uses it to calculate the royalty payment. In various implementations, the smart contract specifies options, self-expiration parameters, and/or unique time-based digital asset ownership elements. Additionally or alternatively, the smart contract (or the options, self-expiration parameters, and/or unique time-based digital asset ownership elements) specifies transaction(s) or transaction type(s) that can be used to mint (generate), purchase, or otherwise obtain the corresponding NFT or fungible token. The specific syntax and/or code of a smart contract may depend on the specific language being used and/or the TBC platform on which the smart contract is to be deployed. Smart contracts can be written in higher-level programming languages and compiled to smart contract-specific bytecode. The higher-level programming languages may be a smart contract specific language such as, for example, Ethereum® Virtual Machine (EVM) bytecode, [Solidity], [Vyper] (Python derived), [Yul+], Bamboo, Lisp Like Language (LLL), C++ for EOS. IO, Simplicity provided by Blockstream™, Rholang, Michelson, Counterfactual, Plasma, Plutus, Sophia, EOS. IO, [Cadence], and/or the like, or may be any of the other programming languages discussed herein, or combination(s) thereof. Once a smart contract is written/developed and compiled, it can then be deployed to one or more blockchains via a suitable interface. Once deployed, one or more blockchain nodes in a blockchain network can execute or run the smart contract code” [0040] [Examiner notes that the text shows smart contract codes performing the calculation of allocation using input metrics (sale price, performance data, transaction data, etc.). The allocation distribution is applied to the specific token (NFT or asset token), matching the limitation that each allocation token receives its portion]); and
in response to determining the allocation distribution, either: automatically initiate an on-chain exchange of the allocation distribution from an instrument owner’s wallet address to a mobile wallet address of the client system, wherein the instrument owner’s wallet address corresponds to an instrument owner with a security interest in one or more underlying physical assets of the first segmented allocation of the plurality of asset tokens; or automatically process an off-chain exchange from the instrument owner’s wallet address to an account of a user operating the client system (“In embodiments, any time a gaming aspect is generated or created (e.g., recorded and/or stored), and/or when that gaming aspect is minted into a token (e.g., entered into a blockchain), at least one sub-token to that gaming aspect or token is also created or minted. This sub-token is also unique to the users/players to which they are awarded or otherwise assigned. Furthermore, the subtokens can be traded (e.g., bought, sold, or otherwise exchanged) in an online marketplace or tokenization platform mentioned previously. Minted items can also be purchased via an option and then immediately sold on the same or different marketplace platforms. For example, if a gamer is awarded a token, but does not have adequate funds to acquire the minted token, the gamer is awarded the right to purchase or otherwise acquire the minted token at a later date or within a specified period of time (e.g., an option), or the gamer can sell the right to purchase/acquire the minted token in an online marketplace or other platform. Here, the right to acquire the minted token is embodied as a sub-token, and the sub-token is tied or linked to the minted token. This subtoken can be embodied as a smart contract and/or a Dapp that references the minted token. For example, the sub-token can include a token ID generated or otherwise assigned to the minted token, a hash of the minted token, and/or the like. Additionally, the sub-token (e.g., smart contract or Dapp) can specify and/or define various conditions, parameters, and/or criteria for acquiring the minted token (e.g., how to exercise the option), and the minted (main) token (which is also a smart contract or Dapp) includes various conditions, parameters, and/or criteria that link the token to the sub-token. For example, the sub-token (e.g., smart contract or Dapp) can specify or define an expiration time period (e.g., measured from the time of minting the sub-token and/or the main token) and/or an expiration date of the main token. Because the main token is linked to the subtoken, ownership of the main token is transferred to an entity/element (e.g., TBC app 116b) that fulfills or satisfies the conditions, parameters, and/or criteria specified by the sub-token (e.g., smart contract or Dapp). When deployed/minted to a blockchain, the sub-token (e.g., smart contract or Dapp) can automatically detect when the conditions, parameters, and/or criteria specified by the sub-token are fulfilled. As examples, the conditions, parameters, and/or criteria specified by the sub-token can include an exercising TBC app 116b paying or otherwise transferring a specified amount of fiat currency, cryptocurrency, in-game assets, or the like to a specified (seller) TBC app 116b (or to the TBC service 136b). Additionally or alternatively, the conditions, parameters, and/or criteria specified by the sub-token can include performing various in-game actions/tasks or reaching specified achievements (e.g., reaching a certain level, defeating an in-game character or boss, winning a certain number of games, earning a specified number of points, traveling to a location in a virtual world, and the like)” [0090] [Examiner notes that this texts shows a system that has a trigger after allocation is matched by the sub-token detecting conditions before transfer leading into the sub-token/smart contract automatically triggering a transfer, the transfer being executed on-chain, the "main token" owner (TBD app 116b) is the source of the transfer (interpreted as the instrument owner's wallet), the recipient wallet/client wallet is receiving the transferred assets, the main token represents ownerships of assets (the source wallet has rights), and the main token to sub-token linkage represents the segmented allocation of asset]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Jakobsson with the added structure of Weldon for the purpose of the token system being able to facilitate secure exchange using a blockchain successfully while also using an event log to monitor updates.
Jakobsson-Weldon does not disclose: generate an allocation token compatible with a segmented allocation control structure restricting plurality of event logs by the container of a first segmented allocation of the plurality of asset tokens based on metadata of a subset of the plurality of asset metadata objects; provide, by the segmented allocation control structure to a client system, the allocation token;
However, Sinmao discloses: generate an allocation token compatible with a segmented allocation control structure restricting plurality of event logs by the container of a first segmented allocation of the plurality of asset tokens based on metadata of a subset of the plurality of asset metadata objects; provide, by the segmented allocation control structure to a client system, the allocation token (“In some instances, a method is disclosed for providing a multi-tier tokenization platform. The method includes initializing one or more general asset tokens by an application on a first machine, wherein the one or more general asset tokens associated with a plurality of users of the platform, each of the general asset tokens having a first value, and the one or more general asset tokens mapped, by the application, to a value of one or more assets in a general asset pool. A request is received by the application to use one of the one or more general asset tokens to create one or more specific asset tokens that map to a portion of specific assets from the general asset pool, wherein the one or more assets including the specific assets. The request can be initiated from a remote machine associated with one of the plurality of users associated which the one of the one or more general asset tokens to be used in the creation of specific asset tokens. A first specific asset token is created that maps to a portion of a whole specific asset, wherein the first specific asset token based at least in part on the request data. A record of the generated specific asset token and the updated status of the general asset token is stored” [0021] [Examiner notes that the specific asset token is the allocation token since it represents just a subset of the total general pool. The multi-tier platform defines and enforces segmentation. The request data and mapping describes which assets (metadata subset) belong to that allocation while the record is the allocation metadata objects (stores the descriptive data for that subset and updates the overall container). The allocation token is then provided to the client system since the user's request triggers creation of a specific asset token for that user, which lets the system provide the resulting token back to them]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Jakobsson-Weldon with the added structure of Sinmao for the purpose of the token system being able to have a specific asset token created that maps to a portion of a whole specific asset (see Sinmao, para 0021).
Claim 8 recites substantially the same limitation as claim 1, in the form of a method for implementing the corresponding system, therefore it is rejected under the same rationale.
Claim 15 recites substantially the same limitation as claim 1, in the form of non-transitory computer readable medium comprising computer readable program code for implementing the corresponding method, for implementing the corresponding system, therefore it is rejected under the same rationale.
Regarding claims 2, 9, and 16, a combination of Jakobsson-Weldon-Sinmao discloses the system of claims 1/8/15.
Weldon further discloses: generate, by the segmented allocation control structure, a plurality of segmented allocations event log of the container control structure corresponding to access to the plurality of asset metadata objects (“In embodiments, any time a gaming aspect is generated or created (e.g., recorded and/or stored), and/or when that gaming aspect is minted into a token (e.g., entered into a blockchain), at least one sub-token to that gaming aspect or token is also created or minted. This sub-token is also unique to the users/players to which they are awarded or otherwise assigned. Furthermore, the subtokens can be traded (e.g., bought, sold, or otherwise exchanged) in an online marketplace or tokenization platform mentioned previously. Minted items can also be purchased via an option and then immediately sold on the same or different marketplace platforms. For example, if a gamer is awarded a token, but does not have adequate funds to acquire the minted token, the gamer is awarded the right to purchase or otherwise acquire the minted token at a later date or within a specified period of time (e.g., an option), or the gamer can sell the right to purchase/acquire the minted token in an online marketplace or other platform. Here, the right to acquire the minted token is embodied as a sub-token, and the sub-token is tied or linked to the minted token. This subtoken can be embodied as a smart contract and/or a Dapp that references the minted token. For example, the sub-token can include a token ID generated or otherwise assigned to the minted token, a hash of the minted token, and/or the like. Additionally, the sub-token (e.g., smart contract or Dapp) can specify and/or define various conditions, parameters, and/or criteria for acquiring the minted token (e.g., how to exercise the option), and the minted (main) token (which is also a smart contract or Dapp) includes various conditions, parameters, and/or criteria that link the token to the sub-token. For example, the sub-token (e.g., smart contract or Dapp) can specify or define an expiration time period (e.g., measured from the time of minting the sub-token and/or the main token) and/or an expiration date of the main token. Because the main token is linked to the subtoken, ownership of the main token is transferred to an entity/element (e.g., TBC app 116b) that fulfills or satisfies the conditions, parameters, and/or criteria specified by the sub-token (e.g., smart contract or Dapp). When deployed/minted to a blockchain, the sub-token (e.g., smart contract or Dapp) can automatically detect when the conditions, parameters, and/or criteria specified by the sub-token are fulfilled. As examples, the conditions, parameters, and/or criteria specified by the sub-token can include an exercising TBC app 116b paying or otherwise transferring a specified amount of fiat currency, cryptocurrency, in-game assets, or the like to a specified (seller) TBC app 116b (or to the TBC service 136b). Additionally or alternatively, the conditions, parameters, and/or criteria specified by the sub-token can include performing various in-game actions/tasks or reaching specified achievements (e.g., reaching a certain level, defeating an in-game character or boss, winning a certain number of games, earning a specified number of points, traveling to a location in a virtual world, and the like)” [0090] [Examiner notes that each sub-token is a segmented allocation of assets within the vault. The sub-token/smart contracts acts as the control structure that determines allocations since the metdata shows who is allowed to access what as the asset metadata objects contain details of the asset like ownership, type of asset, value, etc.]).
Weldon does not discloses: generate, by the segmented allocation control structure, a plurality of segmented allocations within the container based on an output of the container control structure corresponding to access to the plurality of asset metadata objects.
However, Jakobsson discloses: generate, by the segmented allocation control structure, a plurality of segmented allocations within the container based on an output of the container control structure corresponding to access to the plurality of asset metadata objects (“...vault 1650, which may control access to external data storage areas” [0194]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Jakobsson with the added structure of Weldon for the purpose of having a container which offers significant advantages in software development, including efficiency and enhanced security.
Regarding claims 3, 10, and 17, a combination of Jakobsson-Weldon-Sinmao discloses the system of claims 2/9/16.
Weldon further discloses: wherein generating the plurality of segmented allocations comprises applying a plurality of parameters to segment the plurality of asset tokens encapsulated a token of the plurality of asset tokens is at least one of a fungible token or a non-fungible token (NFT) (“Furthermore, in some implementations, multiple sub-tokens can be minted for a single token. In these implementations, the token and/or each sub-token (e.g., smart contract or Dapp) can specify or define various conditions, parameters, and/or criteria that need to be fulfilled by at least one sub-token for ownership of the token. In one example, the token/sub-tokens can specify that a first entity/element (e.g., TBC app 116b) to fulfill specified conditions will acquire the minted token. In another example, the token/sub-tokens can specify conditions, criteria, parameters, and the like for granting ownership rights (or option rights) to one sub-token in the set of sub-tokens (e.g., a first sub-token possessor paying a second sub-token possessor for the second sub-token possessor’ s rights to the token, and so forth). In another example, the token/sub-tokens can specify that multiple entities can share ownership of the token (e.g., purchase ownership shares), and/or specify ownership allocations among the sub-tokens when exercised (e.g., percentage ownership stakes in the token according to purchase/transfer amounts, in-game achievements, and/or the like)” [0091] [Examiner notes that the allocation of each sub-token is controlled by rules or parameters (parameters determines which sub-token goes to which entity, which is effectively splitting the main token according to those parameters). The text also shows segmentation based on parameters (purchase amounts, achievements, etc.) because it shows how the main token is divided into fractional sub-tokens according to specific rules]).
Weldon does not discloses: wherein generating the plurality of segmented allocations comprises applying a plurality of parameters to segment the plurality of asset tokens encapsulated within the container, and wherein the token is at least one of a fungible token or a non-fungible token (NFT).
However, Jakobsson discloses: wherein generating the plurality of segmented allocations comprises applying a plurality of parameters to segment the plurality of asset tokens encapsulated within the container, and wherein the token is at least one of a fungible token or a non-fungible token (NFT) (“...vault 1650, which may control access to external data storage areas” [0194]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Jakobsson with the added structure of Weldon for the purpose of having a container which offers significant advantages in software development, including efficiency and enhanced security.
Regarding claims 4, 11, and 18, a combination of Jakobsson-Weldon-Sinmao discloses the system of claims 3/10/17.
Jakobsson further discloses: request and monitor, by the segmented allocation control structure, the plurality of event logs of the container control structure, the plurality of event logs comprising the metadata of the subset of the plurality of asset metadata objects of the first segmented allocation; determine at least one of the plurality of asset tokens of the first segmented allocation conflicts with a first set of the plurality of parameters; generate an updated allocation token compatible with the segmented allocation control structure restricting the event log by the container of an updated segmented allocation of the plurality of asset tokens based on metadata of an updated subset of the plurality of asset metadata objects, the updated allocation token satisfying the first set of the plurality of parameters; and provide, by the segmented allocation control structure to the client system, the updated allocation token (“A process for determining whether a transaction may be allowed based on inspection of a banlist and allowlist is illustrated in FIG. 19 . Process 1900 may be performed through entities including but not limited to smart contracts. Process 1900 receives (1910) a request for a transfer of a token X to an address A. Token transfers may also refer to the minting of tokens and/or various other token transactions. Process 1900 determines (1910) whether the address A is in a banlist. When address A is on the banlist, process 1900 rejects (1940) the transaction. In such cases, process may determine that the token X remains registered under its current owner. Additionally or alternatively, the smart contract may determine that the request to mint and/or otherwise modify the token X is refused. When address A is not on the banlist, process 1900 determines (1930) whether address A is in an allowlist. When address A is not on the allowlist, process 1900 rejects (1940) the transaction. When address A is on the allowlist, process 1900 executes (1950) the transaction and/or transfers ownership of the token X to address A. Additionally or alternatively, process may determine that the request to mint and/or otherwise modify the token X is approved” [0217] [Examiner notes that the system is explicitly receiving and monitoring requests for token actions. The system checks the metdata (token and address info) for rules compliance and identifies conflicts with parameters (ban list/allow list) and flags them. After the conflict check, the system either rejects or approve which is effectively generating the updated allocation outcome. The result is then applied to the client/address which is seen as providing the updated allocation token]; “In accordance with certain embodiments triggering conversion rules may cause the generation of log entries, which may be implemented as tracking records, as disclosed in co-pending application titled “Managing Watchful Changes” by Markus Jakobsson. The tracking record may be automatically transmitted to an auditing entity, and/or logged on blockchains and/or off-chain databases. The selection of action may depend on one or more conditions associated with the token(s), specifying rules detailing when various actions are taken, where example tracking actions may include but are not limited to the transmission of encrypted data identifying ownership, and/or royalty payments” [0555] [Examiner notes that the event logs are being monitored before being logged onto the blockchain after being triggered (requested)]).
Regarding claims 5, 12, and 19, a combination of Jakobsson-Weldon-Sinmao discloses the system of claims 3/10/17.
Jakobsson further discloses: wherein the first segmented allocation comprises a first plurality of the plurality of asset tokens satisfying a first set of the plurality of parameters, and a second segmented allocation comprising a second plurality of the plurality of asset tokens satisfying a second set of the plurality of parameters (“Multiple views of wallets may also be accessible. One such view can correspond to the classifications described above, which indicates the actions and interactions others can perform relative to elements. Another view may correspond to a classification of content based on use, type, and/or users-specified criterion. For example, all game NFTs may be displayed in one collection view. The collection view may further subdivide the game NFTs into associations with different games or collections of games. Another collection may show all audio content, clustered based on genre. users-specified classification may be whether the content is for purposes of personal use, investment, or both. A content element may show up in multiple views. users can search the contents of their wallet by using search terms that result in potential matches” [0157] [Examiner notes that the wallet is showing different groups (segmented allocations) in each view based on different criteria/rules]).
Regarding claims 6 and 13, a combination of Jakobsson-Weldon-Sinmao discloses the system of claims 1/8.
Jakobsson further discloses: wherein each of the plurality of asset tokens correspond to a controllable electronic record representing an ownership instrument of at least one security interest in at least one of the plurality of asset tokens (“When the user wishes to purchase an NFT using fungible tokens, media wallet applications can request authentication of the NFT directly based upon the public key of the content creator and/or indirectly based upon transaction records within the NFT blockchain. As discussed above, minted NFTs can be signed by content creators and administrators of the NFT blockchain. In addition, users can verify the authenticity of particular NFTs without the assistance of entities that minted the NFT by verifying that the transaction records involving the NFT within the NFT blockchain are consistent with the various royalty payment transactions required to occur in conjunction with transfer of ownership of the NFT by the smart contract underlying the NFT” [0091] [Examiner notes that the NFT is verified via blockchain transaction records so those records are the controllable electronic record. The NFT represents ownership of a digital asset (authenticity + creator signature = proof of ownership). Examiner also notes that the NFT links to royalty payments and transfer of ownership enforced by a smart contract so the holder has rights/claims (security interest) tied to the NFT]).
Regarding claims 7 and 14, a combination of Jakobsson-Weldon-Sinmao discloses the system of claims 1/8.
Jakobsson further discloses: wherein providing, by the segmented allocation control structure to the client system, the allocation token is responsive to (1) receiving a first allocation request comprising a first amount in exchange for a portion of an allocation distribution of the first segmented allocation or (2) a re-allocation, after a threshold time period, of the first segmented allocation corresponding to a re-allocated first segmented allocation and receiving a second allocation exchange request comprising a second exchange amount for a re-allocated portion of a re-allocated allocation distribution of the re-allocated first segmented allocation (“In another embodiment, the transaction is selected from the group consisting of a self-dealing transaction and a transfer transaction. The self-dealing transaction: is a transaction where the requesting party is also the receiving party; and is at least one selected from the group consisting of: a minting of the token; a derivation of the token; and an importation of the token, wherein the requesting party is a token marketplace. The transfer transaction is a transaction wherein the requesting party is an owner of the token, and the receiving party is a consumer of the token” [0012] [Examiner notes that the text explicitly defines two kinds of requests (self-dealing which includes minting, etc. and transfer (owner to consumer)). Each begins with a requesting party initiating a transaction. In a transfer transaction, ownership (a portion of the asset allocation) is transferred from the owner to a consumer (inherently involving an exchange of value or amount). A self-dealing transaction like minting represents a reallocation of tokens since it changes ownership rights (reallocation limitation). Both transaction types result in creation or movement of a token which provides the updated allocation token to the appropriate party]).
Claim 20 recites substantially the same limitation as claims 1 and 6, in the form of non-transitory computer readable medium comprising computer readable program code for implementing the corresponding method, for implementing the corresponding system, therefore it is rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a
USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use
the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached on 571-270-5440. The fax phone number for the organization where this
application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from
Patent Center. Unpublished application information in Patent Center is available to registered users. To
file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit
https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and
https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional
questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like
assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA)
or 571-272-1000.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408