DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in response to the Preliminary Amendment filed on February 28, 2025, in which claims 4, 5, 12, 13, 15 and 18-20 have been amended. Accordingly, claims 1-20 are pending and being presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims 1-3, 5-11 and 13-18 are rejected under 35 U.S.C. 103. Claims 1-6 are also rejected under 35 U.S.C. 101.
Priority
4. Examiner has acknowledged Applicant’s claim for the benefit of International Patent Application No. PCT/CN2023/075015, filed February 8, 2023.
5. Acknowledgment is made of Applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e). Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Information Disclosure Statement
6. The information disclosure statements, filed on December 30, 2024 and February 21, 2025, are in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. They have been placed in the application file, and the information referred to therein has been considered as to the merits.
Claim Objections
7. Claims 2, 8 and 16 are objected to because of the following informalities: Regarding dependent claim 2, the limitation, “wherein a first site identifier, the first microservice identifier, the API identifier, and the first site identifier are all dedicated identifiers in the multi-site cascading system,” on lines 3-4, should be changed to ‘wherein a first site identifier, the first microservice identifier, and the API identifier8 and 16. Appropriate correction is required.
Claim Rejections - 35 USC § 101
8. 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.
9. Claims 1-6 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
“A claim whose BRI covers both statutory and non-statutory embodiments embraces subject matter that is not eligible for patent protection and therefore is directed to non-statutory subject matter. Such claims fail the first step (Step 1: NO) and should be rejected under 35 U.S.C. 101, for at least this reason”. See MPEP, 2106.03 II, Revision June 2020 [R-10.2019]
As per claim 1, it appears that claim 1 would reasonably be interpreted by one of ordinary skill in the art as a “multi-site cascading system” of “software per se,” failing to fall within a statutory category of invention. While recited as a “multi-site cascading system” comprising a “first site” and a “second site,” nevertheless the recited “sites” can reasonably be interpreted by the skilled artisan as “websites,” since it is perfectly reasonable for a first website to receive an invocation request from a second website (e.g., a redirect), through a “dedicated channel” such as HTTPS. Moreover, the recited “invocation request” can be interpreted as invoking either an “API” or “microservice” (Examiner also notes the use of drafting in the alternative “or”), of the first “website”. As well, it is well-known that a first website can call (or “invoke”) another website using a backend server-to-server API, and that the other website can respond in like fashion. Thus, such a “system” alone (a claimed apparatus comprising software units/applications alone) is not a machine, and it is clearly not a process, manufacture nor composition of matter. Therefore the claim is not limited to statutory subject matter and is therefore nonstatutory (Examiner respectfully suggests that the claim should be amended to avoid a rejection under 35 U.S.C. § 101 by adding the limitation “a CPU coupled to a memory” to the claim). Dependent claims 2-6 fail to remedy the deficiencies of independent claim 1 and are therefore similarly rejected.
Claim Rejections - 35 USC § 103
10. 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 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.
11. 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.
12. Claims 1, 3, 5-7, 9-11, 15, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Thakkar et al. (United States Patent Application Publication No. US 2021/0203550 A1), hereinafter “Thakkar” in view of Panikkar et al. (United States Patent Application Publication No. US 2023/0004427 A1), hereinafter “Panikkar”.
As to claim 1, Thakkar discloses a multi-site cascading system comprising a first site and a second site (See FIG. 3, illustrating three disparate data centers (i.e., “sites”), an edge data center 103, a regional data center 102 and a core data center 101, each communicatively connected to orchestration server 201) (Thakkar, FIG. 3, paragraph [0033]), wherein the first site is configured to receive, through a dedicated channel between the first site and the second site (wherein each of the data centers include a local control plane 250 configured to communicate with multi-VIM adapter 220 of orchestration server 201, using Internet-based traffic via a VPN tunnel established between them, or alternatively, via a direct, dedicated link, to enable multi-site virtual infrastructure orchestration of network services. See also FIG. 4, illustrating gateway 484, which may be configured to provide virtual private network (VPN) connectivity over the external network with another VPN endpoint, such as orchestration server 201) (Thakkar, FIGS. 3 and 4, paragraphs [0050] and [0051]), an invocation request sent by the second site (wherein the orchestration server 201, using central orchestrator 210 and multi-VIM adapter 220, provides network service orchestration tasks for the data centers. In particular, central orchestrator 210 generates commands for multi-VIM adapter 220 based on extracted information from network service descriptors and issues the commands to multi-VIM adapter 220. Multi-VIM adapter 220 then generates a set of generic commands to be issued to various, selected cloud computing data centers of the 5G network) (Thakkar, FIGS. 3 and 4, paragraphs [0034]-[0035] and [0038]), wherein the invocation request indicates to invoke one or both of a first microservice and an application programming interface (API) in the first site (wherein FIG. 4 illustrates a cloud computing environment 470 in detail, of one of the data centers, particularly edge data center 103. With reference to FIG. 5, Thakkar further illustrates different software modules of a local control plane 250 (representative of one of LCPs 250a, 250b, 250c, in each of respective data centers 101, 102 and 103). LCP 250 includes a hybrid remoting service 510 for handling communications with multi-VIM adapter 220. Hybrid remoting service 510 is responsible for breaking down the generic commands issued by multi-VIM adapter 220 into instructions to be executed by worker nodes that are depicted in FIG. 5 as microservices (MS) 521, 522, 523, 524. Thakkar teaches that the microservices may be run in one virtual machine within individual containers, and translate a generic command with one or more parameters into one or more APIs in the format that is recognized by the underlying VIM to which VIM-specific adapter 520 is connected. In one embodiment, MS 521 handles the translation of a generic command with one or more parameters into compute APIs recognized by the underlying VIM, and MS 522 handles the translation of a generic command with one or more parameters into storage APIs recognized by the underlying VIM) (Thakkar, FIGS. 4 and 5, paragraphs [0047], [0048] and [0052]); the first site is further configured to invoke the one or both of the first microservice and the API based on the invocation request (wherein again, the generic commands that come in are translated by the appropriate microservice, into the appropriate API) (Thakkar, FIG. 5, paragraph [0052]). Thakkar does not explicitly disclose that the first site is further configured to send an invocation request response to the second site through the dedicated channel. However in analogous art, Panikkar discloses that a first site is further configured to send an invocation request response to a second site through a dedicated channel (wherein FIG. 1 illustrates an information processing system 100 including a number of host devices 102-1, 102-2, . . . 102-N assumed to run respective software container instances 120-1, 120-2, . . . 120-N (collectively, software container instances 120) in which respective microservices 122-1, 122-2, . . . 122-N (collectively, microservices 122) execute. The microservices 122 are provisioned by orchestrator microservice 142, which executes on container instance 140, as part of management host device 104. FIG. 3 shows an example of orchestration-based microservices coordination, where an orchestrator microservice 301 exchanges requests and responses with a set of microservices 303-1, 303-2, . . . 303-S (collectively, microservices 303). Panikkar teaches that such requests and responses may include regular or conventional service calls that are exchanged between the orchestrator microservice 301 and participating microservices 303, and that such service calls may include, e.g., service initiation or request calls issued by the orchestrator microservice 301 to the participating microservices 303, and service response calls sent from the participating microservices 303 to the orchestrator microservice 301) (Panikkar, FIGS. 1 and 3, paragraphs [0033] and [0056]). Thakkar and Panikkar are analogous art because they are from the same field of endeavor, namely, management of microservices in cloud-based virtualization infrastructures. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Thakkar and Panikkar before him or her, to modify the network functions virtualization (NFV) platform of Thakkar to include the additional limitation of a first site is further configured to send an invocation request response to a second site through a dedicated channel, as disclosed by Panikkar, with reasonable expectation that this would result in an orchestration framework having the added benefit of being able to recreate an execution context for a given microservice in the event of failure, and to re-initiate the given microservice to start its job from where it stopped rather than start from the beginning (See Panikkar, paragraph [0058]). This method of improving the network functions virtualization (NFV) platform of Thakkar was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Panikkar. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Thakkar with Panikkar to obtain the invention as specified in claim 1.
Claim 15 is directed to “an invocation device comprising a non-transitory memory and a processor, wherein the non-transitory memory is configured to store instructions, and the processor is configured to execute the stored instructions so that the invocation device is configured to” perform limitations substantially as recited in independent “multi-site cascading system” claim 1, and does not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, as Thakkar-Panikkar discloses such a non-transitory memory (non-transitory computer-readable storage medium comprising instructions) (Thakkar, paragraphs [0011] and [0124] and claim 19) and a processor (computer system configurations including processors/microprocessors) (Thakkar, paragraph [0123]), claim 15 is thus rejected under the same rationale.
In addition, claim 7 includes a “method” claim that performs limitations substantially as recited in “multi-site cascading system” claim 1, and does not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, it is rejected under the same rationale.
As to claim 3, Thakkar-Panikkar discloses the multi-site cascading system according to claim 1, wherein the invocation request comprises a uniform resource locator (URL) that indicates the first microservice or the API in the first site (wherein a REST API call is made to a URL of a license server) (Thakkar, paragraph [0076]). The motivation regarding the obviousness of claim 1 is also applied to claim 3.
Regarding claim 5, Thakkar-Panikkar discloses the multi-site cascading system according to claim 1, further comprising a cascading management platform (again, orchestration server 201, providing a main management interface for a network service provider) (Thakkar, FIG. 3, paragraph [0034]), and wherein the dedicated channel between the first site and the second site and/or a dedicated channel between the first site and a third site are/is established according to an indication of the cascading management platform (again, local control planes (LCPs 250) of each data center 101, 102, 103 communicating with multi-VIM adapter 220 of orchestration server 201 using Internet-based traffic via a VPN tunnel established between them or a dedicated link. In particular, central orchestrator 201 includes WAN infrastructure manager (WIM) 215 (See also, FIG. 18) that communicates with LCPs 250 of different data centers to provision the virtual links for a network service according to the descriptor of the network service) (Thakkar, FIGS. 3 and 18, paragraphs [0051] and [0106]). The motivation regarding the obviousness of claim 1 is also applied to claim 3.
Regarding claim 6, Thakkar-Panikkar discloses the multi-site cascading system according to claim 5, wherein the first site, the second site, the third site, and the cascading management platform are located in a same cloud data center or a plurality of cloud data centers (wherein again, with the exception of the orchestration server 201 that is connected to, though separate from, each of data centers 101, 102, 103 (See again, FIG. 3), each of the “sites” are disparate data centers 101, 102, 103, and as such, the “sites” are located in a plurality of separate data centers) (Thakkar, FIG. 3, paragraph [0033]); and based on the first site, the second site, the third site, and the cascading management platform being located in the plurality of cloud data centers, one or any combination of the first site, the second site, the third site, and the cascading management platform is disposed in one of the plurality of cloud data centers (again, Examiner is interpreting each “site” as a single data center, and as such, each site is disposed therein) (Thakkar, FIG. 3, paragraph [0033]). The motivation regarding the obviousness of claim 1 is also applied to claim 6.
Claims 9, 10 and 11 include “method” claims that perform limitations substantially as recited in “multi-site cascading system” claims 3, 5 and 6, respectively, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
Claims 17 and 18 are directed to “invocation device” claims that perform limitations substantially as recited in “multi-site cascading system” claims 3 and 5, respectively, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
13. Claims 2, 8, 13, 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Thakkar-Panikkar, and further in view of LIANG et al. (United States Patent Application Publication No. US 2026/0056813 A1), hereinafter “LIANG”.
Regarding claim 2, Thakkar-Panikkar discloses the multi-site cascading system according to claim 1. Thakkar-Panikkar further discloses wherein a first site identifier, and the first site identifier are all dedicated identifiers in the multi-site cascading system (wherein the multi-VIM adapter 220 issues a separate workflow execution command for each of the VNFs, with each such command being issued to the data center having the data center ID (i.e., “site” ID) corresponding to the VNF, and further including a pointer to the workflow script to be executed, the ID of the VNF, the selection of the method by which the workflow script is to be executed in the VM implementing the VNF, and the workflow data) (Thakkar, paragraph [0081]). Thakkar-Panikkar does not expressly disclose wherein the invocation request comprises one or both of a first microservice identifier and an API identifier, and wherein the first microservice identifier and the API identifier are all dedicated identifiers. In an analogous art, however, LIANG discloses wherein an invocation request comprises one or both of a first microservice identifier and an API identifier, and wherein the first microservice identifier and the API identifier are all dedicated identifiers (Examiner notes drafting of claim language in the alternative, i.e., using “one or both” and so only either an API identifier or microservice identifier is required by the prior art. LIANG teaches that an authorization request message includes an identifier of the API invoker, an identifier of the target resource owner, an identifier of the target resource, as well as an identifier of the service API requested by the API invoker) (LIANG, paragraph [0084]). Thakkar-Panikkar is analogous art, because Thakkar-Panikkar is from the same field of endeavor, namely, management of microservices in cloud-based virtualization infrastructures, while LIANG is analogous art because LIANG is reasonably pertinent to the particular problem with which the inventor was concerned, as LIANG is directed to API invocation (See LIANG, paragraph [0005]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Thakkar-Panikkar and LIANG before him or her, to modify the network functions virtualization (NFV) platform of Thakkar-Panikkar to include the additional limitation of wherein an invocation request comprises one or both of a first microservice identifier and an API identifier, and wherein the first microservice identifier and the API identifier are all dedicated identifiers, as disclosed by LIANG, with reasonable expectation that this would result in an orchestration framework having the added benefit of ensuring that a given API call was authorized based on the identifier of the API providing the service, thereby adding security (See LIANG, paragraph [0125]). This method of improving the network functions virtualization (NFV) platform of Thakkar-Panikkar was well within the ordinary ability of one of ordinary skill in the art based on the teachings of LIANG. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Thakkar-Panikkar with LIANG to obtain the invention as specified in claim 2.
Claims 8 and 16 include a “method” and an “invocation device” claim, respectively, that perform limitations substantially as recited in “multi-site cascading system” claim 2, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
Claims 13 and 14 include “method” claims that perform limitations substantially as recited in “multi-site cascading system” claims 5 and 6, respectively, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
Allowable Subject Matter
14. Claims 12, 19 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
15. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action. For instance, Chandrashekhar (USPAT 11,258,668) discloses a method for a first network controller executing at a first site of multiple sites spanned by a logical network. Network controllers execute at each site, and the method generates logical network state data for the first site based on (i) data received from computing devices that implement the logical network at the first site and (ii) logical network configuration data from a network manager at the first site. The method provides the logical network state data for the first site to a second network controller executing at a second site. The method provides logical network state data received from the second site to the computing devices that implement the logical network at the first site (See Abstract). LIU (USPGPUB 2024/0231840) discloses a method and apparatus for microservice configuration, an electronic device, a system and a storage medium. Configuration data is received from a main cluster, a service data acquisition request is sent to the main cluster in response to determining that service data in the main cluster has been changed, and the changed service data is received from the main cluster, and at least one service governance task is executed according to the configuration data and the changed service data (See Abstract).
16. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOSTAS J. KATSIKIS whose telephone number is (571)270-5434. The examiner can normally be reached Monday-Friday, 9:00am-5:00pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian J. Gillis can be reached at 571-272-7952. 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.
/KOSTAS J KATSIKIS/Primary Examiner, Art Unit 2441