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 .
DETAILED ACTION
This is the initial office action has been issued in response to patent application, 18/626120, filed on 03 April 2024. Claims 1-20, as originally filed, are currently pending and have been considered below.
Specification
The disclosure is objected to because of the following informalities: in the applicant's specification, applicant recites “signal embodied in a carrier wave. The baseband signal or signal embedded in the carrier wave, or other types of signals currently used or hereafter developed, may be generated according to several methods well-known to one skilled in the art. The baseband signal and/or signal embedded in the carrier wave may be referred to in some contexts as a transitory signal” (see paragraph 0113). Examiner suggest amending to delete “carrier wave” “transitory”.
Appropriate correction is required.
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 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Modi et al. (US2021/0392136 A1, publish date 12/16/2021) in view of Mouton et al. (US11223957 B1, patent date 01/11/2022).
Claim 1:
With respect to claim 1, Modi et al. discloses a method implemented in a communication network including an Internet Protocol (IP) Media Subsystem (IMS) core network (authentication component 338 can facilitate performing the AKA between the authentication component 338 and a subscriber identity module (SIM), a UMTS or universal SIM (USIM), or an IP multimedia services identity module (ISIM) of the communication device, wherein the client (e.g., trusted client) of the communication device can have access to the SIM, USIM, or ISIM to request the AKA procedure, 0087) to perform point-of-use token validation (token validation, Figures 3, 5, and 9), wherein the method comprises:
receiving, by a core application executing at a core access network element in the
IMS core network, a registration message from a client, wherein the registration message comprises a first access token and a mobile station international subscriber directory number (MSISDN) of the client (token validation request, comprising an encrypted token, can be received by the authorization component from an application component, wherein the encrypted authentication token can comprise encrypted device identifier information that can facilitate identifying the device, 0150, Figure 8, 802, Figure 9, 906) (communication device information, such as, for example, a device identifier (e.g., international mobile subscriber identity (IMSI), mobile station international subscriber directory number (MSISDN), 0064) (The encrypted token can comprise device identifier information (e.g., IMSI, MSISDN, MAC address, device serial number, transaction ID, device ID, 0088);
authenticating, by an authorization application at an authorization server communicatively coupled to the IMS core network, the first access token based on a current and valid access token assigned to the client (a determination can be made, by the authorization component, whether the communication device is validated based at least in part on analyzing the encrypted token and a private decryption key, 0150, Figure 8, 804, token validates, Figure 9, 910);
verifying, by an identity application at an identity management server
communicatively coupled to the IMS core network, that the MSISDN of the client is
indicated as being permitted to use the first access token based on a client account
associated with the client (The authorization component 338 can decrypt the encrypted token, including the encrypted device identifier information, based at least in part on a private decryption key, the initialization vector, and a decryption algorithm, to generate decrypted information, including the device identifier information (e.g., IMSI, MSISDN, MAC address, device serial number, transaction ID, device ID, item of data, or other desired device identifier information associated with the communication device), 0089);
performing, by the core application at the IMS core network, a registration of the
client with the IMS core network based on the MSISDN of the client (the authorization component can access subscriber-related information (e.g., subscriber identification information, subscription or account status information, or service plan information, . . . ) in a data store (e.g., subscriber database in the data store), and can analyze the subscriber-related information to determine a subscriber or account status (e.g., active status, suspended status, terminated status, non-existent status), service(s) to which the user and/or communication device (e.g., subscriber) is subscribed and/or has an account, and/or type of service plan associated with the service, etc., 0032) (A SIP client 740 enables the communication device 700 to support SIP protocols and register the subscriber with the SIP registrar server, 0144);
maintaining, by the core application, the registration of the client with the IMS core
network by automatically performing one or more refresh operations on the registration of the client with the IMS core network (application server to know (e.g., know in real time) a subscription or account status of a particular communication device and associated user (e.g., subscriber) with regard to the communication service to facilitate knowing whether the particular communication device and user are authorized to access the application server and utilize the communication service, 0022) (can provide the application component 108 (or configuration component 112) a real-time or substantially real-time update regarding the subscriber or account status of the communication device 104 and/or user with regard to the requested service 110 to ensure that only an authorized communication device and/or user (e.g., with an active status) can gain access to the service 110, 0071);
verifying, by the identity application at the identity management server, at least one
of the MSISDN of the client, the MSISDN of the second client, or the requested service
based on the client account (Based at least in part on the decryption of the encrypted token, and the information, including the device identifier information and/or token-related information, obtained from decrypting the token and/or a device identifier of the communication device that provided the encrypted token to the application component, the authorization component can determine whether the token is validated. For instance, the authorization component can analyze such information to determine whether the token is verified to be the same encrypted token the authorization component communicated to the communication device and/or determine whether the device identifier information in the token matches the device identifier of the communication device that provided the encrypted token to the application component. 0160, Figure 9, 910); and
providing, by the IMS core network, the requested service to the client (facilitate allowing communication device to access and utilize the service, Figure 9, 922).
Modi et al. does not disclose receiving, by the core application, an access request from the client, wherein the access request comprises a second access token of the client, the MSISDN of the client, an indication of a requested service, and a MSISDN of a second client, wherein the requested service is to complete a call from the client to the second client;
authenticating, by the authorization application at the authorization server, the
second access token based on the current and valid access token assigned to the client as claimed.
However, Mouton et al. teaches using a dynamic International Mobile Subscriber Identity (IMSI) and Mobile Station International Subscriber Director Number (MSISDN) (Abstract), receiving, by the core application, an access request from the client, wherein the access request comprises a second access token of the client, the MSISDN of the client, an indication of a requested service, and a MSISDN of a second client (establishing a privatized communications session between UE 12 and another mobile device 20, MNO 14 queries the database for the IMSI/MSISDN of the mobile device 20 with which UE 12 is requesting a communications session. The query returns a result that the IMSI/MSISDN associated with mobile device 20 is associated with a privacy token. the communications session is established based on the privacy token, rather than the IMSI or MSISDN, although the IMSI and MSISDN are appended to the privacy token to ensure compliance with GSMA requirements, Column 4, lines 21-41, Figure 4), wherein the requested service is to complete a call from the client to the second client (The established communications session is fully private because neither MNO 12 nor MNO 22 is aware of the identity of UE 12 or mobile device 20. Column 4, lines 43-46) (session established, Figure 4);
authenticating, by the authorization application at the authorization server, the
second access token based on the current and valid access token assigned to the client
(the communications session is established based on the privacy token, rather than the IMSI or MSISDN, although the IMSI and MSISDN are appended to the privacy token to ensure compliance with GSMA requirements, Column 4, lines 21-41, Figure 4) (the first privacy token and its associated IMSI are registered into a database, such that the first IMSI is mappable to the first privacy token, column 1, lines 58-61) (the IMSI/MSISDN is mappable to the specific privacy token, the session request is sent to a second MNO 22, which provides mobile services to mobile device 20. Although second MNO 22 is not aware of the IMEI of mobile device 20, MNO 22 is aware of the specific token currently associated with the specific IMSI and MSISDN, column 4, lines 32-37).
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Mouton et al. in Modi et al. because the data exchanged via mobile communications network can be highly sensitive, it is paramount that privacy of such data be ensured. Accordingly, there is a strong and unfulfilled need to privatize mobile communications, such that in an event of a data breach, the data cannot be attributed to any specific entity. (see Mouton et al. Column 1, lines 19-31)
Claims 2, 10, 18:
With respect to claims 2, 10, 18, the combination of Modi et al. and Mouton et al. discloses the limitations of claims 1, 9, 15, as addressed.
Mouton et al. teaches wherein the first access token has a validity time period, and
wherein after the validity time period, the first access token is expired and the second
access token becomes valid (The process of obtaining a new privacy token with a new associated IMSI is repeated upon expiration of the validity period of the current token. After the validity period of the privacy token expires, the first MNO receives a billing transaction message associated with mobile services provided for the UE during the validity period of the privacy token, Column 2, lines 17-23)
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
The motivation for combining Modi et al. and Mouton et al. is recited in claims 1, 9, 15.
Claims 3, 11:
With respect to claims 3, 11, the combination of Modi et al. and Mouton et al. discloses the limitations of claims 1, 9, as addressed.
Modi et al. discloses further comprising: receiving, by the authorization application at the authorization server, security credentials to access the client account; and verifying, by the authorization application at the authorization server, a validity of the first access token in response to accessing the client account (The subscriber identification information can comprise user identification information, such as, for example, the name of a user, residential address of the user, phone number of the user, email address of the user, authentication information or credentials (e.g., username of the user with regard to an account or subscription, and/or password, passcode, or personal identification number (PIN) of the user), 0064).
Claim 4:
With respect to claim 4, the combination of Modi et al. and Mouton et al. discloses the limitations of claim 1, as addressed.
Modi et al. discloses further comprising obtaining, by the identity application of the identity management server, a verification parameter indicating that the MSISDN of the client is permitted to use the first access token based on the client account. (the authorization component can access subscriber-related information (e.g., subscriber identification information, subscription or account status information, or service plan information, . . . ) in a data store (e.g., subscriber database in the data store), and can analyze the subscriber-related information to determine a subscriber or account status (e.g., active status, suspended status, terminated status, non-existent status), service(s) to which the user and/or communication device (e.g., subscriber) is subscribed and/or has an account, and/or type of service plan associated with the service, etc., 0032) (the communication device 502 and/or associated user are determined to have an active subscriber or account status with regard to the requested service, the authorization component 504 also can determine a permitted portion (if any) of the subscriber-related information (e.g., IMSI, MSISDN, other device identifier, account status information, subscriber billing address or account, and/or information regarding type of service plan, . . . ) that the application component 506 is permitted (e.g., authorized) to have, based at least in part on the defined trust level associated with the application component 506 and the results of analyzing the subscriber-related information, 0115).
Claims 5, 12:
With respect to claims 5, 12, the combination of Modi et al. and Mouton et al. discloses the limitations of claims 1, 9, as addressed.
Modi et al. discloses wherein performing, by the core application, the registration of the client with the IMS core network based on the MSISDN of the client comprises:
transmitting, by the core application to a registration application at the IMS core
network, a session initiation protocol (SIP) register message (A SIP client 740 enables the communication device 700 to support SIP protocols and register the subscriber with the SIP registrar server, 0144) comprising the MSISDN of the client; and receiving, by the core application from the registration application, a SIP response
message indicating a status of performing the registration of the client with the IMS core
network (the authorization component can access subscriber-related information (e.g., subscriber identification information, subscription or account status information, or service plan information, . . . ) in a data store (e.g., subscriber database in the data store), and can analyze the subscriber-related information to determine a subscriber or account status (e.g., active status, suspended status, terminated status, non-existent status), service(s) to which the user and/or communication device (e.g., subscriber) is subscribed and/or has an account, and/or type of service plan associated with the service, etc., 0032).
Claims 6, 13:
With respect to claims 6, 13, the combination of Modi et al. and Mouton et al. discloses the limitations of claims 1, 9, as addressed.
Modi et al. discloses wherein the one or more refresh operations comprises transmitting another SIP register message (A SIP client 740 enables the communication device 700 to support SIP protocols and register the subscriber with the SIP registrar server, 0144) comprising the MSISDN of the client according to a predefined schedule (application server to know (e.g., know in real time) a subscription or account status of a particular communication device and associated user (e.g., subscriber) with regard to the communication service to facilitate knowing whether the particular communication device and user are authorized to access the application server and utilize the communication service, 0022) (can provide the application component 108 (or configuration component 112) a real-time or substantially real-time update regarding the subscriber or account status of the communication device 104 and/or user with regard to the requested service 110 to ensure that only an authorized communication device and/or user (e.g., with an active status) can gain access to the service 110, 0071).
Claims 7, 14, 19:
With respect to claims 7, 14, 19, the combination of Modi et al. and Mouton et al. discloses the limitations of claims 1, 9, 15, as addressed.
Mouton et al. teaches wherein prior to receiving, by the core application, the access request from the client, the method further comprises:
receiving, by the authorization application at the authorization server, a refresh token
associated with the client and the first access token from the client;
authenticating, by the authorization application at the authorization server, the client
based on both the refresh token and the first access token; and
providing, by the authorization application at the authorization server, the second
access token to the client (The process of obtaining a new privacy token with a new associated IMSI is repeated upon expiration of the validity period of the current token. After the validity period of the privacy token expires, the first MNO receives a billing transaction message associated with mobile services provided for the UE during the validity period of the privacy token, Column 2, lines 17-23)
if the validity period of the privacy token has expired, the privacy token and the IMSI and MSISDN are released back to token database 18. The process then returns to step 102, in which UE 12 requests a new privacy token. In step 104, the new privacy token is obtained from token database 18, wherein the new privacy token has a new IMSI and a new MSISDN associated therewith, which are different from the IMSI and MSISDN associated with the previous privacy token. The process then continues with steps 106-114 as described above. Column 6, lines 1-16).
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
The motivation for combining Modi et al. and Mouton et al. is recited in claims 1, 9, 15.
Claim 8:
With respect to claim 8, the combination of Modi et al. and Mouton et al. discloses the limitations of claim 1, as addressed.
Modi et al. discloses wherein the client account comprises a list of MSISDNs identifying clients that are permitted to access the IMS core network, a list of MSISDNs identifying second clients that the clients are permitted to communicate with using the IMS core network, and a list of services that the clients are permitted to receive using the IMS core network (the authorization component can access subscriber-related information (e.g., subscriber identification information, subscription or account status information, or service plan information, . . . ) in a data store (e.g., subscriber database in the data store), and can analyze the subscriber-related information to determine a subscriber or account status (e.g., active status, suspended status, terminated status, non-existent status), service(s) to which the user and/or communication device (e.g., subscriber) is subscribed and/or has an account, and/or type of service plan associated with the service, etc., 0032) (subscriber database, Figure 3, 340, 342).
Mouton et al. teaches wherein the client account comprises a list of MSISDNs identifying clients that are permitted to access the IMS core network, a list of MSISDNs identifying second clients that the clients are permitted to communicate with using the IMS core network, and a list of services that the clients are permitted to receive using the IMS core network (The token database comprises a pool of IMSIs and MSISDNs, and the IMSI and MSISDN to be associated with a privacy token are selected from their respective pools, Column 2, lines 31-34, token database, first token, second token, IMSI associated).
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
The motivation for combining Modi et al. and Mouton et al. is recited in claim 1.
Claim 9:
With respect to claim 9, Modi et al. discloses a method implemented in a communication network including an Internet Protocol (IP) Media Subsystem (IMS) core network (authentication component 338 can facilitate performing the AKA between the authentication component 338 and a subscriber identity module (SIM), a UMTS or universal SIM (USIM), or an IP multimedia services identity module (ISIM) of the communication device, wherein the client (e.g., trusted client) of the communication device can have access to the SIM, USIM, or ISIM to request the AKA procedure, 0087) to perform point-of-use token validation (token validation, Figures 3, 5, and 9), wherein the method comprises:
performing, by a core application executing at a core access network element in the
IMS core network, a registration of a first client with the IMS core network based on a mobile station international subscriber directory number (MSISDN) of the first client and an access token associated with the first client (token validation request, comprising an encrypted token, can be received by the authorization component from an application component, wherein the encrypted authentication token can comprise encrypted device identifier information that can facilitate identifying the device, 0150, Figure 8, 802, Figure 9, 906) (communication device information, such as, for example, a device identifier (e.g., international mobile subscriber identity (IMSI), mobile station international subscriber directory number (MSISDN), 0064) (The encrypted token can comprise device identifier information (e.g., IMSI, MSISDN, MAC address, device serial number, transaction ID, device ID, 0088);
maintaining, by the core application, the registration of the first client with the IMS
core network based on the access token used while performing the registration of the first client with the IMS core network (application server to know (e.g., know in real time) a subscription or account status of a particular communication device and associated user (e.g., subscriber) with regard to the communication service to facilitate knowing whether the particular communication device and user are authorized to access the application server and utilize the communication service, 0022) (can provide the application component 108 (or configuration component 112) a real-time or substantially real-time update regarding the subscriber or account status of the communication device 104 and/or user with regard to the requested service 110 to ensure that only an authorized communication device and/or user (e.g., with an active status) can gain access to the service 110, 0071);
transmitting, by the core application to the first client, an incoming service notification
indicating that an anonymized service has been requested involving the first client (to prevent undesired (e.g., unauthorized or malicious) access, 0022) (the authorization component 114 determines that token 208 is not authenticated, and accordingly, the communication device 104 and/or associated user are not authenticated, the authorization component 114 can generate not-validated information that can indicate that the token 208, and accordingly, the communication device 104 and/or user, are not validated and the communication device 104 and/or user are not authorized to access and utilize the requested service 110. 0062);
verifying, by an identity application at an identity management server communicatively coupled to the IMS core network, at least one of the MSISDN of the first client, a second MSISDN identifying the second client, or the requested service based on a client account associated with the first client (Based at least in part on the decryption of the encrypted token, and the information, including the device identifier information and/or token-related information, obtained from decrypting the token and/or a device identifier of the communication device that provided the encrypted token to the application component, the authorization component can determine whether the token is validated. For instance, the authorization component can analyze such information to determine whether the token is verified to be the same encrypted token the authorization component communicated to the communication device and/or determine whether the device identifier information in the token matches the device identifier of the communication device that provided the encrypted token to the application component. 0160, Figure 9, 910); and
completing, by the IMS core network, the requested service between the second
client and the first client (facilitate allowing communication device to access and utilize the service, Figure 9, 922).
Modi et al. does not disclose receiving, by the core application, an access request for a requested service from a second client, wherein the requested service is to complete a call from the second client to the first client;
in response to transmitting the incoming service notification to the first client,
receiving, by the core application, an access request from the first client, wherein the
access request comprises the access token of the first client and the MSISDN of the first client;
authenticating, by an authorization application at an authorization server
communicatively coupled to the IMS core network, the access token based on a current
and valid access token assigned to the first client as claimed.
However, Mouton et al. teaches using a dynamic International Mobile Subscriber Identity (IMSI) and Mobile Station International Subscriber Director Number (MSISDN) (Abstract), receiving, by the core application, an access request for a requested service from a second client (establishing a privatized communications session between UE 12 and another mobile device 20, MNO 14 queries the database for the IMSI/MSISDN of the mobile device 20 with which UE 12 is requesting a communications session. The query returns a result that the IMSI/MSISDN associated with mobile device 20 is associated with a privacy token. the communications session is established based on the privacy token, rather than the IMSI or MSISDN, although the IMSI and MSISDN are appended to the privacy token to ensure compliance with GSMA requirements, Column 4, lines 21-41, Figure 4), wherein the requested service is to complete a call from the second client to the first client (The established communications session is fully private because neither MNO 12 nor MNO 22 is aware of the identity of UE 12 or mobile device 20. Column 4, lines 43-46) (session established, Figure 4);
in response to transmitting the incoming service notification to the first client,
receiving, by the core application, an access request from the first client, wherein the
access request comprises the access token of the first client and the MSISDN of the first client (if the validity period of the privacy token has expired, the privacy token and the IMSI and MSISDN are released back to token database 18. The process then returns to step 102, in which UE 12 requests a new privacy token. the new privacy token is obtained from token database 18, wherein the new privacy token has a new IMSI and a new MSISDN associated therewith, Column 6, lines 7-16);
authenticating, by an authorization application at an authorization server
communicatively coupled to the IMS core network, the access token based on a current
and valid access token assigned to the first client (the communications session is established based on the privacy token, rather than the IMSI or MSISDN, although the IMSI and MSISDN are appended to the privacy token to ensure compliance with GSMA requirements, Column 4, lines 21-41, Figure 4) (the first privacy token and its associated IMSI are registered into a database, such that the first IMSI is mappable to the first privacy token, column 1, lines 58-61) (the IMSI/MSISDN is mappable to the specific privacy token, the session request is sent to a second MNO 22, which provides mobile services to mobile device 20. Although second MNO 22 is not aware of the IMEI of mobile device 20, MNO 22 is aware of the specific token currently associated with the specific IMSI and MSISDN, column 4, lines 32-37).
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Mouton et al. in Modi et al. because the data exchanged via mobile communications network can be highly sensitive, it is paramount that privacy of such data be ensured. Accordingly, there is a strong and unfulfilled need to privatize mobile communications, such that in an event of a data breach, the data cannot be attributed to any specific entity. (see Mouton et al. Column 1, lines 19-31)
Claim 15:
With respect to claim 15, Modi et al. discloses a communication network (token validation, Figures 3, 5, and 9), comprising:
a core access network element (Figure 10) comprising:
a non-transitory memory (memory, Figure 10) ;
a processor coupled to the non-transitory memory (processing unit, Figure 10); and
a core application stored at the non-transitory memory, which when executed
by the processor, causes the processor to be configured to:
perform a registration of a first client with an Internet Protocol (IP) Media Subsystem (IMS) core network (authentication component 338 can facilitate performing the AKA between the authentication component 338 and a subscriber identity module (SIM), a UMTS or universal SIM (USIM), or an IP multimedia services identity module (ISIM) of the communication device, wherein the client (e.g., trusted client) of the communication device can have access to the SIM, USIM, or ISIM to request the AKA procedure, 0087) based on a mobile station international subscriber directory number (MSISDN) of the first client and an access token associated with the first client (token validation request, comprising an encrypted token, can be received by the authorization component from an application component, wherein the encrypted authentication token can comprise encrypted device identifier information that can facilitate identifying the device, 0150, Figure 8, 802, Figure 9, 906) (communication device information, such as, for example, a device identifier (e.g., international mobile subscriber identity (IMSI), mobile station international subscriber directory number (MSISDN), 0064) (The encrypted token can comprise device identifier information (e.g., IMSI, MSISDN, MAC address, device serial number, transaction ID, device ID, 0088);
maintain the registration of the first client with the IMS core network by automatically performing one or more refresh operations on the registration of the first client with the IMS core network (application server to know (e.g., know in real time) a subscription or account status of a particular communication device and associated user (e.g., subscriber) with regard to the communication service to facilitate knowing whether the particular communication device and user are authorized to access the application server and utilize the communication service, 0022) (can provide the application component 108 (or configuration component 112) a real-time or substantially real-time update regarding the subscriber or account status of the communication device 104 and/or user with regard to the requested service 110 to ensure that only an authorized communication device and/or user (e.g., with an active status) can gain access to the service 110, 0071); and
receive an access request for a requested service either from the first client or a second client (receive authentication request, Figure 9, 902);
an authorization server comprising an authorization application stored at a non-
transitory memory of the authorization server, which when executed by a processor of the authorization server, causes the authorization application to be configured to authenticate the access token based on a current and valid access token assigned to the first client (a determination can be made, by the authorization component, whether the communication device is validated based at least in part on analyzing the encrypted token and a private decryption key, 0150, Figure 8, 804, token validates, Figure 9, 910); and
an identity management server comprising an identity application stored at a non-
transitory memory of the identity management server, which when executed by a processor of the identity management server, causes the identity application to be configured to verify at least one of the MSISDN of the first client, a second MSISDN identifying the second client, or the requested service based on a client account associated with the first client, (The authorization component 338 can decrypt the encrypted token, including the encrypted device identifier information, based at least in part on a private decryption key, the initialization vector, and a decryption algorithm, to generate decrypted information, including the device identifier information (e.g., IMSI, MSISDN, MAC address, device serial number, transaction ID, device ID, item of data, or other desired device identifier information associated with the communication device), 0089) (Based at least in part on the decryption of the encrypted token, and the information, including the device identifier information and/or token-related information, obtained from decrypting the token and/or a device identifier of the communication device that provided the encrypted token to the application component, the authorization component can determine whether the token is validated. For instance, the authorization component can analyze such information to determine whether the token is verified to be the same encrypted token the authorization component communicated to the communication device and/or determine whether the device identifier information in the token matches the device identifier of the communication device that provided the encrypted token to the application component. 0160, Figure 9, 910).
Modi et al. does not disclose wherein the IMS core network provides the requested service between the first client and the second client in response to the access token being authenticated and the at least one of the MSISDN of the first client, the second MSISDN identifying the second client, or the requested service being validated.
However, Mouton et al. teaches using a dynamic International Mobile Subscriber Identity (IMSI) and Mobile Station International Subscriber Director Number (MSISDN) (Abstract), wherein the IMS core network provides the requested service between the first client and the second client in response to the access token being authenticated and the at least one of the MSISDN of the first client, the second MSISDN identifying the second client, or the requested service being validated (establishing a privatized communications session between UE 12 and another mobile device 20, MNO 14 queries the database for the IMSI/MSISDN of the mobile device 20 with which UE 12 is requesting a communications session. The query returns a result that the IMSI/MSISDN associated with mobile device 20 is associated with a privacy token. the communications session is established based on the privacy token, rather than the IMSI or MSISDN, although the IMSI and MSISDN are appended to the privacy token to ensure compliance with GSMA requirements, Column 4, lines 21-41, Figure 4)(The established communications session is fully private because neither MNO 12 nor MNO 22 is aware of the identity of UE 12 or mobile device 20. Column 4, lines 43-46) (session established, Figure 4).
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Mouton et al. in Modi et al. because the data exchanged via mobile communications network can be highly sensitive, it is paramount that privacy of such data be ensured. Accordingly, there is a strong and unfulfilled need to privatize mobile communications, such that in an event of a data breach, the data cannot be attributed to any specific entity. (see Mouton et al. Column 1, lines 19-31)
Claim 16:
With respect to claim 16, Modi et al. discloses wherein the core application is further configured to transmit an incoming service notification indicating that an anonymized
requested service has been received for the first client (to prevent undesired (e.g., unauthorized or malicious) access, 0022) (the authorization component 114 determines that token 208 is not authenticated, and accordingly, the communication device 104 and/or associated user are not authenticated, the authorization component 114 can generate not-validated information that can indicate that the token 208, and accordingly, the communication device 104 and/or user, are not validated and the communication device 104 and/or user are not authorized to access and utilize the requested service 110. 0062).
Claim 17:
With respect to claim 17, Modi et al. discloses wherein the core application is further
configured to receive a registration message from the first client, wherein the registration message comprises the access token and the MSISDN of the first client (token validation request, comprising an encrypted token, can be received by the authorization component from an application component, wherein the encrypted authentication token can comprise encrypted device identifier information that can facilitate identifying the device, 0150, Figure 8, 802, Figure 9, 906) (communication device information, such as, for example, a device identifier (e.g., international mobile subscriber identity (IMSI), mobile station international subscriber directory number (MSISDN), 0064) (The encrypted token can comprise device identifier information (e.g., IMSI, MSISDN, MAC address, device serial number, transaction ID, device ID, 0088), wherein the authorization application is further configured to authenticate the access token (a determination can be made, by the authorization component, whether the communication device is validated based at least in part on analyzing the encrypted token and a private decryption key, 0150, Figure 8, 804, token validates, Figure 9, 910) based on the client account (the authorization component can access subscriber-related information (e.g., subscriber identification information, subscription or account status information, or service plan information, . . . ) in a data store (e.g., subscriber database in the data store), and can analyze the subscriber-related information to determine a subscriber or account status (e.g., active status, suspended status, terminated status, non-existent status), service(s) to which the user and/or communication device (e.g., subscriber) is subscribed and/or has an account, and/or type of service plan associated with the service, etc., 0032), and
wherein the identity application is further configured to verify a permission of the at least one of the MSISDN of the first client, the second MSISDN identifying the second client, or the requested service (the authorization component can access subscriber-related information (e.g., subscriber identification information, subscription or account status information, or service plan information, . . . ) in a data store (e.g., subscriber database in the data store), and can analyze the subscriber-related information to determine a subscriber or account status (e.g., active status, suspended status, terminated status, non-existent status), service(s) to which the user and/or communication device (e.g., subscriber) is subscribed and/or has an account, and/or type of service plan associated with the service, etc., 0032),
Claim 20:
With respect to claim 20, the combination of Modi et al. and Mouton et al. discloses the limitations of claim 15, as addressed.
Mouton et al. teaches wherein the requested service comprises at least one of a call from the first client to the second client, a call from the second client to the first client, sending a message from the first client to the second client, or sending a message from the second client to the first client (establish session, Figure 4, 12, 20).
Modi et al. and Mouton et al. are analogous art because they are from the same field of endeavor of Tokens associated with Mobile Station International Subscriber Director Number (MSISDN).
The motivation for combining Modi et al. and Mouton et al. is recited in claim 15.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure, (see PTO Form 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Helai Salehi whose telephone number is 571-270-7468. The examiner can normally be reached on Monday - Friday from 9 am to 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, Jeff Pwu, can be reached on 571-272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HELAI SALEHI/ Examiner, Art Unit 2433
/JEFFREY C PWU/ Supervisory Patent Examiner, Art Unit 2433