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 .
Response to Arguments
The applicant’s amendments have overcome the previously made rejections based on 35 USC section 112(a) but have introduced new issues. Claim 1 is not found to be clear because it recites functionality of devices but it is not clear how this functionality relates to the claimed process. Claim 16 is rejected because it redundantly claims the same disclosed step twice, as explained in the rejection. Applicant’s arguments with respect the prior art about claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 16-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 16 has been amended as follows:
pushing thegateway accept list of gateway routers to the floating hub gateway router;
providing router identified in the gateway accept list; and
causing the floating hub gateway router to iterate over the gateway accept list secure tunnel with each gateway router identified in the gateway accept list to enable the inter-gateway connectivity between the gateway routers identified in the gateway accept list.
Claim 16 covers program instructions executed by the disclosed “controller”. The “controller” is distinct from the “floating hub gateway router”, as the controller brings the floating head gateway router into existence in the deploying limitation. The applicant’s disclosure does not have support for both the “pushing” and “causing” limitations covered by amended claim 16, as shown in paragraph 35 of the applicant’s disclosure.
Paragraph 35 states:
[0035] The process 200 pushes (at 220) a gateway accept list configuration to the floating hub gateway identifying the gateway routers that are allowed to connect to the floating hub gateway. The gateway accept list configuration, in some embodiments, includes a list of gateway routers with which the floating hub gateway is allowed to establish connections. In some embodiments, the gateway accept list is a filtered list generated after all isolations that are required based on policy and/or settings to facilitate per-gateway level filtering have been applied (i.e., no gateway router interconnect required specifications). The controller (e.g., SD-WAN controller) then generates this accept-list and pushes it to the floating hub gateway, and the floating hub gateway then iterates over the accept-list and establishes tunnels towards specified gateway routers, according to some embodiments.
The applicant has disclosed that the pushing is what causes the floating hub gateway to iterate over the accept list and establish tunnels. Therefore, there is no support in the disclosure for the claim language which covers both steps of pushing and causing as separate actions because they are disclosed as the same action. It is the pushing that causes the floating hub gateway router to perform the iteration; there is no separate cause disclosed.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-15 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.
Claims 1-15 are 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: Claim 1 is a process claim. It explicitly covers the explicit steps of deploying a floating head gateway, generating a gateway accept list, and pushing the gateway accept list to the floating head gateway. This process is performed by an entity other than the floating head gateway, as the process is deploying the floating head gateway, bringing it into existence. After the pushing step, the claims define the configuration of “the floating head gateway” and the configuration of “each gateway router in the accept list”. It is unclear how the “wherein” clauses which define the functions performed by these claim elements are intended to limit the scope of the claimed process. If the applicant wants the process to cover the functions that the floating hub gateway router and each gateway router in the accept list are configured to perform, then the applicant needs to explicitly claim these functions as steps of the process rather than properties of entities related to the process. As it is now, the Examiner cannot give patentable weight to the subject matter in the functions that the floating hub gateway router and each gateway router in the accept list are configured to perform because they do not recite limitations which limit the process claimed.
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.
Claim(s) 1-7 and 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication Number 2016/0127454 by Maheshwari et al. in view of U.S. Patent Application Publication Number 2018/0349323 by Madden et al.
As to claim 1, Maheshwari teaches a method for enabling inter-gateway connectivity in an SD-WAN (software-defined wide area network) that connects a plurality of remote branch sites (Figures 18A and 18B), the method comprising: deploying a floating hub gateway router (cloud exchange point 1803, paragraph 314, cloud exchanges can be operated a stand-alone device) for the SD-WAN, the SD-WAN including a plurality of gateway routers (PE 1810 and 1812 in Figures 18A and 18B) deployed in a cloud (paragraph 31 describes the how customers may deploy a cloud exchange by configuring it); generating a filtered gateway accept list of identifying gateway routers from among the plurality of gateway routers that are allowed to connect to the floating hub gateway router (paragraphs 35 and 340, the customer determines which interconnects using PE 1802 and 1804 to configure), pushing the gateway accept list to the floating hub gateway router (paragraphs 377-383, the policies supplied by the customer are pushed to cloud exchange 1803 about which gateway routers to cloud networks to manage traffic through); however Maheshwari does not explicitly teach that each gateway route in the accept list has a connection with an edge router in the remote branch site and the functions performed by the floating gateway router and each gateway router.
Madden teaches a method for enabling inter-gateway connectivity in an SD-WAN (software-defined wide area network) that connects a plurality of remote branch sites (paragraph 46, customers 308 can be located remotely from each other), the method comprising: each gateway router in an gateway accept list has a connection with an edge router (service gateways 312) in a remote branch site from among the plurality of remote branch sites (customers 308); and pushing the gateway accept list to the floating hub gateway router (paragraphs 47 and 55, policies are pushed from platform 328 to cloud exchange point 303); and wherein the floating hub gateway router is configured to: establish a tunnel connection with each gateway router in the gateway accept list (paragraph 58); avoid establishing a tunnel connection with any edge router in any remote branch site (paragraph 58, the tunnels do not include the service gateways); receive a set of routes associated with each gateway router in the gateway accept list via the tunnel connection established therewith (paragraphs 49-51); and distribute the set of routes associated with each gateway router among the gateway routers in the gateway accept list (paragraph 76); and wherein each gateway router in the gateway accept list is configured to: identify a route from among a set of routes associated with another gateway router in the gateway accept list (paragraph 84); receive data traffic from an edge router in a remote branch site having a connection therewith (Figure 3); and forward, using the identified route, the data traffic to the floating hub gateway router to reach the other gateway router (Figure 3).
It would have been obvious to one of ordinary skill in the SDN art at the time of the applicant’s filing to combine the teachings of Maheshwari regarding deploying and configuring floating hub gateway router with the teachings of Madden regarding having the gateway router being connected with an edge router because, as referenced in paragraph 67 of the Madden reference, it explicitly builds off of the Maheshwari reference and therefore the combination of features is explicitly suggested by the references themselves.
As to claim 2, see paragraph 54 of Madden and paragraphs 377-383 of Maheshwari.
As to claim 3, see paragraphs 377-383 of Maheshwari.
As to claim 4, see paragraph 3 of Maheshwari and paragraph 3 of Madden.
As to claim 5, see paragraph 313 of Maheshwari paragraph 4 of Madden, the cloud service providers are considered ISPs.
As to claim 6, see Figure 18B of Maheshwari and Figure 2B of Madden.
As to claim 7, see Figure 13 of Maheshwari.
As to claims 8 and 9, see Figures 18A and 18B of Maheshwari and Figures 2A and 2B an paragraphs 27 and 35 of Madden.
As to claim 10, see paragraphs 375-383 of Maheshwari.
As to claim 12, see Figure 18B of Madden
As to claims 13 and 14, see paragraph 76 of Madden.
As to claim 15, see paragraph 27 of Madden.
As to claim 16, Maheshwari teaches a non-transitory machine readable medium storing a program for execution by a set of processing units, the program for enabling inter-gateway connectivity in an SD-WAN (software defined wide area network) that that connects a plurality of remote branch sites (Figures 18A and 18B), the program comprising sets of instructions for: deploying a floating hub gateway router (cloud exchange point 1803, paragraph 314, cloud exchanges can be operated a stand-alone device) for the SD-WAN, the SD-WAN including a plurality of gateway routers (PE 1810 and 1812 in Figures 18A and 18B) deployed in a cloud (paragraph 31 describes the how customers may deploy a cloud exchange by configuring it); generating a gateway accept list identifying gateway routers from among the plurality of gateway routers that are allowed to connect to the floating hub gateway router (paragraphs 35 and 340, the customer determines which interconnects using PE 1802 and 1804 to configure),; and pushing the filtered gateway accept list of gateway routers to the floating hub gateway router (paragraphs 377-383, the policies supplied by the customer are pushed to cloud exchange 1803 about which gateway routers to cloud networks to manage traffic through); providing a network address of the floating hub gateway router to each gateway router identified in the gateway accept list (paragraph 375, 376); and causing the floating hub gateway router to iterate over the gateway accept list of gateway routers (paragraph 82), and to establish, using the network address of the floating hub gateway router, a secure tunnel with each gateway router identified in the gateway accept list (paragraph 53, 54) to enable the inter-gateway connectivity between the gateway routers identified in the gateway accept list (paragraph 51); however Maheshwari does not teach that each identified gateway router has a connection with an edge router in a remote branch site from among the plurality of remote branch sites.
Madden shows how in a cloud exchange system, like that taught by Maheshwari (paragraph 67 of Madden explains how the teachings of Madden apply directly to the architecture disclosed by Maheshwari), that each identified gateway router has a connection with an edge router (service gateways 312) in a remote branch site from among the plurality of remote branch sites (customers 308).
It would have been obvious to one of ordinary skill in the SDN art at the time of the applicant’s filing to combine the teachings of Maheshwari regarding deploying and configuring floating hub gateway router with the teachings of Madden regarding having the gateway router being connected with an edge router because, as referenced in paragraph 67 of the Madden reference, it explicitly builds off of the Maheshwari reference and therefore the combination of features is explicitly suggested by the references themselves.
As to claims 17-18, they are rejected for the same reasoning as claim 2-5.
As to claim 19, it is rejected for the same reasoning as claims 8 and 9.
As to claim 20, it is rejected for the same reason as claim 10.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication Number 2016/0127454 by Maheshwari et al. in view of U.S. Patent Application Publication Number 2018/0349323 by Madden further in view of U.S. Patent Application Publication Number 2010/0142410 by Huynh Van et al.
As to claim 11, the Maheshwari-Madden combination teaches the subject matter of claim 1 however the Maheshwari-Madden combination does not explicitly teach dynamically adding a gateway router.
Huynh Van teaches a method of dynamically adding a new gateway router to connect to a hub and directing the hub to establish a tunnel with the new gateway router (paragraph 331).
It would have been obvious to one of ordinary skill in the virtual network art at the time of the filing to combine the teachings of the Maheshwari-Madden combination regarding managing various CPE devices and their services with a hub with the teachings of Huynh Van regarding adding new CPE devices to be managed by a hub because managing new CPEs allows for more flexibility when managing the network.
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 DOUGLAS B BLAIR whose telephone number is (571)272-3893. The examiner can normally be reached Monday-Friday 9am-5pm.
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 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.
/DOUGLAS B BLAIR/ Primary Examiner, Art Unit 2454
Prosecution Insights