FINAL OFFICE ACTION
Status of the Claims
Claims 1-6 are rejected under 35 U.S.C. 102
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Singhal et al. (U.S. Publication No. 2021/0271489 A1), hereinafter referred to as Singhal.
Regarding Claim 1, Singhal teaches
A data processing apparatus comprising:
an acquisition unit configured to acquire, when a microservice is to be installed, from a microservice package of the microservice, storage destination information… ([0026]; regarding, “…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”; [0048]; regarding, “…generating an installation package comprising a microservice (e.g., an infrastructure microservice) and a corresponding registry”);
indicating a data persistence destination path of the microservice in a first storage device, ([0068]; regarding, “the posted registry can be persistently stored in one or more storage pools, and/or the posted registry can be persistently stored for download access at a microservices deployment manager node, and/or the posted registry can be stored at any location accessible to the node or nodes that are intended to be configured with the set of microservices.”);
the data persistence destination path being used to store data generated by the microservice; ([0051]; regarding, “In the context of the herein-disclosed techniques for bootstrapping a containerized microservices registry this high-availability storage is used to provide redundant storage of the containerized microservices registry.”; [0068]; regarding, “the posted registry can be persistently stored in one or more storage pools, and/or the posted registry can be persistently stored for download access at a microservices deployment manager node, and/or the posted registry can be stored at any location accessible to the node or nodes that are intended to be configured with the set of microservices.”);
a storage unit configured to store the storage destination information acquired by the acquisition unit in a microservice information table in association with identification information of the microservice; (Fig. 1, [0044]; regarding, “An agent on the microservices deployment manager node, possibly the microservices deployment packager 102, can then be configured to identify a set of infrastructure microservices (operation 2). For each such individual ones of the set of infrastructure microservices, registry data 104 is accessed and a corresponding fully qualified domain name entry (e.g., fully qualified domain name entry 110.sub.1, fully qualified domain name entry 110.sub.2) is identified (operation 3).”; [0123]; regarding, “…a distributed platform that contains multiple servers and/or nodes that manage multiple tiers of storage where the tiers of storage might be formed using the shown data repository 831 and/or any forms of network accessible storage. As such, the multiple tiers of storage may include storage that is accessible over communications link 815.”; [0103]; regarding, “Communications link 815 can be configured to transmit (e.g., send, receive, signal, etc.) any type of communications packets comprising any organization of data items. The data items can comprise a payload data, a destination address (e.g., a destination IP address) and a source address (e.g., a source IP address), and can include various packet processing techniques”);
and an installation control unit configured to pass the microservice package to a container management tool after the storage destination information is stored in the microservice information table, ([0042]; regarding, “after running the installation package on a subject node, a microservices caller running on the subject node can access endpoints at that node. The installer is organized such that code corresponding to the infrastructure microservices code 106 is executed before invocation of any non-infrastructure microservices code 155. As such, and using the specially configured, node-specific installation package, a node can bootstrap itself to bring-up infrastructure microservices.”; [0070]; regarding, “the target node autonomously stores the QEMU qcow in a location and format that facilitates access by a virtual machine (step 414) which in turn is configured to provide access to the registry by other virtual machines and/or other operational elements (e.g., applications, containers, operating system calls, etc.).”);
and to instruct the container management tool to install the microservice for which the storage destination information has been acquired. ([0042]; regarding, “after running the installation package on a subject node, a microservices caller running on the subject node can access endpoints at that node. The installer is organized such that code corresponding to the infrastructure microservices code 106 is executed before invocation of any non-infrastructure microservices code 155. As such, and using the specially configured, node-specific installation package, a node can bootstrap itself to bring-up infrastructure microservices.”; [0061-0062]).
Regarding Claim 2, Singhal teaches the apparatus of claim 1 as referenced above. Singhal further teaches:
further comprising: a backup unit configured to back up, based on the storage destination information stored in the microservice information table, the data generated by the microservice stored in the first storage device to a second storage device physically different from the first storage device. ([0051]; regarding, “This high-availability storage serves any/all of a plurality of computing nodes of a cluster. Any/all of a plurality of computing nodes of a cluster can extract (e.g., from an installer package) and invoke a containerized microservices registry in a bootstrapping process. A backing copy of a containerized microservices registry can be stored in high-availability storage, and any/all nodes of the cluster can access the high-availability storage.”; [0058]; regarding, “high-availability storage 305 may be implemented using physical storage devices that are organized into storage pools… high-availability storage pools, can persist as configuration data 340… such configuration data 340 holds any configuration data (e.g., registry data, DNS data, etc.) for any node or plurality of nodes… configuration data 340 holds persistent backing data for a virtual machine (e.g., VM.sub.11). The virtual machine is configured to (1) access the container registry (e.g., from configuration data 340, or from any other storage location), and (2) provide container registry access to any operational elements (e.g., other VMs, applications, containers, operating system calls, etc.) that communicate with the VM. As used herein, a container registry is a data item that associates a microservice uniform resource location or indicator to an internet protocol (IP) address.”).
Regarding Claim 3, Singhal teaches the apparatus of claim 1 as referenced above. Singhal further teaches:
further comprising: a recovery unit configured to recover, based on the storage destination information stored in the microservice information table, the data stored in the second storage device to the first storage device. ([0051]; regarding, “techniques for bootstrapping a containerized microservices registry this high-availability storage is used to provide redundant storage of the containerized microservices registry.”; [0080]; regarding, “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).”; [0081]; regarding, Portions of the foregoing process can be reversed to revert leadership back to the former leader node node.sub.11.)”; [0085-0087]).
Regarding Claim 4, Singhal teaches the apparatus of claim 1 as referenced above. Singhal further teaches:
wherein the acquisition unit is configured to extract the storage destination information from an installation source file of the microservice. ([0040]; regarding, “In some embodiments, an installation package is configured to self-extract and/or self-unpack any or all of the collection of data and executable code.”; [0029]; regarding, “As used herein a local container registry is a data structure that is stored at and accessible to particular computing node, which data structure is populated with executable code corresponding to a set of microservices. Such a local container registry may be associated with a node-local IP address.”; [0114]; regarding, “Various implementations of the data repository comprise storage media organized to hold a series of records or files… Such files or records can be organized into one or more data structures (e.g., data structures used to implement or facilitate aspects of deploying a highly available container registry in a microservices platform).”).
Regarding Claim 5, Singhal teaches the apparatus of claim 1 as referenced above. Singhal further teaches:
wherein the data processing apparatus further comprises the first storage device, and is an edge device that communicates with a cloud. (Fig. 1, [0097]; [0123]; regarding, “the multiple tiers of storage may include storage that is accessible over communications link 815. Such network accessible storage may include cloud storage or networked storage”).
Regarding Claim 6, Singhal teaches:
A non-transitory computer-readable storage medium storing a program for causing a computer that operates a microservice to realize, when the microservice is to be installed:
a function of acquiring storage destination information indicating a data persistence destination path of the microservice in a first storage device from a microservice package of the microservice, ([0026]; regarding, “…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”; [0048]; regarding, “…generating an installation package comprising a microservice (e.g., an infrastructure microservice) and a corresponding registry”);
the storage destination being used to store data generated by the microservice; ([0051]; regarding, “In the context of the herein-disclosed techniques for bootstrapping a containerized microservices registry this high-availability storage is used to provide redundant storage of the containerized microservices registry.”);
a function of storing the acquired storage destination information in a memory in association with the identification information of the microservice; (Fig. 1, [0044]; regarding, “An agent on the microservices deployment manager node, possibly the microservices deployment packager 102, can then be configured to identify a set of infrastructure microservices (operation 2). For each such individual ones of the set of infrastructure microservices, registry data 104 is accessed and a corresponding fully qualified domain name entry (e.g., fully qualified domain name entry 110.sub.1, fully qualified domain name entry 110.sub.2) is identified (operation 3).”; [0123]; regarding, “…a distributed platform that contains multiple servers and/or nodes that manage multiple tiers of storage where the tiers of storage might be formed using the shown data repository 831 and/or any forms of network accessible storage. As such, the multiple tiers of storage may include storage that is accessible over communications link 815.”; [0103]; regarding, “Communications link 815 can be configured to transmit (e.g., send, receive, signal, etc.) any type of communications packets comprising any organization of data items. The data items can comprise a payload data, a destination address (e.g., a destination IP address) and a source address (e.g., a source IP address), and can include various packet processing techniques”);
and a function of passing the microservice package to a container management tool after storing the storage destination information in the microservice information table; ([0042]; regarding, “after running the installation package on a subject node, a microservices caller running on the subject node can access endpoints at that node. The installer is organized such that code corresponding to the infrastructure microservices code 106 is executed before invocation of any non-infrastructure microservices code 155. As such, and using the specially configured, node-specific installation package, a node can bootstrap itself to bring-up infrastructure microservices.”; [0070]; regarding, “the target node autonomously stores the QEMU qcow in a location and format that facilitates access by a virtual machine (step 414) which in turn is configured to provide access to the registry by other virtual machines and/or other operational elements (e.g., applications, containers, operating system calls, etc.).”);
and installing the microservice for which the storage destination information has been acquired. ([0042]; regarding, “after running the installation package on a subject node, a microservices caller running on the subject node can access endpoints at that node. The installer is organized such that code corresponding to the infrastructure microservices code 106 is executed before invocation of any non-infrastructure microservices code 155. As such, and using the specially configured, node-specific installation package, a node can bootstrap itself to bring-up infrastructure microservices.”; [0061-0062]).
Response to Arguments
Applicant’s arguments filed 07/14/2026 have been fully considered.
Applicant argues Singhal fails to disclose the claimed data persistence destination path (“Remarks”, Page 7). Examiner respectfully disagrees. Singhal discloses: The populated local container registry 4012 can be… saved in an externally-accessible location (step 406) and posted for download and/or stored in a persistent storage location. Strictly as examples, the posted registry can be persistently stored in one or more storage pools, and/or the posted registry can be persistently stored for download access at a microservices deployment manager node, and/or the posted registry can be stored at any location accessible to the node or nodes that are intended to be configured with the set of microservices [0068]. Further, Singhal discloses: …system 500 to show a sequence of operations to implement a highly available microservices container registry by using availability zone monitoring and failover [0072]. As claimed, Singhal discloses a data persistence destination path.
Applicant further argues Singhal fails to disclose storing the destination information in the microservice information table prior to the container management tool (“Remarks”, Page 7). Examiner respectfully disagrees. Singhal discloses: Fig. 3B, When a computing system node receives the installation package (step 204), the computing system node will execute a first series of steps to extract and install a node-local registry (e.g., a node-local container registry) at the computing system node [0049]; Such high-availability storage of any implementation, including high-availability storage pools, can persist as configuration data 340. In example embodiments, such configuration data 340 holds any configuration data (e.g., registry data, DNS data, etc.) for any node or plurality of nodes. In the example of FIG. 3A, configuration data 340 holds a highly-available copy of container registry 350.sub.11. Further, and as shown in the example of FIG. 3A, configuration data 340 holds persistent backing data for a virtual machine (e.g., VM.sub.11). The virtual machine is configured to (1) access the container registry (e.g., from configuration data 340, or from any other storage location), and (2) provide container registry access to any operational elements (e.g., other VMs, applications, containers, operating system calls, etc.) that communicate with the VM. As used herein, a container registry is a data item that associates a microservice uniform resource location or indicator to an internet protocol (IP) address [0058].
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATHEW GUSTAFSON whose telephone number is (571)272-5273. The examiner can normally be reached Monday-Friday 8:00-4:00.
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, Bryce Bonzo can be reached at (571) 272-3655. 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.
/MICHAEL MASKULINSKI/Primary Examiner, Art Unit 2113
/M.D.G./Examiner, Art Unit 2113
Prosecution Insights