DETAILED ACTION
1. Claims 1-20 are pending in this examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3. 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.
Continued Examination Under 37 CFR 1.114
4. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
Response to Arguments
5. Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Claim Rejections - 35 USC § 103
6.1. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
6.2. Claims 1, 4-7, 9-13, 15, 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application No. 20200162910 to Masure et al (“Masure”) in view of US Patent Application No. 20230091318 to Lindemann et al (“Lindemann”), and in view of US Patent Application No. 20170310647 to Hu et al (“Hu”).
As per claim 1, Masure discloses a system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the system to perform operations comprising: receiving, from a first remote computing device, a sign-on request; sending, in response to the sign-on request and using a user interface, sign-on information [0108] the service provider 41 presents the user 1 with a first web page 301 which includes a link 302 to sign in and a link 303 to sign in using a mobile number. For example, if SOAP or SAML is used, the service provider 41 presents a second web page 304 includes a field 305 for entering the telephone number, i.e. the MSISDN 27, of the terminal 4 possessed by the user 1. The web page 304 may include, in response to a challenge (not shown), a response 307. The web page 304 includes a link 308 to continue. If OpenID is used, the service provider 41 redirects to a centralized OpenID page hosted by the core identity backend 21. In case of an app running on the terminal 4, the telephone number can be transferred in app-to-app mode, also see figs. 2, 9 associated texts, [0069]);
receiving, at an application included in a subscriber identity module (SIM) component of the user device, a request for response from ([0089], he core identity backend 21 sends a request 175 for the IMSI 58 and IMEI 59 of the MSISDN 27 via the mobile network gateway 60 to the core mobile network systems 52 (step S435). The core mobile network systems 52 sends a reply 175 which contains the IMSI 57 and IMEI 59 at the time the terminal 4 is connected to the mobile network 51 and which is linked to the given MSISDN 27, which is known at that time and which is stored in the HLR 53. The IMSI 58 and IMEI 59 are stored in the table 23.);
determining a type associated with the request for response; generating, based on the type associated with the request for response and at the application, a response to the request for response ([0113]-[0116] The core identity backend 21 may also check the location of the terminal 4 (step S814). In particular, the core identity backend 21 may check whether the terminal 4 is located in an acceptable country or region of a country, is located in an unacceptable country or region of a country, or whether the login location and the location of the terminal 4 or the locations between two transactions differ by more than given distance or by more than given distance in a given time (e.g. login in country A and approval in country B which is over 1,000 km away, 2 minutes later). Thus, location can be used as a risk parameter for fraud detection and/or can be used as an additional factor for authentication. [0114] If the terminal fingerprint corresponds to the one obtained during the binding process, then the core identity backend 21 transmits a notification 317 to the app (step S815), also see ([0054], [0111]); and
encrypting, using a security key at the secure component, the response to generate an encrypted response ([0092] The SIM applet 6 retrieves the IMSI 28 from the EF file system 75 stored on the secure element 5 and the IMEI 29 of the terminal 4 from the baseband data 72 via the SIM toolkit 74 to create the terminal fingerprint 183 (step S443). Herein, the terminal fingerprint 183 created by the applet 6 is referred to as the “second terminal fingerprint” or “secure element-side terminal fingerprint”. The SIM applet 6 encrypts the second fingerprint 183, which contains the IMSI 28, the IMEI 29 and applet version (not shown), with the applet keys K2 (step S444) and sends the encrypted fingerprint 185 to the core identity backend 21 (step S445).
Masure does not explicitly disclose however in the same field of endeavor, Lindemann discloses receiving, by a user device and from a first remote computing device ([0755]); second or two authenticators ([0163]-[0165], figs. 11-12 and associated texts);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Masure with the teaching of Lindemann by including the feature of second or two authenticators, in order for Masure’s system for providing secure user authentication over a network using biometric data. A system, apparatus, method, and machine-readable medium are described for personalizing and pre-registering an authenticator. For example, one embodiment of a method comprising: confirming an identity of a user by a first relying party using a first identity verification technique responsive to the user performing a first transaction with the first relying party; generating or collecting initial user verification
reference data (IUVRD) upon verifying the identity of the user through the first identity
verification technique; requesting personalization of an authenticator; storing the IUVRD into the authenticator; generating, by the authenticator, Fast Identity Online (FIDO) credentials including a private and public key pair; storing the FIDO credentials in a secure storage of the authenticator; providing the public key to the first relying party; securely providing the authenticator to the user; and implementing a second identity
verification technique by comparing the stored IUVRD to data collected from the user (Lindemann, abstract).
Masure and Lindemann do not explicitly disclose however in the same field of endeavor, Hu discloses sending form the application to a secure component included in the sim component ([0053], FIG. 4 outlines the steps that are required to fulfill a verifier's request for authentication using the device authentication system in an example embodiment, which uses TEE. The untrusted operating system (e.g., Android) is referred to as the rich OS 430. The SE 445 and I/O interface 440 may be shared between the rich OS 430 and TEE 420. The device authentication system leverages the TEE 420 to establish secure channels with the device's peripherals. Within the TEE 420, the arbiter 422 executes the code that handles the context switching of the processor between the trusted and untrusted environments. In an example embodiment, the arbiter is an optional component. The device authentication system specific code and the associated micro-kernel are referred to as the trusted OS 421. In an example embodiment, the delegate (for example an external device) is treated the same as applications running in the rich OS 430. The delegate may be utilized to handoff data between the third party verifier 450 and the authentication device 410, also see fig. 3 and associated texts, [0047]-[0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Masure and Lindemann with the teaching of HU by including the feature of secure component, in order for Masure’s system for for authenticating user device interactions with external entities. A secure communication session is established between an external device or application and a trusted execution environment. An authentication request is received from the external application or device at the trusted execution environment. A secure communication channel is established between the trusted execution environment and an input/output interface of the user authentication device. Input is received from a user assurance action related to the authentication request over the secure communication channel. Data is encrypted at a secure element of the user authentication device, and a response is transmitted including the encrypted data and an indicator of the user assurance action to the external application or device from the trusted execution environment in response to the authentication request via the secure communication session (HU, abstract).
As per claim 4, the combination of Masure, Lindemann and HU discloses the system of claim 1, wherein the type associated with the request for response is a location, the operations further comprising: determining, using a localization component, location data associated with the SIM component; and generating the response, wherein the response comprises the location data (Masure, [0113]-[0116]).
As per claim 5, the combination of Masure, Lindemann and HU discloses the system of claim 1, wherein the type associated with the request for response is a confirmation, the operations further comprising: generating, using a second user interface, a prompt associated with the confirmation; receiving, at the second user interface, an answer associated with the confirmation; and generating the response, wherein the response comprises the answer (Masure, [0111]-[0116], also see [0009]-[0014], [0120]-[0122], [0096]-[0100]).
As per claim 6, the combination of Masure, Lindemann and HU discloses the method comprising: receiving, at an application associated with an integrated circuit component, a request for response from a remote computing device, the request being associated with a sign-on process associated with an online service provider [0108] the service provider 41 presents the user 1 with a first web page 301 which includes a link 302 to sign in and a link 303 to sign in using a mobile number. For example, if SOAP or SAML is used, the service provider 41 presents a second web page 304 includes a field 305 for entering the telephone number, i.e. the MSISDN 27, of the terminal 4 possessed by the user 1. The web page 304 may include, in response to a challenge (not shown), a response 307. The web page 304 includes a link 308 to continue. If OpenID is used, the service provider 41 redirects to a centralized OpenID page hosted by the core identity backend 21. In case of an app running on the terminal 4, the telephone number can be transferred in app-to-app mode, … ([0089], the core identity backend 21 sends a request 175 for the IMSI 58 and IMEI 59 of the MSISDN 27 via the mobile network gateway 60 to the core mobile network systems 52 (step S435). The core mobile network systems 52 sends a reply 175 which contains the IMSI 57 and IMEI 59 at the time the terminal 4 is connected to the mobile network 51 and which is linked to the given MSISDN 27, which is known at that time and which is stored in the HLR 53. The IMSI 58 and IMEI 59 are stored in the table 23. also see figs. 2, 9 associated texts, [0069]), also see [0052]);
generating a response to the request for response; sending, to a secure component associated with the integrated circuit component, the response; and
encrypting, at the secure component, the response to generate an encrypted response ([0113]-[0116] The core identity backend 21 may also check the location of the terminal 4 (step S814). In particular, the core identity backend 21 may check whether the terminal 4 is located in an acceptable country or region of a country, is located in an unacceptable country or region of a country, or whether the login location and the location of the terminal 4 or the locations between two transactions differ by more than given distance or by more than given distance in a given time (e.g. login in country A and approval in country B which is over 1,000 km away, 2 minutes later). Thus, location can be used as a risk parameter for fraud detection and/or can be used as an additional factor for authentication. [0114] If the terminal fingerprint corresponds to the one obtained during the binding process, then the core identity backend 21 transmits a notification 317 to the app (step S815),… ([0092] The SIM applet 6 retrieves the IMSI 28 from the EF file system 75 stored on the secure element 5 and the IMEI 29 of the terminal 4 from the baseband data 72 via the SIM toolkit 74 to create the terminal fingerprint 183 (step S443). Herein, the terminal fingerprint 183 created by the applet 6 is referred to as the “second terminal fingerprint” or “secure element-side terminal fingerprint”. The SIM applet 6 encrypts the second fingerprint 183, which contains the IMSI 28, the IMEI 29 and applet version (not shown), with the applet keys K2 (step S444) and sends the encrypted fingerprint 185 to the core identity backend 21 (step S445) also see ([0054]).
wherein the integrated circuit component is a subscriber identity module (SIM) component, the remote computing device is associated with a cellular carrier of the SIM component ([0052]-[0056], fig. 4 and associated texts)
Masure does not explicitly disclose however in the same field of endeavor, Lindemann discloses receiving, by a user device and from a first remote computing device ([0755]); second or two authenticators ([0163]-[0165], figs. 11-12 and associated texts).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Masure with the teaching of Lindemann by including the feature of second or two authenticators, in order for Masure’s system for providing secure user authentication over a network using biometric data. A system, apparatus, method, and machine-readable medium are described for personalizing and pre-registering an authenticator. For example, one embodiment of a method comprising: confirming an identity of a user by a first relying party using a first identity verification technique responsive to the user performing a first transaction with the first relying party; generating or collecting initial user verification
reference data (IUVRD) upon verifying the identity of the user through the first identity verification technique; requesting personalization of an authenticator; storing the IUVRD into the authenticator; generating, by the authenticator, Fast Identity Online (FIDO) credentials including a private and public key pair; storing the FIDO credentials in a secure storage of the authenticator; providing the public key to the first relying party; securely providing the authenticator to the user; and implementing a second identity verification technique by comparing the stored IUVRD to data collected from the user (Lindemann, abstract).
Masure and Lindemann do not explicitly disclose however in the same field of endeavor, Hu discloses generating/sending form the application to a secure component, as well as response ([0053], FIG. 4 outlines the steps that are required to fulfill a verifier's request for authentication using the device authentication system in an example embodiment, which uses TEE. The untrusted operating system (e.g., Android) is referred to as the rich OS 430. The SE 445 and I/O interface 440 may be shared between the rich OS 430 and TEE 420. The device authentication system leverages the TEE 420 to establish secure channels with the device's peripherals. Within the TEE 420, the arbiter 422 executes the code that handles the context switching of the processor between the trusted and untrusted environments. In an example embodiment, the arbiter is an optional component. The device authentication system specific code and the associated micro-kernel are referred to as the trusted OS 421. In an example embodiment, the delegate (for example an external device) is treated the same as applications running in the rich OS 430. The delegate may be utilized to handoff data between the third party verifier 450 and the authentication device 410, also see fig. 3 and associated texts, [0047]-[0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Masure and Lindemann with the teaching of HU by including the feature of secure component, in order for Masure’s system for for authenticating user device interactions with external entities. A secure communication session is established between an external device or application and a trusted execution environment. An authentication request is received from the external application or device at the trusted execution environment. A secure communication channel is established between the trusted execution environment and an input/output interface of the user authentication device. Input is received from a user assurance action related to the authentication request over the secure communication channel. Data is encrypted at a secure element of the user authentication device, and a response is transmitted including the encrypted data and an indicator of the user assurance action to the external application or device from the trusted execution environment in response to the authentication request via the secure communication session (HU, abstract).
As per claim 7, the combination of Masure, Lindemann and Hu discloses the method of claim 6, further comprising sending the encrypted response to a remote computing device (Masure, [0092]).
As per claim 9, the combination of Masure, Lindemann and Hu discloses the method of claim 6, further comprising: determining a type associated with the request for response, wherein the type comprises a location or a confirmation (Masure, ([0113]-[0116], also see [0089]).
Claims 10 &18, are rejected for similar reasons as stated above claim 4.
Claim 11, is rejected for similar reasons as stated above claim 5.
As per claim 12, the combination of Masure, Lindemann and Hu discloses the method of claim 6, further comprising: determining that the application is not installed at the integrated circuit component; and installing, based on the application not being installed at the integrated circuit component, the application to the integrated circuit component (Masure, [0088]).
As per claim 13, the combination of Masure, Lindemann and Hu discloses the method of claim 6, further comprising: generating, at the secure component, a first security key and a second security key, the second security key being mathematically computed or derived from the first security key and is different from the first security key (Masure, [0090]-[0095], also see [0109]-[0111], [0009]-[0014]);
wherein the first security key is configured to encrypt the response to the request for response and second security key is configured to decrypt the response encrypted by the first security key; and sending the second security key to the remote computing device (Masure, [0111]-[0116], also see [0009]-[0014], [0120]-[0122], [0096]-[0100],).
Claim 15, is rejected for similar reasons as stated above claim 6 and 1.
Claim 17, is rejected for similar reasons as stated above claim 9.
Claim 19, is rejected for similar reasons as stated above claim 13.
6.3. Claims 2, 8, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Masure, Lindemann and Hu as applied to claim above, and in view of US Patent Application No. 20240311514 to Dutta et al (“Dutta”).
As per claim 2, the combination of Masure, Lindemann and Hu discloses the invention as described above. Masure, Lindemann and Hu do not explicitly disclose however, In the same field of endeavor, Dutta discloses the system of claim 1, the operations further comprising: coupling, at the secure component, the encrypted response to a certificate to generate a signed response; and sending the signed response to the second remote computing device (Dutta, [0110]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Masure, Lindemann and Hu with the teaching of Dutta by including the feature of a certificate, in order for Masure’s system for securely digital identity is stored in the SIM. The present disclosure provides a system and a method for Public Key Infrastructure (PKI) enabled Subscriber Information Management (SIM) for digital identity management. The method includes receiving a request for issuance of a digital identity for the SIM associated with a user. Responsive to an affirmative verification of a set of documents, the method includes transmitting user information determined from the verified set of documents and a predetermined signal to a Certification Authority (CA). Further, the digital identity is generated upon receiving a Certifying Signing Request (CSR) from an end-entity and a second predetermined signal from a verification source. The generated digital identity is transmitted to the end-entity and to the SIM via a middleware (Dutta, abstract).
As per claim 8, the combination of Masure, Lindemann, Hu, and Dutta discloses the method of claim 6, further comprising: coupling, at the secure component, the encrypted response with a certificate to generate a signed response; and sending the signed response to the remote computing device (Dutta, [0110]). The motivation regarding the obviousness of claim 2 is also applied to claim 8.
Claims 16, are rejected for similar reasons as stated above and claims above 2 and 8.
6.4. Claims 3, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Masure, Lindemann and Hu as applied to claim above, and in view of US Patent Application No. 20200235923 to Nix et al (“Nix”).
As per claim 3, the combination of Masure, Lindemann and Hu discloses the invention as described above, including Masure discloses system of claim 1, wherein the security key is a first security key, the operations further comprising: determining, in response to the sign-on request, that the application is not installed at the SIM component; installing, based on the application not being installed, the application to the SIM component (Masure, [0088]);
generating, based on installing the application to the SIM component and at the secure component, the first security key and a second security key, the second security key being mathematically computed or derived from the first security key and is different from the first security key (Masure, [0090]-[0095], also see [0109]-[0111]);
Masure, Lindemann and Hu do not explicitly disclose however, In the same field of endeavor, Nix discloses the generating, at the secure component, a certificate associated with the second security key; and sending at least one of the second security key, the certificate, or a third security key associated with the certificate to the second remote computing device (Nix, [0119]-[0121], also see claim 1, [0285]-[0287]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Masure, Lindemann and Hu with the teaching of Nix by including the feature of Key, in order for Masure’s system to for secure and efficient communication using a server to communicate with modules and an application. The modules and application can support “Machine to Machine” communications. The methods and systems contemplated herein can also support other applications as well, including mobile phone handsets connecting to a wireless network. An objective of the invention is to address the challenges noted above for securing the deployment of modules that utilize PKI algorithms and keys, as well as increasing efficiency in order to reduce power consumption, including extending the battery life of a module, if present. More efficient communication can also conserve valuable radio-frequency spectrum, among other benefits. Using a server for secure and reliable communication of data between an application and a module can increase the value and usefulness of modules for a user (Nix, [0117]).
As per claim 14, the combination of Masure, Lindemann, Hu and Nix discloses the method of claim 13, further comprising: generating, at the secure component, a certificate associated with the second security key; and sending the certificate or a third security key associated with the certificate to the second remote computing device (Nix, [0119]-[0121], also see claim 1, [0285]-[0287]). The motivation regarding the obviousness of claim 3 is also applied to claim 14.
Claim 20, is rejected for similar reasons as stated above claim 14.
7.1. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art discloses many of the claim features (See PTO-form 892).
7.2. a). US Patent Application No. 20200045046 to Nowak et al., discloses FIDO (“Fast IDentity Online”) authentication processes and systems are described. In an embodiment, a FIDO (“Fast IDentity Online”) authentication process includes a FIDO information systems (IS) computer system receiving a FIDO authentication request for a transaction from a user device, the FIDO authentication request including user data and user device authenticator data, then verifying the user data and user device authenticator data, selecting a FIDO-certified server based on a list of authorized authenticators, business rules and the user device authenticator data, and transmitting the FIDO authentication request to the selected FIDO server. The process also includes the FIDO IS computer system receiving an authentication result from the FIDO-certified server, and transmitting the authentication result to the user device.
b). US Patent No. 10129252 issued to Suen et al., discloses a system and method of validating an identity of a user device is disclosed that includes registering a biometric signature with an authoritative identity source, transmitting an encrypted user identity element from the authoritative identity source to a user device, sending an identity request from a third party entity to the user device, transmitting the encrypted user identity element from the user device to the third party, sending an identity validation request from the third party to the authoritative identity source, transmitting a communication from the authoritative identity request to the third party entity, and informing the third party entity if the identity of the user is confirmed.
Conclusion
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARUNUR RASHID whose telephone number is (571)270-7195. The examiner can normally be reached 9 AM to 5PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
HARUNUR . RASHID
Primary Examiner
Art Unit 2497
/HARUNUR RASHID/Primary Examiner, Art Unit 2497