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
Applicant amended claims 1, 3, 8, 10, 15, and 17 in amendment filed 12/15/2025. Claims 1-20 are pending for examination.
Response to Arguments
Applicant’s arguments with respect to 103 rejections to claims 1, 2, 4, 5, 7-9, 11, 12, 14-16, 18, and 19 over Oiao in view of Sriram have been considered but are moot because the new ground of rejection does not rely on one or more reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 1, 2, 4, 5, 7, 8, 9, 11, 12, 14, 15, 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Qiao et al. (US 12401536 B2, hereinafter Qiao) in view of Sriram et al. (US 20240224027 A1, hereinafter Sriram), and further in view of LÖVSÉN (US 20200314616 A1).
As to Claims 1 and 15, Qiao teaches a method and non-transitory computer-readable media storing computer- executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations, comprising:
receiving, at an access management function (AMF) of a 5G core network from a mobile device, a connection request comprising an indication of IPv4 packet data network type; [¶ 36, The wireless device 100 sets the requested PDU type during the PDU session establishment procedure based on its IP stack capabilities and configuration. The SMF 160 may select PDU type of a PDU session as follows: if the SMF 160 receives a request with PDU type set to IP, the SMF 160 may select either PDU type IPv4 or IPv6 based on DNN configuration and/or operator policies.]
[¶ 74, At step 801 (in FIG. 8A), a wireless device (e.g., wireless device 100) may send a message comprising a registration request to a (R)AN (e.g., (R)AN 105). At step 802, the (R)AN 105 may perform an AMF selection. At step 803, the (R)AN 105 may send a message comprising the registration request to a new AMF (e.g., New AMF 155-1).]
transmitting, from the AMF to a network function repository function (NRF), an identification of a session management function (SMF); [¶ 111, If the old AMF 155-2 has information about active PDU sessions, the old AMF 155-2 may include in an existing PDU session(s) (e.g., which may have been established before the response message) one or more of: SMF information (e.g., SMF identities and/or SMF addresses); UPF information (e.g., UPF identities and/or UPF addresses); PDU session ID(s); wireless device address (e.g., for IPv4) and/or wireless device prefix (e.g., for IPv6) if available; and/or DNN if available.]
[¶ 220, The AMF 155 may select an SMF (e.g., SMF 160) using an NRF, for example, by providing one or more of the following information, that may be received from the wireless device 100, to the NRF: wireless device identity and/or identifier; data network name (DNN); PDU session ID; and/or S-NSSAI. The NRF may select an SMF based on information that the NRF receives from the AMF 155, which may comprise the same information that the AMF 155 received from the wireless device 100 (e.g., at step 2206).]
selecting, by the NRF, a selected SMF; [¶ 220, The AMF 155 may select an SMF (e.g., SMF 160) using an NRF, for example, by providing one or more of the following information, that may be received from the wireless device 100, to the NRF:]
determining that the selected SMF is not capable of handling the IPv4 packet data network type; [¶ 36, the SMF 160 may select PDU type of a PDU session as follows: if the SMF 160 receives a request with PDU type set to IP, the SMF 160 may select either PDU type IPv4 or IPv6 based on DNN configuration and/or operator policies. The SMF 160 may also provide a cause value to the wireless device 100 to indicate whether the other IP version (e.g. IPv6 if IPv4 is selected and vice versa) may be supported on the DNN.]
and transmitting to the AMF an identification of a capable SMF based on SMF status datastore information, the capable SMF having an associated UPF with an IPv4 lane capable of handling the IPv4 packet data network type. [¶ 111, At step 1505 (in FIGS. 15A and 15C), the old AMF 155-2 may send, to the new AMF 155-1, a response message. The old AMF 155-2 may respond to the new AMF 155-1 with a response (e.g., a Namf_Communication_UEContextTransfer response) comprising the wireless device 100 SUPI and/or MM context information. If the old AMF 155-2 has information about active PDU sessions, the old AMF 155-2 may include in an existing PDU session(s) (e.g., which may have been established before the response message) one or more of: SMF information (e.g., SMF identities and/or SMF addresses); UPF information (e.g., UPF identities and/or UPF addresses); PDU session ID(s); wireless device address (e.g., for IPv4) and/or wireless device prefix (e.g., for IPv6) if available; and/or DNN if available.]
Qiao fails to teach, querying an SMF status datastore for capabilities of the selected SMF;
However, Sriram teaches, querying an SMF status datastore for capabilities of the selected SMF; [¶ 0028, In some scenarios, the RAN or the Access & Mobility Function (AMF) can indirectly deduce the ATSSS activation on the device by checking the policies configured for the data flow (a service data unit (SDU) session or a packet data unit (PDU) session), for instance, by querying the SMF and PCF.] [¶ 0033, The type of a MA PDU Session 112 may be one of the following types: i.e. IPv4, IPV6, IPv4v6, and Ethernet.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to combine the method of Qiao with the method of Sriram. Doing so would provide “benefits to the network(s) of the multi-RAN network environment 104 and/or the UE 102. For instance, using the features of release 16 to indicate the ATSSS capabilities can result in efficient use of network resources and conserve UE battery life.” [See Sriram, ¶0050]).
The combination of references does not disclose the selected SMF performing the determining step and transmitting using a redirect message step, as recited in the amended claim 1.
However, in a similar endeavor, LÖVSÉN discloses such features by using SMF to interrogate and to direct/redirect a request to an appropriate SMF (see LÖVSÉN, Fig. 7, [0070] direct a request to an appropriate SMF; [0177] redirect message to SMF 108 handling the connection). (Examiner’s note: interrogating SMF is read as selected SMF).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to modify the combination of Qiao and Sriram, to use a selected SMF to further select the most appropriate SMF for the connection, thus improving the handoff procedure based on better connectivity, as suggested by LÖVSÉN.
As to claim 2, The method of claim 1, further comprising: determining that the selected SMF is capable of handling the IPv4 packet data network type; and transmitting to the AMF an identification of the selected SMF.
Qiao teaches, further comprising: determining that the selected SMF is capable of handling the IPv4 packet data network type; [¶ 36, the SMF 160 may select PDU type of a PDU session as follows: if the SMF 160 receives a request with PDU type set to IP, the SMF 160 may select either PDU type IPv4 or IPv6 based on DNN configuration and/or operator policies. The SMF 160 may also provide a cause value to the wireless device 100 to indicate whether the other IP version (e.g. IPv6 if IPv4 is selected and vice versa) may be supported on the DNN.]
and transmitting to the AMF an identification of the selected SMF. [¶ 111, At step 1505 (in FIGS. 15A and 15C), the old AMF 155-2 may send, to the new AMF 155-1, a response message. The old AMF 155-2 may respond to the new AMF 155-1 with a response (e.g., a Namf_Communication_UEContextTransfer response) comprising the wireless device 100 SUPI and/or MM context information. If the old AMF 155-2 has information about active PDU sessions, the old AMF 155-2 may include in an existing PDU session(s) (e.g., which may have been established before the response message) one or more of: SMF information (e.g., SMF identities and/or SMF addresses); UPF information (e.g., UPF identities and/or UPF addresses); PDU session ID(s); wireless device address (e.g., for IPv4) and/or wireless device prefix (e.g., for IPv6) if available; and/or DNN if available.]
As to claim 4, The method of claim 1, further comprising instantiating an N3 connection from a base station in communication with the mobile device to the UPF associated with the capable SMF, the UPF having the IPv4 lane capable of handling the IPv4 packet data network type.
Qiao teaches, further comprising instantiating an N3 connection from a base station in communication with the mobile device to the UPF associated with the capable SMF. [¶ 127, At step 1521 (in FIGS. 15B and 15D), one or more PDU sessions may be modified, such as described further below regarding FIGS. 17A-17B. One or more of the new AMF 155-1, old AMF 155-2, SMF 160, and/or PCF 135 (if supported) may send, to the UPF 110, the (R)AN N3 tunnel information. Interactions between AMF(s), SMF, PCF (if supported), and UPF to modify one or more PDU sessions may correspond to steps 1701 to 1706 in FIGS. 17A-17B. Additionally or alternatively, step 1521 may be performed before step 1527 and/or after step 1526 described below.]
the UPF having the IPv4 lane capable of handling the IPv4 packet data network type. [¶ 105, The UPF may associate one or more MAC addresses with a PDU session. Information associated with a wireless device may be provided, such as MAC addresses, Ethertype, customer-VLAN tag (C-TAG) and/or service-VLAN tag (S-TAG) VID, C-TAG and/or S-TAG PCP and/or DEI, and/or an IP packet filter set (e.g., if Ethertype indicates an IPv4 and/or an IPv6 payload).]
As to claim 5, The method of claim 1, further comprising establishing an N4 interface between the capable SMF and the UPF associated with the capable SMF.
Qiao teaches, further comprising establishing an N4 interface between the capable SMF and the UPF associated with the capable SMF. [¶ 0086, Additionally or alternatively, the SMF 160 may initiate an N4 session modification procedure with the selected UPF 110, for example, by the SMF 160 sending an N4 session establishment and/or modification request to the UPF 110, and/or by providing one or more packet detection, enforcement and/or reporting rules that may be installed on the UPF 110 for the PDU session.]
As to claim 7, The method of claim 1, wherein the associated UPF with an IPv4 lane capable of handling the IPv4 packet data network type comprises an IPv4 lane or an IPv4 and IPv6 lane.
Qiao teaches, wherein the associated UPF with an IPv4 lane capable of handling the IPv4 packet data network type comprises an IPv4 lane or an IPv4 and IPv6 lane. (¶105, The UPF may associate one or more MAC addresses with a PDU session. Information associated with a wireless device may be provided, such as MAC addresses, Ethertype, customer-VLAN tag (C-TAG) and/or service-VLAN tag (S-TAG) VID, C-TAG and/or S-TAG PCP and/or DEI, and/or an IP packet filter set (e.g., if Ethertype indicates an IPv4 and/or an IPv6 payload).]
As to claim 8, Qiao teaches a session management function, comprising: one or more processors; one or more transceivers; and non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving, at the session management function (SMF), a communication from a network function repository function (NRF) indicating that the SMF is a selected SMF by the NRF, wherein the communication includes a request for IPv4 packet data network type capabilities, wherein the request is responsive to a connection request from a mobile device comprising an indication of an IPv4 packet data network type; [¶ 214, An IP packet filter set may comprise one or more of: a source IP address, a destination IP address, and/or a prefix (e.g., for IPv6); a source port number and/or a destination port number; a protocol ID of the protocol above IP and/or a next header type; a type of service (e.g., for IPv4), a traffic class (e.g., for IPv6), and/or mask; a flow label (e.g., for IPv6); and/or a security parameter index.] [¶ 215, At step 2202, the NEF 125 may perform one or more steps, for example, after or in response to receiving the first message from the DN 115. The NEF 125 may select an SMF (e.g., the SMF 160). The NEF 125 may select an SMF by using an NRF, for example, by providing one or more of the following information, that may be received from the DN 115, to the NRF: wireless device identity and/or identifier; data network name (DNN); PDU session ID; and/or S-NSSAI. The NEF 125 may send, to a selected SMF (e.g., the SMF 160), a second message (e.g., Ethernet MAC addresses provision). The second message may comprise some or all of the information in the first message received from the DN 115 at step 2201.]
determining that the selected SMF is not capable of handling the IPv4 packet data network type; [¶ 36, the SMF 160 may select PDU type of a PDU session as follows: if the SMF 160 receives a request with PDU type set to IP, the SMF 160 may select either PDU type IPv4 or IPv6 based on DNN configuration and/or operator policies. The SMF 160 may also provide a cause value to the wireless device 100 to indicate whether.]
and transmitting to an AMF an identification of a capable SMF based on SMF status datastore information, the capable SMF having an associated UPF with an IPv4 lane capable of handling the IPv4 packet data network type. [¶ 111, At step 1505 (in FIGS. 15A and 15C), the old AMF 155-2 may send, to the new AMF 155-1, a response message. The old AMF 155-2 may respond to the new AMF 155-1 with a response (e.g., a Namf_Communication_UEContextTransfer response) comprising the wireless device 100 SUPI and/or MM context information. If the old AMF 155-2 has information about active PDU sessions, the old AMF 155-2 may include in an existing PDU session(s) (e.g., which may have been established before the response message) one or more of: SMF information (e.g., SMF identities and/or SMF addresses); UPF information (e.g., UPF identities and/or UPF addresses); PDU session ID(s); wireless device address (e.g., for IPv4) and/or wireless device prefix (e.g., for IPv6) if available; and/or DNN if available.]
Qiao fails to teach, querying an SMF status datastore for capabilities of the selected SMF;
However, Sriram teaches, querying an SMF status datastore for capabilities of the selected SMF; [¶ 0028, In some scenarios, the RAN or the Access & Mobility Function (AMF) can indirectly deduce the ATSSS activation on the device by checking the policies configured for the data flow (a service data unit (SDU) session or a packet data unit (PDU) session), for instance, by querying the SMF and PCF.] [¶ 0033, The type of a MA PDU Session 112 may be one of the following types: i.e. IPv4, IPV6, IPv4v6, and Ethernet.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to combine the method of Qiao with the method of Sriram. Doing so would provide “benefits to the network(s) of the multi-RAN network environment 104 and/or the UE 102. For instance, using the features of release 16 to indicate the ATSSS capabilities can result in efficient use of network resources and conserve UE battery life.” [See Sriram, ¶0050]).
The combination of references does not disclose using a redirect message, as recited in the amended claim 1.
However, in a similar endeavor, LÖVSÉN discloses such features by using SMF to send a redirect message (see LÖVSÉN, Fig. 7, [0070] direct a request to an appropriate SMF; [0177] redirect message to SMF 108 handling the connection).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to modify the combination of Qiao and Sriram, to redirect to the most appropriate SMF for the connection using a redirect message, thus improving the handoff procedure based on better connectivity, as suggested by LÖVSÉN.
As to claim 9, The session management function of claim 8, further comprising: determining that the selected SMF is capable of handling the IPv4 packet data network type; and transmitting to the AMF an identification of the selected SMF.
Qiao teaches, further comprising: determining that the selected SMF is capable of handling the IPv4 packet data network type; [¶ 36, the SMF 160 may select PDU type of a PDU session as follows: if the SMF 160 receives a request with PDU type set to IP, the SMF 160 may select either PDU type IPv4 or IPv6 based on DNN configuration and/or operator policies. The SMF 160 may also provide a cause value to the wireless device 100 to indicate whether the other IP version (e.g. IPv6 if IPv4 is selected and vice versa) may be supported on the DNN.]
and transmitting to the AMF an identification of the selected SMF. [¶ 111, At step 1505 (in FIGS. 15A and 15C), the old AMF 155-2 may send, to the new AMF 155-1, a response message. The old AMF 155-2 may respond to the new AMF 155-1 with a response (e.g., a Namf_Communication_UEContextTransfer response) comprising the wireless device 100 SUPI and/or MM context information. If the old AMF 155-2 has information about active PDU sessions, the old AMF 155-2 may include in an existing PDU session(s) (e.g., which may have been established before the response message) one or more of: SMF information (e.g., SMF identities and/or SMF addresses); UPF information (e.g., UPF identities and/or UPF addresses); PDU session ID(s); wireless device address (e.g., for IPv4) and/or wireless device prefix (e.g., for IPv6) if available; and/or DNN if available.]
As to claim 11, The session management function of claim 8, further comprising instantiating an N3 connection from a base station in communication with a mobile device requesting the IPv4 packet data network type to the UPF associated with the capable SMF, the UPF having the IPv4 lane capable of handling the IPv4 packet data network type.
Qiao teaches, further comprising instantiating an N3 connection from a base station in communication with a mobile device requesting the IPv4 packet data network type to the UPF associated with the capable SMF. [¶127, At step 1521 (in FIGS. 15B and 15D), one or more PDU sessions may be modified, such as described further below regarding FIGS. 17A-17B. One or more of the new AMF 155-1, old AMF 155-2, SMF 160, and/or PCF 135 (if supported) may send, to the UPF 110, the (R)AN N3 tunnel information. Interactions between AMF(s), SMF, PCF (if supported), and UPF to modify one or more PDU sessions may correspond to steps 1701 to 1706 in FIGS. 17A-17B. Additionally or alternatively, step 1521 may be performed before step 1527 and/or after step 1526 described below.]
the UPF having the IPv4 lane capable of handling the IPv4 packet data network type.
[¶ 105, The UPF may associate one or more MAC addresses with a PDU session. Information associated with a wireless device may be provided, such as MAC addresses, Ethertype, customer-VLAN tag (C-TAG) and/or service-VLAN tag (S-TAG) VID, C-TAG and/or S-TAG PCP and/or DEI, and/or an IP packet filter set (e.g., if Ethertype indicates an IPv4 and/or an IPv6 payload).]
As to claim 12, The session management function of claim 8, further comprising establishing an N4 interface between the capable SMF and the UPF associated with the capable SMF.
Qiao teaches, further comprising establishing an N4 interface between the capable SMF and the UPF associated with the capable SMF. [¶ 0086, Additionally or alternatively, the SMF 160 may initiate an N4 session modification procedure with the selected UPF 110, for example, by the SMF 160 sending an N4 session establishment and/or modification request to the UPF 110, and/or by providing one or more packet detection, enforcement and/or reporting rules that may be installed on the UPF 110 for the PDU session.]
As to claim 14, The session management function of claim 8, wherein the associated UPF with an IPv4 lane capable of handling the IPv4 packet data network type comprises an IPv4 lane or an IPv4 and IPv6 lane.
Qiao teaches, wherein the associated UPF with an IPv4 lane capable of handling the IPv4 packet data network type comprises an IPv4 lane or an IPv4 and IPv6 lane. [¶ 105, The UPF may associate one or more MAC addresses with a PDU session. Information associated with a wireless device may be provided, such as MAC addresses, Ethertype, customer-VLAN tag (C-TAG) and/or service-VLAN tag (S-TAG) VID, C-TAG and/or S-TAG PCP and/or DEI, and/or an IP packet filter set (e.g., if Ethertype indicates an IPv4 and/or an IPv6 payload).]
As to claim 16, The non-transitory computer-readable media of claim 15, further comprising: determining that the selected SMF is capable of handling the IPN4 packet data network type; and transmitting to the AMF an identification of the selected SMF.
Qiao teaches, further comprising: determining that the selected SMF is capable of handling the IPN4 packet data network type; [¶ 36, the SMF 160 may select PDU type of a PDU session as follows: if the SMF 160 receives a request with PDU type set to IP, the SMF 160 may select either PDU type IPv4 or IPv6 based on DNN configuration and/or operator policies. The SMF 160 may also provide a cause value to the wireless device 100 to indicate whether the other IP version (e.g. IPv6 if IPv4 is selected and vice versa) may be supported on the DNN.]
and transmitting to the AMF an identification of the selected SMF. [¶ 111, If the old AMF 155-2 has information about active PDU sessions, the old AMF 155-2 may include in an existing PDU session(s) (e.g., which may have been established before the response message) one or more of: SMF information (e.g., SMF identities and/or SMF addresses); UPF information (e.g., UPF identities and/or UPF addresses); PDU session ID(s); wireless device address (e.g., for IPv4) and/or wireless device prefix (e.g., for IPv6) if available; and/or DNN if available.]
As to claim 18, The non-transitory computer-readable media of claim 15, further comprising instantiating an N3 connection from a base station in communication with the mobile device to the UPF associated with the capable SMF. the UPF having the IPv4 lane capable of handling the IPv4 packet data network type.
Qiao teaches, further comprising instantiating an N3 connection from a base station in communication with the mobile device to the UPF associated with the capable SMF. [¶ 127, At step 1521 (in FIGS. 15B and 15D), one or more PDU sessions may be modified, such as described further below regarding FIGS. 17A-17B. One or more of the new AMF 155-1, old AMF 155-2, SMF 160, and/or PCF 135 (if supported) may send, to the UPF 110, the (R)AN N3 tunnel information. Interactions between AMF(s), SMF, PCF (if supported), and UPF to modify one or more PDU sessions may correspond to steps 1701 to 1706 in FIGS. 17A-17B. Additionally or alternatively, step 1521 may be performed before step 1527 and/or after step 1526 described below.]
the UPF having the IPv4 lane capable of handling the IPv4 packet data network type. [¶ 105, The UPF may associate one or more MAC addresses with a PDU session. Information associated with a wireless device may be provided, such as MAC addresses, Ethertype, customer-VLAN tag (C-TAG) and/or service-VLAN tag (S-TAG) VID, C-TAG and/or S-TAG PCP and/or DEI, and/or an IP packet filter set (e.g., if Ethertype indicates an IPv4 and/or an IPv6 payload).]
As to claim 19, The non-transitory computer-readable media of claim 15, further comprising establishing an N4 interface between the capable SMF and the UPF associated with the capable SMF.
Qiao teaches, further comprising establishing an N4 interface between the capable SMF and the UPF associated with the capable SMF. [¶ 0086, Additionally or alternatively, the SMF 160 may initiate an N4 session modification procedure with the selected UPF 110, for example, by the SMF 160 sending an N4 session establishment and/or modification request to the UPF 110, and/or by providing one or more packet detection.]
Claim 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Qiao et al. (US 12401536 B2, hereinafter Qiao et al.) in view of Sriram et al. (US 20240224027 A1, hereinafter Sriram et al.) in further view of Purkayastha et al. (US 20210176613 A1, hereinafter Purkayastha et al.)
As to claim 6, Qiao and Sriram fail to teach, wherein a packet data network handling the IPv4 packet data comprises one or more of: an Internet; or an IP multimedia subsystem.
However, Purkayastha teaches, wherein a packet data network handling the IPv4 packet data comprises one or more of: an Internet; or an IP multimedia subsystem. [¶ 0033, As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.] [¶ 0063, For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.] [¶ 0099, Each PDU session may support a single PDU session type (e.g., support the exchange of a single type of PDU requested by the WTRU at the establishment of the PDU session). The following example PDU session types may be defined: IPv4, IPv6, Ethernet, and Unstructured (where the type of PDU exchanged between the WTRU and DN may be transparent to the 5G system).]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to combine the method of Qiao and Sriram with the method of Purkayastha. Doing so would “enable service and content providers to offer their applications and services on the edge of the network, rather than utilizing applications in data centers, reaching over the core network” [See Purkayastha, ¶0002]).
As to claim 13, Qiao and Sriram fail to teach, the session management function of claim 8, wherein a packet data network handling the IPv4 packet data comprises one or more of: an Internet; or an IP multimedia subsystem.
However, Purkayastha teaches, the session management function of claim 8, wherein a packet data network handling the IPv4 packet data comprises one or more of: an Internet; or an IP multimedia subsystem. [¶ 0033, As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.] [¶ 0063, For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.] [¶ 0099, Each PDU session may support a single PDU session type (e.g., support the exchange of a single type of PDU requested by the WTRU at the establishment of the PDU session). The following example PDU session types may be defined: IPv4, IPv6, Ethernet, and Unstructured (where the type of PDU exchanged between the WTRU and DN may be transparent to the 5G system).]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to combine the method of Qiao and Sriram with the method of Purkayastha. Doing so would “enable service and content providers to offer their applications and services on the edge of the network, rather than utilizing applications in data centers, reaching over the core network” [See Purkayastha, ¶0002]).
As to claim 20, Qiao and Sriram fail to teach, the non-transitory computer-readable media of claim 15, wherein a packet data network handling the IPv4 packet data comprises one or more of: an Internet: or an IP multimedia subsystem.
Qiao and Sriram fail to teach, the non-transitory computer-readable media of claim 15, wherein a packet data network handling the IPv4 packet data comprises one or more of: an Internet: or an IP multimedia subsystem. [¶ 0033, As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.] [¶ 0063, For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.] [¶ 0099, Each PDU session may support a single PDU session type (e.g., support the exchange of a single type of PDU requested by the WTRU at the establishment of the PDU session). The following example PDU session types may be defined: IPv4, IPv6, Ethernet, and Unstructured (where the type of PDU exchanged between the WTRU and DN may be transparent to the 5G system).]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant's claimed invention to combine the method of Qiao and Sriram with the method of Purkayastha. Doing so would “enable service and content providers to offer their applications and services on the edge of the network, rather than utilizing applications in data centers, reaching over the core network” [See Purkayastha, ¶0002]).
Allowable Subject Matter
Claims 3, 10, and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Qiao and Sriram and LÖVSÉN fail to teach or suggest, wherein transmitting to the AMF the identification of the capable SMF comprises using 308 code.
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 KATHY W WANG-HURST whose telephone number is (571)270-5371. The examiner can normally be reached Monday-Friday, 8:30am-5:00pm.
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.
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.
/KATHY W WANG-HURST/Supervisory Patent Examiner, Art Unit 2644
Prosecution Insights