Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 4-23 are presented for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 7,12,13,17,22 and 23 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement.
With respect to claim 7, the terms “distributed ledger”, “cryptographic verification” and “resolve resource conflicts” are never defined or discussed in the specification.
The same problem exists for claim 12, the terms “end-to-end encryption, digital signatures, secure key exchange protocols, network traffic authentication, and/or automated intrusion detection” cannot be found in the specification.
This is also true about claim 13, “maintain a distributed cache of frequently allocated resources, implement predictive resource scaling, optimize network paths between providers and requesters, monitor system-wide resource utilization patterns, and/or generate efficiency metrics.” is not defined and is not to be found in the specification. Indeed the term “cache” is not found in the specification.
Because this limitation introduces new subject matter not found in the application as originally filed, the applicant has broadened the scope of the invention beyond what was originally contemplated. Therefore, the specification does not reasonably convey to those skilled in the art that the inventor had possession of the claimed invention as currently amended.
Claim 17 has the same problems as claim 7.
Claim 22 has the same problems as claim 12.
Claim 23 has the same problems as claim 13.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 4,5,8,10,14,18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1).
As per claim 4, Doshi teaches A real-time allocation system, comprising:
an allocation computer comprising a memory, a processor, and a plurality of programming instructions stored in the memory, which when executed by the processor, cause the processor to:
establish secure network connections with a distributed network of computing devices; (Doshi [0048] Peer Discovery. In an example, each IPU is provided with Peer Discovery logic to discover other IPUs in the distributed system that can work together with it. Peer Discovery logic may use mechanisms such as broadcasting to discover other IPUs that are available on a network. The Peer Discovery logic is also responsible to work with the Peer Attestation and Authentication logic to validate and authenticate the peer IPU's identity, determine whether they are trustworthy, and whether the current system tenant allows the current IPU to work with them. To accomplish this, an IPU may perform operations such as: retrieve a proof of identity and proof of attestation; connect to a trusted service running in a trusted server; or, validate that the discovered system is trustworthy. Various technologies (including hardware components or standardized software implementations) that enable attestation, authentication, and security may be used with such operations [0066] IPUs may advertise to other peers available resources or can be discovered during discovery phase as introduced earlier. IPUs may request to other IPUS to those resources. For example, an IPU on system A may request access to storage on system B manage by another IPU. Remote and local IPUs can work together to establish a connection between the target resources and the local system. and [0067] Once the connection and resource mapping is completed, resources can be exposed to the services running in the local compute node using the VF/PF PCIE and CXL Logic. Each of those resources can be offered as VF/PF. The IPU logic can expose to the local host resources that are hosted in the IPU. Examples of resources to expose may include local accelerators, access to services, and the like.).
The word secure is not defined and no standards are provided in the specification.
maintain a real-time resource availability index for computing resources across the distributed network; (Doshi [0019] Because of the dynamic nature of edge computing where machine configurations, availabilities, network connectivity, and operating environments change over time causing irregular connectivity and distributed points of control, the ability to achieve optimal and timely distribution of work to where it can be most efficiently performed is very difficult. What is needed is an improved mechanism to distribute computation and data operations [0050] Functionality Discovery. In an example, a particular IPU includes capabilities to discover the functionalities that peer IPUs provide. Once the authentication is done, the IPU can determine what functionalities that the peer IPUs provide (using the IPU Peer Discovery Logic) and store a record of such functionality locally. Examples of properties to discover can include: (i) Type of IPU and functionalities provided and associated KPIs (e.g. performance/watt, cost etc.); (ii) Available functionalities as well as possible functionalities to execute under secure enclaves (e.g., enclaves provided by Intel® SGX or TDX technologies); (iii) Current services that are running on the IPU and on the system that can potentially accept requests forwarded from this IPU [0126] The distributed resource database is kept approximately current by asynchronous updates from various parts of the distributed infrastructure).
receive resource utilization requests from requesting devices via the distributed network during a collection timeframe, wherein each requesting device is associated with a set of affinity indicators; (Doshi [0110] In operation 952, a requesting entity or an agent or proxy of the requesting entity, sends a computation request to an IPU in the edge local cloudlet 904. The computation request may be described in terms of a graph of operations. The graph of operations includes logical identities of the data to be consumed or produced in the operations. The requesting entity (e.g., CPU or XPU 902) may optionally include a set of objectives. These objectives may be expressed in a service level agreement (SLA) or service level objectives (SLOs). [0127] This shorter listing allows the IPU to proceed to operation 954B where it requests and obtains availability, utilization, and other metrics (including network link utilizations and latencies) for determining the current conditions (as opposed to just relying on average metrics that may be given to it in operation 954A). In similar interactions including operations 954C and 954D, additional other criteria may be fitted so that for example, data-compute affinity is factored in to reduce the weighted distance that data needs to move from its previous location to the best matched next location where it is to be used in a computation. The weighted distance includes the cost of transforming data for security, message/packet serialization-deserialization, etc. Other such factors may include sustainability metrics (like use of green power), PUE (Power Usage Effectiveness) (how efficiently does power usage translate into computational work), etc. The optimization/refining flow ties together with application (Requestor) criteria to achieve an overall multi-objective maximization function (operation 956) and thus it may, at times result in reissuing a new request (operation 952) in order to drill into and explore fine-tuned adjustments to previous-best mapping of computation flow.)
generate a prioritized processing queue by applying a multi-factor weighted algorithm to analyze affinity indicators; (Doshi [0111] In operation 954, a series of one or more iterations are used to select resources from the resource database 906. In each iteration, a request is made to the resource database 906 from the edge local cloudlet 904 and a response is provided. In an implementation, the request is in the form of a query to the resource database 906. The query result includes a sorted list of the resources that match the query [prioritized queue]. The query may seek to find the top-N recommendations of resources in terms of X. The X may be latency, cost, capacity, network distance (in terms of hops), [different affinity indicators.] or the like. The response may include a sorted list of servers that provide the requested resource and metrics that describe the state or capabilities of the server. The metrics may be collected and stored (e.g., centrally or distributed) in a database that is continuously updated with eventual consistency mechanisms. The resource database 906 may be updated by a background service. FIG. 10 below further describes specifics of the query-response mechanism).
identify provider devices having available resources, wherein each provider device is associated with a set of affinity indicators; (Doshi [0140] At 1206, the method 1200 includes transmitting a list of recommended resources available to execute the workflow to the requestor device, the list of recommended resources being ranked based on at least one dimension of the resources. In an embodiment, the list of resources includes a top N of resources based on the at least one dimension of the resources).
execute an iterative technical matching algorithm that: (Doshi see Fig 10 and [0016] FIG. 11 depicts inputs and factors used in iterative refinements during the planning phase, according to an example); and
compares affinity indicators and resources of provider devices with the requesting devices; allocates, based on the comparison, at least a portion of the resources from matched provider devices; (Doshi see Fig 10 all the Blocks specially those dealing with task mapping and availability and also those that show filtering for security (i.e. secure connections to a resource) and also the one that says (Evaluate and iterate to determine best chain of execution) see discussion in paragraphs 123-128 which shows how a shorter list is provided based on various criteria and dimensions see also Fig 11 for iterative planning)
establishes secure data channels for the at least portion of resource transfer; (Doshi [0048] connect to a trusted service running in a trusted server; or, validate that the discovered system is trustworthy)
The word channel does not appear in the specification (nor a definition given). This will be taken to be a trustworthy connection
dynamically updates the resource availability index. (Doshi [0126] The distributed resource database is kept approximately current by asynchronous updates from various parts of the distributed infrastructure. The distributed resource database is also updated by local software at each IPU that refreshes a local copy of the distributed database according to types of resources most frequently used or most recently requested in order to map computations to them. Thus, the IPU proximal to the requestor computes a list of ‘N’ best candidates, by overall estimated latency, capacity, etc. for the logical computations being requested for assigning to resources at large (security and other criteria may also play a role in such mapping). The criteria for selecting the list of ‘N’ best candidates depend on the application requestor's criteria in operation 952).
Doshi does not teach monitors transfer completion within system-defined timeframes.
However, Bahramshahry teaches monitors transfer completion within system-defined timeframes (Bahramshahry [0229] According to another embodiment of the system 601, the scheduler is to further perform additional operations, including: discovering, via the workload discovery engine, that a workload task selected and scheduled for execution via any one of the computing resources has failed, terminated prematurely, failed to complete successfully within a threshold period of time, failed to complete successfully within a time specified by a Service Level Target (SLT) for the workload task, or is no longer executing at any of the one or more computing resources available to execute workload tasks or marked as complete by the computing resources to which it was assigned for execution; updating the local cache to indicate the workload task is to be re-scheduled for execution; and aging or increasing a priority designation within the local cache for the workload task to be re-scheduled for execution).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Bahramshahry with the system of Doshi to monitor transfer completion. One having ordinary skill in the art would have been motivated to use Bahramshahry into the system of Doshi for the purpose of implementing a scalable scheduler with heterogeneous resource allocation of large competing workloads types using Quality of Service (QoS) requirements. (Bahramshahry paragraph 03)
As per claim 5, Doshi teaches the plurality of programming instructions further cause the processor to: monitor real-time resource utilization request metrics across allocated connections; (Doshi [0126] The distributed resource database is kept approximately current by asynchronous updates from various parts of the distributed infrastructure. The distributed resource database is also updated by local software at each IPU that refreshes a local copy of the distributed database according to types of resources most frequently used or most recently requested in order to map computations to them. Thus, the IPU proximal to the requestor computes a list of ‘N’ best candidates, by overall estimated latency, capacity, etc. for the logical computations being requested for assigning to resources at large (security and other criteria may also play a role in such mapping). The criteria for selecting the list of ‘N’ best candidates depend on the application requestor's criteria in operation 952).
detect insufficient resource availability from a first provider device; automatically identify additional provider devices with matching affinity indicators and resource capabilities; redistribute resource allocation across multiple provider devices. (Doshi [0041] The IPU in the computing environment 510 may be coordinated with other network-connected IPUs. In an example, a Service and Infrastructure orchestration manager 530 may use multiple IPUs as a mechanism to implement advanced service processing schemes for the user stacks. This may also enable implementing of system functionalities such as failover, load balancing etc. [0043] As a second configuration, a particular IPU (e.g., IPU 514) can work with other IPUs (e.g., IPU 520) to perform load balancing across other systems. For example, consider a scenario where CDN traffic targeted to the local host is forwarded to another host in case that I/O or compute in the local host is scarce at a given moment. [0056] Functionality for Broker requests. The IPU may include Service Request Brokering logic and Load Balancing logic to perform brokering actions on arrival for requests of target services running in the local system. For instance, the IPU may decide to see if those requests can be executed by other peer systems (e.g., accessible through Service and Infrastructure Orchestration 630). This can be caused, for example, because load in the local systems is high. The local IPU may negotiate with other peer IPUs for the possibility to forward the request. Negotiation may involve metrics such as cost. Based on such negotiation metrics, the IPU may decide to forward the request. [0057] Functionality for Load Balancing requests. The Service Request Brokering and Load Balancing logic may distribute requests arriving to the local IPU to other peer IPUs. In this case, the other IPUs and the local IPU work together and do not necessarily need brokering. Such logic acts similar to a cloud native sidecar proxy. For instance, requests arriving to the system may be sent to the service X running in the local system (either IPU or compute platform) or forwarded to a peer IPU that has another instance of service X running The load balancing distribution can be based on existing algorithms such as based on the systems that have lower load, using round robin, etc. [0058] Functionality for failover, resiliency and reliability. The IPU includes Reliability and Failover logic to monitor the status of the services running on the compute platform or the status of the compute platform itself. The Reliability and Failover logic may require the Load Balancing logic to transiently or permanently forward requests that aim specific services in situations such as where: i) The compute platform is not responding; ii) The service running inside the compute node is not responding; and iii) The compute platform load prevents the targeted service to provide the right level of service level objectives (SLOs). Note that the logic must know the required SLOs for the services. Such functionality may be coordinated with service information 650 including SLO information)
As per claim 8, Doshi teaches wherein the affinity indicators comprise at least one of: location, requirement type, household demographics, derived affinity, unit type and transfer preferences, or religious affiliations. (Doshi [0127] This shorter listing allows the IPU to proceed to operation 954B where it requests and obtains availability, utilization, and other metrics (including network link utilizations and latencies) for determining the current conditions (as opposed to just relying on average metrics that may be given to it in operation 954A). In similar interactions including operations 954C and 954D, additional other criteria may be fitted so that for example, data-compute affinity is factored in to reduce the weighted distance that data needs to move from its previous location to the best matched next location where it is to be used in a computation. The weighted distance includes the cost of transforming data for security, message/packet serialization-deserialization, etc. Other such factors may include sustainability metrics (like use of green power), PUE (Power Usage Effectiveness) (how efficiently does power usage translate into computational work), etc. The optimization/refining flow ties together with application (Requestor) criteria to achieve an overall multi-objective maximization function (operation 956) and thus it may, at times result in reissuing a new request (operation 952) in order to drill into and explore fine-tuned adjustments to previous-best mapping of computation flow)
As per claim 10, Doshi teaches wherein the multi-factor weighted algorithm assigns weights to different parameters in each resource request, wherein the parameters include at least one of: importance, timelines, medical diagnoses, descriptions, or historical data of requesting devices. (Doshi [0110] In operation 952, a requesting entity or an agent or proxy of the requesting entity, sends a computation request to an IPU in the edge local cloudlet 904. The computation request may be described in terms of a graph of operations. The graph of operations includes logical identities of the data to be consumed or produced in the operations. The requesting entity (e.g., CPU or XPU 902) may optionally include a set of objectives. These objectives may be expressed in a service level agreement (SLA) or service level objectives (SLOs). The objectives may be expressed in the form of a multi-objective function that an orchestrating node uses in order to determine an optimal solution by maximizing the function. A set of default objectives may be selected or supplied by infrastructure policies when no other optimization objective is provided. The default objectives may be dynamic (e.g., time-varying). [0131] The queries 1100A-C are used in an evaluation 1102, which takes a multi-objective optimization function 1104 from the requestor, the size or “scale-factor” 1106 for that computation (so that the evaluation 1102 can evaluate scale of capacity supported at different nodes), telemetry data on the computation 1108 and network telemetry 1110 of network environments corresponding to the nodes identified in the top-N-by-X results. The evaluation 1102 produces a mapping, which is used in the request for execution 1112. The mapping may be SLO-weighted in general. The multi-objective optimization function 1104 may use different strategies such as best-fit, greedy, time-interval based, etc., while recommendation outputs from the database may be based on classic top-N or deep learning based top-N training).
As to claim 14, it is rejected based on the same reason as claim 4.
As to claim 18, it is rejected based on the same reason as claim 8.
As to claim 20, it is rejected based on the same reason as claim 10.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Abdollahnejadbarough (US 2020/0334603 A1).
As per claim 6, Doshi and Bahramshahry do not teach determining whether a set of affinity indicators of the available provider device, ordered by priority, matches a set of affinity indicators of the requesting device; removing lowest-priority affinity indicator from the set of affinity indicators, when no exact matches are found; updating the set of affinity indicators of the available provider device; repeating the technical evaluation until either a minimum compatibility threshold is met or the set of indicators associated with the available provider device are exhausted.
However, Abdollahnejadbarough teaches wherein executing the iterative technical matching algorithm comprises: determining whether a set of affinity indicators of the available provider device, ordered by priority, matches a set of affinity indicators of the requesting device; (Abdollahnejadbarough [0014] As additionally shown in FIG. 1A, the MLPSS may assign a score, for each provider, for the each of the identified attributes. For instance, Providers 2, 4, 6, and 8 (shown in FIG. 1A as “V2,” “V4,” “V6,” and “V8,” respectively) may each be assigned a score for “MTBF,” “value,” and “reliability” attributes, while Providers 1, 3, 5, and 7 may each be assigned a score for the “service uptime” and “security classification” attributes. In some embodiments, the scores may be normalized (e.g., on a scale of 1-100), such that disparate types of information can be represented on a similar scale. For example, while Provider 2 may be associated with a score of 100 for the MTBF attribute, the actual MTBF of products from Provider 2 may be a value other than 100. That is, the score of 100 may indicate that the MTBF of products from Provider 2 is relatively the highest out of all candidate providers. In some embodiments, the MLPSS may use data envelopment analysis (e.g., with inverse input/output) to generate the normalized scores. [0015] As further shown in FIG. 1A, the MLPSS may generate an overall score for each provider based on the scores for the attributes. In some embodiments, the MLPSS may use Technique for Order of Preference by Similarity to Ideal Solution (“TOPSIS”), Shannon Entropy, and/or other techniques when generating the overall score for each provider. As shown in FIG. 1B, and as described below in further detail, the MLPSS may apply conditional weights, which may be used to modify scores based on specific criteria or conditions.)
removing lowest-priority affinity indicator from the set of affinity indicators, when no exact matches are found; (Abdollahnejadbarough [0016] As further shown in FIG. 1B, the MLPSS may rank the providers based on the overall scores (e.g., after applying conditional weights). In some embodiments, the MLPSS may remove the lowest ranking providers, and/or may identify the lowest ranking providers as candidates for removal. Additionally, or alternatively, the MLPSS may remove providers that do not satisfy a minimum threshold score)
updating the set of affinity indicators of the available provider device; repeating the technical evaluation until either a minimum compatibility threshold is met or the set of indicators associated with the available provider device are exhausted. (Abdollahnejadbarough 0017] Additionally, the MLPSS may simulate, estimate, and/or otherwise determine new scores for the existing providers (e.g., the providers that were not removed, or identified as candidates for removal) based on the existing providers replacing the removed providers. For example, the MLPSS may determine the new scores for the existing providers in scenarios where goods or services, that were sourced from (and/or that will be sourced from, or are projected to be sourced from) some or all of the removed providers, are instead sourced from one or more of the existing providers. As described below, the MLPSS may identify an optimal replacement scenario that maximizes the scores of the existing providers after replacing the removed providers. In some embodiments, the MLPSS may automatically adjust sourcing requests from the existing providers in accordance with the determined optimal replacement scenarios. For example, the MLPSS may implement one or more application programming interfaces (“APIs”) via which the MLPSS may programmatically modify the sourcing requests, such that manual intervention (e.g., from a human operator) is not necessary to modify the sourcing requests. Additionally, or alternatively, the MLPSS may prepare recommendations for modifying sourcing requests, present the recommendations via one or more messages, and programmatically modify the sourcing requests after receiving approval or confirmation from an administrator or other operator. Fig 3 and 4 and [0023] FIG. 3 illustrates an example process 300 for determining categories for providers and ranking providers within categories based on automatically identified attributes. In some embodiments, process 300 may be performed by MLPSS 210. In some embodiments, process 300 may be performed by one or more other devices in addition to, or in lieu of, MLPSS 210. And [0034] FIG. 4 illustrates process 400 for automatically adjusting sourcing requests from providers based on determining an optimal replacement scenarios for providers ( e.g., providers that have been ranked in accordance with process 300, shown in FIG. 3). In some embodiments, process 400 may be performed by MLPSS 210. In some embodiments, process 400 may be performed by one or more other devices in addition to, or in lieu of, MLPSS 210).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Abdollahnejadbarough with the system of Doshi and Bahramshahry to match affinity indicators. One having ordinary skill in the art would have been motivated to use Abdollahnejadbarough into the system of Doshi and Bahramshahry for the purpose of automating provider replacement operations. ( Abdollahnejadbarough paragraph 10)
As to claim 16, it is rejected based on the same reason as claim 6.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Sheehan (US 2025/0350600 Al) and Mada (US 2024/0372777 A1).
As per claim 7, Doshi and Bahramshahry do not teach maintain a distributed ledger of resource allocation transactions; implement cryptographic verification of resource transfers; automatically detect and resolve resource conflicts;
However, Sheehan teaches maintain a distributed ledger of resource allocation transactions; (Sheehan [0127] In at least some embodiment, a “blockchain” or “blockchain network” refers to any and all suitable forms of distributed ledgers, which includes consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and more)
implement cryptographic verification of resource transfers; (Sheehan [0299] Only C3N users with hardware security devices have their own cryptographic key pairs and can be a credential issuer in the C3N. Though C3N social media only-users that can use C3N user registration services to issue user registration credentials on their behalf).
automatically detect and resolve resource conflicts; (Sheehan [0124] The consensus mechanism determines how new blocks are added to the blockchain and how conflicts or forks are resolved)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Sheehan with the system of Doshi and Bahramshahry to maintain a ledger. One having ordinary skill in the art would have been motivated to use Sheehan into the system of Doshi and Bahramshahry for the purpose of implementing a distributed and peer-to-peer cloud infrastructure. (Sheehan paragraph 04)
Sheehan does not teach generate technical performance metrics for allocated resources; optimize future resource allocation based on historical performance data.
However, Mada teaches generate technical performance metrics for allocated resources; (Mada [0020] In stage B, the control unit 110 obtains information indicating performance metrics of the computing resources in area 1 112 and area N 114—e.g., performance logs 116a and 116b. As discussed, in general, the system 100 can include one or more computing resources. The control unit 110 can obtain the information from the RAN 106 or directly from one or more devices of the computing resources in area 1 112 and area N 114. The control unit 110 can be communicably connected to both the RAN 106, other RANs not shown, or the computing resources in area 1 112 and area N 114.)
optimize future resource allocation based on historical performance data. (Mada [0007] Techniques described enable the use of historical data-including parameters from performance logs of computing resources, such as processing capacity, utilization, failure rate, processing bandwidth, among others—to train a machine learning model and to use the trained machine learning model to optimize one or more communication networks. By optimizing the computing resources of a communication network, the techniques described in this document, compared to traditional techniques, can help reduce power consumption in the sector, reduce data or voice request failures or blackouts, reduce latency, enable low-latency applications of the communication network, increase lifespan of computing elements, among others.).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Mada with the system of Doshi and Bahramshahry and Sheehan to generate technical performance metrics. One having ordinary skill in the art would have been motivated to use Mada into the system of Doshi and Bahramshahry and Sheehan for the purpose of implementing self-regulating networks. (Mada paragraph 05).
As to claim 17, it is rejected based on the same reason as claim 7.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Bequet (US 2022/0167469 A1)
As per claim 9, Doshi teaches implement load balancing across multiple provider devices; monitor network health metrics in real-time; automatically failover to backup providers when performance degrades; (Doshi [0041] The IPU in the computing environment 510 may be coordinated with other network-connected IPUs. In an example, a Service and Infrastructure orchestration manager 530 may use multiple IPUs as a mechanism to implement advanced service processing schemes for the user stacks. This may also enable implementing of system functionalities such as failover, load balancing etc. [0043] As a second configuration, a particular IPU (e.g., IPU 514) can work with other IPUs (e.g., IPU 520) to perform load balancing across other systems. For example, consider a scenario where CDN traffic targeted to the local host is forwarded to another host in case that I/O or compute in the local host is scarce at a given moment. [0056] Functionality for Broker requests. The IPU may include Service Request Brokering logic and Load Balancing logic to perform brokering actions on arrival for requests of target services running in the local system. For instance, the IPU may decide to see if those requests can be executed by other peer systems (e.g., accessible through Service and Infrastructure Orchestration 630). This can be caused, for example, because load in the local systems is high. The local IPU may negotiate with other peer IPUs for the possibility to forward the request. Negotiation may involve metrics such as cost. Based on such negotiation metrics, the IPU may decide to forward the request. [0057] Functionality for Load Balancing requests. The Service Request Brokering and Load Balancing logic may distribute requests arriving to the local IPU to other peer IPUs. In this case, the other IPUs and the local IPU work together and do not necessarily need brokering. Such logic acts similar to a cloud native sidecar proxy. For instance, requests arriving to the system may be sent to the service X running in the local system (either IPU or compute platform) or forwarded to a peer IPU that has another instance of service X running The load balancing distribution can be based on existing algorithms such as based on the systems that have lower load, using round robin, etc. [0058] Functionality for failover, resiliency and reliability. The IPU includes Reliability and Failover logic to monitor the status of the services running on the compute platform or the status of the compute platform itself. The Reliability and Failover logic may require the Load Balancing logic to transiently or permanently forward requests that aim specific services in situations such as where: i) The compute platform is not responding; ii) The service running inside the compute node is not responding; and iii) The compute platform load prevents the targeted service to provide the right level of service level objectives (SLOs). Note that the logic must know the required SLOs for the services. Such functionality may be coordinated with service information 650 including SLO information
Doshi does not teach maintain technical logs of all resource transfers; generate system performance analytics.
However, Bequet teaches maintain technical logs of all resource transfers; generate system performance analytics. (Bequet [0121] The storage of objects (e.g., data objects, task routines, macros of task routines, job flow definitions, instance logs of past performances of job flows, and/or DAGs of task routines and/or job flows) may be effected using a grid of devices. Such a grid may provide distributed storage for data objects that include large data sets, complex sets of task routines for the performance of various analyses divided into tasks specified in job flows, and/or instance logs that document an extensive history of past performances of such analyses. Such distributed storage may be used to provide one or both of fault tolerance and/or faster access through the use of parallelism. In various embodiments, the objects stored within a federated area or a set of federated areas may be organized in any of a variety of ways that may employ any of a variety of indexing systems to enable access. By way of example, one or more databases may be defined by the one or more federated devices to improve efficiency in accessing data objects, task routines and/or instance logs of performances of analyses).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Bequet with the system of Doshi and Bahramshahry to maintain technical logs. One having ordinary skill in the art would have been motivated to use Bequet into the system of Doshi and Bahramshahry for the purpose of determining the status of a container job (Bequet paragraph 17)
Claims 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Zaykov (US 2023/0305888 A1).
As per claim 11, Doshi and Bahramshahry do not teach wherein the plurality of programming instructions further cause the processor to dynamically reassign priorities within the processing queue in response to changing system conditions or the emergence of high-priority resource requests.
However, Zaykov teaches wherein the plurality of programming instructions further cause the processor to dynamically reassign priorities within the processing queue in response to changing system conditions or the emergence of high-priority resource requests. (Zaykov [0109] Method 1200 includes block 1202 and receives information on workload budget constraints, for example, from workload launch requests received by a driver. When a currently executed workload runs out of budget, method 1200 proceeds to block 1203 and determines whether there is any additional processing budget remaining after processing workload on the coprocessor. If there is additional processing budget remaining, method 1200 proceeds to block 1204 and acquires the corresponding task budget from the completed workloads and additionally receives the priority of the completed workloads. From there, the additional budget and priority information can be used to process queued workloads during a subsequent timing interval. [0110] If no budget is available, then method 1200 proceeds to block 1206 to preempt and/or stop the currently executed workload. Optionally, method 1200 can then proceed to block 1208 and reschedule workloads for execution to the coprocessor. This example can be implemented when scheduling workloads according to the coprocessor scheduling policy as previously described. Additionally, or alternatively, method 1200 proceeds to block 1210 (either directly from block 1208 or from block 1206) to reassign the workload priority and optionally reschedule workloads for execution based on the updated workload priority)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Zaykov with the system of Doshi and Bahramshahry to dynamically reassign priorities. One having ordinary skill in the art would have been motivated to use Zaykov into the system of Doshi and Bahramshahry for the purpose of implementing a scheduling policy (Zaykov paragraph 10).
As to claim 19, it is rejected based on the same reason as claim 11.
Claims 12 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Liu (US 2020/0127828 A1).
As per claim 12, Doshi and Bahramshahry do not teach wherein the secure data channels implement, at least, end-to-end encryption, digital signatures, secure key exchange protocols, network traffic authentication, and/or automated intrusion detection.
However, Liu teaches wherein the secure data channels implement, at least, end-to-end encryption, digital signatures, secure key exchange protocols, network traffic authentication, and/or automated intrusion detection. (Liu [0071] In some embodiments, the agent 321 may be coupled to a key management system (KMS) 323. The KMS 323 may generate, distribute, and manage cryptographic keys for devices and applications. It may cover security aspects from secure generation of keys over the secure exchange of keys to secure key handling and storage. The functionalities of the KMS 323 may include key generation, distribution, and replacement as well as key injection, storing, and management. The KMS 323 may comprise or be coupled to a trusted execution environment (TEE). The TEE may be an isolated area on the main processor of a device that is separate from the main operating system. The TEE may provide an isolated execution environment offering security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets. It may guarantee code and data loaded inside to be protected with respect to confidentiality and integrity. In some embodiments, the KMS 323 may generate one or more cryptographic key pairs in the TEE. Before outputting the cryptographic key pair, the TEE may encrypt the private key. The encryption of the private key can be based on various methods or standards, such as Data Encryption Standard (DES), TripleDES, RSA, Advanced Encryption Standard (AES), Twofish, etc. The KMS 323 may store the encrypted private key in association with the public key. To use the private key, the KMS 323 may feed the encrypted private key to the TEE for decryption and processing. [0082] The user-side system 310 may also use the SDK 312 to generate a hash value of the blockchain transaction and generate a digital signature for the transaction using the private key associated with the DID. At step 620, the SDK 312 may send the DID document as well as the blockchain transaction to the DID resolver 322 for sending to the blockchain system. [0084] In some embodiments, a verifier 532 (e.g., a service provider needing to verify information of a customer) may initiate a DID authentication process using an SDK 312. At step 702, the verifier 532 may obtain the DID provided by a purported owner. At step 704, the verifier 532 may call the SDK 312 to create a DID authentication challenge. The verifier 532 may input to the SDK 312 the DID to be authenticated and a network address (e.g., a URL) to which a response to the challenge is to be sent [0088] In some embodiments, the verifier 532 may call its version of an SDK 312 to authenticate the DID included in the signed service request at step 808. At step 810, the SDK 312 may obtain the DID and the digital signature included in the signed service request. In case the signed service request is an HTTP request, the DID and the digital signature may be obtained from the header of the HTTP request. At s)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Liu with the system of Doshi and Bahramshahry to use end-to-end encryption. One having ordinary skill in the art would have been motivated to use Liu into the system of Doshi and Bahramshahry for the purpose of managing decentralized identifiers based on blockchain technology. (Liu paragraph 02)
As to claim 22, it is rejected based on the same reason as claim 12.
Claims 13 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Kim (US 2021/0365366 A1) and Mada (US 2024/0372777 A1).
As per claim 13, Doshi and Bahramshahry do not teach wherein the plurality of programming instructions further cause the processor to, at least, maintain a distributed cache of frequently allocated resources, implement predictive resource scaling, optimize network paths between providers and requesters, monitor system-wide resource utilization patterns, and/or generate efficiency metrics.
However, Kim teaches wherein the plurality of programming instructions further cause the processor to, at least, maintain a distributed cache of frequently allocated resources (Kim [0012] Furthermore, according to technologies disclosed in the disclosure, a resource associated with a function frequently used by the user may be cached to efficiently use a system resource.)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Kim with the system of Doshi and Bahramshahry to maintain a distributed cache. One having ordinary skill in the art would have been motivated to use Kim into the system of Doshi and Bahramshahry for the purpose of implementing resource caching technology. (Kim paragraph 01)
Kim does not teach implement predictive resource scaling and optimize network paths between providers and requesters, monitor system-wide resource utilization patterns, and/or generate efficiency metrics.
However, Mada teaches implement predictive resource scaling (Mada [0005] This document describes technology that provides self-regulating networks (also referred to herein as self-optimizing networks) where a machine-learning model is trained to predict usage of computing resources in a given network as a function of time and use those predictions to preemptively adjust the amount of computing resources deployed to administer the network. In this way, the technology described herein can avoid system failures—e.g., network outages resulting from inadequate processing resources—while also avoiding resource/energy wastage by substantially optimizing the amount of computing resources as a function of time. This in turn can also decrease response latency—e.g., latency caused by system crashes or computing resources having to temporarily store requests until sufficient processing resources becomes available—without having to run/maintain redundant computing resources. In general, the self-optimizing or self-regulating networks described herein can provide for dynamically scaling network computing resources substantially in real time in accordance with the demands of the network. Computing resources can be scaled per network, per use case, or per real time traffic, among others. For example, one or more networks running within a larger network can be scaled up or down to optimize the given network. Network resources for a specific use case or type of network usage (e.g., for a given identified user or users or a given identified type of network activity or types of network activity) can similarly be scaled. Optimization can be performed for to scale up or down any number of network computing resources, e.g., for any type of real time traffic received for one or more networks.)., optimize network paths between providers and requesters, monitor system-wide resource utilization patterns, and/or generate efficiency metrics. (Mada [0007] Advantageous implementations can include one or more of the following features. For example, instead of retroactively addressing inefficiencies due to system failures and delays, the proposed technology can preemptively control computing resources to adjust for predicted demand based on historical data. Techniques described enable the use of historical data-including parameters from performance logs of computing resources, such as processing capacity, utilization, failure rate, processing bandwidth, among others—to train a machine learning model and to use the trained machine learning model to optimize one or more communication networks. By optimizing the computing resources of a communication network, the techniques described in this document, compared to traditional techniques, can help reduce power consumption in the sector, reduce data or voice request failures or blackouts, reduce latency, enable low-latency applications of the communication network, increase lifespan of computing elements, among others.[0020] In stage B, the control unit 110 obtains information indicating performance metrics of the computing resources in area 1 112 and area N 114—e.g., performance logs 116a and 116b. As discussed, in general, the system 100 can include one or more computing resources. The control unit 110 can obtain the information from the RAN 106 or directly from one or more devices of the computing resources in area 1 112 and area N 114. The control unit 110 can be communicably connected to both the RAN 106, other RANs not shown, or the computing resources in area 1 112 and area N 114.).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Mada with the system of Doshi and Bahramshahry and Kim to implement predictive resource scaling. One having ordinary skill in the art would have been motivated to use Mada into the system of Doshi and Bahramshahry and Kim for the purpose of implementing self-regulating networks. (Mada paragraph 05)
As to claim 23, it is rejected based on the same reason as claim 13.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Ponkanen (US 2022/0337591 A1)
As per claim 15, Doshi teaches monitoring real-time resource utilization request metrics across allocated connections; (Doshi [0126] The distributed resource database is kept approximately current by asynchronous updates from various parts of the distributed infrastructure. The distributed resource database is also updated by local software at each IPU that refreshes a local copy of the distributed database according to types of resources most frequently used or most recently requested in order to map computations to them. Thus, the IPU proximal to the requestor computes a list of ‘N’ best candidates, by overall estimated latency, capacity, etc. for the logical computations being requested for assigning to resources at large (security and other criteria may also play a role in such mapping). The criteria for selecting the list of ‘N’ best candidates depend on the application requestor's criteria in operation 952).
detecting insufficient resource availability from a first provider device; automatically identifying additional provider devices with matching affinity indicators and resource capabilities; redistributing resource allocation across multiple provider devices; (Doshi [0041] The IPU in the computing environment 510 may be coordinated with other network-connected IPUs. In an example, a Service and Infrastructure orchestration manager 530 may use multiple IPUs as a mechanism to implement advanced service processing schemes for the user stacks. This may also enable implementing of system functionalities such as failover, load balancing etc. [0043] As a second configuration, a particular IPU (e.g., IPU 514) can work with other IPUs (e.g., IPU 520) to perform load balancing across other systems. For example, consider a scenario where CDN traffic targeted to the local host is forwarded to another host in case that I/O or compute in the local host is scarce at a given moment. [0056] Functionality for Broker requests. The IPU may include Service Request Brokering logic and Load Balancing logic to perform brokering actions on arrival for requests of target services running in the local system. For instance, the IPU may decide to see if those requests can be executed by other peer systems (e.g., accessible through Service and Infrastructure Orchestration 630). This can be caused, for example, because load in the local systems is high. The local IPU may negotiate with other peer IPUs for the possibility to forward the request. Negotiation may involve metrics such as cost. Based on such negotiation metrics, the IPU may decide to forward the request. [0057] Functionality for Load Balancing requests. The Service Request Brokering and Load Balancing logic may distribute requests arriving to the local IPU to other peer IPUs. In this case, the other IPUs and the local IPU work together and do not necessarily need brokering. Such logic acts similar to a cloud native sidecar proxy. For instance, requests arriving to the system may be sent to the service X running in the local system (either IPU or compute platform) or forwarded to a peer IPU that has another instance of service X running The load balancing distribution can be based on existing algorithms such as based on the systems that have lower load, using round robin, etc. [0058] Functionality for failover, resiliency and reliability. The IPU includes Reliability and Failover logic to monitor the status of the services running on the compute platform or the status of the compute platform itself. The Reliability and Failover logic may require the Load Balancing logic to transiently or permanently forward requests that aim specific services in situations such as where: i) The compute platform is not responding; ii) The service running inside the compute node is not responding; and iii) The compute platform load prevents the targeted service to provide the right level of service level objectives (SLOs). Note that the logic must know the required SLOs for the services. Such functionality may be coordinated with service information 650 including SLO information)
Doshi does not teach implement predictive resource scaling for simultaneous resource transfer.
However, Ponkanen teaches implement predictive resource scaling for simultaneous resource transfer. (Ponkanen [0006] A single SSH connection can host multiple channels simultaneously for transferring data in both directions. Channel requests are used to relay out-of-band channel-specific data)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Ponkanen with the system of Doshi and Bahramshahry to implement predictive resource scaling. One having ordinary skill in the art would have been motivated to use Ponkanen into the system of Doshi and Bahramshahry for the purpose of controlling the execution of commands in a network environment. (Ponkanen paragraph 01)
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Doshi (US 2023/0136048 A1) in view of Bahramshahry (US 2020/0026579 A1) in further view of Carmack (US 12,034,740 B1)
As per claim 21, Doshi and Bahramshahry do not teach implementing virtual resource containers; managing resource allocation lifecycles; monitoring container health metrics; automatically scaling resources based on utilization; maintaining technical audit logs of container operations.
However, Carmack teaches implementing virtual resource containers; managing resource allocation lifecycles; monitoring container health metrics; automatically scaling resources based on utilization; maintaining technical audit logs of container operations. (Carmack [col 14, lines 43-63] The telemetry service 212 may be configured to aggregate control group metrics (e.g., information about the processes running within the containers) and container logs and provide the aggregated metrics and logs to a resource monitoring service to allow the customers 202 to monitor resource utilization, such as processor, storage, and network usage, of their respective container instances. Control group metrics include information, such as the amount of memory used by processes of the containers, number of times that a process triggered a page fault, central processing unit usage by the processes of the containers, time during which the central processing units were executing system calls on behalf of processes of the containers, number of reads and writes by the processes of the containers, and number of input/output operations queued for the processes of the containers. In some implementations, the telemetry service 212 may obtain its data directly from one or more agents, such as the agent 222. In other implementations, the telemetry service 212 may obtain its data indirectly from one or more agents, such as through the front-end service 204 or through a connection (not shown) to the database 216. And [col 15, lines 62-66 and col 16, lines 1-9] The container service 200 may be integrated with other services of a computing resource service provider. For example, the container instances may be tagged and/or assigned to an auto-scaling group of an auto-scaling service of the computing resource service provider. In this manner, the auto-scaling service may monitor resource usage by the container instances and may dynamically adjust/allocate resources as needed, such as a sudden increase in resource demand by the container instances. Likewise, the container service 200 may integrate with a load-balancer service of the computing resource service provider. For example, the load-balancer service may distribute traffic to the containers or container instances in order to balance the workload between the container instances)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Carmack with the system of Doshi and Bahramshahry to implement virtual resource containers. One having ordinary skill in the art would have been motivated to use Carmack into the system of Doshi and Bahramshahry for the purpose of mitigation of security threats in a distributed computing environment that performs self-optimizing, dynamic migration of applications. (col 1, lines 57-60)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20160072781 A1 – discloses supporting differentiated secure communications among heterogeneous electronic devices. A communication port communicates via communication networks of different types with two or more associated devices having diverse secure communication capabilities. The gateway logic selectively authenticates the associated devices for group membership into a Secure Communication Group (SCG), and selectively communicates Secure Communication Group Keys (SCGKs) to the devices having the diverse secure communication capabilities for selectively generating session keys locally by the associated devices for mutual secure communication in accordance with the group membership of the associated devices in the SCG.
US 20240378107 A1 – discloses media for intelligent webhook are described herein. The intelligent webhook can insert code into one or containers associated with an application being deployed by an orchestration service. The code enables the intelligent webhook to monitor operations, including startup, of a container mutated to include the code. The intelligent webhook has knowledge of whether a mutated container failed to startup in a prior instance, and if it fails, the intelligent webhook can insert a modified version of the code and/or adjust resource limit constraints to facilitate mutation of a container scheduled to be deployed with an application.
US 11892996 B1 – discloses monitoring indexing nodes, populating and maintaining a resource catalog with relevant information, receiving requests for indexing node availability or assignments, identifying indexing nodes that are available to process data, and/or communicating information relating to available indexing nodes. The system can maintain the resource catalog based on communications with each of the containerized indexing nodes. The system can receive, from a partition manager of a data intake and query system, a request for a containerized indexing node that the partition manager can assign to process data received by the partition manager. The system can identify an available containerized indexing node to process the data. The system can communicate, to the partition manager, an indexing node identifier associated with the available containerized indexing node.
US 20230044756 A1 – discloses a resource splitter to determine a quantity of blocks to divide a resource to be downloaded. A transmitter of the system broadcasts, per block, an identification request through a peer-to-peer network to identify computing devices that have the block. A downloader of the system downloads blocks from other computing devices on the peer-to-peer network. The system also includes an assembler to re-assemble the resource from received blocks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/ Primary Examiner, Art Unit 2196
Prosecution Insights