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 amendment/reconsideration filed 12/9/2025, the amendment/reconsideration has been considered. Claims 1-20 are pending for examination.
Response to Arguments
Applicant's arguments are moot in light of the new ground of rejections set forth below.
Double Patenting
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 obviousness-type 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 is either anticipated by, or would have been obvious over, the reference claim(s). 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); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
4. Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of US Patent REWASKAR et al. (US 2019/0146823). As to claim 1, although the conflicting claims are not identical, they are not patentably distinct from each other because all limitations of the independent claim 1 of the instant application are claimed in claim 9 of the patent, i.e., claim 9 of the patent is more specific. Thus the invention of claim 9 of the patent is in effect a "species" of the "generic" invention of claim 1 of the instant application. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Claims 2-20 are similarly rejected.
Claim Rejections - 35 USC § 112
5. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
6. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
7. Claims 4, 13 and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 4 recites “the first customer network being a provider system separate from the second customer network” which does not find support in the originally filed application. The originally filed application discloses, such as in Figure 1, that the provider system is separate from customer networks, and that the VMs are mapped to one or more customer networks. Claims 12 and 20 are similarly rejected. All new matters shall be deleted from the claims.
8. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
9. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
10. Claims 4, 13 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 4 recites “the first customer network being a provider system separate from the second customer network.” First of all, this limitation conflicts with the disclosure of the specification such as Figure 1 wherein all customer networks are separate from the provider system. Secondly, it is unclear how a provider can be a customer network. Applicant is required to clarify. For the sake of the examination, Examiner interprets as any relationship. Claims 13 and 20 are similarly rejected.
Claim Rejections - 35 USC § 103
11. 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.
12. 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.
13. 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.
14. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over by KORBAR et al (US 2009/0278620, submitted by IDS) in view of REWASKAR et al (US 20190146823 A1).
As to claim 1, KORBAR discloses a method for modifying a network connectivity of a virtual machine, the method comprising:
receiving an allocation request to connect the virtual machine to a second customer network, wherein a virtual network interface controller of the virtual machine is configured with first network configuration information of a first network distinct from the second customer network, the virtual machine is executing on the first network while the allocation request is received and the allocation request includes second network configuration information of the second customer network ([0069], “Compute manager 443 may also send a request to networking manager 445 to cause corresponding networking artifacts to move their association from the platform to the particular customer, as well as for networking artifacts to be modified and/or reconfigured and/or created. For example[ ... ] the customer may wish for the VM to have a particular virtual network”; [0066], there are available partially provisioned VMs in the VM pool managed by VM pool manager 442 [ ... ] partially provisioned VM is reconfigured to meet user-specific settings”; [0070], “a new customer IP address requested by the customer”.
See [0053], “The generic networking artifacts may include, for example, a placeholder virtual network, and a placeholder customer IP address. A VM is created/composed using the generic artifacts, using the particular combination of properties that are not reconfigured ( e.g., VM size, OS type, storage type, processor resources, memory resources, etc.), and the VM is booted;” and
[0060], “In some examples, networking service 445 will provide the VM with the MAC address and physical IP address of the (placeholder) virtual network as normal. In some examples, the customer IP address is an address usable by a customer but which is not actual routable in the internal network.”
Here, the placeholder virtual network wherein the VM was running in is equivalent to a first network, identified by the placeholder customer IP address while the reconfigured new virtual network with “a new customer IP address” is equivalent to a second customer network);
detecting a discovery request from the virtual machine triggered by receipt of the allocation request, wherein the virtual machine remains executing on the first network during detection of the discovery request ([0071], “networking agent in VM host 451 instructs an agent in the VM to retrigger DHCP”, wherein the VM remains executing is implied by [0071], “an agent in the VM to retrigger DHCP”. Also citation in rejection to the preceding limitation); and
updating, responsive to detecting the discovery request from the virtual machine, the virtual network interface controller of the virtual machine to replace the first network configuration information of the first network with the second network configuration information of the second customer network, wherein the virtual machine remains executing on the first network until the virtual network interface controller is updated and executes on the second customer network after the virtual network interface controller is updated ([0076], “The agent on the VM may then accept the user-specific settings associated with the reconfiguration requests, including user-specific networking settings, and then apply those user-specific settings, so that networking and possibly other aspects of the VM are reconfigured”, wherein the vm remains executing is implied by [0076], “The agent on the VM may then accept the user specific settings associated with the reconfiguration requests”’; [0069], “Networking manager 445 may also configure any network rules requested by the customer, including rules for the network interface controller (NIC) and the media control access (MAC) address”.
Also see citation in rejection to the preceding limitations, e.g., [0053], “The generic networking artifacts may include, for example, a placeholder virtual network, and a placeholder customer IP address. A VM is created/composed using the generic artifacts,…, and the VM is booted;” and
[0060], “In some examples, networking service 445 will provide the VM with the MAC address and physical IP address of the (placeholder) virtual network as normal. In some examples, the customer IP address is an address usable by a customer”).
However, KORBAR does not expressly disclose that the first network is a first customer network. REWASKAR discloses a concept for a first network to be a first customer network (abstract, “The fully provisioned VM is reconfigured based on a customer request and this reconfiguration includes changing the virtual network of the VM performed without rebooting the VM”; [0015], “A VM, including a virtual network change for a VM, is reconfigured without rebooting the VM in some examples. In some examples, a user may wish an existing VM already used to be the VM to be reconfigured with a different virtual network. In other examples, a partially configured VM may be reconfigured”; see also claims 8-9. It is to be noted that the claim does not require a specific relationship between the first customer network and the second customer network, nor does the claim require a specific relationship between the customer using the first customer network and the customer using the second customer network. As a result, Examiner interprets as any relationship(s)).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine KORBAR with REWASKAR. The suggestion/motivation of the combination would have been to enable a user to switch from a first virtual network to a second virtual network (REWASKAR, [0015], “A VM, including a virtual network change for a VM, is reconfigured without rebooting the VM in some examples. In some examples, a user may wish an existing VM already used to be the VM to be reconfigured with a different virtual network”).
As to claim 9, see similar rejection to claim 1.
As to claim 10, KORBAR-REWASKAR discloses the computing system of claim 9, further comprising an event generator executable by the one or more hardware processors and configured to issue an allocation change event responsive to receipt of the allocation request, wherein the virtual machine remains executing on the first customer network during issuance of the allocation change event, the discovery request is detected responsive to issuing the allocation change event (KORBAR. [0071], “networking agent in VM host 451 instructs an agent in the VM to retrigger DHCP”, wherein the instruction is equivalent to issuance of the allocation change event, and wherein the VM remains executing is implied by [0071], “an agent in the VM to retrigger DHCP”; REWASKAR, [0015] and claim 1).
As to claim 17, see similar rejection to claim 10,
As to claim 2, KORBAR-REWASKAR discloses the method of claim 1, the first network configuration information including first internet protocol address information of the first customer network, and the second network configuration information including second internet protocol address information of the customer network, wherein updating the virtual network interface controller includes replacing the first internet protocol address information with the second internet protocol address information (KORBAR, [0069], “networking artifacts to be modified and/or reconfigured and/or created… configure any network rules requested by the customer, including rules for the network interface controller and the media control access (MAC address)”; [0070], “Networking manager 445 may create a new virtual network for the VM during reconfiguration, and remap to a new customer IP address requested by the customer, while reusing both the MAC address and the physical IP address of the VM prior to reconfiguration”; REWASKAR, abstract, [0015]; claim 1).
As to clam 11 see similar rejection to claim 2.
As to claim 18, see similar rejections to claims 10 and 2.
As to claim 3, KORBAR-REWASKAR discloses the method of claim 2, wherein the virtual machine ceases to communicate with the first customer network and communicates with the second customer network responsive to replacing the first internet protocol address information of the virtual network interface controller with the second internet protocol address information (KORBAR, [0069]-[0070]; REWASKAR, abstract; claim 1; [0015]).
As to clam 12 see similar rejection to claim 3.
As to claim 19, see similar rejections to claims 10 and 3.
As to claim 4, KORBAR-REWASKAR discloses the method of claim 1, the first network configuration information including first internet protocol address information of the first customer network, the first customer network being a provider system separate from the second customer network (see 112 rejection and Examiner’s interpretation therein), the second network configuration information including second internet protocol address information, the allocation request being received from the provider system, wherein updating the virtual network interface controller includes replacing the first internet protocol address information with the second internet protocol address information (KORBAR, [0069], “networking artifacts to be modified and/or reconfigured and/or created… configure any network rules requested by the customer, including rules for the network interface controller and the media control access (MAC address)”; [0070], “Networking manager 445 may create a new virtual network for the VM during reconfiguration, and remap to a new customer IP address requested by the customer, while reusing both the MAC address and the physical IP address of the VM prior to reconfiguration”, wherein the system receiving the customer’s input and causing the network manager to create the new virtual network is a provider system).
As to clam 13, see similar rejection to claim 4.
As to claim 20, see similar rejections to claims 10 and 4.
As to claim 5, KORBAR-REWASKAR discloses the method of claim 1, further comprising:
at a time before receiving the allocation request, configuring the virtual machine to receive events indicating changes in the first network configuration information (KORBAR, [0071], “networking agent in VM host 451 instructs an agent in the VM to retrigger DHCP”, wherein being configured to receive such instruction is implied).
As to clam 14, see similar rejection to claim 5.
As to claim 6, KORBAR-REWASKAR discloses the method of claim 1, wherein the virtual machine is supported by the virtual network interface controller (KORBAR, [0069], “VM… virtual network… Networking manager 445 may also configure any network rules requested by the customer, including rules for the network interface controller (NIC)”) and a supplementary virtual network interface controller, the supplementary virtual network interface controller including supplementary network configuration information of a network of a provider system (KORBAR, [0070], “Networking manager 445 may create a new virtual network for the VM during reconfiguration, and remap to a new customer IP address requested by the customer”).
As to claim 7, KORBAR-REWASKAR discloses the method of claim 1, the discovery request comprising a dynamic host configuration protocol request (KORBAR, [0071], “networking agent in VM host 451 instructs an agent in the VM to retrigger DHCP”).
As to claim 16, see similar rejection to claim 7.
As to claim 8, KORBAR-REWASKAR discloses the method of claim 1, further comprising:
issuing an allocation change event responsive to receipt of the allocation request, wherein the virtual machine remains executing on the first customer network during issuance of the allocation change event, the discovery request is detected responsive to issuing the allocation change event (see similar rejection to claim 10).
As to claim 15, see similar rejection to claim 8.
Conclusion
15. 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 HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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, 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