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
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-6, 8-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yatsu et al. (US 20110292941; hereinafter “Yatsu”) in view of Devendran et al. (US 20230031921; hereinafter “Devendran”).
Regarding claims 1,12, Yatsu discloses:
A method implemented by a first network device comprising:
generating an operation, administration, and maintenance (OAM) packet ([0043] An OAM frame transmitted from a transmitter 100 to a transmitter 200 will now be described using FIGS. 4 to 6.), comprising a first identifier of the first network device, and indication information indicating a type of the first identifier; ([0042] the OAM frame configuring unit 151, on the basis of control by the OAM administration unit 155, constructs an OAM frame configured with a path MEGID, the MEPID of the local node, the MEPID of a peer node, and an Auto Flag indicating whether or not automatic configuration is enabled.)
and sending the OAM packet to a second network device. ([0073] Herein, the MEPID (expected value) refers to a MEPID expected to be set as the MEPID by the transmitter 200. In other words, the transmitter 100 transmits to the transmitter 200 an OAM frame configured with arbitrary values for the path MEGID, the local node MEPID, and the peer node MEPID.)
Yatsu does not disclose:
wherein when the indication information indicates a first type of the first identifier, the OAM packet comprises a field carrying the first identifier that has a first length, and when the indication information indicates a second type of the first identifier, the field carrying the first identifier has a second length;
However, Devendran discloses:
wherein when the indication information indicates a first type of the first identifier, the OAM packet comprises a field carrying the first identifier that has a first length, and when the indication information indicates a second type of the first identifier, the field carrying the first identifier has a second length; ([0048] MAC header 410 includes the data fields added at the beginning of OAM packet format 400 to turn OAM packet format 400 into a frame that can be transmitted. EtherType 420 is a two-octet field in an Ethernet frame that indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame. EtherType 420 may be used at the receiving end by the data link layer to determine how the payload of OAM packet format 400 is processed.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify OAM frame of the teachings of Yatsu with an OAM frame indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame of the teachings of Devendran, to include an indication field specifying the identifier type (e.g., IPv4 or IPv6) with first length or second length, because a POSITA would have recognized that IPv4 and IPv6 addresses have different lengths (32-bit vs. 128-bit) and that the protocol indication directs parsing and expected field size. The motivation would have been to turn OAM packet format into a frame that can be transmitted (Devendran ¶ [0048]).
Regarding claims 2, 13, 17, Yatsu does not disclose:
wherein the indication information indicates that the type of the first identifier is an Internet Protocol version 6 (IPv6) address.
However, Devendran discloses:
wherein the indication information indicates that the type of the first identifier is an Internet Protocol version 6 (IPv6) address. ([0048] MAC header 410 includes the data fields added at the beginning of OAM packet format 400 to turn OAM packet format 400 into a frame that can be transmitted. EtherType 420 is a two-octet field in an Ethernet frame that indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame. EtherType 420 may be used at the receiving end by the data link layer to determine how the payload of OAM packet format 400 is processed.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify OAM frame of the teachings of Yatsu with an OAM frame indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame of the teachings of Devendran, to include the indication information indicates that the type of the first identifier is an Internet Protocol version 6 (IPv6) address. The motivation would have been to turn OAM packet format into a frame that can be transmitted (Devendran ¶ [0048]).
Regarding claims 3, 14, 18, Yatsu does not disclose:
wherein the indication information indicates that the type of the first identifier is an Internet Protocol version 4 (IPv4) address.
However, Devendran discloses:
wherein the indication information indicates that the type of the first identifier is an Internet Protocol version 4 (IPv4) address. ([0048] MAC header 410 includes the data fields added at the beginning of OAM packet format 400 to turn OAM packet format 400 into a frame that can be transmitted. EtherType 420 is a two-octet field in an Ethernet frame that indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame. EtherType 420 may be used at the receiving end by the data link layer to determine how the payload of OAM packet format 400 is processed.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify OAM frame of the teachings of Yatsu with an OAM frame indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame of the teachings of Devendran, to include wherein the indication information indicates that the type of the first identifier is an Internet Protocol version 4 (IPv4) address. The motivation would have been to turn OAM packet format into a frame that can be transmitted (Devendran ¶ [0048]).
Regarding claims 4,15,19, Yatsu discloses:
wherein the OAM packet further comprises a type field indicating a maintenance entity group (MEG) type, and wherein the type field carries the indication information. ([0042] the OAM frame configuring unit 151, on the basis of control by the OAM administration unit 155, constructs an OAM frame configured with a path MEGID, the MEPID of the local node, the MEPID of a peer node, and an Auto Flag indicating whether or not automatic configuration is enabled.)
Regarding claims 5,20, Yatsu does not disclose:
wherein when the type field carries a first value, the indication information indicates that the type of the first identifier is an IPv6 address; and when a type field carries a second value, the indication information indicates that the type of the first identifier is an IPv4 address.
However, Devendran discloses:
wherein when the type field carries a first value, the indication information indicates that the type of the first identifier is an IPv6 address; and when a type field carries a second value, the indication information indicates that the type of the first identifier is an IPv4 address. ([0048] MAC header 410 includes the data fields added at the beginning of OAM packet format 400 to turn OAM packet format 400 into a frame that can be transmitted. EtherType 420 is a two-octet field in an Ethernet frame that indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame. EtherType 420 may be used at the receiving end by the data link layer to determine how the payload of OAM packet format 400 is processed.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify the teachings of Yatsu with the teachings of Devendran, to include when the type field carries a first value, the indication information indicates that the type of the first identifier is an IPv6 address; and when a type field carries a second value, the indication information indicates that the type of the first identifier is an IPv4 address. The motivation would have been to turn OAM packet format into a frame that can be transmitted (Devendran ¶ [0048]).
Regarding claim 6, Yatsu discloses:
wherein the OAM packet comprises a reserved field carrying the indication information. ([0053] More specifically, the OAM frame configuring unit 151 sets an Auto Flag indicating whether or not automatic configuration is enabled in an "AUTO" region R1 provided in "Reserved (0)" of "Flags", as illustrated in FIG. 6. For example, the OAM frame configuring unit 151 may set "1" in the region R1, which indicates that automatic configuration is enabled. Alternatively, the OAM frame configuring unit 151 may set "0" in the region R1, which indicates that automatic configuration is disabled.)
Regarding claim 8, Yatsu discloses:
wherein the OAM packet further comprises a second identifier of a path from the first network device to the second network device. ([0044] Also, an MPLS-TP path OAM frame includes a 4-byte "Tunnel LSF" and a 4-byte "PW LSF" in which are set a channel label and a path label.)
Regarding claim 9, Yatsu discloses:
wherein the OAM packet further comprises a first field carrying the first identifier ([0044] Also, an MPLS-TP path OAM frame includes a 4-byte "Tunnel LSF" and a 4-byte "PW LSF" in which are set a channel label and a path label. An MPLS-TP path OAM frame also includes a 4-byte "ACH" in which a frame version is set, and a 4-byte Frame Check Sequence (FCS) used in order to detect error. The "Tunnel LSF" includes a label, a "Time Code (TC)" indicating a time interval, an "5" field for identifying a shim header, and a "Time To Live (TTL)" indicating a label's lifetime.)
Yatsu does not disclose:
and a second field carrying the second identifier, and wherein the first field is adjacent to the second field
However, Devendran discloses:
and a second field carrying the second identifier, and wherein the first field is adjacent to the second field. ([0048] MAC header 410 includes the data fields added at the beginning of OAM packet format 400 to turn OAM packet format 400 into a frame that can be transmitted. EtherType 420 is a two-octet field in an Ethernet frame that indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame. EtherType 420 may be used at the receiving end by the data link layer to determine how the payload of OAM packet format 400 is processed.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify an MPLS-TP path OAM frame includes a 4-byte "Tunnel LSF" and a 4-byte "PW LSF" of the teachings of Yatsu with Internet Protocol version 4 (IPv4) or IPv6 of the teachings of Devendran, to include a second field carrying the second identifier, and wherein the first field is adjacent to the second field. The motivation would have been to turn OAM packet format 400 into a frame that can be transmitted (Devendran ¶ [0048]).
Regarding claim 10, Yatsu discloses:
wherein the second identifier is a label switched path (LSP) identifier, a section identifier, a pseudo wire (PW) identifier, or a ring identifier. ([0044] Also, an MPLS-TP path OAM frame includes a 4-byte "Tunnel LSF" and a 4-byte "PW LSF" in which are set a channel label and a path label.)
Regarding claims 11, Yatsu discloses:
wherein the OAM packet corresponds to multi-protocol label switching - transport profile (MPLS-TP) OAM. ([0045] Additionally, an MPLS-TP path OAM frame includes an "OAM payload", which is a region in which is set data used by OAM, and an "OAM header", which is an OAM header region.)
However, Devendran discloses:
an Internet Protocol (IP) mode of MPLS OAM ([0048] MAC header 410 includes the data fields added at the beginning of OAM packet format 400 to turn OAM packet format 400 into a frame that can be transmitted. EtherType 420 is a two-octet field in an Ethernet frame that indicates which protocol (e.g., Internet Protocol version 4 (IPv4), IPv6, etc.) is encapsulated in the payload of the frame. EtherType 420 may be used at the receiving end by the data link layer to determine how the payload of OAM packet format 400 is processed.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify the teachings of Yatsu with the teachings of Devendran, to include an Internet Protocol (IP) mode of MPLS OAM. The motivation would have been to turn OAM packet format 400 into a frame that can be transmitted (Devendran ¶ [0048]).
Regarding claim 16 based on claim 1, Yatsu discloses:
A first network device, comprising: a memory configured to store instructions; and a processor coupled to the memory and configured to execute the instructions to cause the first network device to: ([0040] As illustrated in FIG. 3, the storage 140 includes administration data storage 141, and stores various data used by the transmitter 100 and processing results by the controller 150 later described. The storage 140 is a storage apparatus such as random access memory (RAM), read-only memory (ROM), flash memory or other semiconductor memory element, a hard disk, or an optical disc, for example. The administration data storage 141 stores control information such as a MEGID and MEPIDs configured by the controller 150 later described. [0041] The controller 150 may be a microprocessor unit (MPU))
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Yatsu et al. (US 20110292941; hereinafter “Yatsu”) in view of Devendran et al. (US 20230031921; hereinafter “Devendran”) further in view of Liu et al. (US 20210099382; hereinafter “Liu”).
Regarding claim 7, combination of Yatsu and Devendran does not disclose:
wherein when at least one bit in the reserved field comprises is-a first value, the indication information is used to indicate that the type of the first identifier of the first network device is an IPv6 address; and when at least one bit in the reserved field-is comprises a second value, the indication information indicates is used to indicate that the type of the first identifier of the first network device is an IPv4 address.
However, Liu discloses:
wherein when at least one bit in the reserved field comprises is-a first value, the indication information is used to indicate that the type of the first identifier of the first network device is an IPv6 address; ([0055] The U-SRH in the step 1 may include, but is not limited to, an encapsulation type (LT, such as 3 bits) parameter of the forwarding plane, indicating an encapsulation protocol format of the label, a flexible label encapsulation type is supported, and an MPLS label type (e.g., 0:MPLS/1:IPv6, and others to be allocated) is suggested by default.)
and when at least one bit in the reserved field-is comprises a second value, the indication information indicates is used to indicate that the type of the first identifier of the first network device is an IPv4 address. ([0042]: if the forwarding plane is an IPv4 forwarding plane, the allocating module allocates a UDP port number, such as a UDP port number 2000 indicating that the U-SRH is carried, for the service packet, as the compatibility indicator; [0055] The U-SRH in the step 1 may include, but is not limited to, an encapsulation type (LT, such as 3 bits) parameter of the forwarding plane, indicating an encapsulation protocol format of the label, a flexible label encapsulation type is supported, and an MPLS label type (e.g., 0:MPLS/1:IPv6, and others to be allocated) is suggested by default.)
It would be obvious to the person of ordinary skill in the art, before the effective filling
date of the claimed invention, to modify the teachings of combination of Yatsu and Devendran with the teachings of Liu, to include when at least one bit in the reserved field comprises is-a first value, the indication information is used to indicate that the type of the first identifier of the first network device is an IPv6 address; and when at least one bit in the reserved field-is comprises a second value, the indication information indicates is used to indicate that the type of the first identifier of the first network device is an IPv4 address. The motivation would have been to solve the problem that different label stack encapsulation formats need to be adapted for different forwarding planes when the packet is forwarded by current SR (Liu ¶[0008]).
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 NHU PHAM whose telephone number is (703)756-4511. The examiner can normally be reached Monday - Friday: 8:30 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, Jae Y. Lee can be reached at (571) 270-3936. 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.
/NHU PHAM/Examiner, Art Unit 2479 /JAE Y LEE/Supervisory Patent Examiner, Art Unit 2479
Prosecution Insights