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
This Office Action is in response to the amendment filed 12/01/2025.
Claims 1-20 are pending in this application.
Claims 1,8 and 15 are independent claims.
Claims 1-4, 6, 8-11, 13, 15-18, and 20 are currently amended.
This Office Action is made final.
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 1,7,8,14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (US 2021/0271489 Al) in view of Stokes (US 2021/0400083 A1)
As per claim 1, Singhal teaches A non-transitory computer readable storage medium comprising instructions to cause one or more processors to at least: (Singhal [0106] Common forms of computer readable media include any non-transitory computer readable medium)
identify a requested domain associated with the request; generate a replacement request with an adjusted domain; (Singhal [0077] High availability is facilitated by assigning a failover follower node that is in network communication with the leader node. The leader node and follower node each execute a protocol where a heartbeat signal is exchanged on a periodic basis. As shown by message 511, node.sub.11 sends a heartbeat signal (e.g., a network packet) to node.sub.21. Similarly, and as shown by message 522, node.sub.21 sends a heartbeat signal (e.g., a network packet) to node.sub.11. If it happens that a heartbeat signal is not received within a set amount of time, then the node that did not receive the heartbeat signal will modify the DNS entries such that microservice calls can be routed to a node that is deemed to be operational. [0079] After preparing to take over the high-availability provision of the microservices, the follower accesses the determined DNS server and changes the IP addresses and ports to refer to itself (step 518). Thereafter, when a microservices client calls a microservice via the microservice's FQDN, the DNS server routes the call via the routing path to follower 512.)
in response to the replacement request with the adjusted domain resolving, load a container corresponding to the workload based on a response to the replacement request from the server; (Singhal [0026] To accommodate microservice bootstrapping—where an infrastructure microservice that is needed by a corresponding infrastructure application needs to be brought up—a microservices deployment packager assembles the needed components, including a microservices container registry, into an executable installer such that, upon execution of the executable installer, some or all of the components that are loaded into the executable installer execute so as to configure the computing system node on which the microservices are to be brought up [0049] In this embodiment, the node-local registry is made accessible at an a priori known local IP such that, using the code that implements at least a portion of the domain name services, a node-local DNS can be configured to resolve from a certain specific domain name address (e.g., the FQDN of the microservice) to a node-local IP address. Using the installation package, a second series of steps is executed to install additional components (step 208) and invoke the microservice, which in turn can access the registry through the node-local DNS. In this sense, and as used herein, the term bootstrapping refers an ability of a computing node to self-install code and data from an installation package. More specifically, the term bootstrapping, in the context of the present disclosure refers to bringing up a local microservices container registry onto a target node by having the target node execute an installation package to extract and install all of the components that would be needed for an infrastructure microservice to run)
re-route the request to execute the workload to a target internet protocol (IP) address resolved by the requested domain to an address of the loaded container to execute the workload locally. (Singhal Fig 6 block 612-1 (Change IP address and port DNs entry to the Ip address and port the local microservices registry) and [0080] In high-availability scenarios, and responsive to a loss of communication between the leader node and the follower node, the follower node changes entries in the DNS server that is serving the cluster. Changes to the DNS server record (e.g., changes to the IP and port for the microservices container registry, as shown in DNS entries 501.sub.B) serve to refer to a node-local IP address of the microservices container registry at the follower node (e.g., Node.sub.2N, as shown). Inasmuch as any of the microservices (e.g., MS1, MS2, etc.) are hosted at the follower node, a corresponding DNS entry for those microservices are changed as well to refer to node-local IP address of the microservices that are hosted at the follower node (e.g., Node.sub.2N, as shown))
Singhal does not teach intercept a request to execute a workload.
However, Stokes teaches intercept a request to execute a workload: (Stokes [0046] In step 402, the monitoring device 102 may intercept (e.g., by the receiving device 202) network packets included in a request for a web resource between the first network 118, such as from one or more client devices 106, and the second network 120, such as to the Internet 112 and/or a computing device 11 [0040] As requests are intercepted by the monitoring device 102, the destination domain for a request may be first converted to a different form. This may be achieved by removing any subdomains from the destination domain down to the top-level ICANN-recognized domain suffix, then prepending the suffix with the first subdomain. For instance, “static.nytimes.com” may first be stripped of its leading subdomains “static” and “nytimes” leaving behind the ICANN domain suffix, “.com”. The latter subdomain, “nytimes” is then concatenated with the ICANN suffix, resulting in “nytimes.com”. Such a process may be used when maintaining the first and third party domain lists, which may be stored in a first memory cache and a second memory cache in the memory 206 of the monitoring device 102, respectively.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Stokes with the system of Singhal to intercept a request to execute a workload. One having ordinary skill in the art would have been motivated to use Stokes into the system of Singhal for the purpose of converting a destination domain for a request to a different form (Stokes paragraph 40)
As per claim 7, Stokes teaches wherein the one or more processors are included an end user computing device. (Stokes [0015] The system 100 may also include a router 104 or other gateway computing device, and one or more client devices 106. Client devices 106 may be any type of computing device or program executed thereby that is an endpoint for communications in a communication network, such as a desktop computer 106a, web browsing application program 106b, smart phone 106c, or any other suitable type of computing device as discussed herein.)
The examiner is interpreting this end user device according to what is disclosed in the specification ([0018] to client devices associated with end users and/or consumers (e.g., for license, sale, and/or use)
As to claims 8 and 15, they are rejected based on the same reason as claim 1.
As to claim 14, it is rejected based on the same reason as claim 7.
Claims 2,9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (US 2021/0271489 Al) in view of Stokes (US 2021/0400083 A1) in further view of Seedorf (US 2015/0134730 A1).
As per claim 9, Singhal and Stokes do not teach wherein the processor circuitry is to generate the adjusted domain by prepending a subdomain of the requested domain.
However, Seedorf teaches wherein the processor circuitry is to generate the adjusted domain by prepending a subdomain of the requested domain. (Seedorf [0021] In order to avoid the above problem, according to a preferred embodiment it may be provided that the information about the client terminal is encoded within the client terminal's DNS request as a subdomain in the DNS tree. This comes along with the advantage that no modifications of existing DNS protocol specifications are required, since the subdomain can just be prepended to the requested domain)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Seedorf with the system of Singhal and Stokes to prepend a subdomain. One having ordinary skill in the art would have been motivated to use Seedorf into the system of Singhal and Stokes for the purpose of responding to DNS requests from client terminals by sending a DNS response. (Seedorf paragraph 02)
As to claims 2 and 16, they are rejected based on the same reason as claim 9.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (US 2021/0271489 Al) in view of Stokes (US 2021/0400083 A1) in further view of Thireault (US 2013/0080626 A1).
As per claim 10, Singhal and Stokes do not teach determine whether resources of the apparatus are sufficient to execute the workload locally, and re-route the request to execute the workload to the target IP address in response to determining that the resources of the apparatus are sufficient to execute the workload locally.
However, Thireault teaches determine whether resources of the apparatus are sufficient to execute the workload locally, and re-route the request to execute the workload to the target IP address in response to determining that the resources of the apparatus are sufficient to execute the workload locally. (Thireault [0029] Alternatively, if there is a container identified as running the application, then a determination is made whether the container has sufficient resources to handle the increased load of the new request (decision block 325). If the container does not have sufficient resources to handle the increased load, then at process block 335, a container (or containers) may be spun-up to run the identified application. Alternatively, if the container has sufficient resources to handle the increased load, then at process block 340, the request is routed to the compute platform with the container already running the identified application. As such, the load is effectively balanced to the compute platform and container with available resources from the edge server with the closest physical proximity to the requesting device; thus, providing the most efficient user experience).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Thireault with the system of Singhal and Stokes to determine that the resources of the apparatus are sufficient to execute the workload locally. One having ordinary skill in the art would have been motivated to use Thireault into the system of Singhal and Stokes for the purpose of dynamically routing requests for applications to one of multiple cloud computing environments. (Thireault paragraph 08)
As to claims 3 and 17, they are rejected based on the same reason as claim 10.
Claims 4,5,11,12,18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (US 2021/0271489 Al) in view of Stokes (US 2021/0400083 A1) in further view of Stowe (US 2015/0286508 A1) and Salsburg (US 2011/0270968 A1).
As per claim 11, Singhal and Stokes do not teach determine that a subset of workloads scheduled to be executed at the server, the subset of workloads including the workload.
However, Stowe teaches determine that a subset of workloads scheduled to be executed at the server, the subset of workloads including the workload; (Stowe [0044] The processes and components in this exemplary embodiment begin when a job submission is committed to a particular cluster unit, there is an opportunity for further load balancing. Although the bulk of the workload is designated for the remote cluster unit, a subset of the workload may be carved off to run on local resources that are immediately available, decreasing the overall runtime as in block 402)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Stowe with the system of Singhal and Stokes to determine a subset of the workloads should be executed. One having ordinary skill in the art would have been motivated to use Stowe into the system of Singhal and Stokes for the purpose of automatically directing load away from busy distributed computing environments to idle environments and/or environments that are dynamically scalable. (Stowe paragraph 01)
Stowe does not teach the workloads of the subset of workloads based on at least one of privacy or end user concerns.
However , Salsburg teaches rank the workloads of the subset of workloads based on at least one of privacy or end user concerns.(Salsburg [0037] FIG. 2 shows a flow diagram of a method 200 for moving one or more computing workloads to a public cloud environment, in accordance with certain exemplary embodiments. Referring to FIGS. 1 and 2, in step 210, workloads for an organization or other entity are identified and analyzed to determine the suitability of the workloads for being moved to a public cloud environment. The web server 107 can receive information regarding the workloads and create a workload profile for each workload including the received information. This information for a workload can include business attributes and technology attributes of that workload, or any other information regarding the workload. The workload profiles can be stored in a data storage unit, such as the workload database 111. The analytics server 115 can access the stored workload profiles and analyze the business attributes of the workloads and classify each workload into specific categories (e.g., enterprise-class or commodity-class) based on the business and technology attribute analysis. For example, a computing workload may be classified as an enterprise-class workload or a commodity-class workload based on the workload's business attributes. The analytics server 115 can also analyze the technology attributes of each workload and assign a score or ranking to each workload based on the suitability of that workload for being moved to a public cloud environment. This score or ranking can be based on the classification and on the technology attributes of the workload. Step 210 is described in further detail in connection with FIG. 3).
Privacy and end user concerns are not defined in the specification. They will be treated broadly and as commonly understood.
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Salsburg with the system of Singhal and Stokes and Stowe to rank the workloads. One having ordinary skill in the art would have been motivated to use Salsburg into the system of Singhal and Stokes and Stowe for the purpose of identifying suitable workloads to move to a cloud computing environment. (Salsburg paragraph 02)
As per claim 12, Salsburg teaches wherein the processor circuitry is to select the workload based on the rank. (Salsburg [0023] Computing workloads may be identified and analyzed to determine whether the workloads are suitable for moving to a cloud computing environment. Analyzing a workload may include classifying the workload into a category, such as enterprise-class or commodity-class, based on attributes (e.g., business attributes) of the workload. Analyzing a workload may also include identifying and analyzing technology attributes (e.g., data size, whether a physical to virtual conversion is necessary, required operating system, etc.) of the workload. Each workload may be assigned a score or a ranking based on these analyses that identifies how suitable the workload is for being moved to a cloud computing environment. [0025] The rankings for the workloads and the rankings for the public clouds can be used to find a best-fit cloud for each workload that is determined to be suitable for moving to or hosting in a public cloud environment. The appropriate workloads can then be moved to their respective `best-fit` public clouds [0037] For example, a computing workload may be classified as an enterprise-class workload or a commodity-class workload based on the workload's business attributes. The analytics server 115 can also analyze the technology attributes of each workload and assign a score or ranking to each workload based on the suitability of that workload for being moved to a public cloud environment. This score or ranking can be based on the classification and on the technology attributes of the workload. Step 210 is described in further detail in connection with FIG. 3.).
As to claims 4 and 18, they are rejected based on the same reason as claim 11.
As to claims 5 and 19, they are rejected based on the same reason as claim 12.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Singhal (US 2021/0271489 Al) in view of Stokes (US 2021/0400083 A1) in further view of Salsburg (US 2011/0270968 A1).
As per claim 13, Singhal and Stokes do not teach wherein the workload is designed to be executed at the server.
However, Salsburg teaches wherein the workload is designed to be executed at the server. (Salsburg [0023] Computing workloads may be identified and analyzed to determine whether the workloads are suitable for moving to a cloud computing environment. Analyzing a workload may include classifying the workload into a category, such as enterprise-class or commodity-class, based on attributes (e.g., business attributes) of the workload. Analyzing a workload may also include identifying and analyzing technology attributes (e.g., data size, whether a physical to virtual conversion is necessary, required operating system, etc.) of the workload. Each workload may be assigned a score or a ranking based on these analyses that identifies how suitable the workload is for being moved to a cloud computing environment. [0025] The rankings for the workloads and the rankings for the public clouds can be used to find a best-fit cloud for each workload that is determined to be suitable for moving to or hosting in a public cloud environment. The appropriate workloads can then be moved to their respective `best-fit` public clouds [0037] For example, a computing workload may be classified as an enterprise-class workload or a commodity-class workload based on the workload's business attributes. The analytics server 115 can also analyze the technology attributes of each workload and assign a score or ranking to each workload based on the suitability of that workload for being moved to a public cloud environment. This score or ranking can be based on the classification and on the technology attributes of the workload. Step 210 is described in further detail in connection with FIG. 3.).
Examiner is not sure what is meant “being designed” to be executed at the server. The examiner is relying on the following paragraph to try to understand what that means ([0073] Although the example of FIG. 7 includes the client/client/edge computing device 704 to pull containers to execute the workload 720 designed for execution at the cloud backend 701, FIG. 7 may be described in conjunction with any device capable of pulling containers to execute a workload from another device that the workload was designed by be executed at).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Salsburg with the system of Singhal and Stokes to determine that the workload should be run at the server. One having ordinary skill in the art would have been motivated to use Salsburg into the system of Singhal and Stokes for the purpose of identifying suitable workloads to move to a cloud computing environment. (Salsburg paragraph 02)
As to claims 6 and 20, they are rejected based on the same reason as claim 13.
Response to Arguments
Applicant's arguments filed on 12/01/2025 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claims 1, 8 and 15 have been considered but are moot because the arguments do not apply because of the introduction of new art by Singhal and Stokes.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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