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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/19/2026 has been entered. Claims 1-4, 6-12, 14-19 are pending, claims 5, 13, and 20 are cancelled, and claims 1, 9, and 17 are amended.
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.
Step 1: The claims 1-4, 6-8 are a system, claims 9-12, 14-16 are a method, and claims 17-19 are a computer readable medium. Thus, each independent claim, on its face, is directed to one of the statutory categories of 35 U.S.C. §101. However, the claims 1-4, 6-12, 14-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A Prong 1: The independent claims (1, 9 and 17, taking claim 1 as a representative claim) recite:
A remote compute device comprising: a memory to store a data collection policy; and a processor to communicate with the memory, the processor to:
receive a data request from an application;
determine a data set within the data request;
provide a data bid request to multiple edge compute devices;
receive multiple bidding values from the edge compute devices, wherein a different one of the bidding values corresponds to a different one of the edge compute devices and indicates an overall ability of that edge computer device to provide telemetry data;
wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases;
based on the multiple bidding values and the data collection policy, determine a target edge compute device;
provide a data request for the data set to the target edge compute device;
receive the data set from the target edge compute device;
and provide the data set to the application.
These limitations, except for the italicized portions, under their broadest reasonable interpretations, recite certain methods of organizing human activity for managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) as well as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). The claimed invention recites steps for implementing a bidding process from an application data request to provide a data set [see paragraphs 0018 and 0020 of the specification]. The steps under its broadest reasonable interpretation specifically fall under sales activities. The Examiner notes that although the claim limitations are summarized, the analysis regarding subject matter eligibility considers the entirety of the claim and all of the claim elements individually, as a whole, and in ordered combination.
Prong 2: This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of
A remote compute device comprising: a memory to store a data collection policy; and a processor to communicate with the memory, the processor to: (claim 1)
A method (claim 9)
A remote compute device comprising: a memory to store a data collection policy, wherein the data collection policy is received from a backend server; and a processor to: (claim 17)
from an application;
multiple edge compute devices;
from the edge compute devices,
different one of the edge compute devices;
to the target edge compute device;
the target edge compute device;
to the application.
The additional elements emphasized above are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of processing data) such that it amounts no more than mere instructions to apply the exception using a generic computer component. The limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application – MPEP 2106.05(f).
Accordingly, these additional elements when considered individually or as a whole do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The independent claims are directed to an abstract idea.
Step 2B: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A Prong two, the additional elements in the claims amount to no more than mere instructions to apply the judicial exception using a generic computer component.
Even when considered as an ordered combination, the additional elements of claim 1, 9, and 17 do not add anything that is not already present when they are considered individually. Therefore, under Step 2B, there are no meaningful limitations in claims 1, 9, and 17 that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself (see MPEP 2106.05).
As such, independent claims 1, 9, and 17 are ineligible.
Dependent claims 2-8, 10-16, and 18-20 when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitations fail to establish that the claims are not directed to the same abstract idea of Independent Claims 1, 9 and 17 without significantly more.
Claim 2 recites wherein the processor further to: receive the data collection policy from a backend server, the backend server is in communication with the remote compute device, the multiple edge compute devices, and multiple information handling systems. The receiving the data collection policy merely further limits the abstract idea and the additional element of the backend server in communication with the remote compute device, the multiple edge compute devices, and multiple information handling systems are recited at a high level of generality and does not integrate the judicial exception into a practical application.
Claim 3 recites wherein prior to the data request being provided to the target edge compute device, the processor further to: create a data lane between the remote compute device and the target edge compute device, wherein the data is received from the target edge compute device over the data lane. The creating of the data lane is interpreted as mere transmission of data between the devices and recited at a high level of generality and does not integrate the judicial exception into a practical application.
Claim 4 recites wherein each of the multiple edge compute devices include the data set. The limitation merely further limits the abstract idea and does not integrate the judicial exception into a practical application.
Claim 6 recites wherein the each different one of the bidding values are based on workload load, subsystem health, data transmission cost, and carbon intensity of a corresponding different one of the edge compute devices. The limitation merely further limits the abstract idea and does not integrate the judicial exception into a practical application.
Claim 7 recites wherein the data collection policy includes a reliability, a data transmission cost, carbon footprint, and speed for an edge compute device. The limitation merely further limits the abstract idea and does not integrate the judicial exception into a practical application.
Claim 8 recites wherein the application is an artificial intelligence based data analysis application. The limitation merely further defines the additional element of the independent claim as being artificial intelligence, however is recited at a high level of generality and does not integrate the judicial exception into a practical application.
Claims 10-16 and 18-20 recite parallel claim language and are therefore also rejected for the same reasons as claims 2-8.
Therefore claims 1-4, 6-12, and 14-19 are rejected under 35 USC 101.
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.
Claim 1, 2, 4, 8-10, 12, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Guim Bernat (US 20210021431) in view of Teveler (US 20010034663) in further view of Smith (US 20200167196).
Regarding claims 1 and 9, Guim Bernat discloses:
A remote compute device comprising: (shown in Figures 8 and 9 arrangement element 840)a memory [0110]the example compute resource controller 1090 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, to store a data collection policy; and a processor [0111] processor to communicate with the memory, the processor to: [0076] In some examples, the fourth node 840 implements the overlay manager 850. The overlay manager 850 creates a group containing one or more of the first, second, and/or third nodes 810, 820, 830, respectively, and/or any nodes of the three tier network 700 associated with or implemented as any of the devices of any of the platforms of the three tier network 700. The nodes included in the group (also referred to as an example overlay) are configured to participate in the peer-to-peer resource bidding process. In some examples, the overlay manager 850 can also change the nodes included in the overlay by removing one or more of the nodes or by adding additional nodes. Any nodes (e.g., any of the first node, the second node, and/or the third node) removed from the overlay are prevented from participating in the peer-to-peer resource bidding process, and any nodes (e.g., any of the first node, the second node, and/or the third node) added to the overlay are permitted/allowed to participate in the peer-to-peer resource bidding process. In some examples, one of the owner controller devices 860, 862, 864, associated with an entity that owns/controls a node determines whether that node is to be added to the overlay such that the node can partake in the peer-to-peer resource bidding process. In some examples, any nodes to be added to the overlay are added by an associated one of the owner/controller devices 860, 862, 864 (e.g., at the behest of an associated one of the owner/controller entities) and such nodes can be added to the overlay only after being authenticated by the overlay manager 850, as described below. Thus, the constitution of the overlay created by the overlay manager 850 is flexible and changes dynamically based on the desires of the owner/controller entities and subsequent authentication by the overlay manager 850. (claim 1)
A method comprising: (claim 9)
receive a data request from an application; determine a data set within the data request; [0092] In some examples, the generated request can be transmitted by the configurable overlay interface 1070 of the second node 820 to the overlay manager 850 of the fourth node 840. In some examples, the request to join an overlay can include a variety information about the node, such as the resources/services/functions/algorithms/applications/etc., to be made available via the node 820, the bitstreams corresponding to such resources/services/functions/algorithms/applications/etc., operational attributes (speed, accuracy, etc.), and any other relevant information including the information identified above. And see [0094]
provide a data bid request to multiple edge compute devices; [0085] In some examples, the example overlay operation attestor 910 of the overlay manager 850 generates a blockchain operation to track/trace bidding and resource sharing operations occurring in the overlay. In some examples, a blockchain operation added to the blockchain is transmitted with requests for bids and/or with offers […]Thus, each request for bids and each offer to perform a bid are signed by a node responsible for generating the request for bid or generating the offer to perform the bid, respectively. [0098] In some examples, as described above with reference to FIG. 9, an example request for a bid can include a request from one first node to use a resource of another node to perform/execute/use a particular service/function/algorithm/application/etc., In some examples, the bid request can include any or all of a service type identifier, a service identifier, a cost that the bid requesting node is willing to pay for that service/function/algorithm/etc., a corresponding service level agreement, and, in some instances, other relevant requirements (e.g., accuracy, speed, etc.). [0100]. In some such examples, the new offer can be received from the overlay manager 850 (FIG. 8 and FIG. 9) which is configured to broadcast any new offers to all (or a subset of) the nodes/peers of the overlay using the bid/offer broadcaster 925.
receive multiple bidding values from the edge compute devices, wherein a different one of the bidding values corresponds to a different one of the edge compute devices; [0100] In some such examples, the new offer can be received from the overlay manager 850 (FIG. 8 and FIG. 9) which is configured to broadcast any new offers to all (or a subset of) the nodes/peers of the overlay using the bid/offer broadcaster 925. When the new offer is received at the node/peer, the node/peer can respond to the new offer by doing nothing, or the node/peer can determine that it will respond to the new offer by making a second offer (also referred to or known as a counter-offer) that is more competitive than the new offer. In some such examples, the bid analyzer 1063 and offer generator 1050 of the bid negotiator 1040 again work together determine a second offer (e.g., a counter-offer) responsive to the new offer. Other nodes/peers can also respond to the new offer in the same manner. The second offer can include for example, a willingness to perform the service/function/algorithm/application/etc. at a lower price/cost, a willingness to perform the service/function/algorithm/application/etc. at a faster speed or at an improved accuracy, etc. and see [0102]
based on the multiple bidding values and the data collection policy, determine a target edge compute device; [0103] In some examples, the node/peers in receipt of the request for bid proceed to generate offers (or not) and to respond to new offers (or not) in the manner described above. The negotiation process then proceeds as described above until one of the offers is accepted. [0106] In some examples, the offer-accepting node may notify the overlay manager 850 (FIG. 8) when an offer to a bid request has been accepted and the overlay operation attestor 910 of the overlay manager 850 can respond by transmitting a blockchain to be signed by the node operation attestor 1030 of the node 820 when the task associated with the bid has been completed. When signed, the blockchain is returned to the overlay manager 1040 which uses the signed blockchain to track the successful completion of the task and to determine that negotiations regarding the task are at an end
provide a data request for the data set to the target edge compute device; [0106] In some examples, the offer-accepting node may notify the overlay manager 850 (FIG. 8) when an offer to a bid request has been accepted and the overlay operation attestor 910 of the overlay manager 850 can respond by transmitting a blockchain to be signed by the node operation attestor 1030 of the node 820 when the task associated with the bid has been completed. When signed, the blockchain is returned to the overlay manager 1040 which uses the signed blockchain to track the successful completion of the task and to determine that negotiations regarding the task are at an end and see [0092] the examiner has interpreted the task information of the bid of the reference to be the data request for the data set in the claimed invention under BRI as the task information of the bid in the reference as set forth in [0092] includes resources/services/functions/algorithms/applications/etc., to be made available via the node 820, the bitstreams corresponding to such resources/services/functions/algorithms/applications/etc., operational attributes (speed, accuracy, etc.), and any other relevant information including the information identified
receive the data set from the target edge compute device; and provide the data set to the application. [0106] In some examples, the offer-accepting node may notify the overlay manager 850 (FIG. 8) when an offer to a bid request has been accepted and the overlay operation attestor 910 of the overlay manager 850 can respond by transmitting a blockchain to be signed by the node operation attestor 1030 of the node 820 when the task associated with the bid has been completed. When signed, the blockchain is returned to the overlay manager 1040 which uses the signed blockchain to track the successful completion of the task and to determine that negotiations regarding the task are at an end and see [0102] and the section on "task tracking" at [0104]
Guim Bernat does not disclose:
and indicates an overall ability of that edge compute device to provide telemetry data,
wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases;
However Teveler teaches:
wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases; See example in [0146-0151 including formula] [0147] As described below, the high demand is determined by querying bidders' IDs. If a high percentage of the bidders buy multiple COMPLET objects of the same category (Cmp.sub.i of Cat.sub.j), SCA will proportionally increase $Cmp size (see formula below). For each commodity category, location, and time, Complet Analyzer retrieves recent trading data from TS Bidding Archive Database 701 and looks up current trading data from TS Application Biddings Servers Memory 700. First, Complet Analyzer checks if total COMPLET values in most trades (for a certain period of time) reach current COMPLET maximum size (dollar value of the COMPLET) as set up by the TS 702. If not, and no significant number of COMPLETs have total value smaller than the minimum COMPLET value, SCA will terminate the adjustment process 710. If yes 707, SCA will decrease minimum COMPLET size 708, so more COMPLET objects can be auctioned. SCA stores the new minimum COMPLET value 709 (interchangeable with word size here) in the TS COMPLET Database 706. [0148] If the number of bids is significant 703, i.e. bidders demand is significant; SCA will increase maximum COMPLET size 704 and record 705 the value in the COMPLET database 706. Thus, the SCA mechanism allows TS to adapt to changes in the bidders demands for each particular COMPLET category. The optimal COMPLET size from bidders perspective, as well as TS Owner's view varies with time. [0149] The following formulas describe the adjustment value for maximum and minimum COMPLET size adjustment. The process starts with the base size of the COMPLET $Cmp Base.sub.max (the base COMPLET maximum value tabulated by TS and stored in the TS Bidding Archive Database 701B). [0150] where Nbidid is the percent number of bids that have the same bid ID, TotalN is the total number of bids, $Cmp.sub.max is the dollar value adjustment determined by the Neural Net, $Cmp.sub.min is the minimum allowed COMPLET value, is the base COMPLET minimum value, $bid price is the bid price increment determined by the TS, and $bid price.sub.min and $bid price.sub.max are the minimum and maximum bid prices set up by the TS for a particular commodity, respectively. [0151] Thus, bidding prices ($bid price) are adjusted. The bidding price is the initial minimal price TS asks for the COMPLET. It is obviously different from the COMPLET size $Cmp, that is, it is larger. $Cmp.sub.max is maximum size of a COMPLET, while $Cmp.sub.min is minimum size of a COMPLET.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the task resource bidding process of Guim Bernat to include wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases, as taught in Teveler, in order to reduce the bidders risk (par. 0033).
Guim Bernat in view of Teveler does not teach:
and indicates an overall ability of that edge compute device to provide telemetry data,
However Smith teaches:
and indicates an overall ability of that edge compute device to provide telemetry data, [0107] The workload executor 710 includes an example performance monitor 725. The workload executor 710 accesses a description of a workload from the node scheduler 705 and executes the workload based on the description. For example, a description of a workload may include a machine learning model and a location at which input data resides. The node scheduler 705 may retrieve the input data at the location and execute the machine learning model using the input data. The workload executor 710 provides a result of the workload execution to the node scheduler 705. The performance monitor 725 (e.g., one or more performance counters) monitors performance telemetry (e.g., performance metrics, execution time, energy consumption, throughput, response time, etc.) and provides perform nuance telemetry to the controller 715. The controller 715 may compare the performance metrics to performance terms included in the contract and [0155] The controller 715 determines whether contract terms are met by execution of the workload. (Block 1445). The controller 715 may identify whether telemetry (e.g., power metrics accessed from the energy monitor 735) does not exceed resource terms or performance terms included in the contract. In some examples, the controller 715 may identify rates of service (such as tokens paid per watt used during execution of a workload) to be modified. For example, if a rate of service provided by the energy provider 275 exceeds a rate of service included in the contract, the controller 715 may determine that the contract terms were not met. And see bidding in [0065] An execution of a workload in the edge environment 110 may reduce computation costs and/or processing time used to execute the workload relative to an execution of the workload in the cloud environment 105. For example, an endpoint device may request an edge service to execute a workload at a cost lower than a cost needed to execute the workload in the cloud environment 105. In some examples, multiple edge services 135 may compete to receive a task to execute a workload, and each edge service may provide a bid including a workload execution cost to the orchestrator 142 and/or to the endpoint device 165. Each bid may include a different workload execution cost, and an edge service may lower a respective workload execution cost relative to other bids in order to be selected to execute the workload. Thus, a workload execution cost in the edge environment 110 may be lower than a workload execution cost in the cloud environment 105 provided by a centralized server (e.g., the first server 115).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Guim Bernat in view of Teveler to include indicates an overall ability of that edge compute device to provide telemetry data, as taught in Smith, in order to reduce computation costs and/or processing time used to execute the workload (paragraph 0075).
Regarding claims 2 and 10, Guim Bernat in view of Teveler in further view of Smith teaches the limitations set forth above and Guim Bernat further discloses:
wherein the processor further to: receive the data collection policy [0076] In some examples, one of the owner controller devices 860, 862, 864, associated with an entity that owns/controls a node determines whether that node is to be added to the overlay such that the node can partake in the peer-to-peer resource bidding process. In some examples, any nodes to be added to the overlay are added by an associated one of the owner/controller devices 860, 862, 864 (e.g., at the behest of an associated one of the owner/controller entities) and such nodes can be added to the overlay only after being authenticated by the overlay manager 850, as described below. Thus, the constitution of the overlay created by the overlay manager 850 is flexible and changes dynamically based on the desires of the owner/controller entities and subsequent authentication by the overlay manager 850. from a backend server, the backend server is in communication with the remote compute device, the multiple edge compute devices, and multiple information handling systems. And see IoT platform, edge platform, and cloud platforms in Figure 8 and arrangement in Fig. 3
Regarding claim 4 and 12, Guim Bernat in view of Teveler in further view of Smith teaches the limitations set forth above and Guim Bernat further discloses:
wherein each of the multiple edge compute devices include the data set. [0092] In some examples, the generated request can be transmitted by the configurable overlay interface 1070 of the second node 820 to the overlay manager 850 of the fourth node 840. In some examples, the request to join an overlay can include a variety information about the node, such as the resources/services/functions/algorithms/applications/etc., to be made available via the node 820, the bitstreams corresponding to such resources/services/functions/algorithms/applications/etc., operational attributes (speed, accuracy, etc.), and any other relevant information including the information identified above. And see [0094] [0100] In some such examples, the new offer can be received from the overlay manager 850 (FIG. 8 and FIG. 9) which is configured to broadcast any new offers to all (or a subset of) the nodes/peers of the overlay using the bid/offer broadcaster 925. When the new offer is received at the node/peer, the node/peer can respond to the new offer by doing nothing, or the node/peer can determine that it will respond to the new offer by making a second offer (also referred to or known as a counter-offer) that is more competitive than the new offer. In some such examples, the bid analyzer 1063 and offer generator 1050 of the bid negotiator 1040 again work together determine a second offer (e.g., a counter-offer) responsive to the new offer. Other nodes/peers can also respond to the new offer in the same manner. The second offer can include for example, a willingness to perform the service/function/algorithm/application/etc. at a lower price/cost, a willingness to perform the service/function/algorithm/application/etc. at a faster speed or at an improved accuracy, etc. and see [0102] The examiner interprets the plurality of edge devices negotiating the bidding based on their willingness to perform the request as the data set.
Regarding claim 8 and 16, Guim Bernat in view of Teveler in further view of Smith teaches the limitations set forth above and Guim Bernat further discloses:
wherein the application is an artificial intelligence based data analysis application. [0161] The edge computing node 2050 may include or be coupled to acceleration circuitry 2064, which may be embodied by one or more artificial intelligence (AI) accelerators, a neural compute stick, neuromorphic hardware, an FPGA, an arrangement of GPUs, an arrangement of xPUs/DPUs/IPU/NPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, dedicated ASICs, or other forms of specialized processors or circuitry designed to accomplish one or more specialized tasks. These tasks may include AI processing (including machine learning, training, inferencing, and classification operations), visual data processing, network data processing, object detection, rule analysis, or the like. These tasks also may include the specific edge computing tasks for service management and service operations discussed elsewhere in this document.
Claims 3, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Guim Bernat (US20210021431) in view of Teveler (US 20010034663) in view of Smith (US 20200167196) in further view of KUPERSHMIDT (US 2023/0350836).
Regarding claims 3 and 11, Guim Bernat in view of Teveler in further view of Smith teaches the limitations set forth above.
While Guim Bernat discloses the bidding process for identifying a resource for a task, the combination does not expressly disclose:
wherein prior to the data request being provided to the target edge compute device, the processor further to: create a data lane between the remote compute device and the target edge compute device, wherein the data is received from the target edge compute device over the data lane.
However KUPERSHMIDT discloses:
wherein prior to the data request being provided to the target edge compute device, the processor further to: create a data lane between the remote compute device and the target edge compute device, wherein the data is received from the target edge compute device over the data lane. [0026] Interface 218 may connect first computing device 214 to a first subset 292a of data lanes 292 of network interface device 290. Interface 218 may connect second computing device 216 to a second subset 292c of data lanes 292 of network interface device 290. For example, electronic device 210 may include data lanes 220 positioned on PCB 212 (e.g. as shown in FIG. 2). A first subset 220a of data lanes 220 may extend between first computing device 214 and interface 218 and connect first computing device 214 to first subset 292a of data lanes 292 of network interface device 290 when network interface device 290 is connected to interface 218 (e.g. as shown in FIG. 2). A second subset 220c of data lanes 220 may extend between second computing device 216 and interface 218 and connect second computing device 216 to second subset 292c of data lanes 292 of network interface device 290 when network interface device 290 is connected to interface 218 (e.g. as shown in FIG. 2).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the task resource bidding process of Guim Bernat in view of Teveler in further view of Smith to include wherein prior to the data request being provided to the target edge compute device, the processor further to: create a data lane between the remote compute device and the target edge compute device, wherein the data is received from the target edge compute device over the data lane, as taught in KUPERSHMIDT, in order to optimize the transmission of data between resources (paragraph 00160.
Regarding claim 17, Guim Bernat discloses:
A remote compute device comprising: (shown in Figures 8 and 9 arrangement element 840)
a memory [0110]the example compute resource controller 1090 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, to store a data collection policy; and a processor [0111] processor to communicate with the memory, the processor to: [0076] In some examples, the fourth node 840 implements the overlay manager 850. The overlay manager 850 creates a group containing one or more of the first, second, and/or third nodes 810, 820, 830, respectively, and/or any nodes of the three tier network 700 associated with or implemented as any of the devices of any of the platforms of the three tier network 700. The nodes included in the group (also referred to as an example overlay) are configured to participate in the peer-to-peer resource bidding process. In some examples, the overlay manager 850 can also change the nodes included in the overlay by removing one or more of the nodes or by adding additional nodes. Any nodes (e.g., any of the first node, the second node, and/or the third node) removed from the overlay are prevented from participating in the peer-to-peer resource bidding process, and any nodes (e.g., any of the first node, the second node, and/or the third node) added to the overlay are permitted/allowed to participate in the peer-to-peer resource bidding process. In some examples, one of the owner controller devices 860, 862, 864, associated with an entity that owns/controls a node determines whether that node is to be added to the overlay such that the node can partake in the peer-to-peer resource bidding process. In some examples, any nodes to be added to the overlay are added by an associated one of the owner/controller devices 860, 862, 864 (e.g., at the behest of an associated one of the owner/controller entities) and such nodes can be added to the overlay only after being authenticated by the overlay manager 850, as described below. Thus, the constitution of the overlay created by the overlay manager 850 is flexible and changes dynamically based on the desires of the owner/controller entities and subsequent authentication by the overlay manager 850.
receive a data request from an application; determine a data set within the data request; [0092] In some examples, the generated request can be transmitted by the configurable overlay interface 1070 of the second node 820 to the overlay manager 850 of the fourth node 840. In some examples, the request to join an overlay can include a variety information about the node, such as the resources/services/functions/algorithms/applications/etc., to be made available via the node 820, the bitstreams corresponding to such resources/services/functions/algorithms/applications/etc., operational attributes (speed, accuracy, etc.), and any other relevant information including the information identified above. And see [0094]
provide a data bid request to multiple edge compute devices; [0085] In some examples, the example overlay operation attestor 910 of the overlay manager 850 generates a blockchain operation to track/trace bidding and resource sharing operations occurring in the overlay. In some examples, a blockchain operation added to the blockchain is transmitted with requests for bids and/or with offers […]Thus, each request for bids and each offer to perform a bid are signed by a node responsible for generating the request for bid or generating the offer to perform the bid, respectively. [0098] In some examples, as described above with reference to FIG. 9, an example request for a bid can include a request from one first node to use a resource of another node to perform/execute/use a particular service/function/algorithm/application/etc., In some examples, the bid request can include any or all of a service type identifier, a service identifier, a cost that the bid requesting node is willing to pay for that service/function/algorithm/etc., a corresponding service level agreement, and, in some instances, other relevant requirements (e.g., accuracy, speed, etc.). [0100]. In some such examples, the new offer can be received from the overlay manager 850 (FIG. 8 and FIG. 9) which is configured to broadcast any new offers to all (or a subset of) the nodes/peers of the overlay using the bid/offer broadcaster 925.
receive multiple bidding values from the edge compute devices, wherein a different one of the bidding values corresponds to a different one of the edge compute devices; [0100] In some such examples, the new offer can be received from the overlay manager 850 (FIG. 8 and FIG. 9) which is configured to broadcast any new offers to all (or a subset of) the nodes/peers of the overlay using the bid/offer broadcaster 925. When the new offer is received at the node/peer, the node/peer can respond to the new offer by doing nothing, or the node/peer can determine that it will respond to the new offer by making a second offer (also referred to or known as a counter-offer) that is more competitive than the new offer. In some such examples, the bid analyzer 1063 and offer generator 1050 of the bid negotiator 1040 again work together determine a second offer (e.g., a counter-offer) responsive to the new offer. Other nodes/peers can also respond to the new offer in the same manner. The second offer can include for example, a willingness to perform the service/function/algorithm/application/etc. at a lower price/cost, a willingness to perform the service/function/algorithm/application/etc. at a faster speed or at an improved accuracy, etc. and see [0102]
based on the multiple bidding values and the data collection policy, determine a target edge compute device; [0103] In some examples, the node/peers in receipt of the request for bid proceed to generate offers (or not) and to respond to new offers (or not) in the manner described above. The negotiation process then proceeds as described above until one of the offers is accepted. [0106] In some examples, the offer-accepting node may notify the overlay manager 850 (FIG. 8) when an offer to a bid request has been accepted and the overlay operation attestor 910 of the overlay manager 850 can respond by transmitting a blockchain to be signed by the node operation attestor 1030 of the node 820 when the task associated with the bid has been completed. When signed, the blockchain is returned to the overlay manager 1040 which uses the signed blockchain to track the successful completion of the task and to determine that negotiations regarding the task are at an end
provide a data request for the data set to the target edge compute device; [0106] In some examples, the offer-accepting node may notify the overlay manager 850 (FIG. 8) when an offer to a bid request has been accepted and the overlay operation attestor 910 of the overlay manager 850 can respond by transmitting a blockchain to be signed by the node operation attestor 1030 of the node 820 when the task associated with the bid has been completed. When signed, the blockchain is returned to the overlay manager 1040 which uses the signed blockchain to track the successful completion of the task and to determine that negotiations regarding the task are at an end and see [0092] the examiner has interpreted the task information of the bid of the reference to be the data request for the data set in the claimed invention under BRI as the task information of the bid in the reference as set forth in [0092] includes resources/services/functions/algorithms/applications/etc., to be made available via the node 820, the bitstreams corresponding to such resources/services/functions/algorithms/applications/etc., operational attributes (speed, accuracy, etc.), and any other relevant information including the information identified
receive the data set from the target edge compute device; and provide the data set to the application. [0106] In some examples, the offer-accepting node may notify the overlay manager 850 (FIG. 8) when an offer to a bid request has been accepted and the overlay operation attestor 910 of the overlay manager 850 can respond by transmitting a blockchain to be signed by the node operation attestor 1030 of the node 820 when the task associated with the bid has been completed. When signed, the blockchain is returned to the overlay manager 1040 which uses the signed blockchain to track the successful completion of the task and to determine that negotiations regarding the task are at an end and see [0102] and the section on "task tracking" at [0104]
Guim Bernat does not disclose:
wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases;
and indicates an overall ability of that edge compute device to provide telemetry data,
create a data lane between the remote compute device and the target edge compute device;
However Teveler teaches:
wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases; See example in [0146-0151 including formula] [0147] As described below, the high demand is determined by querying bidders' IDs. If a high percentage of the bidders buy multiple COMPLET objects of the same category (Cmp.sub.i of Cat.sub.j), SCA will proportionally increase $Cmp size (see formula below). For each commodity category, location, and time, Complet Analyzer retrieves recent trading data from TS Bidding Archive Database 701 and looks up current trading data from TS Application Biddings Servers Memory 700. First, Complet Analyzer checks if total COMPLET values in most trades (for a certain period of time) reach current COMPLET maximum size (dollar value of the COMPLET) as set up by the TS 702. If not, and no significant number of COMPLETs have total value smaller than the minimum COMPLET value, SCA will terminate the adjustment process 710. If yes 707, SCA will decrease minimum COMPLET size 708, so more COMPLET objects can be auctioned. SCA stores the new minimum COMPLET value 709 (interchangeable with word size here) in the TS COMPLET Database 706. [0148] If the number of bids is significant 703, i.e. bidders demand is significant; SCA will increase maximum COMPLET size 704 and record 705 the value in the COMPLET database 706. Thus, the SCA mechanism allows TS to adapt to changes in the bidders demands for each particular COMPLET category. The optimal COMPLET size from bidders perspective, as well as TS Owner's view varies with time. [0149] The following formulas describe the adjustment value for maximum and minimum COMPLET size adjustment. The process starts with the base size of the COMPLET $Cmp Base.sub.max (the base COMPLET maximum value tabulated by TS and stored in the TS Bidding Archive Database 701B). [0150] where Nbidid is the percent number of bids that have the same bid ID, TotalN is the total number of bids, $Cmp.sub.max is the dollar value adjustment determined by the Neural Net, $Cmp.sub.min is the minimum allowed COMPLET value, is the base COMPLET minimum value, $bid price is the bid price increment determined by the TS, and $bid price.sub.min and $bid price.sub.max are the minimum and maximum bid prices set up by the TS for a particular commodity, respectively. [0151] Thus, bidding prices ($bid price) are adjusted. The bidding price is the initial minimal price TS asks for the COMPLET. It is obviously different from the COMPLET size $Cmp, that is, it is larger. $Cmp.sub.max is maximum size of a COMPLET, while $Cmp.sub.min is minimum size of a COMPLET.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the task resource bidding process of Guim Bernat to include wherein the data collection policy sets a level of granularity for the bidding values, wherein the level of granularity increases as a number of the multiple edge compute devices increases, as taught in Teveler, in order to reduce the bidders risk (par. 0033).
Guim Bernat in view of Teveler does not teach:
and indicates an overall ability of that edge compute device to provide telemetry data,
create a data lane between the remote compute device and the target edge compute device;
However Smith teaches:
and indicates an overall ability of that edge compute device to provide telemetry data, [0107] The workload executor 710 includes an example performance monitor 725. The workload executor 710 accesses a description of a workload from the node scheduler 705 and executes the workload based on the description. For example, a description of a workload may include a machine learning model and a location at which input data resides. The node scheduler 705 may retrieve the input data at the location and execute the machine learning model using the input data. The workload executor 710 provides a result of the workload execution to the node scheduler 705. The performance monitor 725 (e.g., one or more performance counters) monitors performance telemetry (e.g., performance metrics, execution time, energy consumption, throughput, response time, etc.) and provides perform nuance telemetry to the controller 715. The controller 715 may compare the performance metrics to performance terms included in the contract and [0155] The controller 715 determines whether contract terms are met by execution of the workload. (Block 1445). The controller 715 may identify whether telemetry (e.g., power metrics accessed from the energy monitor 735) does not exceed resource terms or performance terms included in the contract. In some examples, the controller 715 may identify rates of service (such as tokens paid per watt used during execution of a workload) to be modified. For example, if a rate of service provided by the energy provider 275 exceeds a rate of service included in the contract, the controller 715 may determine that the contract terms were not met. And see bidding in [0065] An execution of a workload in the edge environment 110 may reduce computation costs and/or processing time used to execute the workload relative to an execution of the workload in the cloud environment 105. For example, an endpoint device may request an edge service to execute a workload at a cost lower than a cost needed to execute the workload in the cloud environment 105. In some examples, multiple edge services 135 may compete to receive a task to execute a workload, and each edge service may provide a bid including a workload execution cost to the orchestrator 142 and/or to the endpoint device 165. Each bid may include a different workload execution cost, and an edge service may lower a respective workload execution cost relative to other bids in order to be selected to execute the workload. Thus, a workload execution cost in the edge environment 110 may be lower than a workload execution cost in the cloud environment 105 provided by a centralized server (e.g., the first server 115).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Guim Bernat in view of Teveler to include indicates an overall ability of that edge compute device to provide telemetry data, as taught in Smith, in order to reduce computation costs and/or processing time used to execute the workload (paragraph 0075).
While Guim Bernat discloses the bidding process for identifying a resource for a task, the combination of Guim Bernat and Teveler and Smith does not expressly disclose:
create a data lane between the remote compute device and the target edge compute device;
However KUPERSHMIDT discloses:
create a data lane between the remote compute device and the target edge compute device; [0026] Interface 218 may connect first computing device 214 to a first subset 292a of data lanes 292 of network interface device 290. Interface 218 may connect second computing device 216 to a second subset 292c of data lanes 292 of network interface device 290. For example, electronic device 210 may include data lanes 220 positioned on PCB 212 (e.g. as shown in FIG. 2). A first subset 220a of data lanes 220 may extend between first computing device 214 and interface 218 and connect first computing device 214 to first subset 292a of data lanes 292 of network interface device 290 when network interface device 290 is connected to interface 218 (e.g. as shown in FIG. 2). A second subset 220c of data lanes 220 may extend between second computing device 216 and interface 218 and connect second computing device 216 to second subset 292c of data lanes 292 of network interface device 290 when network interface device 290 is connected to interface 218 (e.g. as shown in FIG. 2).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the task resource bidding process of Guim Bernat in view of Teveler in further view of Smith to include create a data lane between the remote compute device and the target edge compute device, as taught in KUPERSHMIDT, in order to optimize the transmission of data between resources (paragraph 00160.
Regarding claim 18, Guim Bernat in view of Teveler in view of Smith in further view of KUPERSHMIDT teaches the limitations set forth above and Guim Bernat further discloses:
wherein each of the multiple edge compute devices include the data set. [0092] In some examples, the generated request can be transmitted by the configurable overlay interface 1070 of the second node 820 to the overlay manager 850 of the fourth node 840. In some examples, the request to join an overlay can include a variety information about the node, such as the resources/services/functions/algorithms/applications/etc., to be made available via the node 820, the bitstreams corresponding to such resources/services/functions/algorithms/applications/etc., operational attributes (speed, accuracy, etc.), and any other relevant information including the information identified above. And see [0094] [0100] In some such examples, the new offer can be received from the overlay manager 850 (FIG. 8 and FIG. 9) which is configured to broadcast any new offers to all (or a subset of) the nodes/peers of the overlay using the bid/offer broadcaster 925. When the new offer is received at the node/peer, the node/peer can respond to the new offer by doing nothing, or the node/peer can determine that it will respond to the new offer by making a second offer (also referred to or known as a counter-offer) that is more competitive than the new offer. In some such examples, the bid analyzer 1063 and offer generator 1050 of the bid negotiator 1040 again work together determine a second offer (e.g., a counter-offer) responsive to the new offer. Other nodes/peers can also respond to the new offer in the same manner. The second offer can include for example, a willingness to perform the service/function/algorithm/application/etc. at a lower price/cost, a willingness to perform the service/function/algorithm/application/etc. at a faster speed or at an improved accuracy, etc. and see [0102] The examiner interprets the plurality of edge devices negotiating the bidding based on their willingness to perform the request as the data set.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Guim Bernat (US 20210021431) in view of Teveler (US 20010034663) in view of Smith (US 20200167196) in further view of Hadar (US 20230067777).
Regarding claims 7 and 15, Guim Bernat in view of Teveler in view of Smith teaches the limitations set forth above and Guim Bernat further discloses:
wherein the data collection policy includes a reliability, […], and speed for an edge compute device. [0098]In some examples, the example bid analyzer 1063 of the example bid negotiator 1040 analyzes the incoming request for bid to identify the requested service/function/algorithm/application/etc., being requested to determine whether the node can provide the requested resource, and, if so, whether the task requested in the bid can be performed according to the terms (e.g., of the service level agreement, with a defined accuracy, with a defined speed, etc.) included in the bid request. When determining whether the node can provide the requested service/function/algorithm/application/etc., the bid analyzer 1063 can compare the request to the existing resources 1085 at the node and the availability of such existing resources 1085.
While Guim Bernat discloses the bidding process for identifying a resource based on a set of criteria in a request for a task, the combination does not expressly disclose:
wherein the data collection policy includes […] a data transmission cost, carbon footprint, […] for an edge compute device.
However Hadar teaches:
wherein the data collection policy includes […] a data transmission cost, carbon footprint, […] for an edge compute device. [0006] Examples include Multi-Access Edge Computing (MEC) that drives connectivity for data push and pull as well as analytics at the edge. This proximity to managed data sources is efficient in key strategic areas such a location services, IoT augmented reality (AR), video analytics, etc. Industrial usages can be precision agriculture for improved crops yields while reducing carbon footprint, media and entertainment where crowd engagement is key that requires fast response and collaborative feedback, urban interactive engagement with citizens for navigation commercials and other rapid response and just-in-time localized offering. [0015] Advantages of the disclosed techniques include a reduction of data load and cost of transmission of data, providing an endless data scale, and providing rapid deployment and quick time to value for new data systems.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the task resource bidding process of Guim Bernat in view of Teveler in view of Smith to include wherein the data collection policy includes […] a data transmission cost, carbon footprint, […] for an edge compute device, as taught in Hadar, in order to a reduction of data load and cost of transmission of data, providing an endless data scale, and providing rapid deployment and quick time to value for new data systems (see paragraph 0015).
Subject Matter Free of Prior Art
Claims 6, 14 and 19 are determined to be free of prior art, however are objected to as being dependent upon a rejected base claim, independent claims 1, 9 and 17. The claims are also rejected under 35 USC 101.
Claims 6, 14, and 19 recite wherein the each different one of the bidding values are based on workload load, subsystem health, data transmission cost, and carbon intensity of a corresponding different one of the edge compute devices.
The closest prior art of record was found to be the following:
Smith (US 20200167196) discloses a bidding process based on the execution of a workload. The reference states [0065] An execution of a workload in the edge environment 110 may reduce computation costs and/or processing time used to execute the workload relative to an execution of the workload in the cloud environment 105. For example, an endpoint device may request an edge service to execute a workload at a cost lower than a cost needed to execute the workload in the cloud environment 105. In some examples, multiple edge services 135 may compete to receive a task to execute a workload, and each edge service may provide a bid including a workload execution cost to the orchestrator 142 and/or to the endpoint device 165. Each bid may include a different workload execution cost, and an edge service may lower a respective workload execution cost relative to other bids in order to be selected to execute the workload. Thus, a workload execution cost in the edge environment 110 may be lower than a workload execution cost in the cloud environment 105 provided by a centralized server (e.g., the first server 115).
Mishra (US 20240427644) discloses a carbon intensity calculator for providing recommendations leading to savings. The references states [0064] The carbon intensity calculator 418 may determine data transfer energy usage and carbon intensity values for workloads based on the forecasted carbon intensity value. The carbon intensity values may be determined to consider scope 3 emissions (such as direct and indirect greenhouse gas emissions) as a result of executing workloads. The carbon intensity calculator 418 may additionally or alternatively determine a carbon intensity rolling average value for workloads, such as based on job duration, or combinations thereof.
“Data Communication Cost” discloses on page 1 “In cloud computing and mobile edge-cloud computing (MECC), increased data communication leads to high bandwidth utilization cost and extra energy consumption for data transfer, management, and processing, directly impacting system performance and latency. 1 Communication cost also plays a significant role in the scalability and throughput of data-intensive applications, as high data rates and large data streams increase the overall cost in multi-device and cloud environments. In parallel algorithms, communication cost and load balancing are main bottlenecks, and their management is essential for optimizing execution time and resource usage. 5 3 Efficient transport protocols, such as Pump Slowly, Fetch Quickly (PSFQ), are designed to reduce data communication cost and enhance energy efficiency in wireless sensor networks. 6 Communication overhead plays an important role in parallel computation.
It was found that no references alone or in combination, neither anticipates, reasonable teaches, nor renders obvious the features of claims 6, 14, and 19 to include wherein the each different one of the bidding values are based on workload load, subsystem health, data transmission cost, and carbon intensity of a corresponding different one of the edge compute devices.
Therefore, none of the cited references disclose or render obvious each and every feature of the claimed invention in claims 6, 14, and 19 and the claimed invention of in claims 6, 14, and 19 is determined to be free of the prior art. Although individually the claimed features could be taught, any combination of references would teach the claimed limitations using a piecemeal analysis, since references would only be combined and deemed obvious based on knowledge gleaned from the applicant's disclosure. Such a reconstruction is improper (i.e., hindsight reasoning). See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). The examiner emphasizes that it is the interrelationship of the limitations that renders these claims free of the prior art/additional art. Therefore, it is hereby asserted by the Examiner that, in light of the above, that the claims 6, 14 and 19 alone are free of prior art as the references do not anticipate the claims and do not render obvious any further modification of the references to a person of ordinary skill in art.
Response to Arguments
Applicant's arguments filed 5/19/2026 have been fully considered but they are not persuasive.
With respect to the remarks directed to 35 USC 101, the claims remain rejected under 35 USC 101. The examiner asserts the claims remain rejected under 35 USC 101 as the claims still recite an abstract idea of the bidding process that uses the data related to the edge computing device to determine the bid values. The claims are not directed to solving a technical problem itself, but rather a business process (i.e. bidding on the ability of an edge device based on itself potential performance/capabilities). The optimize scheme is rooted in the abstract idea itself, not a technical solution to a technical problem.
With respect to the remarks directed to 35 USC 103, the claim rejection has been updated to now include the teachings of Smith to teach the claims as amended. The claims remain rejected under 35 USC 103.
Relevant Art Not Cited
Fedorov US 20200351380 discloses the process for determining optimal processing using edge devices and edge computing.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VICTORIA E. FRUNZI whose telephone number is (571)270-1031. The examiner can normally be reached Monday- Friday 7-4 (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, Marissa Thein can be reached at (571) 272-6764. 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.
VICTORIA E. FRUNZI
Primary Examiner
Art Unit TC 3689
/VICTORIA E. FRUNZI/Primary Examiner, Art Unit 3689 5/27/2026
Prosecution Insights