DETAILED ACTION
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 .
This Office Action is in response to the Amendment request/REMARKS correspondence filed on 01/19/2026
Claims 1-14 are pending and rejected.
Response to Arguments start of page 17.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/02/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments, see Applicant's Argument/REMARKS, filed 01/19/2026, with respect to the rejection(s) of claim(s) 1-14 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of further search and inquiry.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Marcos et al (US20230328805A1) in view of 3GPP TS 23.503 (2021-01) (hereinafter "Spec-1"), in further view of 3GPP TS 24.526 (2021-04) (hereinafter "Spec-2").
Regarding claim 8 (and method claim 1), Marcos teaches a User Equipment (UE), comprising:
an upper layer handling circuit that initiates a UE Route Selection Policy (URSP) rule matching procedure in a mobile communication network, wherein the UE selects a URSP rule from one or more URSP rules ([0010], [0024]-[0026], [0047], teaches URSP rule processing for redundant PDU sessions; states that URSP rules can be sent to the UE and that duplicated traffic associated with redundant PDU sessions is differentiated by “two distinct traffic descriptors, each in a distinct URSP rule.”; further teaches that the PCF derives “two URSP rules” for services requiring redundancy and delivers the URSP rule pairs to the UE));
a Route Selection Policy (URSP) handling circuit that matches a traffic descriptor of the selected URSP rule with an application information ([0010], expressly teaches that duplicated traffic from the same application is associated with redundant PDU sessions using traffic descriptors in distinct URSP rules; further teaches that these traffic descriptors use DNNs, IP descriptors, or non-IP descriptors so that the redundant PDU sessions are matched to RSDs of distinct URSP rules),
wherein the UE selects and evaluating a route selection descriptor (RSD) from a list of RSDs of the selected URSP rule to be matched with a PDU session ([0012], [0024]-[0029], [0047]-[0048], teaches that redundant PDU sessions are matched to RSDs of distinct URSP rules using the traffic descriptors and DNN/S-NSSAI combinations; also teaches that the PCF derives and stores URSP rule pairs for redundant services and that these are later used during PDU session establishment) ; and
a control circuit that determines that the RSD has a list of stored RSD components for a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN) ([0007], [0012], [0031], expressly teaches that the SMF determines the RSN which differentiates PDU sessions handled redundantly, the PCF provides a redundancy indication to the SMF and the SMF uses that indication to set the RSN value toward the RAN; the PDU session establishment response includes an RSN value requesting redundant transmission; also teaches that the PCF stores redundant URSP rule pairs per DNN and S-NSSAI and later uses those stored URSP rule pairs during PDU session establishment),
However, Marcos does not fully disclose the UE selecting among multiple RSDs within the same URSP rule with precedence ordering (at least in the same level of detail as Spec-1, Section 6.6.2.3 pg 74-75, “the UE shall select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence; When a valid Route Selection descriptor is found, the UE determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor”—First phrase supports selecting an RSD from the list (in precedence order); Second phrase supports evaluating the selected RSD by checking whether an existing PDU session matches the RSD components).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met.
A POSITA would have been motivated to combine Marcos and Spec-1, in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
However Marcos and Spec-1 fail to teach but Spec-2 teaches wherein the UE ignores the RSD upon determining that the RSD further comprises a preferred access type set to non- 3GPP access or upon determining that the RSD further comprises a multi-access preference type (pg. 28 Note 2, ignoring & Section 4.2.2.2 pg 9-11, multi-access preference[Wingdings font/0xE0] “v) the selected descriptor includes the multi-access preference but the UE does not support ATSSS, the UE shall proceed to step 4);”; On preferred access type/multi-access generally[Wingdings font/0xE0] “E) preferred access type or multi-access preference, if the preferred access type or the multi-access preference is in the route selection descriptor; and” On recommended behavior when included[Wingdings font/0xE0] “Note 6: if a preferred access type or a multi-access preference is included in the traffic descriptor of a URSP rule, it is recommended that the UE establishes a PDU session based on the preferred access type or the multi-access preference.”; explicit handling logic—if an RSD includes a multi-access preference that the UE cannot support, the UE proceeds to step 4; which means to skip this RSD and move on to the next (ignore)).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 9 (and method claim 2), Marcos and Spec-1 fails to teach the UE, wherein the URSP rule matching procedure is initiated by upper layers of the UE and is triggered due to need to send a PDU of an application.
However, Spec-2 teaches the UE, wherein the URSP rule matching procedure is initiated by upper layers of the UE and is triggered due to need to send a PDU of an application (Section 4.2.2.2 pg. 9, “When the upper layers request information of the PDU session via which to send a PDU of an application…the UE shall evaluate the URSP rules…”, discloses the trigger from the upper layers when sensing a PDU of an application”).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 10 (and method claim 3), Marcos and Spec-1 do not fully teach the UE, wherein each URSP rule comprises a precedence value, a traffic descriptor, and a list of route selection descriptors.
However, Spec-2 teaches the UE, wherein each URSP rule comprises a precedence value, a traffic descriptor, and a list of route selection descriptors (Section 4.2.1(c), pg. 7-8, “one or more route selection descriptors each consisting of a precedence value of the route selection descriptor…Only one URSP rule in the URSP can be a default URSP rule…any non-default URSP rule shall have lower precedence value…if one or more DNNs are included in the traffic descriptor…”; URSP rule = precedence value + traffic descriptor + list of RSDs).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 11 (and method claim 4), Marcos fails to teach but Spec-1 teaches the UE, wherein the traffic descriptor comprises at least one of application identifiers, IP tuples, non-IP descriptors, data network names, connection capabilities, and domain descriptors (Section 6.6.2.1 defines traffic descriptor fields including application identifier, IP flow descriptors, DNN, domain name descriptors—directly to application IDs, IP tuples, non-IP descriptors, DNNs, connection capabilities, domain descriptors).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 12 (and method claim 5), Marcos and Spec-1 fails to teach the UE, wherein each RSD from the list of RSDs is associated with a precedence value indicating a priority for matching.
However, Spec-2 teaches the UE, wherein each RSD from the list of RSDs is associated with a precedence value indicating a priority for matching (Section 4.2.1(c) pg. 8, “one or more route selection descriptors each consisting of a precedence value of the route selection descriptor…”—discloses RSD precedence values).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 13 (and method claim 6), Marcos and Spec-1 fails to teach the UE, wherein the UE skips the RSD and selects another RSD from the list of RSDs that has a lowest precedence value and has not been evaluated.
However, Spec-2 teaches the UE, wherein the UE skips the RSD and selects another RSD from the list of RSDs that has a lowest precedence value and has not been evaluated (Section 4.2.2.2 pg. 10, “the UE shall select a route selection descriptor with the next smallest precedence value which has not yet been evaluated…”[Wingdings font/0xE0]matches skip and evaluate next lowest precedence RSD).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 14 (and method claim 7), Marcos and Spec-1 fails to teach the UE, wherein the UE skips the selected URSP rule when there is no other RSD from the list of RSDs that has not been evaluated.
However, Spec-2 teaches the UE, wherein the UE skips the selected URSP rule when there is no other RSD from the list of RSDs that has not been evaluated (Section 4.2.2.2 pg. 11, “if all route selection descriptors for the matching non-default URSP rule have been evaluated…the UE shall proceed to [evaluate] the next URSP rule…”[Wingdings font/0xE0]maps to skips URSP when no remaining unevaluated RSD exists).
It would have been obvious before the effective filing date for a person of ordinary skill in the art to combine the references. Marcos teaches using paired URSP rules, traffic descriptors, DNNs/S-NSSAI combinations, and redundancy sequency numbers (RSNs) to establish and coordinate redundant PDU sessions for reliable URLLC traffic in a 5G network. Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Marcos and Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling ensuring compatibility with 5G multi-access and redundancy features.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST.
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, Nishant Divecha can be reached at (571) 270-3125. 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights