DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response Applicant communication filed on 6/8/2026.
Claims
Claims 1, 9, and 17 have been amended.
Claim 20 has been cancelled.
Claim 21 has been newly added.
Claims 1-19 and 21 are currently pending in the application.
Response to Arguments
101
The applicant argues that Claim 1 is not directed to an abstract idea because the claims are directed to technical improvements and it is not well-understood, routine, or conventional in the art to perform the steps of Claim 1 (see applicant’s arguments/remarks pages 11-14).
However, the examiner respectfully disagrees. Claim 1 recites: “store an… record comprising a plurality of… assets and an… ledger associated with the plurality of… assets, the… ledger comprising hashes of historical transfer data comprising historical transfer locations and historical transfer times of the plurality of… assets; receive a request to check out at least one… asset of the plurality of… assets, wherein the at least one… asset is configured to be transferred to a plurality of… target locations, and wherein the request comprises an… target location of the plurality of… target locations for the at least one… asset while the at least one… asset is checked out; cause a transfer of the at least one… asset from the… record to the… target location; record a first hash of first recordation data associated with the transfer in the… ledger in real time when the at least one… asset is transferred from the… record to the… target location and a first time that the at least one… asset was transferred to the… target location; receive the at least one… asset from the… target location; store the at least one… asset back in the… record; and store a second hash of second recordation data associated with receipt of the at least one… asset in the… ledger in real time when the at least one… asset is stored back in the… record, the second recordation data comprising a second time that the at least one… asset was stored back in the… record”. This is an abstract idea which can all be performed by a human using pen and paper. A human can track lend assets to others and track the times and places the assets are used on a physical ledger using pen and paper. This falls under certain methods of organizing human activity and mental processes. The additional elements of the claim include a computing system comprising at least one processor in communication with at least one memory. However, this is nothing more than using a computer as a tool to perform the abstract idea and therefore is not an improvement to technology. Further, the additional elements of using an electronic record, digital assets, electronic ledger, and electronic target locations are generally linking the abstract idea to the particular technological environment of computers and blockchain networks. None of the additional elements alone or in combination with the abstract idea recite an improvement in technology. Further the use of the blockchain to store hashed data in an electronic ledger is well-understood, routine, and conventional.
The examiner has considered all of the applicant’s arguments but maintains the 101 rejection.
103
In Applicant’s arguments with respect to claim 1 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-8 and 21 are directed to a system, claims 9-16 are directed to a non-transitory computer-readable storage medium, and claims 17-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Claim 17 recites recording the use of assets and the return of assets on a ledger. Specifically, the claim recites “store an… record comprising a plurality of… assets and an… ledger associated with the plurality of… assets, the… ledger comprising hashes of historical transfer data comprising historical transfer locations and historical transfer times of the plurality of… assets; receive a request to check out at least one… asset of the plurality of… assets, wherein the at least one… asset is configured to be transferred to a plurality of… target locations, and wherein the request comprises an… target location of the plurality of… target locations for the at least one… asset while the at least one… asset is checked out; cause a transfer of the at least one… asset from the… record to the… target location; record a first hash of first recordation data associated with the transfer in the… ledger in real time when the at least one… asset is transferred from the… record to the… target location and a first time that the at least one… asset was transferred to the… target location; receive the at least one… asset from the… target location; store the at least one… asset back in the… record; and store a second hash of second recordation data associated with receipt of the at least one… asset in the… ledger in real time when the at least one… asset is stored back in the… record, the second recordation data comprising a second time that the at least one… asset was stored back in the… record”, which is grouped within the “certain methods of organizing human activity” and “mental process” groupings of abstract ideas in prong one of step 2A of the Alice/Mayo test because the claims involve recording the use of assets and the return of assets on a ledger which falls under the category of commercial/legal interactions, business relations, managing personal behavior or relationships, and concepts performed in the human mind. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; MPEP § 2106.04(a)). Claim 1 is directed to a system that performs the same functions of claim 17 and claim 9 is directed to a non-transitory computer-readable storage medium that stores instructions that causes a processor to perform the same functions of claim 17. Therefore Claims 1 and 9 are also directed to the abstract idea of recording the use of assets and the return of assets on a ledger.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test, the additional element(s) of claims 1, 9, and 17, such as the use of the at least one processor, at least one memory, and computer-readable storage medium, merely use(s) a computer as a tool to perform an abstract idea. Specifically, the at least one processor, at least one memory, and computer-readable storage medium perform(s) the steps or functions of recording the use of assets and the return of assets on a ledger. The use of a processor/server as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Further, the use of the digital assets, electronic record, electronic ledger, and electronic target location is generally linking the use of the judicial exception to a particular technological environment (e.g. computer/blockchain network) or field of use. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP § 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP § 2106.05(b)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
Claims 1, 9, and 17 does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of using a at least one processor, at least one memory, and computer-readable storage medium to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of recording the use of assets and the return of assets on a ledger. As discussed above, taking the claim elements separately, the at least one processor, at least one memory, and computer-readable storage medium perform(s) the steps or functions of the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of recording the use of assets and the return of assets on a ledger. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Further, the use of the digital assets, electronic record, electronic ledger, and electronic target location are recited at a high level and are used for generally linking the use of the judicial exception (e.g. recording the use of assets and the return of assets on a ledger) to a particular technological environment (e.g. computer/blockchain) or field of use and is not indicative of an inventive concept. Therefore, the claim is not patent eligible.
The dependent claims 2-8, 10-16, 18, 19, and 21 further describe the abstract idea. Claims 2 and 10 describe the electronic ledger as a blockchain which is generally linking the abstract idea to a particular technological environment and therefore does not amount to significantly more or integrate the abstract idea into a practical application; claims 3, 11, and 18 recite the abstract idea of identifying a subset of assets and identify a plurality of potential receivers for the subset of assets. There are no additional elements that amount to significantly more or integrate the abstract idea into a practical application; claims 4, 5, 12, 13, and 19 recite the abstract idea of selling assets and receiving funds for the sale. There are no additional elements different from the independent claims that amount to significantly more or integrate the abstract idea into a practical application; claims 6, 7, 8, 14, 15, and 16 recite the abstract idea of a selector choosing a receiver to receive the assets and then sending the receiver the asset. There are no additional elements different from the independent claims that amount to significantly more or integrate the abstract idea into a practical application; claim 21 recites the abstract idea of storing ownership data and location data of the asset in the ledger. The additional element of the processor is merely using a computer as a tool to perform the abstract idea. The additional elements of the NFT, digital asset, and electronic ledger is generally linking the abstract idea to the particular technological environment of computers/blockchain. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Rejections under 35 § U.S.C. 103
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 9-12, 17, 18, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210201336 A1 (“Mallett”) and US 20230396610 A1 (“Berry”) and US 20220358450 A1 (“Stephens”).
Per claims 1, 9, and 17, Mallet discloses:
digital asset (DA) computing system for transferring digital assets and generating histories associated with the digital assets, the DA computing system comprising at least one processor in communication with at least one memory, wherein the at least one processor is programed to: (e.g. computer system 102 comprises a computer memory (“memory”) 104, a display 106, one or more Central Processing Units (“CPU”) 108, one or more Input/Output (I/O) devices 110 (e.g., keyboard, mouse, CRT or LCD display, etc.), other computer-readable media 112, and one or more network connections 114. The branded digital item system 100 is shown residing in memory 104) (Section [0057]);
receive a request to check out at least one digital asset of the plurality of digital assets, wherein the request comprises an electronic target location for the at least one digital asset while the at least one digital asset is checked out (e.g. In response to the user selection of a particular branded digital item of interest, in an example embodiment, the branded digital item system 100 accesses information in the branded digital item blockchain that identifies particular authorized digital environments in which the selected branded digital item may be used. It is appreciated that a brand client and a content provider have previously negotiated use of a particular branded digital item. In some instances, the content provider may have a plurality of different digital environments that the branded digital item may be used) and (e.g. The GUI 802 allows the user to select a particular one of the digital environments 806, 808, 810 that their purchased branded digital item will be used in. In response to a selection, for example, of the Cycling Hero game, the non-fungible token stored in the branded digital item blockchain is accessed from the branded digital item blockchain library 150. Then, after user authentication based on the information in the non-fungible token is completed, the accessed 2D and/or 3D model data of the branded digital item is then used in the selected digital environment) (Section [0106]-[0108], [0150]-[0152], and Fig. 8);
cause a transfer of the at least one digital asset from the electronic record to the electronic target location (e.g. If a match is made between the identity of the digital environment and/or content provider 156 indicated in the user request and the stored authorized digital environment(s) and/or authorized content providers 156, the non-fungible token information and/or the branded digital item may be accessed from the branded digital item blockchain and released for use in the digital environment) (Section [0109]-[0110], [0152], and [0153]);
Although Mallett discloses storing a plurality of digital assets associated with an electronic record of a user, recording data associated with the transfer in an electronic ledger, and transferring at least one digital asset to an electronic target location in response to a request from the user, Mallett does not specifically disclose:
receive the at least one digital asset from the electronic target location;
store the at least one digital asset back in the electronic record;
store a second hash of second recordation data associated with receipt of the at least one digital asset in the electronic ledger in real time when the at least one digital asset is stored back in the electronic record….
However Berry, in analogous art of NFT use in target locations, discloses:
receive the at least one digital asset from the electronic target location (e.g. In other specific embodiments of the method, re-checking the authentication NFT back into the original private distributed trust computing network, includes verifying the authentication NFT being checked back-in and storing, in the deactivated state, the authentication NFT in a distributed ledger of the original private distributed trust computing network) (Section [0093]);
store the at least one digital asset back in the electronic record (e.g. In other specific embodiments of the method, re-checking the authentication NFT back into the original private distributed trust computing network, includes verifying the authentication NFT being checked back-in and storing, in the deactivated state, the authentication NFT in a distributed ledger of the original private distributed trust computing network) (Section [0093]);
store a second hash of second recordation data associated with receipt of the at least one digital asset in the electronic ledger in real time when the at least one digital asset is stored back in the electronic record… (e.g. The event header 106 may include a cryptographic hash of the previous event object 106-A; a nonce 106-B, i.e., a randomly generated 32-bit whole number; a cryptographic hash of the current event object 106-C wedded to the nonce 106-B; and a time stamp 106-D. The event object data 108 may include event information 108-A being recorded) and (e.g. In other specific embodiments of the method, re-checking the authentication NFT back into the original private distributed trust computing network, includes verifying the authentication NFT being checked back-in and storing, in the deactivated state, the authentication NFT in a distributed ledger of the original private distributed trust computing network) (Section [0093]) and (e.g. authentication application 510 is configured to receive third input 528 that is configured to move the authentication NFT 430 from the activated state 560 to the deactivated state 560 and check-in 580 to the distributed ledger 104 of the first private distributed trust computing network 100. In those embodiments of the invention, in which the deactivated state comprises an encrypted authentication NFT, moving the authentication NFT 430 from the activated state 560 to the deactivated state 560 may comprises encrypting (e.g., key wrapping) the authentication NFT 430 with the same hash used to originally encrypt the authentication NFT. Checking-in 580 the authentication NFT 430 comprises creating a new data block/event object 104-A within the distributed ledger 104 of the first private distributed trust computing network 100) (Sections [0052], [0056] and [0080]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the NFT checkout process/system of Mallett to return of the NFT back to the user electronic record when it’s done being used, as taught by Berry, in order to achieve the predictable result of increasing the security of the NFT by securely storing it when it’s not in use (See Berry paragraph [0094]).
Although Mallett/Berry discloses recording digital asset transfers and returns in a distributed ledger, Mallett/Berry does not specifically disclose:
store an electronic record comprising a plurality of digital assets and an electronic ledger associated with the plurality of digital assets, the electronic ledger comprising hashes of historical transfer data comprising historical transfer locations and historical transfer times of the plurality of digital assets;
record a first hash of first recordation data associated with the transfer in the electronic ledger in real time when the at least one digital asset is transferred from the electronic record to the electronic target location, the first recordation data comprising an indication of the electronic target location and a first time that the at least one digital asset was transferred to the electronic target location;
…the second recordation data comprising a second time that the at least one digital asset was stored back in the electronic record.
However Stephens, in analogous art of tracking NFTs on a distributed ledger, discloses:
store an electronic record comprising a plurality of digital assets and an electronic ledger associated with the plurality of digital assets, the electronic ledger comprising hashes of historical transfer data comprising historical transfer locations and historical transfer times of the plurality of digital assets (e.g. The digital asset is created, and a distributed ledger tracking a history of the digital asset is created and stored across a plurality of devices. A unique token may be created for the digital asset, with a unique identifier for the digital asset and metadata identifying properties of the digital asset. Pending or completed changes to properties of the digital asset, such as ownership, visual appearance, or metadata, can be identified as a request to update the history of the digital asset. A new block can be generated for, and appended to, the distributed ledger identifying the changes to the history of the digital asset. The new block can include one or more hashes of one or more previous blocks in the distributed ledger) and (e.g. Tracking the history of the digital assets can include, for example, tracking when, how, and by whom the digital asset was created, used, modified, rented to, rented by, sold to, purchased by, licensed to, licensed by, exchanged to, exchanged by, and/or other actions) (Section [0033], [0034], and Fig 6B);
record a first hash of first recordation data associated with the transfer in the electronic ledger in real time when the at least one digital asset is transferred from the electronic record to the electronic target location, the first recordation data comprising an indication of the electronic target location and a first time that the at least one digital asset was transferred to the electronic target location (e.g. Tracking the history of the digital assets can include, for example, tracking when, how, and by whom the digital asset was created, used, modified, rented to, rented by, sold to, purchased by, licensed to, licensed by, exchanged to, exchanged by, and/or other actions) and (e.g. Each block's block header 310/340/370 can include a Merkle root 320/350/380. The Merkle root 320/350/380 can be is generated based on hashes of each of the tokens, transactions, smart contracts, and/or other elements identified in the payload 330/360/390 for that block. Any attempt to modify a payload after the block has been entered would change the Merkle root. A verifying device can verify that the payload(s) 330/360/390 have not been modified by computing the Merkle root, then comparing the computed Merkle root to the stored Merkle root 320/350/380 that is stored in the block header 310/340/370. Changes to the payload 330/360/390 and/or to the Merkle root 320/350/380 would also change the hash for the block and/or for the block header, for which a value is stored in the next block as the hash) and (e.g. In operation 970, a request to rent the token 400, and thus the digital asset, is received at the digital asset access gateway 920. In some examples, in operation 975, the digital asset management engine 925 may grant a second user a temporary rental license (e.g., through a token smart contract 445) to use the token 400, and thus the digital asset, without transferring ownership of the token 400 or the digital asset from the first user to the second user. In some examples, in operation 975, the digital asset management engine 925 may temporarily transferring ownership of the token 400, and thus the digital asset, from the first user to the second user, without allowing the second user to sell or otherwise transfer ownership during their temporary ownership period (e.g., through a token smart contract 445). The digital asset management engine 925 may automatically revert the ownership back to the first user after the rental license period expires (e.g., through a token smart contract 445) and (e.g. At operation 1415, the digital asset tracking system generates a new block for the distributed ledger automatically in response to receiving the request to update the history of the in-game digital asset, wherein the new block includes a payload identifying one or more updates to the history of the in-game digital asset represented as one or more new interactions with the token, wherein the new block also includes a hash of at least a portion of a prior block of the distributed ledger. Operation 1415 can be followed by operation 1420. The new block of operation 1425 may be an example of the new block of operation 1415) and (e.g. The property of the in-game digital asset can include an ownership of the in-game digital asset, so that the one or more updates to the property of the in-game digital asset include an change to the ownership of the in-game digital asset from a first owner account to a second owner account based on execution of one or more smart contracts. A change to the ownership is illustrated in the buy button 670, the history 660, and the ownership 665 of FIG. 6B, the buy buttons of FIG. 8A, and the operation 955. The in-game digital asset can include a license for in-game use of the in-game digital asset, so that the one or more updates to the property of the in-game digital asset include a grant of the license for in-game use of the in-game digital asset to one or more licensee accounts based on execution of one or more smart contracts) (Section [0033], [0034], [0059], [0060], [0084], [0102], [0128]-[0133], [0135]-[0139], Fig. 6B, and Fig. 14A); Note: the limitation “the first recordation data comprising… a first time that the at least one digital asset was transferred to the electronic target location” does not distinguish over the prior art because it is describing the data being recorded which does not affect the steps/functions of the claim in a manipulative sense.
…the second recordation data comprising a second time that the at least one digital asset was stored back in the electronic record (e.g. In some examples, at least some of the actions or activities identified in the activity feed 224, the content time stamp file 214, and/or the object file 216 can be identified in the history of the non-fungible in-game digital asset tracked in the distributed ledgers 150) and (e.g. Each block's block header 310/340/370 may also include various elements of metadata, such as a version number for the blockchain ledger platform, a version number for the block itself, a timestamp for verification of each payload, a timestamp for generation of the block, a timestamp for entry of the block into the blockchain ledger 300, a timestamp for request of generation of the block, a difficulty target value (e.g., adjusting difficulty of mining), one or more randomized nonce values, a counter identifying how many nonces have been tried, a title of the blockchain ledger 300, an identifier as to what the blockchain ledger 300 is tracking (e.g., a history of a digital asset associated with a video game), or a combination thereof) (Section [0047], [0056], and [0060]). Note: the limitation “the second recordation data comprising a second time that the at least one digital asset was stored back in the electronic record” does not distinguish over the prior art because it is describing the data being stored and does not affect the steps/functions of the claim in a manipulative sense.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the NFT checkout process/system of Mallett/Berry to record the history of the digital asset on the blockchain including the location and the time that the asset was licensed/rented, as taught by Stephens, in order to achieve the predictable result of reducing the risk of fraud by having real-time visibility of a digital assets history to authenticate its use (see Stephens paragraph [0004]).
Per claims 2 and 10, Mallet/Berry/Stephens discloses all the limitations of claims 1 and 9 above. Mallett further discloses:
wherein the electronic ledger comprises a blockchain ledger (e.g. A branded digital item blockchain is then generated with a ledger containing each of the instances of the non-fungible tokens. A cryptographically secured hash of the branded digital item blockchain is generated and added into the ledger of the branded digital item blockchain. Accordingly, the contents of the ledger are secured) (Section [0037]).
Per claims 3, 11, and 18, Mallet/Berry/Stephens discloses all the limitations of claims 1, 9, and 17 above. Mallett further discloses:
identify a subset of the plurality of digital assets stored in the at least one memory for administration by a distributor (e.g. In some embodiments, the searching users may have previously indicated a preference for particular branded digital items. This preference information may be saved into the client user data 142) (Section [0144]);
identify a plurality of potential receivers for the subset of digital assets (e.g. When a previously indicated branded digital item of interest becomes available on the secondary marketplace, a notification of the availability of the branded digital item may be communicated to that particular user) (Section [0144]).
Per claims 4 and 12, Mallet/Berry/Stephens discloses all the limitations of claims 3 and 11 above. Mallett further discloses:
receive a sale input associated with a sale of a digital asset of the plurality of digital assets (e.g. For example, the hypothetical conceptual digital environment illustrates a sell icon 412. In response to selection of the sell icon 412 by the user, a request to sell one or more owned branded digital items is communicated to the branded digital item system 100) (Section [0140]-[0142]);
cause the digital asset to be transferred to a purchaser digital record associated with a purchaser of the sale (e.g. Once the branded digital item is purchased, the branded digital item blockchain is updated with an updated non-fungible token information and/or an updated branded digital item blockchain. The updated branded digital item blockchain reflects the new ownership of the branded digital item. Then, only the new purchasing user may use that particular branded digital item) (Section [0143]-[0145]).
Per claim 21, Mallet/Berry/Stephens discloses all the limitations of claim 1 above. Stephens further discloses:
wherein the at least one processor is further programmed to store at least one non-fungible token (NFT) associated with the at least one digital asset in the electronic ledger, wherein the at least one NFT comprises ownership data associated with the at least one digital asset and location data that electronically points to at least one electronic location where the at least one digital asset is stored (e.g. FIG. 4 is a block diagram illustrating an example token 400 that can be non-fungible and that can represent a digital asset 405 associated with a video game as tracked in a distributed ledger, according to an aspect of the present disclosure. In some examples, the token 400 is a non-fungible token (NFT)) and (e.g. The token 400 may identify a token ownership 420, which may identify who owns the token 400, and by extension, the corresponding digital asset 405) and (e.g. The pointer elements 1305 can point to a location (on a network and/or device) at which one or more copies of digital asset 1360 are stored. For example, the pointer elements 1305 can encode a URI pointing to the location at which the digital asset 1360 is stored. The pointer elements 1305 can point to a location (on a network and/or device) at which one or more copies of the distributed ledger 1350 corresponding to the digital asset 1360 (and/or a corresponding token 1355) are stored. For example, the pointer elements 1305 can encode a URI pointing to the location at which the distributed ledger 1350 and/or the corresponding token 1355 is stored. The pointer elements 1305 can point to a location (on a network and/or device) at which the token 1355 is stored) (Section [0066], [0074], and [0126] and Fig. 4).
The motivation to combine Stephens with Mallet/Berry is disclosed above with reference to claims 1, 9, and 17.
Claims 5, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mallett/Berry/Stephens, as applied to claims 4, 12, and 18 above, in further view of US 20230298435 A1 (“Dalmia”).
Per claims 5 and 13, although Mallett/Berry/Stephens disclose selling a digital asset and transferring the digital asset to the purchaser, Mallett/Berry/Stephens do not specifically disclose:
receive funds associated with the sale;
store the funds in the plurality of digital assets for administration by the distributor.
However Dalmia, in analogous art of selling NFTs, discloses:
receive funds associated with the sale (e.g. The cross-channel application may enable traditional digital wallet and/or crypto wallet functionalities such as making payments in traditional currency and/or cryptocurrency and/or managing NFT assets) (Section [0060] and [0247]);
store the funds in the plurality of digital assets for administration by the distributor (e.g. In example embodiments, the information recorded for a transaction may include identifying information (e.g., a public key) for the providing and receiving parties, an identification of the gaming channel involved in the transaction, any smart contract actions performed as a result of the transfer (e.g., transfer of funds between a digital wallet of a purchaser and a digital wallet of a seller), or other pertinent information relating to the transaction. The transaction can be stored as a block within the blockchain in example embodiments) (section [0060] and [0247]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the NFT selling process/system of Mallett/Berry/Stephens to include the transferring of payment funds and storing the payment funds, as taught by Dalmia, in order to achieve the predictable result of providing convenience to the user by allowing them to get paid and have access to their funds for selling their digital assets.
Per claim 19, Mallett/Berry/Stephens discloses all the limitations of claim 18 above. Mallet further discloses:
receiving a sale input associated with a sale of a digital asset of the plurality of digital assets (e.g. For example, the hypothetical conceptual digital environment illustrates a sell icon 412. In response to selection of the sell icon 412 by the user, a request to sell one or more owned branded digital items is communicated to the branded digital item system 100) (Section [0140]-[0142]);
causing the digital asset to be transferred to a purchaser digital record associated with a purchaser of the sale (e.g. Once the branded digital item is purchased, the branded digital item blockchain is updated with an updated non-fungible token information and/or an updated branded digital item blockchain. The updated branded digital item blockchain reflects the new ownership of the branded digital item. Then, only the new purchasing user may use that particular branded digital item) (Section [0143]-[0145]).
Although Mallett/Berry/Stephens disclose selling a digital asset and transferring the digital asset to the purchaser, Mallett/Berry do not specifically disclose:
receiving funds associated with the sale;
storing the funds in the plurality of digital assets for administration by the distributor.
However Dalmia, in analogous art of selling NFTs, discloses:
receiving funds associated with the sale (e.g. The cross-channel application may enable traditional digital wallet and/or crypto wallet functionalities such as making payments in traditional currency and/or cryptocurrency and/or managing NFT assets) (Section [0060] and [0247]);
storing the funds in the plurality of digital assets for administration by the distributor (e.g. In example embodiments, the information recorded for a transaction may include identifying information (e.g., a public key) for the providing and receiving parties, an identification of the gaming channel involved in the transaction, any smart contract actions performed as a result of the transfer (e.g., transfer of funds between a digital wallet of a purchaser and a digital wallet of a seller), or other pertinent information relating to the transaction. The transaction can be stored as a block within the blockchain in example embodiments) (section [0060] and [0247]).
The motivation to combine Dalmia with Mallett/Berry/Stephens is disclosed above with respect to claims 5 and 13.
Claims 6-8, 14-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mallett/Berry/Stephens, as applied to claims 3, 12, and 18 above, in further view of US 20230267452 A1 (“Isogawa”).
Per claims 6 and 14, although Mallett/Berry/Stephens disclose identifying a subset of digital assets and identifying potential receivers for the subset of digital assets, Mallett/Berry/Stephens do not specifically disclose:
cause display of a plurality of selectors, wherein each selector is associated with at least one digital asset of the subset of digital assets;
cause display of a plurality of display areas, wherein each display area is associated with at least one potential receiver of the plurality of potential receivers.
However Isogawa, in analogous art of transferring digital assets, discloses:
cause display of a plurality of selectors, wherein each selector is associated with at least one digital asset of the subset of digital assets (e.g. A user may configure the transfer of selected digital assets to selected beneficiary and/or backup wallets in the event of the security breach using the user interface) (Section [0031] and [0038]);
cause display of a plurality of display areas, wherein each display area is associated with at least one potential receiver of the plurality of potential receivers (e.g. A user may configure the transfer of selected digital assets to selected beneficiary and/or backup wallets in the event of the security breach using the user interface) (Section [0031] and [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the digital asset transfer system of Mallett/Berry/Stephens to include a user interface that displays a plurality of digital assets that can be assigned to potential receivers, as taught by Isogawa, in order to achieve the predictable result of increasing the security of the digital assets by allowing the user to automatically transfer the digital assets to other wallets if a certain event takes place.
Per claims 7 and 15, Mallett/Berry/Stephens/Isogawa discloses all the limitations of claims 6 and 14 above. Isogawa further discloses:
receive an input associated with a selector of the plurality of selectors and a receiver of the plurality of potential receivers (e.g. At step 202, the digital asset transfer system 100 may receive, by a user interface, configuration parameters comprising an indication of a user wallet address and an indication of a beneficiary wallet address) (Section [0041]);
cause display of the selector in the display area associated with the receiver (e.g. Based on corresponding wallet address(es) of the connected wallet(s), the digital asset transfer system 100 may provide and/or display one or more notifications at the user interface. If the input wallet address(es) do not correspond to beneficiary and/or backup wallet address(es) included in a smart contract generated by the digital asset transfer system 100, the user interface may provide an indication that the input wallet address(es) are not configured as beneficiary and/or backup wallet address(es), such that individual is not a beneficiary corresponding to the user or the user themself.) (Section [0031], [0036], and [0041]).
The motivation to combine Isogawa with Mallett/Berry/Stephens is disclosed above with reference to claims 6 and 14.
Per claims 8 and 16, Mallett/Berry/Stephens/Isogawa discloses all the limitations of claims 7 and 15 above. Isogawa further discloses:
cause the at least one digital asset associated with the selector to be transferred to a digital record associated with the receiver (e.g. In some embodiments, the smart contract included in the blockchain network may be configured to automatically transfer digital assets in the event of a security breach corresponding to a user of the digital asset transfer system 100. A user may configure the transfer of selected digital assets to selected beneficiary and/or backup wallets in the event of the security breach using the user interface) (Section [0038] and [0042]).
The motivation to combine Isogawa with Mallett/Berry/Stephens is disclosed above with reference to claims 6 and 14.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights