CTNF 19/096,433 CTNF 92541 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement 2. The information disclosure statement (IDS) submitted on 10/30/2025 & 02/26/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Double Patenting 08-33 AIA 3. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim either is anticipated by, or would have been obvious over, the reference claim. See, e.g., In re Berg , 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman , 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi , 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum , 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel , 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington , 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l) (1) - 706.02(l) (3) for applications not subject to examination under the first inventor to file provisions of the AIA. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO Internet website contains terminal disclaimer forms, which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA/25, or PTO/AIA/26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. 08-34 AIA 4. Claim (s) 1-6, 11-13, 15-16 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claim (s) 1 of U.S. Patent No : US 12,323,386 B2 . Although the claims at issue are not identical, they are not patentably distinct from each other because Claim(s) 1-6, 11-13, 15-16 of the current application matches directly to every element of Claim 1-2, 7-8, 10-11, 16 & 17 of Patent No: US 12,323,386 B2 . 5. In addition, specifically Independent Claims 1 & 11, is/are rejected on the ground of nonstatutory double patenting as being rejected over claim(s) 1 & 10 of Patent No: 12,323,386 B2, in view of Singh et al. (US 2023/0216828 A1). 6. The claims are not patentable distinct from each other because it would have been obvious to one having ordinary skill in the art at the time the invention was made to take the teachings of Singh et al. and apply them on the teachings of Application No. 19/096,433 to assign a virtual IP address to a container pod in a cloud network system for containerized software operations. 7. The table below shows only a sample of how each of these claims is anticipated by claims such as Claim 1 of Patent No. US 12,323,286 B2. Instant Application 19/096,433 Patent No. 12,323,386 B2. 1. A cloud based network system, comprising: 1. A cloud based network system, comprising: one or more processors; one or more processors; a memory having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to implement a process to assign a virtual internet protocol (VIP) address to an application pod of a containerized software environment, the VIP address being directly reachable from a network external to the containerized software environment, the process including: assign a first VIP address to route traffic to a first fixed internet protocol (IP) address assigned to a first application pod, wherein the first application pod is assigned to an active role; a memory having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to implement a process to assign a virtual internet protocol (VIP) address to an application pod of a containerized software environment, the VIP address being directly reachable from a network external to the containerized software environment, the process including: reserve a range of internet protocol (IP) addresses for use as VIP addresses; assign a first fixed IP address to a first application pod; assign a first VIP address from the range of IP addresses to the first application pod; route traffic directed to the first VIP address to the first fixed IP address; determine when the first application pod has restarted as a new application pod; in response to the first application pod becoming unavailable: switch a second application pod having a second fixed IP address from a standby role to the active role; and assign a new fixed IP address to the new application pod; and assign the first VIP address to route traffic to the second fixed IP address, enabling continued access to a service offered by the first application pod and the second application pod through the first VIP address, despite the first application pod and the second application pod having different fixed IP addresses. assign the first VIP address to the new application pod, the first VIP address configured to route traffic to the new fixed IP address, enabling continued access to a service offered by the first application pod and the new application pod through the first VIP address, despite the first application pod and the new application pod having different fixed IP addresses. 2. The cloud based network system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to: reserve a range of internet protocol (IP) addresses for use as VIP addresses; and assign the first VIP address from the range of IP addresses. Claim 1. reserve a range of internet protocol (IP) addresses for use as VIP addresses; assign a first fixed IP address to a first application pod; assign a first VIP address from the range of IP addresses to the first application pod; 3. The cloud based network system of claim 2, further comprising instructions that, upon execution, cause the one or more processors to: assign a first virtual network interface controller (Vnic) to the first application pod to act as an externally-accessible port not managed by the containerized software environment; assign the first fixed IP address to the first Vnic; and assign the first VIP address to the first Vnic in order to route traffic directed to the first VIP address to be received at the first fixed IP address. 2. The cloud based network system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to: assign a virtual network interface controller (Vnic) to the first application pod to act as an externally-accessible port not managed by the containerized software environment; assign the first fixed IP address to the Vnic; and assign the first VIP address to the Vnic in order to route traffic directed to the first VIP address to be received at the first fixed IP address. 4. The cloud based network system of claim 3, further comprising instructions that, upon execution, cause the one or more processors to: assign a second Vnic to the second application pod; and assign the second fixed IP address to the second Vnic. 5. The cloud based network system of claim 4, further comprising instructions that, upon execution, cause the one or more processors to: operate the cloud based network system on a private cloud environment; assign the first VIP address to the second Vnic in order to route traffic directed to the first VIP address to be received at the second fixed IP address; and route traffic directed to the first VIP address to be received at the first fixed IP address or the second fixed IP address based on a gratuitous address resolution protocol (GARP). 7. The cloud based network system of claim 6, further comprising instructions that, upon execution, cause the one or more processors to: operate the cloud based network system on a private cloud environment; and route traffic directed to the first VIP address to be received at the first fixed IP address or the second fixed IP address based on a gratuitous address resolution protocol (GARP). 6. The cloud based network system of claim 5, further comprising instructions that, upon execution, cause the one or more processors to: assign a second VIP address to the first Vnic and to the second Vnic from the range of IP addresses, in order to route traffic directed to the second VIP address to be received at the first fixed IP address and the second fixed IP address; and route traffic directed to the second VIP address to be received at the first fixed IP address or the second fixed IP address based on the GARP. 8. The cloud based network system of claim 7, further comprising instructions that, upon execution, cause the one or more processors to: assign a third fixed IP address to a third application pod; assign the first VIP address to the first application pod, to the second application pod, and to the third application pod, the first application pod and the third application pod both being in the active role and the second application pod being in the standby role; assign a second VIP address to the first application pod, to the second application pod, and to the third application pod; route traffic to the first fixed IP address and the third fixed IP address via the first VIP address and the second VIP address while both first and third application pods are active based on the GARP; and when either the first application pod or the third application pod crashes, route traffic intended for the crashed pod to the second fixed IP address based on the GARP. 7. The cloud based network system of claim 6, further comprising instructions that, upon execution, cause the one or more processors to: assign a third Vnic to the first application pod; assign a third fixed IP address to the third Vnic; assign a fourth Vnic to the second application pod; assign a fourth fixed IP address to the fourth Vnic; and assign a third VIP address from the range of IP addresses to the third Vnic and to the fourth Vnic, in order to route traffic directed to the third VIP address to be received at the third fixed IP address and the fourth fixed IP address. 8. The cloud based network system of claim 7, further comprising instructions that, upon execution, cause the one or more processors to: assign a fifth fixed IP address to a fifth Vnic of a third application pod; assign a sixth fixed IP address to a sixth Vnic of the third application pod; assign the first VIP address and the second VIP address to the fifth Vnic; assign the third VIP address to the sixth Vnic; assign the third application pod to an active role; when either the first application pod or the third application pod becomes unavailable, route traffic intended for the unavailable pod to the second fixed IP address based on the GARP, including: route traffic directed to the first VIP address or the second VIP address to be received at the first fixed IP address, the second fixed IP address, or the fifth fixed IP address; and route traffic directed to the third VIP address to be received at the third fixed IP address, the fourth fixed IP address, or the sixth fixed IP address. 9. The cloud based network system of claim 4, further comprising instructions that, upon execution, cause the one or more processors to: operate the cloud based network system on a public cloud environment; request that a public cloud operator associate the first VIP address with the first application pod; and in response to the first application pod becoming unavailable, request that the public cloud operator associate the first VIP address with the second application pod. 10. The cloud based network system of claim 9, further comprising instructions that, upon execution, cause the one or more processors to: assign a second VIP address from the range of IP addresses to route traffic to a third fixed IP address assigned to a third Vnic of a third application pod in the active role; switch the second application pod from the standby role to the active role in response to the third application pod becoming unavailable; and assign the second VIP address to route traffic to the third fixed IP address in response to the third application pod becoming unavailable. 11. A method comprising: operating a cloud based network system in a containerized software environment to assign a virtual internet protocol (VIP) address to an application pod, the VIP being directly reachable from a network external to the containerized software environment, including: assigning a first VIP address to route traffic to a first fixed internet protocol (IP) address assigned to a first application pod, wherein the first application pod is assigned to an active role; in response to the first application pod becoming unavailable: switching a second application pod having a second fixed IP address from a standby role to the active; and assigning the first VIP address to route traffic to the second fixed IP address, enabling continued access to a service offered by the first application pod and the second application pod through the first VIP address, despite the first application pod and the second application pod having different fixed IP addresses. 10. A method comprising: operating a cloud based network system in a containerized software environment to assign a virtual internet protocol (VIP) address to an application pod of a containerized software environment, the VIP being directly reachable from a network external to the containerized software environment, including: reserving a range of internet protocol (IP) addresses for use as VIP addresses; assigning a first fixed IP address to a first application pod; assigning a first VIP address from the range of IP addresses to the first application pod; routing traffic directed to the first VIP address to the first fixed IP address; determining when the first application pod has restarted as a new application pod; assigning a new fixed IP address to the new application pod; and assigning the first VIP address to the new application pod, the first VIP address configured to route traffic to the new fixed IP address. 12. The method of claim 11 further comprising: reserving a range of internet protocol (IP) addresses for use as VIP addresses; and assigning the first VIP address from the range of IP addresses. Claim 10. reserving a range of internet protocol (IP) addresses for use as VIP addresses; assigning a first fixed IP address to a first application pod; assigning a first VIP address from the range of IP addresses to the first application pod; 13. The method of claim 11 further comprising: assigning a first virtual network interface controller (Vnic) to the first application pod to act as an externally-accessible port not managed by the containerized software environment; assigning the first fixed IP address to the first Vnic; and assigning the first VIP address to the first Vnic in order to route traffic directed to the first VIP address to be received at the first fixed IP address. 11. The method of claim 10 further comprising: assigning a virtual network interface controller (Vnic) to the first application pod to act as an externally-accessible port not managed by the containerized software environment; assigning the first fixed IP address to the Vnic; and assigning the first VIP address to the Vnic in order to route traffic directed to the first VIP address to be received at the first fixed IP address. 14. The method of claim 13 further comprising: assigning a second Vnic to the second application pod; and assigning the second fixed IP address to the second Vnic. 15. The method of claim 14 further comprising: operating the cloud based network system on a private cloud environment; assigning the first VIP address to the second Vnic in order to route traffic directed to the first VIP address to be received at the second fixed IP address; and routing traffic directed to the first VIP address to be received at the first fixed IP address or the second fixed IP address based on a gratuitous address resolution protocol (GARP) and whether the first application pod has become unavailable. 16. The method of claim 15 further comprising: operating the cloud based network system on a private cloud environment; and routing traffic directed to the first VIP address to be received at the first fixed IP address or the second fixed IP address based on a gratuitous address resolution protocol (GARP). 16. The method of claim 15 further comprising: assigning a second VIP address to the first Vnic and to the second Vnic, in order to route traffic directed to the second VIP address to be received at the first fixed IP address and the second fixed IP address; and routing traffic directed to the second VIP address to be received at the first fixed IP address or the second fixed IP address based on the GARP and whether the first application pod has become unavailable. 17. The method of claim 16 further comprising: assigning a third fixed IP address to a third application pod; assigning the first VIP address to the first application pod, to the second application pod, and to the third application pod, the first application pod and the third application pod both being in the active role and the second application pod being in the standby role; assigning a second VIP address to the first application pod, to the second application pod, and to the third application pod; routing traffic to the first fixed IP address and the third fixed IP address via the first VIP address and the second VIP address while both first and third application pods are active based on the GARP; and when either the first application pod or the third application pod crashes, routing traffic intended for the crashed pod to the second fixed IP address based on the GARP. 17. The method of claim 15 further comprising: assigning a third Vnic to the first application pod; assigning a third fixed IP address to the third Vnic; assigning a fourth Vnic to the second application pod; assigning a fourth fixed IP address to the fourth Vnic; and assigning a third VIP address to the third Vnic and to the fourth Vnic, in order to route traffic directed to the third VIP address to be received at the third fixed IP address or the fourth fixed IP address based on the GARP and whether the first application pod has become unavailable. 18. The method of claim 17 further comprising: assigning a fifth fixed IP address to a fifth Vnic of a third application pod; assigning a sixth fixed IP address to a sixth Vnic of the third application pod; assigning the first VIP address and the second VIP address to the fifth Vnic; assigning the third VIP address to the sixth Vnic; assigning the third application pod to an active role; when either the first application pod or the third application pod becomes unavailable, routing traffic intended for the unavailable pod to the second fixed IP address based on the GARP, including: routing traffic directed to the first VIP address or the second VIP address to be received at the first fixed IP address, the second fixed IP address, or the fifth fixed IP address; and routing traffic directed to the third VIP address to be received at the third fixed IP address, the fourth fixed IP address, or the sixth fixed IP address. 19. The method of claim 14 further comprising: operating the cloud based network system on a public cloud environment; requesting that a public cloud operator associate the first VIP address with the first application pod; and in response to the first application pod becoming unavailable, requesting that the public cloud operator associate the first VIP address with the second application pod. 20. The method of claim 19 further comprising: assigning a second VIP address to route traffic to a third fixed IP address assigned to a third Vnic of a third application pod in the active role; switching the second application pod from the standby role to the active role in response to the third application pod becoming unavailable; and assigning the second VIP address to route traffic to the third fixed IP address in response to the third application pod becoming unavailable . Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 8. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-07-aia AIA 07-07 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 – 07-12-aia AIA (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. 07-15-03-aia AIA Claim(s) 1-2 & 11-12 is/are rejected under 35 U.S.C. 102 (a) (2) as being anticipated by Singh et al. (US 2023/0216828 A1) . Re Claim 1 & 11, Singh teaches a cloud based network system, comprising: one or more processors; (Singh; FIG. 9; ¶ [0079]-[0083]; Processors.) a memory having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to implement a process to assign a virtual internet protocol (VIP) address to an application pod of a containerized software environment, the VIP address being directly reachable from a network external to the containerized software environment, the process including: (Singh; FIG. 1-9; ¶ [0012]-[0077], [0079]-[0089]; A memory, storing instructions, executing by processors, a process of assigning a virtual IP address to an application pod of containerized software, the VIP address is reachable from a network external to the container.) assign a first VIP address to route traffic to a first fixed internet protocol (IP) address assigned to a first application pod, (Singh; FIG. 1-9; ¶ [0012]-[0077], [0079]-[0089], [0100]; Assigning a persistent IP address (first VIP address), routing traffic to a pod.) wherein the first application pod is assigned to an active role; (Singh; FIG. 1-9; Background, Summary, ¶ [0012]-[0077], [0079]-[0089]; An active role related to an application pod.) in response to the first application pod becoming unavailable: (Singh; FIG. 1-9; ¶ [0012]-[0077], [0079]-[0089]; A first pod shuts down.) switch a second application pod having a second fixed IP address from a standby role to the active role; and (Singh; FIG. 1-9; ¶ [0012]-[0077], [0079]-[0089]; Activating a second pod, with an persistent IP address, to an active role.) assign the first VIP address to route traffic to the second fixed IP address, , (Singh; FIG. 1-9; ¶ [0012]-[0077], [0079]-[0089]; Assigning a persistent IP address, to route traffic.) enabling continued access to a service offered by the first application pod and the second application pod through the first VIP address, despite the first application pod and the second application pod having different fixed IP addresses. (Singh; FIG. 1-9; Background, Summary, ¶ [0012]-[0077], [0079]-[0089], [0106]-[0115]; Continues access to services/functions from one pod to a second different pod, despite the changing of IP addresses.) Re Claim 2 & 12, Singh discloses the cloud based network system of claim 1, further comprising instructions that, upon execution, cause the one or more processors to: reserve a range of internet protocol (IP) addresses for use as VIP addresses; and (Singh; FIG. 1-9; Background, Summary, ¶ [0052]-[0072]; A pool of IP addresses.) assign the first VIP address from the range of IP addresses. (Singh; FIG. 1-9; Background, Summary, ¶ [0012]-[0077], [0079]-[0089], [0106]-[0115]; Assigning a persistent IP address from a pool of IP addresses.) Claim Rejections - 35 USC § 103 07-20-aia AIA 9. 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. 07-21-aia AIA Claim (s) 3-4, 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (US 2023/0216828 A1) and further in view of K N et al. (US 2022/0334864 A1) . Re Claim 3 & 13, Singh discloses the cloud based network system of claim 2, yet does not explicitly suggest further comprising instructions that, upon execution, cause the one or more processors to: assign a first virtual network interface controller (Vnic) to the first application pod to act as an externally-accessible port not managed by the containerized software environment; assign the first fixed IP address to the first Vnic; and assign the first VIP address to the first Vnic in order to route traffic directed to the first VIP address to be received at the first fixed IP address. However, in analogous art, K N teaches further comprising instructions that, upon execution, cause the one or more processors to: assign a first virtual network interface controller (Vnic) to the first application pod to act as an externally-accessible port not managed by the containerized software environment; (K N; Background, Summary, ¶ [0042]-[0072], [0078]-[0116]; Assigning VNIC to a pod.) assign the first fixed IP address to the first Vnic; and (K N; Background, Summary, ¶ [0042]-[0072], [0078]-[0116]; Assigning a IP address.) assign the first VIP address to the first Vnic in order to route traffic directed to the first VIP address to be received at the first fixed IP address. (K N; Background, Summary, ¶ [0042]-[0072], [0078]-[0116]; Assigning a address for the routing of traffic.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention (AIA) to modify Singh in view of K N to assign VIPs to VNICs for the reasons of deploying, configurating and utilizing containerized pods in a computing network. (K N Summary) Re Claim 4 & 14, Singh-K N discloses the cloud based network system of claim 3, further comprising instructions that, upon execution, cause the one or more processors to: assign a second Vnic to the second application pod; and (K N; Background, Summary, ¶ [0042]-[0072], [0078]-[0116]; Assigning VNIC to a pod.) assign the second fixed IP address to the second Vnic. (K N; Background, Summary, ¶ [0042]-[0072], [0078]-[0116]; Assigning VNIC to a pod.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention (AIA) to modify Singh in view of K N to assign VIPs to VNICs for the reasons of deploying, configurating and utilizing containerized pods in a computing network. (K N Summary) Conclusion 10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER B ROBINSON whose telephone number is (571)270-0702. The examiner can normally be reached M-F 7:00-3:00 EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas R Taylor can be reached at 571-272-3889. 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. /CHRISTOPHER B ROBINSON/ Primary Examiner, Art Unit 2443 Application/Control Number: 19/096,433 Page 2 Art Unit: 2443
Prosecution Insights