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 .
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.
This office action is in response to the communication filed on 08/29/2024.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 8-13 are rejected under 35 U.S.C. 101 as not falling within one of the four statutory categories of invention. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because:
Claims 8-13 are drawn to “a boundary node” which can be read as a virtual node as in [0017], [0018], [0070] of the Specification. Thus, applying the broadest reasonable interpretation in light of the specification and taking into account the meaning of the words in their ordinary usage as they would be understood by one of ordinary skill in the art, the claims as a whole cover software per se, and are non-statutory under 35 USC § 101.
Claim Rejections - 35 USC § 102
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under AIA 35 U.S.C. 102(a)(1) as being anticipated by Allan et al. (US 2013/0195111, “Allan”).
As to claim 1, Allan discloses a method for providing a service redistribution policy for a multi-area network, the method comprising:
receiving, in a node of a first network in the multi-area network, a packet from a host for a service, wherein the packet has a destination in a second network in the multi-area network that is across one or more boundaries between the first network and the second network (fig. 1, [0033], a customer connecting to BEB-A in area L1-A communicates (for service) with a customer device connecting to BEB-B1 in area L1-B, L1-A and L1-B are linked by area L2. [0036], a boundary node including ABB-a1, ABB-a2, collectively as a virtual node BEB-L2 in between 2 network areas L1-A and L2 in fig. 2; [0035], ABB-a1 and ABB-a2 each sit on the boundary between routing area L1-A and L2. Accordingly, each of ABB-a1 and ABB-a2 can advertise the ability to reach destinations in routing areas L1-B and L2 within routing area L1-A, and advertise the ability to reach destinations in routing area L1-A within routing area L2);
identifying, in the node, a route from the first network to the second network in a routing table (fig. 2, [0048], [0054], BEB-L2 has a route for BEB-B1 and a route for BEB-B2, which was advertised from BEB-B1, BEB-B2 to ABB-b in L1-B, redistributed into L2 by ABB-b, and then redistributed into L1-A by ABB-a1 and ABB-a2 or BEB-L2);
assigning, in the node, the route to the service; and forwarding, from the first network to the second network, the service based on the route (fig. 1, 2, routes from BEB-A to BEB-B1 can be BEB-A to ABB-a1 (or ABB-a2 depending on which one is active, see [0059]) then to ABB-b, then to BEB-B1. Fig. 7-9, [0059], unidirectional route update at ABB 61 from B5 to B2 for service I10 for traffic from L2 to L1-A).
As to claim 8, Allan discloses a boundary node on a boundary between a first network and a second network in a multi-area network ([0036], a boundary node including ABB-a1, ABB-a2, collectively as a virtual node BEB-L2 in between 2 network areas L1-A and L2 in fig. 2), the boundary node configured to:
receive a packet from a host for a service, wherein the packet has a destination in the second network (fig. 1, [0033], a customer connecting to BEB-A in area L1-A communicates (for service) with a customer device connecting to BEB-B1 in area L1-B, L1-A and L1-B are linked by area L2. [0036], a boundary node including ABB-a1, ABB-a2, collectively as a virtual node BEB-L2 in between 2 network areas L1-A and L2 in fig. 2; [0035], ABB-a1 and ABB-a2 each sit on the boundary between routing area L1-A and L2. Accordingly, each of ABB-a1 and ABB-a2 can advertise the ability to reach destinations in routing areas L1-B and L2 within routing area L1-A, and advertise the ability to reach destinations in routing area L1-A within routing area L2);
identify a route from the first network to the second network in a routing table (fig. 2, [0048], [0054], BEB-L2 has a route for BEB-B1 and a route for BEB-B2, which was advertised from BEB-B1, BEB-B2 to ABB-b in L1-B, redistributed into L2 by ABB-b, and then redistributed into L1-A by ABB-a1 and ABB-a2 or BEB-L2);
assign the route to the service; and forward the packet to the destination in the second network based on the route (fig. 1, 2, routes from BEB-A to BEB-B1 can be BEB-A to ABB-a1 (or ABB-a2 depending on which one is active, see [0059]) then to ABB-b, then to BEB-B1. Fig. 7-9, [0059], unidirectional route update at ABB 61 from B5 to B2 for service I10 for traffic from L2 to L1-A).
As to claim 14, Allan discloses a non-transitory computer readable storage medium having computer readable code thereon, the non-transitory computer readable storage medium including instructions configured to cause a computer system to perform operations, comprising:
receiving a packet from a host for a service in a node of a first network in the multi-area network, wherein the packet has a destination in a second network in the multi-area network that is across one or more boundaries between the first network and the second network (fig. 1, [0033], a customer connecting to BEB-A in area L1-A communicates (for service) with a customer device connecting to BEB-B1 in area L1-B, L1-A and L1-B are linked by area L2. [0036], a boundary node including ABB-a1, ABB-a2, collectively as a virtual node BEB-L2 in between 2 network areas L1-A and L2 in fig. 2; [0035], ABB-a1 and ABB-a2 each sit on the boundary between routing area L1-A and L2. Accordingly, each of ABB-a1 and ABB-a2 can advertise the ability to reach destinations in routing areas L1-B and L2 within routing area L1-A, and advertise the ability to reach destinations in routing area L1-A within routing area L2);
identifying a route from the first network to the second network in a routing table (fig. 2, [0048], [0054], BEB-L2 has a route for BEB-B1 and a route for BEB-B2, which was advertised from BEB-B1, BEB-B2 to ABB-b in L1-B, redistributed into L2 by ABB-b, and then redistributed into L1-A by ABB-a1 and ABB-a2 or BEB-L2);
assigning the route to the service; and forwarding, from the first network to the second network, the service based on the route (fig. 1, 2, routes from BEB-A to BEB-B1 can be BEB-A to ABB-a1 (or ABB-a2 depending on which one is active, see [0059]) then to ABB-b, then to BEB-B1. Fig. 7-9, [0059], unidirectional route update at ABB 61 from B5 to B2 for service I10 for traffic from L2 to L1-A).
As to claim 2, Allan discloses configuring the service to be redistributable in a single direction from the first network across the one or more boundaries towards the second network ([0047], unidirectional route distribution across boundaries).
As to claim 3, Allan discloses: receiving, in the node, a different packet from a different host for the service, wherein the packet has a destination across the one or more boundaries from the second network to the first network; and discarding the packet at the node based on the service being redistributable in the single direction from the first network across the one or more boundaries towards the second network (fig. 6, [0041], unidirectional route redistribution at a boundary node bordering two areas, BEBB1 is a receiving-only service I10 (transmit indicator T=0, receive indicator R=1) which is leaked by ABB between L1-B and L2 using translation I10->B8 as route advertisement BEBB1, I10, T=0, R=1. This route advertisement only allows at ABB between L1-B and L2 packets/frames for service I10 on the downstream direction from L2 to L1-B and does not allow packets/frames on the upstream direction (because T=0, R=1), hence implicitly discarding such upstream packets when such upstream packets are received.)
As to claim 4, Allan discloses configuring the service to be redistributable in a first direction from the first network across the one or more boundaries towards the second network and in a second direction from the second network across the one or more boundaries towards the first network ([0035], bi-directional communication across ABB traversing 2 areas).
As to claim 5, Allan discloses:
receiving, at a boundary node on at least one of the one or more boundaries, the route from a control plane for the multi-area network, wherein the control plane generated the route based on the service ([0034], [0062]) being configured to be at least one of:
redistributable in a first direction from the first network across the one or more boundaries towards the second network and in a second direction from the second network across the one or more boundaries towards the first network; and redistributable in a direction from the first network across the one or more boundaries towards the second network; and installing the route in the routing table for the boundary node ([0035], bidirectional routing, [0047], unidirectional routing across network areas).
As to claim 6, Allan discloses configuring the boundary node as a virtual node ([0007], [0036], [0037], virtual node as boundary node).
As to claim 7, Allan discloses redistributing, from the node, the route from the first network across at least one of the one or more boundaries to a different boundary node in a different network; and updating a different routing table for the different boundary node by installing the route in the different routing table (fig. 3, [0054] –[0055], routes from L1-A from BEB as B5 and B2 are redistributed to L2 to be B8, fig. 4, L2 routes are redistributed into L1 by ABB-1 and ABB-2, and then redistributed into L1-B, also [0047], [0048], translation or routing table at boundary nodes).
Claims 9-13 are rejected for the same rationale in claims 2, 4-7 respectively.
Claims 15-20 are rejected for the same rationale in claims 2-7 respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is included in form PTO 892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HIEU T HOANG whose telephone number is (571) 270-1253. The examiner can normally be reached Mon-Fri 9 AM -5 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, Vivek Srivastava can be reached on 571-272-7304. 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.
/HIEU T HOANG/Primary Examiner, Art Unit 2449
Prosecution Insights