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 communication filed 3/10/2026. Claims 1-12, 15 and 18 are pending for examination, the rejection cited as stated below.
Claim Construction
2. Claim 15 is interpreted in light of the specification that the claimed “computer-readable storage medium” is “non-transitory computer-readable storage medium” (see specification, paragraph [0043], “A computer-readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fibre optic cable, electrical signals communicated through a wire, and/or other transmission media.”
Claim Rejections - 35 USC § 103
3. 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.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-7, 11-12, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over VAIKAR (US 2019/0158459) in view of Gessner et al (US 2021/0328809).
As to claim 1, VAIKAR discloses a method of organizing distribution of information related to a domain name system, DNS, in a computer network, the method comprising, by a first node of the
computer network:
performing a virtualization-based execution of a first instance of a software application ([0005]), thereby aggregating DNS information specific to the software application ([0006]);
generating a DNS message indicative of the DNS information ([000 7]); and
transmitting the DNS message to a second node of the computer network for usage of the DNS information by a virtualization-based execution of a second instance of the software application ([0007]-[0008]).
However, VAIKAR does not expressly disclose that the virtualization-based execution is a container-based execution. Gessner discloses a concept that a virtualization-based execution of an application associated with DNS is container-based ([0004]; [0019]; [0047]).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled on the art to combine VAIKAR with Gessner. The suggestion/motivation of the combination would have been to scale DNS instances ([0047]).
As to claim 15, see similar rejection to claim 1.
As to claim 18, see similar rejection to claim 1.
As to claim 2, VAIKAR-Gessner discloses the method of claim 1, further comprising, by the second node, transmitting a request for a container-based execution of the second instance to a third node of the computer network, the request being configured to cause the third node to perform the container-based execution of the second instance using the DNS information (VAIKAR, see paragraphs [0007]-[0008], when the second node is a DNS cache synchronization controller, which executes the synchronization controlling instance of the virtual distributed DNS application).
As to claim 4, VAIKAR-Gessner discloses the method of claim 2, the transmission of the DNS message being performed only if the first instance is part of a serverless workload (Gessner, [0047]-[0048], wherein the scaling up and down are automatically performed by the software without needing another manager/server).
As to claim 5, VAIKAR-Gessner discloses the method of claim 2, further comprising, by the second node, storing the DNS information in a dataset of the software application within an application definition database (VAIKAR, [0008], the DNS information is stored in in order to forward to other hypervisors, and wherein the stored association constitutes an application definition database).
As to claim 6, VAIKAR-Gessner discloses the method of claim 1, further comprising, by the second node, performing the container-based execution of the second instance using the DNS information (VAIKAR, [0007], the DNS resolution instance of the virtual distributed DNS application on the second node performs the DNS resolution).
As to claim 7, VAIKAR-Gessner discloses the method of claim 6, the transmission of the DNS message being performed only if the first instance is part of a run-to-completion workload ([0009], the workload of resolving the DNS to an IP address can be considered equivalent a run-to-completion workload).
As to claim 11, VAIKAR-Gessner discloses the method of claim 1, the first node and the second node being registered with a common multicast group of nodes of the computer network participating in performing container-based execution of instances of the software application, the transmission of the DNS message being a multicast of the DNS message to the multicast group (VAIKAR, [0007], “The hypervisor may transmit, via unicast and/or multicast communications, the association to other hypervisors in a datacenter”, wherein the hypervisors in the same datacenter are considered a common group of nodes of the computer network. See Gessner for container-based).
As to claim 12, VAIKAR-Gessner discloses the method of claim 1, the DNS message indicating that the first node is available for retrieval of DNS information specific to the software application (see citation in rejection to claim 1, VAIKAR, wherein the providing by the first node the DNS information specific to virtual distributed DNS application indicates that the first node is available for retrieval of said DNS information. It is to be noted that the claim does not limit for which entity to retrieve the DNS information therefore Examiner assumes any entity).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over VAIKAR-Gessner, as applied to claim 1 above, and further in view of ON (Official Notice)
As to claim 3, VAIKAR-Gessner discloses the method of claim 2, further comprising, by the third node, receiving the DNS information from the first node VAIKAR (see citation in rejection to claim 1 and claim 2, wherein the DNS information is received by the third node originally from the first node), but does not expressly disclose that the receiving is by retrieving. An official notice is taken here that it is a known practice at the time of the invention to pull information instead of push information. Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to modify VAIKAR-Gessner using the pull practice of ON so that the DNS information in VAIKAR-Gessner is not pushed to the third node but instead pulled by the third node from another node such as the first node. The suggestion/motivation of the modification would have been to improve flexibility in receiving information.
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over VAIKAR-Gessner, as applied to claim 1 above, and further in view of ROSKIND (WO 2010/027794).
As to claim 8, VAIKAR-Gessner discloses the method of claim 1, the first node being configured for performing the aggregation of the DNS information using a first DNS cache local to the first node (see citation in rejection to claim 1, VAIKAR), but does not expressly disclose initializing the container-based execution of the first instance, the initialization comprising: requesting a recent version of the DNS information via the computer network if the first DNS cache fulfils a cold-cache criterion with respect to the software application; and in response to receiving the recent version, filling the first DNS cache with the recent version prior to starting the container-based execution of the first instance. ROSKIND discloses a concept of pre-fetching DNS entries (a recent version is implied compared to empty cache) at the initialization of an application instance to fill the cold-empty cache ([0023]).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine VAIKAR-Gessner with ROSKIND. The suggestion/motivation of the combination would have been to accelerate application startup (ROSKIND, [0023]).
As to claim 9, VAIKAR-Gessner- ROSKIND discloses the method of claim 1, the container-based execution of the second instance being performed by a worker node of the computer network (see citation in rejection to claim 1, VAIKAR, wherein each hypervisor can be considered a work node, or Gessner, wherein each container can be considered a work node), the method further comprising, by the worker node, filling a second DNS cache local to the worker node with the DNS information, the usage of the DNS information by the container-based execution of the second instance comprising reading the DNS information from the second DNS cache (VAIKAR, [0007]-[0009]), the worker node being configured for delaying the filling of the second DNS cache until the worker node starts a container-based execution of an instance of the software application (ROSKIND, [0023], filling cache by pre-fetching DNS entries happens at the application initialization time).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over VAIKAR- Gessner, as applied to claim 1 above, and further in view of Glzis et al (US 2022/0261270).
As to claim 10, VAIKAR-Gessner discloses the method of claim 1, further comprising, by the first node in response to completing the execution of the first instance, deleting the DNS information if the DNS information is no longer needed by the container-based execution (see VAIKAR, Figure 5; see Gessner, as cited in rejection to claim 1 for container-based execution), but does not expressly disclose that the no longer being needed is caused by no further instance of the software application is scheduled for container-based execution by the first Node. Glzis discloses a concept of deleting all local environment, DNS server, log file, etc. when no further instance of a software application is scheduled for execution by a first node ([0042]).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine VAIKAR-Gessner with Glzis. The suggestion/motivation of the combination would have been to clean local environment (Glzis, [0042]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUA FAN/Primary Examiner, Art Unit 2458
Prosecution Insights