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 .
Status of the Claims
The office action is in response to the claim amendments and remarks filed on October 24, 2025 for the application filed December 20, 2022. Claims 1, 7, and 15 have been amended. Claims 1-20 are currently pending.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-9, 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jahangir et al. (US2018/0007612A1), in view of Diaz et al. (US2012/0250622A1).
Regarding claim 1, Jahangir teaches a system for wireless communication, comprising: a Proxy Call Session Control Function (P-CSCF) that is in communication with a mobile device in a network; a first Serving Call Session Control Function (S-CSCF) configured to handle a first part of a communication with the mobile device; a Telephony Application Server (TAS) configured to store information about routing options that are available to the communication of the mobile device; and a second S-CSCF that is selected upon the first S-CSCF being unreachable to other network nodes in the network (Abstract: A communication session for a UE can be restored in the event of serving call session control function (S-CSCF) node unavailability and/or application server (AS) unavailability by storing, prior to IMS unavailability, attribute-value pairs (AVPs) at a home subscriber server (HSS). These AVPs can be used independently by individual IMS nodes to restore a communication session for a UE due to an unavailable IMS node. When a first S-CSCF node becomes unavailable, a proxy CSCF (P-CSCF) node can send a SIP request originating from the UE to a second S-CSCF node. Paragraph [0002]: During a registration procedure with the IMS core network, the UE is assigned a serving call session control function (S-CSCF) node and an application server (AS). These assigned nodes are tasked with serving the UE during a subsequent communication session, and all signaling originating from, and terminating at, the UE during the communication session is to be routed through the assigned nodes of the IMS core. Paragraph [0030]: The first S-CSCF node 104 receives the SIP request 110 from the P-CSCF node 102 (or from an intermediate IMS node), and forwards the SIP request 110 to the first AS 106. The first AS 106 can be configured to provide any of the IMS-based services described herein as part of a subsequently established communication session.)
wherein the second S-CSCF is configured to: receive an unregistered request for a remaining part of the communication with the mobile device; determine a routing option based on the routing options stored by the TAS that are available to the communication with the mobile device, wherein the routing options indicate at least one of (3) whether binding information between the P-CSCF and the mobile device is stored by the TAS or retrievable, and route the communication using the routing option without triggering a new registration procedure (Abstract: A communication session for a UE can be restored in the event of serving call session control function (S-CSCF) node unavailability and/or application server (AS) unavailability by storing, prior to IMS unavailability, attribute-value pairs (AVPs) at a home subscriber server (HSS). These AVPs can be used independently by individual IMS nodes to restore a communication session for a UE due to an unavailable IMS node. When a first S-CSCF node becomes unavailable, a proxy CSCF (P-CSCF) node can send a SIP request originating from the UE to a second S-CSCF node. The second S-CSCF node can then send a request to the HSS for an identifier of an AS associated with the UE. Upon receipt of the AS identifier (e.g., an active AS name AVP) from the HSS, the second S-CSCF node can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0015]: Accordingly, a registration procedure for a UE includes sending, from an AS, and to a HSS for storage at the HSS, a first value for an “active AS name” attribute (i.e., a first AVP) and a second value for a “user registration data” attribute (i.e., a second AVP). These AVPs can be transmitted over a Diameter (Cx) interface from the AS to the HSS. Thus, at registration, the HSS stores, for a particular UE, the first AVP for the active AS name attribute and the second AVP for the user registration data attribute. Maintaining these AVPs in repository data of the HSS for a given UE allows for restoring a communication session for the UE in the event of S-CSCF node unavailability and/or AS unavailability. The storage of these AVPs in the HSS repository allows an individual IMS node to interact directly with the HSS to obtain information it can use to restore the communication session without having to tear down the communication session or issue unneeded communications to other IMS nodes. Paragraph [0017]: In the event that the first S-CSCF node is determined to be unavailable, a process for restoring the communication session for the UE can include selecting, by the P-CSCF node, a second S-CSCF node, and sending, via the communications interface of the P-CSCF node, the SIP request to the second S-CSCF node. The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Thus, the techniques and systems described herein do not force the UE to re-register on the IMS core, unlike existing IMS restoration procedures. Paragraph [0030]: The first S-CSCF node 104 receives the SIP request 110 from the P-CSCF node 102 (or from an intermediate IMS node), and forwards the SIP request 110 to the first AS 106. Paragraph [0031]: As shown in FIG. 1, the first AS 106 is further configured to send multiple attribute-value pairs (AVPs) 114 to the HSS 108 for storage at the HSS 108 as part of the registration procedure for the UE 100. Paragraph [0042]: In response to determining that the first S-CSCF node 104 is unavailable, an IMS restoration technique is initiated where the P-CSCF node 102 selects a second S-CSCF node 202 (labeled “S-CSCF-B” 202 in FIG. 2), and sends the SIP request 200 to the second S-CSCF node 202. The P-CSCF node 102 is configured with “route advance” logic to select a different, available S-CSCF node as a backup without tearing down the current communication session. Paragraph [0046]: The second S-CSCF node 202 can therefore send a request (via the UDR message 210) for an identifier of the first AS 106 that is associated with the UE 100. Paragraph [0047]: The HSS 108 can transmit a user data answer (UDA) message 212 to the second S-CSCF 202 that includes the identifier of the first AS 106. Recall that the identifier of the first AS 106 was previously stored in the master database 118 as the first value of the first AVP 114(1) for the active AS name attribute. The identifier of the first AS 106 that is returned in the UDA message 212 can comprise a SIP URI for the first AS 106. An example of a UDA message 212 is as follows: UDA (AS SIP URI). Upon receiving the UDA message 212, the second S-CSCF 202 now has the AS mapping for the UE 100 that can be used to restore the communication session for the UE 100. Paragraph [0048]: Using the AS mapping from the UDA message 212, the second S-CSCF node 202 can send the SIP request 200 to the first AS 106 identified by the first value for the active AS name AVP 114(1). Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Jahangir does not explicitly teach wherein when the binding information between the P-CSCF and the mobile device is not stored by the TAS or retrievable, the second S-CSCF is further configured to route the communication using circuit switched fall back.
However, Diaz teaches wherein when the binding information between the P- CSCF and the mobile device is not stored by the TAS or retrievable, the second S-CSCF is further configured to route the communication using circuit switched fall back (Paragraph [0020]: When routing the request for communication towards the circuit-switched network, this may be achieved by the service identifier node modifying the recipient included in the request for communication by adding a prefix which indicates the request should be routed towards the circuit-switched network and then routing the communication through the circuit-switched network. A convenient means of achieving this is by returning the request to a serving call session control function node (S-CSCF), from which it may have originally been directed to the service identifier node, before onward routing through the network to the recipient user. However, in an alternative approach the service identifier node may obtain the direction of the “following” node towards which the request is to be routed and then route the request to the said following node. In turn, the said following node may route the communication through the circuit switched network. Paragraph [0051]: In operation, said SIAS node of this example receives from the S-CSCF of the IMS network a message to request communication addressed to a user A, said message includes information about said communication features. If said communication features are not allowed for said user A or said user A is not in the database, an error message is sent to the S-CSCF. Paragraph [0052]: If the requested communication is voice-type communication or it is indicated in the database that the user wants the communication to be routed through the circuit switched network for the type of communication indicated in the request for communication, the SIAS node routes the message to request communication towards the circuit switched network. Also see Paragraphs [0066], [0068] - [0069] which indicates that the SIAS node equivalent to a TAS).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein when the binding information between the P- CSCF and the mobile device is not stored by the TAS or retrievable, the second S-CSCF is further configured to route the communication using circuit switched fall back, as taught by Diaz in the system of Jahangir, in order to route the communication to a circuit switched network based on the session content and the user, which improves the assignment of resources in communication networks providing multimedia services (Diaz: Paragraphs [0014], [0018], [0020], [0051], [0052]).
Regarding claim 2, the combination of Jahangir and Diaz teaches the system of claim 1 (see rejection for claim 1);
Jahangir further teaches wherein the routing options that are available to the communication are stored in a user profile associated with the mobile device (Paragraph [0015]: Accordingly, a registration procedure for a UE includes sending, from an AS, and to a HSS for storage at the HSS, a first value for an “active AS name” attribute (i.e., a first AVP) and a second value for a “user registration data” attribute (i.e., a second AVP). These AVPs can be transmitted over a Diameter (Cx) interface from the AS to the HSS. Thus, at registration, the HSS stores, for a particular UE, the first AVP for the active AS name attribute and the second AVP for the user registration data attribute. Maintaining these AVPs in repository data of the HSS for a given UE allows for restoring a communication session for the UE in the event of S-CSCF node unavailability and/or AS unavailability. The storage of these AVPs in the HSS repository allows an individual IMS node to interact directly with the HSS to obtain information it can use to restore the communication session without having to tear down the communication session or issue unneeded communications to other IMS nodes. Paragraph [0031]: As shown in FIG. 1, the first AS 106 is further configured to send multiple attribute-value pairs (AVPs) 114 to the HSS 108 for storage at the HSS 108 as part of the registration procedure for the UE 100. Paragraph [0032]: The AVPs 114 can be transmitted from the first AS 106 to the HSS 108 over a Diameter interface in the form of a profile update request (PUR) message. Paragraph [0034]: The HSS 108 can be associated with a master database 118 (sometimes referred to herein as an “HSS repository”) that maintains data pertaining to UEs 100 that have registered, or are in the process of registering, on the IMS network. FIG. 1 shows HSS repository data as including the first, “active AS name” AVP 114(1) and the second, “user registration data” AVP 114(2) as a result of the PUR message 116 received from the first AS 106 during registration. FIG. 1 also shows an example first value of the active AS name AVP 114(1) that identifies the first AS 106 as “AS-A.” Thus, the first, active AS name AVP 114(1) reflects the assignment of the first AS 106 to the UE 100 (sometimes referred to as an “AS binding”). Thus, storage of the first, active AS name AVP 114(1) in the master database 118 of the HSS 108 creates a binding between the UE 100 and the first AS 106 that is maintained in the HSS repository 118. Similarly, the storage of one or more second values for the second, user registration data AVP 114(2) in the master database 118 reflects information for a user profile associated with the UE 100.)
Regarding claim 3, the combination of Jahangir and Diaz teaches the system of claim 2 (see rejection for claim 2);
Jahangir further teaches wherein the second S-CSCF is configured to: receive the user profile from a home server configured to manage subscriber information (Abstract: When a first S-CSCF node becomes unavailable, a proxy CSCF (P-CSCF) node can send a SIP request originating from the UE to a second S-CSCF node. The second S-CSCF node can then send a request to the HSS for an identifier of an AS associated with the UE. Upon receipt of the AS identifier (e.g., an active AS name AVP) from the HSS, the second S-CSCF node can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0017]: The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0043]: In response to receiving the SIP request 200, the second S-CSCF node 202 is configured to send a request for restoration information to the HSS 108 over a Diameter interface. Paragraph [0046]: Accordingly, the second S-CSCF node 202 is configured to send a UDR message 210 to the HSS 108 in order to obtain, from the HSS repository 118, the first value of the active AS name AVP 114(1) that was stored in the master database 118 during registration of the UE 100.)
Regarding claim 4, the combination of Jahangir and Diaz teaches the system of claim 2 (see rejection for claim 2);
Jahangir further teaches wherein the TAS is configured to: receive the user profile from a home server configured to manage subscriber information (Paragraph [0031]: As shown in FIG. 1, the first AS 106 is further configured to send multiple attribute-value pairs (AVPs) 114 to the HSS 108 for storage at the HSS 108 as part of the registration procedure for the UE 100. Paragraph [0032]: The AVPs 114 can be transmitted from the first AS 106 to the HSS 108 over a Diameter interface in the form of a profile update request (PUR) message. Paragraph [0034]: The HSS 108 can be associated with a master database 118 (sometimes referred to herein as an “HSS repository”) that maintains data pertaining to UEs 100 that have registered, or are in the process of registering, on the IMS network. FIG. 1 shows HSS repository data as including the first, “active AS name” AVP 114(1) and the second, “user registration data” AVP 114(2) as a result of the PUR message 116 received from the first AS 106 during registration. FIG. 1 also shows an example first value of the active AS name AVP 114(1) that identifies the first AS 106 as “AS-A.” Thus, the first, active AS name AVP 114(1) reflects the assignment of the first AS 106 to the UE 100 (sometimes referred to as an “AS binding”). Thus, storage of the first, active AS name AVP 114(1) in the master database 118 of the HSS 108 creates a binding between the UE 100 and the first AS 106 that is maintained in the HSS repository 118. Similarly, the storage of one or more second values for the second, user registration data AVP 114(2) in the master database 118 reflects information for a user profile associated with the UE 100. Paragraph [0049]: In response to receiving the SIP request 200 with a different, and unfamiliar, S-CSCF name in the message header, the first AS 106 can confirm the new UE-to-S-CSCF-B association by contacting the HSS 108 over a Diameter interface. This confirmation request is shown in FIG. 2 by the UDR message 214 sent from the first AS 106 to the HSS 108. This UDR message 214 acts as a request by the first AS 106 to confirm that the HSS 108 has updated the S-CSCF binding 206 for the UE 100 with the identifier of the second S-CSCF 202 in the master database 118. The UDR message 214 can include a request for the UE's 100 registration status and the S-CSCF name. An example of a UDR message 214 sent from the first AS 106 is as follows: UDR (User State/S-CSCF Name).)
and store the information about the routing options in a local cache of the TAS or an external database accessible to the TAS (Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Regarding claim 6, the combination of Jahangir and Diaz teaches the system of claim 1 (see rejection for claim 1);
Jahangir further teaches wherein the second S-CSCF is configured to: receive, from the TAS, the routing options that are available to the communication of the mobile device (Paragraph [0017]: In the event that the first S-CSCF node is determined to be unavailable, a process for restoring the communication session for the UE can include selecting, by the P-CSCF node, a second S-CSCF node, and sending, via the communications interface of the P-CSCF node, the SIP request to the second S-CSCF node. The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0046]: The second S-CSCF node 202 can therefore send a request (via the UDR message 210) for an identifier of the first AS 106 that is associated with the UE 100. Paragraph [0047]: The HSS 108 can transmit a user data answer (UDA) message 212 to the second S-CSCF 202 that includes the identifier of the first AS 106. Recall that the identifier of the first AS 106 was previously stored in the master database 118 as the first value of the first AVP 114(1) for the active AS name attribute. The identifier of the first AS 106 that is returned in the UDA message 212 can comprise a SIP URI for the first AS 106. An example of a UDA message 212 is as follows: UDA (AS SIP URI). Upon receiving the UDA message 212, the second S-CSCF 202 now has the AS mapping for the UE 100 that can be used to restore the communication session for the UE 100. Paragraph [0081]: At 522, the second S-CSCF node 202 can send, via the communications interface of the second S-CSCF node 202, the SIP request 200 to the first AS 106 identified by the identifier received at 512. Paragraph [0082]: At 524, and in response to receiving the SIP request 200 with a different, and unfamiliar, S-CSCF name in the message header, the AS identified by the identifier received at 520 can confirm the new UE-to-S-CSCF-B association by contacting the HSS 108 over a Diameter interface. This confirmation request is shown in FIG. 2 by the UDR message 214 sent from the first AS 106 to the HSS 108. This UDR message 214 acts as a request by the first AS 106 to confirm that the HSS 108 has updated the S-CSCF binding 206 for the UE 100 with the identifier of the second S-CSCF 202 in the master database 118. The UDR message 214 can include a request for the UE's 100 registration status and the S-CSCF name.)
Regarding claim 7, Jahangir teaches a method for wireless communication, comprising: receiving, by a network node in a network, an unregistered request for a communication of a user device; determining, by the network node, a routing option based on routing options stored by a Telephony Application Server (TAS) that are available to the communication of the user device, wherein the routing options indicate at least one of (3) whether binding information between a Proxy Call Session Control Function (P-CSCF) and the user device is stored by the TAS or retrievable, and routing, by the network node, the communication using the routing option without triggering a new registration procedure (Paragraph [0002]: During a registration procedure with the IMS core network, the UE is assigned a serving call session control function (S-CSCF) node and an application server (AS). These assigned nodes are tasked with serving the UE during a subsequent communication session, and all signaling originating from, and terminating at, the UE during the communication session is to be routed through the assigned nodes of the IMS core. Paragraph [0016]: After registration of a UE, the UE is assigned a first S-CSCF node. During a communication session for the UE, a proxy call session control function (P-CSCF) node can receive, via a communications interface, a Session Initiation Protocol (SIP) request from the UE, and, upon making an attempt to contact the first S-CSCF node, the P-CSCF node may determine that the first S-CSCF node is unavailable (e.g., the P-CSCF node may not receive a response from the first S-CSCF node, or may receive a negative response from the first S-CSCF node, indicating that the first S-CSCF node is unavailable). Also see rejection for claim 1).
Jahangir does not explicitly teach wherein when the binding information between the P-CSCF and the user device is not stored by the TAS or retrievable, the network node is further configured to route the communication using circuit switched fall back.
However, Diaz teaches wherein when the binding information between the P-CSCF and the user device is not stored by the TAS or retrievable, the network node is further configured to route the communication using circuit switched fall back (see rejection for claim 1);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein when the binding information between the P-CSCF and the user device is not stored by the TAS or retrievable, the network node is further configured to route the communication using circuit switched fall back, as taught by Diaz in the system of Jahangir, in order to route the communication to a circuit switched network based on the session content and the user, which improves the assignment of resources in communication networks providing multimedia services (Diaz: Paragraphs [0014], [0018], [0020], [0051], [0052]).
Regarding claim 8, the combination of Jahangir and Diaz teaches the method of claim 7 (see rejection for claim 7);
Jahangir further teaches wherein the routing options that are available to the communication are stored in a user profile associated with the user device (see rejection for claim 2).
Regarding claim 9, the combination of Jahangir and Diaz teaches the method of claim 8, comprising (see rejection for claim 8);
Jahangir further teaches receiving, by the network node, the user profile from a home server configured to manage subscriber information (see rejection for claim 3);
Regarding claim 11, the combination of Jahangir and Diaz teaches the method of claim 7, comprising (see rejection for claim 7);
Jahangir further teaches receiving, by the network node, the routing options that are available to the communication from the TAS (Paragraph [0017]: In the event that the first S-CSCF node is determined to be unavailable, a process for restoring the communication session for the UE can include selecting, by the P-CSCF node, a second S-CSCF node, and sending, via the communications interface of the P-CSCF node, the SIP request to the second S-CSCF node. The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0046]: The second S-CSCF node 202 can therefore send a request (via the UDR message 210) for an identifier of the first AS 106 that is associated with the UE 100. Paragraph [0047]: The HSS 108 can transmit a user data answer (UDA) message 212 to the second S-CSCF 202 that includes the identifier of the first AS 106. Recall that the identifier of the first AS 106 was previously stored in the master database 118 as the first value of the first AVP 114(1) for the active AS name attribute. The identifier of the first AS 106 that is returned in the UDA message 212 can comprise a SIP URI for the first AS 106. An example of a UDA message 212 is as follows: UDA (AS SIP URI). Upon receiving the UDA message 212, the second S-CSCF 202 now has the AS mapping for the UE 100 that can be used to restore the communication session for the UE 100. Paragraph [0081]: At 522, the second S-CSCF node 202 can send, via the communications interface of the second S-CSCF node 202, the SIP request 200 to the first AS 106 identified by the identifier received at 512. Paragraph [0082]: At 524, and in response to receiving the SIP request 200 with a different, and unfamiliar, S-CSCF name in the message header, the AS identified by the identifier received at 520 can confirm the new UE-to-S-CSCF-B association by contacting the HSS 108 over a Diameter interface. This confirmation request is shown in FIG. 2 by the UDR message 214 sent from the first AS 106 to the HSS 108. This UDR message 214 acts as a request by the first AS 106 to confirm that the HSS 108 has updated the S-CSCF binding 206 for the UE 100 with the identifier of the second S-CSCF 202 in the master database 118. The UDR message 214 can include a request for the UE's 100 registration status and the S-CSCF name.)
Regarding claim 12, the combination of Jahangir and Diaz teaches the method of claim 11 (see rejection for claim 11);
Jahangir further teaches wherein the routing options are stored in a local cache of the TAS or an external database accessible to the TAS (Paragraph [0046]: The second S-CSCF node 202 can therefore send a request (via the UDR message 210) for an identifier of the first AS 106 that is associated with the UE 100. Paragraph [0047]: The HSS 108 can transmit a user data answer (UDA) message 212 to the second S-CSCF 202 that includes the identifier of the first AS 106. Recall that the identifier of the first AS 106 was previously stored in the master database 118 as the first value of the first AVP 114(1) for the active AS name attribute. The identifier of the first AS 106 that is returned in the UDA message 212 can comprise a SIP URI for the first AS 106. An example of a UDA message 212 is as follows: UDA (AS SIP URI). Upon receiving the UDA message 212, the second S-CSCF 202 now has the AS mapping for the UE 100 that can be used to restore the communication session for the UE 100. Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Regarding claim 13, the combination of Jahangir and Diaz teaches the method of claim 11 (see rejection for claim 11);
Jahangir further teaches wherein the routing options include whether the binding information is stored in a local cache of the TAS or an external database accessible to the TAS (Paragraph [0040]: In response to receiving the SIP request 200 at the P-CSCF node 102, the P-CSCF node 102 can attempt to contact the first S-CSCF node 104. The P-CSCF node 102 may know that the first S-CSCF node 104 is assigned to the UE 100 from the identifier (e.g., a fully qualified domain name (FQDN), IP address, etc.) of the first S-CSCF node 104 that was included in the message header of the 200 OK message 112 received at the P-CSCF node 102 during the registration procedure. The HSS repository 108 can also maintain the binding between the UE 100 and the first S-CSCF node 104. Paragraph [0042]: In response to determining that the first S-CSCF node 104 is unavailable, an IMS restoration technique is initiated where the P-CSCF node 102 selects a second S-CSCF node 202 (labeled “S-CSCF-B” 202 in FIG. 2), and sends the SIP request 200 to the second S-CSCF node 202. Paragraph [0043]: the second S-CSCF node 202 can receive the SIP request 200 from the P-CSCF node 102 (or from an intermediate IMS node). In response to receiving the SIP request 200, the second S-CSCF node 202 is configured to send a request for restoration information to the HSS 108 over a Diameter interface. This request is shown in the form of a server assignment request (SAR) message 204. Paragraph [0044]: Thereafter, the S-CSCF binding 206 is updated in the HSS repository 118 to reflect an association between the UE 100 and the second S-CSCF node 202. Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Regarding claim 14, the combination of Jahangir and Diaz teaches the method of claim 7 (see rejection for claim 7);
Jahangir further teaches wherein the network node comprises a Serving CSCF (Paragraph [0002]: During a registration procedure with the IMS core network, the UE is assigned a serving call session control function (S-CSCF) node and an application server (AS). These assigned nodes are tasked with serving the UE during a subsequent communication session, and all signaling originating from, and terminating at, the UE during the communication session is to be routed through the assigned nodes of the IMS core. Paragraph [0016]: After registration of a UE, the UE is assigned a first S-CSCF node. During a communication session for the UE, a proxy call session control function (P-CSCF) node can receive, via a communications interface, a Session Initiation Protocol (SIP) request from the UE, and, upon making an attempt to contact the first S-CSCF node, the P-CSCF node may determine that the first S-CSCF node is unavailable (e.g., the P-CSCF node may not receive a response from the first S-CSCF node, or may receive a negative response from the first S-CSCF node, indicating that the first S-CSCF node is unavailable)).
Regarding claim 15, Jahangir teaches a method of wireless communication, comprising: retrieving, by a first network node in a network, a user profile that comprises routing options available to a communication of a user device from a home server configured to manage subscriber information (Paragraph [0031]: As shown in FIG. 1, the first AS 106 is further configured to send multiple attribute-value pairs (AVPs) 114 to the HSS 108 for storage at the HSS 108 as part of the registration procedure for the UE 100. Paragraph [0032]: The AVPs 114 can be transmitted from the first AS 106 to the HSS 108 over a Diameter interface in the form of a profile update request (PUR) message. Paragraph [0034]: The HSS 108 can be associated with a master database 118 (sometimes referred to herein as an “HSS repository”) that maintains data pertaining to UEs 100 that have registered, or are in the process of registering, on the IMS network. FIG. 1 shows HSS repository data as including the first, “active AS name” AVP 114(1) and the second, “user registration data” AVP 114(2) as a result of the PUR message 116 received from the first AS 106 during registration. FIG. 1 also shows an example first value of the active AS name AVP 114(1) that identifies the first AS 106 as “AS-A.” Thus, the first, active AS name AVP 114(1) reflects the assignment of the first AS 106 to the UE 100 (sometimes referred to as an “AS binding”). Thus, storage of the first, active AS name AVP 114(1) in the master database 118 of the HSS 108 creates a binding between the UE 100 and the first AS 106 that is maintained in the HSS repository 118. Similarly, the storage of one or more second values for the second, user registration data AVP 114(2) in the master database 118 reflects information for a user profile associated with the UE 100. Paragraph [0049]: In response to receiving the SIP request 200 with a different, and unfamiliar, S-CSCF name in the message header, the first AS 106 can confirm the new UE-to-S-CSCF-B association by contacting the HSS 108 over a Diameter interface. This confirmation request is shown in FIG. 2 by the UDR message 214 sent from the first AS 106 to the HSS 108. This UDR message 214 acts as a request by the first AS 106 to confirm that the HSS 108 has updated the S-CSCF binding 206 for the UE 100 with the identifier of the second S-CSCF 202 in the master database 118. The UDR message 214 can include a request for the UE's 100 registration status and the S-CSCF name. An example of a UDR message 214 sent from the first AS 106 is as follows: UDR (User State/S-CSCF Name).)
wherein the routing options indicate at least one of: (3) whether binding information between a Proxy Call Session Control Function (P-CSCF) and the user device is stored by a Telephony Application Server (TAS) or retrievable (Paragraph [0015]: Accordingly, a registration procedure for a UE includes sending, from an AS, and to a HSS for storage at the HSS, a first value for an “active AS name” attribute (i.e., a first AVP) and a second value for a “user registration data” attribute (i.e., a second AVP). These AVPs can be transmitted over a Diameter (Cx) interface from the AS to the HSS. Thus, at registration, the HSS stores, for a particular UE, the first AVP for the active AS name attribute and the second AVP for the user registration data attribute. Maintaining these AVPs in repository data of the HSS for a given UE allows for restoring a communication session for the UE in the event of S-CSCF node unavailability and/or AS unavailability. The storage of these AVPs in the HSS repository allows an individual IMS node to interact directly with the HSS to obtain information it can use to restore the communication session without having to tear down the communication session or issue unneeded communications to other IMS nodes. Paragraph [0017]: In the event that the first S-CSCF node is determined to be unavailable, a process for restoring the communication session for the UE can include selecting, by the P-CSCF node, a second S-CSCF node, and sending, via the communications interface of the P-CSCF node, the SIP request to the second S-CSCF node. The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Thus, the techniques and systems described herein do not force the UE to re-register on the IMS core, unlike existing IMS restoration procedures. Paragraph [0030]: The first S-CSCF node 104 receives the SIP request 110 from the P-CSCF node 102 (or from an intermediate IMS node), and forwards the SIP request 110 to the first AS 106. Paragraph [0031]: As shown in FIG. 1, the first AS 106 is further configured to send multiple attribute-value pairs (AVPs) 114 to the HSS 108 for storage at the HSS 108 as part of the registration procedure for the UE 100. Paragraph [0042]: In response to determining that the first S-CSCF node 104 is unavailable, an IMS restoration technique is initiated where the P-CSCF node 102 selects a second S-CSCF node 202 (labeled “S-CSCF-B” 202 in FIG. 2), and sends the SIP request 200 to the second S-CSCF node 202. The P-CSCF node 102 is configured with “route advance” logic to select a different, available S-CSCF node as a backup without tearing down the current communication session. Paragraph [0046]: The second S-CSCF node 202 can therefore send a request (via the UDR message 210) for an identifier of the first AS 106 that is associated with the UE 100. Paragraph [0047]: The HSS 108 can transmit a user data answer (UDA) message 212 to the second S-CSCF 202 that includes the identifier of the first AS 106. Recall that the identifier of the first AS 106 was previously stored in the master database 118 as the first value of the first AVP 114(1) for the active AS name attribute. The identifier of the first AS 106 that is returned in the UDA message 212 can comprise a SIP URI for the first AS 106. An example of a UDA message 212 is as follows: UDA (AS SIP URI). Upon receiving the UDA message 212, the second S-CSCF 202 now has the AS mapping for the UE 100 that can be used to restore the communication session for the UE 100. Paragraph [0048]: Using the AS mapping from the UDA message 212, the second S-CSCF node 202 can send the SIP request 200 to the first AS 106 identified by the first value for the active AS name AVP 114(1). Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
storing the routing options in a local cache of the first network node or an external database of the first network node (Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Jahangir does not explicitly teach wherein when the binding information between the P-CSCF and the user device is not stored by the TAS or retrievable, a Serving Call Session Control Function (S-CSCF) communicatively coupled to the first network node is further configured to route the communication using circuit switched fall back.
However, Diaz teaches wherein when the binding information between the P-CSCF and the user device is not stored by the TAS or retrievable, a Serving Call Session Control Function (S-CSCF) communicatively coupled to the first network node is further configured to route the communication using circuit switched fall back (Paragraph [0020]: When routing the request for communication towards the circuit-switched network, this may be achieved by the service identifier node modifying the recipient included in the request for communication by adding a prefix which indicates the request should be routed towards the circuit-switched network and then routing the communication through the circuit-switched network. A convenient means of achieving this is by returning the request to a serving call session control function node (S-CSCF), from which it may have originally been directed to the service identifier node, before onward routing through the network to the recipient user. However, in an alternative approach the service identifier node may obtain the direction of the “following” node towards which the request is to be routed and then route the request to the said following node. In turn, the said following node may route the communication through the circuit switched network. Paragraph [0051]: In operation, said SIAS node of this example receives from the S-CSCF of the IMS network a message to request communication addressed to a user A, said message includes information about said communication features. If said communication features are not allowed for said user A or said user A is not in the database, an error message is sent to the S-CSCF. Paragraph [0052]: If the requested communication is voice-type communication or it is indicated in the database that the user wants the communication to be routed through the circuit switched network for the type of communication indicated in the request for communication, the SIAS node routes the message to request communication towards the circuit switched network. Also see Paragraphs [0066], [0068] - [0069] which indicates that the SIAS node equivalent to a TAS).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein when the binding information between the P-CSCF and the user device is not stored by the TAS or retrievable, a Serving Call Session Control Function (S-CSCF) communicatively coupled to the first network node is further configured to route the communication using circuit switched fall back, as taught by Diaz in the system of Jahangir, in order to route the communication to a circuit switched network based on the session content and the user, which improves the assignment of resources in communication networks providing multimedia services (Diaz: Paragraphs [0014], [0018], [0020], [0051], [0052]).
Regarding claim 16, the combination of Jahangir and Diaz teaches the method of claim 15, comprises (see rejection for claim 15);
Jahangir further teaches transmitting, by the first network node, the routing options to a second network node in the network to enable the second network node to route the communication without triggering a new registration procedure (Paragraph [0015]: Accordingly, a registration procedure for a UE includes sending, from an AS, and to a HSS for storage at the HSS, a first value for an “active AS name” attribute (i.e., a first AVP) and a second value for a “user registration data” attribute (i.e., a second AVP). These AVPs can be transmitted over a Diameter (Cx) interface from the AS to the HSS. Thus, at registration, the HSS stores, for a particular UE, the first AVP for the active AS name attribute and the second AVP for the user registration data attribute. Maintaining these AVPs in repository data of the HSS for a given UE allows for restoring a communication session for the UE in the event of S-CSCF node unavailability and/or AS unavailability. The storage of these AVPs in the HSS repository allows an individual IMS node to interact directly with the HSS to obtain information it can use to restore the communication session without having to tear down the communication session or issue unneeded communications to other IMS nodes. Paragraph [0017]: In the event that the first S-CSCF node is determined to be unavailable, a process for restoring the communication session for the UE can include selecting, by the P-CSCF node, a second S-CSCF node, and sending, via the communications interface of the P-CSCF node, the SIP request to the second S-CSCF node. The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0046]: The second S-CSCF node 202 can therefore send a request (via the UDR message 210) for an identifier of the first AS 106 that is associated with the UE 100. Paragraph [0047]: The HSS 108 can transmit a user data answer (UDA) message 212 to the second S-CSCF 202 that includes the identifier of the first AS 106. Recall that the identifier of the first AS 106 was previously stored in the master database 118 as the first value of the first AVP 114(1) for the active AS name attribute. The identifier of the first AS 106 that is returned in the UDA message 212 can comprise a SIP URI for the first AS 106. An example of a UDA message 212 is as follows: UDA (AS SIP URI). Upon receiving the UDA message 212, the second S-CSCF 202 now has the AS mapping for the UE 100 that can be used to restore the communication session for the UE 100. Paragraph [0081]: At 522, the second S-CSCF node 202 can send, via the communications interface of the second S-CSCF node 202, the SIP request 200 to the first AS 106 identified by the identifier received at 512. Paragraph [0082]: At 524, and in response to receiving the SIP request 200 with a different, and unfamiliar, S-CSCF name in the message header, the AS identified by the identifier received at 520 can confirm the new UE-to-S-CSCF-B association by contacting the HSS 108 over a Diameter interface. This confirmation request is shown in FIG. 2 by the UDR message 214 sent from the first AS 106 to the HSS 108. This UDR message 214 acts as a request by the first AS 106 to confirm that the HSS 108 has updated the S-CSCF binding 206 for the UE 100 with the identifier of the second S-CSCF 202 in the master database 118. The UDR message 214 can include a request for the UE's 100 registration status and the S-CSCF name. Paragraph [0084]: At 528, in response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Regarding claim 17, the combination of Jahangir and Diaz teaches the method of claim 16 (see rejection for claim 16);
Jahangir further teaches wherein the second network node comprises a new Serving Call Session Control Function (S-CSCF) that is selected upon an original S-CSCF being unreachable to other network nodes in the network (Abstract: A communication session for a UE can be restored in the event of serving call session control function (S-CSCF) node unavailability and/or application server (AS) unavailability by storing, prior to IMS unavailability, attribute-value pairs (AVPs) at a home subscriber server (HSS). These AVPs can be used independently by individual IMS nodes to restore a communication session for a UE due to an unavailable IMS node. When a first S-CSCF node becomes unavailable, a proxy CSCF (P-CSCF) node can send a SIP request originating from the UE to a second S-CSCF node. The second S-CSCF node can then send a request to the HSS for an identifier of an AS associated with the UE. Upon receipt of the AS identifier (e.g., an active AS name AVP) from the HSS, the second S-CSCF node can send the SIP request to the AS in order to restore the communication session for the UE. Paragraph [0017]: In the event that the first S-CSCF node is determined to be unavailable, a process for restoring the communication session for the UE can include selecting, by the P-CSCF node, a second S-CSCF node, and sending, via the communications interface of the P-CSCF node, the SIP request to the second S-CSCF node. The second S-CSCF node can then send, via a communications interface of the second S-CSCF node, and to the HSS, a request for an identifier of an AS associated with the UE. Such a request can comprise a user data request (UDR) message that is sent over a Diameter interface from the second S-CSCF node to the HSS. The second S-CSCF node can then receive a response from the HSS including the identifier of the AS, where the identifier can comprise the first value for the active AS name attribute, which was previously stored in the HSS as the first AVP. The second S-CSCF node—now in possession of the identifier of the AS—can send the SIP request to the AS in order to restore the communication session for the UE. Thus, the techniques and systems described herein do not force the UE to re-register on the IMS core, unlike existing IMS restoration procedures. Paragraph [0042]: In response to determining that the first S-CSCF node 104 is unavailable, an IMS restoration technique is initiated where the P-CSCF node 102 selects a second S-CSCF node 202 (labeled “S-CSCF-B” 202 in FIG. 2), and sends the SIP request 200 to the second S-CSCF node 202. The P-CSCF node 102 is configured with “route advance” logic to select a different, available S-CSCF node as a backup without tearing down the current communication session.)
Regarding claim 18, the combination of Jahangir and Diaz teaches the method of claim 15 (se rejection for claim 15);
Jahangir further teaches wherein the routing options include whether the binding information is stored in the local cache of the first network node or the external database of the first network node (Paragraph [0040]: In response to receiving the SIP request 200 at the P-CSCF node 102, the P-CSCF node 102 can attempt to contact the first S-CSCF node 104. The P-CSCF node 102 may know that the first S-CSCF node 104 is assigned to the UE 100 from the identifier (e.g., a fully qualified domain name (FQDN), IP address, etc.) of the first S-CSCF node 104 that was included in the message header of the 200 OK message 112 received at the P-CSCF node 102 during the registration procedure. The HSS repository 108 can also maintain the binding between the UE 100 and the first S-CSCF node 104. Paragraph [0042]: In response to determining that the first S-CSCF node 104 is unavailable, an IMS restoration technique is initiated where the P-CSCF node 102 selects a second S-CSCF node 202 (labeled “S-CSCF-B” 202 in FIG. 2), and sends the SIP request 200 to the second S-CSCF node 202. Paragraph [0043]: the second S-CSCF node 202 can receive the SIP request 200 from the P-CSCF node 102 (or from an intermediate IMS node). In response to receiving the SIP request 200, the second S-CSCF node 202 is configured to send a request for restoration information to the HSS 108 over a Diameter interface. This request is shown in the form of a server assignment request (SAR) message 204. Paragraph [0044]: Thereafter, the S-CSCF binding 206 is updated in the HSS repository 118 to reflect an association between the UE 100 and the second S-CSCF node 202. Paragraph [0051]: In response to confirming the S-CSCF binding 206 between the UE 100 and the second S-CSCF node 202, the first AS 106 can update a local user profile that the first AS 106 maintains for the UE 100 with the new association between the UE 100 and the second S-CSCF node 202. In other words, the first AS 106 can update a local contact binding 218 so that the local contact binding specifies an association between the UE 100 and the second S-CSCF node 202. This local contact binding 218 can be maintained in local storage of the first AS 106.)
Regarding claim 19, the combination of Jahangir and Diaz teaches the method of claim 15 (see rejection for claim 15);
Jahangir further teaches wherein the home server comprises a Home Subscriber Sever (HSS) or a Home Location Register (HLR) (Paragraph [0031]: As shown in FIG. 1, the first AS 106 is further configured to send multiple attribute-value pairs (AVPs) 114 to the HSS 108 for storage at the HSS 108 as part of the registration procedure for the UE 100. Paragraph [0032]: The AVPs 114 can be transmitted from the first AS 106 to the HSS 108 over a Diameter interface in the form of a profile update request (PUR) message. Paragraph [0034]: The HSS 108 can be associated with a master database 118 (sometimes referred to herein as an “HSS repository”) that maintains data pertaining to UEs 100 that have registered, or are in the process of registering, on the IMS network. FIG. 1 shows HSS repository data as including the first, “active AS name” AVP 114(1) and the second, “user registration data” AVP 114(2) as a result of the PUR message 116 received from the first AS 106 during registration. FIG. 1 also shows an example first value of the active AS name AVP 114(1) that identifies the first AS 106 as “AS-A.” Thus, the first, active AS name AVP 114(1) reflects the assignment of the first AS 106 to the UE 100 (sometimes referred to as an “AS binding”). Thus, storage of the first, active AS name AVP 114(1) in the master database 118 of the HSS 108 creates a binding between the UE 100 and the first AS 106 that is maintained in the HSS repository 118. Similarly, the storage of one or more second values for the second, user registration data AVP 114(2) in the master database 118 reflects information for a user profile associated with the UE 100. Paragraph [0049]: In response to receiving the SIP request 200 with a different, and unfamiliar, S-CSCF name in the message header, the first AS 106 can confirm the new UE-to-S-CSCF-B association by contacting the HSS 108 over a Diameter interface. This confirmation request is shown in FIG. 2 by the UDR message 214 sent from the first AS 106 to the HSS 108. This UDR message 214 acts as a request by the first AS 106 to confirm that the HSS 108 has updated the S-CSCF binding 206 for the UE 100 with the identifier of the second S-CSCF 202 in the master database 118. The UDR message 214 can include a request for the UE's 100 registration status and the S-CSCF name. An example of a UDR message 214 sent from the first AS 106 is as follows: UDR (User State/S-CSCF Name).)
Regarding claim 20, the combination of Jahangir and Diaz teaches the method of claim 15 (see rejection for claim 15);
Jahangir further teaches wherein the first network node comprises a telephonic application server (TAS) (Abstract: A communication session for a UE can be restored in the event of serving call session control function (S-CSCF) node unavailability and/or application server (AS) unavailability by storing, prior to IMS unavailability, attribute-value pairs (AVPs) at a home subscriber server (HSS). These AVPs can be used independently by individual IMS nodes to restore a communication session for a UE due to an unavailable IMS node. When a first S-CSCF node becomes unavailable, a proxy CSCF (P-CSCF) node can send a SIP request originating from the UE to a second S-CSCF node. Paragraph [0002]: During a registration procedure with the IMS core network, the UE is assigned a serving call session control function (S-CSCF) node and an application server (AS). These assigned nodes are tasked with serving the UE during a subsequent communication session, and all signaling originating from, and terminating at, the UE during the communication session is to be routed through the assigned nodes of the IMS core. Paragraph [0030]: The first S-CSCF node 104 receives the SIP request 110 from the P-CSCF node 102 (or from an intermediate IMS node), and forwards the SIP request 110 to the first AS 106. The first AS 106 can be configured to provide any of the IMS-based services described herein as part of a subsequently established communication session. Paragraph [0037]: Once the UE 100 is successfully registered on the IMS network, the UE 100 can originate a communication session, such a voice communication session (e.g., a phone call). Unless and until the first S-CSCF node 104 and/or the first AS 106 become unavailable, all SIP signaling that is part of the communication session, and that originates and terminates at the UE 100, is routed through the assigned first S-CSCF node 104 and the first AS 106.)
Claims 5, 10 are rejected under 35 U.S.C. 103 as being unpatentable over Jahangir et al. (US2018/0007612A1), in view of Diaz et al. (US2012/0250622A1), and further in view of Siegel et al. (US2009/0191867A1).
Regarding claim 5, the combination of Jahangir and Diaz teaches the system of claim 2 (see rejection for claim 2);
The combination of Jahangir and Diaz does not explicitly teach wherein the user profile is implemented as an Extensible Markup Language (XML) document, and wherein the routing options that are available to the communication of the mobile device are indicated using one or more entries in the XML document.
However, Siegel teaches wherein the user profile is implemented as an Extensible Markup Language (XML) document, and wherein the routing options that are available to the communication of the mobile device are indicated using one or more entries in the XML document (Paragraph [0100]: FIG. 1G shows the structure of a user profile. This figure in connection with FIGS. 1F and 1H are discussed next. The user profile 185 and its components are stored in the HSS 160 and are loaded into an S-CSCF 158 assigned to the user at registration. Different service profiles 186 a, 186 b, 186 c allow the user to get difference services on a session. Within the service profile 186 c, the initial Filter Criteria (iFCs) 196 determine which application servers 197 get involved in the call. When the message is sent to the application server 197, it uses the PUID in the message to determine how it is to handle the service for that particular PUID. The initial Filter Criteria 196 is defined in an XML document and has a structure as shown in 1H. Paragraph [0128]: As discussed earlier, the SIP REGISTER message contains the information necessary to perform the registration (See FIG. 9). The PUID being registered is in the To Header. The Contact Header includes a SIP URI which designates the network address at which the PUID is to be registered. The address would be a full IP address including the port number of the security association (e.g. tunnel) between the User Equipment and the P- CSCF)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the user profile is implemented as an Extensible Markup Language (XML) document, and wherein the routing options that are available to the communication of the mobile device are indicated using one or more entries in the XML document, as taught by Siegel in the combined system of Jahangir and Diaz, so that the user profile information in the document can be used to provide routing information such as the binding between the P-CSCF and the mobile device (Siegel: Paragraphs [0009], [0128]).
Regarding claim 10, the combination of Jahangir and Diaz teaches the method of claim 8 (see rejection for claim 8);
The combination of Jahangir and Diaz does not explicitly teach wherein the user profile is implemented as an Extensible Markup Language (XML) document.
However, Siegel teaches wherein the user profile is implemented as an Extensible Markup Language (XML) document (Paragraph [0100]: FIG. 1G shows the structure of a user profile. This figure in connection with FIGS. 1F and 1H are discussed next. The user profile 185 and its components are stored in the HSS 160 and are loaded into an S-CSCF 158 assigned to the user at registration. Different service profiles 186 a, 186 b, 186 c allow the user to get difference services on a session. Within the service profile 186 c, the initial Filter Criteria (iFCs) 196 determine which application servers 197 get involved in the call. When the message is sent to the application server 197, it uses the PUID in the message to determine how it is to handle the service for that particular PUID. The initial Filter Criteria 196 is defined in an XML document and has a structure as shown in 1H.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the user profile is implemented as an Extensible Markup Language (XML) document, as taught by Siegel in the combined system of Jahangir and Diaz, so that the user profile information in the document can be used to provide routing information such as the binding between the P-CSCF and the mobile device (Siegel: Paragraphs [0009], [0128]).
Response to Arguments
Applicant's arguments filed October 24, 2025 with respect to claims 1-4, 6-9, 11-20 being rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jahangir et al. (US2018/0007612A1), and claims 5 and 10 being rejected under 35 U.S.C. 103 as being unpatentable over Jahangir in view of Siegel et al. (US2009/0191867A1) have been fully considered.
Applicant submits that the cited reference Jahangir fails to disclose: "wherein when the binding information between the P- CSCF and the mobile device is not stored by the TAS or retrievable, the second S-CSCF is further configured to route the communication using circuit switched fall back.", as recited in amended independent claim 1, and similarly in amended independent claims 7 and 15. However, Diaz et al. (US2012/0250622A1) teaches "wherein when the binding information between the P-CSCF and the mobile device is not stored by the TAS or retrievable, the second S-CSCF is further configured to route the communication using circuit switched fall back." Diaz teaches that the SIAS node (which is equivalent to the TAS) routes the communication through the circuit switched network if the user is not in the database, by communicating with the S-CSCF.
Dependent claims 2-4, 6, 8-9, 11-14, 16-20 are also taught by the combination of Jahangir and Diaz. Dependent claims 5 and 10 are taught by the combination of Jahangir, Diaz, and Siegel.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LATHA CHAKRAVARTHY whose telephone number is (703)756-1172. The examiner can normally be reached M-Th 8:30 AM - 5 PM.
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, Huy Vu can be reached at 571-272-3155. 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.
/L.C./Examiner, Art Unit 2461
/KIBROM T HAILU/Primary Examiner, Art Unit 2461