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 .
DETAILED ACTION
2. This action is in response to the amendment filed January 16, 2026.
3. Claim 1 has been amended.
4. Claims 1-2, 4-11, and 13-18 have been examined and are pending with this action.
Response to Arguments
5. Applicant’s arguments, filed January 16, 2026, with respect to the rejection of claims 1-2 and 4-9, previously rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, have been fully considered and are persuasive in view of the amendments to claim 1. The rejection of claims 1-2 and 4-9 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, has been withdrawn.
Applicant’s arguments with respect to claim(s) 1-2, 4-11, and 13-18, previously rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Park et al. (US 2023/0097726 A1), have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Although the examiner has applied Park in the past and agreed with past arguments presented by the applicant(s), with ongoing analysis of the application and references, the examiner believes Park is still applicable and relative as to the teachings of the presently recited pending claimed limitations. Without acquiescing and in the interest of expediting prosecution, Xu et al. (US 2022/0124595 A1) has been cited to better teach the pending claim limitations.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
6. Claims 1-2, 5-11, and 14-18 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Xu et al. (US 2022/0124595 A1).
INDEPENDENT:
As per claims 1, Xu teaches a method of User Equipment (UE) Route Selection Policy (URSP) rule matching, comprising:
receiving a request from upper layers for protocol data unit (PDU) session information of the UE in a mobile communication network (see Xu, [0004]: “When there is application data to be transmitted, the terminal device can use a parameter in an RSD to transmit a PDU session establishment request message to a network device.”; and [0054]: “When an application data stream with a TD appears, the terminal device can select a parameter combination according to component values in a corresponding RSD, and initiate a PDU session establishment request to the network device via the parameter combination.”);
selecting a URSP rule from one or more URSP rules, wherein a traffic descriptor of the selected URSP rule matches with an application information (see Xu, [0057]: “A scheme in which the terminal device associates, based on the URSP, an application to a corresponding PDU session for transmission is as follows. When data appears at an application layer, the terminal device uses the URSP rules in the URSP to check whether features of the application data match a TD in one URSP rule, and the order of checking can be determined according to a precedence of each TD in each URSP rule, that is, the terminal device checks matching in the precedence order of the TDs. When the application data matches one URSP rule, an RSD list in the URSP rule is used to perform PDU session binding.”; and [0062]: “The terminal device first checks whether a currently established PDU session is established via a valid RSD parameter in the matching URSP rule, and if any, bind the matching application data to the PDU session for transmission.”);
selecting a route selection descriptor (RSD) from a list of RSDs of the selected URSP rule that matches an existing PDU session, wherein the existing PDU session has a list of requested parameters and a list of stored parameters, and wherein the existing PDU session is selected when matches are found either in the list of requested parameters of the existing PDU session or in the list of stored parameters of the existing PDU session, and wherein values for the list of requested parameters are obtained during PDU session establishment from a UL NAS TRANSPORT message or a PDU SESSION ESTABLISHMENT REQUEST message (see Xu, [0004]: “When there is application data to be transmitted, the terminal device can use a parameter in an RSD to transmit a PDU session establishment request message to a network device.”; [0056]: “Certainly, if the parameter combination selected can match a PDU session established, the terminal device can bind application data to the PDU session, that is, the terminal device can transmit the application data via the PDU session.”; [0063]: “If not, the terminal device can establish a PDU session in a precedence order of valid RSDs. Parameters in an RSD with a highest precedence are first used to establish a PDU session. If a certain parameter in the RSD has one or more values, the terminal device selects one value from the value or values of the parameter and combines the selected value and another parameter to perform PDU session establishment.”; [0087]: “A value of the first parameter is a value of a parameter in an RSD in a URSP rule that matches the first application data stream.”; [0114]: “When the UE detects a new data stream (a target address is 10.10.10.10), the UE can check whether the new data stream can match a URSP rule in the precedence order of the URSP rules (a URSP rule with a lower precedence being preferentially checked). Here, the new data stream matches the URSP rule-1, where a target address in a traffic descriptor in the URSP rule-1 is 10.10.10.10. Then the UE checks whether all RSDs in the URSP rule-1 have corresponding established PDU sessions, that is, checks whether parameter combinations in the RSD-1 and the RSD-2 have corresponding established PDU sessions, where the precedence of the RSD-1 is higher than that of the RSD-2. If the parameter combinations in the RSD-1 and the RSD-2 have corresponding established PDU sessions, bind the data stream to one of the established PDU sessions, i.e., the terminal device binds the data stream to one established PDU session.”; and [0149]: “The terminal device can store information of the RSD unsatisfying the cause-parameter condition that is determined according to the cause parameter, for example, the RSD may be stored as the invalid RSD, or the RSD satisfying the cause-parameter condition or an RSD parameter satisfying the cause-parameter condition can be stored as the valid RSD for the next evaluation.”); and
associating the existing PDU session with the application and providing the existing PDU session information to the upper layers, wherein the match is determined when either the list of requested parameters or the list of stored parameters of the existing PDU session matches corresponding parameters of the RSD (see Xu, [0003]: “The URSP policy determines a binding relationship between application data and a protocol data unit (PDU) session, and also determines what PDU session a terminal device shall establish to transmit the application data.”; [0053]: “The terminal device can select a route for an application according to at least one URSP rule, that is, bind different applications to sessions with different attribute parameters for data transmission.”; [0057]: “When the application data matches one URSP rule, an RSD list in the URSP rule is used to perform PDU session binding.”; and [0062]: “The terminal device first checks whether a currently established PDU session is established via a valid RSD parameter in the matching URSP rule, and if any, bind the matching application data to the PDU session for transmission.”).
As per claims 10, Xu teaches a User Equipment (UE), comprising:
upper layer entities that request protocol data unit (PDU) session information, wherein the upper layer entities trigger UE Route Selection Policy (URSP) rule matching for an application (see Claim 1 rejection above);
a URSP rule matching circuit that selects a URSP rule from one or more URSP rules, wherein a traffic descriptor of the selected URSP rule matches with the application information (see Claim 1 rejection above);
a PDU session handling circuit that selects a route selection descriptor (RSD) from a list of RSDs of the selected URSP rule that matches an existing PDU session, wherein the existing PDU session has a list of requested parameters and a list of stored parameters, and wherein the existing PDU session is selected when matches are found either in the list of requested parameters of the existing PDU session or in the list of stored parameters of the existing PDU session, and wherein values for the list of requested parameters are obtained during PDU session establishment from a UL NAS TRANSPORT message or a PDU SESSION ESTABLISHMENT REQUEST message (see Claim 1 rejection above); and
a control circuit that associates the existing PDU session with the application and provides the existing PDU session information to the upper layers, wherein the match is determined when either the list of requested parameters or the list of stored parameters of the existing PDU session matches corresponding parameters of the RSD (see Claim 1 rejection above).
DEPENDENT:
As per claims 2 and 11, which respectively depend on claims 1 and 10, Xu further teaches wherein the list of requested or stored parameters comprises at least one of a Data Network Name (DNN), a Single-Network Slice Selection Assistance Information (S-NSSAI), and a Service and Session Continuity (SSC) mode (see Xu, [0006]: “The cause-parameter condition includes at least one of: whether a rejection cause in the cause parameter indicates that a service and session continuity (SSC) mode is not supported, an allowed SSC mode in the cause parameter, or whether a combination of a data network name (DNN) and single-network slice selection assistant information (S-NSSAI) in a current RSD differs from a combination of a DNN and S-NSSAI used for initiation of a previous PDU session.”).
As per claims 5 and 14, which respectively depend on claims 2 and 11, Xu further teaches wherein the list of requested parameters comprises a first DNN1, wherein the list of stored parameters comprises a second DNN2, and wherein the RSD comprises either the first DNN1 or the second DNN2 (see Xu, [0054]: “… an IP multimedia subsystem (IMS) traffic can be described with an IMS DNN… One value of the S-NSSAI and the DNN can be combined with the values of the other parameters to constitute a parameter combination. Therefore, each RSD can correspond to one or more parameter combinations, each parameter combination constitutes features of a PDU session, and traffic data corresponding to the TD can be transmitted via a PDU session corresponding to a parameter combination in the RSD.”; and page 5, TABLE 2: “DNN selection” & “Either a single value or a list of values of DNN(s)”).
As per claims 6 and 15, which respectively depend on claims 2 and 11, Xu further teaches wherein the list of requested parameters comprises a first S-NSSAI1, wherein the list of stored parameters comprises a second S-NSSAI2, and wherein the RSD comprises either the first S-NSSAI1 or the second S-NSSAI2 (see Xu, [0009]: “The cause-parameter condition includes at least one of: whether a rejection cause in the cause parameter indicates that an SSC mode is not supported, an allowed SSC mode in the cause parameter, or whether a combination of a DNN and S-NSSAI in a current RSD differs from a combination of a DNN and S-NSSAI used for initiation of a previous PDU session.”; and [0053]: “The NSSP may include one piece of or more pieces of single network slice selection assistance information (S-NSSAI). The S-NSSAI may or may not have a precedence.”).
As per claims 7 and 16, which respectively depend on claims 2 and 11, Xu further teaches wherein the list of requested parameters comprises a first SSC mode1, wherein the list of stored parameters comprises a second SSC mode2, and wherein the RSD comprises either the first SSC model or the second SSC mode2 (see Xu, [0007]: “The cause-parameter condition includes at least one of: whether a rejection cause in the cause parameter indicates that an SSC mode is not supported, an allowed SSC mode in the cause parameter, or whether a combination of a DNN and S-NSSAI in a current RSD differs from a combination of a DNN and S-NSSAI used for initiation of a previous PDU session.”; page 4, TABLE 2: “SSC mode selected Network slice selection”; and [0082]: “A value of the SSC mode in the RSD-1 is an SSC mode-3, and the network device rejects the PDU session establishment because “the SSC mode-3 is unsupported”, and indicates that an allowed value of the SSC mode is “SSC mode=1” (i.e., SSC mode-1), and thus the terminal device jumps, in the precedence order of the RSDs, to an RSD including “SSC mode=1” or an RSD in which a value of the SSC mode is not limited, instead of directly trying to use the RSD with the secondary precedence.”).
As per claims 8 and 17, which respectively depend on claims 2 and 11, Xu further teaches wherein the list of requested or stored parameters further comprises a PDU session type (see Xu, [0081]: “However, if a value of the PDU session type in an RSD-2 with a secondary precedence is still the IPv4, the terminal device shall not use the RSD-2, and shall jump to an RSD in which the value of the PDU session type is not or is not limited to the IPv4. However, according to the current scheme, the terminal device tries to establish a PDU session in the precedence order of the URSP rules and the precedence order of the RSDs. In other words, even if the value of the PDU session type in the RSD-2 is the IPv4, the terminal device still uses a parameter combination in the RSD-2 to initiate PDU session establishment to the network device.”).
As per claims 9 and 18, which respectively depend on claims 1 and 10, Xu further teaches wherein the list of requested parameters has values different from values of the list of stored parameters of the same PDU session (see Xu, [0055]: “It can be understood that values of parameters in different RSDs may be the same or different”; and [0092]: “The second parameter and the third parameter may include at least one of the following: the DNN, the S-NSSAI, the PDU session type, the SSC mode, the PDU session identity, and the access type. The second parameter and the third parameter may be the same or different.”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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.
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.
7. Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Xu et al. (US 2022/0124595 A1) in view of Asthana et al. (US 2022/0124609 A1).
As per claims 4 and 13, which respectively depend on claims 1 and 10, although Xu explicitly teaches wherein values for the list of stored parameters is obtained, Xu does not explicitly teach during PDU session establishment from a PDU SESSION ESTABLISHMENT ACCEPT message.
Asthana teaches wherein values for the list of stored parameters is obtained during PDU session establishment from a PDU SESSION ESTABLISHMENT ACCEPT message (see Xu, [0086]: “In an embodiment, the API may be configured for informing the one or more services within the UE about a number of events. Examples of the number of events may include a PDU Session Establishment Accept, a PDU session modification, a PDU session release, a PDU session reject procedure and one or more NAS mobility and session management related procedures. In an embodiment, the API may further be configured for updating the one or more services with data related parameters comprising one or more of a reject cause, a SSC mode, a PDU session type, a QoS rules, a Session AMBR, a 5G system (5GS) network feature support, network slice information, a 5GS mobile (5GSM) capability and a multi access support.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Xu in view of Asthana so that the values for the list of stored parameters is obtained during PDU session establishment from a PDU SESSION ESTABLISHMENT ACCEPT message. One would be motivated to do so because Xu teaches in paragraph [0065], “If no PDU session is established, the terminal device can attempt to perform PDU session establishment according to another parameter combination in the RSD or by checking a parameter combination in an RSD with a secondary precedence.”, and further teaches in paragraph [0074], “the terminal device can transmit a PDU session establishment request message to the SMF. The PDU session establishment request message can carry a PDU session parameter. The PDU session parameter is a parameter combination selected by the terminal device. The PDU session parameter can include at least one of the following: the DNN, the S-NSSAI, a PDU session type, the SSC mode, a PDU session identity, and an access type.”, emphasis added.
Conclusion
8. For the reasons above, claims 1-2, 4-11, and 13-18 have been rejected and remain pending.
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas R Taylor can be reached on 571-272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael Won/Primary Examiner, Art Unit 2443