DETAILED ACTION
1. This action is responsive to the communications filed on 04/03/2026
2. Claims 1-20 are pending in this application.
3. Claims 1, 14, 20, have been amended.
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
4. Applicant’s argument with respect to claims 1-20 have been considered but are moot in view of the new grounds of rejection.
Although a new ground of rejection has been used to address additional limitations that have been added to claims 1-20, a response is considered necessary for several of applicant's arguments since references Murakami, Beck ‘886, and Beck ‘377 will continue to be used to meet several claimed limitations.
In the remarks, applicant argued that:
a. The Office Action further relies on para. [0060] of Murakami for "reducing priority," citing Murakami's disclosure of rewriting LOCAL_PREF so that routing information is not selected as the best path. However, the cited section of Murakami describes rewriting attributes (e.g., LOCAL_PREF) contained in BGP routing information in order to affect route selection, i.e., rewriting applied to received/processed BGP routing information participating in inbound/outbound processing or best-path selection. See paras. [0030], [0056], and [0060]. By contrast, Murakami does not teach rewriting LOCAL_PREF of the routing information in the IRR database, which is allegedly mapped to the "second BGP route." Thus, Murakami also fails to teach reducing the priority of a different second BGP route associated with the first route and from the same AS (Applicant’s remarks, page 7).
In response: The examiner respectfully disagrees.
In Murakami, there are multiple BPG routes. In particular, Murakami compares a received BGP route against stored BGP routing information in an IRR database. The examiner has equated the received BGP route as the first BGP route and the stored BGP routing information as the second BGP route. The IRR database stores pieces of BGP routing information which is registered into the database. These are previously registered routes/prefixes. When the first BGP route is received, it is checked against the database’s pieces of BGP routing information, which are Prefix, PrefixLength, and Origin AS number. As the database only has pieces of BGP routing path information, it is clear that it is different from the received BGP route. If the route is considered hijacked, the LOCAL_PREF contained in the BGP routing information is rewritten so that it is not selected as the best path, which is in essence, reducing the priority of that route.
b. Beck '377 fails to rectify the deficiencies of Murakami and Beck '886 discussed above with respect to claims 1, 14 and 20. Therefore, claims 1, 14 and 20 and their dependent claims, including claim 11 are patentable over the alleged combination of Murakami, Beck '886 and Beck '377. Accordingly, Applicants respectfully request that the rejection be withdrawn (Applicant’s remarks, page 8).
In response: The examiner respectfully disagrees.
The examiner has combined Murakami and Beck ‘886 with Beck ‘377. In particular, Beck ‘377 discloses that each autonomous system originates one or more prefixes that represent addresses assigned to hosts and devices within its network (Paragraph 26). The announcements include attestations which are signatures that assert the authenticity of prefix ownership. These attestations are verified using RPKI and if the signature is not verified, the route prefix is rejected (Paragraphs 28, 29, 50). Therefore, it is clear to the examiner that RPKI is used to validate BGP routes, and if they are not able to validate the signature attached to that route, it is rejected (i.e., unavailable). Beck ‘377 goes on to disclose that multiple BGP routes can be received and gives an example of a malicious route (i.e., first BGP route) and an example of a new route prefix (i.e., second BGP route).
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.
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. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Murakami (US 2011/0093612) in view of Beck (US 2019/0372886) and Beck (US 2021/0067377), hereinafter Beck ‘377.
Regarding claim 1, Murakami disclosed:
A route processing method, comprising:
determining, by a first network device (Figure 2, BGP router (RR) 10), that a first border gateway protocol (BGP) route (Paragraph 36, BGP information from BGP routers) is unavailable (Paragraph 28, invalid) (Paragraph 28, the BGP router 10 has a route reflector that collects BGP information from each of the BGP routers 20, 30, and 40 and reflects the BGP routing information in each of the routers by forming a BGP peer with each of the routers. RR 10 monitors the BGP routing information and rejects an invalid (i.e., unavailable) hijacked path. Paragraph 36, comparing the BGP routing information received from the BGP routers to the BGP routing information that is in the IRR database 105. Paragraph 47, when the RR 10 receives the Origin AS number (i.e., first route), it compares it to an Origin AS number in a database 105. If there is a match, it is considered an exact match (and valid), if there is not a match, the routing information is considered to be hijacked (and therefore, unavailable));
determining, by the first network device, a second BGP route (Paragraph 36, BGP information from IRR database) associated with the first BGP route (Paragraph 36, received BGP information from BGP routers. Paragraph 47, when the RR 10 receives the Origin AS number (i.e., first route), it compares it to an Origin AS number in a database 105 (i.e., second route)); and
reducing, by the first network device, a priority (Paragraph 60, best path selection) of the second BGP route (Paragraph 60, when checking the hijacked route whether a certain Prefix is needed, the RR 10 designates the Prefix and executes the Anti-Hijack process for the designated Prefix. Local attributes such as LOCAL_PREF, contained in the BGP routing information, can be rewritten so that the BGP routing information is received as routing information but is not selected as the best path (i.e., reducing priority)).
While Murakami disclosed routes associated with one another (see above), Murakami did not explicitly disclose wherein the first BGP route and the second BGP route are from a same autonomous system (AS).
However, in an analogous art, Beck disclosed wherein the first BGP route and the second BGP route are from a same autonomous system (AS) (Paragraph 25, Autonomous Systems, such as an ISP are assigned a range of IP addresses, such as netblocks. Paragraph 37, Internet traffic among routers 110, 111, 112, 113, 115 occur according to BGP routing information advertised by entities operating those routers. The entity operating router 110 is assigned netblock 24.158.32.0 so routers then update their routing tables to route Internet traffic to the same netblock to router 110 (i.e., multiple routes from the same AS)).
One of ordinary skill in the art would have been motivated to combine the teachings of Murakami with Beck because the references involve BGP routes, and as such, are within the same environment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the routes from the same AS of Beck with the teachings of Murakami in order to reduce the impact of BGP attacks (Beck, Paragraph 2).
While Murakami and Beck disclosed unavailable BGP routes (see above), Murakami and Beck did not explicitly disclose a first BGP route is unavailable by validating the first BGP route based on a resource public key infrastructure (RPKI) mechanism; and receiving, by the first network device, a second BGP route different from the first BGP route.
However, in an analogous art, Beck ‘377 disclosed that a first BGP route is unavailable by validating the first BGP route based on a resource public key infrastructure (RPKI) mechanism (Paragraph 26, each autonomous system (AS) originates one or more prefixes representing the addresses assigned to hosts and devices within its network and advertises those prefixes. Paragraph 28, attestations are digitally signed statements used to assert the authenticity of prefix ownership and advertised routes and claim the right to originate a prefix. This right to originate a prefix is validated. Paragraph 29, a route origin authorization (ROA) is an attestation of a BGP route announcement and attests that the origin AS number is authorized to announce the prefixes. Route attestations are signed by each AS as it traverses the network and the attestation is verified cryptographically using the resource public key infrastructure (RPKI). Paragraph 50, if the signature of the received prefix announcement is not a valid signature, the prefix is rejected (i.e., unavailable)); and
receiving, by the first network device, a second BGP route different from the first BGP route (Paragraph 42, announcing a malicious route (i.e., first BGP route). Paragraph 43, equating a prefix to a route. Paragraphs 46-48, having new prefix announcements (i.e., second BGP route) and validating the signed prefix announcement).
One of ordinary skill in the art would have been motivated to combine the teachings of Murakami and Beck with Beck ‘377 because the references involve BGP routes, and as such, are within the same environment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the RPKI of Beck ‘377 with the teachings of Murakami and Beck in order to improve BGP security (Beck ‘377, Paragraph 2).
Regarding claims 14, 20, the claims are substantially similar to claim 1. Claim 14 recites one or more processors and one or more memories (Murakami, Paragraphs 19, 21, processors and memory). Claim 20 recites a non-transitory computer readable storage medium (Murakami, Paragraph 19, computer readable medium). Therefore, the claims are rejected under the same rationale.
Regarding claims 2, 15, the limitations of claims 1, 14, have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
wherein a route prefix corresponding to the first BGP route belongs to a subnet of a route prefix corresponding to the second BGP route (Murakami, Paragraph 49, searching the Prefix length of 1.1.1.0/32 and 1.1.0.0/24), or the route prefix corresponding to the second BGP route belongs to a subnet of the route prefix corresponding to the first BGP route.
Regarding claims 3, 16, the limitations of claims 2, 15, have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
wherein after the priority of the second BGP route is reduced, the priority of the second BGP route is lower than a priority of a third BGP route, and the route prefix corresponding to the first BGP route belongs to a subnet of a route prefix corresponding to the third BGP route (Murakami, Paragraphs 52-53, the BGP routing information may be allowed to pass or priorities may be assigned to the actions of the states. By classifying the routing information into the eight states, appropriate filtering for all the possible paths is executed. Therefore, as there are multiple paths, each one can have a priority assigned or have its routing information selected but not selected as the best path. Paragraph 60, when checking the hijacked route whether a certain Prefix is needed, the RR 10 designates the Prefix and executes the Anti-Hijack process for the designated Prefix. Local attributes such as LOCAL_PREF, contained in the BGP routing information, can be rewritten so that the BGP routing information is received as routing information but is not selected as the best path (i.e., reducing priority)).
Regarding claims 4, 17, the limitations of claims 1, 14, have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
sending, by the first network device, a first notification message to a second network device, wherein the first notification message notifies the second network device to reduce a priority of a fourth BGP route, and the fourth BGP route and the first BGP route are from the same AS (Murakami, Paragraph 30, the RR 10 announces the BGP routing information to each BGP router. Paragraph 56, the filtering of the BGP routing information is announced to each of the BGP routers 20 (i.e., second network device), 30, 40. Paragraph 60, when checking the hijacked route whether a certain Prefix is needed, the RR 10 designates the Prefix and executes the Anti-Hijack process for the designated Prefix. Local attributes such as LOCAL_PREF, contained in the BGP routing information, can be rewritten so that the BGP routing information is received as routing information but is not selected as the best path (i.e., reducing priority)). Beck, Paragraph 37, Internet traffic among routers 110, 111, 112, 113, 115 occur according to BGP routing information advertised by entities operating those routers. The entity operating router 110 is assigned netblock 24.158.32.0 so routers then update their routing tables to route Internet traffic to the same netblock to router 110 (i.e., multiple routes from the same AS)).
For motivation, please refer to claim 1.
Regarding claims 5, 18, the limitations of claims 1, 14, have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
sending, by the first network device, a second notification message to a third network device, wherein the third network device is configured to send a third notification message to at least a fourth network device based on the second notification message, the third notification message notifies the fourth network device to reduce a priority of a fifth BGP route, and the fifth BGP route and the first BGP route are from the same AS (Murakami, Paragraph 30, the RR 10 announces the BGP routing information to each BGP router. Each BGP router exchanges BGP routing information (i.e., notification) between them. Paragraph 56, the filtering of the BGP routing information is announced to each of the BGP routers 20, 30 (i.e., third network device), 40. Paragraph 60, when checking the hijacked route whether a certain Prefix is needed, the RR 10 designates the Prefix and executes the Anti-Hijack process for the designated Prefix. Local attributes such as LOCAL_PREF, contained in the BGP routing information, can be rewritten so that the BGP routing information is received as routing information but is not selected as the best path (i.e., reducing priority). Beck, Paragraph 37, Internet traffic among routers 110, 111, 112, 113, 115 occur according to BGP routing information advertised by entities operating those routers. The entity operating router 110 is assigned netblock 24.158.32.0 so routers then update their routing tables to route Internet traffic to the same netblock to router 110 (i.e., multiple routes from the same AS)).
For motivation, please refer to claim 1.
Regarding claims 6, 19, the limitations of claims 1, 14 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
sending, by the first network device, a fourth notification message to a fifth network device, wherein the fourth notification message notifies the fifth network device that the first BGP route is unavailable (Murakami, Paragraph 30, the RR 10 announces the BGP routing information to each BGP router. Paragraph 47, when the RR 10 receives the Origin AS number (i.e., first route), it compares it to an Origin AS number in a database 105. If there is a match, it is considered an exact match (and valid), if there is not a match, the routing information is considered to be hijacked (and therefore, unavailable)). Paragraph 56, the filtering of the BGP routing information is announced to each of the BGP routers 20, 30, 40 (i.e., fifth network device). Paragraph 60, when checking the hijacked route whether a certain Prefix is needed, the RR 10 designates the Prefix and executes the Anti-Hijack process for the designated Prefix. Local attributes such as LOCAL_PREF, contained in the BGP routing information, can be rewritten so that the BGP routing information is received as routing information but is not selected as the best path (i.e., reducing priority)).
Regarding claim 7, the limitations of claim 3 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
sending, by the first network device, a fifth notification message to a sixth network device (Beck, Paragraph 62, showing 11 BGP routers), wherein the fifth notification message notifies the sixth network device that the third BGP route is available (Murakami, Paragraph 30, the RR 10 announces the BGP routing information to each BGP router. Paragraph 47, when the RR 10 receives the Origin AS number (i.e., first route), it compares it to an Origin AS number in a database 105. If there is a match, it is considered an exact match (and valid) (i.e., available), if there is not a match, the routing information is considered to be hijacked (and therefore, unavailable)). Paragraph 56, the filtering of the BGP routing information is announced to each of the BGP routers 20, 30, 40).
For motivation, please refer to claim 1.
Regarding claim 8, the limitations of claim 1 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
setting, by the first network device, the second BGP route as a risky route in a route table (Murakami, Paragraph 52, if the BGP route is considered Multiple Origin, Punching Hole, Hijacking, or Miss Config, the path is held to be registered in the routing information database 102).
Regarding claim 9, the limitations of claim 1 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
wherein the determining, by the first network device, a second BGP route associated with the first BGP route comprises: determining, by the first network device based on a BGP peer relationship, the second BGP route associated with the first BGP route, wherein the first BGP route and the second BGP route are from a same BGP peer (Murakami, Paragraph 27, each BGP router forms a BGP peer through a session of external BGP with a BGP router in the external AS and exchanges BGP routing information with the external AS. Paragraph 28, the RR 10 forms a BGP peer with each of the BGP routers. Paragraph 47, when the RR 10 receives the Origin AS number (i.e., first route), it compares it to an Origin AS number in a database 105 (i.e., second route) and both involve the same BGP peers).
Regarding claim 10, the limitations of claim 1 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
wherein the determining, by the first network device, a second BGP route associated with the first BGP route comprises: determining, by the first network device based on a next hop, the second BGP route associated with the first BGP route, wherein a next hop corresponding to the first BGP route is the same as a next hop corresponding to the second BGP route (Murakami, Paragraph 27, each BGP router forms a BGP peer through a session of external BGP with a BGP router in the external AS and exchanges BGP routing information with the external AS. Paragraph 28, the RR 10 forms a BGP peer with each of the BGP routers. Paragraph 47, when the RR 10 receives the Origin AS number (i.e., first route), it compares it to an Origin AS number in a database 105 (i.e., second route) and both involve the same BGP peers. Beck, Paragraph 26, the path length refers to a number of hops through which the packet travels to reach the AS to which the packet is addressed. Paragraph 57, detailing the number of hops for the path to reach a certain ASN).
For motivation, please refer to claim 1.
Regarding claim 11, the limitations of claim 1 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
wherein the determining, by a first network device, that a first BGP route is unavailable comprises: determining, by the first network device based on a route origin authorization (ROA) entry corresponding to the first BGP route, that the first BGP route is unavailable, wherein the ROA entry comprises information about an available BGP route (Beck ‘377, Paragraphs 28-29, attestations are digitally signed statements used to assert the authenticity of prefix ownership and advertised routes (i.e., available route). A ROA is an attestation of a BGP route announcement. The ROA attests that the origin AS is authorized to announce the prefixes). Paragraph 50, if the signature is not a valid signature, the prefix announcement is rejected (i.e., unavailable)).
For motivation, please refer to claim 1.
Regarding claim 12, the limitations of claim 3 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
wherein costs of the third BGP route are higher than costs of the second BGP route (Beck, Paragraph 31, determining a security cost for each path based on the path’s security attributes. A determined security cost is added to the path length. Paragraph 57, assigning the costs to the paths such as Path A through ASN2 having a security cost of 0.5 while going through ASN1 the security cost is 1).
For motivation, please refer to claim 1.
Regarding claim 13, the limitations of claim 1 have been addressed. Murakami, Beck, and Beck ‘377 disclosed:
recording, by the first network device, a status of the first BGP route by using at least one of a log (Murakami, Paragraph 62, register a log indicating a state of the BGP routing information), a TRAP, an alarm, and/or a BGP monitoring protocol.
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 Steven C. Nguyen whose telephone number is (571)270-5663. The examiner can normally be reached M-F 7AM - 3PM and alternatively, through e-mail at Steven.Nguyen2@USPTO.gov.
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, Christopher Parry can be reached at 571-272-8328. 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.
/S.C.N/Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights