DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In virtue of the Application filed on 01/27/2023, in which claims 1-20 are presented for examination, wherein claims 1, 6, 11, 16, are recited in independent form. The present Application claims priority to Foreign Applications KR10-2022-0012743 with a filing date of 01/27/2022 and KR10-2022-0182110 with a filing date of 12/22/2022 (certified copies received 03/29/2023).
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 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-4, 6-9, 11, 13, 15, 16, 18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication US 20230164631 to Me et al (hereinafter d1) in view of US Patent Application US 20230093435 to Huang et al (hereinafter d2).
Regarding claim 1, as to the limitations “A method performed by an application server (AS) for an extended reality (XR) service in a wireless communication system, the method comprising:” d1 discloses techniques in the field of wireless communication (see d1 para. 0001) implemented in a system (see d1 Fig. ) which comprises at least an Application Function (i.e. Application server) (see d1 para. 0066, Fig. 1), PCF (see d1 Fig. 1), Terminal (i.e. UE)(see d1 Fig. 1), NEF (see d1 Fig. 8) wherein the devices elements a transceiver; and a processor are at least obvious (see d1 Figs. 9-10) which are controlled to carry out signal flow charts (see d1 Figs. 6-8) embodying communication reflecting methods (see d1 Figs. 4- 8); incorporating at least XR implementation (see d1 para. 0087, 0090, 0100, 0142-0144, 0165);
as to the limitation “providing XR service-related information including the identification information and information about a delay time allowable for the XR service to the wireless communication system accessed by the at least one UE” d1 discloses in Fig. 4 steps 401 wherein a PCF receives request information. The request information is used to request to establish a first QoS flow for a terminal, the request information includes first indication information, and the first indication information is used to indicate to perform network coding on the first QoS flow. Implementation may include an SMF sends the request information to the PCF. Correspondingly, the PCF receives the request information from the SMF; wherein the terminal may send the request information to an AMF by using an access network device. After receiving the request information, the AMF sends the request information to the SMF. After receiving the request information, the SMF further sends the request information to the PCF. When enabling a service, the terminal may send the request information to the AMF, to establish a QoS flow (namely, the first QoS flow) corresponding to the service in which the terminal may trigger a PDU session modification (PDU session modification) procedure, and send the request information to the AMF in the PDU session modification procedure (see d1 para. 0092-0096). The implementation may also include a service server which generates the request information, and sends the request information to the PCF. Correspondingly, the PCF receives the request information from the service server wherein the service server is a service server of a service corresponding to the first QoS flow. In Manner 2, the service server may send the request information to the PCF by using an NEF. The service server may send the request information to the PCF when the service server needs to send downlink service data to the terminal or has established a service data flow connection to the terminal wherein the service server may trigger a PDU session modification procedure, and send the request information to the PCF in the PDU session modification procedure (see d1 para. 0091-0099). It is noted that in this embodiment of this application, the service (denoted as a first service) corresponding to the first QoS flow may be a high-reliability and/or low-delay service. The high-reliability service may be a service in which a packet loss rate is less than or equal to a first threshold or a quantity of lost packets in a time period of a specific length is less than or equal to a second threshold. The low-delay service may be a service whose delay is less than or equal to a third threshold. The first threshold, the second threshold, and the third threshold may be preset or specified in a protocol. This is not limited in this application. For example, the first threshold may be 0.1%, the second threshold may be 2, and the third threshold may be 10 ms. For example, the first service may be an XR service, a tactile internet service, or another service that requires high reliability and a low delay. Wherein the data flows have different reliability and rate requirements. Therefore, a core network maps different data flows to different QoS flows. For example, for the visual data flow, basic layer video and audio (based layer video and audio) data has relatively high delay and reliability requirements, and enhancement layer video (enhancement layer video) data has relatively low delay and reliability requirements. Therefore, referring to FIG. 5, if the terminal initiates a visual data service, the terminal may send request information 1. The request information 1 is used to request to establish a QoS flow 1, the QoS flow 1 is used to transmit basic layer video and audio data, the request information 1 includes first indication information, and the first indication information is used to indicate to perform network coding on the QoS flow 1. The terminal may further send request information 2. The request information 2 is used to request to establish a QoS flow 2, the QoS flow 2 is used to transmit enhancement layer video data, and the request information does not include information used to indicate to perform network coding on the QoS flow 2. The request information may include a QoS class identifier (QoS class identifier, QCI), and a QoS requirement of the first QoS flow may be indicated by using the QCI. The QCI may also indicate whether to perform network coding on the first QoS flow. For example, some QCIs may indicate to perform network coding on a QoS flow (for example, QCIs with some values may indicate to perform network coding on the QoS flow), and these QCIs may be newly defined QCIs (for example, some newly defined values of QCIs, where QCIs with these values may indicate to perform network coding on the QoS flow), or may be existing QCIs (for example, some existing values of QCIs, where QCIs with these values may indicate to perform network coding on the QoS flow). When a QCI does not indicate to perform network coding on the QoS flow, the request information may include information indicating whether to perform network coding on the first QoS flow. The information may be a parameter. When this parameter exists, it indicates that network coding is requested for the first QoS flow, and when this parameter does not exist, it indicates that network coding is not requested for the first QoS flow. Alternatively, the information may be 1 bit. When a value of the bit is 1, it indicates that network coding is requested for the first QoS flow, and when the value of the bit is 0, it indicates that network coding is not requested for the first QoS flow; or vice versa. When a QCI indicates to perform network coding on the QoS flow, the request information may not include information indicating to perform network coding on the first QoS flow (see d1 para. 100-0102). It is also noted that the request information further includes one or both of the following information: information about a type of network coding performed on the first QoS flow, or information about a protocol layer used to implement the type of network coding performed on the first QoS flow. Types of network coding in this application may include RLNC, BATS coding, fountain coding, and the like. There may be only one type of network coding performed on the first QoS flow, or there may be a plurality of types of network coding performed on the first QoS flow. A protocol layer used to implement the type of network coding may be a packet data convergence protocol (packet data convergence protocol, PDCP) layer, a radio link control (radio link control, RLC) layer, or another protocol layer. Because a lower protocol layer used to implement a type of network coding, flexibility is higher when the type of network coding is implemented, and therefore, the information may be used to select a type of network coding used by the terminal (see d1 para. 103-0104). Also relevant to the limitation d1 discloses that if the PCF receives the request information from the service server, optionally, the request information further includes one or more of the following information: address information of the terminal, address information of the service server, or an identifier of the terminal. The information may be used for downlink service data transmission in a subsequent process. Wherein The address information of the terminal may be at least one of an IP address, a port number, and the like of the terminal. The address information of the service server may be at least one of an IP address, a port number, a uniform resource locator (Uniform Resource Locator, URL), and the like of the service server. The identifier of the terminal may be a subscriber permanent identifier (subscriber permanent identifier, SUPI) (see d1 para. 0105-0107). Regarding providing to a network entity for a multi-modal service, policy information for the multi-modal service to be provided to one or more UE d1 provides relevant disclosure in reference to Fig. 4 including in step 402 wherein the PCF sends network coding information to a communication device based on the request information. The network coding information includes second indication information, and the second indication information is used to indicate a QoS flow on which network coding is to be performed. Correspondingly, the communication device receives the network coding information from the PCF. The communication device may include the access network device accessed by the terminal and/or the terminal. In step 403 he communication device performs network coding on the QoS flow indicated by the second indication information. Wherein a data transmission delay is reduced while transmission reliability of the QoS flow is improved. Wherein optionally, before step 402, the method further includes additional steps wherein the PCF determines the network coding information. If the PCF determines to perform network coding on the first QoS flow, the QoS flow indicated by the second indication information is the first QoS flow; or if the PCF determines not to perform network coding on the first QoS flow, the QoS flow indicated by the second indication information is a second QoS flow. The second QoS flow may be a QoS flow with a QoS parameter that is the same as or similar to that of the first QoS flow, to meet a service requirement of the first service. The QoS flow may have a plurality of QoS parameters, for example, a delay and a packet loss rate. Similar QoS flows may be two QoS flows whose QoS parameters are partially the same, for example, two QoS flows with a same delay and/or packet loss rate. Similar QoS flows may be alternatively two QoS flows whose difference of a same QoS parameter does not exceed a threshold. The threshold may be preset, predefined, specified in a protocol, or determined through negotiation between network elements. This is not limited in this application. For example, two QoS flows whose delay difference does not exceed 2 ms may be considered as similar QoS flows, or two QoS flows whose delay difference does not exceed 2 ms and/or whose packet loss rate difference does not exceed 0.1% may be considered as similar QoS flows (see d1 para. 0107-0114).
D1 also discloses Fig. 8 which suggests in step 801 that the AF sends an application service request (Application service request) to a PCF by using an NEF. The application service request may include request information. For related descriptions of the request information, refer to the foregoing descriptions. Details are not described again. During specific implementation, in step 801, the AF may send the application service request to the NEF, and the NFE may send the application service request to the PCF that manages a QoS flow of the terminal. In step 802 the PCF and an SMF perform a session management policy association modification procedure. Reference to Fig. 7 step 703 also provides additional detail. In step 803 the SMF indicates, through an N4 PDU session establishment (N4 PDU session establishment) procedure or an N4 PDU session modification (N4 PDU session modification) procedure, a UPF to configure a first QoS flow (for example, configure existing information such as a QCI) for the terminal. Correspondingly, the UPF configures the first QoS flow for the terminal according to the indication. In step 804 the SMF sends an N1N2 transfer message (Namf communication N1N2 message transfer) to an AMF. Correspondingly, the AMF receives the N1N2 transfer message from the SMF (see d1 para. 0166-0173).
d1 does not appear to explicitly allocating, to at least one user equipment (UE), identification information for identifying the at least one UE using a same XR service or for identifying at least one service flow (SF) for transferring XR data to each of the at least one UE; although the disclosure of d1 is particularly relevant to the limitation and may meet the requirements under a broadest reasonable interpretation, in order to provide the most complete and effective examination, attention is directed to d2 which, in a similar field of endeavor of wireless communication discloses XR service architecture wherein an XR device associated with a terminal device transmits a session request carrying and XR service identifier to an SMF for requesting establishment of a specific XR service and based on the received XR service identifier, the same SMF determines the requested XXR service and obtains a plurality of QoS flows of the requested XR service (see d2 Fig. 10 para. 0225-0249).
Regarding a motivation to combine d2 and d1, D2 also contains ample teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference of d1 by combining it with the disclosure of d2 to arrive at the claimed invention including to improve QoS in XR service (see d2 para. 0004). Wherein the teaching, suggestion, and/or motivation, is evident in references d1 and/or d2, as well as being found squarely within the knowledge generally available to one of ordinary skill in the art. One of ordinary skill in the art would look to modify d1 with the teaching of d2 in order to achieve the stated advantages of improved XR service. Furthermore, the techniques are employed in the same field of endeavor (Wireless Communication) in a similar manner (XR) for similar purposes (improved services) which would yield a reasonable expectation of success. one of ordinary skill in the art.
Regarding claim 2, as to the limitation “The method of claim 1, wherein the XR service-related information includes at least one of quality-of-service (QoS) information, scheduling information, and policy information to be applied to the XR service” d1 in view of d2 discloses extended reality (extended reality, XR) service that includes AR, VR, and mixed reality (mixed reality, MR) which includes data transmission characteristics of the XR service (see d1 para. 0087-0088; Tables 1-2) suggesting the limitations of the claims.
Regarding claim 3, as to the limitation “The method of claim 1, wherein the identification information includes an application function (AF) specific SF group ID, and wherein the XR service-related information includes at least one of an indicator indicating whether to support a multi-modality service for the at least one XR SF for the at least one UE belonging to the AF specific SF group ID or information about the allowable delay time required while transferring XR data of the at least one XR SF to the at least one UE” d1 in view of d2 discloses an identifier (i.e. an application function (AF) specific SF group ID) (see d1 para. 0079, 0106) and wherein the XR service-related information includes at least one of an indicator indicating whether to support a multi-modality service for the at least one XR SF for the at least one UE belonging to the AF specific SF group ID or information about the allowable delay time required while transferring XR data of the at least one XR SF to the at least one UE (see d1 Tables 1-2).
Regarding claim 4, as to the limitation “The method of claim 1, further comprising: providing XR SF detection information for detecting the at least one SF to the wireless communication system accessed by the at least one UE” d1 in view of d2 discloses providing XR SF detection information for detecting the at least one SF to the wireless communication system accessed by the at least one UE (see d1 para. 0074, 098, 0167-0168, Fig. 8).
Regarding claim 6, as to the limitations “An application server (AS) for an extended reality (XR) service in a wireless communication system, the AS comprising: a transceiver; and a processor configured to:” d1 discloses techniques in the field of wireless communication (see d1 para. 0001) implemented in a system (see d1 Fig. ) which comprises at least an Application Function (i.e. Application server) (see d1 para. 0066, Fig. 1), PCF (see d1 Fig. 1), Terminal (i.e. UE)(see d1 Fig. 1), NEF (see d1 Fig. 8) wherein the devices elements a transceiver; and a processor are at least obvious (see d1 Figs. 9-10) which are controlled to carry out signal flow charts (see d1 Figs. 6-8) embodying communication reflecting methods (see d1 Figs. 4- 8); incorporating at least XR implementation (see d1 para. 0087, 0090, 0100, 0142-0144, 0165);
as to the limitation “allocate, to at least one user equipment (UE), identification information for identifying the at least one UE using a same XR service or for identifying at least one service flow (SF) for transferring XR data to each of the at least one UE; and provide XR service-related information including the identification information and information about a delay time allowable for the XR service to the wireless communication system accessed by the at least one UE through the transceiver” d1 discloses in Fig. 4 steps 401 wherein a PCF receives request information. The request information is used to request to establish a first QoS flow for a terminal, the request information includes first indication information, and the first indication information is used to indicate to perform network coding on the first QoS flow. Implementation may include an SMF sends the request information to the PCF. Correspondingly, the PCF receives the request information from the SMF; wherein the terminal may send the request information to an AMF by using an access network device. After receiving the request information, the AMF sends the request information to the SMF. After receiving the request information, the SMF further sends the request information to the PCF. When enabling a service, the terminal may send the request information to the AMF, to establish a QoS flow (namely, the first QoS flow) corresponding to the service in which the terminal may trigger a PDU session modification (PDU session modification) procedure, and send the request information to the AMF in the PDU session modification procedure (see d1 para. 0092-0096). The implementation may also include a service server which generates the request information, and sends the request information to the PCF. Correspondingly, the PCF receives the request information from the service server wherein the service server is a service server of a service corresponding to the first QoS flow. In Manner 2, the service server may send the request information to the PCF by using an NEF. The service server may send the request information to the PCF when the service server needs to send downlink service data to the terminal or has established a service data flow connection to the terminal wherein the service server may trigger a PDU session modification procedure, and send the request information to the PCF in the PDU session modification procedure (see d1 para. 0091-0099). It is noted that in this embodiment of this application, the service (denoted as a first service) corresponding to the first QoS flow may be a high-reliability and/or low-delay service. The high-reliability service may be a service in which a packet loss rate is less than or equal to a first threshold or a quantity of lost packets in a time period of a specific length is less than or equal to a second threshold. The low-delay service may be a service whose delay is less than or equal to a third threshold. The first threshold, the second threshold, and the third threshold may be preset or specified in a protocol. This is not limited in this application. For example, the first threshold may be 0.1%, the second threshold may be 2, and the third threshold may be 10 ms. For example, the first service may be an XR service, a tactile internet service, or another service that requires high reliability and a low delay. Wherein the data flows have different reliability and rate requirements. Therefore, a core network maps different data flows to different QoS flows. For example, for the visual data flow, basic layer video and audio (based layer video and audio) data has relatively high delay and reliability requirements, and enhancement layer video (enhancement layer video) data has relatively low delay and reliability requirements. Therefore, referring to FIG. 5, if the terminal initiates a visual data service, the terminal may send request information 1. The request information 1 is used to request to establish a QoS flow 1, the QoS flow 1 is used to transmit basic layer video and audio data, the request information 1 includes first indication information, and the first indication information is used to indicate to perform network coding on the QoS flow 1. The terminal may further send request information 2. The request information 2 is used to request to establish a QoS flow 2, the QoS flow 2 is used to transmit enhancement layer video data, and the request information does not include information used to indicate to perform network coding on the QoS flow 2. The request information may include a QoS class identifier (QoS class identifier, QCI), and a QoS requirement of the first QoS flow may be indicated by using the QCI. The QCI may also indicate whether to perform network coding on the first QoS flow. For example, some QCIs may indicate to perform network coding on a QoS flow (for example, QCIs with some values may indicate to perform network coding on the QoS flow), and these QCIs may be newly defined QCIs (for example, some newly defined values of QCIs, where QCIs with these values may indicate to perform network coding on the QoS flow), or may be existing QCIs (for example, some existing values of QCIs, where QCIs with these values may indicate to perform network coding on the QoS flow). When a QCI does not indicate to perform network coding on the QoS flow, the request information may include information indicating whether to perform network coding on the first QoS flow. The information may be a parameter. When this parameter exists, it indicates that network coding is requested for the first QoS flow, and when this parameter does not exist, it indicates that network coding is not requested for the first QoS flow. Alternatively, the information may be 1 bit. When a value of the bit is 1, it indicates that network coding is requested for the first QoS flow, and when the value of the bit is 0, it indicates that network coding is not requested for the first QoS flow; or vice versa. When a QCI indicates to perform network coding on the QoS flow, the request information may not include information indicating to perform network coding on the first QoS flow (see d1 para. 100-0102). It is also noted that the request information further includes one or both of the following information: information about a type of network coding performed on the first QoS flow, or information about a protocol layer used to implement the type of network coding performed on the first QoS flow. Types of network coding in this application may include RLNC, BATS coding, fountain coding, and the like. There may be only one type of network coding performed on the first QoS flow, or there may be a plurality of types of network coding performed on the first QoS flow. A protocol layer used to implement the type of network coding may be a packet data convergence protocol (packet data convergence protocol, PDCP) layer, a radio link control (radio link control, RLC) layer, or another protocol layer. Because a lower protocol layer used to implement a type of network coding, flexibility is higher when the type of network coding is implemented, and therefore, the information may be used to select a type of network coding used by the terminal (see d1 para. 103-0104). Also relevant to the limitation d1 discloses that if the PCF receives the request information from the service server, optionally, the request information further includes one or more of the following information: address information of the terminal, address information of the service server, or an identifier of the terminal. The information may be used for downlink service data transmission in a subsequent process. Wherein The address information of the terminal may be at least one of an IP address, a port number, and the like of the terminal. The address information of the service server may be at least one of an IP address, a port number, a uniform resource locator (Uniform Resource Locator, URL), and the like of the service server. The identifier of the terminal may be a subscriber permanent identifier (subscriber permanent identifier, SUPI) (see d1 para. 0105-0107). Regarding providing to a network entity for a multi-modal service, policy information for the multi-modal service to be provided to one or more UE d1 provides relevant disclosure in reference to Fig. 4 including in step 402 wherein the PCF sends network coding information to a communication device based on the request information. The network coding information includes second indication information, and the second indication information is used to indicate a QoS flow on which network coding is to be performed. Correspondingly, the communication device receives the network coding information from the PCF. The communication device may include the access network device accessed by the terminal and/or the terminal. In step 403 he communication device performs network coding on the QoS flow indicated by the second indication information. Wherein a data transmission delay is reduced while transmission reliability of the QoS flow is improved. Wherein optionally, before step 402, the method further includes additional steps wherein the PCF determines the network coding information. If the PCF determines to perform network coding on the first QoS flow, the QoS flow indicated by the second indication information is the first QoS flow; or if the PCF determines not to perform network coding on the first QoS flow, the QoS flow indicated by the second indication information is a second QoS flow. The second QoS flow may be a QoS flow with a QoS parameter that is the same as or similar to that of the first QoS flow, to meet a service requirement of the first service. The QoS flow may have a plurality of QoS parameters, for example, a delay and a packet loss rate. Similar QoS flows may be two QoS flows whose QoS parameters are partially the same, for example, two QoS flows with a same delay and/or packet loss rate. Similar QoS flows may be alternatively two QoS flows whose difference of a same QoS parameter does not exceed a threshold. The threshold may be preset, predefined, specified in a protocol, or determined through negotiation between network elements. This is not limited in this application. For example, two QoS flows whose delay difference does not exceed 2 ms may be considered as similar QoS flows, or two QoS flows whose delay difference does not exceed 2 ms and/or whose packet loss rate difference does not exceed 0.1% may be considered as similar QoS flows (see d1 para. 0107-0114).
D1 also discloses Fig. 8 which suggests in step 801 that the AF sends an application service request (Application service request) to a PCF by using an NEF. The application service request may include request information. For related descriptions of the request information, refer to the foregoing descriptions. Details are not described again. During specific implementation, in step 801, the AF may send the application service request to the NEF, and the NFE may send the application service request to the PCF that manages a QoS flow of the terminal. In step 802 the PCF and an SMF perform a session management policy association modification procedure. Reference to Fig. 7 step 703 also provides additional detail. In step 803 the SMF indicates, through an N4 PDU session establishment (N4 PDU session establishment) procedure or an N4 PDU session modification (N4 PDU session modification) procedure, a UPF to configure a first QoS flow (for example, configure existing information such as a QCI) for the terminal. Correspondingly, the UPF configures the first QoS flow for the terminal according to the indication. In step 804 the SMF sends an N1N2 transfer message (Namf communication N1N2 message transfer) to an AMF. Correspondingly, the AMF receives the N1N2 transfer message from the SMF (see d1 para. 0166-0173).
d1 does not appear to explicitly allocating, to at least one user equipment (UE), identification information for identifying the at least one UE using a same XR service or for identifying at least one service flow (SF) for transferring XR data to each of the at least one UE; although the disclosure of d1 is particularly relevant to the limitation and may meet the requirements under a broadest reasonable interpretation, in order to provide the most complete and effective examination, attention is directed to d2 which, in a similar field of endeavor of wireless communication discloses XR service architecture wherein an XR device associated with a terminal device transmits a session request carrying and XR service identifier to an SMF for requesting establishment of a specific XR service and based on the received XR service identifier, the same SMF determines the requested XXR service and obtains a plurality of QoS flows of the requested XR service (see d2 Fig. 10 para. 0225-0249).
Regarding a motivation to combine d2 and d1, D2 also contains ample teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference of d1 by combining it with the disclosure of d2 to arrive at the claimed invention including to improve QoS in XR service (see d2 para. 0004). Wherein the teaching, suggestion, and/or motivation, is evident in references d1 and/or d2, as well as being found squarely within the knowledge generally available to one of ordinary skill in the art. One of ordinary skill in the art would look to modify d1 with the teaching of d2 in order to achieve the stated advantages of improved XR service. Furthermore, the techniques are employed in the same field of endeavor (Wireless Communication) in a similar manner (XR) for similar purposes (improved services) which would yield a reasonable expectation of success. one of ordinary skill in the art.
Regarding claim 7, as to the limitation “The AS of claim 6, wherein the XR service-related information includes at least one of quality-of-service (QoS) information, scheduling information, and policy information to be applied to the XR service” d1 in view of d2 discloses extended reality (extended reality, XR) service that includes AR, VR, and mixed reality (mixed reality, MR) which includes data transmission characteristics of the XR service (see d1 para. 0087-0088; Tables 1-2) suggesting the limitations of the claims.
Regarding claim 8, as to the limitation “The AS of claim 6, wherein the identification information includes an application function (AF) specific SF group ID, and wherein the XR service-related information includes at least one of an indicator indicating whether to support a multi-modality service for the at least one XR SF for the at least one UE belonging to the AF specific SF group ID or information about the allowable delay time required while transferring XR data of the at least one XR SF to the at least one UE” d1 in view of d2 discloses an identifier (i.e. an application function (AF) specific SF group ID) (see d1 para. 0079, 0106) and wherein the XR service-related information includes at least one of an indicator indicating whether to support a multi-modality service for the at least one XR SF for the at least one UE belonging to the AF specific SF group ID or information about the allowable delay time required while transferring XR data of the at least one XR SF to the at least one UE (see d1 Tables 1-2).
Regarding claim 9, as to the limitation “The AS of claim 6, wherein the processor is further configured to provide XR SF detection information for detecting the at least one SF to the wireless communication system accessed by the at least one UE, through the transceiver” d1 in view of d2 discloses providing XR SF detection information for detecting the at least one SF to the wireless communication system accessed by the at least one UE (see d1 para. 0074, 098, 0167-0168, Fig. 8).
Regarding claim 11, as to the limitations “A method performed by a policy control function (PCF) configured to manage policy information for an extended reality (XR) service in a wireless communication system, the method comprising:” d1 discloses techniques in the field of wireless communication (see d1 para. 0001) implemented in a system (see d1 Fig. ) which comprises at least an Application Function (i.e. Application server) (see d1 para. 0066, Fig. 1), PCF (see d1 Fig. 1), Terminal (i.e. UE)(see d1 Fig. 1), NEF (see d1 Fig. 8) wherein the devices elements a transceiver; and a processor are at least obvious (see d1 Figs. 9-10) which are controlled to carry out signal flow charts (see d1 Figs. 6-8) embodying communication reflecting methods (see d1 Figs. 4- 8); incorporating at least XR implementation (see d1 para. 0087, 0090, 0100, 0142-0144, 0165);
as to the limitation “receiving, from an application server (AS) configured to provide XR service through a network exposure function (NEF), a first message including identification information, the identification information for identifying at least one user equipment (UE) using a same XR service or identifying at least one service flow (SF) for transferring XR data to each of the at least one UE, and first XR service-related information including quality-of-service (QoS) information related to at least one SF based on the identification information; and transmitting a second message including second XR service-related information, which is based on the first XR service-related information, and the identification information to a session management function (SMF) configured to manage a protocol data unit (PDU) session related to the XR service” d1 discloses in Fig. 4 steps 401 wherein a PCF receives request information. The request information is used to request to establish a first QoS flow for a terminal, the request information includes first indication information, and the first indication information is used to indicate to perform network coding on the first QoS flow. Implementation may include an SMF sends the request information to the PCF. Correspondingly, the PCF receives the request information from the SMF; wherein the terminal may send the request information to an AMF by using an access network device. After receiving the request information, the AMF sends the request information to the SMF. After receiving the request information, the SMF further sends the request information to the PCF. When enabling a service, the terminal may send the request information to the AMF, to establish a QoS flow (namely, the first QoS flow) corresponding to the service in which the terminal may trigger a PDU session modification (PDU session modification) procedure, and send the request information to the AMF in the PDU session modification procedure (see d1 para. 0092-0096). The implementation may also include a service server which generates the request information, and sends the request information to the PCF. Correspondingly, the PCF receives the request information from the service server wherein the service server is a service server of a service corresponding to the first QoS flow. In Manner 2, the service server may send the request information to the PCF by using an NEF. The service server may send the request information to the PCF when the service server needs to send downlink service data to the terminal or has established a service data flow connection to the terminal wherein the service server may trigger a PDU session modification procedure, and send the request information to the PCF in the PDU session modification procedure (see d1 para. 0091-0099). It is noted that in this embodiment of this application, the service (denoted as a first service) corresponding to the first QoS flow may be a high-reliability and/or low-delay service. The high-reliability service may be a service in which a packet loss rate is less than or equal to a first threshold or a quantity of lost packets in a time period of a specific length is less than or equal to a second threshold. The low-delay service may be a service whose delay is less than or equal to a third threshold. The first threshold, the second threshold, and the third threshold may be preset or specified in a protocol. This is not limited in this application. For example, the first threshold may be 0.1%, the second threshold may be 2, and the third threshold may be 10 ms. For example, the first service may be an XR service, a tactile internet service, or another service that requires high reliability and a low delay. Wherein the data flows have different reliability and rate requirements. Therefore, a core network maps different data flows to different QoS flows. For example, for the visual data flow, basic layer video and audio (based layer video and audio) data has relatively high delay and reliability requirements, and enhancement layer video (enhancement layer video) data has relatively low delay and reliability requirements. Therefore, referring to FIG. 5, if the terminal initiates a visual data service, the terminal may send request information 1. The request information 1 is used to request to establish a QoS flow 1, the QoS flow 1 is used to transmit basic layer video and audio data, the request information 1 includes first indication information, and the first indication information is used to indicate to perform network coding on the QoS flow 1. The terminal may further send request information 2. The request information 2 is used to request to establish a QoS flow 2, the QoS flow 2 is used to transmit enhancement layer video data, and the request information does not include information used to indicate to perform network coding on the QoS flow 2. The request information may include a QoS class identifier (QoS class identifier, QCI), and a QoS requirement of the first QoS flow may be indicated by using the QCI. The QCI may also indicate whether to perform network coding on the first QoS flow. For example, some QCIs may indicate to perform network coding on a QoS flow (for example, QCIs with some values may indicate to perform network coding on the QoS flow), and these QCIs may be newly defined QCIs (for example, some newly defined values of QCIs, where QCIs with these values may indicate to perform network coding on the QoS flow), or may be existing QCIs (for example, some existing values of QCIs, where QCIs with these values may indicate to perform network coding on the QoS flow). When a QCI does not indicate to perform network coding on the QoS flow, the request information may include information indicating whether to perform network coding on the first QoS flow. The information may be a parameter. When this parameter exists, it indicates that network coding is requested for the first QoS flow, and when this parameter does not exist, it indicates that network coding is not requested for the first QoS flow. Alternatively, the information may be 1 bit. When a value of the bit is 1, it indicates that network coding is requested for the first QoS flow, and when the value of the bit is 0, it indicates that network coding is not requested for the first QoS flow; or vice versa. When a QCI indicates to perform network coding on the QoS flow, the request information may not include information indicating to perform network coding on the first QoS flow (see d1 para. 100-0102). It is also noted that the request information further includes one or both of the following information: information about a type of network coding performed on the first QoS flow, or information about a protocol layer used to implement the type of network coding performed on the first QoS flow. Types of network coding in this application may include RLNC, BATS coding, fountain coding, and the like. There may be only one type of network coding performed on the first QoS flow, or there may be a plurality of types of network coding performed on the first QoS flow. A protocol layer used to implement the type of network coding may be a packet data convergence protocol (packet data convergence protocol, PDCP) layer, a radio link control (radio link control, RLC) layer, or another protocol layer. Because a lower protocol layer used to implement a type of network coding, flexibility is higher when the type of network coding is implemented, and therefore, the information may be used to select a type of network coding used by the terminal (see d1 para. 103-0104). Also relevant to the limitation d1 discloses that if the PCF receives the request information from the service server, optionally, the request information further includes one or more of the following information: address information of the terminal, address information of the service server, or an identifier of the terminal. The information may be used for downlink service data transmission in a subsequent process. Wherein The address information of the terminal may be at least one of an IP address, a port number, and the like of the terminal. The address information of the service server may be at least one of an IP address, a port number, a uniform resource locator (Uniform Resource Locator, URL), and the like of the service server. The identifier of the terminal may be a subscriber permanent identifier (subscriber permanent identifier, SUPI) (see d1 para. 0105-0107). Regarding providing to a network entity for a multi-modal service, policy information for the multi-modal service to be provided to one or more UE d1 provides relevant disclosure in reference to Fig. 4 including in step 402 wherein the PCF sends network coding information to a communication device based on the request information. The network coding information includes second indication information, and the second indication information is used to indicate a QoS flow on which network coding is to be performed. Correspondingly, the communication device receives the network coding information from the PCF. The communication device may include the access network device accessed by the terminal and/or the terminal. In step 403 he communication device performs network coding on the QoS flow indicated by the second indication information. Wherein a data transmission delay is reduced while transmission reliability of the QoS flow is improved. Wherein optionally, before step 402, the method further includes additional steps wherein the PCF determines the network coding information. If the PCF determines to perform network coding on the first QoS flow, the QoS flow indicated by the second indication information is the first QoS flow; or if the PCF determines not to perform network coding on the first QoS flow, the QoS flow indicated by the second indication information is a second QoS flow. The second QoS flow may be a QoS flow with a QoS parameter that is the same as or similar to that of the first QoS flow, to meet a service requirement of the first service. The QoS flow may have a plurality of QoS parameters, for example, a delay and a packet loss rate. Similar QoS flows may be two QoS flows whose QoS parameters are partially the same, for example, two QoS flows with a same delay and/or packet loss rate. Similar QoS flows may be alternatively two QoS flows whose difference of a same QoS parameter does not exceed a threshold. The threshold may be preset, predefined, specified in a protocol, or determined through negotiation between network elements. This is not limited in this application. For example, two QoS flows whose delay difference does not exceed 2 ms may be considered as similar QoS flows, or two QoS flows whose delay difference does not exceed 2 ms and/or whose packet loss rate difference does not exceed 0.1% may be considered as similar QoS flows (see d1 para. 0107-0114).
D1 also discloses Fig. 8 which suggests in step 801 that the AF sends an application service request (Application service request) to a PCF by using an NEF. The application service request may include request information. For related descriptions of the request information, refer to the foregoing descriptions. Details are not described again. During specific implementation, in step 801, the AF may send the application service request to the NEF, and the NFE may send the application service request to the PCF that manages a QoS flow of the terminal. In step 802 the PCF and an SMF perform a session management policy association modification procedure. Reference to Fig. 7 step 703 also provides additional detail. In step 803 the SMF indicates, through an N4 PDU session establishment (N4 PDU session establishment) procedure or an N4 PDU session modification (N4 PDU session modification) procedure, a UPF to configure a first QoS flow (for example, configure existing information such as a QCI) for the terminal. Correspondingly, the UPF configures the first QoS flow for the terminal according to the indication. In step 804 the SMF sends an N1N2 transfer message (Namf communication N1N2 message transfer) to an AMF. Correspondingly, the AMF receives the N1N2 transfer message from the SMF (see d1 para. 0166-0173).
d1 does not appear to explicitly allocating, to at least one user equipment (UE), identification information for identifying the at least one UE using a same XR service or for identifying at least one service flow (SF) for transferring XR data to each of the at least one UE; although the disclosure of d1 is particularly relevant to the limitation and may meet the requirements under a broadest reasonable interpretation, in order to provide the most complete and effective examination, attention is directed to d2 which, in a similar field of endeavor of wireless communication discloses XR service architecture wherein an XR device associated with a terminal device transmits a session request carrying and XR service identifier to an SMF for requesting establishment of a specific XR service and based on the received XR service identifier, the same SMF determines the requested XXR service and obtains a plurality of QoS flows of the requested XR service (see d2 Fig. 10 para. 0225-0249).
Regarding a motivation to combine d2 and d1, D2 also contains ample teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference of d1 by combining it with the disclosure of d2 to arrive at the claimed invention including to improve QoS in XR service (see d2 p