DETAILED ACTION
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S Pub. No. 2010/0233991 A1 to Crawford et al. (hereinafter “Crawford”) in view of U.S Pub. No. 2016/0255483 A1 to PARLAMAS et al. (hereinafter “PARLAMAS”).
Regarding claim 1, Crawford teaches a method for directing an invite message of an emergency call to a first realm (paragraphs [0072] and [0074]; call establishment signaling (SIP INVITE) can be sent to the P-CSCF 512), the method comprising:
requesting, by an emergency network function (NF), location information associated with the emergency call (paragraphs [0034]- [0036] and [0047]- [0048]; determined that the user location has changed (e.g. by the monitoring component 302), a location determination component 304 can be employed to identify the new/changed location of the user);
receiving, by the emergency NF, a modified emergency services routing number (ESRN), wherein the modified ESRN is generated by a location NF modifying an original ESRN to include a traffic path identifier (paragraphs [0054] and [0077]; E911 profile can be created or an existing E911 profile can be updated and/or modified. Typically, the E911 profile can include parameters, such as TTN, ESRN, LRF indicator, etc. Typically, the E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information);
based on the traffic path identifier, routing the invite message to the first realm (paragraphs [0054] and [0077]; E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information such as subscriber location).
However, Crawford does not teach based on routing the invite message to the first realm, waiting, by a routing NF, for an authentication response from an authenticating NF prior to routing the invite message to an authentication-enabled public safety answering point (PSAP).
In the same field of endeavor, PARLAMAS teaches based on routing the invite message to the first realm, waiting, by a routing NF, for an authentication response from an authenticating NF prior to routing the invite message to an authentication-enabled public safety answering point (PSAP) (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of based on routing the invite message to the first realm, waiting, by a routing NF, for an authentication response from an authenticating NF prior to routing the invite message to an authentication-enabled public safety answering point (PSAP) as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 2, Crawford does not teach the method of claim 1, wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to the authentication-enabled PSAP, and wherein the authentication response includes an authenticated caller identity token.
In the same field of endeavor, PARLAMAS teaches wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to the authentication-enabled PSAP, and wherein the authentication response includes an authenticated caller identity token (PSAP) (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to the authentication-enabled PSAP, and wherein the authentication response includes an authenticated caller identity token as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 3, Crawford does not teach the method of claim 2, wherein the authenticated caller identity token is a personal assertion token (PASSporT).
In the same field of endeavor, PARLAMAS teaches wherein the authenticated caller identity token is a personal assertion token (PASSporT) (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein the authenticated caller identity token is a personal assertion token (PASSporT) as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 4, Crawford teaches the method of claim 1, wherein the emergency NF is an emergency call state control function (E-CSCF) (Abstract, paragraphs [0041] and [0051]; E911 profile can then be stored in the HSS and can be queried by an E-CSCF (Emergency Call Session Control Function) during emergency call processing).
Regarding claim 5, Crawford teaches the method of claim 1, wherein the location NF is a gateway mobile location center (GLMC) (paragraphs [0045], [0054] and [0059]; ESRN 404 can be utilized by the IMS network (e.g., by an Emergency Services Gateway) to select a trunk to the selective router that serves the PSAP that serves the caller's location).
Regarding claim 6, Crawford teaches the method of claim 1, wherein the routing NF is a session border controller (SBC) (paragraphs [0039] and [0041]; system 200 can be utilized within the E-CSCF (Emergency Call Session Control Function) in the IMS).
Regarding claim 7, Crawford does not teach the method of claim 1, wherein the authenticating NF is a secure telephone identity authentication service (STI-AS).
In the same field of endeavor, PARLAMAS teaches wherein the authenticating NF is a secure telephone identity authentication service (STI-AS) (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein the authenticating NF is a secure telephone identity authentication service (STI-AS) as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 8, Crawford teaches the method of claim 1, wherein the traffic path identifier is a prefix of the modified ESRN (paragraphs [0054] and [0077]; E911 profile can be created or an existing E911 profile can be updated and/or modified. Typically, the E911 profile can include parameters, such as TTN, ESRN, LRF indicator, etc. Typically, the E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information).
Regarding claim 9, Crawford teaches a method for directing an invite message of an emergency call to a second realm (paragraphs [0072] and [0074]; call establishment signaling (SIP INVITE) can be sent to the P-CSCF 512), the method comprising:
requesting, by an emergency network function (NF), location information associated with the emergency call (paragraphs [0034]- [0036] and [0047]- [0048]; determined that the user location has changed (e.g. by the monitoring component 302), a location determination component 304 can be employed to identify the new/changed location of the user);
receiving, by the emergency NF, a modified emergency services routing number (ESRN), wherein the modified ESRN is generated by a location NF modifying an original ESRN to include a traffic path identifier (paragraphs [0054] and [0077]; E911 profile can be created or an existing E911 profile can be updated and/or modified. Typically, the E911 profile can include parameters, such as TTN, ESRN, LRF indicator, etc. Typically, the E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information);
based on the traffic path identifier, routing the invite message to a second realm (paragraphs [0054] and [0077]; E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information such as subscriber location).
However, Crawford does not teach based on routing the invite message to the second realm, routing, by a routing NF, the invite message to a non-authentication enabled public safety answering point (PSAP) without waiting for an authentication response from an authenticating NF.
In the same field of endeavor, PARLAMAS teaches based on routing the invite message to the second realm, routing, by a routing NF, the invite message to a non-authentication enabled public safety answering point (PSAP) without waiting for an authentication response from an authenticating NF (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of based on routing the invite message to the second realm, routing, by a routing NF, the invite message to a non-authentication enabled public safety answering point (PSAP) without waiting for an authentication response from an authenticating NF as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 10, Crawford teaches the method of claim 9, wherein the traffic path identifier is a prefix of the modified ESRN (paragraphs [0054] and [0077]; E911 profile can be created or an existing E911 profile can be updated and/or modified. Typically, the E911 profile can include parameters, such as TTN, ESRN, LRF indicator, etc. Typically, the E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information).
Regarding claim 11, Crawford teaches the method of claim 10, wherein the emergency NF is an emergency call state control function (E-CSCF) (Abstract, paragraphs [0041] and [0051]; E911 profile can then be stored in the HSS and can be queried by an E-CSCF (Emergency Call Session Control Function) during emergency call processing).
Regarding claim 12, Crawford teaches the method of claim 11, wherein the location NF is a gateway mobile location center (GMLC) (paragraphs [0045], [0054] and [0059]; ESRN 404 can be utilized by the IMS network (e.g., by an Emergency Services Gateway) to select a trunk to the selective router that serves the PSAP that serves the caller's location).
Regarding claim 13, Crawford teaches the method of claim 12, wherein the routing NF is a session border controller (SBC) (paragraphs [0039] and [0041]; system 200 can be utilized within the E-CSCF (Emergency Call Session Control Function) in the IMS).
Regarding claim 14, Crawford does not teach the method of claim 13, wherein the authenticating NF is a secure telephone identity authentication service (STI-AS).
In the same field of endeavor, PARLAMAS teaches wherein the authenticating NF is a secure telephone identity authentication service (STI-AS) (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein the authenticating NF is a secure telephone identity authentication service (STI-AS) as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 15, Crawford teaches a method for directing an invite message of an emergency call to a first realm or a second realm (paragraphs [0072] and [0074]; call establishment signaling (SIP INVITE) can be sent to the P-CSCF 512), the method comprising:
requesting, by an emergency network function (NF), location information associated with the emergency call (paragraphs [0034]- [0036] and [0047]- [0048]; determined that the user location has changed (e.g. by the monitoring component 302), a location determination component 304 can be employed to identify the new/changed location of the user);
receiving, by the emergency NF, a modified emergency services routing number (ESRN), wherein the modified ESRN is generated by a location NF modifying an original ESRN to include a traffic path identifier (paragraphs [0054] and [0077]; E911 profile can be created or an existing E911 profile can be updated and/or modified. Typically, the E911 profile can include parameters, such as TTN, ESRN, LRF indicator, etc. Typically, the E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information); and
based on the traffic path identifier, routing, by a routing NF, the invite message to the first realm or the second realm (paragraphs [0054] and [0077]; E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information such as subscriber location).
However, Crawford does not teach wherein the first realm is associated with one or more authentication-enabled public safety answering points (PSAPs) and wherein the second realm is associated with one or more non-authentication-enabled PSAPs.
In the same field of endeavor, PARLAMAS teaches wherein the first realm is associated with one or more authentication-enabled public safety answering points (PSAPs) and wherein the second realm is associated with one or more non-authentication-enabled PSAPs (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein the first realm is associated with one or more authentication-enabled public safety answering points (PSAPs) and wherein the second realm is associated with one or more non-authentication-enabled PSAPs as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 16, Crawford does not teach the method of claim 15, wherein the invite message is routed to the first realm based on the traffic path identifier, and wherein in the first realm, the routing NF waits for an authentication response from an authenticating NF.
In the same field of endeavor, PARLAMAS teaches wherein the invite message is routed to the first realm based on the traffic path identifier, and wherein in the first realm, the routing NF waits for an authentication response from an authenticating NF (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein the invite message is routed to the first realm based on the traffic path identifier, and wherein in the first realm, the routing NF waits for an authentication response from an authenticating NF as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 17, Crawford does not teach the method of claim 16, wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to an authentication-enabled PSAP of the one or more authentication-enabled PSAPs, and wherein the authentication response comprises an authenticated caller identity token.
In the same field of endeavor, PARLAMAS teaches wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to an authentication-enabled PSAP of the one or more authentication-enabled PSAPs, and wherein the authentication response comprises an authenticated caller identity token (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to an authentication-enabled PSAP of the one or more authentication-enabled PSAPs, and wherein the authentication response comprises an authenticated caller identity token as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 18, Crawford does not teach the method of claim 17, wherein the authenticated caller identity token is a personal assertion token (PASSporT).
In the same field of endeavor, PARLAMAS teaches wherein the authenticated caller identity token is a personal assertion token (PASSporT) (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein, based on an authentication flag, the emergency NF retains one or more authentication headers of the invite message, wherein the authentication flag indicates the invite message is to be routed to the authentication-enabled PSAP, and wherein the authentication response includes an authenticated caller identity token as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 19, Crawford does not teach the method of claim 15, wherein the invite message is routed to the second realm based on the traffic path identifier, and wherein in the second realm, a routing NF routes the invite message to a non-authentication enabled PSAP of the one or more non-authentication-enabled PSAPs without waiting for an authentication response from an authenticating NF.
In the same field of endeavor, PARLAMAS teaches wherein the invite message is routed to the second realm based on the traffic path identifier, and wherein in the second realm, a routing NF routes the invite message to a non-authentication enabled PSAP of the one or more non-authentication-enabled PSAPs without waiting for an authentication response from an authenticating NF (paragraphs [0040]-[0041]; API GW 111 is responsible for user verification and authentication, for interacting with network security functions, application authentication, generating authorization codes, managing access tokens and passwords… when a 911 call is received by the universal voice platform 109, the call is ultimately routed from the universal voice platform 109 towards a PSAP 105 via the NENA i2 ESGW 110 and the E911 SR 113).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skilled in the art to modify Crawford’s teaching with a feature of wherein the invite message is routed to the second realm based on the traffic path identifier, and wherein in the second realm, a routing NF routes the invite message to a non-authentication enabled PSAP of the one or more non-authentication-enabled PSAPs without waiting for an authentication response from an authenticating NF as taught by PARLAMAS in order to access a network service through the software client at the current location (Abstract, PARLAMAS).
Regarding claim 20, Crawford teaches the method of claim 15, wherein the traffic path identifier is a prefix of the modified ESRN (paragraphs [0054] and [0077]; E911 profile can be created or an existing E911 profile can be updated and/or modified. Typically, the E911 profile can include parameters, such as TTN, ESRN, LRF indicator, etc. Typically, the E911 profile parameters can facilitate routing of an emergency call to an optimal PSAP and can provide information).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AKELAW A TESHALE whose telephone number is (571)270-5302. The examiner can normally be reached 9 am -6pm.
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, FAN TSANG can be reached at (571) 272-7547. 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.
AKELAW TESHALE
Primary Examiner
Art Unit 2694
/AKELAW TESHALE/Primary Examiner, Art Unit 2694