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 .
Response to Amendment
This communication is considered fully responsive to the amendment filed on 08/05/2025.
Claims 1-3, 5-11, 13-15 have been amended.
Claim 16 was previously canceled.
Claims 1-15 are pending in the current application.
Response to Arguments
Applicant’s arguments with respect to claims 1-15 filed on 08/05/2025 have been considered but are moot because the arguments related solely to newly added limitations addressed in the instant Office Action with newly identified prior art, thus rendering applicant’s arguments moot.
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.
Claim(s) 1-3 and 10 rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP TS 23.503 V16.4.1, “Policy and charging control framework for the 5G System (5GS);” Stage 2 (Release 16), April 6, 2020, provided as IDS filed Nov 29, 2022, (hereinafter “3GPP TS 23.503”).
Examiner’s note: in what follows, references are drawn to 3GPP TS 23.503 unless otherwise mentioned.
With respect to independent claims:
Regarding claim 1, 3GPP TS 23.503 teaches A method comprising:
receiving, from a network, a first route selection policy rule and a second route selection policy rule, (pages 56-57; 6.1.3.20 Access Traffic Steering, Switching and Splitting …
The PCF (‘Policy Control Function (PCF)’ is interpreted as “a network”) may also provide URSP rules (interpreted as “a first route selection policy rule and a second route selection policy rule”)) to the UE for instructing the UE to establish a MA PDU Session, as described in clause 6.6.2.) (see the Example URSP rules in Table A-1, pages 103-105). The Table A-1 of 3GPP TS 23.503 is reproduced herein below.
Table A-1: Example of URSP rules
Example URSP rules
Comments
Rule Precedence =1
Traffic Descriptor: Application Identifiers=App1
Route Selection Descriptor Precedence=1
Network Slice Selection: S-NSSAI-a
SSC Mode Selection: SSC Mode 3
DNN Selection: internet
Access Type preference: 3GPP access
This URSP rule associates the traffic of application "App1" with S-NSSAI-a, SSC Mode 3, 3GPP access and the "internet" DNN.
It enforces the following routing policy:
The traffic of App1 should be transferred on a PDU session supporting S-NSSAI-a, SSC Mode 3 and DNN=internet over 3GPP access. If this PDU session is not established, the UE shall attempt to establish a PDU session with S-NSSAI-a, SSC Mode 3 and the "internet" DNN over 3GPP access.
Rule Precedence =2
Traffic Descriptor: Application Identifiers=App2
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-a
Access Type preference: Non-3GPP access
This URSP rule associates the traffic of application "App2" with S-NSSAI-a and Non-3GPP access.
It enforces the following routing policy:
The traffic of application App2 should be transferred on.
a PDU session supporting S-NSSAI-a using a Non-3GPP access. If this PDU session is not established, the UE shall attempt to establish a PDU session with S-NSSAI-a over Access Type=non-3GPP access.
Route Selection Descriptor Precedence =2
Non-seamless Offload indication: Permitted (WLAN SSID-a)
If the PDU session cannot be established, the traffic of App2 shall be directly offloaded to WLAN, if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD)
Rule Precedence =3
Traffic Descriptor: DNN=DNN_1
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-a
Access Type preference: Non-3GPP access
This URSP rule associates the traffic of applications that are configured to use DNN_1 with DNN_1, S-NSSAI-a over Non-3GPP access.
It enforces the following routing policy:
The traffic of application(s) that are configured to use DNN_1 should be transferred on a PDU session supporting S-NSSAI-a over Non-3GPP access. If this PDU session is not established, the UE shall attempt to establish the PDU session with S-NSSAI-a over Non-3GPP access.
Rule Precedence =4
Traffic Descriptor:
Application Identifiers=App1
Connection Capabilities="internet", "supl"
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-a
DNN Selection: DNN_1
Access Type preference: Non-3GPP access
This URSP rule associates the application "App1" and the Connection Capabilities "internet" and "supl" with DNN_1, S-NSSAI-a over Non-3GPP access.
It enforces the following routing policy:
When the "App1" requests a network connection with Connection Capability "internet" or "supl", the UE establishes (if not already established) a PDU session with DNN_1 and S-NSSAI-a over Non-3GPP access. After that, the UE routes the traffic of "App1" over this PDU session.
Rule Precedence =5
Traffic Descriptor:
Application Identifiers=App3
Connection Capabilities="ims"
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-c
DNN Selection: DNN_1
Access Type preference: Multi-Access
This URSP rule associates the application "App3" and the Connection Capability "ims" with DNN_1, S-NSSAI-c and multi-access connectivity.
It enforces the following routing policy:
When the "App3" requests a network connection with Connection Capability "ims", the UE establishes (if not already established) a MA PDU Session with DNN_1 and S-NSSAI-c. After that, the UE routes the traffic of "App3" over this MA PDU Session by using the received ATSSS rules.
Rule Precedence =6
Traffic Descriptor: Application Identifiers=App1
Route Selection Descriptor Precedence =1
DNN Selection: DNN_1
Network Slice Selection: S-NSSAI-a
Access Type preference: Multi Access
This URSP rule associates App 1 with DNN_1, S-NSSAI-a with Multi Access connectivity.
It enforces the following routing policy:
The traffic of Application 1 should be transferred on a PDU session supporting S-NSSAI-a and DNN_1 according to the received ATSSS rules. After that the UE routes the traffic of any other application according to the ATSSS rule with match all packet filters if available.
Rule Precedence = lowest priority
Traffic Descriptor: *
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-b
SSC Mode Selection: SSC Mode 3
DNN Selection: internet
This URSP rule associates all traffic not matching any prior rule a PDU Session with S-NSSAI-b, SSC Mode 3 and the "internet" DNN.
It enforces the following routing policy:
All traffic not matching any prior rule should be transferred on a PDU session supporting S-NSSAI-b, SSC Mode 3 and DNN=internet with no access network preference.
Examiner’s Comments: In Table A-1 of 3GPP TS 23.503, the Rule Precedence 1-2 are, at least, interpreted as the claimed features “a first route selection policy rule and a second route selection policy rule” of claim 1. The contents of Table A-1 disclose almost the same contents as Table 4 of the Instant Application. See Table 4 in paragraphs [0210-0212] of the Specification as originally filed in the Instant Application.
wherein the first route selection policy rule (Rule Precedence=1, see Table A-1, page 104) includes
i) first traffic information that determines when the first route selection policy rule is applicable (Table A-1, page 104: Rule Precedence=1, Traffic Descriptor: Application Identifiers=App1(interpreted as “first traffic information”)), and
ii) one or more route selection information (Table A-1, page 104: Rule Precedence=1, Route Selection Descriptor Precedence=1 (interpreted as “one or more route selection information”)), Network Slice Selection: S-NSSAI-a, SSC Mode Selection: SSC Mode 3, DNN Selection: internet, Access Type preference: 3GPP access), and
wherein the second route selection policy rule (Rule Precedence=2, see Table A-1, page 104) includes
i) second traffic information that determines when the second route selection policy rule is applicable (Table A-1, page 104: Rule Precedence=2, Traffic Descriptor: Application Identifiers=App2 (interpreted as “second traffic information”)), and
ii) one or more route selection information (Table A-1, page 104: Rule Precedence=2, Route Selection Descriptor Precedence =1 (interpreted as “one or more route selection information”)), Network Slice Selection: S-NSSAI-a, Access Type preference: Non-3GPP access; Route Selection Descriptor Precedence =2, Non-seamless Offload indication: Permitted (WLAN SSID-a));
determining that a first application is matching the first traffic information of the first route selection policy rule (page 98, 6.6.2 UE Route Selection Policy information: Each URSP rule contains a Traffic descriptor (containing one or more components described in Table 6.6.2.1-2) that determines when the rule is applicable. A URSP rule is determined to be applicable when every component in the Traffic descriptor matches the corresponding information from the application.) (Table A-1, page 104: Rule Precedence=1: Traffic Descriptor: Application Identifiers=App1 (interpreted as “a first application is matching the first traffic information of the first route selection policy rule”));
based on the first route selection policy rule being determined to be applicable for the first application (page 100, 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP: When a URSP rule is determined to be applicable for a given application (see clause 6.6.2.1), the UE shall select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence.)(Table A-1, page 104: Rule Precedence=1, Traffic Descriptor: Application Identifiers=App1(interpreted as “the first route selection policy rule being determined to be applicable for the first application”, the App1 is interpreted as “first application”)), selecting first route selection information within the first route selection policy rule (page 100, 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP: When a URSP rule is determined to be applicable for a given application (see clause 6.6.2.1), the UE shall select a Route Selection Descriptor (interpreted as “route selection information”,) within this URSP rule in the order of the Route Selection Descriptor Precedence.) (Table A-1, page 104: Rule Precedence=1, Route Selection Descriptor Precedence=1 (interpreted as “first route selection information”), Network Slice Selection: S-NSSAI-a, SSC Mode Selection: SSC Mode 3, DNN Selection: internet, Access Type preference: 3GPP access);
associating the first application to a first session based on the first route selection information (page 100, 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP: 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. The UE compares the components of the selected Route Selection Descriptor with the existing PDU Session(s) as follows: … When a matching PDU Session exists the UE associates the application to the existing PDU Session, i.e. route the traffic of the detected application on this PDU Session.) (Table A-1, page 104: Rule Precedence=1, Route Selection Descriptor Precedence=1 (interpreted as “first route selection information”), Network Slice Selection: S-NSSAI-a, SSC Mode Selection: SSC Mode 3, DNN Selection: internet, Access Type preference: 3GPP access)( Table A-1, page 104: Rule Precedence=1, Comments: This URSP rule associates the traffic of application "App1" with S-NSSAI-a, SSC Mode 3, 3GPP access and the "internet" DNN. It enforces the following routing policy: The traffic of App1 should be transferred on a PDU session supporting S-NSSAI-a, SSC Mode 3 and DNN=internet over 3GPP access (interpreted as “associating the first application to a first session based on the first route selection information”). If this PDU session is not established, the UE shall attempt to establish a PDU session with S-NSSAI-a, SSC Mode 3 and the "internet" DNN over 3GPP access);
determining that a second application is matching the second traffic information of the second route selection policy rule (page 98, 6.6.2 UE Route Selection Policy information: Each URSP rule contains a Traffic descriptor (containing one or more components described in Table 6.6.2.1-2) that determines when the rule is applicable. A URSP rule is determined to be applicable when every component in the Traffic descriptor matches the corresponding information from the application.) (Table A-1, page 104: Rule Precedence=2: Traffic Descriptor: Application Identifiers=App2(interpreted as “a second application is matching the second traffic information of the second route selection policy rule”));
based on the second route selection policy rule being determined to be applicable for the second application (page 100, 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP: When a URSP rule is determined to be applicable for a given application (see clause 6.6.2.1), the UE shall select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence.)(Table A-1, page 104: Rule Precedence=2, Traffic Descriptor: Application Identifiers=App2(interpreted as “the first route selection policy rule being determined to be applicable for the first application”, the App2 is interpreted as “second application”)), selecting second route selection information within the second route selection policy rule (page 100, 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP: When a URSP rule is determined to be applicable for a given application (see clause 6.6.2.1), the UE shall select a Route Selection Descriptor (interpreted as “route selection information”,) within this URSP rule in the order of the Route Selection Descriptor Precedence.) (Table A-1, page 104: Rule Precedence=2, Route Selection Descriptor (interpreted as “second route selection information”), Network Slice Selection: S-NSSAI-a, Access Type preference: Non-3GPP access):
based on the second route selection information further including an indicator indicating whether to establish a separate dedicated for the second route selection policy rule (page 100, 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP: When a URSP rule is determined to be applicable for a given application (see clause 6.6.2.1), the UE shall select a Route Selection Descriptor (interpreted as “route selection information”,) within this URSP rule in the order of the Route Selection Descriptor Precedence.) (Table A-1, page 104: Route Selection Descriptor Precedence =2, Network Slice Selection: S-NSSAI-a, Access Type preference: Non-3GPP access, Route Selection Descriptor Precedence =2: Non-seamless Offload indication: Permitted (WLAN SSID-a)), determining whether to establish a second session which is the dedicated session (Table A-1, page 104: Rule Precedence =2, Route Selection Descriptor Precedence =1: This URSP rule associates the traffic of application "App2" with S-NSSAI-a and Non-3GPP access. It enforces the following routing policy: The traffic of application App2 should be transferred on a PDU session supporting S-NSSAI-a using a Non-3GPP access. If this PDU session is not established, the UE shall attempt to establish a PDU session with S-NSSAI-a over Access Type=non-3GPP access. Route Selection Descriptor Precedence =2: If the PDU session cannot be established, the traffic of App2 shall be directly offloaded to WLAN (interpreted as “a second session which is the dedicated session”,), if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD)) (Examiner’s note: ‘Route Selection Descriptor Precedence=1 and Route Selection Descriptor Precedence=2’ are interpreted as “indicator indicating whether to establish a separate dedicated for the second route selection policy rule”); and
based on determining to establish the second session, requesting, to the network, establishment of the second session (Table A-1, page 104: Rule Precedence =2, Route Selection Descriptor Precedence =1: …The traffic of application App2 should be transferred on a PDU session supporting S-NSSAI-a using a Non-3GPP access. … Route Selection Descriptor Precedence =2: If the PDU session cannot be established, the traffic of App2 shall be directly offloaded to WLAN , if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD)).
With respect to dependent claims:
Regarding claim 2, 3GPP TS 23.503 teaches The method of claim 1, wherein the indicator always indicates establishment of the dedicated session for the second route selection policy rule (Table A-1, page 104: Rule Precedence =2, Route Selection Descriptor Precedence =1: This URSP rule associates the traffic of application "App2" with S-NSSAI-a and Non-3GPP access. It enforces the following routing policy: The traffic of application App2 should be transferred on a PDU session supporting S-NSSAI-a using a Non-3GPP access. If this PDU session is not established, the UE shall attempt to establish a PDU session with S-NSSAI-a over Access Type=non-3GPP access. Route Selection Descriptor Precedence =2: If the PDU session cannot be established, the traffic of App2 shall be directly offloaded to WLAN , if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD)) (Examiner’s note: The discussion of “If this PDU session is not established, the UE shall attempt …” and “If the PDU session cannot be established, the traffic of App2 shall be directly…” are interpreted as “the indicator always indicates establishment” ).
Regarding claim 3, 3GPP TS 23.503 teaches The method of claim 1, wherein the indicator indicates establishment of the dedicated session for the second route selection policy rule based on absence of a session corresponding to the second route selection information (Table A-1, page 104: Rule Precedence =2, Route Selection Descriptor Precedence =1: This URSP rule associates the traffic of application "App2" with S-NSSAI-a and Non-3GPP access. It enforces the following routing policy: The traffic of application App2 should be transferred on a PDU session supporting S-NSSAI-a using a Non-3GPP access. If this PDU session is not established, the UE shall attempt to establish a PDU session with S-NSSAI-a over Access Type=non-3GPP access. Route Selection Descriptor Precedence =2: If the PDU session cannot be established, the traffic of App2 shall be directly offloaded to WLAN , if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD)) (Examiner’s note: The discussion of “If this PDU session is not established, the UE shall attempt …” and “If the PDU session cannot be established, the traffic of App2 shall be directly…” are interpreted as “based on absence of a session corresponding to the second route selection information” ).
Regarding claim 10, 3GPP TS 23.503 teaches The method of claim 1, wherein the method is performed by a user equipment (UE) in communication with at least one of a mobile device, a network, and/or autonomous vehicles other than the UE (pages 56-57; 6.1.3.20 Access Traffic Steering, Switching and Splitting … The PCF (interpreted as “a network”) may also provide URSP rules to the UE for instructing the UE to establish a MA PDU Session, as described in clause 6.6.2.).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 11 and 15 rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.503 in view of U.S. Patent Application Publication No. 2021/0168151 to Sun et al. (hereinafter “Sun”).
Regarding claim 11, it is a user equipment claim corresponding to the method claim 1, 3GPP TS 23.503 teaches the claim 1 except limitations “at least one transceiver”; “at least one processor;” and “at least one memory operably connectable to the at least one processor and storing instructions that, based on being executed by the at least one processor, cause the UE to perform operations…”
In analogous art, Sun teaches the missing limitations ““at least one transceiver”(Fig. 10 and paragraph [0153] of Sun; a terminal apparatus includes .,.. a communications interface 1003); “at least one processor(Fig. 10 and paragraph [0153] of Sun; a processor 1001); and “at least one memory (Fig. 10 and paragraph [0153] of Sun; a memory 1002) operably connectable to the at least one processor and storing instructions that, based on being executed by the at least one processor, cause the UE to perform operations (paragraph [0155] of Sun; The processor 1001 invokes the program stored in the memory 1002 to perform the following steps.). Therefore claim 11 is rejected for the similar reasons set forth in the rejection of claim 1 over 3GPP TS 23.503 in view of Sun.
Regarding claim 15, it is a processing apparatus corresponding to the UE claim 11, and is therefore rejected for the similar reasons set forth in the rejection of claim 11.
Claim(s) 4-7 rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.503 in view of WIPO Publication WO2019137286A1 (hereinafter “WO2019137286”).
Regarding Claim 4, 3GPP TS 23.503 teaches The method of claim 1, 3GPP TS 23.503 fails to teach wherein the indicator consists of a 1-bit flag.
WO2019137286 discloses an indicator consists of a 1-bit flag in page 32, lines 5-10 as recited in below.
PNG
media_image1.png
168
908
media_image1.png
Greyscale
(page 32, lines 5-10 of WO2019137286)
[Google Translated: “The first indication is an independent parameter or a sub-parameter in a parameter, and may also be an indication bit. The first indication may indicate whether the indicated data network is a LADN by using a value of 0 or 1, and a value of 0 indicates that the first DNN is not a DNN corresponding to the LADN; and a value of 1 indicates that the first DNN is a DNN corresponding to the LADN. . Or vice versa. Of course, other values may also be used to indicate whether the data network indicated by the first DNN is a LADN.”]
As recited above, WO2019137286 discloses an indicator consists of a 1-bit flag. Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the Technical Specification of 3GPP TS 23.503 by using the 1-bit flag in order to indicate a specific PDU session.
Regarding Claim 5, The combination of 3GPP TS 23.503 and WO2019137286 teaches The method of claim 4, WO2019137286 further teaches wherein presence of the 1-bit flag indicates establishment of the dedicated session .
PNG
media_image2.png
130
892
media_image2.png
Greyscale
(page 32, lines 18-21 of WO2019137286)
[Google Translated: “After the UE determines that the application matches the first DNN according to the URSP, the UE determines whether the data network indicated by the first DNN is a LADN according to the first information. When the UE determines that the PDU session needs to be modified or activated, it is determined that the PDU session corresponds to the first DNN, and whether the data network indicated by the first DNN is the LADN is determined according to the first information (interpreted as “indicator”).”]
Regarding Claim 6, 3GPP TS 23.503 teaches The method of claim 1, The method of claim 1, 3GPP TS 23.503 fails to explicitly teach wherein the indicator consists of binary information indicating the second PDU session.
WO2019137286 discloses the indicator consists of binary information in page 32, lines 5-10 as recited in below.
PNG
media_image1.png
168
908
media_image1.png
Greyscale
(page 32, lines 5-10 of WO2019137286)
[Google Translated: “The first indication is an independent parameter or a sub-parameter in a parameter, and may also be an indication bit. The first indication may indicate whether the indicated data network is a LADN by using a value of 0 or 1, and a value of 0 indicates that the first DNN is not a DNN corresponding to the LADN; and a value of 1 indicates that the first DNN is a DNN corresponding to the LADN. . Or vice versa. Of course, other values may also be used to indicate whether the data network indicated by the first DNN is a LADN.”]
As recited above, WO2019137286 discloses an indicator consists of binary information. Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the Technical Specification of 3GPP TS 23.503 by using the indicator consists of binary information disclosed in WO2019137286 in order to indicate a specific PDU session.
Regarding Claim 7, the combination of 3GPP TS 23.503 and WO2019137286 teaches The method of claim 6, 3GPP TS 23.503 further teaches wherein establishment of the second session is requested based on absence of the second session (Table A-1, page 104: Rule Precedence =2, Route Selection Descriptor Precedence =2: If the PDU session cannot be established, the traffic of App2 shall be directly offloaded to WLAN (interpreted as “a second session which is the dedicated session”,), if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD)) (Examiner’s note: “If the PDU session cannot be established, the traffic of App2 shall be directly…” are interpreted as “based on absence of a session corresponding to the second route selection information” ).
Claim(s) 8 and 9 rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.503 in view of 3GPP TSG-SA3 Meeting #99e S3-201329 e-meeting, May 11-15 2020, Samsung, “Illustrative flow for the proposal in the CR S3-201296”, provided as IDS filed Nov 29, 2022, (hereinafter “3GPP S3-201329”).
Regarding Claim 8, 3GPP TS 23.503 teaches The method of claim 1, 3GPP TS 23.503 does not explicitly teach wherein the first route selection policy rule or the second route selection policy rule includes one or more traffic information according to protocol information.
However, 3GPP S3-201329 teaches wherein the first route selection policy rule or the second route selection policy rule includes one or more traffic information according to protocol information (Page 2 of 3GPP S3-201329, 3.2; Same DNN “internet-dns”, can be used for protection of ICMP packets, if the application mentions ICMP Protocol ID in the Traffic Descriptor.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the Technical Specification of 3GPP TS 23.503 by using the feature of 3GPP S3-201329 in order to include traffic information according to protocol information.
Regarding Claim 9, the combination of 3GPP TS 23.503 and 3GPP S3-201329 teaches The method of claim 8, 3GPP S3-201329 teaches wherein the protocol information indicates a hypertext transfer protocol (HTTP) or an internet control message protocol (ICMP) (Page 2 of 3GPP S3-201329, 3.2; Same DNN “internet-dns”, can be used for protection of ICMP packets, if the application mentions ICMP Protocol ID in the Traffic Descriptor.).
Claim(s) 12 and 13 rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.503 in view of Sun, and further in view of WIPO Publication WO2019137286A1 (hereinafter “WO2019137286”).
Regarding Claim 12, the combination of 3GPP TS 23.503 and Sun teaches The UE of claim 11, the combination of 3GPP TS 23.503 and Sun fails to teach wherein the indicator consists of a 1-bit flag.
WO2019137286 discloses an indicator consists of a 1-bit flag in page 32, lines 5-10 as recited in below.
PNG
media_image1.png
168
908
media_image1.png
Greyscale
(page 32, lines 5-10 of WO2019137286)
[Google Translated: “The first indication is an independent parameter or a sub-parameter in a parameter, and may also be an indication bit. The first indication may indicate whether the indicated data network is a LADN by using a value of 0 or 1, and a value of 0 indicates that the first DNN is not a DNN corresponding to the LADN; and a value of 1 indicates that the first DNN is a DNN corresponding to the LADN. . Or vice versa. Of course, other values may also be used to indicate whether the data network indicated by the first DNN is a LADN.”]
As recited above, WO2019137286 discloses an indicator consists of a 1-bit flag. Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of 3GPP TS 23.503 and Sun by using the 1-bit flag in order to indicate a specific PDU session.
Regarding Claim 13, the combination of 3GPP TS 23.503 and Sun teaches The UE of claim 11, the combination of 3GPP TS 23.503 and Sun fails to teach wherein the indicator consists of binary information indicating the second PDU session.
WO2019137286 discloses the indicator consists of binary information in page 32, lines 5-10 as recited in below.
PNG
media_image1.png
168
908
media_image1.png
Greyscale
(page 32, lines 5-10 of WO2019137286)
[Google Translated: “The first indication is an independent parameter or a sub-parameter in a parameter, and may also be an indication bit. The first indication may indicate whether the indicated data network is a LADN by using a value of 0 or 1, and a value of 0 indicates that the first DNN is not a DNN corresponding to the LADN; and a value of 1 indicates that the first DNN is a DNN corresponding to the LADN. . Or vice versa. Of course, other values may also be used to indicate whether the data network indicated by the first DNN is a LADN.”].
Claim(s) 14 rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.503 in view of Sun, and further in view of 3GPP S3-201329.
Regarding Claim 14, the combination of 3GPP TS 23.503 and Sun teaches The UE of claim 11, the combination of 3GPP TS 23.503 and Sun fails to teach wherein the first route selection policy rule or the second route selection policy rule includes one or more traffic information according to protocol information.
However, 3GPP S3-201329 teaches wherein the first route selection policy rule or the second route selection policy rule includes one or more traffic information according to protocol information (Page 2 of 3GPP S3-201329, 3.2; Same DNN “internet-dns”, can be used for protection of ICMP packets, if the application mentions ICMP Protocol ID in the Traffic Descriptor.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify the combination of 3GPP TS 23.503 and Sun by using the feature of 3GPP S3-201329 in order to include traffic information according to protocol information.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411