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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Information Disclosure Statement
The information disclosure statement (IDS) submitted is being considered by the examiner.
Claim Status
Claims 1-8, 11-20 are pending and claims 9-10 are canceled according to preliminary claim amendment filed on 04/04/2024.
Claim Rejections - 35 USC § 102
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 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.
Claim(s) 1 – 2, 7 and 11 – 14 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ruan et al. CN112637251A (publication date 2021-04-09, translation provided for citation, listed in applicant submitted IDS and listed as D1 in both EPO and PCT search reports).
Regarding claim 1, Ruan teaches a method for advertising enhanced frame preemption capability information, comprising:
(Ruan: Summary and para. [0062] functional modules or program modules, which may be implemented by software or hardware. For modules implemented by hardware, each of the foregoing modules may be located in the same processor)
acquiring enhanced frame preemption capability information, wherein the enhanced frame preemption capability information comprises at least one of:
(Ruan: para. [0036] S100: Extract the device information from the MIB library, where the device information is encapsulated in the information field of the LLDPDU, and the Ethernet capability notification information TLV value is appended to the information field of the LLDPDU, and the TLV value is used to indicate whether the device supports frame preemption Function)
a reason for frame preemption being not enabled;
(Ruan: para. [0043-0045] and Table 1 - Additional Ethernet Capability Advertisement message shall contain an indication of the bytes used to identify the local IEEE 802.3 LAN station's support and current status of the Additional Ethernet Capability. Table 1 defines the first two bytes of the field, while reserving additional bytes for other information extensions:
bit
Function
value
0
Preemption function support
1=supported; 0=not supported
1
Preempt functional status
1=on; 0=off
2
Preemption function enabled
1=enable; 0=disable
4:3
Size of additional fields (addFragSize)
Use a 2-bit integer value to represent the minimum number of bytes over 64 bytes required by the receiver in a non-final segment
15:5
reserve
Preemption function support – not supported which corresponds to claim limitation “reason Preemption function is disabled”)
an indication value for specifying a minimum value of a last fragment of a preempted packet; or
a multi-level frame preemption capability supported by a port; wherein, a number of selectable values supported by the indication value is greater than a preset threshold; and
sending the enhanced frame preemption capability information to a communication peer end. (Ruan: para. [0055] during the connection process of the device, the device initializes the information in its own MIB library, extracts the device information from the MIB, and the device information will be encapsulated in the information field of the LLDPDU, and the information field of the LLDPDU is appended with The TLV value of the Ethernet capability advertisement information is used to indicate whether the device supports the frame preemption function. The LLDP protocol frame is then sent out through the triggering method of the device itself, such as when the timer expires or when the device status changes, etc)
Regarding claim 2, Ruan teaches the method for advertising enhanced frame preemption capability information of claim 1, wherein sending the enhanced frame preemption capability information to a communication peer end (Ruan: para. [0055] during the connection process of the device, the device initializes the information in its own MIB library, extracts the device information from the MIB, and the device information will be encapsulated in the information field of the LLDPDU, and the information field of the LLDPDU is appended with The TLV value of the Ethernet capability advertisement information is used to indicate whether the device supports the frame preemption function. The LLDP protocol frame is then sent out through the triggering method of the device itself, such as when the timer expires or when the device status changes, etc) comprises:
sending the enhanced frame preemption capability information to the communication peer end by extending an Additional Ethernet Capabilities (AEC) field of a Link Layer Discovery Protocol (LLDP) packet. (Ruan: para. [0055 & 0036 & 0042-0043 & 0046 & 0048] during the connection process of the device, the device initializes the information in its own MIB library, extracts the device information from the MIB, and the device information will be encapsulated in the information field of the LLDPDU, and the information field of the LLDPDU is appended with The TLV value of the Ethernet capability (corresponds to claim limitation “Additional Ethernet Capabilities (AEC) field”) advertisement information is used to indicate whether the device supports the frame preemption function. The LLDP protocol frame is then sent out through the triggering method of the device itself, such as when the timer expires or when the device status changes, etc)
Regarding claim 7, Ruan teach a method for configuring a frame preemption function, comprising: (Ruan: Summary and para. [0062] functional modules or program modules, which may be implemented by software or hardware. For modules implemented by hardware, each of the foregoing modules may be located in the same processor)
receiving enhanced frame preemption capability information sent by a communication peer end,
(Ruan: para. [0036] S100: Extract the device information from the MIB library, where the device information is encapsulated in the information field of the LLDPDU, and the Ethernet capability notification information TLV value is appended to the information field of the LLDPDU, and the TLV value is used to indicate whether the device supports frame preemption Function)
wherein the enhanced frame preemption capability information comprises at least one of:
a reason for frame preemption being not enabled;
(Ruan: para. [0043-0045] and Table 1 - Additional Ethernet Capability Advertisement message shall contain an indication of the bytes used to identify the local IEEE 802.3 LAN station's support and current status of the Additional Ethernet Capability. Table 1 defines the first two bytes of the field, while reserving additional bytes for other information extensions:
bit
Function
value
0
Preemption function support
1=supported; 0=not supported
1
Preempt functional status
1=on; 0=off
2
Preemption function enabled
1=enable; 0=disable
4:3
Size of additional fields (addFragSize)
Use a 2-bit integer value to represent the minimum number of bytes over 64 bytes required by the receiver in a non-final segment
15:5
reserve
Preemption function support – not supported, which corresponds to claim limitation “reason Preemption function is disabled”)
an indication value for specifying a minimum value of a last fragment of a preempted packet; or a multi-level frame preemption capability supported by a port;
and wherein, a number of selectable values supported by the indication value is greater than a preset threshold;
determining a configuration parameter of the frame preemption function according to the enhanced frame preemption capability information sent by the communication peer end and enhanced frame preemption capability information supported locally. (Ruan: para. [0055] during the connection process of the device, the device initializes the information in its own MIB library, extracts the device information from the MIB, and the device information will be encapsulated in the information field of the LLDPDU, and the information field of the LLDPDU is appended with The TLV value of the Ethernet capability advertisement information is used to indicate whether the device supports the frame preemption function. The LLDP protocol frame is then sent out through the triggering method of the device itself, such as when the timer expires or when the device status changes, etc)
Regarding claim 11, Ruan teaches a communication device, comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein: the memory stores an instruction executable by the at least one processor which, when executed by the at least one processor, causes the at least one processor to carry out the method for advertising enhanced frame preemption capability information of claim 1. (Ruan: Summary and para. [0062] functional modules or program modules, which may be implemented by software or hardware. For modules implemented by hardware, each of the foregoing modules may be located in the same processor)
Regarding claim 12, Ruan teaches a non-transitory computer-readable storage medium, storing a computer program which, when executed by a processor, causes the processor to carry out the method for advertising enhanced frame preemption capability information of claim 1. (Ruan: Summary and para. [0062] functional modules or program modules, which may be implemented by software or hardware. For modules implemented by hardware, each of the foregoing modules may be located in the same processor)
Regarding claims 13 – 14, Ruan teaches all the limitations as discussed in the rejection of claims 11 – 12, and therefore apparatus claims 13 – 14 are rejected using the same rationales.
Claim Rejections - 35 USC § 103
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.
Claim(s) 3 – 6, 8 and 15 – 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ruan in view of IEEE Standard for Ethernet Amendment 5: Specification and Management Parameters for Interspersing Express Traffic", IEEE STANDARD, IEEE, PISCATAWAY, NJ, USA, 14 October 2016 (2016-10-14), pages 1-58, XP068110544 (listed in applicant submitted IDS and listed as D2 in EPO search report), hereinafter IEEE.
Regarding claim 3, Ruan teaches the method for advertising enhanced frame preemption capability information of claim 1, wherein sending the enhanced frame preemption capability information to a communication peer end (Ruan: para. [0055] during the connection process of the device, the device initializes the information in its own MIB library, extracts the device information from the MIB, and the device information will be encapsulated in the information field of the LLDPDU, and the information field of the LLDPDU is appended with The TLV value of the Ethernet capability advertisement information is used to indicate whether the device supports the frame preemption function. The LLDP protocol frame is then sent out through the triggering method of the device itself, such as when the timer expires or when the device status changes, etc) comprises:
Ruan does not explicitly teaches: encoding the enhanced frame preemption capability information in a Tag-Length-Value (TLV) format, adding the encoded enhanced frame preemption capability information to a data field of a verify (SMD_V) packet or a respond (SMD_R) packet, and sending the SMD_V packet or the SMD_R packet to the communication peer end, wherein a Start mPacket Delimiter (SMD) field of the SMD_V packet or the SMD_R packet carrying the enhanced frame preemption capability information is set to a value representing that the enhanced frame preemption capability information is carried.
However, IEEE from the same or similar fields of endeavor teaches the use of: encoding the enhanced frame preemption capability information in a Tag-Length-Value (TLV) format, (IEEE: page 28 - 79.3.7 Additional Ethernet Capabilities TLV - Additional Ethernet Capabilities TLV is an optional TLV that indicates which additional capabilities are supported. Figure 79–8 shows the format of this TLV. Figure 79–8—Additional Ethernet Capabilities TLV)
adding the encoded enhanced frame preemption capability information to a data field of a verify (SMD_V) packet or a respond (SMD_R) packet, (IEEE: page 40 - 99.3.3 Start mPacket Delimiter (SMD) - The term “SMD-S” refers to any of the four SMD values (SMD-S0, SMD-S1, SMD-S2, and SMD-S3) in an mPacket carrying the start of a preemptable packet. The term “SMD-C” refers to any of the four SMD values (SMD-C0, SMD-C1, SMD-C2, and SMD-C3) in an mPacket carrying a continuation fragment of a preemptable packet. Two additional SMD values, SMD-V and SMD-R, identify mPackets used to verify that a link can support the preemption capability) and sending the SMD_V packet or the SMD_R packet to the communication peer end, wherein a Start mPacket Delimiter (SMD) field of the SMD_V packet or the SMD_R packet carrying the enhanced frame preemption capability information is set to a value representing that the enhanced frame preemption capability information is carried. (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation - Verification relies on the transmission of a verify mPacket and receipt of a respond mPacket to confirm that the remote station supports the preemption capability. The format of a verify mPacket and a respond mPacket is as shown in part (a) of Figure 99–4, with the SMD values defined in Table 99–1 and an mData field containing 60 octets of 0x00. When an mPacket with an SMD-V and a correct mCRC is received, a respond mPacket is sent. A respond mPacket has 7 octets of preamble (0x55), an SMD-R, 60 octets of 0x00, and an mCRC). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of IEEE in the method of Ruan. One of ordinary skill in the art would be motivated to do so for where it is ensured by design that links can support preemption capability (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation).
Regarding claim 4, Ruan teaches the method for advertising enhanced frame preemption capability information of claim 1, wherein sending the enhanced frame preemption capability information to a communication peer end (Ruan: para. [0055] during the connection process of the device, the device initializes the information in its own MIB library, extracts the device information from the MIB, and the device information will be encapsulated in the information field of the LLDPDU, and the information field of the LLDPDU is appended with The TLV value of the Ethernet capability advertisement information is used to indicate whether the device supports the frame preemption function. The LLDP protocol frame is then sent out through the triggering method of the device itself, such as when the timer expires or when the device status changes, etc) comprises:
Ruan does not explicitly teaches: setting a value of a SMD field of a Media Access Control (MAC) Merge Packet (mPacket) to a value representing the enhanced frame preemption capability information.
However, IEEE from the same or similar fields of endeavor teaches the use of: setting a value of a SMD field of a Media Access Control (MAC) Merge Packet (mPacket) to a value representing the enhanced frame preemption capability information. (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation - Verification relies on the transmission of a verify mPacket and receipt of a respond mPacket to confirm that the remote station supports the preemption capability. The format of a verify mPacket and a respond mPacket is as shown in part (a) of Figure 99–4, with the SMD values defined in Table 99–1 and an mData field containing 60 octets of 0x00. When an mPacket with an SMD-V and a correct mCRC is received, a respond mPacket is sent. A respond mPacket has 7 octets of preamble (0x55), an SMD-R, 60 octets of 0x00, and an mCRC). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of IEEE in the method of Ruan. One of ordinary skill in the art would be motivated to do so for where it is ensured by design that links can support preemption capability (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation).
Regarding claim 5, Ruan teaches the method for advertising enhanced frame preemption capability information of claim 1, Ruan does not explicitly teach: wherein the reason for frame preemption being not enabled comprises: management configuration being disabled, state machine exception, unsuccessful state machine initialization, and an unknown reason.
However, IEEE from the same or similar fields of endeavor teaches the use of: wherein the reason for frame preemption being not enabled comprises: management configuration being disabled, state machine exception, unsuccessful state machine initialization, and an unknown reason (IEEE: page 55 - 99.5.3.1 Functional specifications - Disabled on link failure indication (corresponds to claim limitation “unsuccessful state machine initialization”, and it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use “configuration being disabled, state machine exception, and an unknown reason” to describe different disabling reasons). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of IEEE in the method of Ruan. One of ordinary skill in the art would be motivated to do so for where it is ensured by design that links can support preemption capability (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation).
Regarding claim 6, Ruan teaches the method for advertising enhanced frame preemption capability information of claim 1, Ruan does not explicitly teaches: wherein the method further comprises:
triggering sending of an SMD_R packet in response to frame preemption being not enabled or being enabled already, after receiving an SMD_V packet sent by the communication peer end for requesting frame preemption capability information.
However, IEEE from the same or similar fields of endeavor teaches the use of: triggering sending of an SMD_R packet in response to frame preemption being not enabled or being enabled already, after receiving an SMD_V packet sent by the communication peer end for requesting frame preemption capability information. (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation - Verification relies on the transmission of a verify mPacket and receipt of a respond mPacket to confirm that the remote station supports the preemption capability. The format of a verify mPacket and a respond mPacket is as shown in part (a) of Figure 99–4, with the SMD values defined in Table 99–1 and an mData field containing 60 octets of 0x00. When an mPacket with an SMD-V and a correct mCRC is received, a respond mPacket is sent. A respond mPacket has 7 octets of preamble (0x55), an SMD-R, 60 octets of 0x00, and an mCRC). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the teaching of IEEE in the method of Ruan. One of ordinary skill in the art would be motivated to do so for where it is ensured by design that links can support preemption capability (IEEE: pages 42-43 - 99.4.3 Verifying preemption operation).
Regarding claims 8, Ruan and IEEE teach all the limitations as discussed in the rejection of claims 2 – 4, and therefore method claim 8 is rejected using the same rationales.
Regarding claims 15 – 20, Ruan and IEEE teach all the limitations as discussed in the rejection of claims 5 – 6, and therefore method claims 15 – 20 are rejected using the same rationales.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please also see PTO-892.
Cakulev et al.US 20200236578 A1 in para. [0015] teaches one or more preemption indicators (e.g., a preemption capability indication (PCI), a preemption vulnerability indication (PVI), and/or the like) associated with the ARP can be included within the QoS profile.
OJEWALE, M., et al. "Multi-Level Preemption in TSN: Feasibility and Requirements Analysis," IEEE 23rd International Symposium on Real-Time Distributed Computing (ISORC), 2020, pages 47-55, (listed in applicant submitted IDS and listed as D2 in PCT search report) - pages 50 – 54 – VI. On The Feasibility and Requirements Of The Multi-Level Preemption Paradigm – The receiver node, in return, sends a response to confirm that it supports preemption(s) or otherwise. In practice, this information is interpreted by the sending node based on the SMD value of the response frame. The transmission of any preemptable frame starts only after this verification process. From this discussion, both the “Transmit Processing” and the “Receive Processing” functions would require modifications before multi-level preemption can be enabled. For the transmission, we would need the SMD values to also inform the sending node of the preemption level the receiver node supports.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUTCHUNG CHU whose telephone number is (571)272-4064. The examiner can normally be reached 10:00 AM - 4:00 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, Moo R Jeong can be reached at (571) 272-9617. 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.
/WUTCHUNG CHU/ Primary Examiner, Art Unit 2418
Prosecution Insights