DETAILED ACTION
Examiner's Note: The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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 Arguments
Applicant’s remarks filed on 03/16/2026 have been fully considered.
Regarding claim[s] 1 – 23, under the various obviousness rejections, applicant’s remarks are moot because the new ground of rejection does not rely on all reference[s] applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Therefore, see the office action below.
The examiner will respond to all other remarks that do not concern the prior art rejections, if any, in the office action below.
Applicant’s states on page[s] 2 and 3 of the remarks as filed: “
III. The Claims Are Patentable
Independent claims 1, 9, and 17 recite, in one form or another, receiving a resource exchange request to exchange a first resource associated with a first user for a second resource associated with a second user; prompting the first user to digitally sign a data record using a private key associated with the first user, wherein the data record comprises a smart contract configured to automatically transfer the first resource to the second user upon receipt of the second resource from the second user, wherein the smart contract is dynamically generated based on resource transfer data received from the first user and the second user; detecting that the first user has digitally signed the data record; detecting that the second resource has been received from the second user; and based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user, executing the smart contract to automatically transfer the first resource to the second user, wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user.
Dravneek and Unagami, singularly or in combination with the other cited references, do not teach or suggest the above-presented features of independent claims 1, 9, and 17. Unagami teaches generally of a system for generating smart contracts for programming execution provisions of an incentive based on goal achievement. (See Unagami Abstract). Nelson teaches generally of a tokenization system for generating non-fungible tokens for collectibles, such as sports cards. (See Nelson Abstract).
Specifically, Dravneek and Unagami, singularly or in combination with the other cited references, do not teach or suggest the following recitation of the independent claims: based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user, executing the smart contract to automatically transfer the first resource to the second user, wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user.”
In response the examiner isn’t persuaded, and points to the prior art combination of Unagami in view of Nelson et al. [US PGPUB # 2023/0126016].
Specifically, of Unagami, at Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid [i.e. applicant’s…. prompt the first user to digitally sign a data record using a private key associated with the first user, wherein the data record]
Then further of Unagami, at Figure # 4, and paragraph: 0107, Note that when terminal 120 or terminal 110 is used by a supporter, transaction data generator 1101 generates transaction data including the support information corresponding to the first challenge content (also called “eighth transaction data” hereinafter). Note that the eighth transaction data is an example of fourth transaction data according to the present disclosure. In the present embodiment, when terminal 120 or terminal 110 is used by a supporter, transaction data generator 1101 generates the eighth transaction data including the support information generated by inputter 1102. More specifically, transaction data generator 1101 generates the eighth transaction data including a blockchain address held by the user, the generated support information, an address of the second smart contract, and a signature, for example. Transaction data generator 1101 may further generate the eighth transaction data by providing an identifier. Transaction data generator 1101 generates the signature using a user-specific signature generation key. [i.e. applicant’s…comprises a smart contract configured to automatically transfer the first resource to the second user upon receipt of the second resource from the second user]
Then further of Unagami, at paragraph: 0040, Additionally, the first smart contract may be further programmed to be capable of executing provision of an incentive to a supporter who has registered the support information for the first challenge content when the goal indicated by the first challenge content is achieved [i.e. applicant’s…resource transfer data from the first user]; and when the third transaction data is recorded in the distributed ledger [i.e. applicant’s…resource transfer data from the second user], the first smart contract may provide, to the device used by the user and the different device used by the supporter, the incentive provided when the goal indicated by the first challenge content is achieved. [i.e. applicant’s….. wherein the smart contract is dynamically generated based on resource transfer data received from the first user and the second user].
Unagami at Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid [i.e. applicant’s…. detect that the first user has digitally signed the data record].
Unagami, at Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid [i.e. applicant’s…. and based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user].
Unagami, at paragraph: 0037, Through this, the transaction data generated when the challenge is actually achieved based on data obtained from the user is recorded in the distributed ledger, which enables the smart contract to automatically provide an incentive to the device used by the user [i.e. applicant’s…. execute the smart contract to automatically transfer the first resource to the second user]
Now turning to the prior art of Nelson,. Specifically, at paragraph: 0063, The system may be configured to generate a different contract for each NFT token generated for a collectible. For example, a first entity may have physical ownership of a collectible unit to generate a first NFT token, and the NFT token system 320 may be configured to generate a first contract for the first NFT token to transfer a portion of the transaction price to an address associated with the first entity. Physical ownership of the collectible unit may then be transferred to a second entity, who then generates a second NFT token. The NFT token system 320 may then be configured to generate a second contract for the second NFT token to transfer a portion of the transaction price associated with the second entity. Thereafter, when the first NFT token changes ownership, the first contract may automatically transfer a portion of the transaction price to the first blockchain address associated with the first entity, and when the second NFT token changes ownership, the second contract may automatically transfer a portion of the transaction price to the second blockchain address associated with the second entity. [i.e. applicant’s……wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second use].
This meets applicant’s argument of “…Dravneek and Unagami, singularly or in combination with the other cited references, do not teach or suggest the following recitation of the independent claims: based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user, executing the smart contract to automatically transfer the first resource to the second user, wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user.”
Applicant’s states on page[s] 3 of the remarks as filed: “With respect to the claim recitation of based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user, executing the smart contract to automatically transfer the first resource to the second user, wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user, the Office cites Unagami at Figure 5 and Paragraph [0118] and Nelson at Paragraph [0063] as teaching this recitation. The cited portions of Unagami disclose of a transaction data verifier that verifies received transaction data such as verifying the address, consent information, and signature for a transaction. While the cited portions of Nelson disclose of creating a different contract for each NFT token generated for a collectable, one for physical ownership of a collectable and one for a transfer of ownership of the collectable. The claimed invention, on the other hand, is not creating NFTs for baseball card collection. The cited prior art does not teach or suggest executing smart contract to automatically transfer the first resource to the second user where a non-fungible token is associated with the first resource and transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user.”
In response the examiner isn’t persuaded, and points to the prior art combination of Unagami in view of Nelson et al. [US PGPUB # 2023/0126016].
Specifically, of Unagami, at Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid [i.e. applicant’s…. prompt the first user to digitally sign a data record using a private key associated with the first user, wherein the data record]
Then further of Unagami, at Figure # 4, and paragraph: 0107, Note that when terminal 120 or terminal 110 is used by a supporter, transaction data generator 1101 generates transaction data including the support information corresponding to the first challenge content (also called “eighth transaction data” hereinafter). Note that the eighth transaction data is an example of fourth transaction data according to the present disclosure. In the present embodiment, when terminal 120 or terminal 110 is used by a supporter, transaction data generator 1101 generates the eighth transaction data including the support information generated by inputter 1102. More specifically, transaction data generator 1101 generates the eighth transaction data including a blockchain address held by the user, the generated support information, an address of the second smart contract, and a signature, for example. Transaction data generator 1101 may further generate the eighth transaction data by providing an identifier. Transaction data generator 1101 generates the signature using a user-specific signature generation key. [i.e. applicant’s…comprises a smart contract configured to automatically transfer the first resource to the second user upon receipt of the second resource from the second user]
Then further of Unagami, at paragraph: 0040, Additionally, the first smart contract may be further programmed to be capable of executing provision of an incentive to a supporter who has registered the support information for the first challenge content when the goal indicated by the first challenge content is achieved [i.e. applicant’s…resource transfer data from the first user]; and when the third transaction data is recorded in the distributed ledger [i.e. applicant’s…resource transfer data from the second user], the first smart contract may provide, to the device used by the user and the different device used by the supporter, the incentive provided when the goal indicated by the first challenge content is achieved. [i.e. applicant’s….. wherein the smart contract is dynamically generated based on resource transfer data received from the first user and the second user].
Unagami at Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid [i.e. applicant’s…. detect that the first user has digitally signed the data record].
Unagami, at Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid [i.e. applicant’s…. and based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user].
Unagami, at paragraph: 0037, Through this, the transaction data generated when the challenge is actually achieved based on data obtained from the user is recorded in the distributed ledger, which enables the smart contract to automatically provide an incentive to the device used by the user [i.e. applicant’s…. execute the smart contract to automatically transfer the first resource to the second user]
Now turning to the prior art of Nelson,. Specifically, at paragraph: 0063, The system may be configured to generate a different contract for each NFT token generated for a collectible. For example, a first entity may have physical ownership of a collectible unit to generate a first NFT token, and the NFT token system 320 may be configured to generate a first contract for the first NFT token to transfer a portion of the transaction price to an address associated with the first entity. Physical ownership of the collectible unit may then be transferred to a second entity, who then generates a second NFT token. The NFT token system 320 may then be configured to generate a second contract for the second NFT token to transfer a portion of the transaction price associated with the second entity. Thereafter, when the first NFT token changes ownership, the first contract may automatically transfer a portion of the transaction price to the first blockchain address associated with the first entity, and when the second NFT token changes ownership, the second contract may automatically transfer a portion of the transaction price to the second blockchain address associated with the second entity. [i.e. applicant’s……wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second use].
Applicant’s states on page[s] 3 and 4 of the remarks as filed: “Finally, Applicant question the combination of the primary references with Nelson. The Office states that it would be obvious to combine the teaching of Dravneek as modified and Nelson in order for the distribution or resources between a first user and second user through a resource management server of Dravneek as modified to include authentication operations of the first and second user of Nelson. However, Nelson is in the field of trading collectables, such as baseball cards, which is a completely different field of art that would not have been contemplated by someone ordinary skilled in the art of the claimed invention.
According to MPEP § 2143.01 V-VI:
If proposed modification would render the prior art invention being modified
unsatisfactory for its intended purpose, then there is no suggestion or motivation
to make the proposed modification…..[and] [i]f the proposed modification or
combination of the prior art would change the principle of operation of the prior
art invention being modified, then the teachings of the references are not
sufficient to render the claims prima facie obvious.
According to the court in In re Gordan, 733 F.2d 900, 221 U.S.P.Q. 1125 (Fed. Cir.
1984), if proposed modification would render the prior art invention being modified
unsatisfactory for its intended purpose, then there is no suggestion or motivation to make the proposed modification and the Office has not established a prima facie case of obviousness.
Applicants remind the Office that the ruling in In re Ratti, (270 F.2d 810 (CCPA 1959)) states that where a proposed modification would change the principle of operation of the prior art invention being modified, then the teachings are not sufficient to establish a prima facie case of obviousness. According to the Board in Ex Parte Vito Cellini, (Appeal 2008-4104, BPAI 2008),
"a change in the basic principles" refers to change that is fundamental in scope, so as to relate to scientific or technical principles of operation. Interchanging the various NFT components of a collectable tokenization system with those of a system for identification and integration of like resources and a system for generating smart contracts for programming execution provisions of an incentive based on goal achievement does not establish a prima facie case of obviousness because the combination of the references fundamentally changes the "basic principles" under
which the prior art was designed to operate. Clearly there is no guidance for picking and choosing from either reference to design Applicants claimed invention.
As such, as described in the cited case law above, the fact that the combination of the references results in a change of the principle operation of the prior art is evidence that one of ordinary skill in the art would not have arrived at the present invention by combining the references, and thus there is no motivation to combine the references.”
In response the examiner isn’t persuaded, and points out that the operation of Dravneek would benefit from the authentication operations of Nelson. Specifically, that the first user, second user authenticate themselves before transfer/access to resources to the resource management server. NO change in operation of Dravneek.
Applicant’s states on page[s] 4 and 5 of the remarks as filed: “Furthermore, regarding a rejection based on simple substitution grounds, the Supreme Court has stated that it must be asked whether an improvement is more than the predictable use of prior art elements according to their established functions. KSR International Co. V. Teleflex Inc., 550 U.S. 398, 416-417 (2007). Moreover, a combination is only obvious where all of the elements are old and each perform the same function it had been known to perform. Id. at 416- 417. Applicant submits that substitution of a collectable NFT system with a system for generating smart contracts for programming execution provisions of an incentive based on goal achievement would not have expected results.
In light of the above, Applicant respectfully submits that independent claims 1, 9, and 17 as amended, and the claims depending therefrom are patentable over Dravneek and Unagami, singularly or in combination with the other cited references. Reconsideration and allowance of all pending claims are therefore respectfully requested.”
In response the examiner isn’t persuaded, and points out that applicant’s claim language is intentionally broadly drawn [emphasis add….] and thus would be applicable to collectable NFT systems and would produce expected results. Applicant’s claimed invention is broadly for use with any type of data that can be use with NFT/smart contracts/blockchain systems. Applicant is arguing specifically, but claiming the invention in too broad of a manner.
Response to Amendment
Status of the instant application:
Regarding claim[s] 1 – 4, 6 – 12, 14 – 20, 22, 23 are pending in the instant application.
Regarding claim[s] 5, 13, 21, under the various obviousness rejections, applicant’s cancellation of the claims is noted, therefore, the rejections are withdrawn.
Regarding claim[s] 1 – 4, 6 – 12, 14 – 20, 22, 23, under the various obviousness rejections, applicant’s claim amendments have been considered. Therefore, the rejections are withdrawn. However, there are new prior art rejections issued on the claims to address the claim amendments in the office action below.
Specification
Applicant’s amendments to the paragraph: 0089 of the specification as filed is noted and accepted.
Double Patenting
Regarding claim[s] 1 - 7, 9 - 15, 17 - 22 that were rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1 - 20 of U.S. Patent No. 12107967, applicant’s e-terminal disclaimer was filed and approved on 03/16/2026, therefore, the rejections are withdrawn.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim[s] 1, 2, 4, 6 – 10, 12, 14 – 18, 20, 22, 23 is/are rejected under 35 U.S.C. 103 as being obvious over Dravneek et al. [US PGPUB # 2018/0232682] in view of Unagami et al. [US PGPUB # 2023/0306427], further in view of Nelson et al. [US PGPUB # 2023/0126016]
The applied reference has a common assignee with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2).
This rejection under 35 U.S.C. 103 might be overcome by:
(1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C.102(b)(2)(A);
(2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B); or
(3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement. See generally MPEP § 717.02.
As per claim 1. Dravneek does teach a system for authenticating peer-to-peer resource exchanges using non-fungible tokens [paragraph: 0009, In some embodiments, distributing the resource transfer tasks to the subset of users of the integrated resource cluster further comprises: identifying one or more resources and attributes of the first user of the subset of users; matching the one or more resources and attributes of the first user to at least one of the resource transfer tasks; and assigning the at least one of the resource transfer tasks to the first user.], the system comprising:
a memory device with computer-readable program code stored thereon [paragraph: 0068, It will also be understood that one or more computer-executable program code portions for carrying out the specialized operations of the present invention may be required on the specialized computer include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.];
a communication device [Figure # 1, resource management server - 101, Figure # 2, resource management server application - 150]; and
a processing device operatively coupled to the memory device and the communication device, wherein the processing device is configured to execute the computer-readable program code [paragraph: 0066, As the phrase is used herein, a processor may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more general-purpose circuits perform the function by executing particular computer-executable program code embodied in computer-readable medium, and/or by having one or more application-specific circuits perform the function.] to:
receive a resource exchange request to exchange a first resource associated with a first user for a second resource associated with a second user [paragraph: 0005, lines 18 – 21, receive a resource exchange request from a requesting user];
detect that the second resource has been received from the second user [paragraph: 0005, lines 19 – 21, distribute resource transfer tasks to the subset of users of the integrated resource cluster to dispense an outbound resource to the requesting user].
Dravneek does not clearly teach the claim limitations of: “prompt the first user to digitally sign a data record using a private key associated with the first user, wherein the data record comprises a smart contract configured to automatically transfer the first resource to the second user upon receipt of the second resource from the second user, wherein the smart contract is dynamically generated based on resource transfer data received from the first user and the second user;
detect that the first user has digitally signed the data record; and
based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user, execute the smart contract to automatically transfer the first resource to the second user.”
However, Unagami does teach the claim limitations of: “prompt the first user to digitally sign a data record using a private key associated with the first user, wherein the data record [Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid.] comprises a smart contract configured to automatically transfer the first resource to the second user upon receipt of the second resource from the second user [Figure # 4, and paragraph: 0107, Note that when terminal 120 or terminal 110 is used by a supporter, transaction data generator 1101 generates transaction data including the support information corresponding to the first challenge content (also called “eighth transaction data” hereinafter). Note that the eighth transaction data is an example of fourth transaction data according to the present disclosure. In the present embodiment, when terminal 120 or terminal 110 is used by a supporter, transaction data generator 1101 generates the eighth transaction data including the support information generated by inputter 1102. More specifically, transaction data generator 1101 generates the eighth transaction data including a blockchain address held by the user, the generated support information, an address of the second smart contract, and a signature, for example. Transaction data generator 1101 may further generate the eighth transaction data by providing an identifier. Transaction data generator 1101 generates the signature using a user-specific signature generation key.]], wherein the smart contract is dynamically generated based on resource transfer data received from the first user and the second user [paragraph: 0040, Additionally, the first smart contract may be further programmed to be capable of executing provision of an incentive to a supporter who has registered the support information for the first challenge content when the goal indicated by the first challenge content is achieved [i.e. applicant’s…resource transfer data from the first user]; and when the third transaction data is recorded in the distributed ledger [i.e. applicant’s…resource transfer data from the second user], the first smart contract may provide, to the device used by the user and the different device used by the supporter, the incentive provided when the goal indicated by the first challenge content is achieved.];
detect that the first user has digitally signed the data record [Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid]; and
based on detecting that the first user has digitally signed the data record and that the second resource has been received from the second user [Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid], execute the smart contract to automatically transfer the first resource to the second user [paragraph: 0037, Through this, the transaction data generated when the challenge is actually achieved based on data obtained from the user is recorded in the distributed ledger, which enables the smart contract to automatically provide an incentive to the device used by the user.].”
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Dravneek and Unagami in order for the distribution of resources between a first user and a second user thru a resource management server of Dravneek to include securing the requested resource of the first and second user of Unagami. This would allow for the requested resource to be secure while in transit between the first and second user. See paragraph: 0087 of Unagami.
Dravneek and Unagami do not clearly teach the claim limitation of: “…wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user.”
However, Nelson does teach the claim limitation of: “…wherein a non-fungible token is associated with the first resource, wherein automatically transferring the first resource to the second resource comprises processing a transaction within the data record to change ownership of the non-fungible token from a distributed register address associated with the first user to a distributed register address associated with the second user [paragraph: 0063, The system may be configured to generate a different contract for each NFT token generated for a collectible. For example, a first entity may have physical ownership of a collectible unit to generate a first NFT token, and the NFT token system 320 may be configured to generate a first contract for the first NFT token to transfer a portion of the transaction price to an address associated with the first entity. Physical ownership of the collectible unit may then be transferred to a second entity, who then generates a second NFT token. The NFT token system 320 may then be configured to generate a second contract for the second NFT token to transfer a portion of the transaction price associated with the second entity. Thereafter, when the first NFT token changes ownership, the first contract may automatically transfer a portion of the transaction price to the first blockchain address associated with the first entity, and when the second NFT token changes ownership, the second contract may automatically transfer a portion of the transaction price to the second blockchain address associated with the second entity.].”
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Dravneek as modified and Nelson in order for the distribution of resources between a first user and a second user thru a resource management server of Dravneek as modified to include authentication operations of the first and second user of Nelson. This would allow for the resource to be requested and received by an authorized peer. See paragraph: 0027 of Nelson.
As per claim 2. Dravneek does teach the system according to claim 1, wherein the resource exchange request comprises resource exchange data, wherein the resource exchange data identifies the first resource, the second resource, the first user, and the second user [Dravneek, paragraph: 0005, lines 1 – 18, Embodiments of the present invention address these and/or other needs by providing a system for identification and integration of like resources and configuring resources for common use. The system typically includes a processor, a memory, and a communication device in communication with a plurality of user devices of a plurality of users over a network, the plurality of user devices comprising a first user device of a first user and a second user device of a second user. The system also typically includes a resource management module stored in the memory, executable by the processor. In one embodiment, the resource management module is configured to: analyze resources and/or attributes of the plurality of users to identify a subset of users having complimentary resources and/or attributes, the subset of users comprising the first user and the second user; generate an integrated resource cluster comprising the subset of users having complimentary resources and/or attributes].
As per claim 4. Dravneek does teach the system according to claim 1, wherein the resource exchange request is received from a user computing device associated with the first user over a wireless network connection [Dravneek, paragraph: 0020, “User device” as used herein may refer to a computing device used by the user to access the system through an online portal. The user device may include a processor, a non-transitory storage medium, a communications device, and a display. The system may support user logins and inputs from any combination of disparate devices. Accordingly, the user device may be a portable electronic device such as a smartphone, tablet, or laptop, or the user device may be a stationary unit such as a personal desktop computer or a networked terminal within an entity's premises. Where further of Dravneek, at paragraph: 0034, lines 1 – 16, FIG. 1 is a block diagram illustrating an operating environment 001, in accordance with one embodiment of the present invention. The operating environment may include a plurality of user devices 100 in operative communication with a resource management server 101 over a network 180. The network 180 may also be a global area network (GAN), such as the Internet, a wide area network (WAN), a local area network (LAN), or any other type of network or combination of networks. The network 180 may provide for wireline, wireless, or a combination wireline and wireless communication between devices on the network 180. The user device may be a mobile device such as a smartphone, tablet, or laptop, a personal computing device such as a desktop computer, smart device, single board computer, or a device owned and operated by an entity, such as a computer system terminal located on the entity's premises.].
As per claim 6. Dravneek as modified does teach the system according to claim 1, wherein the private key is stored within a user computing device associated with the first user, wherein detecting that the first user has digitally signed the data record comprises detecting that the user computing device has digitally signed the data record using the private key [Unagami, Figure # 5, and paragraph: 0118, Transaction data verifier 211 verifies received transaction data. Specifically, upon receiving transaction data from residence 100, a device such as terminal 110 or terminal 120, detection server 300, or service server 400, transaction data verifier 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including consent information, transaction data verifier 211 verifies whether the address, consent information, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, transaction data verifier 211 may verify whether the address, information indicating the data, and signature included in the transaction data are valid.].
As per claim 7. Dravneek as modified does teach the system according to claim 1, wherein the smart contract causes the processing device to transmit the data record to a plurality of distributed register nodes to be appended to a distributed register hosted on the distributed register nodes [Unagami, paragraph: 0032, lines 1 – 22, A control method according to one aspect of the present disclosure is a control method for a data distribution system, the data distribution system including a plurality of authentication servers, each having a distributed ledger, and a service server. The control method includes: generating, by the service server, challenge content in which an incentive is provided to a user when the user achieves a goal which can be determined based on data of the user and which the user is challenging; generating, by the service server, a first smart contract programmed to be capable of executing provision of the incentive to the user when the goal indicated by the challenge content generated is achieved; generating first transaction data including the first smart contract and transmitting the first transaction data to a first authentication server among the plurality of authentication servers, by the service server; recording the first transaction data in the distributed ledger of the first authentication server and running the first smart contract by the first authentication server executing a consensus algorithm for agreeing on a validity of the first transaction data with a plurality of second authentication servers, among the plurality of authentication servers, that are different from the first authentication server].
As per claim 8. Dravneek does teach the system according to claim 1, wherein the resource transfer data comprises a second resource type, second resource amount, and a time limit [Dravneek, paragraph: 0022, In some embodiments, the information may include an offer to sell goods or services. In other embodiments, the information may include a request for goods or services. The information may further include location data, pricing data, or time data. The information may further include an identity of a user or various characteristics or statistics of the user.].
As per computer program product claim 9 that includes the same or similar claim limitations as system claim 1 and is similarly rejected.
***The examiner points out that applicant’s recited: “computer program product,” “computer-readable program code” and “non – transitory computer readable medium,” is taught by Dravneek at paragraphs: 0065 – 0068.
As per computer program product claim 10 that includes the same or similar claim limitations as system claim 2, and is similarly rejected.
As per computer program product claim 12 that includes the same or similar claim limitations as system claim 4, and is similarly rejected.
As per computer program product claim 14 that includes the same or similar claim limitations as system claim 6, and is similarly rejected.
As per computer program product claim 15 that includes the same or similar claim limitations as system claim 7, and is similarly rejected.
As per computer program product claim 16 that includes the same or similar claim limitations as system claim 8, and is similarly rejected.
As per computer – implemented method claim 17, that includes the same or similar claim limitations as system claim # 1, and is similarly rejected.
As per computer – implemented method claim 18, that includes the same or similar claim limitations as system claim # 2, and is similarly rejected.
As per computer – implemented method claim 20, that includes the same or similar claim limitations as system claim # 4, and is similarly rejected.
As per computer – implemented method claim 22, that includes the same or similar claim limitations as system claim # 6, and is similarly rejected.
As per computer – implemented method claim 23, that includes the same or similar claim limitations as system claim # 8, and is similarly rejected.
Claim(s) 3, 11, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dravneek et al. [US PGPUB # 2018/0232682] in view of Unagami et al. [US PGPUB # 2023/0306427] and Nelson et al. [US PGPUB # 2023/0126016] as applied to claim[s] 2 above, and further in view of Becker et al. [US PAT # 11363069]
As per claim 3. Dravneek and Unagami and Nelson do teach what is taught in the rejection of claim 2 above.
Dravneek and Unagami and Nelson do not clearly teach the system according to claim 2, wherein the computer-readable program code further causes the processing device to:
prompt the first user and the second user to provide authentication credentials;
receive the authentication credentials from the first user and the second user;
compare the authentication credentials with the resource exchange data; and
authenticate the first user and the second user based on comparing the authentication credentials with the resource exchange data.
However, Becker does teach the system according to claim 2, wherein the computer-readable program code further causes the processing device to:
prompt the first user and the second user to provide authentication credentials [col. 9, lines 63 – 67 and col. 10, lines 1 – 15];
receive the authentication credentials from the first user and the second user [col. 9, lines 63 – 67 and col. 10, lines 1 – 15];
compare the authentication credentials with the resource exchange data [col. 9, lines 63 – 67 and col. 10, lines 1 – 15]; and
authenticate the first user and the second user based on comparing the authentication credentials with the resource exchange data [Figure # 1A and col. 9, lines 63 – 67 and col. 10, lines 1 – 15, Based on the user credentials provided by first user device 104 and/or second user device 106, validation circuit 118 can compare values of the provided user credentials to user credentials stored in a user information database 119 of memory 116. User information database 119 can store information associated with users that can be referenced for verification of user credentials. For example, user information database 119 may store information such as user login information (e.g., usernames and passwords), user biometrics, device identifiers, security authorization levels of users, etc. Validation circuit 118 can compare the information stored in user information database 119 to the provided user credentials to determine if any discrepancies are present. In other words, validation circuit 118 can determine if any of the provided user credentials are inconsistent with the information stored in user information database 119. If the provided user credentials match the information stored in user information database 119, a determination can be made that users associated with a request for a multiple custody linkage do not pose an immediate threat to resource 107].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Dravneek as modified and Becker in order for the distribution of resources between a first user and a second user thru a resource management server of Dravneek as modified to include securing the requested resource of the first and second user of Becker. This would allow for preventing the compromise of the distributed resource data between the first user second user. See col. 9, lines 10 – 12 of Becker.
As per computer program product claim 11 that includes the same or similar claim limitations as system claim 3, and is similarly rejected.
As per computer – implemented method claim 19, that includes the same or similar claim limitations as system claim # 3, and is similarly rejected.
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 concerning this communication or earlier communications from the examiner should be directed to DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm.
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, Kambiz Zand can be reached at 571- 272- 3811. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434
Prosecution Insights