DETAILED ACTION
In response to communications filed 12/02/2025.
Claims 1-32 are pending for 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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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, 7, 8, 9, 12, 18, 19, 20, 23, 27, 28, 30, 31 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al. (US 2021/0337619 A1) in view of Salem et al. (US 2021/0044529 A1) hereinafter “Zhang” and “Salem” respectively.
Regarding Claim 1, Zhang teaches A method for a user equipment (UE) (Zhang: paragraphs 0048, 0060 & Figs. 1-3, communication device or user equipment (UE)) to communicate with a wireless network (Zhang: paragraph 0051 & Figs 1-2, network), comprising:
set one or more configuration parameters from the wireless network (Zhang: paragraph 0085, receiving from a network entity a configuration message including a parameter specifying out-of-order delivery of data units from lower layers to upper layers of a protocol stack implemented on the UE);
identifying the data received from the wireless network that matches the one or more configuration parameters set (Zhang: paragraphs 0123-0126, where UE is configured to determine a configuration of the RLC layer for out-of-order delivery of packets to the PDCP layer based on the received message or configuration parameter); and
selectively activating out-of-order delivery (OOOD) to an upper layer for the data received from the wireless network (Zhang: paragraph 0099-0102, out-of-order delivery of data packets to upper layers) that matches the one or more configuration parameters set (Zhang: paragraphs 0099, 0103 & 0105, UE may choose to enable OutOfOrderDelivery (OOOD) based on indicated parameter received in configuration message).
Although Zhang teaches a user equipment receiving configuration information to enable or choose OutOfOrderDelivery based on a parameter received in a configuration message, Zhang fails to explicitly teach executing an application programming interface (API) in the UE to set the one or more configuration parameters for selectively activating said OOOD. However, Salem from an analogous art similarly teaches out-of-order delivery of packets based on quality or latency requirements (Salem: paragraphs 0022 & 0028) and further teaches executing an API from an application of a user equipment to indicate target quality of service requirements for delivery of said packets (Salem: paragraphs 0079-0080).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang to include an API in the UE as taught by Salem so as to allow further communications of data between different applications and/or services within the network
Regarding Claim 7, Zhang-Salem teaches the respective claim(s) as presented above and further teaches wherein the activating out-of-order delivery for the data comprises activating a Packet Data Convergence Protocol (PDCP) OOOD (Zhang: paragraphs 0103-0106, PDCP out-of-order delivery).
Regarding Claim 8, Zhang-Salem teaches the respective claim(s) as presented above and further teaches wherein the activating out-of-order delivery for the data comprises using a first flag indicating OOOD activation follows a wireless network configuration (Zhang: paragraphs 0103-0104, an OOD parameter indicating configuration of NR PDCP layer for out-of-order delivery of data packets).
Regarding Claim 9, Zhang teaches the respective claim(s) as presented above and further teaches wherein the activating out-of-order delivery for the data comprises using a second flag indicating OOOD activation follows configuration provided by the API (Zhang: paragraph 0101, OutOfOrderDelivery may be set to “true” to indicate the configuration). Examiner recites same reasoning to combine Zhang-Salem as presented in rejected claim 1.
Regarding Claim 12, Zhang teaches A user equipment (UE) (Zhang: paragraphs 0048, 0060 & Figs. 1-3, communication device or user equipment (UE)) in a wireless communication network (Zhang: paragraph 0051 & Figs 1-2, network), comprising:
a wireless transceiver (Zhang: paragraph 0062 & Fig. 3, communication circuitry));
a memory (Zhang: paragraph 0066 & Fig. 3, memory); and
a processor communicatively coupled to the wireless transceiver and the memory (Zhang: 0066 & Fig. 3, processor(s) coupled to memory), wherein the processor and the memory are configured to
set one or more configuration parameters from the wireless network (Zhang: paragraph 0085, receiving from a network entity a configuration message including a parameter specifying out-of-order delivery of data units from lower layers to upper layers of a protocol stack implemented on the UE);
identify the data received from the wireless network that matches the one or more configuration parameters set (Zhang: paragraphs 0123-0126, where UE is configured to determine a configuration of the RLC layer for out-of-order delivery of packets to the PDCP layer based on the received message or configuration parameter); and
selectively activating out-of-order delivery (OOOD) to an upper layer for the data received from the wireless network (Zhang: paragraph 0099-0102, out-of-order delivery of data packets to upper layers) that matches the one or more configuration parameters set (Zhang: paragraphs 0099, 0103 & 0105, UE may choose to enable OutOfOrderDelivery (OOOD) based on indicated parameter received in configuration message).
Although Zhang teaches a user equipment receiving configuration information to enable or choose OutOfOrderDelivery based on a parameter received in a configuration message, Zhang fails to explicitly teach executing an application programming interface (API) in the UE to set the one or more configuration parameters for selectively activating said OOOD. However, Salem from an analogous art similarly teaches out-of-order delivery of packets based on quality or latency requirements (Salem: paragraphs 0022 & 0028) and further teaches executing an API from an application of a user equipment to indicate target quality of service requirements for delivery of said packets (Salem: paragraphs 0079-0080).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang to include an API in the UE as taught by Salem so as to allow further communications of data between different applications and/or services within the network
Regarding Claim 18, Zhang-Salem teaches the respective claim(s) as presented above and further teaches activate out-of-order delivery for data by activating a Packet Data Convergence Protocol (PDCP) OOOD (Zhang: paragraphs 0103-0106, PDCP out-of-order delivery).
Regarding Claim 19, Zhang-Salem teaches the respective claim(s) as presented above and further teaches activate out-of-order delivery for data by using a first flag indicating OOOD activation follows a wireless network configuration (Zhang: paragraphs 0103-0104, an OOD parameter indicating configuration of NR PDCP layer for out-of-order delivery of data packets).
Regarding Claim 20, Zhang-Salem teaches the respective claim(s) as presented above and further teaches activate out-of-order delivery for data by using a second flag indicating OOOD activation follows configuration provided by the API (Zhang: paragraph 0101, OutOfOrderDelivery may be set to “true” to indicate the configuration). Examiner recites same reasoning to combine Zhang-Salem as presented in rejected claim 12.
Regarding Claim 23, Zhang teaches A user equipment (UE) (Zhang: paragraphs 0048, 0060 & Figs. 1-3, communication device or user equipment (UE)) in a wireless network (Zhang: paragraph 0051 & Figs 1-2, network), comprising:
means for setting one or more configuration parameters from the wireless network (Zhang: paragraph 0085, receiving from a network entity a configuration message including a parameter specifying out-of-order delivery of data units from lower layers to upper layers of a protocol stack implemented on the UE);
means for identifying the data received from the wireless network that matches the one or more configuration parameters set (Zhang: paragraphs 0123-0126, where UE is configured to determine a configuration of the RLC layer for out-of-order delivery of packets to the PDCP layer based on the received message or configuration parameter); and
means for selectively activating out-of-order delivery (OOOD) to an upper layer for the data received from the wireless network (Zhang: paragraph 0099-0102, out-of-order delivery of data packets to upper layers) that matches the one or more configuration parameters set (Zhang: paragraphs 0099, 0103 & 0105, UE may choose to enable OutOfOrderDelivery (OOOD) based on indicated parameter received in configuration message).
Although Zhang teaches a user equipment receiving configuration information to enable or choose OutOfOrderDelivery based on a parameter received in a configuration message, Zhang fails to explicitly teach executing an application programming interface (API) in the UE to set the one or more configuration parameters for selectively activating said OOOD. However, Salem from an analogous art similarly teaches out-of-order delivery of packets based on quality or latency requirements (Salem: paragraphs 0022 & 0028) and further teaches executing an API from an application of a user equipment to indicate target quality of service requirements for delivery of said packets (Salem: paragraphs 0079-0080).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang to include an API in the UE as taught by Salem so as to allow further communications of data between different applications and/or services within the network
Regarding Claim 27, Zhang-Salem teaches the respective claim(s) as presented above and further teaches means for activating a Packet Data Convergence Protocol (PDCP) OOOD (Zhang: paragraphs 0103-0106, PDCP out-of-order delivery).
Regarding Claim 28, Zhang-Salem teaches the respective claim(s) as presented above and further teaches means for using a first flag indicating OOOD activation follows a wireless network configuration (Zhang: paragraphs 0103-0104, an OOD parameter indicating configuration of NR PDCP layer for out-of-order delivery of data packets).
Regarding Claim 30, Zhang teaches A non-transitory computer-readable medium (Zhang: paragraph 0068, non-transitory computer-readable memory medium) having stored therein instructions executable by one or more processors (Zhang: paragraph 0068, executing program instructions stored on a memory medium) of a user equipment (UE) (Zhang: paragraphs 0048, 0060 & Figs. 1-3, communication device or user equipment (UE)) in a wireless communication network (Zhang: paragraph 0051 & Figs 1-2, network) to:
set one or more configuration parameters from the wireless network (Zhang: paragraph 0085, receiving from a network entity a configuration message including a parameter specifying out-of-order delivery of data units from lower layers to upper layers of a protocol stack implemented on the UE);
identify the data received from the wireless network that matches the one or more configuration parameters set (via the API) (Zhang: paragraphs 0123-0126, where UE is configured to determine a configuration of the RLC layer for out-of-order delivery of packets to the PDCP layer based on the received message or configuration parameter); and
selectively activating out-of-order delivery (OOOD) to an upper layer for the data received from the wireless network (Zhang: paragraph 0099-0102, out-of-order delivery of data packets to upper layers) that matches the one or more configuration parameters set (via the API) (Zhang: paragraphs 0099, 0103 & 0105, UE may choose to enable OutOfOrderDelivery (OOOD) based on indicated parameter received in configuration message).
Although Zhang teaches a user equipment receiving configuration information to enable or choose OutOfOrderDelivery based on a parameter received in a configuration message, Zhang fails to explicitly teach executing an application programming interface (API) in the UE to set the one or more configuration parameters for selectively activating said OOOD. However, Salem from an analogous art similarly teaches out-of-order delivery of packets based on quality or latency requirements (Salem: paragraphs 0022 & 0028) and further teaches executing an API from an application of a user equipment to indicate target quality of service requirements for delivery of said packets (Salem: paragraphs 0079-0080).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang to include an API in the UE as taught by Salem so as to allow further communications of data between different applications and/or services within the network.
Regarding Claim 31, Zhang-Salem teaches the respective claim(s) as presented above and further teaches the one or more configuration parameters indicating whether a wireless network out-of-order delivery (OOOD) configuration or a UE-side OOOD configuration is to be used (Zhang: paragraph 0085, receiving from a network entity a configuration message including a parameter specifying out-of-order delivery); and
wherein selectively activating OOOD to an upper layer comprises using one of the wireless network OOOD configuration or the UE-side OOOD configuration (Zhang: paragraphs 0099, 0103 & 0105, UE may choose to enable OutOfOrderDelivery (OOOD) based on indicated parameter received in configuration message).
Regarding Claim 32, Zhang-Salem teaches the respective claim(s) as presented above and further teaches the one or more configuration parameters indicating whether a wireless network out-of-order delivery (OOOD) configuration or a UE-side OOOD configuration is to be used (Zhang: paragraph 0085, receiving from a network entity a configuration message including a parameter specifying out-of-order delivery); and
wherein selectively activating OOOD to an upper layer comprises using one of the wireless network OOOD configuration or the UE-side OOOD configuration (Zhang: paragraphs 0099, 0103 & 0105, UE may choose to enable OutOfOrderDelivery (OOOD) based on indicated parameter received in configuration message).
Claims 2, 3, 4, 5, 6, 13, 14, 15, 16, 17, 24, 25 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang-Salem in view of Callard et al. (US 2018/0098241 A1) hereinafter “Callard.”
Regarding Claim 2, Zhang-Salem teaches the respective claim(s) as presented above however fails to teach the following limitation(s). Callard from an analogous art similarly teaches not in-order delivery of packets (Callard: paragraphs 0041-0042) and
further teaches identifying one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters (Callard: paragraph 0041 & Fig.2, flow identifier used to identify the PDSCP PDU with an associated transmission flow). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to identify flows of traffic as taught by Callard so as to allow OOOD of specific flows of data within the network.
Regarding Claim 3, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches wherein the identifying the one or more IP flows comprises measuring the one or more IP flows from a default resource bearer provided by the wireless network (Callard: paragraph 0042, mapping PDCP PDU to a particular data radio bearer (DRB) configured to provide not in-order delivery of the packets, thus teaching a default resource bearer). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 2.
Regarding Claim 4, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches wherein the identifying the one or more IP flows comprises identifying all of the one or more IP flows sharing an API-provided resource bearer (Callard: paragraph 0042, mapping PDCP PDU to a particular data radio bearer (DRB) configured to provide not in-order delivery of the packets). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 2.
Regarding Claim 5, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches wherein the identifying the one or more IP flows comprises measuring the one or more IP flows associated with one or more API-provided traffic flow templates (TFTs) (Callard: paragraph 0086, different traffic flow templates (TFTs). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 2.
Regarding Claim 6, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches wherein the identifying the one or more IP flows comprises 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 (Callard: paragraph 0055, quality of service flow ID QoS flow ID indicates quality of service that is required for a particular flow). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 2.
Regarding Claim 13, Zhang-Salem teaches the respective claim(s) as presented above however fails to teach the following limitation(s). Callard from an analogous art similarly teaches not in-order delivery of packets (Callard: paragraphs 0041-0042) and further teaches identify one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters (Callard: paragraph 0041 & Fig.2, flow identifier used to identify the PDSCP PDU with an associated transmission flow). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to identify flows of traffic as taught by Callard so as to allow OOOD of specific flows of data within the network.
Regarding Claim 14, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches identify the one or more IP flows comprises measuring the one or more IP flows from a default resource bearer provided by the wireless network (Callard: paragraph 0042, mapping PDCP PDU to a particular data radio bearer (DRB) configured to provide not in-order delivery of the packets, thus teaching a default resource bearer). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 13.
Regarding Claim 15, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches identify the one or more IP flows by identifying all of the one or more IP flows sharing an API-provided resource bearer (Callard: paragraph 0042, mapping PDCP PDU to a particular data radio bearer (DRB) configured to provide not in-order delivery of the packets). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 13.
Regarding Claim 16, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches identify the one or more IP flows by measuring the one or more IP flows associated with one or more API-provided traffic flow templates (TFTs) (Callard: paragraph 0086, different traffic flow templates (TFTs). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 13.
Regarding Claim 17, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches identify the one or more IP flows by 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 (Callard: paragraph 0055, quality of service flow ID QoS flow ID indicates quality of service that is required for a particular flow). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 13.
Regarding Claim 24, Zhang-Salem teaches the respective claim(s) as presented above however fails to teach the following limitation(s). Callard from an analogous art similarly teaches not in-order delivery of packets (Callard: paragraphs 0041-0042) and further teaches means for identifying one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters (Callard: paragraph 0041 & Fig.2, flow identifier used to identify the PDSCP PDU with an associated transmission flow). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to identify flows of traffic as taught by Callard so as to allow OOOD of specific flows of data within the network.
Regarding Claim 25, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches means for measuring the one or more IP flows from a default resource bearer provided by the wireless network (Callard: paragraph 0042, mapping PDCP PDU to a particular data radio bearer (DRB) configured to provide not in-order delivery of the packets, thus teaching a default resource bearer). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 24.
Regarding Claim 26, Zhang-Salem-Callard teaches the respective claim(s) as presented above and further teaches means for 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 (Callard: paragraph 0055, quality of service flow ID QoS flow ID indicates quality of service that is required for a particular flow). Examiner recites same reasoning to combine Zhang-Salem-Callard as presented in rejected claim 24.
Claims 10 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang-Salem in view of Wang et al. (US 2019/0268801 A1) hereinafter “Wang.”
Regarding Claim 10, Zhang-Salem teaches the respective claim(s) as presented above however fails to explicitly teach deactivating OOOD in response to a downlink transport control protocol (TCP) throughput on a bearer meeting or exceeding a configured threshold. However, Wang from an analogous art similarly teaches out-of-order packet handling (Wang: paragraph 0009) specifically teaches the counter-based triggering of buffering content can be disabled based on a threshold (Wang: paragraph 0022-0023) therefore similarly teaching OOOD deactivation or disabling based on a bearing meeting a configured threshold.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to include a bearer threshold to deactivate OOOD as taught by Wang so as to ensure OOOD based on available bandwidth and/or resources.
Regarding Claim 29, Zhang-Salem teaches the respective claim(s) as presented above however fails to explicitly teach means for deactivating OOOD in response to a downlink transport control protocol (TCP) throughput on a bearer meeting or exceeding a configured threshold. However, Wang from an analogous art similarly teaches out-of-order packet handling (Wang: paragraph 0009) specifically teaches the counter-based triggering of buffering content can be disabled based on a threshold (Wang: paragraph 0022-0023) therefore similarly teaching OOOD deactivation or disabling based on a bearing meeting a configured threshold.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to include a bearer threshold to deactivate OOOD as taught by Wang so as to ensure OOOD based on available bandwidth and/or resources.
Claims 11, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang-Salem in view of Li et al. (US 2020/0374237 A1) hereinafter “Li.”
Regarding Claim 11, Zhang-Salem teaches the respective claim(s) as presented above however fails to explicitly teach deactivating OOOD in response to a number of duplicate downlink transport control protocol (TCP) acknowledgements (ACKs) meeting or exceeding a configured threshold. However, Li from an analogous art similarly teaches out-of-order delivery (Li: paragraph 0013) and further teaches in-order delivery is performed based on QoS flow including a transmission control protocol (Transmission Control Protocol, TCP) flow (Li: paragraph 0098).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to include deactivating OOOD as taught by Li so as to ensure OOOD based on available bandwidth and/or resources.
Regarding Claim 21, Zhang-Salem teaches the respective claim(s) as presented above however fails to explicitly teach determine if a number of duplicate TCP ACKs meets or exceeds a configured threshold (Salem: paragraph 0078, determine if target is exceeded). However, Li from an analogous art similarly teaches out-of-order delivery (Li: paragraph 0013) and further teaches in-order delivery is performed based on QoS flow including a transmission control protocol (Transmission Control Protocol, TCP) flow (Li: paragraph 0098).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to include deactivating OOOD as taught by Li so as to ensure OOOD based on available bandwidth and/or resources.
Regarding Claim 22, Zhang-Salem teaches the respective claim(s) as presented above however fails to explicitly teach deactivate OOOD in response to a number of duplicate downlink transport control protocol (TCP) acknowledgements (ACKs) meeting or exceeding a configured threshold. However, Li from an analogous art similarly teaches out-of-order delivery (Li: paragraph 0013) and further teaches in-order delivery is performed based on QoS flow including a transmission control protocol (Transmission Control Protocol, TCP) flow (Li: paragraph 0098).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang-Salem to include deactivating OOOD as taught by Li so as to ensure OOOD based on available bandwidth and/or resources.
Response to Amendment
Paragraphs 0074-0084, 0096-0099 and Figs. 5-8 of the instant specification discloses the structure and the acts performed by those structures, which correspond to the means-plus-function features of claims 23-29.
Response to Arguments
Applicant’s arguments:
a) Zhang-Salem alone or in combination fails to teach and/or suggest the UE selectively activating out-of-order delivery since the OOOD is initiated by a network configuration message to configure the UE in some embodiments and the feature of a UE to choose to enable and/or disable the OutOfOrderDelivery feature is unclear and/or is not relevant to the claimed subject matter and (remarks, page 9)
b) Zhang alone or in combination fails to teach selectively activating OOOD that matches one or more configuration parameters set via an API since Zhang fails to mention any API (remarks, pages 10-13).
c) Salem similarly fails to teach selectively activating OOOD that matches one or more configuration parameters set via an API since Salem fails to teach selectively activating OOOD (remarks, pages 10-11).
Examiner’s response:
Applicant's arguments filed 12/02/2025 have been fully considered but they are not persuasive.
Regarding argument a), Examiner respectfully disagrees with the assessment that the OutOfOrderDelivery feature to is irrelevant to the claimed subject matter as argued. Zhang teaches an LTE RLC layer may re-assemble and delivery RLC SDUs out of an RLC PDU that may not have been fully received and/or is out of order and if an out-of-order delivery configuration is enabled, then an RLC AM downlink layer may not attempt to reassemble any RLC SDUs or deliver any RLC SDUs to upper layers (Zhang: paragraphs 0113-0114). As stated in the previous Office Action, Zhang teaches a user equipment may be configured for out-of-order delivery of data packets from lower layers to upper layers (e.g., the UE may be configured to bypass standard LTE re-ordering functionality and in-order delivery guarantee at the RLC layer) and may further choose to enable and/or disable an “OutOfOrderDelivery” feature (Zhang: paragraphs 0099 & 0101-0103). Examiner notes since the delivery and/or reassembly of data packets in-order or out-of-order is contingent on whether said out-of-order delivery configuration or “OutOfOrderDelivery” feature is enabled at the UE, Zhang teaches selectively enabling and/or activating out-of-order-delivery for delivering out-of-order data packets to an upper layer based on the obtained configuration parameters.
Regarding arguments b & c), Examiner first notes the prior art of Salem and not Zhang is relied upon to specifically teach executing an application programming interface (API) in the UE to set the one or more configuration parameters. Salem is not being used as a reference to support the feature of selectively activating of OOOD to an upper layer which is taught by Zhang in the rejection. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091,231 USPQ 375 (Fed. Cir. 1986). That being stated, as previously presented, Salem similarly teaches out-of-order delivery of packets based on quality or latency requirements (Salem: paragraphs 0022 & 0028) and further teaches executing an API from an application of a user equipment to indicate target quality of service requirements for delivery of said packets (Salem: paragraphs 0079-0080). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zhang to include an API in the UE as taught by Salem so as to allow further communications of data between different applications and/or services within the network.
Therefore, the rejection(s) of claims 1, 12 and 23 is maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 NAJEEB ANSARI whose telephone number is (571)270-5446. The examiner can normally be reached Monday-Friday 10am to 2pm.
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, ASAD NAWAZ can be reached at 469-295-9193. 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.
/NAJEEB ANSARI/Examiner, Art Unit 2463
/ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463