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 .
Claim Interpretation
Claims 1, 16 and 30, recite, “receiving, via a first network connection with a serving network, configuration information, the configuration information specifying the serving network and including a traffic routing policy rule comprising a traffic descriptor for identifying traffic of the localized service to be routed via the hosting network; detecting that a traffic flow matches the traffic routing policy rule; responsive to detecting that the traffic flow matches the traffic routing policy rule, selecting the hosting network; and establishing a second network connection with the hosting network”
Here the “detecting that a traffic flow matches the traffic routing policy rule; responsive to detecting that the traffic flow matches the traffic routing policy rule, selecting the hosting network” This is contingent/conditional limitation(s). The contingent/conditional limitations are not positively recited in the claim(s) and are thus only executed [or performed or implemented], when the condition is true/met.
[See, (MPEP 2111.04) II. CONTINGENT LIMITATIONS
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent is not met.]
In present claim 1 for instance selecting the hosting network, is only performed when the detecting traffic flow matches traffic routing policy rule; otherwise, this step is not performed, and the prior art is not required to teach this element when the condition is not met. And subsequently the establishing the second network connection with hosting network not required.
However, for compact prosecution, examiner has addressed these limitations.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 16, 19, 20, 22, 25-26 and 30-35 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Poncorbo Marcos et al. (US 2023/0189105) (hereafter Marcos).
Regarding claims 1, 16 and 30, Marcos discloses a method performed by a user equipment (UE), the method comprising:
receiving, via a first network connection with a serving network, configuration information, the configuration information specifying the serving network and including a traffic routing policy rule including a traffic descriptor for identifying traffic of a localized service to be routed via a hosting network (see, Fig., 3 S100, obtain a policy node of a first network, a UE route selection policy (URSP) associated with an application, para, [0011], the transfer policy indicates a network identifier, the network identifier identifying one of the first network and the second network to which the application is to be transferred to. In some embodiments, the transfer policy indicates an application identifier, the application identifier identifying the application that is to be transferred according to the transfer policy. In some embodiments, the transfer policy indicates a preferred access type, the preferred access type comprising a network identifier identifying one of the first network and the second network to which the application is to be transferred to, [0012], the transfer policy indicates a route selection descriptor, RSD, the RSD indicating the preferred access type and the network identifier);
detecting that a traffic flow matches the traffic routing policy rule (see, S102, Fig. 3, [0012], the traffic descriptor further comprises a rule correlation identifier, ID; the method further comprising determining whether the rule correlation ID is a same for both the first network and the second network; and sending traffic to one of the first network and the second network based at least in part on whether the rule correlation ID is the same);
responsive to detecting that the traffic flow matches the traffic routing policy rule, selecting the hosting network ([0091], a transfer policy response identifying a transfer policy, the transfer policy indicating whether the application is to be transferred to using a second network, the second network being different from the first network associated with the policy node 16, the first network being one of a standalone non-public network, SNPN, and a public land mobile network, PLMN and the second network being another one of the SNPN and the PLMN and the transfer policy being based at least in part on at least one of: (i) Quality-of-service, QoS, information associated with the application and (ii) whether the UE 12 has a subscription to the second network ); and
establishing a second network connection with the hosting network (see, para [0091]).
Regarding claims 19, Marcos further discloses a network node (see, para [0049], network node) a serving network of a user equipment (UE) (see, para [0049]), comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network node to:
determine that the UE has to be arranged to allow the UE to use a localized service in a hosting network (see, para [0011], see, S112, obtain a transfer policy from a policy node of a first network, the transfer policy is associated with network selection, the transfer policy indicates a network identifier, the network identifier identifying one of the first network and the second network to which the application is to be transferred to. In some embodiments, the transfer policy indicates an application identifier, the application identifier identifying the application that is to be transferred according to the transfer policy. In some embodiments, the transfer policy indicates a preferred access type, the preferred access type comprising a network identifier identifying one of the first network and the second network to which the application is to be transferred to, see, Fig. 6, S114, determine whether the application is transferred from using first network to using second network based on obtained transfer policy); and
generate configuration information, the configuration information specifying the hosting network and including a traffic routing policy rule comprising a traffic descriptor for identifying traffic of the localized service to be routed via the hosting network (see, [0012], the transfer policy indicates a route selection descriptor, RSD, the RSD indicating the preferred access type and the network identifier. In some embodiments, the transfer policy includes information indicating a traffic associated with the application. In some embodiments, the information is comprised in a traffic descriptor, the traffic descriptor identifying the application that is to be transferred according to the transfer policy); and
send the generated configuration information to the UE (see, Fig. 6, obtain a transfer policy, see, para [0037], providing the URSP rules to the UE on which network the UE is to use for the user data related to application and/or provide that the network that the UE has to use (e.g. according to policy)).
Regarding claim 20, Marcos further discloses the network node, wherein the network node includes a policy control function (PCF) arranged to trigger a UE policy update procedure to send the generated configuration information to the UE (see, para [0012], the transfer policy is a UE route selection policy, URSP, and the policy node comprises a policy control function, PCF, see, [0052], network node is policy control function (PCF) ).
Regarding claim 22, Marcos further discloses the UE, wherein the at least one processor is further configured to cause the UE to route the traffic flow to the hosting network via the second network connection (([0091], a transfer policy response identifying a transfer policy, the transfer policy indicating whether the application is to be transferred to using a second network, the second network being different from the first network associated with the policy node 16, the first network being one of a standalone non-public network, SNPN, and a public land mobile network, PLMN and the second network being another one of the SNPN and the PLMN and the transfer policy being based at least in part on at least one of: (i) Quality-of-service, QoS, information associated with the application and (ii) whether the UE 12 has a subscription to the second network ).
Regarding claim 25, Marcos further discloses the UE, wherein the traffic routing policy rule is a UE route selection policy (URSP) rule (see, para [0037], ), and the URSP rule comprises one or more route selection descriptors (RSDs) (see, para [0012], [0020], [0079], [0037], [0083], providing a UE 12 route selection policy (URSP) rule indicating the negotiated transfer policy. In some embodiments, one or more of: the URSP includes a route selection descriptor (RSD)).
Regarding claim 26, Marcos further discloses the UE, wherein the one or more RSDs include at least one of: one or more session and service continuity mode selections, one or more network slice selections, one or more data network name selections, one or more protocol data unit session type selections, one or more non-seamless offload indications, or one or more access type preferences (see, para [0126], network slice selection).
Regarding claim 31, Marcos further discloses the processor, wherein the configuration information further comprises one or more of: a list of one or more preferred hosting networks (see, para [0011]); one or more selection criteria associated with the one or more preferred hosting networks (see, [0012], route selection descriptor); one or more availability conditions associated with the one or more preferred networks; statement of requirements information associated with the localized service; one or more service IDs associated with the localized service; a list of the one or more preferred hosting networks and, for each network of the one or more preferred hosting networks, one or more respective associated localized services; or one or more application IDs associated with an application that uses the localized service (see, para [0015], application identifiers).
Regarding claim 32, Marcos further discloses the processor of claim 31, wherein the configuration information comprises one or more selection criteria associated with the one or more preferred hosting networks, the one or more selection criteria including at least one of: an indication of an application which is associated with the processor and uses the localized service (see, para [0015], transfer policy indicates the application identifier, [0079]); a time duration during which the hosting network may be selected (see, para [0010], [0014]); or a location of the processor at which the hosting network may be selected.
Regarding claim 33, Marcos further discloses the processor of claim 30, wherein the traffic routing policy rule comprises an identifier of the hosting network (see, para [0011]).
Regarding claim 34, Marcos further discloses the processor of claim 30, wherein the serving network is a home network to which the processor has subscribed, and the serving network stores a subscription permanent identifier (SUPI) and one or more credentials of the processor ([0199], SUPI identifier, [0083], storing the transfer policy and corresponding rule identifier).
Regarding claim 35, Marcos further discloses the processor of claim 30, wherein the traffic descriptor includes at least one of: one or more application descriptors (see, para [0011], application identifier); one or more Internet Protocol (IP) flow descriptors; one or more target addresses of application traffic; one or more data network names requested by an application; or one or more connection capabilities requested by the application.
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 non-obviousness.
Claim(s) 21 is rejected under 35 U.S.C. 103 as being unpatentable over Marcos in view of Hong (US 2024/0236837) (hereafter Hong).
Regarding claim 21, Marcos further discloses the network node wherein the network node includes a unified data management (UDM) (see, para [0099], UDM) system but does not explicitly disclose its arranged to use a UE parameter update procedure or steering of roaming procedure to provision a list of preferred hosting network. However, in same field of endeavor, Hong teaches in para [0070], the first communication node sends the network selection information to the second communication node by using a steering of roaming (SoR) message. See, para [0093], after receiving the request message for acquiring the network selection information sent by the second communication node, the first communication node may use a steering of roaming (SoR) message to send the network selection information to the second communication node. Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Hong with the Marcos, as a whole so as to use the procedure of steering of roaming to select the network.
10. Claim(s) 23 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Marcos in view of Hind et al. (US2006/0172737)(hereafter Hind).
Regarding claim 23, Marcos does not explicitly disclose the UE of claim 22, wherein selection of the hosting network is an automatic network selection procedure, however, in same field of endeavor, Hind teaches [0008], wherein the network selection procedure comprises an automatic network selection procedure of the mobile communication device. [0063] also teaches network selection could be automatic. Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Hind with the Marcos, as a whole so as to select the network automatically.
Regarding claim 24, Marcos further discloses the UE, wherein to perform the automatic network selection procedure, the at least one processor is further configured to cause the UE to: conduct a scan to determine one or more available networks; and select the hosting network from the one or more available network (see, para [0078]).
11. Claim(s) 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over Marcos in view of Dods et al. (US 10862805)(hereafter Dods).
Regarding claim 27, Marcos does not disclose the UE, wherein a first RSD of the one or more RSDs comprises a hosting network offload component, the hosting network offload component being settable between a plurality of states, a first state of the plurality of states indicating that offload via the hosting network should be performed, and a second state of the plurality of states indicating that offload via the hosting network should not be performed.
However, in same field of endeavor, Dods teaches col. 6, lines 30-37, in this case, the network device may process the set of offloading indicators with the set of assumptions to generate an overall indicator value that may be used to determine whether to offload the traffic flow of the session. Additionally, the network device may compare the overall indicator value to a threshold overall indicator value (e.g., which may be configured) to determine whether the session is a high-throughput session.
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Dods with the Marcos, as a whole so as to use network offload function to determine whether to offload the traffic or not, the motivation is to perform intelligent offloading of services for a network device.
Regarding claim 28, the combined teaching further discloses the UE wherein the at least one processor is further configured to cause the UE to, responsive to the network offload component being in the first state, initiate an automatic network selection procedure (col. 6 lines 63-67 and col. 7 lines 1-6).
12. Claim(s) 29 are rejected under 35 U.S.C. 103 as being unpatentable over Marcos in view of Dods and further in view of Wang et al. (US 2015/0139056) (hereafter Wang).
Regarding claim 29, the combined teachings do not disclose wherein the at least one processor is further configured to cause the UE to, responsive to the network offload component being in the second state, initiate a transfer of the UE to an idle state and/or requesting release of the UE from the first connection with the serving network. However, Wang teaches [0103] Step S908, if the network side determines that there is no offload demand within a period of time, the network element of the 3GPP access network may instruct the UE to release the association with the WLAN access network via an RRC request signaling and switches off the WiFi module; and the UE replies with an acknowledge message to the 3GPP network to inform same after receiving the message and releasing the associated with the WLAN. Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Wang with Marcos and Dods, as a whole so as to configure the UE as claimed to release the connection with the network, the motivation is to controlling and configuring a state of function of the UE.
13. Claim(s) 36 is rejected under 35 U.S.C. 103 as being unpatentable over Marcos in view of Soliman et al. (US 2022/0377654)(hereafter Soliman).
Regarding claim 36, Marcos does not disclose the processor, wherein the at least one controller is further configured to cause the processor to: receive, via the first network connection with the serving network, further configuration information, wherein the further configuration information specifies a further hosting network and includes a further traffic routing policy rule including a further traffic descriptor for identifying traffic of a further localized service to be routed via the further hosting network; detect that a further traffic flow matches the further traffic routing policy rule; and responsive to detecting that the further traffic flow matches the further traffic routing policy rule, establish a third network connection with the further hosting network.
But Marcos does teach determine that the UE has to be arranged to allow the UE to use a localized service in a hosting network (see, para [0011], see, S112, obtain a transfer policy from a policy node of a first network, the transfer policy is associated with network selection, the transfer policy indicates a network identifier, the network identifier identifying one of the first network and the second network to which the application is to be transferred to. In some embodiments, the transfer policy indicates an application identifier, the application identifier identifying the application that is to be transferred according to the transfer policy. In some embodiments, the transfer policy indicates a preferred access type, the preferred access type comprising a network identifier identifying one of the first network and the second network to which the application is to be transferred to, see, Fig. 6, S114, determine whether the application is transferred from using first network to using second network based on obtained transfer policy); and generate configuration information, the configuration information specifying the hosting network and including a traffic routing policy rule comprising a traffic descriptor for identifying traffic of the localized service to be routed via the hosting network (see, [0012], the transfer policy indicates a route selection descriptor, RSD, the RSD indicating the preferred access type and the network identifier. In some embodiments, the transfer policy includes information indicating a traffic associated with the application. In some embodiments, the information is comprised in a traffic descriptor, the traffic descriptor identifying the application that is to be transferred according to the transfer policy); and send the generated configuration information to the UE (see, Fig. 6, obtain a transfer policy, see, para [0037], providing the URSP rules to the UE on which network the UE is to use for the user data related to application and/or provide that the network that the UE has to use (e.g. according to policy)). In same field of endeavor, Soliman teaches in para [0019], The traffic descriptor of a URSP rule specifies a matching criterion that is matched against the application that is triggered by the UE. The traffic descriptor may list one or more application identifiers and/or one or more data network names. The RSD of the URSP rule identifies one or more network slices (e.g. one or more single network slice selection assistance information (S-NSSAIs)), one or more DNNs, and one PDU session type, among other items. See, para [0040], A URSP rule that has the traffic source parameter and also includes other elements of a traffic descriptor will be evaluated by the relay UE for remote UE traffic against traffic descriptor information obtained from the remote UE (when triggering an application). This convention supports use cases 1 and 3 of FIGS. 3 and 5, respectively. A URSP rule that includes the traffic source parameter set to remote UE traffic and includes no other elements of a traffic descriptor is used by the relay UE to route all traffic from remote UEs to the corresponding RSD (e.g., network slice). [0041], the method includes receiving a UE route selection policy (URSP) from a network. The URSP includes respective URSP rules for routing UE traffic through respective network slices to the network. A first URSP rule indicates whether an associated first network slice is designated for remote UE traffic, relay UE traffic, or both remote UE traffic and relay UE traffic.
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to modify the teachings of the Marcos to further identify the further network using further traffic policy using the Soliman , to establish a third network connection with the further hosting network, the motivation is to perform policy based selection of network.
Conclusion
14. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Youtz et al. (US 2021/0314818) discloses INSTRUCTING A USER EQUIPMENT TO UTILIZE A FIFTH GENERATION (5G) NETWORK INSTEAD OF A WIRELESS NETWORK.
Kim et al. (US 2021/0160740) discloses TRANSMITTING/RECEIVING METHOD FOR ENSURING CONNECTIVITY IN WIRE-LESS COMMUNICATION SYSTEM, AND DEVICE THEREFOR.
Yu et al. (US 2022/0053444) discloses Network Communication Method And Apparatus.
Xu et al. (US 2022/0124595) discloses METHODS FOR WIRELESS COMMUNICATION, TERMINAL DEVICE, AND NETWORK DEVICE.
Miklos et al. (US 2022/0272031) discloses UE ROUTE SELECTION POLICIES FOR MULTI-PORT DEVICES.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DHAVAL V PATEL whose telephone number is (571)270-1818. The examiner can normally be reached Monday to Friday (8:00am-4:30pm).
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, Hannah Wang can be reached at 571-272-9018. 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.
/DHAVAL V PATEL/Primary Examiner, Art Unit 2631
Prosecution Insights