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 .
This communication is in response to the election of group 1 of the application for prosecution filed on 03/15/2026. Claims 1-10 are currently pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200280855 to Avetisov et al. (hereinafter Avetisov) in view of US, PGPub. No. 20170046792 to HALDENBY et al. (hereinafter HALDENBY).
Regarding claim 1, Avetisov discloses a mobile device secure communications method (FIGs 1-3A, ¶0281-¶0282, “FIG. 3A is a diagram showing an example of a process 300A for authentication of a user. The process 300A may occur within an example computing environment, such as the example computing environment 100A illustrated in FIG. 1A, the example computing environment 100B illustrated in FIG. 1B, or the example computing environment 200 illustrated in FIG. 2… The process 300A of FIG. 3A illustrates operations performed by a device, such as a mobile device 101 including a trusted execution environment 103 and authentication application (e.g., an authentication application 120 or 220), according to at least one embodiment described herein. While example authentication application 120 is shown in FIG. 3A by reference, example authentication application 220 may be configured to perform all or some of the illustrated operations described below. Accordingly, reference to authentication application 120 should be not construed as limiting. As described previously, example mobile devices 101 may include a trusted execution environment 103 and execute an authentication application 120 (or authentication application 220). As such, the separation of the blocks 101, 103, 120 may be considered illustrative as each of the operations may be performed on a mobile device 101.”), comprising:
providing a first secure communications application in a memory device of a first mobile computing device (FIG. 1A, ¶0063, 120, 101, “FIG. 1A illustrates an example computing environment 100A within which an out-of-band authentication system with a client-side role in out-of-band authentication may be implemented. In some embodiments, the computing environment 100A may include a mobile device 101, a client device 135, a relaying party 145, and an authentication server 155. These components may communicate with one another via a network 121, such as the Internet and various other local area networks. In addition, embodiments of the example computing environment 100A may include a mobile computing client device, such as mobile device 101, that supports client-side out-of-band authentication based on a secure channel to a trusted execution environment”), (¶077, “…For example, the secure channel may protect communications between a trusted application or module within the TEE 103 and the API 104 such that other trusted applications or modules within the TEE 103 are prevented from accessing data communicated between the authentication application 120 and the trusted application or module which the communication session was established via the API 104”); and
executing software instructions of the first secure communications application (¶0282, “The process 300A of FIG. 3A illustrates operations performed by a device, such as a mobile device 101 including a trusted execution environment 103 and authentication application (e.g., an authentication application 120 or 220), according to at least one embodiment described herein. While example authentication application 120 is shown in FIG. 3A by reference, example authentication application 220 may be configured to perform all or some of the illustrated operations described below…”), wherein the executing is arranged to carry out the acts of:
requesting at least one identification number (¶0095, “The authentication application 120 may be configured to establish a session defining a secure channel with the TEE 103 to protect data communications between the authentication application and the TEE. For example, the authentication application 120 may be configured to generate an identifier and provide the identifier to the TEE 103, such as via the API 104. The identifier may be tied to the authentication application 120, determined at random, selected deterministically (e.g., based on a register value, system time, etc.), or a combination thereof, such as concatenation of an identifier tied to the authentication application 120 and a current system time.…”);
selecting an identification number from the at least one identification number (¶0095, “…The identifier may be tied to the authentication application 120, determined at random, selected deterministically (e.g., based on a register value, system time, etc.), or a combination thereof, such as concatenation of an identifier tied to the authentication application 120 and a current system time. Further, the identifier may be determined by a processing of the data described above, such as by input of the data into a cryptographic hashing function or key generation algorithm to generate the identifier…”);
blockchain smart contract (¶0188, “… reference other smart contracts or invoke or draw upon logic implemented outside of the decentralized computing platform. For example, a smart contract for performing a process like that in FIG. 3B (e.g., for authentication of a user) may in some instances call to another smart contract to perform a process like that in FIG. 6 (e.g., for authentication of a user based on records or verification of authentication as publishing of a record of that authentication). Similarly, a smart contract or contracts may perform processes like those described in FIGS. 3 and 5-9 and implement other processes (e.g., like one or more processes performed by a server) discussed with reference to FIG. 1A, FIG. 1B, or FIG. 2…”), (¶0189, “…Such smart contracts may be implemented on computing nodes 207 participating on a protocol corresponding to the decentralized data store, such as an Ethereum blockchain protocol for an Ethereum based block-chain data store.”)
However, Avetisov does not explicitly disclose the following limitation:
receiving a hash of the identification number from a registrar, the registrar having signed the hash of the identification number;
signing a transaction involving the identification number; and
directing registration of the hashed and signed version of the identification number on a blockchain smart contract using a public key controlled with a private key associated with a first user, wherein the registering causes the registrar to store a public number hash of the identification number, a controller public key associated with the identification number, and
a representation of a first encoded human readable datum (EHRD) associated with the identification number.
HALDENBY discloses receiving a hash of the identification number from a registrar, the registrar having signed the hash of the identification number (¶0054, “…The one or more of peer systems 160 may be further configured to generate one or more hashes representative of the new block, which may be appended to a prior version of the hybrid private-public ledger along with the newly generated block...”, wherein the cryptographic hashes are used as unique identifier (ID) for a new block in a blockchain, typically represented as a 64-character hexadecimal string);
signing a transaction involving the identification number (¶0089, “…client device 102 may append the encrypted and/or hashed copies of rules engine 324 and trigger event list 322 to the data specifying transaction 308 (e.g., cryptographic hash 308A, public key 308B, and digital signature 308C), and transmit the data specifying transaction 308B to one or more of peer systems 160 for verification, processing (e.g., additional cryptographic hashing) and inclusion into a new block of the hybrid block-chain ledger.”);
directing registration of the hashed and signed version of the identification number on a blockchain smart contract using a public key controlled with a private key associated with a first user, wherein the registering causes the registrar to store a public number hash of the identification number, a controller public key associated with the identification number, and a representation of a first encoded human readable datum (EHRD) associated with the identification number (¶0045, “…The stored customer data may also include authentication credentials associated with registered users of the financial institution (e.g., a user name, a user-specified password, a system-generated password, an alphanumeric identification number (e.g., a PIN number) specified by the users or assigned by system 140, biometric information, and information facilitating enhanced authentication techniques).”), (¶0063, “data specifying transaction 204 may include, but is not limited to, a cryptographic hash 204A of prior transaction 202, a quantity or number of units of the tracked asset portion that are subject to transfer in transaction 204, and a public key of the recipient (e.g., public key 204B of user 112). Further, in some aspects, the data specifying transaction 204 may include a digital signature 204C of the user 110, which may be applied to hash 204A and public key 204B using a private key 204D of user 110 using any of the exemplary techniques described above …”), (¶0048, “… consistent with the disclosed embodiments, data repository 144 may be configured to store the rules engine and/or event triggers in encrypted form (e.g., using the stored master key), and/or store a hashed representation of the rules engine and/or the event triggers list. Systems 141 and 145 may be configured to store the private crypto keys, master key, rules engine, and/or event triggers within corresponding ones of data repositories 146 and 149 in a manner similar to that described above.”), (¶0176, “…The disclosed embodiments are, however, not limited to these exemplary encoding schemes, and in further embodiments, peer systems 160 may encode the new ledger block using a human readable crypto-graffiti encoding scheme, which may simplify the block-chain data structure. Further, and by way of example, the new ledger block generated by peer systems 160 may be structure to include, among other things: a block header (which identifies an address of a prior block); an identifier of the corresponding one or peer systems 160 that created the additional ledger block; a rules header that identifies the integrated and/or external sensor devices and includes a rules associate key (e.g., that associates a rule to the Internet-connected device); an encrypted list of event triggers and an encrypted rules engine; a header for the received transaction data; and the received transaction data written into the hybrid, block-chain data structure. In certain instances, peer systems 160 may write the transaction data into the additional ledger block as HEX, Unicode, a combinations of the two, and/or any additional or alternate encoding suitable for the transaction data and the new ledger block.”), (¶0093, “client device 104 may also parse data specifying prior transaction 308 (e.g., as obtained from the current version of the hybrid block-chain ledger) and extract encrypted and/or hashed copies of rules engine 324 and trigger event list 322. In certain aspects, client device 104 may append the encrypted and/or hashed copies of rules engine 324 and trigger event list 322 to the data specifying transaction 310 (e.g., cryptographic hash 310A, public key 310B, and digital signature 310C), and transmit the data specifying transaction 310 to one or more of peer systems 160 for verification, processing (e.g., additional cryptographic hashing) and inclusion into a new block of the hybrid block-chain ledge…”).
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Avetisov to include storing a representation of a first encoded human readable datum (EHRD) associated with the identification number as disclosed by HALDENBY and be motivated in doing so in order to simplify the block-chain data structure- HALDENBY ¶0176 in parts.
Regarding claim 2, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
Avetisov further discloses wherein the identification number is a telephone number (¶0048, “…Example of identifiers may include a network address identifier or a monitored address identifier. Example network address identifiers may include one or more of an IMEI number, telephone number, MAC and IP address, or other identifiers suitable to uniquely reference a given computing device...”).
Regarding claim 5, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
Avetisov further discloses wherein requesting at least one identification number includes requesting at least two identification numbers and wherein selecting the identification number includes selecting one of the at least two identification numbers (¶0008, “… requesting, by the application, from the trusted execution environment, a first key of a key-pair corresponding to a second key of the key-pair maintained in the secure memory and, for at least one credential in the set of credentials, a representation generated within the trusted execution environment, wherein the representation is indicative of a value of the corresponding credential, and the representation does not reveal the value; transmitting, from the first computing device, the representation and the first key or data corresponding to the representation and the first key over the secure session to the server; requesting, by the application, to the trusted execution environment, storage of a user certificate corresponding to the second computing device within the secure memory; receiving, by the application, a user selection of the second computing device; obtaining, by the application, from the trusted execution environment, data signed by the second key, the signed data being indicative of a result of user authentication on the first computing device; and transmitting, from the first computing device, data including the signed data to the server to cause the server to issue a user session to the second computing device based on authentication of the signed data.”), see also ¶0009.
Regarding claim 9, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
Avetisov further discloses wherein the executing software instructions are further arranged to carry out the acts of: receiving at the first secure communications application a request to connect (¶0035, “…the beacon may be operable to receive communications from the mobile device, such as to receive a login request, although the mobile device may transmit such login requests on another protocol…”), the request including a third identification number signed with a private key (¶0159, “… an authentication server 155 may verify access requests received from a mobile device 101, such as by verifying whether the access request complies with a policy, and which may include verification of representations of credentials stored by the user device, or other data, like certificates, such as by signature verification, where data is signed by a private key, or signature key, maintained within a TEE 103 of the mobile device 101 of the user…”);
performing a hash on the third identification number (¶0054, “…, different representations may be generated using different inputs to a cryptographic hashing function to obfuscate the credential values….”), (¶0095, “The established credentials 109 may include cryptographic hashes or other ciphertext of credential values whether biometric or alphanumeric, such that those representations may be passed to a sever, like authentication server 155, for authentication operations without divulging actual credential values. In addition, or alternatively, the established credentials 109 may include unique signature information from the TEE 103 (such as a public key) that is passed to the authentication server 155 such that signed data (with a corresponding private key) output by the TEE can be verified as originating from the TEE.”);
directing a look-up to determine if a version of the hashed third identification number is found on the blockchain smart contract (¶0193, “…The cryptographic hashes in the hash digest may be operable to identify (e.g., other transactions in other nodes by cryptographic hash pointer) or verify information (e.g., on-chain or off-chain information by cryptographic hash) associated with the transaction… In some embodiments, recording of information like a smart contract to the directed acyclic graph 205 of cryptographic hash pointers is achieved by storing the smart contract in node content of the directed acyclic graph of cryptographic of hash pointer by a transaction for storing data, like a sstore or Txdata function. In some embodiments, a cryptographic hash digest of the smart contract is stored in node content, where the cryptographic hash digest may include cryptographic hashes operable to identify previous versions of the smart contract (e.g., stored in other nodes by cryptographic hash pointer), identify other smart contracts to be called during execution of the smart contract (e.g., stored in other nodes by cryptographic hash pointer), or verify information (e.g., on-chain or off-chain information by cryptographic hash) such that the smart contract or other information access by the smart contract whether stored on-chain or off-chain can verified by the cryptographic hash digest.”); and
based on finding the version of the hashed third identification number on the blockchain smart contract, providing the first user with an opportunity to accept the request to connect (¶0062, “…Some embodiments may input such a credential or value based thereon into a one-way cryptographic function, like a cryptographic hash function, such use SHA 256, and embodiments may supply the output or a value based thereon via a network to a remote computing device that determines whether the user is to be authenticated based on a comparison between the cryptographic hash value and a previously stored cryptographic hash value, for instance, supplied during registration or credential creation based on the same input and hash function. Upon determining that the cryptographic hash values match, the corresponding security criterion may be determined to be have been satisfied by the remote computing device.”), see also ¶0191- ¶0195 for matching cryptographic hashes, (¶0307, “…In some embodiments, the request 504 also includes an encryption key such that the authentication server 155 may encrypt data for decoding only by the mobile device 101, like within the TEE of the mobile device 101, which may generate the encryption key. An encryption key may also be used to establish a secure connection, such as by HTTPS, TLS, etc., to afford secure communication of data between the mobile device 101 and the authentication server 155.”), (¶0338, “… the mobile device 101 and authentication server 155 may establish a secure session by the mobile device 101 transmitting a session key encrypted by the obtained public key to facilitate the exchange of information. The secure session may be HTTP over TLS/SSL, SSH, WebSocket over TCP, or other secure connection type by which the mobile device and authentication server 155 may exchange data, like registration information…”).
.
Regarding claim 10, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 9.
Avetisov further discloses wherein the executing software instructions are further arranged to carry out the acts of:
based on finding the version of the hashed third identification number on the blockchain smart contract, retrieving a representation of a third encoded human readable datum (EHRD) associated with the third identification number (¶0105, “… the application 110 may be a web browser configured to request data on and receive data from the server 145 for presentation on a display of the client device 135. Accordingly, the application 110 may be configured to retrieve data from the server 145 and present the data received from the server to the user. In some cases, the server 145 may redirect the application 110 to retrieve some or all data from one or more other servers, like server 155. The retrieved data, when executed or processed, may cause the application 110 to present on the display of the client device 135 a log-in page or other user interface including one or more fields or other user interface elements configured to receive user credential 111 input for accessing the online resource 147. In turn, the application 110 may transmit data corresponding to the credentials 111 input by the user, which may be a user name, password, or selection of one of more user interface elements, to a given server (e.g., at least one of server 145 or server 155) specified in the retrieved data for authentication. In some embodiments, the application 110 may transmit data corresponding to the credentials 111 without direct user input of the credentials, such as where the user has configured the application 110 to populate fields with or automatically submit stored credentials. In some embodiments, when executed or processed, the retrieved data may cause the application 110 to automatically collect or transmit other identifying data corresponding to the user or client device 135 with the credentials 111. For example, the application 110 may collect or generate identifying data about the user-client device 135 combination in the form of cookie, log, token, or other data. In addition, or alternatively, the application 110 may collect identifying data about the user-client device combination, such as by querying the runtime environment on the client device. All or a subset of the above information may be transmitted to one or more of servers 145 or 155.”, wherein user-client device information includes unique identification numbers (device IDs such as IMEI).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200280855 to Avetisov et al. (hereinafter Avetisov) in view of US. PGPub. No. 20170046792 to HALDENBY et al. (hereinafter HALDENBY) and further in view of US. PGPub. No. 20100266110 to SOO et al. (hereinafter SOO).
Regarding claim 3, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
However, Avetisov in view of HALDENBY does not explicitly disclose the limitation of:
wherein the identification number is a telephone number having an E.164 format.
SOO discloses wherein the identification number is a telephone number having an E.164 format (¶0032, “when the customer subscribes to a service from the IMS network 110, the service provider assigns the customer a phone number (e.g., an E.164 number) and any other credentials required for activation. The service provider may also provide the customer with a VCS, e.g., VCS 204. The customer may then connect the VCS 204 to the IP phone 102 and computer 103. The customer may then register using the provided credentials and phone number”). See also ¶0039.
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Avetisov and HALDENBY to include telephone number with E.164 format as disclosed by SOO and be motivated in doing so in order to ensure global uniqueness which allows accurate, automated international calls and SMS routing without errors.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200280855 to Avetisov et al. (hereinafter Avetisov) in view of US. PGPub. No. 20170046792 to HALDENBY et al. (hereinafter HALDENBY) and further in view of US. PGPub. No. 20180117447 to Tran et al. (hereinafter Tran).
Regarding claim 4, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
However, Avetisov in view of HALDENBY does not explicitly disclose:
wherein the representation of the first encoded human readable datum (EHRD) is a profile picture having hashed data embedded therein.
Tran discloses profile picture having hashed data embedded therein (¶0397, “a digital asset is certified via embedding its SHA256 digest in the blockchain. This is done by generating a transaction that encodes/contains the hash via an OP_RETURN script. This is a bitcoin scripting opcode that marks the transaction output as provably unspendable and allows a small amount of data to be inserted, which is the digital asset hash, plus a marker to identify all of a company's transactions. Once the transaction is confirmed by the blockchain, the digital asset is permanently certified and proven to exist at least as early as the time the transaction was confirmed”).
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Avetisov and HALDENBY to include having a hash embedded in a profile picture as disclosed by Tran and be motivated in doing so in order for the system to prove data ownership without revealing actual data by publicly revealing the SHA256 digest-Tran ¶0397 in parts.
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200280855 to Avetisov et al. (hereinafter Avetisov) in view of US. PGPub. No. 20170046792 to HALDENBY et al. (hereinafter HALDENBY) and further in view of US. Pat. No. 11368442 to Bhatnagar et al. (hereinafter Bhatnagar).
Regarding claim 6, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
Avetisov further discloses wherein the executing software instructions are further arranged to carry out the acts of:
accepting a second identification number at the first mobile computing device (¶0008, “…obtaining, by the application, from the trusted execution environment, data signed by the second key, the signed data being indicative of a result of user authentication on the first computing device;…”);
performing a hash on the second identification number (¶0062, “…Some embodiments may input such a credential or value based thereon into a one-way cryptographic function, like a cryptographic hash function, such use SHA 256, and embodiments may supply the output or a value based thereon via a network to a remote computing device that determines whether the user is to be authenticated based on a comparison between the cryptographic hash value and a previously stored cryptographic hash value, for instance, supplied during registration or credential creation based on the same input and hash function…”), (¶0054, “…, different representations may be generated using different inputs to a cryptographic hashing function to obfuscate the credential values…”);
directing a look-up to determine if a version of the hashed second identification number is found on the blockchain smart contract (¶0193, “…The cryptographic hashes in the hash digest may be operable to identify (e.g., other transactions in other nodes by cryptographic hash pointer) or verify information (e.g., on-chain or off-chain information by cryptographic hash) associated with the transaction… In some embodiments, recording of information like a smart contract to the directed acyclic graph 205 of cryptographic hash pointers is achieved by storing the smart contract in node content of the directed acyclic graph of cryptographic of hash pointer by a transaction for storing data, like a sstore or Txdata function. In some embodiments, a cryptographic hash digest of the smart contract is stored in node content, where the cryptographic hash digest may include cryptographic hashes operable to identify previous versions of the smart contract (e.g., stored in other nodes by cryptographic hash pointer), identify other smart contracts to be called during execution of the smart contract (e.g., stored in other nodes by cryptographic hash pointer), or verify information (e.g., on-chain or off-chain information by cryptographic hash) such that the smart contract or other information access by the smart contract whether stored on-chain or off-chain can verified by the cryptographic hash digest.”);
based on finding the version of the hashed second identification number on the blockchain smart contract, establish and conduct encrypted communications between the first mobile computing devices and a second mobile computing device (¶0062, “…Some embodiments may input such a credential or value based thereon into a one-way cryptographic function, like a cryptographic hash function, such use SHA 256, and embodiments may supply the output or a value based thereon via a network to a remote computing device that determines whether the user is to be authenticated based on a comparison between the cryptographic hash value and a previously stored cryptographic hash value, for instance, supplied during registration or credential creation based on the same input and hash function. Upon determining that the cryptographic hash values match, the corresponding security criterion may be determined to be have been satisfied by the remote computing device.”), see also ¶0191- ¶0195 for matching cryptographic hashes, (¶0307, “…In some embodiments, the request 504 also includes an encryption key such that the authentication server 155 may encrypt data for decoding only by the mobile device 101, like within the TEE of the mobile device 101, which may generate the encryption key. An encryption key may also be used to establish a secure connection, such as by HTTPS, TLS, etc., to afford secure communication of data between the mobile device 101 and the authentication server 155.”), (¶0338, “… the mobile device 101 and authentication server 155 may establish a secure session by the mobile device 101 transmitting a session key encrypted by the obtained public key to facilitate the exchange of information. The secure session may be HTTP over TLS/SSL, SSH, WebSocket over TCP, or other secure connection type by which the mobile device and authentication server 155 may exchange data, like registration information…”).
However, Avetisov in view of HALDENBY does not explicitly disclose:
generating ephemeral key pairs; and using the ephemeral key pairs to establish and conduct encrypted communications between the first mobile computing devices and a second mobile computing device.
Bhatnagar discloses generating ephemeral key pairs; and using the ephemeral key pairs to establish and conduct encrypted communications between the first mobile computing devices and a second mobile computing device (Col. 5, lines 10-60, “… In the example described above, the first device belongs to a first secure communication network and the first secure communication network and the second secure communication network are different networks. Additionally, the processor may be configured to generate a second ephemeral key pair. The second ephemeral private key is used to generate the key-encrypting key along with the first ephemeral public key. Accordingly, the processor is configured to transmit the second ephemeral public key to the first user with the first encrypted communication, the key identifier, and the encrypted first encryption key….”). see also Col. 16, lines 64-67 to Col. 17, lines 1-60.
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Avetisov and HALDENBY to include generation of ephemeral key pair for encrypted communication as disclosed by Bhatnagar and be motivated in doing so in order to provide critical security benefits such as Perfect forward secrecy which ensures that past session data remains secure if a long term private key is compromised.
Regarding claim 7, Avetisov in view of HALDENBY and further in view of Bhatnagar discloses the mobile device secure communications method according to claim 6.
Avetisov further discloses wherein the executing software instructions are further arranged to carry out the acts of: retrieving a representation of a second encoded human readable datum (EHRD) associated with second the identification number (¶0105, “… the application 110 may be a web browser configured to request data on and receive data from the server 145 for presentation on a display of the client device 135. Accordingly, the application 110 may be configured to retrieve data from the server 145 and present the data received from the server to the user. In some cases, the server 145 may redirect the application 110 to retrieve some or all data from one or more other servers, like server 155. The retrieved data, when executed or processed, may cause the application 110 to present on the display of the client device 135 a log-in page or other user interface including one or more fields or other user interface elements configured to receive user credential 111 input for accessing the online resource 147. In turn, the application 110 may transmit data corresponding to the credentials 111 input by the user, which may be a user name, password, or selection of one of more user interface elements, to a given server (e.g., at least one of server 145 or server 155) specified in the retrieved data for authentication. In some embodiments, the application 110 may transmit data corresponding to the credentials 111 without direct user input of the credentials, such as where the user has configured the application 110 to populate fields with or automatically submit stored credentials. In some embodiments, when executed or processed, the retrieved data may cause the application 110 to automatically collect or transmit other identifying data corresponding to the user or client device 135 with the credentials 111. For example, the application 110 may collect or generate identifying data about the user-client device 135 combination in the form of cookie, log, token, or other data. In addition, or alternatively, the application 110 may collect identifying data about the user-client device combination, such as by querying the runtime environment on the client device. All or a subset of the above information may be transmitted to one or more of servers 145 or 155.”, wherein user-client device information includes unique identification numbers (device IDs such as IMEI).
Claim 8 rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200280855 to Avetisov et al. (hereinafter Avetisov) in view of US. PGPub. No. 20170046792 to HALDENBY et al. (hereinafter HALDENBY) and further in view of US. PGPub.No. 20080040610 to Fergusson; Scott (hereinafter Fergusson).
Regarding claim 8, Avetisov in view of HALDENBY discloses the mobile device secure communications method according to claim 1.
However, Avetisov in view of HALDENBY does not explicitly disclose the following limitation:
wherein the executing software instructions are further arranged to carry out the acts of: displaying on a user interface verified and unverified identification numbers.
Fergusson discloses wherein the executing software instructions are further arranged to carry out the acts of: displaying on a user interface verified and unverified identification numbers (¶0003, “As a part of their Customer Identification Program obligations to collect and verify customer information, many financial institutions are required to develop procedures to collect relevant identifying information regarding each customer's name, address, date of birth, and taxpayer identification number such as Social Security Number or government-issued passport number. Verification of the customer's identifying information typically occurs with traditional documentation such as a driver's license or passport, although other alternative methods may be implemented provided the documentation meets certain threshold requirements.”), (¶0040, “…In some embodiments, for example, the graphical user interface 72 can be configured to selectively display a list of only those clients that have not been previously submitted for client identity verification with the CIP vendor 80. Alternatively, and in other embodiments, the graphical user interface 72 can be configured to selectively display only those clients whose identity has been previously verified…”).
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Avetisov and HALDENBY to include displaying both verified and unverified identification numbers on the user interface as disclosed by Fergusson and be motivated in doing so in order to offer a balanced approach that promotes transparency, user control, and operational flexibility.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights