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 .
Specification
The specification filed on November 29, 2023 is accepted.
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The following title is suggested: System and method for safely managing misuse of data of a stolen device.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/05/2026 and 03/05/2025 was filed after the mailing date of the application no. 18/565450 on 11/29/2023. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to 103
Applicant’s arguments filed on 12/19/2025 have been fully considered and are not persuasive. In response to applicants’ argument that the cited Pazhoor fails to teach the limitation” second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data” the applicant argues that Pazhoor only teaches locating the stored data using hashed key. The examiner respectfully disagrees because Pazhoor on [col 15 line 1-20] teaches requestor-linked data store 140 may store an encrypted data record 144 encrypted using public key (i.e., storing encrypted data encrypted using public key). See on [col 24 line5-60] teaches requester-linked data store storing encrypted data record. Further teaches requestor-linked data store 140 may be located on a multi-nodal secure datastore 148 or on a multi-nodal secure datastore 148 and a local database 152. Locating by access control regulator 112 may be done by determining which of multi-nodal secure datastore 148 and local database 152 is storing the requestor-linked data store 140. Locating may include referencing by access control regulator 112 a master list which includes a location of requestor-linked data store 140 and whether requestor-linked data store 140 may be located on a multi-nodal secure datastore 148, on a local database 152, or on a combination of the two (i.e., list of index indicating type of data because local database 148 and multi-nodal data store 152 store different type of data in view [col 30 line 15-27]). A master list may include a hash-table and/or distributed hash table which may be used to locate a requestor-linked data store. For example, a public key associated with a requestor containing location information pertaining to requestor-linked data store 140 may be converted into a series of hash functions. This may occur by converting an entry into a series of integers by using a hash function. A hash function may include any function that may be used to map a set of data which falls into the hash table. Hash functions may be stored in a hash table, where it can be quickly retrieved using a hashed key. The hashed key may then be used to access requestor-linked data store 140 when prompted. Using the hashed key, a hash function may compute an index that may suggest where requestor-linked data store 140 may be found. Locating may also be performed by linking the at least an encrypted data record 144 to a digital signature associated with the requestor. Requestor may produce a digital signature as described above in reference to FIG. 1, which may then be linked to the at least an encrypted data record 144 and locate to the location of the at least an encrypted data record 144 (i.e., index of encrypted data for locating the encrypted data). When the digital signature is presented, it may contain location information of the at least an encrypted data record 144 and allow access control regulator 112 to locate the precise location of encrypted data record 144. For example, digital signature may be generated using a public and/or private key linked to requestor which may contain location information of encrypted data record 144. In an embodiment, encrypted data record 144 may be linked to a requestor key, so that when a requestor key is presented, location of encrypted data record 144 becomes apparent. Locating may also be performed by information that may be contained in data access request. For example, a data access request associated with a user may contain location information of encrypted data record 144 that requestor is attempting to access. When generating a data access request, requestor may specify the location of encrypted data record 144 that may then be transmitted to access control regulator 112. Please note that the requestor linked data store 140 is implemented in data security management device [col 15 line 55-65] which also stores the public key [col 12 line 60-65]. i.e., equivalent to public key held by second computer.
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.
Claims 1-7 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Purves (US 20190222422) in view of Pazhoor et al (hereinafter Pazhoor) (US 10530577).
Regarding claim 1 Purves teaches a data management system comprising: (Purves on [0051] teaches system 100);
a first computer (Purves Fig 1 block 102 and text on [0051] teaches user device 102 i.e., first computer);
a second computer (Purves Fig 1 block 106 and text on [0051] teaches secure gateway 106 i.e., second computer);
and a third computer (Purves Fig 1 block 104 and text on [0051] teaches resource provider 104 i.e., third computer);
the second computer (Purves Fig 2 step S214 and text on [0071] teaches the secure gateway 106 may transmit the decrypted list of card aliases to the user device 102 (i.e., first computer), the decrypted list of card aliases may be displayed on the user device 102 to the user);
the first computer designates an index of data to be presented, which is an index included in the list, and transmits the designated index to the second computer (Purves Fig 2 step S216on [0072-0073] teaches the user may select one card alias (i.e., designate an index of data) of the decrypted list of card aliases, resulting in a selected card alias, the user device 102 may transmit the selected card alias to the secure gateway 106);
the second computer transmits, to the first computer, the encrypted data corresponding to the index transmitted by the first computer (Purves Fig 2 step S218-S220 and text on [0074-0075] teaches after receiving the selected card alias, the secure gateway 106 may transmit a request for access data including the selected card alias to the network computer 110, the network computer 110 may transmit encrypted access data associated with the selected alias to the user device 102);
and the first computer decrypts the encrypted data corresponding to the index based on the secret key and transmits the decrypted data to the third computer (Purves Fig 2 step S218-S220 and text on [0074-0075] teaches the network computer 110 may transmit encrypted access data associated with the selected alias to the user device 102. The user device 102 may then decrypt the encrypted access data using private key and may use it to conduct a transaction by providing it to the resource provider host site 104A or another access device operated by the resource provider).
Although Purves teaches public-private key pair for performing encryption and decryption, but fails to explicitly teach wherein the first computer generates a secret key based on biometric information on a user of the first computer, the second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data, however Pazhoor from analogous at teaches
wherein the first computer generates a secret key based on biometric information on a user of the first computer (Pazhoor on [col 9 line 10-15 and col 23 line 15-20] teaches generating biometric key from biometric data. See on [col 11 line 50-60, col 12 line 15-25 and col 12 line 50-55] teaches biometric reader generating public-private key pair from biometric feature);
the second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data (Pazhoor on [col 15 line 1-20] teaches requestor-linked data store 140 may store an encrypted data record 144 encrypted using public key. See on [col 24 line5-60] teaches a master list may include a hash-table and/or distributed hash table which may be used to locate a requestor-linked data store. For example, a public key associated with a requestor containing location information pertaining to requestor-linked data store 140 may be converted into a series of hash functions. This may occur by converting an entry into a series of integers by using a hash function. A hash function may include any function that may be used to map a set of data which falls into the hash table. Hash functions may be stored in a hash table, where it can be quickly retrieved using a hashed key. The hashed key may then be used to access requestor-linked data store 140 when prompted. Using the hashed key, a hash function may compute an index that may suggest where requestor-linked data store 140 may be found).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by generating biometric key and locating encrypted information based on index from list of indexes. One would be motivated to do so in order to locate requested data based on index information and authenticate the requested data based on biometric key in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 2 the combination of Purves and Pazhoor teaches all the limitations of claims 1 above, Pazhoor further teaches wherein the second computer holds the public key, the first computer uses the secret key and the second computer uses the public key, thereby performing authentication between the first computer and the second computer, and when the authentication is successfully performed, the second computer transmits the list to the first computer (Pazhoor on [col 25 line 35-65] teaches matching may also include evaluating a digital signature of requestor with a requestor public and utilizing the public key to evaluate encrypted data record 144. For example, access control regulator 112 may receive a data access request which includes a digital signature from requestor and a requestor public key. Access control regulator 112 may use requestor public key to evaluate requestor digital signature, and then use requestor public key to evaluate encrypted data record 144. Matching may include ensuring that requestor public key validates and/or verifies both requestor digital signature and encrypted data record 144; i.e., determining that decryption of each digital signature with public key produces the purportedly signed data or a representation thereof as represented by each digital signature. Matching may also be performed through the use of a requestor private key which may be transmitted in a data access request. For example, requestor may transmit to access control regulator 112 requestor private key with the data access request. Matching may include checking that the private key generates the same digital signature that may be stored in a database i.e., mutual authentication between entities-based signature verification using public-private key pair).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by performing mutual authentication based on signature verification using public-private key pair. One would be motivated to do so in order to locate requested data based on index and authenticate the requested data based on mutual authentication using public-private key pair in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 3 the combination of Purves and Pazhoor teaches all the limitations of claims 1 above, Pazhoor further teaches wherein the third computer holds the public key, the first computer holds provision consent information on the data, attaches an electronic signature to the provision consent information using the secret key, and transmits, to the third computer, the provision consent information to which the electronic signature is attached, and the third computer verifies the electronic signature using the public key (Pazhoor on [col 25 line 35-65 and col 28 line 50-65] teaches Matching may also include evaluating a digital signature of requestor with a requestor public key and utilizing the public key to evaluate encrypted data record 144. For example, access control regulator 112 may receive a data access request which includes a digital signature from requestor and a requestor public key. Access control regulator 112 may use requestor public key to evaluate requestor digital signature, and then use requestor public key to evaluate encrypted data record 144. Matching may include ensuring that requestor public key validates and/or verifies both requestor digital signature and encrypted data record 144; i.e., determining that decryption of each digital signature with public key produces the purportedly signed data or a representation thereof as represented by each digital signature. Matching may also be performed through the use of a requestor private key which may be transmitted in a data access request. For example, requestor may transmit to access control regulator 112 requestor private key with the data access request. Matching may include checking that the private key generates the same digital signature that may be stored in a database).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by performing mutual authentication based on signature verification using public-private key pair. One would be motivated to do so in order to locate requested data based on index and authenticate the requested data based on mutual authentication using public-private key pair in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 4 the combination of Purves and Pazhoor teaches all the limitations of claims 1 above, Purves further teaches a fourth computer (Purves on [0081] teaches the authorizing entity computer 112);
the fourth computer holds original data before encryption of the encrypted data, and transmits the original data to the first computer (Purves on [0081] teaches the authorizing entity computer 112 may transmit data relating to the card and information regarding the user to the network computer 110, after receiving the data relating to the card and the information regarding the user, network computer 110 or the blockchain 108 may encrypt at least some of the user and card data using a public key associated with the user device 102);
wherein the first computer generates a symmetric key based on the biometric information (Pazhoor on [col 9 line 10-15 and col 23 line 15-20] teaches generating biometric key from biometric data. See on [col 11 line 50-60, col 12 line 15-25 and col 12 line 50-55] teaches biometric reader encrypted private key generated from biometric feature);
and the encrypted data held by the second computer is data obtained by the first computer encrypting the original data based on the symmetric key and transmitting the encrypted original data to the second computer (Pazhoor on [col 11 line 25-30] teaches public key and private key may include two uniquely related cryptographic keys that may function to encode information. Both keys may work in either symmetric and asymmetric encryption systems. Symmetric encryption may utilize the same key for encryption and decryption).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by generating biometric key and locating encrypted information based on index from list of indexes. One would be motivated to do so in order to locate requested data based on index information and authenticate the requested data based on biometric key in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 5 the combination of Purves and Pazhoor teaches all the limitations of claims 4 above, Purves further teaches wherein the first computer includes a biometric information acquiring device and is connected to a display device (Purves on [0071] teaches user device with display. See on [0104] teaches user may be prompted to input a biometric sample (i.e., the first device having biometric acquiring unit). The user device 102 may convert the biometric sample into a biometric template and compare the biometric template with a previously stored biometric template);
and the first computer displays information indicating a modality of the biometric information on the display device (Purves on [0063] teaches the user device may receive the verification request message and may display the contents of the verification request message to the user of the user device 102.,The verification request message may contain information for the user to input into the user device. See on [0104] For example, the user may be prompted to input a biometric sample. The user device 102 may convert the biometric sample into a biometric template and compare the biometric template with a previously stored biometric template. Similarly, the user may be prompted to input a PIN, password, etc.);
transmits the decrypted verifiable credential to the third computer, and displays the decrypted data and the decrypted verifiable credential on the display device (Purves on [0071] teaches the decrypted list of card aliases may be displayed on the user device 102 to the user. For example, the list of card aliases may be presented to the user via a user interface on a display of the user device 102. See on [0090] teaches After a card alias has been selected, the digital card facilitator 410 may display information associated with the selected card alias as well as other relevant information, such as the initial identifier (e.g., the email address), the user's name, and the user's address. See on [0102] teaches the user device 102 may display the list of payment accounts).
Pazhoor teaches the encrypted data held by the second computer includes an encrypted verifiable credential obtained by the fourth computer encrypting a verifiable credential based on the public key (Pazhoor on [col 11 line 35-45] teaches a public key may be made available to everyone via a publicly accessible repository or directory. A public key may use asymmetric algorithms to convert data such as a message into an unreadable format. An individual who has a public key may encrypt the data intended for a specific receiver. The receiver with the private key can only decode the data which may be encrypted by the public key. A private key may be kept confidential to its respective owner, who may include, without limitation, a requestor as further described herein. A private key may include a secret key that may be used to decrypt the data. In an embodiment, a public and private key pair may be mathematically related, so that whatever is encrypted with a public key may only be decrypted by its corresponding private keys. See on [col 15 line 1-10] teaches requestor may use a public biometric key to encrypt information contained in requestor-linked data store 140 and requestor may use a private biometric key to decrypt information contained in requestor-linked data store 140 and/or to gain access to requestor-linked data store);
acquires biometric information via the biometric information acquiring device, generates the secret key based on the acquired biometric information (Pazhoor on [col 9 line 10-15 and col 23 line 15-20] teaches generating biometric key from biometric data. See on [col 11 line 50-60, col 12 line 15-25 and col 12 line 50-55] teaches biometric reader encrypted private key generated from biometric feature);
decrypts the encrypted verifiable credential included in the encrypted data corresponding to the index based on the secret key (Pazhoor on [col 11 line 35-45 and col 13 line 1-10] teaches a public key may be made available to everyone via a publicly accessible repository or directory. A public key may use asymmetric algorithms to convert data such as a message into an unreadable format. An individual who has a public key may encrypt the data intended for a specific receiver. The receiver with the private key can only decode the data which may be encrypted by the public key. A private key may be kept confidential to its respective owner, who may include, without limitation, a requestor as further described herein. A private key may include a secret key that may be used to decrypt the data. In an embodiment, a public and private key pair may be mathematically related, so that whatever is encrypted with a public key may only be decrypted by its corresponding private keys. See on [col 15 line 1-10] teaches requestor may use a public biometric key to encrypt information contained in requestor-linked data store 140 and requestor may use a private biometric key to decrypt information contained in requestor-linked data store 140 and/or to gain access to requestor-linked data store).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by generating biometric key and locating encrypted information based on index from list of indexes. One would be motivated to do so in order to locate requested data based on index information and authenticate the requested data based on biometric key in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 6 the combination of Purves and Pazhoor teaches all the limitations of claims 1 above, Purves further teaches a fourth computer (Purves on [0081] teaches the authorizing entity computer 112);
wherein the fourth computer holds original data before encryption of the encrypted data, and the public key (Purves on [0081] teaches the authorizing entity computer 112 may transmit data relating to the card and information regarding the user to the network computer 110, after receiving the data relating to the card and the information regarding the user, network computer 110 or the blockchain 108 may encrypt at least some of the user and card data using a public key associated with the user device 102);
and the encrypted data held by the second computer is data obtained by the fourth computer encrypting the original data based on the public key and transmitting the encrypted original data to the second computer (Purves on [0081] teaches the authorizing entity computer 112 may transmit data relating to the card and information regarding the user to the network computer 110, after receiving the data relating to the card and the information regarding the user, network computer 110 or the blockchain 108 may encrypt at least some of the user and card data using a public key associated with the user device 102).
Regarding claim 7 the combination of Purves and Pazhoor teaches all the limitations of claims 6 above, Purves further teaches wherein the first computer includes a biometric information acquiring device and is connected to a display device (Purves on [0071] teaches user device with display. See on [0104] teaches user may be prompted to input a biometric sample (i.e., the first device having biometric acquiring unit). The user device 102 may convert the biometric sample into a biometric template and compare the biometric template with a previously stored biometric template);
and the first computer displays information indicating a modality of the biometric information on the display device (Purves on [0063] teaches the user device may receive the verification request message and may display the contents of the verification request message to the user of the user device 102.,The verification request message may contain information for the user to input into the user device. See on [0104] For example, the user may be prompted to input a biometric sample. The user device 102 may convert the biometric sample into a biometric template and compare the biometric template with a previously stored biometric template. Similarly, the user may be prompted to input a PIN, password, etc.).
Pazhoor teaches the encrypted data held by the second computer includes an encrypted verifiable credential obtained by the fourth computer encrypting a verifiable credential based on the public key (Pazhoor on [col 11 line 35-45] teaches a public key may be made available to everyone via a publicly accessible repository or directory. A public key may use asymmetric algorithms to convert data such as a message into an unreadable format. An individual who has a public key may encrypt the data intended for a specific receiver. The receiver with the private key can only decode the data which may be encrypted by the public key. A private key may be kept confidential to its respective owner, who may include, without limitation, a requestor as further described herein. A private key may include a secret key that may be used to decrypt the data. In an embodiment, a public and private key pair may be mathematically related, so that whatever is encrypted with a public key may only be decrypted by its corresponding private keys. See on [col 15 line 1-10] teaches requestor may use a public biometric key to encrypt information contained in requestor-linked data store 140 and requestor may use a private biometric key to decrypt information contained in requestor-linked data store 140 and/or to gain access to requestor-linked data store);
acquires biometric information via the biometric information acquiring device, generates the secret key based on the acquired biometric information (Pazhoor on [col 9 line 10-15 and col 23 line 15-20] teaches generating biometric key from biometric data. See on [col 11 line 50-60, col 12 line 15-25 and col 12 line 50-55] teaches biometric reader encrypted private key generated from biometric feature);
decrypts the encrypted verifiable credential included in the encrypted data corresponding to the index based on the secret key (Pazhoor on [col 11 line 35-45 and col 13 line 1-10] teaches a public key may be made available to everyone via a publicly accessible repository or directory. A public key may use asymmetric algorithms to convert data such as a message into an unreadable format. An individual who has a public key may encrypt the data intended for a specific receiver. The receiver with the private key can only decode the data which may be encrypted by the public key. A private key may be kept confidential to its respective owner, who may include, without limitation, a requestor as further described herein. A private key may include a secret key that may be used to decrypt the data. In an embodiment, a public and private key pair may be mathematically related, so that whatever is encrypted with a public key may only be decrypted by its corresponding private keys. See on [col 15 line 1-10] teaches requestor may use a public biometric key to encrypt information contained in requestor-linked data store 140 and requestor may use a private biometric key to decrypt information contained in requestor-linked data store 140 and/or to gain access to requestor-linked data store).
transmits the decrypted verifiable credential to the third computer, and displays the decrypted data and the decrypted verifiable credential on the display device (Purves on [0071] teaches the decrypted list of card aliases may be displayed on the user device 102 to the user. For example, the list of card aliases may be presented to the user via a user interface on a display of the user device 102. See on [0090] teaches After a card alias has been selected, the digital card facilitator 410 may display information associated with the selected card alias as well as other relevant information, such as the initial identifier (e.g., the email address), the user's name, and the user's address. See on [0102] teaches the user device 102 may display the list of payment accounts).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by generating biometric key and locating encrypted information based on index from list of indexes. One would be motivated to do so in order to locate requested data based on index information and authenticate the requested data based on biometric key in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 10 Purves teaches a data management method performed by a data management system including a first computer, a second computer, and a third computer, the data management method comprising: (Purves on [0008-0010 and 0051] teaches method for data management comprising user device 102 i.e., first computer, secure gateway 106 i.e., second computer and resource provider 104 i.e., third computer);
the second computer (Purves Fig 2 step S214 and text on [0071] teaches the secure gateway 106 may transmit the decrypted list of card aliases to the user device 102 (i.e., first computer), the decrypted list of card aliases may be displayed on the user device 102 to the user);
the first computer designates an index of data to be presented, which is an index included in the list, and transmits the designated index to the second computer (Purves Fig 2 step S216on [0072-0073] teaches the user may select one card alias (i.e., designate an index of data) of the decrypted list of card aliases, resulting in a selected card alias, the user device 102 may transmit the selected card alias to the secure gateway 106);
the second computer transmits, to the first computer, the encrypted data corresponding to the index transmitted by the first computer (Purves Fig 2 step S218-S220 and text on [0074-0075] teaches after receiving the selected card alias, the secure gateway 106 may transmit a request for access data including the selected card alias to the network computer 110, the network computer 110 may transmit encrypted access data associated with the selected alias to the user device 102);
and the first computer decrypts the encrypted data corresponding to the index based on the secret key and transmits the decrypted data to the third computer (Purves Fig 2 step S218-S220 and text on [0074-0075] teaches the network computer 110 may transmit encrypted access data associated with the selected alias to the user device 102. The user device 102 may then decrypt the encrypted access data using private key and may use it to conduct a transaction by providing it to the resource provider host site 104A or another access device operated by the resource provider).
Although Purves teaches public-private key pair for performing encryption and decryption, but fails to explicitly teach wherein the first computer generates a secret key based on biometric information on a user of the first computer, the second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data, however Pazhoor from analogous at teaches
wherein the first computer generates a secret key based on biometric information on a user of the first computer (Pazhoor on [col 9 line 10-15 and col 23 line 15-20] teaches generating biometric key from biometric data. See on [col 11 line 50-60, col 12 line 15-25 and col 12 line 50-55] teaches biometric reader generating public-private key pair from biometric feature);
the second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data (Pazhoor on [col 15 line 1-20] teaches requestor-linked data store 140 may store an encrypted data record 144 encrypted using public key. See on [col 24 line5-60] teaches a master list may include a hash-table and/or distributed hash table which may be used to locate a requestor-linked data store. For example, a public key associated with a requestor containing location information pertaining to requestor-linked data store 140 may be converted into a series of hash functions. This may occur by converting an entry into a series of integers by using a hash function. A hash function may include any function that may be used to map a set of data which falls into the hash table. Hash functions may be stored in a hash table, where it can be quickly retrieved using a hashed key. The hashed key may then be used to access requestor-linked data store 140 when prompted. Using the hashed key, a hash function may compute an index that may suggest where requestor-linked data store 140 may be found).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by generating biometric key and locating encrypted information based on index from list of indexes. One would be motivated to do so in order to locate requested data based on index information and authenticate the requested data based on biometric key in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Regarding claim 11 Purves teaches a computer-readable non-transitory recording medium for storing a data management program configured to cause a data management system including a first computer, a second computer, and a third computer to perform data management (Purves on [0008-0010 and 0051] teaches method for data management comprising user device 102 i.e., first computer, secure gateway 106 i.e., second computer and resource provider 104 i.e., third computer. See on [0038] teaches non-transitory computer readable medium storing instructions executed by processor);
and the data management program causes following processing to be executed: processing by the second computer of transmitting the list to the first computer (Purves Fig 2 step S214 and text on [0071] teaches the secure gateway 106 may transmit the decrypted list of card aliases to the user device 102 (i.e., first computer), the decrypted list of card aliases may be displayed on the user device 102 to the user);
processing by the first computer of designating an index of data to be presented, which is an index included in the list, and transmitting the designated index to the second computer (Purves Fig 2 step S216on [0072-0073] teaches the user may select one card alias (i.e., designate an index of data) of the decrypted list of card aliases, resulting in a selected card alias, the user device 102 may transmit the selected card alias to the secure gateway 106);
processing by the second computer of transmitting, to the first computer, the encrypted data corresponding to the index transmitted by the first computer (Purves Fig 2 step S218-S220 and text on [0074-0075] teaches after receiving the selected card alias, the secure gateway 106 may transmit a request for access data including the selected card alias to the network computer 110, the network computer 110 may transmit encrypted access data associated with the selected alias to the user device 102);
and processing by the first computer of decrypting the encrypted data corresponding to the index based on the secret key and transmitting the decrypted data to the third computer (Purves Fig 2 step S218-S220 and text on [0074-0075] teaches the network computer 110 may transmit encrypted access data associated with the selected alias to the user device 102. The user device 102 may then decrypt the encrypted access data using private key and may use it to conduct a transaction by providing it to the resource provider host site 104A or another access device operated by the resource provider).
Although Purves teaches public-private key pair for performing encryption and decryption, but fails to explicitly teach wherein the first computer generates a secret key based on biometric information on a user of the first computer, the second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data, however Pazhoor from analogous at teaches wherein the data management program causes the first computer to perform processing of generating a secret key based on biometric information of a user of the first computer (Pazhoor on [col 9 line 10-15 and col 23 line 15-20] teaches generating biometric key from biometric data. See on [col 11 line 50-60, col 12 line 15-25 and col 12 line 50-55] teaches biometric reader generating public-private key pair from biometric feature);
the second computer holds a public key corresponding to the secret key, encrypted data as data encrypted based on the public key, a list of indexes indicating a type of the data, and an index of the encrypted data (Pazhoor on [col 15 line 1-20] teaches requestor-linked data store 140 may store an encrypted data record 144 encrypted using public key. See on [col 24 line5-60] teaches a master list may include a hash-table and/or distributed hash table which may be used to locate a requestor-linked data store. For example, a public key associated with a requestor containing location information pertaining to requestor-linked data store 140 may be converted into a series of hash functions. This may occur by converting an entry into a series of integers by using a hash function. A hash function may include any function that may be used to map a set of data which falls into the hash table. Hash functions may be stored in a hash table, where it can be quickly retrieved using a hashed key. The hashed key may then be used to access requestor-linked data store 140 when prompted. Using the hashed key, a hash function may compute an index that may suggest where requestor-linked data store 140 may be found).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Pazhoor into the teaching of Purves by generating biometric key and locating encrypted information based on index from list of indexes. One would be motivated to do so in order to locate requested data based on index information and authenticate the requested data based on biometric key in order to determine that the requestor is authorized to access the requested data (Pazhoor [col 1 line 36-65]).
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Purves (US 20190222422) in view of Pazhoor et al (hereinafter Pazhoor) (US 10530577) and further in view HAGA et al (hereinafter HAGA) (US 20170134164).
Regarding claim 8 the combination of Purves and Pazhoor teaches all the limitations of claims 6 above, the combination fails to explicitly teach wherein the second computer holds a public key certificate including the public key, and transmits the public key certificate to the first computer, the public key held by the fourth computer is a public key included in the public key certificate transmitted to the fourth computer by the first computer, and the first computer uses the secret key, and the fourth computer uses the public key certificate, thereby performing authentication between the first computer and the fourth computer, however HAGA from analogous art teaches
wherein the second computer holds a public key certificate including the public key, and transmits the public key certificate to the first computer, the public key held by the fourth computer is a public key included in the public key certificate transmitted to the fourth computer by the first computer, and the first computer uses the secret key, and the fourth computer uses the public key certificate, thereby performing authentication between the first computer and the fourth computer (HAGA on [0071 and 0122] teaches the secret key and public key certificate are used for authentication between the master ECU 100 and external tools 30a and 30b. The shared key 60 representatively represents individual shared keys. This shared key 60 is an AES (Advanced Encryption Standard) key in shared-key cryptography, that is shared between the master ECU 100 and the ECUs, and is used for transmitting session keys for encryption processing regarding frames).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of HAGA into the combined teaching of Purves and Pazhoor by performing mutual authentication using public key certificate and secret key. One would be motivated to do so in order to prevent unauthorized access of the data by performing mutual authentication between devices using public key certificate of first device and secret key of second device (HAGA [0004-0005]).
Regarding claim 9 combination of Purves, Pazhoor and HAGA teaches all the limitations of claims 8 above, HAGA further teaches wherein the first computer uses the secret key, and the second computer uses the public key certificate, thereby performing authentication between the first computer and the second computer, and when the authentication is successfully performed, the second computer transmits the public key certificate to the first computer (HAGA on [0071 and 0122] teaches the secret key and public key certificate are used for authentication between the master ECU 100 and external tools 30a and 30b. The shared key 60 representatively represents individual shared keys. This shared key 60 is an AES (Advanced Encryption Standard) key in shared-key cryptography, that is shared between the master ECU 100 and the ECUs, and is used for transmitting session keys for encryption processing regarding frames).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of HAGA into the combined teaching of Purves and Pazhoor by performing mutual authentication using public key certificate and secret key. One would be motivated to do so in order to prevent unauthorized access of the data by performing mutual authentication between devices using public key certificate of first device and secret key of second device (HAGA [0004-0005]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436