Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
2. This Office Action is in response to application filed on 09/20/2023. Claims 1-20 were previously pending. Claims 1-20 are rejected.
Information Disclosure Statement
3. The information disclosure statement(s) (IDS) submitted on 09/20/2023 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Double Patenting
4. 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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
4.1. Claims 1-20 of instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent 11,290,332. B2. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants of each.
18345382
16932593
US 11290332
1.
A method comprising:
identifying a hierarchy for a computing network comprising a plurality of devices;
building a topology graph comprising a plurality of nodes pairwise connected by a plurality of edges, wherein each node represents one of the plurality of devices in the computing network, and wherein each of the edges represents a link;
completing network topology visibility;
allocating and tracking an IP address for each of the plurality of devices;
building the computing network; and
generating a configuration for the computing network.
1. A method comprising:
accessing by a network deployment system model information for a computing network comprising a plurality of layers of linked devices, the model information specifying a network topology for the computing network, a plurality of components of the computing network, and information identifying hierarchical relationships between one or more components from the plurality of components; and
setting up the computing network by the network deployment system based upon the model information, wherein setting up the computing network comprises:
creating a topology database, wherein creating the topology database comprises:
creating switches at each layer in the computing network;
mapping links connecting the switches, wherein each link connects a pair of switches;
creating Border Gateway Protocol (“BGP”) routing for both an underlay network and an overlay network;
creating a topology graph of the computing network, wherein the topology graph `comprises a plurality of nodes, each of the plurality of nodes representing one of the devices in the computing network, and wherein the nodes are connected by edges each of the representing one link;
generating Zero Touch Provisioning (“ZTP”) links; and
building the computing network based on the topology database.
19.
A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to:
identify a hierarchy for a computing network comprising a plurality of devices;
build a topology graph comprising a plurality of nodes pairwise connected by a plurality of edges, wherein each node represents one of the plurality of devices in the computing network, and wherein each of the edges represents a link;
complete network topology visibility;
allocate and track an IP address for each of the plurality of devices;
build the computing network; and
generate a configuration for the computing network.
16. A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to:
access model information for a computing network comprising a plurality of layers of linked devices, the model information specifying a network topology for the computing network, a plurality of components of the computing network, and information identifying hierarchical relationships between one or more components from the plurality of components; and
set up the computing network based upon the model information, wherein setting up the computing network comprises:
creating a topology database, wherein creating the topology database comprises:
creating switches at each layer in the computing network;
mapping links connecting the switches, wherein each link connects a pair of switches;
creating Border Gateway Protocol (“BGP”) routing for both an underlay network and an overlay network; creating a topology graph of the computing network, wherein the topology graph comprises a plurality of nodes, each of the plurality of nodes representing one of the devices in the computing network, and wherein the nodes are connected by edges, each of the edges representing one link;
generating Zero Touch Provisioning (“ZTP”) links; and
building the computing network based on the topology database.
Claim Rejections - 35 USC § 103
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
5.1. 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.
5.2. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
5.3. Claims 1-7, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable Poduri et al., ("Poduri", US 2018/0082449 A1) in view of Cohn et al., ("Cohn", US 2018/0234298 A1).
Regarding Claim 1, Poduri teaches, a method comprising:
identifying a hierarchy for a computing network comprising a plurality of devices (Poduri, [00167]: identifying a database server is on the “top level” of a hierarchy illustrated by the topology graph. The web server is on the “second level.” The applications is on the “third level.” Any number of levels may be included in a hierarchy described by a topology graph);
building a topology graph comprising a plurality of nodes pairwise connected by a plurality of edges, wherein each node represents one of the plurality of devices in the computing network, and wherein each of the edges represents a link (Poduri, [0167-69]: generating a set of insights (topology graph), The topology graph may illustrate the web server connected to each of the applications. In this example, the database server is “directly connected” with the web server);
completing network topology visibility (Poduri, [0167]: A visualization for the insight may be a topology graph);
building the computing network (Poduri, [0167-168]: a topology graph describes an overall architecture, hierarchy, arrangement, setting, and/or usage of nodes of a computer system. The topology graph may show that one node is “connected to” another node, indicating that the two nodes have a relationship with each other).
allocating and tracking an IP address for each of the plurality of devices;
generating a configuration for the computing network.
Cohn teaches,
allocating and tracking an IP address for each of the plurality of devices (Cohn, [0060, 87]: the addresses may be dynamically assigned (by a Dynamic Host Configuration Protocol (DHCP));
generating a configuration for the computing network (Cohn, FIG.2, virtual topology 200, [0078], FIG.3, physical topology 300, [0082], FIG.4B, virtual topology 404, [0099]: instantiated virtual topology 404. The instantiated virtual topology 404 is based on the virtual topology 200 and the physical topology 300).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “network requirement” of Cohn into the invention of Poduri. The suggestion/motivation would have been to implement enabling satisfying network requirements to improve processing speed (Cohn, FIG.6). Including the “network requirement” of Cohn into the invention of Poduri was within the ordinary ability of one of ordinary skill in the art based on the teachings of Poduri.
Regarding Claim 2, Poduri-Cohn teaches, the method of claim 1, wherein the hierarchy for the computing network identifying a relative position of devices within the computing network (Poduri, [0093, 167]: A visualization for the topology graph may illustrate the Sales Application as well as other nodes directly and/or indirectly connected to the Sales Application).
Regarding Claim 3, Poduri-Cohn teaches, the method of claim 1, wherein identifying the hierarchy for the computing network can include iterative determining of a position of a device within the computing network (Poduri, [0093, 167]: The topology graph may illustrate the Sales Application as well as other nodes directly and/or indirectly connected to the Sales Application. The Sales Application node, in the topology graph, may be labeled with “75%.” Additionally, the percentage of communications, using another node in the topology graph, that are above an average error count may be determined. The other node in the topology graph may be labeled with the determined percentage.)
Regarding Claim 4, Poduri-Cohn teaches, the method of claim 1, wherein the topology graph is built for at least one underly level and at least one overlay level of the computing network (Cohn, [0087, 214]: The overlay network is implemented on top of an underlay network corresponding to the physical topology).
Regarding Claim 5, Poduri-Cohn teaches, the method of claim 4, wherein the topology graph includes IP fabric and racks (Cohn, FIG.4B, [0099]: The instantiated virtual topology 404 is based on the virtual topology 200 and the physical topology 300).
Regarding Claim 6, Poduri-Cohn teaches, the method of claim 4, wherein building the topology graph comprises modeling an entire fabric topology of the computing network in a fabric definitions file (Cohn, FIG.1, virtual topology 104, virtual topology specification 105, physical topology 106, [0063]: a virtual topology specification 105 is a description of a virtual topology 104. The virtual topology specification 105 may include any reference to a physical topology 106 and/or digital devices therein)
Regarding Claim 7, Poduri-Cohn teaches, the method of claim 6, wherein the fabric definitions file identifies locations for specification of at least one of: topology; number of spine devices; number of fabric devices; or number of leaf devices (Cohn, [0063]: The description of the particular arrangement of virtual topology elements (VTEs) may be provided in graphic form 112).
Regarding Claim 17, Poduri-Cohn teaches, the method of claim 1, further comprising building communication routes within the computing network (Cohn, FIG.2, virtual topology 200, [0103]: building the communication path indicated in the virtual topology 200).
Regarding Claim 18, Poduri-Cohn teaches, the method of claim 1, further comprising deploying the computing network (Cohn, [0099]: to instantiate the same virtual topology on a physical topology).
Regarding Claim 19, Poduri teaches, a non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to (Poduri, FIG.6, processor 604, memory 606, [0195]: Such instructions, when stored in non-transitory storage media accessible to processor 604, render computer system into a special-purpose machine that is customized to perform the operations specified in the instructions):
identify a hierarchy for a computing network comprising a plurality of devices (Poduri, [00167]: identifying a database server is on the “top level” of a hierarchy illustrated by the topology graph. The web server is on the “second level.” The applications is on the “third level.” Any number of levels may be included in a hierarchy described by a topology graph);
build a topology graph comprising a plurality of nodes pairwise connected by a plurality of edges, wherein each node represents one of the plurality of devices in the computing network, and wherein each of the edges represents a link (Poduri, [0167-69]: generating a set of insights (topology graph), The topology graph may illustrate the web server connected to each of the applications. In this example, the database server is “directly connected” with the web server);
complete network topology visibility (Poduri, [0167]: A visualization for the insight may be a topology graph);
build the computing network (Poduri, [0167-168]: a topology graph describes an overall architecture, hierarchy, arrangement, setting, and/or usage of nodes of a computer system. The topology graph may show that one node is “connected to” another node, indicating that the two nodes have a relationship with each other).
Poduri does not expressly teach,
allocate and track an IP address for each of the plurality of devices;
generate a configuration for the computing network.
Cohn teaches,
allocate and track an IP address for each of the plurality of devices ((Cohn, [0060, 87]: the addresses may be dynamically assigned (by a Dynamic Host Configuration Protocol (DHCP));
generate a configuration for the computing network (Cohn, FIG.2, virtual topology 200, [0078], FIG.3, physical topology 300, [0082], FIG.4B, virtual topology 404, [0099]: instantiated virtual topology 404. The instantiated virtual topology 404 is based on the virtual topology 200 and the physical topology 300).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “network requirement” of Cohn into the invention of Poduri. The suggestion/motivation would have been to implement enabling satisfying network requirements to improve processing speed (Cohn, FIG.6). Including the “network requirement” of Cohn into the invention of Poduri was within the ordinary ability of one of ordinary skill in the art based on the teachings of Poduri.
Regarding Claim 20, Poduri teaches, a system comprising:
a memory comprising a configuration database; and a processor configured to (Poduri, FIG.6, processor 604, memory 606, [0195]: Such instructions, when stored in non-transitory storage media accessible to processor 604, render computer system into a special-purpose machine that is customized to perform the operations specified in the instruction):
identify a hierarchy for a computing network comprising a plurality of devices (Poduri, [00167]: identifying a database server is on the “top level” of a hierarchy illustrated by the topology graph. The web server is on the “second level.” The applications is on the “third level.” Any number of levels may be included in a hierarchy described by a topology graph);
build a topology graph comprising a plurality of nodes pairwise connected by a plurality of edges, wherein each node represents one of the plurality of devices in the computing network, and wherein each of the edges represents a link (Poduri, [0167-69]: generating a set of insights (topology graph), The topology graph may illustrate the web server connected to each of the applications. In this example, the database server is “directly connected” with the web server);
complete network topology visibility (Poduri, [0167]: A visualization for the insight may be a topology graph);
build the computing network (Poduri, [0167-168]: a topology graph describes an overall architecture, hierarchy, arrangement, setting, and/or usage of nodes of a computer system. The topology graph may show that one node is “connected to” another node, indicating that the two nodes have a relationship with each other).
Poduri does not expressly teach,
allocate and track an IP address for each of the plurality of devices;
generate a configuration for the computing network.
Cohn teaches,
allocate and track an IP address for each of the plurality of devices (Cohn, FIG.4B, virtual topology 404, [0099]: instantiated virtual topology 404. The instantiated virtual topology 404 is based on the virtual topology 200 (illustrated in FIG. 2) and the physical topology 300 (illustrated in FIG. 3)). );
generate a configuration for the computing network (Cohn, FIG.2, virtual topology 200, [0078], FIG.3, physical topology 300, [0082], FIG.4B, virtual topology 404, [0099]: instantiated virtual topology 404. The instantiated virtual topology 404 is based on the virtual topology 200 and the physical topology 300).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “network requirement” of Cohn into the invention of Poduri. The suggestion/motivation would have been to implement enabling satisfying network requirements to improve processing speed (Cohn, FIG.6). Including the “network requirement” of Cohn into the invention of Poduri was within the ordinary ability of one of ordinary skill in the art based on the teachings of Poduri.
5.4. Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable Poduri et al., ("Poduri", US 2018/0082449 A1) in view of Cohn et al., ("Cohn", US 2018/0234298 A1), and further in view of Barry et al., ("Barry", US 2018/0167307 A1).
Regarding Claim 8, Poduri-Cohn teaches, the method of claim 4, but not expressly teaches, wherein building the topology graph comprises:
validating the topology;
creating a node corresponding to each switch in the computing network (Cohn, [0087]);
placing nodes corresponding to transit routers (TR) at the top of the topology graph;
organizing the remaining nodes according to the hierarchy of the computing network and according to the links between devices in the computing network.
Barry teaches,
validating the topology (Barry, [1557-1565]: validates fabric graph has roles source, transit, or root, depending. Each fabric graph in the list must assign a consistent role to each node.);
creating a node corresponding to each switch in the computing network (Barry, FIG.14, [0106]: assigning the role to the switch node, such as, source, transit or root);
placing nodes corresponding to transit routers (TR) at the top of the topology graph (Barry, FIG.6B, Node-4 600d, Node-8 600h, [0084]: Node-8 600h is the root and Node-4 600d is a transit node);
organizing the remaining nodes according to the hierarchy of the computing network and according to the links between devices in the computing network (Barry, FIG.6B, Node-1 600a, Node-3 600c, Node-6 600f , [0084]: Nodes may have multiple roles, for example, Node-6 600f is also a transit node for those flows coming from Node-1 600a and Node-3 600c).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “switch topology” of Barry into the invention of Poduri-Cohn. The suggestion/motivation would have been to implement “switch topology” to enable providing respective nodes to include multicast/broadcast capable circuit switches in addition to packet switches for increasing functionality of the optical nodes and the network (Barry, [0009]). Including the “xx” of Barry into the invention of Poduri-Cohn was within the ordinary ability of one of ordinary skill in the art based on the teachings of Barry.
Regarding Claim 9, Poduri-Cohn-Barry teaches, the method of claim 8, further comprising generating the edges representing the links between devices in the computing network (Poduri, [0167]: a topology graph describes an overall architecture, hierarchy, arrangement, setting, and/or usage of nodes of a computer system. The topology graph may show that one node is “connected to” (“link”) another node, indicating that the two nodes have a relationship with each other).
Regarding Claim 10, Poduri-Cohn-Barry teaches, the method of claim 9, further comprising ingesting the graph into a visualization tool, wherein the visualization tool generates the topology graph (Poduri,[0093]: A visualization for the insight may be a topology graph).
5.5. Claims 11-14 are rejected under 35 U.S.C. 103 as being unpatentable Poduri et al., ("Poduri", US 2018/0082449 A1) in view of Cohn et al., ("Cohn", US 2018/0234298 A1), and further in view of Kasperson et al., ("Kasperson", US 2021/0021505 A1).
Regarding Claim 11, Poduri-Cohn teaches, the method of claim 1, but not expressly teaches, further comprising assigning a global device name to each of the devices in the computing network.
Kasperson teaches, (Kasperson, [0011]: an unique identifier which may include a vendor ID combined with a serial number (“global unique ID”) is assigned to a network cable).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “global device name” of Kasperson into the invention of Poduri-Cohn. The suggestion/motivation would have been to implement “globally unique identifier” to provide certain identifying information when interrogated by a connected device (Kasperson, [0011]). Including the “global device name” of Kasperson into the invention of Poduri-Cohn was within the ordinary ability of one of ordinary skill in the art based on the teachings of Kasperson.
Regarding Claim 12, Poduri-Cohn teaches, the method of claim 1, but not expressly teaches, wherein completing network topology visibility comprises generating a physical cable map.
Kasperson teaches (Kasperson, [0011]: the “network topology” includes, the number and capacity of lanes provided by the cables, as well as the physical layer ports to which lanes of each cable are assigned).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “physical cable map” of Kasperson into the invention of Poduri-Cohn. The suggestion/motivation would have been to implement “physical cable map” to ensure the appropriate hardware is activated in the port and that the appropriate settings and parameters are provided to cause the hardware to operate according to the given protocol at the desired data transfer rate (Kasperson, [0011-12]). Including the “physical cable map” of Kasperson into the invention of Poduri-Cohn was within the ordinary ability of one of ordinary skill in the art based on the teachings of Kasperson.
Regarding Claim 13, Poduri-Cohn-Kasperson teaches, the method of claim 12, wherein the physical cable map identifies links between the plurality of devices in the computing network, wherein each link connects a pair of devices in the computing network (Kasperson, [0011]: The unique identifier of the network cable may be used to determine how many lanes are available between the two endpoints of a cable).
Regarding Claim 14, Poduri-Cohn-Kasperson teaches, the method of claim 12, wherein generating the physical cable map comprises identifying links between devices in the computing network (Kasperson, [0011]: The unique identifier of the network cable may be used to determine how many lanes are available between the two endpoints of a cable)).
5.6. Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable Poduri et al., ("Poduri", US 2018/0082449 A1) in view of Cohn et al., ("Cohn", US 2018/0234298 A1) and Kasperson et al., ("Kasperson", US 2021/0021505 A1), and further in view of Barry et al., ("Barry", US 2018/0167307 A1) and Gafni, US 2021/0367850 A1.
Regarding Claim 15, Poduri-Cohn-Kasperson teaches, the method of claim 14, but not expressly teaches, wherein identifying links between devices in the computing network comprises:
identifying transit router (TR) to fabric links;
identifying links from spine switches to fabric switches;
identifying links from fabric switches to leaf switches; and
identifying links between leaf switches.
Barry teaches,
identifying transit router (TR) to fabric links (Barry, FIG.6A, FIG.6A, nodes 600a-600h, [0073]: Node-6 600f and Node-8 600h (“root”) includes the link from Node-6 600f to Node-8 600h, the l6,8 link, and the link from Node-8 600h to Node-6 600f, the l8,6 link);
identifying links from fabric switches to leaf switches (Barry, FIG.6A, [0073]: Node-5 600e and Node-2 600b (“leaf”) includes the link from Node-5 600e to Node-2 600b, the l5,2 link, and the link from Node-2 600b to Node-5 600e, the l2,5 link); and
identifying links between leaf switches (Barry, FIG.6A, nodes 600a-600h, [0073]: Node-1 600a (“leaf”) and Node-2 600b (“leaf”) includes the link from Node-1 600a to Node-2 600b, the l1,2 link, and the link from Node-2 600b to Node-1 600a, the l2,1 link).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “switch topology” of Barry into the invention of Poduri-Cohn. The suggestion/motivation would have been to implement “switch topology” to enable providing respective nodes to include multicast/broadcast capable circuit switches in addition to packet switches for increasing functionality of the optical nodes and the network (Barry, [0009]). Including the “xx” of Barry into the invention of Poduri-Cohn was within the ordinary ability of one of ordinary skill in the art based on the teachings of Barry.
Poduri-Cohn-Kasperson-Barry does not expressly teach,
identifying links from spine switches to fabric switches
Gafni teaches (Gafni, FIG.1, leaf switch device 20, spine switch devices 22, ports 26, [0052]: Each spine switch device 22 has six ports 26 connected to respective ones of the leaf switch devices 20).
Prior to the effective filing date of invention, it would have been obvious to a person of ordinary skill in the art to implement the “spine switch” of Gafni into the invention of Poduri-Cohn-Kasperson-Barry. The suggestion/motivation would have been to implement a numbers of “spine switches” and links at each level are chosen so as to provide sufficient bandwidth between the spine switches to enable multiple computing nodes (Gafni, FIG.1). Including the “spine switch” of Gafni into the invention of Poduri-Cohn-Kasperson-Barry was within the ordinary ability of one of ordinary skill in the art based on the teachings of Gafni.
Regarding Claim 16, Poduri-Cohn-Kasperson-Barry-Gafni teaches, the method of claim 15, wherein allocating and tracking an IP address for each of the plurality of devices comprises:
creating at least one IP table in an IP database (It is obvious to a person of ordinary that an IP database is created for the addresses already assigned by a DHCP);
allocating an IP address to each of the plurality of devices (Cohn, [0060, 87]: the addresses may be dynamically assigned DHCP);
allocating IP addresses to links (Cohn, [0060, 87]: the addresses may be dynamically assigned DHCP); and
updating the IP table to include the allocated IP addresses (It is obvious to a person of ordinary that updating the IP table for already adding IP address).
Conclusion
6. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Klessig US 2009/0122718 A1, Internet protocol subnet assigning method for metro ethernet network, involves receiving information identifying virtual connections, and assigning internet subnet to virtual connection based on global topology of network.
7. Any inquiry concerning this communication or earlier communications from the examiner should
be directed to CHHIAN (AMY) LING whose telephone number is (571)270-1074. The examiner can
normally be reached M-F 9-6 ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a
USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use
the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor,
BRIAN J GILLIS can be reached on (571) 272-7952. 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.
/C.L/Examiner, Art Unit 2446
/BRIAN J. GILLIS/Supervisory Patent Examiner, Art Unit 2446