DETAILED ACTION
This office action is in response to the amendments filed on 06/04/2026.
Claims 1-17 are cancelled.
Claims 18, 23, 24, are amended.
Claims 18-33 are presented 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 .
Response to Arguments
Applicant’s arguments, see Remarks pg. 5, filed 06/04/2026, with respect to 35 USC 112 (f) interpretation have been fully considered and are persuasive. The 35 USC 112 (f) interpretation has been withdrawn.
Applicant's arguments filed 06/04/2026 regarding 35 USC 102 and 35 USC 103 rejections in Remarks pg. 5-8 have been fully considered but they are not persuasive.
Applicant argues in essence:
[a] “However, Applicant respectfully disagrees with the Examiner's characterization of Park. While Park generally discloses processing user plane data based on PDU session and QoS-related configuration information, Park does not disclose processing user plane data in units of a PDU set as now required by amended claim 18. Nor do the additional references remedy this deficiency.
As amended, claim 18 requires processing user plane data in units of a PDU set based on PDU set information included in radio resource configuration information, wherein the PDU set comprises one or more PDUs carrying a payload of one unit of information generated at an application level.
Thus, the amended claim is directed to application-aware processing in which a plurality of PDUs carrying payload data associated with one unit of information generated at an application level are treated as a single processing unit. The claimed processing is therefore performed at a PDU set granularity rather than at a packet, bearer, QoS flow, or PDU session granularity. Park fails to disclose or suggest such processing.”
In response to [a], examiner respectfully disagrees. Applicant argues that the claims now require the processing of a plurality of PDUs as a single processing unit, however the claims recite “wherein the PDU set comprises one or more PDUs carrying a payload of one unit of information generated at an application level.”. Therefore under broadest reasonable interpretation, the claim still reads on a single PDU comprising the PDU set, and Park discloses the packets being that of an application layer of the UE.
Park para.0153 “Packets may arrive from and/or destined to the application/service layer 2030 of wireless device 2000, CN_UP 2020, and/or an AF (e.g., the AF 1545). QoS flow may be granular of QoS differentiation in a PDU session.”
Therefore examiner maintains the Park reference as the PDU set may still be a single PDU.
[b] “Specifically, the Examiner relies on paragraphs [0215]-[0218] of Park, which describe PDU session configuration parameters, QoS flow identifiers, QoS parameters, and bearer configurations used for establishing and managing PDU sessions and associated radio bearers.
For example, paragraph [0215] describes configuration parameters associated with a PDU session, while paragraphs [0217] and [0218] describe establishment and management of PDU sessions, QoS flows, and associated bearers based on those parameters. These disclosures are directed to network-layer connectivity and QoS management mechanisms. The processing described in Park is performed with respect to PDU sessions, QoS flows, and bearers, which are network communication constructs.
In contrast, amended claim 18 requires processing based on a PDU set that is defined according to an application-level information unit. The claimed PDU set is not merely a QoS flow, bearer, or PDU session. Rather, it represents a collection of one or more PDUs carrying a payload of one unit of information generated at an application level.
Nothing in paragraphs [0215]-[0218], or elsewhere in Park, discloses grouping multiple PDUs that carry a payload of one unit of information generated at an application level. Furthermore, Park does not disclose PDU set information identifying such a grouping, nor any processing operation performed using such PDU set information.”
In response to [b], examiner respectfully disagrees. As stated above, the PDU set of the claim is one or more PDUs, that is, the PDU set may be a single PDU. Further, Park discloses processing of a single packet such as in para.0342 below, in response to a configuration received by the UE. In this case, compression parameters may be received, and individual packets are operated, i.e. PDU set of a single PDU. Therefore, as the claim under its broadest reasonable interpretation reads on a single PDU, Park is relied upon for the rejection.
Park: Para.0191 “ The two RLC PDUs from the RB may each correspond to one Ethernet frame and/or IP packet (e.g., n and/or n+1).”
Park: para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type. At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.). The one or more Ethernet frames may comprise a MAC address of the wireless device 3410. The wireless device 3410 may compress headers of the one or more Ethernet frames (e.g., based on header compression parameters indicated in the RRC message).”
[c] “Accordingly, even if Park discloses processing user plane data based on PDU session parameters, QoS flow parameters, or bearer configurations, such processing is fundamentally different from the claimed processing performed in units of a PDU set corresponding to one unit of information generated at an application level.
The additional references cited by the Examiner likewise do not disclose or suggest the foregoing application-level PDU set concept or processing at a PDU set granularity. Accordingly, even when the cited references are combined, they fail to teach or suggest the subject matter of amended claim 18.”
In response to [c], examiner respectfully disagrees. The process of Park is not fundamentally different to this concept. Park receives an RRC message that modifies PDUs at the UE in at least para.0341 and step 3403 in Fig. 34, and in step 3404 processes a PDU generated at the application level. Chen is further relied upon to show the radio resource configuration information being that of a protocol data unit set information, i.e. discard information associated with the PDUs. Therefore, examiner maintains reliance of Park reference in the rejection as set forth below.
Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.”
para.0153 “Packets may arrive from and/or destined to the application/service layer 2030 of wireless device 2000, CN_UP 2020, and/or an AF (e.g., the AF 1545). QoS flow may be granular of QoS differentiation in a PDU session.”
para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type. At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.). The one or more Ethernet frames may comprise a MAC address of the wireless device 3410. The wireless device 3410 may compress headers of the one or more Ethernet frames (e.g., based on header compression parameters indicated in the RRC message).”
Claim Objections
Claim 32 is objected to because of the following informalities:
Claim 32 recites in part “wherein the controller..discards all”, however claim 28 no longer recites a controller via amendment. This should be corrected to “wherein the processor..discards all”
Appropriate correction is required.
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.
Claim(s) 18, 24, 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Chen et al. (hereinafter Chen, US 2019/0254117 A1).
Regarding Claim 18, Park discloses A method for processing an application data flow by a user equipment (UE) (Park: para.0152 “ The 5GC may be able to trigger a specific application in the wireless device 1500 (e.g., after a request from an application server). If receiving that trigger message, the wireless device 1500 may pass it to the identified application in the wireless device 1500. The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” Processing application data by a wireless device in a PDU session), the method comprising:
receiving a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.” radio resource configuration information associated with assistance information is obtained, that is each of the configuration parameters are information used to configure the radio resource. Examiner notes that the higher layer message can be an RRC message in para.0119 of applicant’s specification “the higher layer message may be an RRC message”, para.0107 defined a PDU set as “(A PDU Set is composed of one or more PDUs…” and para.0115 shows that the assistance information within the radio resource configuration information may be traffic characteristics “radio resource configuration information may include at least one of assistance
information for an application traffic characteristic”, in this case QoS information and channel information.);
configuring the radio resource configuration information in the UE (Park: para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type” parameters of the UE are configured based on the obtained information in RRC message.); and
distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information (Park: para.0152 “The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message).” para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type. At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.). The one or more Ethernet frames may comprise a MAC address of the wireless device 3410. The wireless device 3410 may compress headers of the one or more Ethernet frames (e.g., based on header compression parameters indicated in the RRC message).” fig. 34 is a process for a PDU session, and as seen in para.0152 the PDU session may be for a the data of a particular application. User plane data of Application data, the frames that are sent to the user plane core network entity, are processed in view of the RRC message and transmitted, for example at least headers are modified. See also para.0298, and para.0334 “The target base station 3340 may employ the wireless device configuration information and/or wireless device capability information of the wireless device 3310 to properly configure wireless device configuration and/or one or more bearer configurations (e.g., PDU session configurations, QoS flow configurations) before the wireless device 3310 connects to the target base station 3340.” Examiner notes that the PDU set as defined in the claim may be a single PDU.);
wherein the PDU set comprises one or more PDUs carrying a payload of one unit of information generated at an application level (Park: para.0153 “Packets may arrive from and/or destined to the application/service layer 2030 of wireless device 2000, CN_UP 2020, and/or an AF (e.g., the AF 1545). QoS flow may be granular of QoS differentiation in a PDU session.” Para.0259 “ The data network connection may comprise Ethernet frames transmitted at step 2804, from the wireless device 2810 to the base station 2815 via the Ethernet type PDU session. At step 2805, the Ethernet frames may be forwarded from the base station 2815 to the AMF/SMF 2820 and/or to the UPF 2825 via the Ethernet type PDU session.” Para.0151 “The 5GC may support a PDU connectivity service that provides exchange of PDUs between a wireless device 1500 and a data network identified by a DNN.” A PDU session is created between the UE and a destination, wherein PDUs, i.e. one or more PDUs, are transmitted at the application layer).
However Park does not explicitly disclose distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information.
Chen discloses receiving a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Chen: para.0163 “Once the RLC entity receives the first or new PDCP PDU discard timer information from the upper layer, the duplicated PDCP PDU that is not delivered to the RLC entity may apply the PDCP PDU discard timer. The value of the PDCP PDU discard timer may be determined based on the received discard timer information (e.g., indicated by a Discard Timer Index or a Discard Timer Value).” Para.0043 “In the following, the PDCP duplication operation for the case of two RLC entities (e.g., the UE is configured with two RLC entities) is introduced for brevity, but it should be noted that implementations of the present disclosure may be also applicable for the more than two RLC entities cases (e.g., the UE is configured with more than two RLC entities).”The RLC of the UE obtains radio resource configuration information of a PDU discard timer index or value, that is used to configure the radio resource configuration of the pdu discard timer. This is associated with pdu set information as the discard timer is used for PDUs.)
distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information (Chen: para.0178 “For example, the PDCP Control PDU 1500 containing the duplication assistance information is shown in FIG. 15. When the UE receives the PDCP Control PDU containing the duplication assistance information, the UE may apply the PDCP PDU discard timer to the duplicated PDCP PDU(s) for the associated RLC entity indicated by the P/S field. For example, if the P/S field is set for the primary RLC entity, the duplicated PDCP PDU in the buffer of the primary RLC entity may be discarded when the associated PDCP PDU discard timer expires and/or the duplicated PDCP PDU is still in the buffer of the primary RLC entity.” The PDU discard timer is used, that is based on the discard timer index, to process user plane data, para.0083 “user plane PDCP data pdu”.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate receiving a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information; distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
Regarding Claim 24 Park discloses A method for processing an application data flow by a base station (Park: para.0341 first base station 3420), the method comprising: transmitting, to a user equipment (UE), a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.” radio resource configuration information associated with assistance information is sent by the base station to the UE, that is each of the configuration parameters are information used to configure the radio resource. Examiner notes that the higher layer message can be an RRC message in para.0119 of applicant’s specification “the higher layer message may be an RRC message”, para.0107 defined a PDU set as “(A PDU Set is composed of one or more PDUs…” and para.0115 shows that the assistance information within the radio resource configuration information may be traffic characteristics “radio resource configuration information may include at least one of assistance information for an application traffic characteristic”, in this case QoS information and channel information.); and
distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information (Park: para.0342 “ At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.).” para.0357 “ At step 3612, the base station may transmit an RRC message comprising bearer configuration parameters for the PDU session. At step 3615, the base station may transmit and/or receive packets of the PDU session.” Para.0358 “At step 3621, the base station may transmit an RRC message comprising bearer configuration parameters for the Ethernet type PDU session. At step 3624, the base station may transmit and/or receive (e.g., from the wireless device) Ethernet frames of the Ethernet type PDU session. The Ethernet frames may comprised compressed headers comprising source and/or destination MAC addresses.” Based on the radio resource configuration information sent by the base station in Fig. 36 3612/3621 or Fig. 34 3402 that is configured on the UE side for modifying and sending over the PDUs, user plane data PDU frames that are received via ethernet PDU session or PDU session are processed. Examiner notes that the PDU set as defined in the claim may be a single PDU.).
wherein the PDU set comprises one or more PDUs carrying a payload of one unit of information generated at an application level (Park: para.0153 “Packets may arrive from and/or destined to the application/service layer 2030 of wireless device 2000, CN_UP 2020, and/or an AF (e.g., the AF 1545). QoS flow may be granular of QoS differentiation in a PDU session.” Para.0259 “ The data network connection may comprise Ethernet frames transmitted at step 2804, from the wireless device 2810 to the base station 2815 via the Ethernet type PDU session. At step 2805, the Ethernet frames may be forwarded from the base station 2815 to the AMF/SMF 2820 and/or to the UPF 2825 via the Ethernet type PDU session.” Para.0151 “The 5GC may support a PDU connectivity service that provides exchange of PDUs between a wireless device 1500 and a data network identified by a DNN.” A PDU session is created between the UE and a destination, wherein PDUs, i.e. one or more PDUs, are transmitted at the application layer).
However Park does not explicitly disclose distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information.
Chen discloses transmitting, to a user equipment (UE), a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Chen: para.0163 “Once the RLC entity receives the first or new PDCP PDU discard timer information from the upper layer, the duplicated PDCP PDU that is not delivered to the RLC entity may apply the PDCP PDU discard timer. The value of the PDCP PDU discard timer may be determined based on the received discard timer information (e.g., indicated by a Discard Timer Index or a Discard Timer Value).” Para.0043 “In the following, the PDCP duplication operation for the case of two RLC entities (e.g., the UE is configured with two RLC entities) is introduced for brevity, but it should be noted that implementations of the present disclosure may be also applicable for the more than two RLC entities cases (e.g., the UE is configured with more than two RLC entities).” The RLC of the UE obtains radio resource configuration information of a PDU discard timer index or value, that is used to configure the radio resource configuration of the pdu discard timer. This is associated with pdu set information as the discard timer is used for PDUs.)
distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information (Chen: para.0178 “For example, the PDCP Control PDU 1500 containing the duplication assistance information is shown in FIG. 15. When the UE receives the PDCP Control PDU containing the duplication assistance information, the UE may apply the PDCP PDU discard timer to the duplicated PDCP PDU(s) for the associated RLC entity indicated by the P/S field. For example, if the P/S field is set for the primary RLC entity, the duplicated PDCP PDU in the buffer of the primary RLC entity may be discarded when the associated PDCP PDU discard timer expires and/or the duplicated PDCP PDU is still in the buffer of the primary RLC entity.” The PDU discard timer is used, that is based on the discard timer index, to process user plane data, para.0083 “user plane PDCP data pdu”.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate transmitting, to a user equipment (UE), a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information; distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
Regarding Claim 28, Park discloses A user equipment (UE) processing an application data flow (Park: para.0152 “ The 5GC may be able to trigger a specific application in the wireless device 1500 (e.g., after a request from an application server). If receiving that trigger message, the wireless device 1500 may pass it to the identified application in the wireless device 1500. The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” Processing application data by a wireless device in a PDU session), comprising:
a receiver (Park: Fig. 4 communication interface 407) configured to receive a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.” radio resource configuration information associated with assistance information is obtained, that is each of the configuration parameters are information used to configure the radio resource. Examiner notes that the higher layer message can be an RRC message in para.0119 of applicant’s specification “the higher layer message may be an RRC message”, para.0107 defined a PDU set as “(A PDU Set is composed of one or more PDUs…” and para.0115 shows that the assistance information within the radio resource configuration information may be traffic characteristics “radio resource configuration information may include at least one of assistance information for an application traffic characteristic”, in this case QoS information and channel information.); and
a processor (Park: Fig. 4 processor 408) configured to configure the radio resource configuration information in the UE (Park: para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type” parameters of the UE are configured based on the obtained information in RRC message.) and
distinctly processing user plane data of application data in units of PDU set based on the radio resource configuration information (Park: para.0152 “The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message).” para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type. At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.). The one or more Ethernet frames may comprise a MAC address of the wireless device 3410. The wireless device 3410 may compress headers of the one or more Ethernet frames (e.g., based on header compression parameters indicated in the RRC message).” fig. 34 is a process for a PDU session, and as seen in para.0152 the PDU session may be for a the data of a particular application. User plane data of Application data, the frames that are sent to the user plane core network entity, are processed in view of the RRC message and transmitted, for example at leas headers are modified. See also para.0298, and para.0334 “The target base station 3340 may employ the wireless device configuration information and/or wireless device capability information of the wireless device 3310 to properly configure wireless device configuration and/or one or more bearer configurations (e.g., PDU session configurations, QoS flow configurations) before the wireless device 3310 connects to the target base station 3340.” Examiner notes that the PDU set as defined in the claim may be a single PDU.).
wherein the PDU set comprises one or more PDUs carrying a payload of one unit of information generated at an application level (Park: para.0153 “Packets may arrive from and/or destined to the application/service layer 2030 of wireless device 2000, CN_UP 2020, and/or an AF (e.g., the AF 1545). QoS flow may be granular of QoS differentiation in a PDU session.” Para.0259 “ The data network connection may comprise Ethernet frames transmitted at step 2804, from the wireless device 2810 to the base station 2815 via the Ethernet type PDU session. At step 2805, the Ethernet frames may be forwarded from the base station 2815 to the AMF/SMF 2820 and/or to the UPF 2825 via the Ethernet type PDU session.” Para.0151 “The 5GC may support a PDU connectivity service that provides exchange of PDUs between a wireless device 1500 and a data network identified by a DNN.” A PDU session is created between the UE and a destination, wherein PDUs, i.e. one or more PDUs, are transmitted at the application layer).
However Park does not explicitly disclose distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information.
Chen discloses receive a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Chen: para.0163 “Once the RLC entity receives the first or new PDCP PDU discard timer information from the upper layer, the duplicated PDCP PDU that is not delivered to the RLC entity may apply the PDCP PDU discard timer. The value of the PDCP PDU discard timer may be determined based on the received discard timer information (e.g., indicated by a Discard Timer Index or a Discard Timer Value).” Para.0043 “In the following, the PDCP duplication operation for the case of two RLC entities (e.g., the UE is configured with two RLC entities) is introduced for brevity, but it should be noted that implementations of the present disclosure may be also applicable for the more than two RLC entities cases (e.g., the UE is configured with more than two RLC entities).”The RLC of the UE obtains radio resource configuration information of a PDU discard timer index or value, that is used to configure the radio resource configuration of the pdu discard timer. This is associated with pdu set information as the discard timer is used for PDUs.)
distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information (Chen: para.0178 “For example, the PDCP Control PDU 1500 containing the duplication assistance information is shown in FIG. 15. When the UE receives the PDCP Control PDU containing the duplication assistance information, the UE may apply the PDCP PDU discard timer to the duplicated PDCP PDU(s) for the associated RLC entity indicated by the P/S field. For example, if the P/S field is set for the primary RLC entity, the duplicated PDCP PDU in the buffer of the primary RLC entity may be discarded when the associated PDCP PDU discard timer expires and/or the duplicated PDCP PDU is still in the buffer of the primary RLC entity.” The PDU discard timer is used, that is based on the discard timer index, to process user plane data, para.0083 “user plane PDCP data pdu”.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate receive a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information; distinctly processing user plane data of application data in units of a PDU set based on the radio resource configuration information associated with the PDU set information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
Claim(s) 19-21, 25-27, 29-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Chen et al. (hereinafter Chen, US 2019/0254117 A1) further in view of Sharma et al. (hereinafter Sharma, US 2021/0227422 A1).
Regarding Claim 19, Park-Chen discloses claim 18 as set forth above.
However Park-Chen does not explicitly disclose wherein the PDU set information includes at least one of a PDU Set sequence number, PDU Set end PDU indication information, and PDU Set importance information.
Sharma discloses wherein the PDU set information includes at least one of a PDU Set sequence number, PDU Set end PDU indication information, and PDU Set importance information (Sharma: para.0134 “At step 632 the PDCP entity 452 starts a PDCP discard timer in respect of the newly formed second PDCP PDU 418. Reflecting the determination at step 606 that the received second PDCP SDU 416 which forms the second PDCP PDU 418 is associated with the higher priority, the PDCP discard timer is started with a second duration, which is longer than the first duration which would have been assigned to the PDCP discard timer to a PDCP PDU not having the higher priority, as described above in step 616.” The discard timers are set based on priority of each PDU, that is, the radio resource configuration information is associated with pdu set importance information.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Park-Chen with Sharma in order to incorporate wherein the PDU set information includes at least one of a PDU Set sequence number, PDU Set end PDU indication information, and PDU Set importance information, and apply this concept to the discard timers sent in Chen, such that the discard timers are associated with PDU importance.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of prioritizing data such that data delivery is not degraded or reduced (Sharma: para.0068).
Regarding Claim 20, Park-Chen discloses Claim 18 as set forth above.
However Park does not explicitly disclose wherein the radio resource configuration information includes at least one of PDU set discard configuration indication information and discard timer information according to a PDU set importance.
Chen discloses wherein the radio resource configuration information includes at least one of PDU set discard configuration indication information and discard timer information (Chen: para.0163 “Once the RLC entity receives the first or new PDCP PDU discard timer information from the upper layer, the duplicated PDCP PDU that is not delivered to the RLC entity may apply the PDCP PDU discard timer. The value of the PDCP PDU discard timer may be determined based on the received discard timer information (e.g., indicated by a Discard Timer Index or a Discard Timer Value).” Para.0043 “In the following, the PDCP duplication operation for the case of two RLC entities (e.g., the UE is configured with two RLC entities) is introduced for brevity, but it should be noted that implementations of the present disclosure may be also applicable for the more than two RLC entities cases (e.g., the UE is configured with more than two RLC entities).” The RLC of the UE obtains radio resource configuration information of a PDU discard timer).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate wherein the radio resource configuration information includes at least one of PDU set discard configuration indication information and discard timer information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
However Park-Chen does not explicitly disclose PDU set discard configuration indication information and discard timer information according to a PDU set importance.
Sharma discloses PDU set discard configuration indication information and discard timer information according to a PDU set importance (Sharma: para.0134 “At step 632 the PDCP entity 452 starts a PDCP discard timer in respect of the newly formed second PDCP PDU 418. Reflecting the determination at step 606 that the received second PDCP SDU 416 which forms the second PDCP PDU 418 is associated with the higher priority, the PDCP discard timer is started with a second duration, which is longer than the first duration which would have been assigned to the PDCP discard timer to a PDCP PDU not having the higher priority, as described above in step 616.” The discard timers are set based on priority of each PDU).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Park-Chen with Sharma in order to incorporate PDU set discard configuration indication information and discard timer information according to a PDU set importance, and apply this concept to the discard timers sent in Chen.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of prioritizing data such that data delivery is not degraded or reduced (Sharma: para.0068).
Regarding Claim 21, Park-Chen-Sharma discloses claim 20 as set forth above.
However Park does not explicitly disclose wherein the PDU set discard configuration identification information is configured in association with a data radio bearer.
Chen discloses wherein the PDU set discard configuration identification information is configured in association with a data radio bearer (Chen: para.0164 “In some implementations, the PDCP PDU discard timer may have different values for different radio bearers (e.g., DRBs). In some implementations, the value of the PDCP PDU discard timer may be different when the PDCP duplication function is activated or deactivated for a certain radio bearer.” The discard timer may be set based on the radio bearer.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate wherein the PDU set discard configuration identification information is configured in association with a data radio bearer.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
Regarding Claims 25-27, 29-31, they do not teach nor further define over the limitations of claims 19-21, therefore the supporting rationale for the rejections to claims 19-21 apply equally as well to that of claims 25-27, 29-31.
Claim(s) 22, 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Chen et al. (hereinafter Chen, US 2019/0254117 A1) in view of Chun et al. (hereinafter Chun, US 2012/0195276 A1).
Regarding Claim 22, Park-Chen discloses claim 18 as set forth above.
However Park-Chen does not explicitly disclose wherein distinctly processing, if a packet data convergence protocol (PDCP) discard timer or a discard timer according to a PDU set importance expires for one PDCP service data unit (SDU), discards all PDCP service data units (SDUs) included in the PDU set information to which the one PDCP SDU belongs, along with a PDCP PDU in a PDCP entity.
Chun discloses wherein distinctly processing, if a packet data convergence protocol (PDCP) discard timer or a discard timer according to a PDU set importance (Chun: para.0070 “ In addition, the timer expiration time can be set flexibly according to data type since not all IP packets or PDCP PDUs have the same importance.” Discard timer set based on importance.) expires for one PDCP service data unit (SDU), discards all PDCP service data units (SDUs) included in the PDU set information (Chun: para.0061 “Specifically, the RLC transmitting side constructs a RLC PDU by segmenting and concatenating RLC SDUs received from an upper entity so as to match a MAC PDU size (i.e., a RLC PDU size) indicated by a lower entity. A header of a RLC PDU includes information associated with segmentation, concatenation or the like of RLC SDUs.” The PDU header comprises information regarding set of SDU that comprise the PDU) to which the one PDCP SDU belongs, along with a PDCP PDU in a PDCP entity (Chun: para.0066 “The timer can also run commonly for a specific number of PDCP SDUs or a specific group of PDCP SDUs. For example, when a specific number of related PDCP SDUs or a specific group of PDCP SDUs is present, the timer can run only for the first PDCP SDU.” Para.0068 “When the timer expires while the PDCP entity has not received any notification of whether or not the PDCP PDU has been successfully transmitted from the RLC entity, the PDCP entity can decide to discard a PDCP SDU associated with the timer.” Para.0071 “Preferably, the PDCP entity discards the PDCP PDU associated with the PDCP SDU together with the PDCP SDU.” The discard timer is set for a group of related SDUs in view of the first SDU of the group. When the timer expires, the group of SDUs and associated PDU are discarded.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Park-Chen with Chun in order to incorporate wherein distinctly processing, if a packet data convergence protocol (PDCP) discard timer or a discard timer according to a PDU set importance expires for one PDCP service data unit (SDU), discards all PDCP service data units (SDUs) included in the PDU set information to which the one PDCP SDU belongs, along with a PDCP PDU in a PDCP entity.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving QoS of a wireless mobile communication system (Chun: para.0009).
Regarding Claim 32 it does not teach nor further define over the limitations of claim 22, therefore the supporting rationale for the rejection to claim 22 applies equally as well to that of claim 32.
Claim(s) 23, 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Chen et al. (hereinafter Chen, US 2019/0254117 A1) in view of Deng (US 2023/0262793 A1).
Regarding Claim 23, Park-Chen disclose claim 18 as set forth above.
However Park-Chen does not explicitly disclose wherein the assistance information includes a PDU set delay budget parameter received from a core network node.
Deng discloses wherein the assistance information includes a PDU set delay budget parameter received from a core network node (Deng: para.0257 “Step 404: the SMF sends the determined Uu PDB to be sent to the relay UE to the relay UE.” para.0260 “ It should be noted that the Uu PDB in the embodiment of the disclosure is the communication delay of the communication between the relay UE and the UPF through the Uu interface, and is also understood as the upper limit of the packet transmission delay of the communication between the relay UE and the UPF. That is, the relay UE sends the received high-level data packet (PDU) to the UPF by means of packet within the packet transmission delay determined by the Uu PDB, and the UPF sends the received high-level data packet (PDU) to the relay UE by means of packet within the packet transmission delay determined by the Uu PDB, to achieve the purpose of communicating between the relay UE and the core network. That is to say, the Uu PDB in the embodiment of the disclosure is the communication delay directed at the high-level data packet.” The UE receives from the SMF, a core network entity, a delay budget parameter UU PDB, and PDUs are sent according to this delay budget. Examiner notes that a packet delay budget is a delay budget parameter in applicants specification para.0162 “PDU-Set level Packet Delay Budget”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park-Chen and Deng in order to incorporate wherein the assistance information includes a PDU set delay budget parameter received from a core network node.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved QoS in communication within a network (Deng: para.0003).
Regarding Claim 33, it does not teach nor further define over the limitations of claim 23, therefore the supporting rationale for the rejection to claim 23 applies equally as well that of claim 33.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Luo et al. US 2025/0330876 A1 see abstract, para.0030 and para.0068, wherein the PDU set information includes discard timer for the PDU set, sent to the UPF.
Xiao et al. US 2016/0352643 A1 see para.0003 for PDU and SDU discard based on discard timer.
Xu et al. US 2021/0051611 A1 see para.0115 PDCP PDU using discard timer between UE and base station.
Baek et al. US 2023/0309100 A1, para.0079, and para.0007 showing pdu operations for XR data.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached at 5712725863. 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.
/EUI H KIM/ Examiner, Art Unit 2453
/KAMAL B DIVECHA/ Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights