DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed on 10/11/2024.
Claims 1-20 are currently pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/14/2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note
Applicants are suggested to include information from paragraphs 0031-0032 of the specification into the claims to provide a better condition for an allowance.
Claim Rejections - 35 USC § 112
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.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Claim 1 (claims “part of 13” and 20 includes similar limitations) recites:
“… establishing a network tunnel from a CPE to a virtual router … providing a configuration interface accessible by a customer device; receiving … one or more selections of customer network information to be communicated over the network tunnel …”, however, it is not clear (1) whether the customer network information is selected by the customer device or not; (2) whether selections of the customer network information is related to the CPE or the virtual router or not – or omitting necessary steps/components which causes the claimed limitations unclear;
“… receiving … selections of customer network information … receiving customer network information from the CPE …”, however, it is not clear whether “customer network information” included in two different locations are the same or not (or receiving the same information twice) – it is not clear to define a boundary of the limitations/components.
Claims 2-11 depend from the claim 1, and are analyzed and rejected accordingly.
Claim 12 recites “… receiving a configuration indication indicating allowed customer network information, disallowed customer network information … receiving at least a portion of the allowed customer network information … based at least on the configuration indication”, however, it is not clear (1) what the “configuration indication” means (e.g., the configuration flag, etc.); (2) whether “a portion of the allowed customer network information” is received based on the disallowed customer network information or not.
Claims 13-19 depend from the claim 12, and are analyzed and rejected accordingly.
Claim 4 recites “… wherein the receiving comprises …”, however, it is not clear whether “the receiving” is referring to which receiving – it is not clear to define a boundary of the limitation/terms.
Claim 5 recites “… the receiving comprises a one-hop communication over the plurality of networks”, however, it is not clear how “the one-hop communication” can receives over the plurality of networks – or omitting necessary steps/components which causes the claimed limitations unclear.
Claim 10 recites “… third IP address for the network tunnel corresponding to the network tunnel”, however, it is not clear (1) whether the network tunnel is defined by the IP address or not; (2) what the term, “the network tunnel corresponding to the network tunnel”, means.
Claim 11 recites “… configuring a first port to receive a first type of customer network information; configuring a second port to receive a second type of customer network information; dropping received customer network information that is not configured to be received by a port”, however, it is not clear (1) whether the first/second port(s) are the ports of the CPE, the virtual router or the customer device – or omitting necessary steps/components which causes the claimed limitations unclear; (2) whether the customer network information has different types (e.g. the first type and the second type); (3) whether the received customer network information is the first type or the second type – it is not clear to define a boundary of the limitation/terms; (4) whether “a port” is the same as “a first port” or “a second port”.
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.
Claims 1-16, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sivasankaran (US 10,244,076 B2).
As per claim 1, Sivasankaran teaches a method, comprising:
establishing a network tunnel from a customer premises equipment (CPE) to a virtual router located at a provider site; providing a configuration interface accessible by a customer device [figs. 1, 2, 4, 6; col. 2, lines 14-21, 47-55; col. 5, lines 20-23; col. 8, lines 47-54; col. 10, lines 31-45 of Sivasankaran teaches establishing a network tunnel (e.g., the network tunnel to a particular CE router identified by the IP address and port, etc.) from a customer premises equipment (CPE) (e.g., the CE router to the customer device) to a virtual router (e.g., the router of cloud routing service system which uses the virtual routing table or the software defined networking (SDN) based solutions) located at a provider site (e.g., the cloud service provider network); providing a configuration interface (e.g., the user interface to a services portal or soliciting routing criteria) accessible by a customer device (e.g., the customer device (CD) 155)];
receiving, via the configuration interface, one or more selections of customer network information to be communicated over the network tunnel [figs. 1, 6; col. 8, lines 26-39; col. 10, lines 20-30 of Sivasankaran teaches receiving, via the configuration interface, one or more selections of customer network information (e.g., the fields 608, 610, 612, 614 of fig. 6) to be communicated over the network tunnel (e.g., the network tunnel between the particular CE router and the router of the cloud routing service system)];
automatically configuring the CPE based at least in part on the one or more selections; and receiving customer network information from the CPE through the network tunnel at the virtual router based at least in part on the configured CPE [figs. 1, 6, 7; col. 2, lines 47-55; col. 3, lines 3-27, col. 9, lines 23-32; col. 11, lines 65-67; col. 12, lines 1-10 of Sivasankaran teaches automatically configuring the CPE based at least in part on the one or more selections (e.g., the customer policies); and receiving customer network information (e.g., the customer routing information or the revised/alternative customer criteria) from the CPE (e.g., the CE router) through the network tunnel at the virtual router (e.g., the router of cloud routing service system) based at least in part on the configured CPE].
As per claim 2, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches receiving, at a computing device of the provider site, the one or more selections, wherein the automatically configuring of the CPE is performed by the computing device at the provider site [figs. 1, 4; col. 3, lines 8-27; col. 8, lines 40-54 of Sivasankaran teaches receiving, at a computing device of the provider site (e.g., the device of the cloud routing services system), the one or more selections (e.g., the customer policies), wherein the automatically configuring of the CPE is performed by the computing device at the provider site (e.g., the device of the cloud routing services system)].
As per claim 3, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches wherein the automatically configuring of the CPE is performed by the customer device [figs. 1, 4; col. 9, lines 18-32 of Sivasankaran teaches wherein the automatically configuring of the CPE is performed by the customer device (e.g., the customer device 155)].
As per claim 4, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches transmitting a query from the virtual router through the network tunnel to the CPE based at least in part on the configured CPE, wherein the receiving comprises receiving the customer network information from the CPE through the network tunnel at the virtual router based at least in part on the query [figs. 6, 7; col. 9, lines 23-32; col. 11, lines 65-67; col. 12, lines 1-10 of Sivasankaran teaches transmitting a query from the virtual router (e.g., the router of cloud routing service system which uses the virtual routing table or the software defined networking (SDN) based solutions) through the network tunnel to the CPE based at least in part on the configured CPE, wherein the receiving comprises receiving the customer network information (e.g., the customer routing information or the revised/alternative customer criteria) from the CPE through the network tunnel at the virtual router based at least in part on the query – see also the rejections to the claim 1].
As per claim 5, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches wherein receiving customer network information from the CPE comprises receiving customer network information over a plurality of networks, and wherein the receiving comprises a one-hop communication over the plurality of networks [figs. 3, 6, 7; col. 7, lines 7-20; col. 9, lines 23-32; col. 11, lines 65-67; col. 12, lines 1-10 of Sivasankaran teaches wherein receiving customer network information (e.g., the customer routing information or the revised/alternative customer criteria) from the CPE comprises receiving customer network information over a plurality of networks (e.g., the plurality of CE routers of the networks), and wherein the receiving comprises a one-hop communication (e.g., the WiFi communications, Bluetooth wireless communications, etc.) over the plurality of networks].
As per claim 6, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches wherein receiving customer network information from the CPE comprises receiving customer network information comprising at least one of network packet header information, simple network management protocol (SNMP) information, or interface statistics [fig. 6; col. 10, lines 11-19, 41-45 of Sivasankaran teaches wherein receiving customer network information from the CPE comprises receiving customer network information comprising at least one of network packet header information (e.g., the IP address), simple network management protocol (SNMP) information, or interface statistics].
As per claim 7, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches wherein the establishing the network tunnel network further comprises configuring the network tunnel with an internet protocol security (IPSec) framework [fig. 1; col. 4, lines 56-64 of Sivasankaran teaches wherein the establishing the network tunnel network further comprises configuring the network tunnel with an internet protocol security (IPSec) framework (e.g., the IPSec tunnel)].
As per claim 8, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches providing the received customer network information from the virtual router to one or more security systems, wherein the one or more security systems comprise at least one of management systems, network packet header information collection systems, or analytics systems [fig. 1; col. 3, lines 28-31; col. 4, lines 1-15 of Sivasankaran teaches providing the received customer network information from the virtual router to one or more security systems (e.g., the secure cloud interconnect firewall, etc.), wherein the one or more security systems comprise at least one of management systems, network packet header information collection systems, or analytics systems (e.g., the authorization, packet filtering, etc.)].
As per claim 9, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches providing a key for the network tunnel to the customer device, wherein the receiving the customer network information is based at least in part on providing the key [fig. 1; col. 3, lines 1-7 of Sivasankaran teaches providing a key (e.g., the login information) for the network tunnel to the customer device, wherein the receiving the customer network information (e.g., the customer routing policies) is based at least in part on providing the key (e.g., the login information)].
As per claim 10, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches wherein establishing the network tunnel further comprises determining a first internet protocol (IP) address for the network tunnel corresponding to the virtual router, determining a second IP address for the network tunnel corresponding to the CPE, and determining a third IP address for the network tunnel corresponding to the network tunnel [figs. 1, 4, 6; col. 2, lines 47-55; col. 3, lines 8-27; col. 4, lines 56-64; col. 7, lines 63-67; col. 8, lines 1-6; col. 10, lines 11-19, 31-45 of Sivasankaran teaches wherein establishing the network tunnel further comprises determining a first internet protocol (IP) address (e.g., the layer 3 technology/address) for the network tunnel corresponding to the virtual router, determining a second IP address (e.g., the CE router address) for the network tunnel corresponding to the CPE, and determining a third IP address (e.g., the layer 3 technology/address or the network configuration IP address) for the network tunnel corresponding to the network tunnel].
As per claim 11, Sivasankaran teaches the method of claim 1.
Sivasankaran further teaches configuring a first port to receive a first type of customer network information; configuring a second port to receive a second type of customer network information; and dropping received customer network information that is not configured to be received by a port [figs. 2, 6; col. 4, lines 1-15; col. 5, lines 20-62; col. 11, lines 65-67; col. 12, lines 1-10 of Sivasankaran teaches configuring a first port (e.g., port of the CE router or the provider edge router, etc.) to receive a first type of customer network information (e.g., the customer routing information); configuring a second port (e.g., port of the CE router or the provider edge router, etc. of the alternative routing path) to receive a second type of customer network information; and dropping received customer network information (e.g., the information for no routing path exist) that is not configured to be received by a port].
Claims 12-16 and 19 are method claims that correspond to the method claims 1-4 and 9, and are analyzed and rejected accordingly – (note: indicating allowed customer network information, disallowed customer network information, the allowed customer network information, etc. are indication of the fields 608, 610, 612, 614 of fig. 6. and revised customer criteria of fig. 7).
Claim 20 is a system claim that corresponds to the method claim 1, and is analyzed and rejected accordingly – see fig. 3 for the system components, a processor, a memory, etc.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sivasankaran (US 10,244,076 B2) in view of Gonzalez et al. (US 7,830,816 B1).
As per claim 17, Sivasankaran teaches the method of claim 16.
Although Sivasankaran teaches transmitting the query for the allowed customer information – see rejections above, Sivasankaran does not explicitly disclose, but Gonzalez teaches wherein the query comprises a simple network management protocol (SNMP) poll, wherein the allowed customer network information comprises SNMP information, and wherein receiving the allowed customer network information is based at least in part on the SNMP poll [col. 2, lines 28-46; col. 6, lines 12-21; col. 9, lines 9-18 of Gonzalez teaches wherein the query comprises a simple network management protocol (SNMP) poll, wherein the allowed customer network information (e.g., the operational parameters) comprises SNMP information, and wherein receiving the allowed customer network information is based at least in part on the SNMP poll].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivasankaran with the teaching of Gonzalez to include using a SNMP poll or message for a communication path of a service provider because it provides determining the interface status of the port initiated from a CPE - see column 2 of Gonzalez.
As per claim 18, Sivasankaran teaches the method of claim 12.
Sivasankaran further teaches wherein the configuration indication indicates disallowing queries to be provided from the provider site, and disallowing information to be provided from the CPE [figs. 6, 7; col. 9, lines 23-32; col. 11, lines 65-67; col. 12, lines 1-10 of Sivasankaran teaches wherein the configuration indication indicates disallowing queries (e.g., no routing path exists for the queries) to be provided from the provider site (e.g., from the cloud routing service system), and disallowing information (e.g., not allowing the customer routing policies) to be provided from the CPE (e.g., the CE router or the customer device)].
Although Sivasankaran teaches processing queries between the provider site and the CPE, Sivasankaran does not explicitly disclose, but Gonzalez teaches processing the simple network management protocol (SNMP) queries [col. 3, lines 48-50; col. 6, lines 3-7 of Gonzalez teaches processing the simple network management protocol (SNMP) queries].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sivasankaran with the teaching of Gonzalez to include using a SNMP protocol for a communication path of a service provider because it provides determining the interface status of the port initiated from a CPE - see column 2 of Gonzalez.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAUNG T LWIN whose telephone number is (571)270-7845. The examiner can normally be reached on Monday - Friday 10:00 am - 6:00 pm.
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, Farid Homayounmehr can be reached on 571-272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAUNG T LWIN/Primary Examiner, Art Unit 2495