DETAILED ACTION
This action is in response to communication filed on 4/7/2025.
Claims 1-20 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 .
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 1-3 and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US 2023/0110709) in view of Huang et al. (US 2021/0051562).
Regarding claim 1, Wang discloses a method, comprising:
receiving, by a processor of a user equipment (UE), one or more packets from a network (Wang discloses a UE receiving data units/packets (SDU) of data streams from the network; [0013] “As shown, the UE can receive a 4G/LTE data stream (e.g., via the 4G/LTE connection) and a 5G/NR data stream (e.g., via the 5G/NR connection)”);
evaluating, by the processor, a [local application-specific] forwarding policy (Wang discloses the UE evaluating a local forwarding policy by maintaining and checking a buffer occupancy counter and/or t-reordering timer to determine whether to provide (forward) the buffered packets; [0012] “Some implementations described herein can trigger provision of buffered data to the upper layer based on a buffer occupancy counter that is based on a number of packets (e.g., data units, etc.) that are buffered by the UE. When the buffer occupancy counter satisfies a threshold, the UE can provide the buffered packets to the upper layer. The buffer occupancy counter can be implemented in addition to or as an alternative to the t-reordering timer”); and
forwarding, by the processor, at least one packet of the one or more packets to an application according to the application-specific forwarding policy (Wang discloses the UE forwarding the stored data units/packets to an upper layer of the UE (which delivers to applications) according to the evaluated counter/timer policy; [0019] “As shown by reference number 135, the UE can provide all stored data units that are before a reorder value, and can provide consecutive stored data units after the reorder value, to the upper layer”).
However, the prior art does not explicitly disclose evaluating, by the processor, a local application-specific forwarding policy.
Huang in the field of the same endeavor disclose techniques for enhanced UE route selection policy (URSP) rules evaluation in 5G new radio (NR) systems. In particular, Huang teaches the following:
evaluating, by the processor, a local application-specific forwarding policy (Huang discloses a UE evaluating local application-specific policies (URSP rules) by matching traffic descriptors to application information; [0022] “When UE 101 starts application 140, UE upper layers trigger URSP rules evaluation. Specifically, UE 101 evaluates the URSP rules, except the default URSP rule, with a traffic descriptor matching the application information in increasing order of their precedence values. If UE 101 finds a non-default URSP rule (141) with a traffic descriptor (142) matching the application information, and an established PDU session matching at least one of the route selection descriptors (143) of the non-default URSP rule, UE 101 then provides information on the PDU session that matches the route selection descriptor of the lowest precedence value to the upper layers”).
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 Huang. One would have been motivated to apply Huang’s teaching of evaluating local application-specific polices (matched to the application via traffic descriptors) to the local forwarding policy of Wang (counter/timer-based decision of when to provide packets to the upper layer). Doing so would allow the known buffer/reordering forwarding control of Wang to be applied on per-application basis, which is predictable variation that improvise flexibility and user experience for different applications without changing the basic packet receive and forward operation.
Regarding claim 2, Wang-Huang discloses the method of claim 1, wherein the application-specific forwarding policy involves forwarding immediately upon receipt or forwarding out of order such that the application receives service data units (SDUs) upon receipt by the UE and without the application waiting for reordering of packets (Wang; [0012] “Some implementations described herein can trigger provision of buffered data to the upper layer based on a buffer occupancy counter that is based on a number of packets (e.g., data units, etc.) that are buffered by the UE. When the buffer occupancy counter satisfies a threshold, the UE can provide the buffered packets to the upper layer. The buffer occupancy counter can be implemented in addition to or as an alternative to the t-reordering timer. For example, the buffer occupancy counter can cause the content of the PDCP buffer to be provided to the upper layer more frequently than the t-reordering timer”).
Regarding claim 3, Wang-Huang discloses the method of claim 1, wherein the application-specific forwarding policy comprises an application-controlled policy that helps a latency-sensitive application to cope with hybrid automatic repeat request (HARQ) and one or more other retransmission mechanism-related latency variation in conjunction with an in-order delivery requirement (Wang; [0009] “For a UE performing EN-DC, data can be received on both a 4G/LTE connection and a 5G/NR leg (e.g., on a secondary cell group split bearer). Since data speed and latency are significantly different for 4G/LTE and 5G/NR, this creates some challenges for EN-DC UEs. For example, in scenarios where the 4G/LTE connection experiences bad radio frequency conditions and performs hybrid automatic repeat request (HARQ) and/or radio link control (RLC) retransmissions, the 5G/NR connection can continue to receive data at a higher rate than the 4G/LTE connection. This can cause a large number of out-of-order packets at the UE”, and Huang [0031] “an application identifier included in the traffic descriptor matches with an application ID of the application. Note that if the traffic descriptor contains more than one component, then, all of them (i.e., each component of a respective component type of the traffic descriptor) need to be matched with the application information”).
Regarding claim(s) 11-13, do(es) not teach or further define over the limitation in claim(s) 1-3 respectively. Therefore claim(s) 11-13 is/are rejected for the same rationale of rejection as set forth in claim(s) 1-3 respectively.
Claims 4-5, 7-9, 14-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US 2023/0110709) in view of Huang et al. (US 2021/0051562) in view of Hande et al. (US 2022/0038955).
Regarding claim 4, Wang-Huang discloses the invention substantially, however the prior art does not explicitly disclose the method of claim 1, wherein the evaluating of the local application-specific forwarding policy comprises implementing a channel for the application to control a modem packet forwarding policy regarding retransmission and reordering latencies.
Hande in the field of the same endeavor discloses techniques for monitoring data flows to activate out-of-order delivery (OOOD) transmissions on a user equipment (UE). In particular, Hande teaches the following:
wherein the evaluating of the local application-specific forwarding policy comprises implementing a channel for the application to control a modem packet forwarding policy regarding retransmission and reordering latencies (Hande discloses implementing an application programming interface (API) as a channel that allows the application/upper layers to control the modem/PDCP packet forwarding policy by setting configuration parameters that activate or deactivate out-of-order delivery (OOOD). This controls whether the PDCP layer waits for reordering (which addresses retransmission and reordering latencies) or delivers packets out-of-order/immediately; [0089-0093] “In block 1002, the UE may execute an API, that operates to categorize and/or designate one or more IP flows as one or more sets of PDCP-OOOD flows…In block 1010, the API may then determine one or more configuration parameters for each set of PDCP-OOOD flow indicating if a network RRC-configured flag for PDCP-OOOD enablement is used, or if the UE-side PDCP-OOOD configuration is used. Under these configurations, the UE API may use a configuration parameter for any or all of the PDCP-OOOD flows to selectively configure PDCP-OOOD for activation based on API determinations”, [0096-0098] “In block 1102, the UE may execute an API to set one or more configuration parameters from the wireless network… In block 1106, the UE may activate out-of-order delivery (OOOD) for the data from the wireless network that matches the one or more configuration parameters via the AP… sing a first flag indicating OOOD activation following a wireless network configuration, and/or using a second flag indicating OOOD activation following configuration provided by the API”).
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 Hande. One would have been motivated to incorporate Hand’s teaching of an API channel that lets the application control the modem’s OOOD/reordering policy into the application-specific forwarding policy of Wang/Huang. Doing so would provide a known, predictable interface for the application to influence retransmission and reordering related latencies on a per flow basis, improving flexibility for latency sensitive applications without altering the basic packet receive and forward operation.
Regarding claim 5, Wang-Huang-Hande discloses the method of claim 1, wherein the evaluating of the local application-specific forwarding policy comprises:
receiving a request from the application to apply the local application-specific forwarding policy by ignoring an in-order delivery requirement for service data units (SDUs) matching a flow filter provided by the application (Hande discloses the UE executing an API (the channel/request path from the application) that sets configuration parameters to activate out of order delivery (OOOD), which ignores the normal in-order delivery requirement; [0089-0093] “In block 1002, the UE may execute an API, that operates to categorize and/or designate one or more IP flows as one or more sets of PDCP-OOOD flows… In block 1010, the API may then determine one or more configuration parameters for each set of PDCP-OOOD flow indicating if a network RRC-configured flag for PDCP-OOOD enablement is used, or if the UE-side PDCP-OOOD configuration is used. Under these configurations, the UE API may use a configuration parameter for any or all of the PDCP-OOOD flows to selectively configure PDCP-OOOD for activation based on API determinations”); and
matching the one or more packets to the flow filter (Hande discloses the API identifies and matches IP flows/data to application provided traffic flow templates (TFTs) or QFIs (which functions as flow filters) and activates OOOD only for the matching flows; [0097] “In block 1104, the UE may identify data from the wireless network that matches the one or more configuration parameters via the API… the identifying of the one or more IP flows may include measuring the one or more IP flows associated with one or more API-provided traffic flow templates (TFTs)”, [0098] “In block 1106, the UE may activate out-of-order delivery (OOOD) for the data from the wireless network that matches the one or more configuration parameters via the API. In some examples, the activating of out-of-order delivery for the data may include activating a Packet Data Convergence Protocol (PDCP) OOOD” Rationale to combine is similar to claim 4).
Regarding claim 7, Wang-Huang-Hande discloses the method of claim 1, wherein the evaluating of the local application-specific forwarding policy comprises:
receiving a request from a host operating system to apply the local application-specific forwarding policy by implementing out-of-order forwarding for service data units (SDUs) matching a flow filter (Hande; [0097] “In block 1104, the UE may identify data from the wireless network that matches the one or more configuration parameters via the API. In some examples, the identifying of data from the wireless network may include identifying one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters… the identifying of the one or more IP flows may include measuring the one or more IP flows associated with one or more API-provided traffic flow templates (TFTs). In some examples, identifying the one or more IP flows may include measuring the one or more IP flows associated with one or more API-provided quality-of service flow indicator (QFI) on one of a default resource bearer provided by the wireless network, or an API-provided resource bearer”); and
matching the one or more packets to the flow filter (Hande; [0098] “In block 1106, the UE may activate out-of-order delivery (OOOD) for the data from the wireless network that matches the one or more configuration parameters via the API. In some examples, the activating of out-of-order delivery for the data may include activating a Packet Data Convergence Protocol (PDCP) OOOD”. Rationale to combine is similar to claim 4).
Regarding claim 8, Wang-Huang-Hande discloses the method of claim 1, wherein the evaluating of the local application-specific forwarding policy comprises:
receiving, via a user interface, a user configuration that configures an out-of-order forwarding policy to forward packets mating a match rule using the out-of-order forwarding policy (Hande; [0096] “In block 1102, the UE may execute an API to set one or more configuration parameters from the wireless network”, [0097] “In block 1104, the UE may identify data from the wireless network that matches the one or more configuration parameters via the API. In some examples, the identifying of data from the wireless network may include identifying one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters…in some examples, the identifying of the one or more IP flows may include measuring the one or more IP flows associated with one or more API-provided traffic flow templates (TFTs)”); and
matching the one or more packets to the match rule (Hande; [0098] “In block 1106, the UE may activate out-of-order delivery (OOOD) for the data from the wireless network that matches the one or more configuration parameters via the API. In some examples, the activating of out-of-order delivery for the data may include activating a Packet Data Convergence Protocol (PDCP) OOOD”. Rationale to combine is similar to claim 4).
Regarding claim 9, Wang-Huang-Hande discloses the method of claim 1, further comprising:
adjusting, by the processor, a modem forwarding policy for received packets responsive to a host setting up a virtual connection or a related filter with the local application-specific forwarding policy (Hande; [0090] “In block 1004, the API determines IP flows associated with either a default radio bearer or an application-provided dedicated radio bearer”, [0091] “In block 1006, the API may, alternately or in addition, determine IP flows associated with application-provided TFTs”, [0092] “In block 1008, the API may, alternately or in addition, determine IP flows associated with application provided QFIs on either a default RB or a dedicated RB”. Rationale to combine is similar to claim 4).
Regarding claim(s) 14-15 and 17-19, do(es) not teach or further define over the limitation in claim(s) 4-5 and 7-9 respectively. Therefore claim(s) 14-15 and 17-19 is/are rejected for the same rationale of rejection as set forth in claim(s) 4-5 and 7-9 respectively.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US 2023/0110709) in view of Huang et al. (US 2021/0051562) in view of Hande et al. (US 2022/0038955) in view of Huang et al. (US 2019/0313277), hereafter Huang’277.
Regarding claim 6, Wang-Huang-Hande discloses the invention substantially, however the prior art does not explicitly the method of claim 5, wherein the receiving of the request comprise receiving the request via an AT command.
Huang’277 in the field of the same endeavor discloses techniques related to AT commands for 5G session management (5GSM) operations and QoS management. In particular, Haung’277 discloses the following:
wherein the receiving of the request comprise receiving the request via an AT command (Huang’277 discloses configuration request involving packet filters/TFTs are received by modem via AT commands; [0027] “AT commands for modifying PDU sessions, creating and modifying QoS flows and rules, and for querying QoS flow and rule parameters are defined for 5G networks”).
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 Huang’277. One would have been motivated because AT commands are the standard 3GPP-defined TE-MT interface for this type of modem configuration (flow filters and related policies). This substitution of one known application to modem interface (API) for another known interface (AT command) yields the predictable results.
Regarding claim(s) 16, do(es) not teach or further define over the limitation in claim(s) 6 respectively. Therefore claim(s) 16 is/are rejected for the same rationale of rejection as set forth in claim(s) 6 respectively.
Allowable Subject Matter
Claims 10 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
For the reason above, claims 1-20 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
Prosecution Insights