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 .
Information Disclosure Statement
The information disclosure statement (IDS) was submitted on 10/25/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
Double Patenting
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 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); 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claim(s) 1-20 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12, 14-19 of U.S. Patent No. 12,160,355. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-12, 14-19 of U.S. Patent No. 12,160,355 teach on each and every limitation of claims 1-20 of the Instant Application.
The term “obtaining” in the instant application is different from the term “receiving” in the US Patent 12,160,355 B2 as shown in the table below. The term “obtaining returned test responses” in the instant application is an obvious modification of “receiving returned test responses” because in order to obtain, the returned test responses must be received. This is an obvious modification as it yields the same expected, predictable results.
Instant Application
US Patent 12,160,355 B2
1. A method, comprising:
establishing, from an agent hub device, a tunnel to a remote vantage point device;
sending, by the agent hub device, test traffic into the tunnel to the remote vantage point device, wherein the remote vantage point device, after obtaining the test traffic, sends the test traffic as though the test traffic originates from the remote vantage point device,
obtaining, at the agent hub device, one or more returned test responses in response to the test traffic;
and producing, by the agent hub device, test results based on the one or more returned test responses.
1. A method, comprising:
establishing, from an agent hub device that operates as a cloud agent or enterprise agent on behalf of a plurality of remote vantage point devices, a virtual private network (VPN) tunnel to a remote vantage point device of the plurality of remote vantage point devices;
generating, by the agent hub device, test traffic to appear as though the test traffic originates from the remote vantage point device,
where the test traffic is associated with a test from the cloud agent or enterprise agent; encapsulating, by the agent hub device, the test traffic into the VPN tunnel to the remote vantage point device to cause the remote vantage point device to decapsulate the test traffic
and send the test traffic to one or more Internet devices as though the test traffic originated from the remote vantage point device;
receiving, at the agent hub device and from the one or more Internet devices, one or more returned test responses in response to the test traffic;
and producing, by the agent hub device, test results based on the one or more returned test responses.
2. The method as in claim 1, wherein the remote vantage point device sends the test traffic to appear as though the test traffic originates from the remote vantage point device by setting a source address of the test traffic to be a source address of the remote vantage point device.
2. The method as in claim 1, wherein generating the test traffic to appear as though the test traffic originates from the remote vantage point device comprises:
setting a source address of the test traffic to be a source address of the remote vantage point device.
3. The method as in claim 2, further comprising: applying an Internet Protocol Network Address Translation Masquerade to the test traffic.
14. …
applying an Internet Protocol Network Address Translation Masquerade to the test traffic
4. The method as in claim 1, further comprising: managing domain name service operations to appear to originate from the remote vantage point device.
3. The method as in claim 1, further comprising:
managing domain name service operations to appear to originate from the remote vantage point device.
5. The method as in claim 1, further comprising: removing effects of the tunnel from the test results.
4. The method as in claim 1, further comprising:
removing effects of the VPN tunnel from the test results.
6. The method as in claim 5, further comprising: measuring the effects of the tunnel as part of the test traffic.
5. The method as in claim 4, further comprising: measuring the effects of the VPN tunnel as part of the test traffic.
7. The method as in claim 5, further comprising: using a pre-determined measurement of the effects of the tunnel for all test traffic.
6. The method as in claim 4, further comprising: using a pre-determined measurement of the effects of the VPN tunnel for all test traffic.
8. The method as in claim 1, wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device.
7. The method as in claim 1, wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device.
9. The method as in claim 8, wherein the one or more measured metrics are selected from a group consisting of: geographical distance; latency; bandwidth; number of autonomous system hops; number of hops; and jitter.
8. The method as in claim 7, wherein the one or more measured metrics are selected from a group consisting of: geographical distance; latency; bandwidth; number of autonomous system hops; number of hops; and jitter.
10. The method as in claim 1, wherein the agent hub device is selected based on one or more performance minimums between the agent hub device and the remote vantage point device.
9. The method as in claim 1, wherein the agent hub device is selected based on one or more performance minimums between the agent hub device and the remote vantage point device.
11. The method as in claim 1, wherein the tunnel is an Internet Protocol Security Virtual Private Network tunnel.
10. The method as in claim 1, wherein the tunnel is an Internet Protocol Security (IPsec) VPN tunnel.
12. The method as in claim 1, wherein the test traffic comprises probe traffic to one or more applications.
11. The method as in claim 1, wherein the test traffic comprises probe traffic to one or more applications.
13. The method as in claim 1, further comprising: operating as an agent hub device for a plurality of remote vantage point devices.
12. The method as in claim 1, wherein the agent hub device operates as a hub device for a plurality of remote vantage point devices including the remote vantage point device.
14. The method as in claim 1, wherein the agent hub device is one of either a cloud agent or an enterprise agent.
1. … establishing, as an agent hub device that operates as a cloud agent or enterprise agent on behalf of a plurality of remote vantage point devices
15. A tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor on a computer, cause the computer to perform a method comprising:
establishing, as an agent hub device, a tunnel to a remote vantage point device;
sending test traffic into the tunnel to the remote vantage point device, wherein the remote vantage point device, after obtaining the test traffic, sends the test traffic as though the test traffic originates from the remote vantage point device,
obtaining one or more returned test responses in response to the test traffic;
and producing test results based on the one or more returned test responses.
14. A tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor on a computer, cause the computer to perform a method comprising:
establishing, as an agent hub device that operates as a cloud agent or enterprise agent on behalf of a plurality of remote vantage point devices, a virtual private network (VPN) tunnel to a remote vantage point device of the plurality of remote vantage point devices;
generating test traffic to appear as though the test traffic originates from the remote vantage point device
1. … and send the test traffic to one or more Internet devices as though the test traffic originated from the remote vantage point device;
by applying an Internet Protocol Network Address Translation Masquerade to the test traffic, where the test traffic is associated with a test from the cloud agent or enterprise agent by applying an Internet Protocol Network Address Translation Masquerade to the test traffic; encapsulating the test traffic into the VPN tunnel to the remote vantage point device to cause the remote vantage point device to decapsulate the test traffic to one or more Internet devices as though the test traffic originated from the remote vantage point device;
receiving, from the one or more Internet devices, one or more returned test responses in response to the test traffic;
and producing test results based on the one or more returned test responses.
16. The tangible, non-transitory, computer-readable medium as in claim 15, the remote vantage point device sends the test traffic to appear as though the test traffic originates from the remote vantage point device by setting a source address of the test traffic to be a source address of the remote vantage point device.
15. The tangible, non-transitory, computer-readable medium as in claim 14, wherein generating the test traffic to appear as though the test traffic originates from the remote vantage point device comprises:
setting a source address of the test traffic to be a source address of the remote vantage point device.
17. The tangible, non-transitory, computer-readable medium as in claim 15, wherein the method further comprises: managing domain name service operations to appear to originate from the remote vantage point device.
16. The tangible, non-transitory, computer-readable medium as in claim 14, wherein the method further comprises:
managing domain name service operations to appear to originate from the remote vantage point device.
18. The tangible, non-transitory, computer-readable medium as in claim 15, wherein the method further comprises: removing effects of the tunnel from the test results.
17. The tangible, non-transitory, computer-readable medium as in claim 14, wherein the method further comprises:
removing effects of the VPN tunnel from the test results.
19. The tangible, non-transitory, computer-readable medium as in claim 15, wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device.
18. The tangible, non-transitory, computer-readable medium as in claim 14, wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device.
20. An apparatus, comprising: one or more network interfaces to communicate with a network; a processor coupled to the one or more network interfaces and configured to execute one or more processes;
and a memory configured to store a process that is executable by the processor, the process, when executed, configured to:
establish, as an agent hub device, a tunnel to a remote vantage point device;
send test traffic into the tunnel to the remote vantage point device, wherein the remote vantage point device, after obtaining the test traffic, sends the test traffic as though the test traffic originates from the remote vantage point device,
receive one or more returned test responses in response to the test traffic;
and produce test results based on the one or more returned test responses.
19. An apparatus, comprising: one or more network interfaces to communicate with a network; a processor coupled to the one or more network interfaces and configured to execute one or more processes;
and a memory configured to store a process that is executable by the processor, the process, when executed, configured to:
establish, as an agent hub device that operates as a cloud agent or enterprise agent on behalf of a plurality of remote vantage point devices, a virtual private network (VPN) tunnel to a remote vantage point device of the plurality of remote vantage point devices;
generate test traffic to appear as though the test traffic originates from the remote vantage point device, where the test traffic is associated with a test from the cloud agent or enterprise agent;
encapsulate the test traffic into the VPN tunnel to the remote vantage point device to cause the remote vantage point device to decapsulate the test traffic
and send the test traffic to one or more Internet devices as though the test traffic originated from the remote vantage point device;
receive, from the one or more Internet devices, one or more returned test responses in response to the test traffic;
and produce test results based on the one or more returned test responses.
Claim Rejections - 35 USC § 112
112(b):
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.
Claim(s) 5-9, 18 is/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 5 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: measuring tunnel effects. Claim 5 recites “removing effects of the tunnel from the test results.” This renders the claim unclear as Claim 5 depends on Claim 1 and Claim 1 does not have a step for measuring effects of the tunnel. It is unclear as to removal of the effects of the tunnel from the test results as the essential step of measuring the effects of the tunnel is missing. This same rejection applies to Claim 18.
Claim 8 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: selection of an agent hub device, measuring metrics. Claim 8 recites “wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device.” This renders the claim unclear as Claim 8 depends on Claim 1 and Claim 1 does not have a step for selection of an agent hub device nor a step on measuring metrics. It is unclear as to the selection of the agent hub device based on measured metrics when there is no step for measuring metrics and no step for selection of the agent hub device.
Dependents are also rejected as having the same deficiencies as the claims from which they depend.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 13-16, 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2015/0103679 Al (Tessmer).
Regarding Claim 1:
Tessmer teaches A method, comprising:
establishing, from an agent hub device (ie. controller, host machine), a tunnel to a remote vantage point device (ie. next hop, second host machine, tunnel endpoint); ([0020] a first host machine generates a packet to send for the connectivity test, then (i) inserts logical network information into the generated packet and (ii) encapsulates the generated packet with tunnel endpoint information that specifies a tunnel between the first host machine and a second host machine. Claim 1. … receiving a command to test connectivity between the first host machine and a set of at least one additional host machine that also host virtual machines on the particular logical network; Claim 2. The method of claim 1, wherein the command is received from a network controller that manages the first host machine and a plurality of additional host machines.)
sending, by the agent hub device, test traffic into the tunnel to the remote vantage point device (ie. next hop, second host machine, tunnel endpoint), ([0026] Next, the process 100 generates (at 110) a connectivity test packet to send to the one or more destination machines for the requested connectivity test. [0027] Thus, the process next appends (at 115) or inserts logical network information to the connectivity test packet. The generated test packet is sent to the virtual switch on the host, which stores the logical network data for various logical networks supported by the host machine. The virtual switch uses this logical network data to append the correct logical network information to the packet in a designated logical network information section. [0028] The process 100 next encapsulates (at 120) the packet in a tunnel between two tunnel endpoints. [0029] Next, the process 100 sends (at 125) the encapsulated packet to the appropriate next hop for the connection between tunnel endpoints.)
wherein the remote vantage point device (ie. next hop, second host machine, tunnel endpoint), after obtaining the test traffic, sends the test traffic as though the test traffic originates from the remote vantage point device, ([0030] The command received to initiate the connectivity test may indicate a single destination ( e.g., one host machine) or multiple destinations ( e.g., a broadcast to all host machines that host VMs connected to a particular logical network. The tunnel endpoint then adds different encapsulations for each replicated packet, with packets for different tunnel endpoints having different destination addresses. [0065] Fig 4 & 5, The test packets sent by the host machine that receives the command to initiate a connectivity test first have logical network information appended and are then encapsulated with a tunnel header. [0070] the tunnel encapsulation section contains (i) a source VTEP MAC address, (ii) a destination VTEP MAC address, (iii) a source VTEP IP address, and (iv) a destination VTEP IP address. In the example shown in FIG. 4, the encapsulation on the test packet 420 uses the addresses of the VTEP located at host 400 for its source addresses and the addresses of the VTEP located at host 405 for its destination addresses.) Encapsulation allows the packet to appear as originating from the sender and includes the source address of the sender.
obtaining, at the agent hub device, one or more returned test responses in response to the test traffic; ([0032] After sending the packet or packets, the process 100 awaits (at 130) one or more return packets from the destination host machines. … The virtual switch identifies the logical network information in the packet as well as the flag that marks the packet as a connectivity test packet. Accordingly, the host machine generates a reply to send back to the source machine.)
and producing, by the agent hub device, test results based on the one or more returned test responses. ([0043] The control interface 220 communicates (through a virtual switch, such as virtual switch 210) with one or more controllers external to the host, such as the controller 285. The controllers can send commands to test the connectivity between the host machine 200 and one or more additional host machines (e.g., in the data center). The control interface 220 also sends replies back to the controllers---e.g., VM and/or virtual switch status data, connectivity test results, etc. [0057] reply packets, results of connectivity test.)
Regarding Claim 15:
Tessmer teaches A tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor on a computer ([0081] features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium. When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions.), cause the computer to perform a method comprising:
establishing, as an agent hub device (ie. controller, host machine), a tunnel to a remote vantage point device (ie. next hop, second host machine, tunnel endpoint); ([0020] a first host machine generates a packet to send for the connectivity test, then (i) inserts logical network information into the generated packet and (ii) encapsulates the generated packet with tunnel endpoint information that specifies a tunnel between the first host machine and a second host machine. Claim 1. … receiving a command to test connectivity between the first host machine and a set of at least one additional host machine that also host virtual machines on the particular logical network; Claim 2. The method of claim 1, wherein the command is received from a network controller that manages the first host machine and a plurality of additional host machines.)
sending test traffic into the tunnel to the remote vantage point device (ie. next hop, second host machine, tunnel endpoint), ([0026] Next, the process 100 generates (at 110) a connectivity test packet to send to the one or more destination machines for the requested connectivity test. [0027] Thus, the process next appends (at 115) or inserts logical network information to the connectivity test packet. The generated test packet is sent to the virtual switch on the host, which stores the logical network data for various logical networks supported by the host machine. The virtual switch uses this logical network data to append the correct logical network information to the packet in a designated logical network information section. [0028] The process 100 next encapsulates (at 120) the packet in a tunnel between two tunnel endpoints. [0029] Next, the process 100 sends (at 125) the encapsulated packet to the appropriate next hop for the connection between tunnel endpoints.)
wherein the remote vantage point device (ie. next hop, second host machine, tunnel endpoint), after obtaining the test traffic, sends the test traffic as though the test traffic originates from the remote vantage point device, ([0030] The command received to initiate the connectivity test may indicate a single destination ( e.g., one host machine) or multiple destinations ( e.g., a broadcast to all host machines that host VMs connected to a particular logical network. The tunnel endpoint then adds different encapsulations for each replicated packet, with packets for different tunnel endpoints having different destination addresses. [0065] Fig 4 & 5, The test packets sent by the host machine that receives the command to initiate a connectivity test first have logical network information appended and are then encapsulated with a tunnel header. [0070] the tunnel encapsulation section contains (i) a source VTEP MAC address, (ii) a destination VTEP MAC address, (iii) a source VTEP IP address, and (iv) a destination VTEP IP address. In the example shown in FIG. 4, the encapsulation on the test packet 420 uses the addresses of the VTEP located at host 400 for its source addresses and the addresses of the VTEP located at host 405 for its destination addresses.) Encapsulation allows the packet to appear as originating from the sender and includes the source address of the sender.
obtaining one or more returned test responses in response to the test traffic; ([0032] After sending the packet or packets, the process 100 awaits (at 130) one or more return packets from the destination host machines. … The virtual switch identifies the logical network information in the packet as well as the flag that marks the packet as a connectivity test packet. Accordingly, the host machine generates a reply to send back to the source machine.)
and producing test results based on the one or more returned test responses. ([0043] The control interface 220 communicates (through a virtual switch, such as virtual switch 210) with one or more controllers external to the host, such as the controller 285. The controllers can send commands to test the connectivity between the host machine 200 and one or more additional host machines (e.g., in the data center). The control interface 220 also sends replies back to the controllers---e.g., VM and/or virtual switch status data, connectivity test results, etc. [0057] reply packets, results of connectivity test.)
Regarding Claim 20:
Tessmer teaches An apparatus, comprising: one or more network interfaces to communicate with a network; a processor coupled to the one or more network interfaces (Claim 11. an interface to a physical network that connects the plurality of host machines.) and configured to execute one or more processes; and a memory configured to store a process that is executable by the processor, ([0081] features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium. When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions.) the process, when executed, configured to:
establish, as an agent hub device (ie. controller, host machine), a tunnel to a remote vantage point device (ie. next hop, second host machine, tunnel endpoint); ([0020] a first host machine generates a packet to send for the connectivity test, then (i) inserts logical network information into the generated packet and (ii) encapsulates the generated packet with tunnel endpoint information that specifies a tunnel between the first host machine and a second host machine. Claim 1. … receiving a command to test connectivity between the first host machine and a set of at least one additional host machine that also host virtual machines on the particular logical network; Claim 2. The method of claim 1, wherein the command is received from a network controller that manages the first host machine and a plurality of additional host machines.)
send test traffic into the tunnel to the remote vantage point device (ie. next hop, second host machine, tunnel endpoint), ([0026] Next, the process 100 generates (at 110) a connectivity test packet to send to the one or more destination machines for the requested connectivity test. [0027] Thus, the process next appends (at 115) or inserts logical network information to the connectivity test packet. The generated test packet is sent to the virtual switch on the host, which stores the logical network data for various logical networks supported by the host machine. The virtual switch uses this logical network data to append the correct logical network information to the packet in a designated logical network information section. [0028] The process 100 next encapsulates (at 120) the packet in a tunnel between two tunnel endpoints. [0029] Next, the process 100 sends (at 125) the encapsulated packet to the appropriate next hop for the connection between tunnel endpoints.)
wherein the remote vantage point device (ie. next hop, second host machine, tunnel endpoint), after obtaining the test traffic, sends the test traffic as though the test traffic originates from the remote vantage point device, ([0030] The command received to initiate the connectivity test may indicate a single destination ( e.g., one host machine) or multiple destinations ( e.g., a broadcast to all host machines that host VMs connected to a particular logical network. The tunnel endpoint then adds different encapsulations for each replicated packet, with packets for different tunnel endpoints having different destination addresses. [0065] Fig 4 & 5, The test packets sent by the host machine that receives the command to initiate a connectivity test first have logical network information appended and are then encapsulated with a tunnel header. [0070] the tunnel encapsulation section contains (i) a source VTEP MAC address, (ii) a destination VTEP MAC address, (iii) a source VTEP IP address, and (iv) a destination VTEP IP address. In the example shown in FIG. 4, the encapsulation on the test packet 420 uses the addresses of the VTEP located at host 400 for its source addresses and the addresses of the VTEP located at host 405 for its destination addresses.) Encapsulation allows the packet to appear as originating from the sender and includes the source address of the sender.
obtain one or more returned test responses in response to the test traffic; ([0032] After sending the packet or packets, the process 100 awaits (at 130) one or more return packets from the destination host machines. … The virtual switch identifies the logical network information in the packet as well as the flag that marks the packet as a connectivity test packet. Accordingly, the host machine generates a reply to send back to the source machine.)
and produce test results based on the one or more returned test responses. ([0043] The control interface 220 communicates (through a virtual switch, such as virtual switch 210) with one or more controllers external to the host, such as the controller 285. The controllers can send commands to test the connectivity between the host machine 200 and one or more additional host machines (e.g., in the data center). The control interface 220 also sends replies back to the controllers---e.g., VM and/or virtual switch status data, connectivity test results, etc. [0057] reply packets, results of connectivity test.)
Regarding Claims 2, 16:
Tessmer teaches on the inventions of Claims 1, 15 as described.
Tessmer teaches wherein the remote vantage point device sends the test traffic to appear as though the test traffic originates from the remote vantage point device by setting a source address of the test traffic to be a source address of the remote vantage point device. ([0030] The command received to initiate the connectivity test may indicate a single destination ( e.g., one host machine) or multiple destinations ( e.g., a broadcast to all host machines that host VMs connected to a particular logical network. The tunnel endpoint then adds different encapsulations for each replicated packet, with packets for different tunnel endpoints having different destination addresses. [0065] Fig 4 & 5, The test packets sent by the host machine that receives the command to initiate a connectivity test first have logical network information appended and are then encapsulated with a tunnel header. [0070] the tunnel encapsulation section contains (i) a source VTEP MAC address, (ii) a destination VTEP MAC address, (iii) a source VTEP IP address, and (iv) a destination VTEP IP address. In the example shown in FIG. 4, the encapsulation on the test packet 420 uses the addresses of the VTEP located at host 400 for its source addresses and the addresses of the VTEP located at host 405 for its destination addresses.) Encapsulation allows the packet to appear as originating from the sender and includes the source address of the sender.
Regarding Claim 13:
Tessmer teaches on the invention of Claim 1 as described.
Tessmer teaches further comprising: operating as an agent hub device for a plurality of remote vantage point devices. (1. … receiving a command to test connectivity between the first host machine and a set of at least one additional host machine that also host virtual machines on the particular logical network; 2. The method of claim 1, wherein the command is received from a network controller that manages the first host machine and a plurality of additional host machines. [0028]-[0030] multiple endpoints. [0036] The physical network 275 connects the host 200 to additional hosts 280 and network controller 285.)
Regarding Claim 14:
Tessmer teaches on the invention of Claim 1 as described.
Tessmer teaches wherein the agent hub device is a cloud agent. ([0089] Finally, as shown in FIG. 8, bus 805 also couples electronic system 800 to a network 865 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network ("LAN"), a wide area network ("WAN"), or an Intranet, or a network of networks, such as the Internet.)
Claim Rejections - 35 USC § 103
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.
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.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0103679 Al (Tessmer) in view of US PGPub 2006/0029064 A1 (Rao).
Regarding Claim 3:
Tessmer teaches on the invention of Claim 2 as described.
Tessmer teaches on routing traffic ([0028]-[0030]). However, Tessmer is silent on applying an Internet Protocol Network Address Translation Masquerade to the test traffic.
Rao teaches, in the same field of endeavor, a method for routing packets from an endpoint to a gateway, Abstract.
Rao also teaches on applying an Internet Protocol Network Address Translation Masquerade to the test traffic. ([0128] Once the VPN tunnel is established and routing information for the network on which the VPN gateway computing device 940 resides is retrieved from the VPN gateway computing device 940. [0134] The gateway computing device is a virtual VPN gateway computing device using NAT to masquerade the IP addresses of the protected system and of the private network. A NAT-enabled VPN gateway computing device may monitor and secure packet traffic permitting more secure transmission of traffic to dynamic ports on a client computing device from the private network,)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Rao to include applying an Internet Protocol Network Address Translation Masquerade to the test traffic. This would have been advantageous as discussed, as it would allow the modified system to provide further security and privacy of IP addressing when testing between nodes in a network.
Claim(s) 4, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0103679 Al (Tessmer) in view of US 9411787 B1 (Lad).
Regarding Claims 4, 17:
Tessmer teaches on the inventions of Claims 1, 15 as described.
Tessmer teaches on endpoints adding different encapsulations for each replicated packet when forwarding packets ([0030]). However, Tessmer is silent on further comprising: managing domain name service operations to appear to originate from the remote vantage point device.
Lad teaches, in the same field of endeavor, on cross-layer troubleshooting of application delivery which includes collecting test results from a plurality of distributed agents for a plurality of application delivery layers, Abstract.
Lad teaches managing domain name service (DNS) operations to appear to originate from the remote vantage point device. (Col 20 ln 24-31, A DNS test (e.g., that can be performed by one or more distributed agents and controlled by agent controllers, such as agent controllers 114) includes several authoritative name servers that serve a specific domain name. For example, DNS queries from agents can be sent to the specified DNS servers targeting the specified domain name (e.g., one or more domain names that an entity wants to test for, such as www.domain-name.com).) The agents will run the domain services from where they are distributed/installed.
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Lad to include managing domain name service operations to appear to originate from the remote vantage point device. This would have been advantageous as discussed, as it would allow the modified system to provide a more thorough testing of the cloud environment by including testing domain name services when deploying test agents for determining URL resolution and accuracy.
Claim(s) 5-7, 11, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0103679 Al (Tessmer) in view of US PGPub 2005/0094567 A1 (Kannan).
Regarding Claims 5, 18:
Tessmer teaches on the inventions of Claims 1, 15 as described.
Tessmer teaches on reply packets and test results ([0043][0057]). However, Tessmer is silent on removing effects of the tunnel from the test results.
Kannan teaches, in the same field of endeavor, systems and methods for testing network systems and processors, [0008].
Kannan also teaches removing effects of the VPN tunnel from the test results. ([0058] Returning to packet generation step 550, PE Router B 1301 receives the generated packets from tunnel 7100 and routes those packets to GRE tunnel 7204 and INE 1171. INE 1171 may then initiate tests of the received packet(s) to determine performance (step 5600). Moreover, in one embodiment, INE 1171 removes the packet loss, jitter, and latency effects of the GRE tunnels 7204 and 7200, so that the determined performance measurements represent only tunnel 7100.)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Kannan to include removing effects of the VPN tunnel from the test results. This would have been advantageous as discussed, as it would allow the modified system to provide further detail and accuracy in the results by providing only the results of the test traffic data.
Regarding Claim 6:
Tessmer (as modified by Kannan) teaches on the invention of Claim 5 as described.
Tessmer teaches on reply packets and test results ([0043][0057]). However, Tessmer is silent on further comprising: measuring the effects of the tunnel as part of the test traffic.
Kannan teaches measuring the effects of the tunnel as part of the test traffic. ([0060] The jitter, latency, and packet loss effects of GRE tunnels 7200 and 7204 should be removed from performance calculations made for the interface under test. The INE 1171 determines the time Tl, which represents the end-to-end latency (time) measured between INE 1170 (as source) to INE 1171 (as destination). INE 1170 then determines time T2 by performing a loop back test, sending one or more packets (with time stamps) to tunnel 7200, PE Router A 1200, and returning on tunnel 7201.)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Kannan to include measuring the effects of the tunnel as part of the test traffic. This would have been advantageous as discussed, as it would allow the modified system to provide accuracy when removing the effects of the VPN tunnel from the testing results, by testing the tunnels to determine tunnel effects.
Regarding Claim 7:
Tessmer (as modified by Kannan) teaches on the invention of Claim 5 as described.
Tessmer teaches on reply packets and test results ([0043][0057]). However, Tessmer is silent on further comprising: using a pre-determined measurement of the effects of the tunnel for all test traffic.
Kannan teaches using a pre-determined measurement of the effects of the tunnel for all test traffic. ([0059] One way to correct for the GRE tunnel portion 7200 is to use the traditional "ping" protocol utility (from the INE to the PE) on the GRE Tunnel 7200 and use the results to correct for the error introduced by the GRE tunnel 7200. Another ping can be performed over GRE tunnel 7204. The results of the ping tests, which provide time to traverse the tunnels, can be used to remove the effects of each of tunnels 7200 and 7204. A more accurate approach is to use a loop back (also referred to as a second tunnel approach). For example, to correct for GRE tunnel 7200, tunnel 7201 is established, and to correct for tunnel 7204, tunnel 7203 is established, as shown in FIG. 7.)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Kannan to include using a pre-determined measurement of the effects of the tunnel for all test traffic. This would have been advantageous as discussed, as it would allow the modified system to provide accuracy when removing the effects of the tunnel from the testing results, by pre-testing the tunnels to determine tunnel effects and providing this as a pre-determined measurement before submitting other test traffic into the tunnels.
Regarding Claim 11:
Tessmer teaches on the invention of Claim 1 as described.
Tessmer teaches on tunnels and tunnel encapsulation ([0030][0031]) However, Tessmer is silent on wherein the tunnel is an Internet Protocol Security Virtual Private Network tunnel.
Kannan teaches wherein the tunnel is an Internet Protocol Security Virtual Private Network tunnel. (Claim 18. The method of claim 17, comprising: establishing the tunnel based on at least one of a Generic Routing Encapsulation (GRE) protocol, an IPSec (Internet Protocol Security) protocol, a VLAN protocol, and an IP encapsulation within IP (IP-in-IP) protocol.)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Kannan to include wherein the tunnel is an Internet Protocol Security Virtual Private Network tunnel. This would have been advantageous as discussed, as it would allow the modified system to provide further security when testing between private networks.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0103679 Al (Tessmer) in view of US Patent 8,989,199 B1 (Sella).
Regarding Claim 10:
Tessmer teaches on the invention of Claim 1 as described.
Tessmer teaches on multiple controllers, host machines and endpoints as well as testing connectivity of segments ([0028][0043]). However, Tessmer is silent on wherein the agent hub device is selected based on one or more performance minimums between the agent hub device and the remote vantage point device.
Sella teaches, in the same field of endeavor, A Software Defined Network (SDN) includes a plurality of forwarding devices and a routing control device located separate from the forwarding devices, Abstract.
Sella also teaches wherein the agent hub device is selected based on one or more performance minimums between the agent hub device and the remote vantage point device. (The forwarding device may ask the controller with the lowest latency to establish a fast path to a destination. For example, a device may choose to balance traffic across multiple paths to the controllers, perhaps by rounding the metric to a closest 5 for example, therefore treating performance values of 3, 4, 5, 6, 7 as the same as a value of 5. Among those controllers with the lowest rounded metric, the forwarding device may adopt a round robin algorithm to select the controller to create the fast path. This helps to limit the impact of slight modifications in the performance values as the network reacts to real world situations., Col 10 ln 33-45)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Sella to include wherein the agent hub device is selected based on one or more performance minimums between the agent hub device and the remote vantage point device. This would have been advantageous as discussed, as it would allow the modified system to choose an agent hub device closest to areas of the network that will be tested as well as allowing for choosing a controller with the least latency, see Sella (Col 10 ln 33-45).
Claim(s) 8-9, 12, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0103679 Al (Tessmer) in view of US Patent 10,728,135 B2 (Raney).
Regarding Claims 8, 19:
Tessmer teaches on the inventions of Claims 1, 15 as described.
Tessmer teaches on multiple controllers, host machines and endpoints as well as testing connectivity of segments ([0028][0043]). However, Tessmer is silent on wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device.
Raney teaches wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device. (Col 7 ln 16-26, Deployment information 215 can include, for example, information concerning geographic location, source/destination addresses such as IP (Internet Protocol) addresses, traffic type, server zone, geographic region, a range of IP addresses, a data center identifier, a server identifier, a cluster identifier, a host identifier, a geo-location identifier, and/or other desired deployment information, Col 6 ln 58-65. When testing is desired, the test controller 220 uses this deployment information 215 within database 216 to determine processing nodes for dynamic placement of test agents.)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Raney to include wherein the agent hub device is selected from a plurality of options based on one or more measured metrics between the agent hub device and the remote vantage point device. This would have been advantageous as discussed, as it would allow the modified system to provide optimal placement of probes/test agents based on collected metrics, see Raney Col 7 ln 16-26.
Regarding Claim 9:
Tessmer (as modified by Raney) teaches on the invention of Claim 8 as described.
Tessmer teaches on reply packets and test results ([0043][0057]). However, Tessmer is silent on wherein the one or more measured metrics are selected from a group consisting of: geographical distance; latency; bandwidth; number of autonomous system hops; number of hops; and jitter.
Raney teaches wherein the one or more measured metrics are selected from a group consisting of: geographical distance (ie. region, zone, geo-location identifier). (Col 7 ln 16-26, Deployment information 215 can include, for example, information concerning geographic location, source/destination addresses such as IP (Internet Protocol) addresses, traffic type, server zone, geographic region, a range of IP addresses, a data center identifier, a server identifier, a cluster identifier, a host identifier, a geo-location identifier, and/or other desired deployment information, Col 6 ln 58-65. When testing is desired, the test controller 220 uses this deployment information 215 within database 216 to determine processing nodes for dynamic placement of test agents.)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Raney to include wherein the one or more measured metrics are selected from a group consisting of: geographical distance. This would have been advantageous as discussed, as it would allow the modified system to provide optimal placement of probes/test agents based on distance, see Raney Col 7 ln 16-26.
Regarding Claim 12:
Tessmer teaches on the invention of Claim 1 as described.
Tessmer teaches on reply packets and test results ([0043][0057]). However, Tessmer is silent on wherein the test traffic comprises probe traffic to one or more applications.
Raney teaches wherein the test traffic comprises probe traffic to one or more applications. (When testing is desired, the test controller 220 uses this deployment information 215 within database 216 to determine processing nodes for dynamic placement of test agents. For example, it is assumed for example embodiment 200 that a test is desired for network traffic between an application in the first server zone (ZONE1) 108 and an application in the second server zone (ZONE2) 110. As such, test agents 208 and 210 have been dynamically placed and activated with respect to application 206 and application 124 while no test agent has been placed and activated in the third server zone (ZONE3) 112 for application 114B, Col 7 ln 16-26)
It would have been obvious to an ordinary person having skill in the art before the effective filing date of the claimed invention, to modify Tessmer per Raney to include wherein the test traffic comprises probe traffic to one or more applications. This would have been advantageous as discussed, as it would allow the modified system to provide collection abilities to the generated packets, to be able to customize the metrics collected along the path taken by the packet.
Conclusion & Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHEL J HACKENBERG whose telephone number is (571)272-5417. The examiner can normally be reached 9am-5pm M-F.
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, Glenton B Burgess can be reached at (571)272-3949. 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.
/RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454
Prosecution Insights