DETAILED ACTION
The present application, filed on 10/2/2025 is being examined under the AIA first inventor to file provisions.
The following is a non-final First Office Action on the Merits. Claims 21-40 are pending and have been considered below.
Priority
This application is a CON of 17/942,868 09/12/2022, which is a CON of 16/544,770 08/19/2019 PAT 11,443,317, which claims benefit of 62/782,341 12/19/2018
The priority is acknowledged.
Double Patenting Rejection
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time wise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428,46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046,29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel/,422 F.2d 438,164 USPQ 619 (CCPA 1970); and, In re Thorington, 418 F.2d 528,163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
The claims of the instant application are rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims of patent US 12,361,488. The conflicting claims are nearly identical, with the US 12,361,488 patent claims being narrower, which makes the two sets of claims not patentably distinct from each other, as shown by the claim-by-claim comparison in the table here below.
Instant Application
Language from US 11,443,317
Claim 21.
A method of tracing flow of tagged funds on a blockchain, the method comprising:
obtaining, by a blockchain network participant, at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
receiving, at a transmitter, an identifier of funds on the blockchain ledger
replaying the identifier of funds against the global transaction history to yield a spending history of the identifier of funds;
receiving, at the transmitter, a tagging profile, the tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith;
replaying the tagging profile against the global transaction history to yield a propagation profile, the propagation profile including transaction outputs and weight values associated therewith derived from the tagging profile;
determining whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile;
blocking a requested transaction if the intersection condition is satisfied; and
issuing a new transaction to return funds associated with the requested transaction to a sender of funds upon the intersection condition being satisfied.
Claim 1.
A system for tracing flow of tagged funds on a blockchain, the system comprising:
a blockchain network participant that operates as a full node in a network of the blockchain, the blockchain network participant being configured to
obtain at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
a transmitter at which to
receive an identifier of funds on the blockchain ledger and a tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith pursuant to a request from the blockchain network participant,
wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of taqqed transaction outputs;
a transaction replayer that is representative of a first application program that is executable by the system, the transaction replayer being configured to
replay the tagging profile against the global transaction history to yield a spending history of the identifier of funds, and
replay the tagging profile against the global transaction history to yield a propagation profile;
a funds weighting evaluator that is representative of a second application program that is executable by the system, the funds weiqhtinq evaluator being configured to
determine whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile; and
a payment gatekeeper that is representative of a third application program that is executable by the system, the payment gatekeeper being configured to
block a requested transaction if the intersection condition is satisfied and issue a new transaction so as to return funds associated with the requested transaction.
Claim 22. The method of claim 21, further comprises
transmitting an alert notification to a network participant if the intersection condition is satisfied.
Claim 2. The system of claim 1,
wherein the transmitter sends an alert notification to a market participant if the intersection condition is satisfied.
Claim 23. The method of claim 22,
wherein the tagging profile is based at least in part on funds associated with the network participant and the alert notification indicates an economic interaction between funds in the spending history of the identifier of funds with the network participant.
Claim 4. The system of claim 1,
wherein the tagging profile is based at least in part on funds associated with a market participant and the alert notification indicates an economic interaction between funds in the spending history of the identifier of funds with the market participant.
Claim 24. The method of claim 21,
wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of tagged transaction outputs.
Claim 12. A system for tracing flow of tagged funds on a blockchain, the system comprising:
a blockchain network participant that operates as a client able to
request and search a copy of the blockchain,
the blockchain network participant being configured to
obtain at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
a transmitter at which to
receive an identifier of funds on the blockchain ledger and a tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith pursuant to a request from the blockchain network participant,
wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of tagged transaction outputs;
a first application program that, when executed,
replays the tagging profile against the global transaction history to yield a spending history of the identifier of funds and a propagation profile;
a second application program that, when executed,
determines whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile; and
a third application program that, when executed,
blocks a requested transaction if the intersection condition is satisfied, and issues a new transaction so as to return funds associated with the requested transaction.
Claim 25, Claim 37. The method of claim 21 and claim 33,
wherein the tagging profile is based at least in part on an identification of stolen funds.
Claim 3. The system of claim 1,
wherein the tagging profile is based at least in part on an identification of stolen funds.
Claim 26. The method of claim 21,
wherein the identifier of funds and the spending history are equivalent.
Claim 6. The system of claim 1,
wherein the identifier of funds and the spending history are equivalent.
Claim 27, Claim 35. The method of claim 21 and claim 33,
wherein determining whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile includes
determining if a weight value of a transaction output in the spending history of the identifier of funds intersects with a transaction output in the propagation profile having a weight value above a trigger threshold.
Claim 7. The system of claim 1,
wherein the intersection condition is satisfied only if a weight value of a transaction output in the spending history of the identifier of funds intersects with a transaction output in the propagation profile having a weight value above a trigger threshold.
Claim 28. The method of claim 21,
wherein replaying the tagging profile against the global transaction history includes
assigning an equal weighting value to any outputs from a transaction in the global transaction history, wherein at least one input to the transaction is associated with a weighting
Claim 8. The system of claim 1,
wherein the transaction replayer
assigns an equal weighting value to any outputs from a transaction in the global transaction history
wherein at least one input to the transaction is associated with a weighting value.
Claim 29, Claim 36. The method of claim 21 and claim 33
wherein the tagging profile includes a blacklist of transaction outputs.
Claim 9. The system of claim 1,
wherein the tagging profile includes a blacklist of transaction outputs.
Claim 30. The method of claim 21,
wherein the identifier of funds includes a set of transaction outputs derived from an extended public key (xpub).
Claim 10. The system of claim 1,
wherein the identifier of funds includes a set of transaction outputs derived from an extended public key (xpub).
Claim 31. The method of claim 21,
wherein the identifier of funds includes a block height on the blockchain.
Claim 11. The system of claim 1,
wherein the identifier of funds includes a block height on the blockchain.
Claim 32, Claim 39. The method of claim 21 and claim 33,
wherein determining whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile includes
searching for transaction outputs that appear in both the spending history of the identifier of funds and the propagation profile.
Claim 12.
A system for tracing flow of tagged funds on a blockchain, the system comprising:
a blockchain network participant that operates as a client able to
request and search a copy of the blockchain,
the blockchain network participant being configured to
obtain at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
a transmitter at which to
receive an identifier of funds on the blockchain ledger and a tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith pursuant to a request from the blockchain network participant,
wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of tagged transaction outputs;
a first application program that, when executed,
replays the tagging profile against the global transaction history to yield a spending history of the identifier of funds and a propagation profile;
a second application program that, when executed,
determines whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile; and
a third application program that, when executed,
blocks a requested transaction if the intersection condition is satisfied, and issues a new transaction so as to return funds associated with the requested transaction.
Claim 33. A method of tracing flow of tagged funds on a blockchain, the method comprising:
obtaining, by a blockchain network participant, at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
receiving, at a transmitter, an identifier of funds on the blockchain ledger and a tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith pursuant to a request from the blockchain network participant, wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of tagged transaction outputs;
ascertaining a spending history of the identifier of funds and a propagation profile;
determining whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile;
blocking a requested transaction if the intersection condition is satisfied; and
issuing a new transaction to return funds associated with the requested transaction upon the intersection condition being satisfied.
Claim 12.
A system for tracing flow of tagged funds on a blockchain, the system comprising:
a blockchain network participant that operates as a client able to
request and search a copy of the blockchain,
the blockchain network participant being configured to
obtain at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
a transmitter at which to
receive an identifier of funds on the blockchain ledger and a tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith pursuant to a request from the blockchain network participant,
wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of tagged transaction outputs;
a first application program that, when executed,
replays the tagging profile against the global transaction history to yield a spending history of the identifier of funds and a propagation profile;
a second application program that, when executed,
determines whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile; and
a third application program that, when executed,
blocks a requested transaction if the intersection condition is satisfied, and issues a new transaction so as to return funds associated with the requested transaction.
Claim 34. The method of claim 33,
wherein ascertaining the spending history of the identifier of funds and the propagation profile includes
replaying the tagging profile against the global transaction history to yield the propagation profile and
replaying the identifier of funds against the global transaction history to yield the spending history of the identifier of funds.
Claim 1.
A system for tracing flow of tagged funds on a blockchain, the system comprising:
a blockchain network participant that operates as a full node in a network of the blockchain, the blockchain network participant being configured to
obtain at least a portion of a blockchain ledger representing a global transaction history of funds on the blockchain;
a transmitter at which to
receive an identifier of funds on the blockchain ledger and a tagging profile including a set of tagged transaction outputs on the blockchain ledger and weight values associated therewith pursuant to a request from the blockchain network participant,
wherein each of the weight values is indicative of an amount of the funds included in a corresponding one of the set of taqqed transaction outputs;
a transaction replayer that is representative of a first application program that is executable by the system, the transaction replayer being configured to
replay the tagging profile against the global transaction history to yield a spending history of the identifier of funds, and
replay the tagging profile against the global transaction history to yield a propagation profile;
a funds weighting evaluator that is representative of a second application program that is executable by the system, the funds weiqhtinq evaluator being configured to
determine whether the spending history of the identifier of funds satisfies an intersection condition with respect to the propagation profile; and
a payment gatekeeper that is representative of a third application program that is executable by the system, the payment gatekeeper being configured to
block a requested transaction if the intersection condition is satisfied and issue a new transaction so as to return funds associated with the requested transaction.
Claim 40. The method of claim 33,
wherein the blockchain network participant includes a node on the blockchain network and the global transaction history of funds on the blockchain is local to the node.
5. The system of claim 1,
wherein the blockchain network participant includes a node on the blockchain network and the global transaction history of funds on the blockchain is local to the node.
This is a non-provisional obviousness-type double patenting rejection because the conflicting claims have been patented in fact.
Examiner Remarks
The comprehensive search, included domestic and foreign patents search, “more like this” search, similarity search and ip.com NPL search (all attached to this office action). It yielded no relevant prior art.
Based on the eligibility results of the analysis for parent US 12,361,488, it is concluded that the set of claims of the instant application is eligible as well.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20230052242 A1 RAMANATHAN; Ramanathan et al. APPARATUSES, COMPUTER-IMPLEMENTED METHODS, AND COMPUTER PROGRAM PRODUCTS FOR ALTERNATIVE PAYMENT TRANSACTIONS A method, apparatus, and computer program product for alternative payment transactions are provided. An example computer-implemented method includes receiving a first request for payment associated with a first transaction that includes one or more first payment parameters and generating an initial payment responsive to the first request for payment based upon the first payment parameters. The computer-implemented method also includes determining first alternative payment data based upon first payment attribute data of a first user associated with the first transaction. The first payment attribute data is associated with non-cash liquid assets of the first user. The computer-implemented method additionally includes modifying the initial payment based upon the first alternative payment data and effectuating the modified initial payment from a first user account associated with the first user in satisfaction of the first transaction. The computer-implemented method may subsequently include modifying the first payment attribute data of the first user.
US 20230005027 A1 TIETZEN; Terrance Patrick et al. DETECTING AND TRIGGERING A PREVENTATIVE OPERATION MODE CHANGE IN A LOYALTY PROGRAM Potential impending disaster information is received for a potential impending disaster including an event impact value for an extent of the potential impending disaster, a response value for a relief effort for the potential impending disaster, and a donation impact value for effectiveness of the response value. A detection is made, using an artificial intelligence engine, of the response value, of the donation impact value, and of at least one redirection trigger from the potential impending disaster information. Upon the detection of the at least one redirection trigger, a redirection mode is configured. Data is received for a transaction between a customer and a merchant. A determination is made from information from the transaction of a donation amount and a location associated with the transaction. When configured to operate in the redirection mode, generating signals to cause accrual of: at least a portion of the donation amount to a redirection account based on the location associated with the transaction, and any remaining portion of the donation amount to one or more defined donation accounts based on charity catchment area parameters. After the donation amount and the location associated with the transaction are determined, data fields derived from the transaction are received that include: first data for the transaction defined using a first merchant account, and second, different data for the same transaction defined using a second merchant account. Information is transmitted to facilitate a donation of the donation amount to a charity.
US 20220051219 A1 SELLS; Patrick et al. CRYPTOCURRENCY PAYMENT AND DISTRIBUTION PLATFORM In embodiments of the present disclosure, a third-party cryptocurrency payment and distribution platform is provided that may facilitate the orchestration of fiat-to-cryptocurrency and cryptocurrency-to-fiat currency exchanges without necessitating a bank's direct involvement in the cryptocurrency transactions, but rather enables banks and other entities to provide access to cryptocurrency services for their customers through an external entity.
US 20220188925 A1 Blaikie, III; Alfred Blair et al. Method and System for Data Futures Platform A system, method, and platform for performing transactions for data. The data is grouped. The data is associated with a platform. Transaction information for the data is received. One or more transactions are performed based on the transaction information. The verification of the transaction is provided.
US 20220051259 A1 BENKREIRA; Abdelkader et al. SYSTEM, METHOD, AND COMPUTER-ACCESSIBLE MEDIUM FOR GEO-FENCED ZONES Exemplary systems, methods, and computer-accessible mediums can include, for example, receiving a first location of a user(s) and time information associated with that location, initiating a record for the user(s) based on the location and the time information, receiving a second location of the user(s), where the second location can be in a second bounded area, storing in record, a transaction(s) associated with the user(s) based on the second location, and automatically initiating a single payment for the transaction(s) when the user(s) leaves the first location.
US 20220148004 A1 Howell; Sosh A. SYSTEMS AND METHODS FOR PREDICTING ON-FILE PAYMENT CREDENTIALS Disclosed herein are systems and methods for predicting on-file payment credentials. The methods can include obtaining, from a financial institution, transaction data comprising one or more transactions conducted at one or more merchants. For each respective merchant of the one or more merchants, the methods can include parsing each of the one or more transactions at the respective merchant to create a merchant profile for the respective merchant, the merchant profile comprising merchant behavior data for the respective merchant. The methods can determine a likelihood of a respective associated merchant having the payment credential information on file by calculating a score for the merchant based on the merchant profile. The score can represent that the merchant profile is indicative of the associated merchant having the payment credential information stored on file.
US 20230067467 A1 Bantanur; Vijay Sahebgouda et al. AUTOMATED MULTI-PARTY TRANSACTION DECISIONING SYSTEM Methods, systems, devices, and computer-readable media for a multi-party transaction decisioning system are provided. The system may analyze a purchase transaction associated with a first user and may identify that the transaction is associated with more than one party based on determining that an amount of the transaction is atypical for the first user. The system may identify a party associated with the multi-party transaction based on analyzing data associated with the first user. The system may generate a delegation request for a portion of the amount of the multi-party transaction to be delegated to the identified party and may transmit the delegation request to the identified party. Subsequently, the system may receive a payment transaction from the identified party, and the system may identify that the payment transaction is associated with the previously transmitted delegation request.
US 20220301013 A1 ORTIZ; Edison U. et al. SYSTEMS AND METHODS FOR ESTABLISHING DATA LINKAGES Systems and methods for establishing data linkages are described in various embodiments. A system architecture is described which provides a data processing orchestrator device or service which securely interoperates with data sets at various points in time associated with a set of interactions a user may have with computer systems. The data sets are obtained from different data repositories, and are combined together for analysis such that a first data set representing intents (e.g., web search/browse history) can be combined together with a second data set representing outcomes (e.g., purchase transaction history, web site shopping carts).
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Hayes can be reached at 571.272.6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3697
Prosecution Insights