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 .
DETAILED ACTION
The present office action is responsive to communications received on 04/11/2024.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 07/22/2024 and 09/17/2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Status of Claims
Claims 1-20 are pending.
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 are rejected under 35 U.S.C. 101 for reciting software per se.
With respect to claim 1 and 10 the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because it recites a system, network and node and upon review of the application there is no definition for a system, network or node as only hardware and based on broadest reasonable interpretation it could be virtual or software, therefore failing step 1 of the 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”).
With respect to dependent claims 2-9 and 11-19 do not cure the deficiencies of independent claim 1 and 10 and are directed to non-statutory subject matter and are rejected under 35 U.S.C. 101.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sathe et al. (US 20240062280 A1) hereinafter referred to as Sathe.
With respect to claim 1, Sathe discloses: A system comprising: a signaling log collector of a first party in communication with a network, the signaling log collector being configured to: (Sathe ¶69 teaches, Fig. 2, of a system comprising different participants and each comprises a separate memory [log collector] and blockchain node 204. “the blockchain (generally 204) established a blockchain based ledger and shares data 204A between the participants. Blockchain 204 utilizes marketplace smart contracts 204B for respective participants”. Network illustrated in Fig. 1).
identify a transaction to be validated, the transaction being between second and third parties on the network; (Sathe ¶21 summarizes the prior art and teaches that the control cloud agent would verify DER device to enroll as part of tender using the device data [credential] which is used to determine if the device meets the requirements for bidding. Additionally, Sathe in the detailed description ¶69 teaches, Fig. 2, explain participants each comprising blockchain node sharing ledger and bid [tender] for transaction between parties. So, if for example looking at Fig. 2 the platform operator receiving the contract shared by the market operator which also pertains to two other different blockchain nodes as part of the bidding [tender] process).
in response to the identifying, collect signaling data associated with the transaction from the network; obtain one or more credentials from the signaling data; (Sathe ¶21 and 29 disclose in response to identifying a DER device more credentials information is collected from metering agent to verify whether the DER device is eligible for participation in the bidding process).
and send the one or more credentials to a blockchain node; (Sathe ¶21, and explained in more details in Sathe ¶ 69, disclose the data which implicitly comprises the credentials is recorded on blockchain. The blockchain data 204 is shared among all parties illustrated by the data sharing arrows in Sathe Fig. 2).
and the blockchain node, wherein the blockchain node is in communication with the network, the signaling log collector, and a blockchain and configured to: generate a smart contract tender for the transaction, the smart contract tender including at least one primary credential defining validation process participation requirements; (Sathe ¶21 discloses computing device, which implicitly comprises storage/memory/log receiving the bid [tender] “the quote bidder information including DER device information [at least one primary credentials] with which to confirm [match] the DER device; and communicate with a control agent for the DER device to verify eligibility to enrol.” The data recorded on blockchain which is shared between parties as explained in Sathe ¶69 and illustrated in Fig. 2 data flow arrows).
and transmit the smart contract tender to at least one additional blockchain node connected to the network. (Sathe ¶32 teaches that tender quotes from bidders are accepted [acknowledgement] and recorded, all recording is done on the blockchain and shared between parties as illustrated in Sathe Fig. 2 and explained in Sathe ¶69).
With respect to claim 2, Sathe discloses: The system of claim 1, wherein the signaling log collector and the blockchain node are installed on a cloud. (Sathe ¶69 discloses the interaction with data can be “web-based” or “cloud-based” 208 wherein the components shown in Fig. 2 all use cloud/web-based technology as illustrated).
With respect to claim 3, Sathe discloses: The system of claim 1, wherein the signaling log collector and the blockchain node are installed at a premises associated with an intermediary to the transaction on the network. (Sathe Fig. 2 illustrates the memory and blockchain are installed on intermediary entities to the transaction process on the illustrated cloud-based network, see Sathe ¶69).
With respect to claim 4, Sathe discloses: The system of claim 1, wherein generating the smart contract tender comprises including information from a digital wallet associated with the first party. (Sathe ¶223 “Participants have respective computing devices (not shown) to interact with the credits market platform via the participant interface. Such devices can store or have access to blockchain wallets or other manners of storing blockchain key information [credentials] for managing accounts [first party or any number of parties] and facilitating transaction signing.”).
With respect to claim 5, Sathe discloses: The system of claim 1, wherein generating the contract tender comprises including information from a hierarchical digital identity associated with the first party. (Sathe ¶87 “Platform 102 queries the blockchain to retrieve the latest quote information (e.g. with aggregated [hierarchical] tender values). Platform 102 is enabled to update to the contract counterparty 108A dashboard including the updated quote, and the new tender details.” The tender values and contract comprises credentials of the involved parties as understood by the examiner from reading the prior art).
With respect to claim 6, Sathe discloses: The system of claim 1, wherein the blockchain node is further configured to read data from the blockchain and thereby determine that the at least one additional blockchain node has validated the transaction. (Sathe ¶15 teaches DER device “participation [transaction] is verified by an independent third party service and recorded in an immutable and verifiable manner.” Additionally, Sathe ¶28 teaches the control agent [blockchain node] obtaining completed and validated past participations as part of verification whether the DER device is eligible to participate in a bidding. Wherein the data shared is in the form of blockchain as illustrated in Sathe Fig. 2, 204).
With respect to claim 7, Sathe discloses: The system of claim 6, wherein the data from the blockchain includes indicia of participation by the at least one additional blockchain node comprising at least the at least one primary credential. (Sathe ¶65 teaches DER device(s) [at least one additional blockchain node] can submit bid (tenders) comprising indication [indicia] of willingness to participate comprising the DER credentials such as “service delivery levels …” etc.).
With respect to claim 8, Sathe discloses: The system of claim 1, wherein the smart contract tender further includes at least one secondary credential defining additional validation information. (Sathe ¶17 summarizes there are secondary credentials that are used to verify if a bidder is eligible like “credibility score” among other factors).
With respect to claim 9, Sathe discloses: The system of claim 8, wherein the blockchain node is further configured to validate the transaction using responsive data including the at least one primary credential and the at least one secondary credential originating from the at least one additional blockchain node. (Sathe ¶17 and 21 teach using DER device bidder information which comprises multiple credentials to verify by the control agent, which is one of the blockchain nodes illustrated in Sathe Fig. 2, whether the transaction is eligible. Sathe ¶28 discloses the “participation verification information” [credentials] are obtained from the metering agent).
With respect to claim 10, Sathe discloses: A system comprising: a blockchain node in communication with a network and a blockchain and configured to: (Sathe ¶69 teaches, Fig. 2, of a system comprising different participants and each comprises a separate blockchain node 204. “the blockchain (generally 204) established a blockchain based ledger and shares data 204A between the participants. Blockchain 204 utilizes marketplace smart contracts 204B for respective participants”. Network illustrated in Fig. 1).
receive a smart contract tender from an additional blockchain node connected to the network, the smart contract tender including at least one primary credential defining validation process participation requirements for a transaction between parties separate from the blockchain node and the additional blockchain node; (Sathe ¶21 summarizes the prior art and teaches that the control cloud agent would verify DER device to enroll as part of tender using the device data [credential] which is used to determine if the device meets the requirements for bidding. Additionally, Sathe in the detailed description ¶69 teaches, Fig. 2, explain participants each comprising blockchain node sharing ledger and bid [tender] for transaction between parties. So, if for example looking at Fig. 2 the platform operator receiving the contract shared by the market operator which also pertains to two other different blockchain nodes that could be the user or DER device nodes as part of the bidding [tender] process).
and a signaling log collector, wherein the signaling log collector is in communication with the network and the blockchain node and configured to: in response to the receiving the smart contract tender, determine a match between each of the at least one primary credentials and equivalent blockchain node credentials; (Sathe ¶21 discloses computing device, which implicitly comprises storage/memory/log receiving the bid [tender] “the quote bidder information including DER device information [at least one primary credentials] with which to confirm [match] the DER device; and communicate with a control agent for the DER device to verify eligibility to enrol.” The data recorded on blockchain which is shared between parties as explained in Sathe ¶69 and illustrated in Fig. 2 data flow arrows).
in response to the match, query the network for one or more credentials associated with the transaction; and send the one or more credentials to the blockchain node; (Sathe ¶28-29 “receive participation verification information from one or more metering agents monitoring participation of the respective [matched] DER devices to verify respective participation in respective contracts [participation is interpreted as one or more credentials]; communicate [send] blockchain information [credentials] to participants in the platform”)
wherein the blockchain node is further configured to: query the one or more credentials and the smart contract tender to identify one or more matching credentials; (Sathe ¶30-32 “receive respective merchant product and merchant offer information (query credentials) and publish respective merchant offers for spending rewards issued in response to verified participation; … communicate notifications of the quote to the plurality of quote bidders, the plurality of quote bidders determined [identify matching credentials] in response to a) the market service and b) type of DER device associated with the quote bidder; for a respective quote bidder, any one or more of: provide an upcoming quotes interface for quotes available for a bid by the respective quote bidder;”)
update the smart contract with an acknowledgement indication; and provide the updated smart contract to the additional blockchain node. (Sathe ¶32 teaches that tender quotes from bidders are accepted [acknowledgement] and recorded, all recording is done on the blockchain and shared between parties as illustrated in Sathe Fig. 2 and explained in Sathe ¶69).
With respect to claim 11, Sathe discloses: The system of claim 10, wherein the signaling log collector and the blockchain node are installed on a cloud. (Sathe ¶69 discloses the interaction with data can be “web-based” or “cloud-based” 208 wherein the components shown in Fig. 2 all use cloud/web-based technology as illustrated).
With respect to claim 12, Sathe discloses: The system of claim 10, wherein the signaling log collector and the blockchain node are installed at a premises associated with an intermediary to the transaction on the network. (Sathe Fig. 2 illustrates the memory and blockchain are installed on intermediary entities to the transaction process on the illustrated cloud-based network, see Sathe ¶69).
With respect to claim 13, Sathe discloses: The system of claim 10, wherein the smart contract tender further includes at least one secondary credential defining additional validation information. (Sathe ¶17 summarizes there are secondary credentials that are used to verify if a bidder is eligible like “credibility score” among other factors).
With respect to claim 14, Sathe discloses: The system of claim 13, wherein the signaling log collector is further configured to determine a secondary match between at least one of the secondary credentials and equivalent blockchain node credentials, and the query is performed in further response to the secondary match. (Sath ¶224 give another example using a price [a credential] match to bid and if there is a match then a bid is placed and if there is a mismatch then a query to place bid is not placed).
With respect to claim 15, Sathe discloses: The system of claim 14, wherein the signaling log collector is further configured to determine at least one mismatch between at least one of the primary credentials or secondary credentials and equivalent blockchain node credentials and refrain from the query in response to the at least one mismatch. (Sath ¶224 give another example using a price [a credential] match to bid and if there is a match then a bid is placed and if there is a mismatch then a query to place bid is not placed).
With respect to claim 16, Sathe discloses: The system of claim 10, wherein the signaling log collector is further configured to obtain the equivalent credentials from a hierarchical digital identity associated with the blockchain node. (Sathe ¶87 “Platform 102 queries the blockchain to retrieve the latest quote information (e.g. with aggregated [hierarchical] tender values). Platform 102 is enabled to update to the contract counterparty 108A dashboard including the updated quote, and the new tender details.” The tender values and contract comprises credentials as understood by the examiner from reading the prior art).
With respect to claim 17, Sathe discloses: The system of claim 13, wherein the signaling log collector is further configured to obtain the equivalent credentials from a digital wallet associated with the blockchain node. (Sathe ¶223 “Participants have respective computing devices (not shown) to interact with the credits market platform via the participant interface. Such devices can store or have access to blockchain wallets or other manners of storing blockchain key information [credentials] for managing accounts and facilitating transaction signing.”).
With respect to claim 18, Sathe discloses: The system of claim 10, wherein the blockchain node is further configured to monitor the network and update the smart contract tender with additional information about the transaction obtained from monitoring the network. (Sathe ¶87 “Platform 102 queries the blockchain to retrieve the latest quote information (e.g. with aggregated tender values). Platform 102 is enabled to update to the contract counterparty 108A dashboard including the updated quote, and the new tender details.”).
With respect to claim 19, Sathe discloses: The system of claim 10, wherein the blockchain node is configured to update the smart contract tender with a failure acknowledgement if a match is not identified within a predetermined time period after receiving the smart contract tender. (¶89 “customer tenders are associated with a gate (e.g. a time to reply [predetermined time period after receiving the smart contract tender]). Clearance operations wait for gate closure … If the tender made by the particular contract counterparty 108A is not accepted, the linked quote to the customers of the particular contract counterparty 108A is cancelled (e.g. the blockchain is updated with the cancellation [update the smart contract tender with a failure acknowledgement])”).
With respect to claim 20, Sathe discloses: A computer-implemented method for validating a transaction performed by a processor located in a network comprising: receiving one or more credentials associated with a network transaction between second and third parties from a signaling log collector of a first party; generating a smart contract tender for the transaction, the smart contract tender including at least one primary credential defining validation process participation requirements; and transmitting the smart contract tender to at least one blockchain node connected to the network. (Rejected based on the same rationale as claim 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lynberg (US 20220083988 A1) ¶119 “FIG. 1 shows an enterprise architecture for the established collaborative organizations that are responsible for the nation's currency and the matching technology platform. In the transactions between the depicted entities 100, each has independent, interdependent, and collective functions, instructions, messages, orders, delivery, distribution, identification, validation, forensic, and quantitative and qualitative information that is transmitted and received against the distributed ledger technology platform. The proof-of-stake is held by the Federal Reserve. The governance, laws, regulations, and the system/method provide customers with access to digital cryptographic currency, or virtualized legal tender, through an existing banking user interface, and provide augmented trust and value to global customers using the $100 bill, or other currency, as an asset and store of value.”.
Chen et al. (US 20180225757 A1) “Disclosed is an Internet-based currency exchange and settlement system, comprising: at least two legal tender nodes, used for receiving an exchange request of a client and sending the exchange request to other legal tender nodes; an electronic currency node, used for circulation between electronic currency and legal tender; a balancing module, used for establishing an exchange path between the electronic currency node and a corresponding legal tender node, and maintaining the balance of expenditure and income of the corresponding legal tender node; a searching module, used for retrieving a legal tender node sending an exchange request within a same time interval; a matching module, used for exchange matching between the legal tender nodes and between the legal tender nodes and the electronic currency node. Also disclosed is an Internet-based currency exchange and settlement method. The present invention is targeted towards the requirements of international travellers having actual legal tender requirements, is based on a big data cashing requirement value chain network smart internal aggregation algorithm, and delivers exchanged destination legal tender to a user via a physical terminal of a target country location.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANY S GADALLA whose telephone number is (571)272-2322. The examiner can normally be reached Mon to Fri 8:00AM - 4:00PM.
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, Carl Colin can be reached on (571) 272-3862. 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.
/HANY S. GADALLA/Primary Examiner, Art Unit 2493