DETAILED ACTION
This action is in response to communication filed on 10/31/2024.
Claims 17, 19, 22, 26, 28, 29, 31, 32, 36, 40, 44, 45, 47, 48, 52, 56, 60, 61, 68, 69 are pending.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/5/2024 and 11/6/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 of this title, 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.
Claims 17, 19, 22, 26, 29, 31, 32, 36, 40, 45, 47, 48, 52, 56, 61 are rejected under 35 U.S.C. 103 as being unpatentable over Sachs et al. (US 2020/0259896) in view of Moon et al. (US 2023/0077354).
Regarding claim 29, Sachs discloses a method performed by a first network node for configuration mapping in a communications network, the method comprising:
receiving from a controller entity at least one first configuration parameter (Sachs discloses the CNC is the centralized controller entity that supplies the first configuration parameter (TSN Stream requirement: cycle times + gate-control lists) directly to the 5GC/AMF (first network node) in the fully-centralized model; [1253] “the CNC treats the 5G network as a TSN switch in the path, and therefore requests the 5G core network (5GC) to configure resources for this TSN stream. For example, this can be done by the CNC sending to an access management function (AMF, see FIGS. 110-111) the cycle times and gate control lists for traffic classes within the TSN stream”);
mapping the at least one first configuration parameter to at least one second configuration parameter (Sachs discloses the AMF (first network node) explicitly performs a parameter translation/mapping: TSN-specific parameter (cycle time, gate-control list = first parameters) for 5G QoS flow parameter + time-window/periodicity value (second parameter). This mapping is required to make the TSN requirement usable inside the 5G RAN; [1254] “in operation 14, the receiving entity (e.g., AMF) in the 5GC can translate the requested TSN stream requirements (e.g., cycle time, gate control list, etc.) to QoS requirements for the UE that is connected to the TSN Talker/Listener (e.g., sensor). In addition, the AMF can translate the requested TSN stream requirements into a time window and periodicity for the gNB(s) to which the UE will transmit and/or receive this TSN stream” and [1947] “when estimating the required QoS for the TSN stream in step 3), the VEP considers the internal communication performance parameters within the 5G network, i.e. between the VEP and the end-device. e.g. one way or round-trip latency, packet error rate or reliability indicator, etc. When the VEP communicates QoS requirements to the TSN network, it considers those internal performance parameters, since the TSN network “thinks” that the VEP and the endpoint are the same”);
transmitting to a second network node the at least one second configuration parameter (Sachs discloses the AMF transmits the mapped second parameter (time-window, periodicity, QoS indicators) to the gNB (second network node) as the resource-confirmation request; [1254] “In operation 14, the receiving entity (e.g., AMF) in the 5GC can translate the requested TSN stream requirements (e.g., cycle time, gate control list, etc.) to QoS requirements for the UE that is connected to the TSN Talker/Listener (e.g., sensor)” and [1255] “a mapping between traffic classes within this TSN stream and QoS flows of the UE can be identified. For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB” and [2256] “…forward the settings to another core network node or function, such as the policy control function (PCF) to perform this function. The AF or PCF may be configured with information as to how redundancy is to be supported in the wireless communication network (e.g., using any of the techniques described above)”);
receiving from the second network node success or failure information pertaining to one or both of the configuration parameters and the configuration mapping, the success or failure information being provided by status codes (Sachs discloses the gNB returns explicit success/failure information (“yes”/accept or “no”/decline) directly pertaining to whether the second parameters (and thus the mapping) can be supported. The “yes”/”no” response functions as the status code (binary status) indication with optional alternate-value payload, standard in network configuration protocols; [1257] “the AMF sends an indication and/or request the gNB(s) to confirm that the QoS, time window, and/or periodicity requirements can be met. In operation 15, after receiving the request/indication sent in operation 14, the gNB (or gNBs, as the case may be) determines whether it can serve this additional QoS flow with the indicated time-window requirement….the gNB responds to the 5GC function (e.g., AMF) by accepting the request (“yes”) or declining the request (“no”)”); and
transmitting to the controller entity success or failure information pertaining to the one of both of the configuration parameters and the configuration mapping, the success or failure information being provided by status codes (Sachs discloses the AMF forwards the identical success/failure information (the same “yes”/”no” status) back to the CNC (controller entity), completing the closed-loop mapping and status reporting; [1257] “After making this determination, the gNB responds to the 5GC function (e.g., AMF) by accepting the request (“yes”) or declining the request (“no”). In some embodiments, when declining the request, the gNB can indicate an alternative time window (e.g., by an offset to the requested time window) during which the gNB could accept a corresponding request” and [1258] “In operation 16, after receiving the response from the gNB(s), the 5GC function may then translate this response—which is based on per QoS flow mapping—to a traffic flow/TSN stream level of granularity, and provides a response to the TSN CNC. The response may be in a format that can be decoded by the TSN CNC”).
However, the prior art does not explicitly disclose the success or failure information being provided by status codes.
Moon in the field of the same endeavor discloses techniques for supporting time-sensitive communication in a 5G network by having an application function (AF) entity obtain delay-related information from the 5G system and transmit QoS-related request to a policy control function (PCF). In particular, Moon teaches the following:
the success or failure information being provided by status codes (Moon discloses transmitting (“respond…with the updated result”) success or failure information (“updated result” implies the outcome of the configuration update, which is success if updated or failure if not) pertaining to configuration parameters and mapping (QoS settings for TSN streams, including delay requirement converted between TSN and 5GS clocks). The TSN AF acts as a controller-like entity in Moon’s context, receiving the response from the PCF (analogous to the first network node transmitting to the controller; [0060] “At step 10, the PCF 750 may update the QoS setting rule for the SMF 740 by using the 5QI selected at step 9. Thereafter, the SMF 740 may respond to the PCF 750 with the updated result as in step 10a. Then, the PCF 750 may respond to the TSN AF 760 with the updated result as in step 10b”)).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with Moon to incorporate standardized status code for conveying success or failure in TSN/5G configuration responses, thereby enhancing interoperability, detailed error handling and predictable outcomes in time-sensitive networking systems.
Regarding claim 31, Sachs discloses the method of claim 29, further comprising:
determining at least one user session that is affected by the at least one first configuration parameter (Sachs discloses determining at least one user session (PDU session) affected by the first configuration parameter because the AF converts the received TSN settings to identify and target the relevant PDU session for medication to align with the new TSN path requirement, including determining which session handle the affected stream forwarding paths in the 5GS; [2244] “AF converts the TSN configuration settings for the 5GS, triggers PDU session modification and further provides SMF with relevant forwarding rules and packet filter set which are further used by SMF to configure UPF forwarding rules and packet filter set. This may include knowledge about which paths have been selected by the CNC for forwarding stream traffic in the 5GS”); and
providing to the second network node information on how the at least one user session is to be modified (Sachs [2244] “AF converts the TSN configuration settings for the 5GS, triggers PDU session modification and further provides SMF with relevant forwarding rules and packet filter set which are further used by SMF to configure UPF forwarding rules and packet filter set. This may include knowledge about which paths have been selected by the CNC for forwarding stream traffic in the 5GS; this knowledge might be used by the 5GS to route streams accordingly”).
Regarding claim 32, Sachs discloses the method of claim 29, further comprising:
determining traffic flow information or flow direction information regarding whether the traffic flow is uplink traffic, downlink traffic, or user terminal to user terminal traffic (Sachs [0775] “One way of achieving a timely delivery of packets might involve the use of playout-buffers at the egress points of the 5G network (i.e. at a UE and the UPF for downlink or uplink). Those playout buffers need to be time aware and also aware of the time schedule used for Qbv and specified by the TSN network's CNC”); and
providing to the second network node the traffic flow information or flow direction information (Sachs [1261] “In operation 23, after receiving this message, the AMF retrieves the UE profile from a user data management (UDM) function in the 5GC and, based on this information, determines to which gNB(s) the UE is connected. In operation 24, the AMF sends a request to the gNB(s) to enable the TSN QoS feature towards the UE based on the transmission schedule, which can be included in the request”).
Regarding claim 36, Sachs discloses the method of claim 29,
wherein the at least one first configuration parameter is maximum latency, and the at least one second configuration parameter is a required delay; or
wherein the at least one first configuration parameter is maximum loss, and the at least one second configuration parameter is Packet Error Rate, PER; or
wherein the at least one first configuration parameter is interval information (Sachs [1254] “In operation 14, the receiving entity (e.g., AMF) in the 5GC can translate the requested TSN stream requirements (e.g., cycle time, gate control list, etc.) to QoS requirements for the UE that is connected to the TSN Talker/Listener (e.g., sensor)”), and the at least one second configuration parameter is periodicity information (Sachs [1255] “operation 14 can involve various sub-operations. For example, the UE and a PDU session corresponding to the TSN stream can be identified, and a mapping between traffic classes within this TSN stream and QoS flows of the UE can be identified. For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB”); or
wherein the at least one first configuration parameter is one or both of maximum packets per interval and maximum payload size, and the at least one second configuration parameter is one or more of Guaranteed Flow Bit Rate, GFBR, and Maximum Flow Bit Rate, MFBR.
Regarding claim 40, Sachs discloses the method of claim 29, wherein the at least one first configuration parameter is any one of maximum latency variation, maximum consecutive loss tolerance, maximum disordering, a differentiated services code point value, minimum packets per interval, and minimum payload size (Sachs [0742] “TSN aims at supporting all type of traffic classes (Quality of Service (QoS) and non-QoS) over the same infrastructure. Therefore, the TSN network sits somewhere between a CBR and a best effort type of packet service, where the latency is typically larger compared to a CBR network, but the latency variation and the jitter are bounded—no tails. In other words, TSN offers a guarantee that the network will not perform worse than a specific agreed end-to-end latency and jitter, as seen in the bottom part of FIG. 28”).
Regarding claim(s) 17, 19, 22, 26, 45, 47, 48, 52, 56, 61 do(es) not teach or further define over the limitation in claim(s) 29, 31, 32, 36, 40 respectively. Therefore claim(s) 17, 19, 22, 26, 45, 47, 48, 52, 56, 61 is/are rejected for the same rationale of rejection as set forth in claim(s) 29, 31, 32, 36, 40 respectively.
Claims 28, 44, 60, 68, 69 are rejected under 35 U.S.C. 103 as being unpatentable over Sachs et al. (US 2020/0259896) in view of Moon et al. (US 2023/0077354) in view of Talebi Fard et al. (US 2025/0267023 “hereafter Talebi”).
Regarding claim 69, Sachs discloses the method of claim 40, the second network node is a Policy Control Function, PCF (Sachs [2256] “the AF may perform this function or, alternatively, it may forward the settings to another core network node or function, such as the policy control function (PCF) to perform this function. The AF or PCF may be configured with information as to how redundancy is to be supported in the wireless communication network”).
However the prior art does not explicitly disclose wherein the controller entity is a DetNet controller, the first network node is a Time Sensitive communication Time Synchronization function, TSCTSF.
Talebi in the field of the same endeavor discloses techniques for integrating Deterministic Networking into 5G/3GPP systems by configuring UPF and UE as DetNet nodes, enhancing signaling for flow creation and resource allocation through entities like TSCTSF, PCF, SMF, and NEF, and managing QoS mapping, failure handling, and event reporting to ensure low-latency, low-jitter, and reliable time-sensitive communication. In particular, Kang teaches the following:
wherein the controller entity is a DetNet controller, the first network node is a Time Sensitive communication Time Synchronization function, TSCTSF, (Talebi [0210] “The DetNet node or DetNet system may comprise a DetNet controller entity that may act as a DetNet Control Plane” and [0305] “the TSCTSF may perform calculation of required DetNet resources based on an element of the DetNet parameter. If the TSCTSF receives a DetNet parameter, or a QoS parameter associated with a DetNet node or DetNet flow, the TSCTSF may calculate a Requested PDB by subtracting the UE-DS-T Residence Time, or DS-TT residence time, provided by the PCF (if available), from the Requested 5GS delay. In an example, the TSCTSF may determine or modify the DetNet assistance information, the DetNet management container, the DetNet parameter, and/or the like”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Talebi to integrate DetNet-specific controller and TSCTSF roles into TSN/5G interworking setups, thereby enhancing deterministic flow management, QoS mapping, and failure handling for reliable, low-latency time-sensitive communication in 3GPP networks.
Regarding claim(s) 28, 44, 60 and 68 do(es) not teach or further define over the limitation in claim(s) 69 respectively. Therefore claim(s) 28, 44, 60 and 68 is/are rejected for the same rationale of rejection as set forth in claim(s) 69 respectively.
Conclusion
For the reason above, claims 17, 19, 22, 26, 28, 29, 31, 32, 36, 40, 44, 45, 47, 48, 52, 56, 60, 61, 68, 69 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451