DETAILED ACTION
This action is in response to the application filed on 8 February 2024.
Claims 1-20 are under examination.
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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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 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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 11-15, and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Yong et al. (US 2014/0086253 A1) in view of RFC 4271 (https://datatracker.ietf.org/doc/html/rfc4271).
Regarding claim 1, Yong discloses a method for processing a border gateway protocol (BGP) message, as evidenced by:
“the control plane functions… may be realized by leveraging… BGP…” (Yong, ¶[0057]).
Yong further discloses obtaining a BGP message, as evidenced by handling BGP Update messages (Yong, ¶[0065]).
Yong further discloses wherein the BGP message comprises first network layer reachability information (NLRI) used for advertising a first route, as evidenced by:
“BGP Update message… may be used to send routing updates… advertising feasible routes” (Yong, ¶[0065]).
Yong further discloses wherein the first NLRI comprises a first field set, as evidenced by NLRI including routing information fields defining the route (Yong, ¶[0065]).
Yong further discloses the first field set carries necessary routing information of the first route, as evidenced by NLRI fields including route-identifying information such as address family and next-hop information (Yong, ¶[0065]).
Yong further discloses each field in a second field set carries optional routing information of the first route, as evidenced by:
“optional transitive tunnel encapsulation attribute TLV…” (Yong, ¶[0065]).
Yong does not disclose the first NLRI comprises first indication information.
Yong does not disclose the first indication information indicates that the first NLRI does not comprise a first field in the second field set.
Yong does not specifically disclose the second field set does not comprise the first indication information.
RFC 4271 discloses indication information (flags) associated with attributes in a BGP message, as evidenced by:
“Each path attribute is a triple <attribute type, attribute length, attribute value>. The attribute flags octet is structured as follows…” (RFC 4271, Section 4.3),
and
“The high-order bit (bit 0) of the Attribute Flags octet defines whether the attribute is optional (if set to 1) or well-known (if set to 0)” (RFC 4271, Section 4.3).
RFC 4271 further discloses that optional attributes are included only when present, and their presence is indicated by the attribute flags and encoding within the message (Section 4.3).
Thus, it would have been obvious to one of ordinary skill in the art to include first indication information indicating that the NLRI does not comprise a field in the second field set, and to structure the second field set such that it does not include the first indication information, since RFC 4271 teaches using flags to indicate whether optional information is present, and it would have been a predictable design choice that absence of a field is indicated when the corresponding flag is not set, thereby enabling efficient parsing and flexible encoding of BGP messages.
Yong further discloses sending the BGP message to a second communication apparatus, as evidenced by:
“BGP Update message… may be used to send routing updates to BGP peers” (Yong, ¶[0065]).
Regarding claim 2, Yong further discloses the first indication information comprises a plurality of bits, as evidenced by structured encoding of routing information and attributes (Yong, ¶[0065]). RFC 4271 further discloses the first indication information indicates, in a bit mapping manner, that the first NLRI does not comprise the first field, as evidenced by: “The attribute flags octet is structured as follows…” and “The high-order bit (bit 0)… defines whether the attribute is optional…” (RFC 4271, Section 4.3). RFC 4271 further supports the first indication information indicates, in an enumeration manner, that the first NLRI does not comprise the first field, since attributes are identified by type and their presence is determined by inclusion in the message. Thus, it would have been obvious to implement indication information using bits or enumeration.
Regarding claim 3, Yong further discloses the BGP message comprises a plurality of pieces of NLRI, the plurality of pieces of NLRI are used for advertising a plurality of routes, and the BGP message comprises a common information field and a plurality of dedicated information fields corresponding to the plurality of pieces of NLRI respectively, as evidenced by BGP Update messages carrying multiple NLRI entries and associated attributes (Yong, ¶[0065]). Thus, organizing routing information into shared and dedicated portions would have been an obvious data structuring technique.
Regarding claim 4, Yong further discloses the BGP message comprises third NLRI, wherein the third NLRI comprises the common information field and the dedicated information fields, and the third NLRI comprises a plurality of pieces of sub-NLRI, each piece of sub-NLRI corresponding to one of the plurality of pieces of NLRI, as evidenced by hierarchical and structured NLRI encoding within BGP Update messages (Yong, ¶[0065]). Thus, grouping NLRI into hierarchical structures would have been obvious.
Regarding claim 11, Yong further discloses the first indication information further indicates that the first NLRI comprises a second field in the second field set, as an extension of indicating presence or absence of optional routing information (Yong, ¶[0065]). RFC 4271 supports this with flag-based indication, as evidenced by: “The attribute flags octet is structured as follows…” (RFC 4271, Section 4.3). Thus, it would have been obvious to indicate both presence and absence.
Regarding claim 12, Yong further discloses parsing the BGP message to obtain the first field set and the first indication information, as evidenced by processing BGP Update messages and extracting routing information (Yong, ¶[0065]). Yong further discloses obtaining the first route when the first indication information indicates that the first NLRI does not comprise the second field set, or obtaining the first route when the first indication information indicates that the first NLRI comprises the second field set, as inherent in interpreting routing information based on included or omitted attributes. RFC 4271 supports interpretation based on presence or absence of attributes.
Regarding claim 13, Yong further discloses the first indication information comprises a plurality of bits, the first indication information indicates, in a bit mapping manner or an enumeration manner, that the first NLRI does not comprise the first field, as evidenced by structured attribute encoding (Yong, ¶[0065]). RFC 4271 explicitly discloses bit-based flags, as evidenced by: “Each path attribute is a triple… The attribute flags octet…” (RFC 4271, Section 4.3). Thus, it would have been obvious to use bit mapping or enumeration.
Regarding claim 14, Yong further discloses the BGP message comprises a plurality of pieces of NLRI, the plurality of pieces of NLRI are used for advertising a plurality of routes, and the BGP message comprises a common information field and a plurality of dedicated information fields corresponding to the plurality of pieces of NLRI respectively, as discussed above for claim 3.
Regarding claim 15, Yong further discloses the BGP message comprises third NLRI, wherein the third NLRI comprises the common information field and the dedicated information fields, and the third NLRI comprises a plurality of pieces of sub-NLRI, each piece of sub-NLRI corresponding to one of the plurality of pieces of NLRI, as discussed above for claim 4.
Regarding claim 20, Yong further discloses an apparatus, comprising a processor and a memory storing instructions that, when executed by the processor, cause the processor to perform the method according to claim 2, including the first indication information comprising a plurality of bits and indicating in a bit mapping or enumeration manner, as evidenced by BGP processing functionality (Yong, ¶[0057], ¶[0065]). RFC 4271 supports bit-based indication as discussed above.
Claims 5-9 and 16-18 are rejected under 35 U.S.C. § 103 as being unpatentable over Yong et al. (US 2014/0086253 A1) in view of RFC 4271, and further in view of RFC 7432. (https://datatracker.ietf.org/doc/html/rfc7432)
Regarding claim 5, Yong further discloses the first route is a first Ethernet virtual private network (EVPN) route, and the first NLRI is a first EVPN NLRI, as evidenced by overlay routing and encapsulation attributes (Yong, ¶[0065]). RFC 7432 explicitly discloses: “EVPN NLRI is carried in BGP using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes” (RFC 7432, Section 7). Thus, it would have been obvious to apply Yong’s NLRI structure to EVPN routes.
Regarding claim 6, Yong does not disclose an encoding format of the first EVPN NLRI is different from an encoding format of an EVPN NLRI defined in RFC 7432. RFC 7432 discloses: “The format of the EVPN NLRI is as follows…” (RFC 7432, Section 7). Thus, modifying or varying the encoding format relative to the standardized format would have been an obvious design choice.
Regarding claim 7, Yong further discloses the first EVPN route is a compressed MAC/IP advertisement route, and the optional routing information comprises an Ethernet segment identifier and an Ethernet tag identifier, as evidenced by encapsulation-related routing parameters (Yong, ¶[0065]). RFC 7432 explicitly discloses: “Route Type 2: MAC/IP Advertisement Route” and “Ethernet Segment Identifier (ESI)… Ethernet Tag ID…” (RFC 7432, Section 7.2). Thus, it would have been obvious to include these fields.
Regarding claim 8, Yong further discloses the optional routing information further comprises a multi-protocol label switching (MPLS) label, as evidenced by tunneling attributes (Yong, ¶[0065]). RFC 7432 explicitly discloses: “MPLS Label1… MPLS Label2…” (RFC 7432, Section 7.2). Thus, it would have been obvious to include MPLS labels.
Regarding claim 9, Yong further discloses the first EVPN route is a compressed IP prefix route, and the optional routing information comprises an Ethernet segment identifier, an Ethernet tag identifier, and a gateway IP address, as evidenced by routing attributes (Yong, ¶[0065]). RFC 7432 explicitly discloses: “IP Prefix Route” (RFC 7432, Section 7.5), including corresponding fields. Thus, it would have been obvious to include these parameters.
Regarding claim 16, Yong further discloses the first route is a first EVPN route, and the first NLRI is a first EVPN NLRI, as discussed above for claim 5. RFC 7432 supports this with: “EVPN NLRI is carried in BGP…” (RFC 7432, Section 7).
Regarding claim 17, Yong does not disclose an encoding format of the first EVPN NLRI is different from an encoding format of an EVPN NLRI defined in RFC 7432. RFC 7432 discloses: “The format of the EVPN NLRI is as follows…” (RFC 7432, Section 7). Thus, modifying the format would have been obvious.
Regarding claim 18, Yong further discloses the first EVPN NLRI comprises a route type field, and the route type field comprises one of a compressed MAC/IP advertisement route, a compressed IP prefix route, a compressed Ethernet auto-discovery route, a compressed inclusive multicast route, or a compressed Ethernet segment route, as evidenced by EVPN-related routing (Yong, ¶[0065]). RFC 7432 explicitly discloses: “Route Type 1: Ethernet Auto-Discovery Route,” “Route Type 2: MAC/IP Advertisement Route,” “Route Type 3: Inclusive Multicast Ethernet Tag Route,” “Route Type 4: Ethernet Segment Route,” and “Route Type 5: IP Prefix Route” (RFC 7432, Section 7). Thus, it would have been obvious to include these route types.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure (see form 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUAT PHUNG whose telephone number is (571)270-3126. The examiner can normally be reached on M-Th 7:30 AM - 6:30 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, Marcus Smith can be reached on 571-27. 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.
/Luat Phung/
Primary Examiner, Art Unit 2468