DETAILED ACTION
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 .
Designations of the Particular Relevance of the Art
The Examiner has pointed out particular references contained in the prior art of record within the body of the Action for Applicant’s convenience. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages, paragraph and figures may apply. Applicant, in preparing the response, should consider fully the reference in totality as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or explained by the Examiner. See MPEP § 707.05.
Manner of Making Amendments under 37 C.F.R. § 1.121
Any subsequent submission by Applicant's amending the claims must comply with the requirements of 37 C.F.R. § 1.121(c) and MPEP § 714(II)(C) regarding the manner of presenting amended claims. That is, amended text must be properly indicated. Failure to provide a compliant amendment may result in the amendment being treated as non-compliant and not entered.
Pursuant to MPEP § 714(II)(C), all changes to currently amended claims must be shown relative to the immediate prior version of the claims. Deleted matter ordinarily must be shown by strike-through; however, when deleting five (5) or fewer consecutive characters, deletion by double brackets may be used and, in certain circumstances, is required. In particular, where strike-through cannot be readily perceived—such as when deleting a single numeral, punctuation mark, or other short character string—double brackets must be used to clearly identify the deleted matter. For example, deletion of punctuation marks standing alone (e.g., commas, periods, semicolons, parentheses, or quotation marks) should be indicated by double brackets rather than strike-through.
Applicant's amendment contains one or more instances in which deletions of five or fewer consecutive characters, including punctuation marks and/or other minimally perceptible characters, are shown by strike-through instead of double brackets, thereby rendering the changes unclear. Applicant is required to submit an amendment in compliance with 37 C.F.R. § 1.121 and MPEP § 714(II)(C), clearly identifying all such deletions using double brackets where appropriate.
Similarly, the text of any added subject matter must be presented in a manner such that the underlining is readily perceptible. Where underlining of added matter cannot be easily perceived, including, for example, the addition, deletion, or substitution of one or more characters, punctuation marks, numerals, or word fragments, the amendment shall instead be presented by deleting the entire affected text and adding the complete replacement text with underlining. Examples include, without limitation, amendments correcting misspellings, changing a singular term to a plural term or vice versa, adding or deleting prefixes or suffixes, or modifying punctuation or numerals.
Response to Amendment
Applicant’s submission amends claims 1, 10, and 15, and cancels claim 21. Claims 1, 3-5, 7-10, 12-15, and 17-20 are now pending.
Response to Arguments
Applicant’s arguments—set forth at pp. 8-14 in the Remarks with respect to independent claims 1, 10, and 15—have been fully considered but are moot because the new grounds of rejection relies on one or more reference not applied in the prior rejection of record for some teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
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.
The factual inquiries 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, 3, 5, 7-10, 12, 14, 15, 17, 19, and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over US 2017/0099188 (hereinafter, “CHANG”) in view of US 5,771,275 (hereinafter, “BRUNNER”), JP 2017-34309A (hereinafter, “KITADA” - citations are to NPL Machine Translation), further US 2014/0112343 (hereinafter, “LAMBETH”), and US Patent No. 6,760,324 (hereinafter, “SCOTT”).
Regarding claim 1, CHANG discloses:
A control system comprising: (hybrid cloud network environment 100)
a first gateway device comprising: (public network cloud gateway 112)
a virtual switch processor that connects a cloud virtual network to a wide area network (¶ 0021: Hybrid cloud network environment 100 can include a plurality of networks or clouds, such as a . . . public cloud 104 separated by a WAN 106, such as the Internet; . . . [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108; ¶ 0054: [P]ublic cloud network gateway 712, such as the public cloud network gateway 112 of FIG. 1[, . . .] can include hardware 768; ¶ 0056: Hardware 768 can represent any machine or apparatus that is capable of accepting, performing logic operations on, storing, or displaying data, and may include a processor 780) and that configures a control virtual network within the cloud virtual network . . . , and (¶ 0027: [P]ublic cloud network gateway 112 can establish, from the public cloud 104, . . . secure access tunnels to connect public cloud VMs (cVMs) 118, and . . . the public cloud network gateway 112 can include a cloud virtual switch or cloud Virtual Ethernet Module (cVEM) 116b that communicates with the VSM 114 to retrieve VM-specific network policies (e.g., port profiles), switches network traffic between public cloud VMs 118)
a communication link that is connected to the wide area network and that forwards communication data received from the cloud virtual network based on a proprietary protocol; and (¶ 0021: [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108. . . . [P]ublic cloud network gateway 112 can be implemented using Intercloud Fabric™ Switch (ICS) from Cisco®)
a second gateway device comprising: (private cloud network gateway 110)
a second communication link that connects a local control network to the wide area network and that forwards the communication data received via the wide area network and converted by the first gateway device. (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet [WAN 106] to the public cloud 104 through the site-to-site tunnel 108. . . . [P]rivate cloud network gateway 110 can be implemented using Intercloud Fabric™ Extender (ICX) from Cisco®)
wherein the virtual switch processor causes a virtual machine in the control virtual network to perform communication . . . . (¶ 0027: [P]ublic cloud network gateway 112 can include a cloud virtual switch or cloud Virtual Ethernet Module (cVEM) 116b that communicates with the VSM 114 to retrieve VM-specific network policies (e.g., port profiles), switches network traffic between public cloud VMs 118, switches network traffic between public cloud VMs and the private cloud 102)
CHANG does not explicitly disclose:
a protocol converter that . . . converts communication data received from the cloud virtual network . . . ; and
a second protocol converter that . . . converts the communication data received via the wide area network . . . .
In the same field of endeavor, however, BRUNNER teaches:
a protocol converter that . . . converts communication data received from the cloud virtual network . . . ; and
a second protocol converter that . . . decodes the communication data received via the wide area network and converted by the first gateway device (Abstract: [A] wireless office environment mobile switching center (WOE-MSC) [42 and] a public land mobile network mobile switching center (PLMN-MSC) [14(2)]. A protocol converter [72] is provided in each of these nodes to convert between . . . message formats; col. 9, l. 67 – col. 10, l. 1: [M]obile switching center 42 is functioning as . . . the gateway switch; col. 2, ll. 27-29: [A] corresponding protocol converter deencapsulates . . . messages from the received . . . packets for processing)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the gateway devices of CHANG to provide protocol converters having protocol conversion functionality as taught by BRUNNER in order to/for the purposes of ensuring compatibility in hybrid cloud network environments “to enable . . . message transport” in disparate networks. See BRUNNER, at col. 6, ll. 44-45.
CHANG also does not explicitly disclose:
by generating a pseudo virtual switch inside the control virtual network, and
In the same field of endeavor, however, KITADA teaches:
by generating a pseudo virtual switch inside the control virtual network, and (Pg. 3, 7th ¶: The virtual switch control system [mapped to claimed virtual switch processor] . . . controls the virtual switch 150 so that one or more virtual switches (pseudo virtual switches) 129 and 139 exist in the containers 120 and 130 in a pseudo manner)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify CHANG’s virtual switch processor to provide pseudo virtual switches as taught by KITADA such that when viewed from the container, it appears that there is a pseudo virtual switch dedicated to the container—but the switching process itself is a virtual switch shared by the container—so that the efficiency of the switching process can be improved while ensuring a high security level. See KITADA, at pg. 6, 9th ¶.
CHANG also does not explicitly disclose:
by broadcast or multicast, and
in a case where a source virtual machine in the control virtual network performs communication by broadcast, the virtual switch processor broadcasts the communication of the source virtual machine by transferring the communication of the source virtual machine to all of the virtual machines in the control virtual network except the source virtual machine.
In the same field of endeavor, however, LAMBETH teaches:
by broadcast or multicast, and (Claim 37: [W]herein modifying the packet comprises converting the broadcast packet to a multicast packet for a predefined multicast group; ¶ 0027: A PAN defines a layer 2 broadcast domain)
in a case where a source virtual machine in the control virtual network performs communication by broadcast, the virtual switch processor broadcasts the communication of the source virtual machine by transferring the communication of the source virtual machine to all of the virtual machines in the control virtual network except the source virtual machine, and (Claim 37: [T]he packet is a broadcast packet to all virtual machines assigned to the PAN; ¶ 0050: The broadcast must reach all the nodes in PAN N2, which are executing in hosts 304a, 304b, and 304d; ¶ 0051: [T]he virtual switch delivers the broadcast to all the ports configured for PAN N3)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LAMBETH to include broadcast and multicast messaging in order to/for the purposes of optimization of a virtual infrastructure networking stack to enable the virtual infrastructure to allow placement of VMs in the virtual infrastructure so as to improve performance. See LAMBETH, at ¶¶ 0030, 0035. Further, the Examiner finds that it would have been obvious to one of ordinary skill in the art for the source virtual machine to try omitting the step of transferring its own communication to itself.
CHANG also does not explicitly disclose:
the first gateway device and the second gateway device communicate with each other via the wide area network using the proprietary protocol optimized for control communication.
In the same field of endeavor, however, SCOTT teaches:
the first gateway device and the second gateway device communicate with each other via the wide area network using the proprietary protocol optimized for control communication. (Col. 54, ll. 35-49: The Network Proprietary device enables communication with other present invention Gateway Servers using a proprietary protocol. This is the normal protocol used for Gateway to Gateway communication. There are two main configuration parameters for the Network Proprietary device. The first is the port range, which controls which UDP/IP ports will be used for media data transmitted to and from this Gateway Server. The second is the Local System ID of the Gateway Server. This name will be presented to remote Gateway Servers when a call is placed, and may be used by the remote Gateway Server in order to identify and authenticate the originating Gateway Server. More details on this process are discussed in the User Management section)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of SCOTT to include proprietary protocol for Gateway to Gateway communication in order to/for the purposes of prioritizing traffic so as to ensure that Gateway to Gateway media data has the highest priority, time-sensitive control data (Gateway to Database/Routing Servers) has medium priority, and management/provisioning traffic has the lowest priority. See SCOTT, at col. 109, ll. 28-33.
Regarding claim 3, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control system of claim 1. CHANG further discloses:
wherein the first gateway device further comprises:
a new node detector that detects a new virtual machine having been added to a cloud virtual network; and (¶ 0056: DCT protocol module 772 can include logic for performing the DCT protocol or process discussed with respect to FIGS. 4 and 5; Fig. 4, Identify targeted cVM 404; ¶ 0042: [S]ecure access tunnel 432 can be established between the cVMs during their deployment; ¶ 0043: Upon receiving the ARP request at 404, the virtual switch or public cloud network gateway 412 can resolve the requested network address information such as by looking up the requested network address in the switch's ARP cache to identify the MAC address of the second cVM 418 b)
a setting information transmitter that transmits, to the new virtual machine detected by the new node detector, network setting information for connecting the new virtual machine to the control virtual network. (¶ 0044: At 408, . . . the first cVM can begin the DCT establishment process or protocol by sending a DCT connection request to the second cVM 418b over the control tunnel 444. The DCT connection request can include information for authenticating the first cVM 418a derived from the second cVM's security information, as well as keys, credentials, certificates, or other information necessary to establish a DCT with the first cVM)
Regarding claim 5, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control system of claim 1, while CHANG further discloses:
wherein at least one of the first gateway device and the second gateway device is configured as a virtual machine. (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM [and] public cloud network gateway 112 can be configured as a VM switch overlay)
Regarding claim 7, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control system of claim 1. CHANG further discloses:
wherein the virtual switch processor forwards communication of a source virtual machine by transferring the communication to a virtual machine belonging to a designated recipient(s). (¶ 0021: [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels; ¶ 0034: In the public cloud 204, the access tunnel 232a can be used for secure communications between cVM 218a and 218d, and the access tunnel 23b can be used for secure communications between public cloud VM 218b and public cloud VM 218c. For instance, if the public cloud VM 218a desires to send a packet to the public cloud VM 218d, the packet can first be sent to the public cloud network gateway 212, where network and security policy may be enforced. Then the public cloud network gateway 212 may forward the packet to the cVM 218d. That is, packets sent between cVMs 218a and cVM 218d may pass through the public cloud network gateway 212 before arriving at the packets' intended destinations)
CHANG does not explicitly disclose:
multicasts or multicast group.
In the same field of endeavor, however, LAMBETH teaches:
multicasts and multicast group. (¶ 0050: [A]ll the hosts hosting a particular PAN are registered for a common multicast; ¶ 0052: [T]he broadcast from H is converted into a multicast that includes all the nodes in PAN N1; Claim 37: [W]herein modifying the packet comprises converting the broadcast packet to a multicast packet for a predefined multicast group)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LAMBETH to include broadcast and multicast messaging in order to/for the purposes of optimization of a virtual infrastructure networking stack to avoid flooding the physical networks with broadcast ranges too wide on Layer 2 which causes performance degradation. See LAMBETH, at ¶¶ 0030, 0035, 0050, ¶ 0053.
Regarding claim 8, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control system of claim 1, while CHANG further discloses:
wherein upon receiving communication to an on-premises environment from the control virtual network, the virtual switch processor transfers the communication . . . (¶ 0021: [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102)
CHANG does not explicitly disclose:
to the first protocol converter.
In the same field of endeavor, however, BRUNNER teaches:
transfers the communication to the first protocol converter. (col. 6, ll. 57-61: ISDN addresses are used by the protocol conversion functionality 72 (in place of origination and destination point codes as used in FIG. 2 SS7 messaging) to address information packets for transmission through the integrated services digital network 62)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the gateway devices of CHANG to provide protocol converters having protocol conversion functionality as taught by BRUNNER in order to/for the purposes of ensuring compatibility in hybrid cloud network environments “to enable . . . message transport” in disparate networks. See BRUNNER, at col. 6, ll. 44-45.
Regarding claim 9, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control system of claim 1. CHANG further discloses:
wherein the communication data is transmitted from the control virtual network, and (¶ 0021: [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108)
CHANG does not explicitly disclose:
the first protocol converter converts the transmitted communication data based on a communication protocol used for communication for an on-premises environment.
In the same field of endeavor, however, BRUNNER teaches:
wherein the first protocol converter converts the transmitted communication data based on a communication protocol used for communication for an on-premises environment. (Abstract: [A] wireless office environment mobile switching center (WOE-MSC) [42 and] a public land mobile network mobile switching center (PLMN-MSC) [14(2)]. A protocol converter [72] is provided in each of these nodes to convert between . . . message formats; col. 9, l. 67 – col. 10, l. 1: [M]obile switching center 42 is functioning as . . . the gateway switch)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the gateway devices of CHANG to provide protocol converters having protocol conversion functionality as taught by BRUNNER in order to/for the purposes of ensuring compatibility in hybrid cloud network environments “to enable . . . message transport” disparate networks. See BRUNNER, at col. 6, ll. 44-45.
Regarding claim 10, CHANG discloses:
A control method comprising:
connecting, by a virtual switch processor, a cloud virtual network to a wide area network; (¶ 0021: Hybrid cloud network environment 100 can include a plurality of networks or clouds, such as a private cloud 102 (e.g., an enterprise virtual datacenter) and a public cloud 104 separated by a WAN 106, such as the Internet; . . . [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108)
configuring, by the virtual switch processor, a control virtual network within the cloud virtual network . . . ; (¶ 0027: [P]ublic cloud network gateway 112 can establish, from the public cloud 104, the secure site-to-site tunnel 108 to interconnect with the private cloud network gateway 110, secure access tunnels to connect public cloud VMs (cVMs) 118, and . . . the public cloud network gateway 112 can include a cloud virtual switch or cloud Virtual Ethernet Module (cVEM) 116b that communicates with the VSM 114 to retrieve VM-specific network policies (e.g., port profiles), switches network traffic between public cloud VMs 118)
forwarding, by a communication link connected to the wide area network, communication data received from the cloud virtual network based on a proprietary protocol; (¶ 0021: [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108. . . . [P]ublic cloud network gateway 112 can be implemented using Intercloud Fabric™ Switch (ICS) from Cisco®)
connecting, by a second gateway device, a local control network to the wide area network; and (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet [WAN 106] to the public cloud 104 through the site-to-site tunnel 108)
receiving, by the second gateway device, the communication data forwarded by the communication link and received via the wide area network. (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet [WAN 106] to the public cloud 104 through the site-to-site tunnel 108. . . . [P]rivate cloud network gateway 110 can be implemented using Intercloud Fabric™ Extender (ICX) from Cisco®)
CHANG does not explicitly disclose:
converting, by a first protocol converter included in a first gateway device . . . , communication data received from the cloud virtual network . . . ; and
decoding . . . the communication data converted by the first protocol converter and received via the wide area network.
In the same field of endeavor, however, BRUNNER teaches:
converting, by a first protocol converter in a first gateway device. . . , communication data received from the cloud virtual network . . . ; and
decoding . . . the communication data converted by the first protocol converter and received via the wide area network. (Abstract: [A] wireless office environment mobile switching center (WOE-MSC) [42 and] a public land mobile network mobile switching center (PLMN-MSC) [14(2)]. A protocol converter [72] is provided in each of these nodes to convert between . . . message formats; col. 9, l. 67 – col. 10, l. 1: [M]obile switching center 42 is functioning as . . . the gateway switch; col. 2, ll. 27-29: [A] corresponding protocol converter deencapsulates . . . messages from the received . . . packets for processing)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the gateway devices of CHANG to provide protocol converters having protocol conversion functionality as taught by BRUNNER in order to/for the purposes of ensuring compatibility in hybrid cloud network environments “to enable . . . message transport” over disparate networks. See BRUNNER, at col. 6, ll. 44-45.
CHANG also does not explicitly disclose:
by generating a pseudo virtual switch inside the control virtual network, and
In the same field of endeavor, however, KITADA teaches:
by generating a pseudo virtual switch inside the control virtual network, and (Pg. 3, 7th ¶: The virtual switch control system [mapped to claimed virtual switch processor] . . . controls the virtual switch 150 so that one or more virtual switches (pseudo virtual switches) 129 and 139 exist in the containers 120 and 130 in a pseudo manner)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify CHANG’s virtual switch processor to provide pseudo virtual switches as taught by KITADA such that when viewed from the container, it appears that there is a pseudo virtual switch dedicated to the container—but the switching process itself is a virtual switch shared by the container—so that the efficiency of the switching process can be improved while ensuring a high security level. See KITADA, at pg. 6, 9th ¶.
CHANG also does not explicitly disclose:
by broadcast or multicast, and
in a case where a source virtual machine in the control virtual network performs communication by broadcast, the virtual switch processor broadcasts the communication of the source virtual machine by transferring the communication of the source virtual machine to all of the virtual machines in the control virtual network except the source virtual machine.
In the same field of endeavor, however, LAMBETH teaches:
by broadcast or multicast, and (Claim 37: [W]herein modifying the packet comprises converting the broadcast packet to a multicast packet for a predefined multicast group; ¶ 0027: A PAN defines a layer 2 broadcast domain)
in a case where a source virtual machine in the control virtual network performs communication by broadcast, the virtual switch processor broadcasts the communication of the source virtual machine by transferring the communication of the source virtual machine to all of the virtual machines in the control virtual network except the source virtual machine, and (Claim 37: [T]he packet is a broadcast packet to all virtual machines assigned to the PAN; ¶ 0050: The broadcast must reach all the nodes in PAN N2, which are executing in hosts 304a, 304b, and 304d; ¶ 0051: [T]he virtual switch delivers the broadcast to all the ports configured for PAN N3)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LAMBETH to include broadcast and multicast messaging in order to/for the purposes of optimization of a virtual infrastructure networking stack to enable the virtual infrastructure to allow placement of VMs in the virtual infrastructure so as to improve performance. See LAMBETH, at ¶¶ 0030, 0035. Further, the Examiner finds that it would have been obvious to one of ordinary skill in the art for the source virtual machine to try omitting the step of transferring its own communication to itself.
CHANG also does not explicitly disclose:
the first gateway device and the second gateway device communicate with each other via the wide area network using the proprietary protocol optimized for control communication.
In the same field of endeavor, however, SCOTT teaches:
the first gateway device and the second gateway device communicate with each other via the wide area network using the proprietary protocol optimized for control communication. (Col. 54, ll. 35-49: The Network Proprietary device enables communication with other present invention Gateway Servers using a proprietary protocol. This is the normal protocol used for Gateway to Gateway communication. There are two main configuration parameters for the Network Proprietary device. The first is the port range, which controls which UDP/IP ports will be used for media data transmitted to and from this Gateway Server. The second is the Local System ID of the Gateway Server. This name will be presented to remote Gateway Servers when a call is placed, and may be used by the remote Gateway Server in order to identify and authenticate the originating Gateway Server. More details on this process are discussed in the User Management section)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of SCOTT to include proprietary protocol for Gateway to Gateway communication in order to/for the purposes of prioritizing traffic so as to ensure that Gateway to Gateway media data has the highest priority, time-sensitive control data (Gateway to Database/Routing Servers) has medium priority, and management/provisioning traffic has the lowest priority. See SCOTT, at col. 109, ll. 28-33.
Regarding claim 12, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control method of claim 10, while CHANG further discloses:
further comprising:
detecting a new virtual machine having been added to the cloud virtual network; and (Fig. 4, Identify targeted cVM 404; ¶ 0042: [S]ecure access tunnel 432 can be established between the cVMs during their deployment; ¶ 0043: Upon receiving the ARP request at 404, the virtual switch or public cloud network gateway 412 can resolve the requested network address information such as by looking up the requested network address in the switch's ARP cache to identify the MAC address of the second cVM 418 b)
transmitting, to the new virtual machine detected, network setting information for connecting the new virtual machine to the control virtual network. (¶ 0044: At 408, . . . the first cVM can begin the DCT establishment process or protocol by sending a DCT connection request to the second cVM 418b over the control tunnel 444. The DCT connection request can include information for authenticating the first cVM 418a derived from the second cVM's security information, as well as keys, credentials, certificates, or other information necessary to establish a DCT with the first cVM)
Regarding claim 14, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control method of claim 10. CHANG further discloses:
wherein at least one of the first gateway device and the second gateway device is configured as a virtual machine. (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet to the public cloud 104 through the site-to-site tunnel 108. The public cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108)
Regarding claim 15, CHANG discloses:
A non-transitory computer readable storage medium storing a program that causes a computer to execute: (¶ 0062: computer-readable media that may be used to store instructions)
connecting a cloud virtual network to a wide area network; (¶ 0021: Hybrid cloud network environment 100 can include a plurality of networks or clouds, such as a private cloud 102 (e.g., an enterprise virtual datacenter) and a public cloud 104 separated by a WAN 106, such as the Internet; . . . [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108)
configuring a control virtual network within the cloud virtual network; (¶ 0027: [P]ublic cloud network gateway 112 can establish, from the public cloud 104, the secure site-to-site tunnel 108 to interconnect with the private cloud network gateway 110, secure access tunnels to connect public cloud VMs (cVMs) 118, and . . . the public cloud network gateway 112 can include a cloud virtual switch or cloud Virtual Ethernet Module (cVEM) 116b that communicates with the VSM 114 to retrieve VM-specific network policies (e.g., port profiles), switches network traffic between public cloud VMs 118)
forwarding, by a first gateway device connected to the wide area network, communication data received from the cloud virtual network based on a proprietary protocol; (¶ 0021: [P]ublic cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108. . . . [P]ublic cloud network gateway 112 can be implemented using Intercloud Fabric™ Switch (ICS) from Cisco®)
connecting, by a second gateway device, a local control network to the wide area network; and (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet [WAN 106] to the public cloud 104 through the site-to-site tunnel 108)
receiving, by the second gateway device, the communication data from the first gateway device and received via the wide area network. (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet [WAN 106] to the public cloud 104 through the site-to-site tunnel 108)
CHANG does not explicitly disclose:
converting, by a first gateway device, . . . communication data received from the cloud virtual network . . . ;
decoding . . . the communication data converted by the first gateway device and received via the wide area network. (Abstract: [A] wireless office environment mobile switching center (WOE-MSC) [42 and] a public land mobile network mobile switching center (PLMN-MSC) [14(2)]. A protocol converter [72] is provided in each of these nodes to convert between . . . message formats; col. 9, l. 67 – col. 10, l. 1: [M]obile switching center 42 is functioning as . . . the gateway switch; col. 2, ll. 27-29: [A] corresponding protocol converter deencapsulates . . . messages from the received . . . packets for processing)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the gateway devices of CHANG to provide protocol converters having protocol conversion functionality as taught by BRUNNER in order to/for the purposes of ensuring compatibility in hybrid cloud network environments “to enable . . . message transport” over disparate networks. See BRUNNER, at col. 6, ll. 44-45.
CHANG also does not explicitly disclose:
by generating a pseudo virtual switch inside the control virtual network, and
In the same field of endeavor, however, KITADA teaches:
by generating a pseudo virtual switch inside the control virtual network, and (Pg. 3, 7th ¶: The virtual switch control system [mapped to claimed virtual switch processor] . . . controls the virtual switch 150 so that one or more virtual switches (pseudo virtual switches) 129 and 139 exist in the containers 120 and 130 in a pseudo manner)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify CHANG’s virtual switch processor to provide pseudo virtual switches as taught by KITADA such that when viewed from the container, it appears that there is a pseudo virtual switch dedicated to the container—but the switching process itself is a virtual switch shared by the container—so that the efficiency of the switching process can be improved while ensuring a high security level. See KITADA, at pg. 6, 9th ¶.
CHANG also does not explicitly disclose:
by broadcast or multicast, and
in a case where a source virtual machine in the control virtual network performs communication by broadcast, the virtual switch processor broadcasts the communication of the source virtual machine by transferring the communication of the source virtual machine to all of the virtual machines in the control virtual network except the source virtual machine.
In the same field of endeavor, however, LAMBETH teaches:
by broadcast or multicast, and (Claim 37: [W]herein modifying the packet comprises converting the broadcast packet to a multicast packet for a predefined multicast group; ¶ 0027: A PAN defines a layer 2 broadcast domain)
in a case where a source virtual machine in the control virtual network performs communication by broadcast, the virtual switch processor broadcasts the communication of the source virtual machine by transferring the communication of the source virtual machine to all of the virtual machines in the control virtual network except the source virtual machine, and (Claim 37: [T]he packet is a broadcast packet to all virtual machines assigned to the PAN; ¶ 0050: The broadcast must reach all the nodes in PAN N2, which are executing in hosts 304a, 304b, and 304d; ¶ 0051: [T]he virtual switch delivers the broadcast to all the ports configured for PAN N3)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LAMBETH to include broadcast and multicast messaging in order to/for the purposes of optimization of a virtual infrastructure networking stack to enable the virtual infrastructure to allow placement of VMs in the virtual infrastructure so as to improve performance. See LAMBETH, at ¶¶ 0030, 0035. Further, the Examiner finds that it would have been obvious to one of ordinary skill in the art for the source virtual machine to try omitting the step of transferring its own communication to itself.
CHANG also does not explicitly disclose:
the first gateway device and the second gateway device communicate with each other via the wide area network using the proprietary protocol optimized for control communication.
In the same field of endeavor, however, SCOTT teaches:
the first gateway device and the second gateway device communicate with each other via the wide area network using the proprietary protocol optimized for control communication. (Col. 54, ll. 35-49: The Network Proprietary device enables communication with other present invention Gateway Servers using a proprietary protocol. This is the normal protocol used for Gateway to Gateway communication. There are two main configuration parameters for the Network Proprietary device. The first is the port range, which controls which UDP/IP ports will be used for media data transmitted to and from this Gateway Server. The second is the Local System ID of the Gateway Server. This name will be presented to remote Gateway Servers when a call is placed, and may be used by the remote Gateway Server in order to identify and authenticate the originating Gateway Server. More details on this process are discussed in the User Management section)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of SCOTT to include proprietary protocol for Gateway to Gateway communication in order to/for the purposes of prioritizing traffic so as to ensure that Gateway to Gateway media data has the highest priority, time-sensitive control data (Gateway to Database/Routing Servers) has medium priority, and management/provisioning traffic has the lowest priority. See SCOTT, at col. 109, ll. 28-33.
Regarding claim 17, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the non-transitory computer readable storage medium of claim 15. CHANG further discloses:
wherein the computer further executes:
detecting a new virtual machine having been added to the cloud virtual network; and (Fig. 4, Identify targeted cVM 404; ¶ 0042: [S]ecure access tunnel 432 can be established between the cVMs during their deployment; ¶ 0043: Upon receiving the ARP request at 404, the virtual switch or public cloud network gateway 412 can resolve the requested network address information such as by looking up the requested network address in the switch's ARP cache to identify the MAC address of the second cVM 418 b)
transmitting, to the new virtual machine detected, network setting information for connecting the new virtual machine to the control virtual network. (¶ 0044: At 408, . . . the first cVM can begin the DCT establishment process or protocol by sending a DCT connection request to the second cVM 418b over the control tunnel 444. The DCT connection request can include information for authenticating the first cVM 418a derived from the second cVM's security information, as well as keys, credentials, certificates, or other information necessary to establish a DCT with the first cVM)
Regarding claim 19, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the non-transitory computer readable storage medium of claim 15. CHANG further discloses:
wherein at least one of the first gateway device and the second gateway device is configured as a virtual machine. (¶ 0021: [P]rivate cloud network gateway 110 can be configured as a VM for extending the private cloud across the Internet to the public cloud 104 through the site-to-site tunnel 108. The public cloud network gateway 112 can be configured as a VM switch overlay for interconnecting workloads running in the public cloud 104 via secure access tunnels, and for forwarding network traffic to the private network 102 using the site-to-site tunnel 108)
Regarding claim 20, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the non-transitory computer readable storage medium of claim 1. CHANG further discloses:
wherein the virtual switch processor is configured to configure the control virtual network using resources of the cloud virtual network. (Claim 3: [T]he cloud orchestrator includes at least one of a virtual switch controller, a cloud manager, or a hypervisor manager)
Claims 4, 13, and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over CHANG in view of BRUNNER, KITADA, LAMBETH, and SCOTT, and in view of US 2021/0367842 (hereinafter, “LE GUILLOU”).
Regarding claim 4, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control system of claim 3. CHANG does not explicitly disclose:
wherein the new node detector detects the new virtual machine by receiving, from at least one of the virtual machines in the cloud virtual network, an IP address assignment request, and
the setting information transmitter transmits, to the new virtual machine, the network setting information via the cloud virtual network.
In the same field of endeavor, however, LE GUILLOU further teaches:
wherein the new node detector detects the new virtual machine by receiving, from at least one of the virtual machines in the cloud virtual network, an IP address assignment request, and (¶ 0217: [A]ccess equipment AP comprises a DHCP server module (not shown) and detects the IP address assignment request DHCP-REQUEST received by the DHCP server from the user equipment UE)
the setting information transmitter transmits, to the new virtual machine, the network setting information via the cloud virtual network. (¶ 0223: [A] transmission module for transmitting a configuration command to the user equipment UE comprising the plurality of configuration rules)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LE GUILLOU to incorporate functionality for detecting VMs introduced onto a cloud virtual network and for transmitting configuration information in order to/for the purposes of enabling network resource access management. See LE GUILLOU, ¶ 0002.
Regarding claim 13, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the control method of claim 12. CHANG does not explicitly disclose:
further comprising:
detecting the new virtual machine by receiving, from at least one of the virtual machines in the cloud virtual network, an IP address assignment request, and
transmitting, to the new virtual machine, the network setting information via the cloud virtual network.
In the same field of endeavor, however, LE GUILLOU further teaches:
detecting the new virtual machine by receiving, from at least one of the virtual machines in the cloud virtual network, an IP address assignment request, and (¶ 0217: [A]ccess equipment AP comprises a DHCP server module (not shown) and detects the IP address assignment request DHCP-REQUEST received by the DHCP server from the user equipment UE)
transmitting, to the new virtual machine, the network setting information via the cloud virtual network. (¶ 0223: [A] transmission module for transmitting a configuration command to the user equipment UE comprising the plurality of configuration rules)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LE GUILLOU to incorporate functionality for detecting UE new to the network and for transmitting configuration information in order to/for the purposes of enabling network resource access management. See LE GUILLOU, ¶ 0002.
Regarding claim 18, the combination of CHANG, BRUNNER, KITADA, LAMBETH, and SCOTT, as applied above, renders obvious the non-transitory computer readable storage medium of claim 17. CHANG does do not explicitly disclose:
wherein the computer further executes:
detecting the new virtual machine by receiving, from at least one of the virtual machines in the cloud virtual network, an IP address assignment request, and
transmitting, to the new virtual machine, the network setting information via the cloud virtual network.
In the same field of endeavor, however, LE GUILLO teaches:
detecting the new virtual machine by receiving, from at least one of the virtual machines in the cloud virtual network, an IP address assignment request, and (¶ 0217: [A]ccess equipment AP comprises a DHCP server module (not shown) and detects the IP address assignment request DHCP-REQUEST received by the DHCP server from the user equipment UE)
transmitting, to the new virtual machine, the network setting information via the cloud virtual network. (¶ 0223: [A] transmission module for transmitting a configuration command to the user equipment UE comprising the plurality of configuration rules)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid cloud network environment of CHANG with the teachings of LE GUILLOU to incorporate functionality for detecting UE new to the network and for transmitting configuration information in order to/for the purposes of enabling network resource access management. See LE GUILLOU, ¶ 0002.
Conclusion
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 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 Garth D Richmond whose telephone number is (703)756-4559. The Examiner can normally be reached M-F 8 a.m. - 5 p.m. ET.
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, Kathy Wang-Hurst can be reached at 571-270-5371. 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.
/GARTH D RICHMOND/Examiner, Art Unit 2644
/KATHY W WANG-HURST/Supervisory Patent Examiner, Art Unit 2644
Prosecution Insights