DETAILED ACTION
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 .
Status of Claims
This action is in reply to the application filed on 12/23/2025.
Claims 1, 2, 8, 11 and 18 are amended.
Claims 3, 9, 13 and 19 are canceled.
Claims 1-2, 4-8, 10-12, 14-18, and 20 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 12/13/2025 have been fully considered but they are not persuasive.
35 U.S.C. § 101
Applicant argues the newly amended claims are not abstract as the claims recite versioning, and specifically the digital signing of the data structures represent technical operation on the data structure.
Examiner respectfully disagrees, the as currently claimed the versioning, and signing of the data structures represents mere instruction to apply the excretion to a technical environment. Under 2106.05(f)(1). “Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it".”
For at least the reasons stated above applicant’s arguments regarding 35 U.S.C. § 101 are not persuasive.
35 U.S.C. § 103
Applicant argues that the new amendments are not taught by the Chow reference.
Examiner assets that the Demtchenko and Severion references address the amended claims.
For at least the reasons stated above applicant’s arguments regarding 35 U.S.C. § 103 are not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 2, 4-8, 10-12, 14-18 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claims 1 and 11, claim 1 representing, it is unclear what is intended by the limitation “wherein the knowledge graph represents vendors that are associated with specific nodes of the knowledge graph”. First, it is unclear how the graph represents the vendor, when the vendors are represented by the nodes “vendors that are associated with specific nodes”, as claimed. The specification does not shed light on the proper interpretation either. This is because, the claim uses the word “represents” in a form to mean “ to serve as a sign or symbol of”, whereas, paragraph 49 explains uses term “represented” ( “the knowledge graph may be ‘versioned’ and ‘acknowledged’ by all vendors that are represented in the knowledge graph”) in the form of a different definition of “represent” meaning “to act in the place of or for usually by legal right“. For the purposes of compact prosecution, the claim is interpreted as “to serve as a sign or symbol of”, in a descriptive use.
Dependent claims are rejected by virtue of their dependency.
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-2, 4-8, 10-12, 14-18, and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In the instant case, claims 1 and 11 are directed to a method, and non-transitory computer-readable recording medium. For the purposes of this analysis, representative claim 1 is addressed.
Claim 1 recites “a payment system” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). Abstract ideas are in bold below.
Claim 1 recites:
for a component of a hardware device, registering a component identification (IDI and billing information within an immutable distributed ledger;
creating a data structure that comprises an aggregator node that corresponds to an aggregator and a node that corresponds to the component, wherein the data structure is a knowledge graph comprising term data for each component represented by the knowledge graph, where the term data is included in respective nodes of the knowledge graph, and wherein the knowledge graph represents vendors that are associated with specific nodes of the knowledge graph;
after the data structure is determined to be validated, versioning the data structure by performing at least one of the following:(i) causing each node in the data structure to be digitally signed by each vendor represented by the data structure, such that the data structure is modified to include a plurality of digital signatures; or, alternatively (ii) storing the data structure in the immutable distributed ledger and generating a hash of the data structure, wherein the hash is digitally signed by each vendor represented by the data structure;
receiving, from a vendor of the component, an acknowledgement as to an accuracy and completeness of the data structure insofar as information in the data structure applies to the component;
collecting telemetry concerning an operation of the component; and
using the telemetry as a basis for performing a process concerning the component and/or the operation of the component.
The additional elements of claim 1 such as “for a component of a hardware device, registering a component identification (IDI and billing information within an immutable distributed ledger”, “…the component”, “receiving, from a vendor of the component, an acknowledgement as to an accuracy and completeness of the data structure insofar as information in the data structure applies to the component”, “collecting telemetry concerning operation of the component;” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Furthermore, “receiving, from a vendor of the component, an acknowledgement as to an accuracy and completeness of the data structure insofar as information in the data structure applies to the component” represent the use of computer functions to perform an economic task (MPEP 2106.05(f)(2). Therefore, the additional elements do not integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of a payment system.
Hence, claim 1 is not patent eligible.
Claim 2 and 12 recites “wherein the node corresponding to the component includes information that comprises the component ID, the billing information, and an identity of a particular vendor of the component.” However, this does no more than describe the abstract idea.
Claim 4 and 14 recites “wherein the aggregator node is associated with an entity that manufactured …, and the aggregator node includes a vendor ID, billing information concerning …, and a device ID.” However, this does no more than describe the abstract idea. The additional elements of “…the device… the hardware device and/or the component…” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 5 and 15 recites “wherein the billing information indicates an amount to be paid, to a vendor of the component, for customer usage of the component.” However, this does no more than describe the abstract idea.
Claim 6 and 16 recites “wherein the telemetry comprises information indicating an extent to which the component was used by one or more customers.” However, this does no more than describe the abstract idea.
Claim 7 and 17 recites “wherein the process comprises billing a customer for usage of the component.” However, this does no more than describe the abstract idea.
Claim 8 and 18 recites “wherein the telemetry is derived from state information,… and payment to respective vendors of the component and the one or more other components is made based on the batch processing.” However, this does no more than describe the abstract idea. The additional elements of “…for the component, that is stored in an immutable distributed ledger that includes state information for one or more other components, and a batch processing of the state information in the immutable distributed ledger is performed,…” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. Therefore, as it is no more than apply it does not improve the functioning of a computer, or improve other technology or technical field.
Claim 10 and 20 recites “wherein the data structure further comprises a payment proxy service node that communicates with the aggregator node, and the payment proxy service is operable to implement distribution of a customer payment, for use of the component, to the vendor and to the aggregator.” However, this does no more than describe the abstract idea.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect an improvement to another technology or technical field, the claims do not amount to an improvement to the functioning of a computer system itself, and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
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 nonobviousness.
Claims 1-2, 4-8, 10-12, 14-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chow et al. (US 2017/0046669 A1) in view of Demtchenko et al (US 11,080,607 A1) and Severion Et al. (EP 4239510 A1)
Regarding claims 1 and 11
Chow Teaches:
for a component of a hardware device, registering a component identification (IDI and billing information within an immutable distributed ledger; (See at least Chow [0026] and [0109]: [0026] As illustrated in FIGS. 1A and 1B, settlement system 130 may maintain a data repository 134 (e.g., within one or more of the tangible, non-transitory memories) that includes authentication data 134A, device data 134B, and settled payment data 134C. In some aspects, authentication data 134A may include data identifying one or more authentication credentials associated with corresponding users (e.g., user 170), such as alpha-numeric user names, alpha-numeric passwords, biometric credentials, etc. Additionally, device data 134B may include one or more unique identifiers of devices, e.g., device 102, that are registered onto network 152 and further, are associated with verified device identifiers and authenticated owner identifiers eligible to receive data provisioning the one or more available services. Further, settled payment data 134C may, include, but it not limited to, data identifying one or more settled micro-payment transactions involving corresponding accounts of user 170. [0109] Device 102 may, in some instances, extract the portions of the sensor data and/or the portions of the tariff data from the one or more block-chain ledgers, and may perform operations that initiate the micro-payment transaction based on the extracted portions of the sensor and/or tariff data.
creating a data structure that comprises an aggregator node that corresponds to an aggregator, and a node that corresponds to the component; (See at least Chow [0094] In certain aspects, the peer computing system (not depicted in FIGS. 1A, 1B, or 2) may be configured (e.g., by elements of code or other software instructions executed by a corresponding processor) to receive the data package and digital signature, validate the received information, and further, generate a new block of the current block-chain ledger that includes the captured sensor data. For example, the peer computing system may validate the received data package and digital signature using a public key of user 170, and in response to a successful validation, generate a new block that includes the captured sensor data (e.g., data representative of the new block). The peer computing system may also generate one or more cryptographic hashes appropriate to and representative of the generated block, which the peer computing system may append to the current version of the block-chain ledger, thus generating an updated block-chain ledger. In some instances, the peer computing system may maintain data indicative of the updated block-chain ledger within a corresponding data repository (e.g., within one or more tangible non-transitory memories), and may provide the updated block-chain ledger to one or more devices (e.g., device 102, device 202, etc.) and/or systems (e.g., settlement system 130) operating within environment 100. Further, in some aspects, the peer computing system, and additionally or alternatively, one or more additional peer computing systems accessible across network 152, may function as a “miner” that validates received data and generates updated versions of the block-chain ledgers.
receiving, from a vendor of the component, an acknowledgement as to an accuracy and completeness of the data structure insofar as information in the data structure applies to the component; (See at least Chow [0102] Referring to FIG. 3, device 102 may receive provisioning data (e.g., a provisioning package) from settlement system 130 that identifies one or more available services and includes service data that enables device 102 to perform operations consistent with the one or more available services (e.g., in step 302). In certain aspects, and as described above, settlement system 130 may receive the request for available services from device 102 (e.g., a provisioning request), and upon a successful authentication of user 170, perform operations that obtain portions of the service data from a corresponding data repository (e.g., from service data 134D of data repository 134) and packaged the obtained service data into the provisioning package for delivery to device 102. Settlement system 130 may transmit the generated provisioning package to device 102 across network 152, and device 102 may receive the transmitted provisioning package in step 302.
collecting telemetry concerning operation of the component; and (See at least Chow [0048] The monitored values of the resource-specific parameters may, in some instances, accurately reflect an actual, real-time consumption of the particular resource (e.g., an actual “wear and tear” of a vehicle operated by user 170). Further, by initiating micro-payment transactions that account for the monitored parameter values at a particular point in time, or that account for corresponding changes in each of the monitored parameter values, the disclosed embodiments may assign costs to a user associated with device 102, e.g., user 170, that reflect the actual, real-time consumption of the particular resource.
using the telemetry as a basis for performing a process concerning the component and/or operation of the component. (See at least Chow [0048] The monitored values of the resource-specific parameters may, in some instances, accurately reflect an actual, real-time consumption of the particular resource (e.g., an actual “wear and tear” of a vehicle operated by user 170). Further, by initiating micro-payment transactions that account for the monitored parameter values at a particular point in time, or that account for corresponding changes in each of the monitored parameter values, the disclosed embodiments may assign costs to a user associated with device 102, e.g., user 170, that reflect the actual, real-time consumption of the particular resource.
However Chow does not specifically teafch: wherein the data structure is a knowledge graph comprising term data for each component represented by the knowledge graph, where the term data is included in respective nodes of the knowledge graph, and wherein the knowledge graph represents vendors that are associated with specific nodes of the knowledge graph;
However Demtchenko teaches at least at (Col 5 line 49 - Col 6 line 8) The data platform for automated pharmaceutical research also features literature extraction whereby a knowledge graph of data category entries and their relationships is constructed from literature. The data platform automates the work of a human reader who reads abstracts one by one and writes down relationships from a closed list between terms, also from a closed list, as he or she encounters them. In a preferred embodiment, the literature extraction process focuses on the entities of various types including, but not limited to genes, proteins, drugs, and diseases which is supported by internally stored and manually curated lists for each entity type. The knowledge graph derived from literature extraction is comprised of nodes which represent an entity term of a specific type, and edges which represent the relationships between terms. The nodes represent entities that exist in the above mentioned category-specific knowledge graphs. This means that the relationships extracted from the literature connect, as edges, the category-specific knowledge graphs together to form a massive, unified knowledge graph which can support advanced search queries spanning a plurality of data categories. To extract relationships between entity terms, the data platform utilizes natural language processing (NLP) algorithms and a plurality of verb databases specific to each entity type. The verb databases are compiled using available existing medical terminology as well as manual curation from domain experts.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the automated implementation of provisioned service based on captured sensor data of Chow in view of data platform for automated pharmaceutical research using knowledge graph as taught by Demtchenko in order to use a the custom knowledge graph and to provide a plurality of functions such as statistical and graphical analysis, similarity based searching, and edge prediction among others. (Demtchenko (abstract))
However Demtchenko does not specifically teach: after the data structure is determined to be validated, versioning the data structure by performing at least one of the following: (i) causing each node in the data structure to be digitally signed by each vendor represented by the data structure, such that the data structure is modified to include a plurality of digital signatures; or, alternatively (ii) storing the data structure in the immutable distributed ledger and generating a hash of the data structure, wherein the hash is digitally signed by each vendor represented by the data structure;
However Severion teaches at least at [0062] (Col 22 lines 30-47) In an embodiment, the appending request comprises an indication of a new digest of a new version of the data structure with the data block appended thereto and a consistency proof for verifying without knowledge of the data block that the new version of the data structure contains a current version of the data structure with no alteration and that the new version of the data structure has been obtained by appending the data block to the current version of the data structure. However, the new digest may be indicated in any way (for example, comprised in the appending request, to be calculated from the consistency proof and so on) and the consistency proof may be of any type (for example, the Merkle consistency proof, the hash values of all the data blocks and so on); moreover, the appending request may comprise any additional information, down to none (for example, its digital signature, an inclusion proof of the data block and so on).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the automated implementation of provisioned service based on captured sensor data of Chow in view of data platform for collaborative verification of certification computing system based on consistency proofs as taught by Severino in order to provide update versions of data structures with verification and validation including digital signatures. .
Regarding claims 2 and 12
Chow Teaches:
wherein the node corresponding to the component includes information that comprises the component ID, the billing information, and an identity of a vendor of the component. (See at least Chow [0026] As illustrated in FIGS. 1A and 1B, settlement system 130 may maintain a data repository 134 (e.g., within one or more of the tangible, non-transitory memories) that includes authentication data 134A, device data 134B, and settled payment data 134C. In some aspects, authentication data 134A may include data identifying one or more authentication credentials associated with corresponding users (e.g., user 170), such as alpha-numeric user names, alpha-numeric passwords, biometric credentials, etc. Additionally, device data 134B may include one or more unique identifiers of devices, e.g., device 102, that are registered onto network 152 and further, are associated with verified device identifiers and authenticated owner identifiers eligible to receive data provisioning the one or more available services. Further, settled payment data 134C may, include, but it not limited to, data identifying one or more settled micro-payment transactions involving corresponding accounts of user 170.
Regarding claims 4 and 14
Chow Teaches:
wherein the aggregator node is associated with an entity that manufactured the device, and the aggregator node includes a vendor ID, billing information concerning the hardware device and/or the component, and a device ID. (See at least Chow [0097], [0098] and [0100]: [0097] In some aspects, the tariff data may form a portion of a rental contract established between user 170 and a vehicle-rental company. The rental contract may, in some instances, specify the rental period (e.g., one hour), the tariff data establishing the unit cost of consumed fuel (e.g., $1.50 per liter of consumed fuel), and information identifying one or more financial terms, such as a source account of user 170 that funds rental costs (including the exemplary micro-payment transaction) and an account of the vehicle-rental company that receives the rental costs. In one instance, the contract may be a written agreement, which user 170 may execute prior to picking up the rental vehicle. In other instances, and consistent with the disclosed embodiments, the rental contract may corresponding to a digital or electronic contract (e.g., an “e-contract”), the terms of which a computing system associated with the vehicle-rental company (e.g., one or more of third-party computing systems 160) may transmit to the peer computing system for inclusion within a new block of a block-chain ledger. [0098] For example, and as described, a block-chain module of the vehicle-rental-agency computer system may receive data indicative of the terms of the rental contract (e.g., the tariff data establishing the unit cost of the consumed fuel), and may perform operations that apply a corresponding digital signature to the rental-contract data using any of the exemplary processes described above. In some aspects, the block-chain module of the vehicle-rental-agency computer system may transmit the rental-contract data and the applied digital signature to the peer computing system, which may generate a new block that includes the rental-contract data, generate one or more cryptographic hashes appropriate to and representative of the new block, and append the new block to the current version of the block-chain ledger using any of the processes described above. [0100] Settlement system 130 may extract the financial terms from the updated block-chain ledger, and may perform any of the exemplary processes described herein to settle the initiated micro-payment transaction in accordance with the corresponding payment-service data (e.g., the payment-service cryptograms, authentication tokens, and other payment-service data) and the financial terms obtained from the updated block-chain ledger, either alone or in conjunction with one or more of third-party computing systems 160. In some aspects, settlement system 130 may be configured to ensure each party's performance of the terms of the digital or electronic contract for the rental of the vehicle, and further, to settle one or more periodic micro-payment transactions in accordance with the terms of that digital or electronic contract. Further, upon settlement of the initiated micro-payment transaction, and any additional or alternate micro-payment transaction, settlement system 130 may perform additional operations that transmit data indicative of the settlement micro-payment transaction or transactions, along with applied digital signatures, to the peer computing system for inclusion in a new block of the block-chain ledger, as described above.
Regarding claims 5 and 15
Chow Teaches:
wherein the billing information indicates an amount to be paid, to a vendor of the component, for customer usage of the component. (See at least Chow [0097] In some aspects, the tariff data may form a portion of a rental contract established between user 170 and a vehicle-rental company. The rental contract may, in some instances, specify the rental period (e.g., one hour), the tariff data establishing the unit cost of consumed fuel (e.g., $1.50 per liter of consumed fuel), and information identifying one or more financial terms, such as a source account of user 170 that funds rental costs (including the exemplary micro-payment transaction) and an account of the vehicle-rental company that receives the rental costs. In one instance, the contract may be a written agreement, which user 170 may execute prior to picking up the rental vehicle. In other instances, and consistent with the disclosed embodiments, the rental contract may corresponding to a digital or electronic contract (e.g., an “e-contract”), the terms of which a computing system associated with the vehicle-rental company (e.g., one or more of third-party computing systems 160) may transmit to the peer computing system for inclusion within a new block of a block-chain ledger.
Regarding claims 6 and 16
Chow Teaches:
wherein the telemetry comprises information indicating an extent to which the component was used by one or more customers. (See at least Chow [0092] In certain aspects, as described above, device 102 may be configured to store sensor data (e.g., sensor data 107) captured by one or more sensors (e.g., sensor 103 and/other on-board sensors) and additionally or alternatively, by one or more external sensors in communication with device 102, within corresponding portions of a data repository maintained in one or more tangible, non-transitory memories (e.g., within sensor output data 104C of data repository 104). In further aspects, as described below, the disclosed embodiments may be configured to record the captured sensor data (e.g., as captured by sensor 103, the one or more on-board sensors, and/or the one or more external sensors) within one or more blocks of a block-chain ledger, which may be generated and maintained by one or more peer computing systems (not depicted in FIGS. 1A, 1B, or 2). In certain aspects, described below, device 102, settlement system 130, and any additional or alternate component of computing environment 130 may obtain the updated versions of the generated and maintained block-chain ledger, extract portions of the recorded sensor data, and based on the extracted sensor data, perform any of the exemplary processes described herein to initiate and settle periodic micro-payment transactions reflecting a real-time consumption or usage of various resources.
Regarding claims 7 and 17
Chow Teaches:
wherein the process comprises billing a customer for usage of the component. (See at least Chow [0092] In certain aspects, as described above, device 102 may be configured to store sensor data (e.g., sensor data 107) captured by one or more sensors (e.g., sensor 103 and/other on-board sensors) and additionally or alternatively, by one or more external sensors in communication with device 102, within corresponding portions of a data repository maintained in one or more tangible, non-transitory memories (e.g., within sensor output data 104C of data repository 104). In further aspects, as described below, the disclosed embodiments may be configured to record the captured sensor data (e.g., as captured by sensor 103, the one or more on-board sensors, and/or the one or more external sensors) within one or more blocks of a block-chain ledger, which may be generated and maintained by one or more peer computing systems (not depicted in FIGS. 1A, 1B, or 2). In certain aspects, described below, device 102, settlement system 130, and any additional or alternate component of computing environment 130 may obtain the updated versions of the generated and maintained block-chain ledger, extract portions of the recorded sensor data, and based on the extracted sensor data, perform any of the exemplary processes described herein to initiate and settle periodic micro-payment transactions reflecting a real-time consumption or usage of various resources.
Regarding claims 8 and 18
Chow Teaches:
wherein the telemetry is derived from state information, for the component, that is stored in the immutable distributed ledger that includes state information for one or more other components, and a batch processing of the state information in the immutable distributed ledger is performed, and payment to respective vendors of the component and the one or more other components is made based on the batch processing. (See at least Chow [0092] and [0094]: [0092] In certain aspects, as described above, device 102 may be configured to store sensor data (e.g., sensor data 107) captured by one or more sensors (e.g., sensor 103 and/other on-board sensors) and additionally or alternatively, by one or more external sensors in communication with device 102, within corresponding portions of a data repository maintained in one or more tangible, non-transitory memories (e.g., within sensor output data 104C of data repository 104). In further aspects, as described below, the disclosed embodiments may be configured to record the captured sensor data (e.g., as captured by sensor 103, the one or more on-board sensors, and/or the one or more external sensors) within one or more blocks of a block-chain ledger, which may be generated and maintained by one or more peer computing systems (not depicted in FIGS. 1A, 1B, or 2). In certain aspects, described below, device 102, settlement system 130, and any additional or alternate component of computing environment 130 may obtain the updated versions of the generated and maintained block-chain ledger, extract portions of the recorded sensor data, and based on the extracted sensor data, perform any of the exemplary processes described herein to initiate and settle periodic micro-payment transactions reflecting a real-time consumption or usage of various resources. [0094] In certain aspects, the peer computing system (not depicted in FIGS. 1A, 1B, or 2) may be configured (e.g., by elements of code or other software instructions executed by a corresponding processor) to receive the data package and digital signature, validate the received information, and further, generate a new block of the current block-chain ledger that includes the captured sensor data. For example, the peer computing system may validate the received data package and digital signature using a public key of user 170, and in response to a successful validation, generate a new block that includes the captured sensor data (e.g., data representative of the new block). The peer computing system may also generate one or more cryptographic hashes appropriate to and representative of the generated block, which the peer computing system may append to the current version of the block-chain ledger, thus generating an updated block-chain ledger. In some instances, the peer computing system may maintain data indicative of the updated block-chain ledger within a corresponding data repository (e.g., within one or more tangible non-transitory memories), and may provide the updated block-chain ledger to one or more devices (e.g., device 102, device 202, etc.) and/or systems (e.g., settlement system 130) operating within environment 100. Further, in some aspects, the peer computing system, and additionally or alternatively, one or more additional peer computing systems accessible across network 152, may function as a “miner” that validates received data and generates updated versions of the block-chain ledgers.
Regarding claims 10 and 20
Chow Teaches:
wherein the data structure further comprises a payment proxy service node that communicates with the aggregator node, and the payment proxy service is operable to implement distribution of a customer payment, for use of the component, to the vendor and to the aggregator. (See at least Chow [0023] and [0028] [0023] Additionally, and as illustrated in FIGS. 1A and 1B, device 102 may maintain a data repository, e.g., data repository 104, within one or more of the tangible, non-transitory memories. Data repository 104 may, for example, include service data 104A, which stores data supporting a performance of operations consistent with one or more provisioned services by device 102, as described below. Data repository 104 may also include sensor configuration data 104B that for sensor 103 and any additional or alternate sensor, specifies a unique sensor identifier (e.g., a serial number, etc.) and further, data characterizing a corresponding sensor type and the one or more parameters monitored or detected by that sensor type (e.g., a tachometer that measures a working speed of an engine in revolutions-per-minute (RPM), etc.). Data repository 124 may also include sensor output data 104C, which stores data captured by sensor 103 and any additional or alternate sensor during corresponding ones of the monitoring periods. [0028] By way of example, the one or more available services may include, but are not limited to, a payment service that, when provisioned to device 102, enables device 102 to perform operations that initiate periodic micro-payment transactions reflecting changes in monitored parameter values and additionally or alternatively, a consumption of one or more device-, system-, and/or apparatus-related resources, at the successive payment periods. Further, and as described above, service data 134D may include payment-service data, such as executable application modules, payment-service cryptograms, authentication tokens, and other data that facilitates the initiation of periodic micro-payment transactions by device 102, and the back-end processing and settlement of the initiated micro-payment transactions by settlement system 130. In some instances, the portions of the payment-service data may, among other things, identify one or more accounts held by user 170 at a financial institution (e.g., which may maintain one or more of third party computing systems 160) and include payment-service cryptograms that enable device 102 and settlement system 130 to initiate and settle the periodic micro-payment transactions based on funds held within the one or more accounts of user 170.
Prior Art of Record Not Currently Relied Upon
Dechu et al. (US 2018/0130130 A1) Teaches: Autonomous peer-to-peer energy networks operating on a blockchain.
Sethi et al. (US 2020/0302434 A1) Teaches: Virtual network function services usage tracking using a distributed trust based network.
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 GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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, Ryan Donlon can be reached at 571-270-3602. 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 April 9, 2026
Prosecution Insights