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 is responsive to RCE filed on 2/3/26. Claims 1-17 are pending.
Continued Examination Under 37 CFR 1.114
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 filed on 2/3/26 has been entered.
Response to Amendment
Claims 1, 5-6, 12 and 15 are amended. Claims 1-17 are 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.
Claim(s) 1-10, 12 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Edison (US 2017/0249481 A1), in view of Chen (US 2018/0191688 A1).
As to claim 1, Edison discloses a system for protecting the privacy of personal data (Edison, ¶ 0023, fig. 2A), the system comprising:
a private zone implemented on one or more first storage devices in communication with the one or more processors (the system 100 includes one or more data contributor computing environments 102 (private zone), which each include a data storage 104 (one or more first storage devices) and a processor 106 that is in communication with the data storage 104) (Edison, ¶ 0023-0030, figs. 1& 2A), the one or more storage devices having stored thereon a plurality of personal data files comprising records of raw data and a set of instructions that, when executed by the one or more processors, cause the one or more processors to identify specific data items within the set of raw data (data storage 104 that houses clear text data (raw data) such as healthcare claims and clinical data (personal data files) that are each partially made up of personal information; processor 106 that is in communication with the data storage 104 configured to sanitize or cleanse and hash the personal information (identify specific data items); ) (Edison, ¶ 0006, 0023-0032, fig. 2A);
a translation zone implemented on one or more second storage devices in communication the one or more processors (the cleansed, hashed personal information and associated clear text non-personal information is communicated to a secure facility computing environment 108 (translation zone);) (Edison, ¶ 0023-0024, fig. 2A), the translation zone comprising a personal data key map comprising a mapping between each of the specific data items and a corresponding personal data key for each of the specific data items, and a set of instructions that (each unique ID (personal data key) is associated with (mapping) data representative of a specific individual (specific data items); the same unique ID is also associated with the clear text data, e.g., within the de-identified claims and clinical storages 116, 118, to which it relates by the secure facility computing environment 108 (processors)) (Edison, ¶ 0023-0025, 0045-0051, figs. 5-6), when executed by the one or more processors, cause the one or more processors to replace each of the specific data items with the corresponding personal data key and the personal data key corresponding to the original specific data item (personal information (specific data item) includes social security number "SSN", first name, last name, and address, contributor IDs, Medicare ID, Medicaid recipient number, and Medicaid family number, and each data contributor computing environment 102 sanitizes the personal information clear text using specific rules/logic (generate); table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2);
a general zone implemented on one or more third storage devices, wherein the general zone comprises a set of parsed records wherein the specific data items within the records of raw data are replaced by the corresponding personal data keys ((the cleansed data (set of parsed records) is loaded into and stored within respective storage or databases, such as healthcare claims data and clinical data may be stored within a de-identified claims storage 112 and a de-identified clinical storage 114 (third storage devices) of an extract, transform, and load "ETL" zone 116 (general zone) of the secure facility computing environment 108, where the cleansed data is associated with a unique ID (personal data key) associated with a recently stored personal information value (specific data item)) (Edison, ¶ 0023-00320, figs. 1& 2A, 6); and a personal data key creation subroutine configured to execute on the one or more processors (each data contributor computing environment 102 also includes a processor 106 that is in communication with the data storage 104 and that is configured to sanitize or cleanse and hash (personal data key creation subroutine) the personal information (specific data item)) (Edison, ¶ 0023-0032, figs. 1& 2A, 6) to cause the one or more processors to:
receive a specific data item (data contributor computing environment 102 standardizes/sanitizes clear text of personal information (specific
data item)) (Edison, ¶ 0023-0032, figs. 1& 2A-B, 6);
generate a universal unique identifier (UUID) corresponding to the specific data item, (personal information (specific data item) includes social security number "SSN", first name, last name, and address, contributor IDs, Medicare ID, Medicaid recipient number, and Medicaid family number, and each data contributor computing environment 102 sanitizes the personal information clear text using specific rules/logic (generate); table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2), wherein the UUID is generated independently of content of the specific data item (see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2); generate either a random or pseudo-random salt (the standardized/sanitized text is salted using a "common salt" where "Salting" is a cryptography concept that involves providing (generate) additional data, such as a common random number (random salt); see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3)); concatenate the UUID with the salt to produce a salted UUID (the concatenation of the salt and sanitized clear text (unique identifier) of the personal information becomes the message digest (salted unique identifier;) see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-2)); and hash the salted UUID to produce the personal data key (the message digest (salted unique identifier) is input to and hashed using a hashing algorithm and the hashed data values, are concatenated for each record/file to generate a unique ID (personal data key), where a unique ID is generated and associated with the stored hashed personal information; see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-2).
However Edison, does not explicitly disclose generate a universal unique identifier (UUID) as an intermediate identifier corresponding to the specific data item, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation; concatenate the UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step; and hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the original specific data item.
In an analogous art, Chen discloses generate a universal unique identifier (UUID) as an intermediate identifier corresponding to the specific data item (the password can be concatenated with a first salt to generate a first salted password (i.e. intermediate identifier)) (Chen, ¶0032, 0037, figs 2-3), wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation ( password processing module 104 can be configured to process the password information for secure transmission by salting and hashing the password multiple times. For example, the password can be concatenated with a first salt to generate a first salted password) (Chen, ¶0032, 0037, figs 2-3); generate either a random or pseudo-random salt (The first salted password (e.g., the concatenation of the password and the first salt) can be passed through a hashing algorithm to generate a first password hash) (Chen, 0032, 0037, figs 2-3);
concatenate the UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step (The first password hash can be concatenated with a second salt to generate a second salted password (i.e. salted UUID)) (Chen, 0032, 0037, figs 2-3); and hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the original specific data item ( The first password hash can be concatenated with a second salt to generate a second salted password) (Chen, 0032, 0037, figs 2-3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Chen teachings into Edison’s teaching of generate a universal unique identifier (UUID) as an intermediate identifier corresponding to the specific data item, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation; concatenate the UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step; and hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the original specific data item. This combination effectively provides secure transmission by salting and hashing the password multiple times.
As to claim 2, Edison-Chen discloses the system of claim 1, discloses wherein the private zone comprises a private zone security protocol configured to provide access only to persons with a need to know (The secure facility computing environment 108 also includes a virtual private network (VPN) 132 that is configured to restrict researcher computer 122 access to certain certified views. The structure of the VPN 132 and its interaction with the data access zone 128 and researcher computers 122 is described in further detail below with respect to FIG. 7.) (Edison, ¶ 0032-0033).
As to claim 3, Edison-Chen discloses the system of claim 2, discloses wherein the translation zone comprises a translation zone security protocol configured to provide access only to designated persons (The secure facility computing environment 108 also includes a virtual private network (VPN) 132 that is configured to restrict researcher computer 122 access to certain certified views. The structure of the VPN 132 and its interaction with the data access zone 128 and researcher computers 122 is described in further detail below with respect to FIG. 7.) (Edison, ¶ 0032-0033).
As to claim 4, Edison-Chen discloses the system of claim 3, Edison wherein the general zone comprises a general zone security protocol configured to allow access to developers (a researcher (developer), via a computing device 122, accesses certified views for which the researcher has been granted access (allow access), where the VPN 132 (general zone security protocol) accesses certified views from the certified view storage 130 of the data access zone 128 (general zone) and places them in a sandbox 702;) (Edison, ¶ 0045-0046, 0052, figs. 1 & 7).
As to claim 5, Edison disclose a system for personal data protection (Edison, ¶ 0023, fig. 2A), the system comprising:
one or more processors (Edison, ¶ 0023, fig. 1);
one or more storage devices in communication with the one or more processors (Edison, ¶ 0023, fig. 1), wherein the storage devices comprise a set of instructions that, when executed by the one or more processors, cause the one or more processors to:
receive, from at least one data controller, a plurality of data records (each data contributor computing environment 102 (data controller) includes data storage 104 that houses (receive) clear text data such as healthcare claims and clinical data (a plurality of data records) that are each partially made up of personal information) (Edison, ¶ 0023-0032, fig. 1);
identify specific data items in the set of data records (data contributor computing environment 102 standardizes/sanitizes (identify) clear text (plurality of data records) of personal information (specific data items); figures 2A-B,) (Edison, ¶ 0023-0032, figs. 2A-B);
create a personal data key for each of the specific data items by generating a universal unique identifier (UUID) corresponding to each of the specific data items personal information (specific data item) includes social security number "SSN", first name, last name, and address, contributor IDs, Medicare ID, Medicaid recipient number, and Medicaid family number, and each data contributor computing environment 102 sanitizes the personal information clear text using specific rules/logic (generate); table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2), wherein the UUID is generated independently of content of the specific data item (see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2), generating either a random or pseudo-random salt for each UUID (the standardized/sanitized text is salted using a "common salt" where "Salting" is a cryptography concept that involves providing (generating) additional data, such as a common random number (random salt) see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-2), concatenating each UUID with the salt to produce a salted UUID (the concatenation of the salt and sanitized clear text (unique identifier) of the personal information becomes the message digest (salted unique identifier) see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3), and hashing each salted UUID to produce the personal data key corresponding to each of the specific data items (the message digest (salted unique identifier) is input to and hashed using a hashing algorithm and the hashed data values, are concatenated for each record/file to generate (produce) a unique ID, where a unique ID is generated and associated with the stored hashed personal information (original specific data item); see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3)); store the specific data items, a set of corresponding personal data keys, and a set of associated metadata in a personal data key map within a restricted access zone on the one or more storage devices (prior to the hashed data being stored, it may be processed to change encounter IDs, provider IDs, and facility IDs (set of associated metadata) into sequential alternate IDs and once the hashed values (specific data items) are stored in the identity vault (restricted access zone), matching and linking of the data involves the use of unique IDs where each unique ID (personal data key) is associated with (mapping) stored hashed personal information of an individual within the identity vault) (Edison, ¶ 0027, 0045-0051); and
replace the specific data items with the corresponding personal data keys to create a set of parsed records comprising the personal data keys see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3).
However Edison, does not explicitly disclose create a personal data key for each of the specific data items by generating a universal unique identifier (UUID) as an intermediate identifier corresponding to each of the specific data items, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation; concatenating each UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step;
In an analogous art, Chen discloses create a personal data key for each of the specific data items by generating a universal unique identifier (UUID) as an intermediate identifier corresponding to each of the specific data items (the password can be concatenated with a first salt to generate a first salted password (i.e. intermediate identifier)) (Chen, ¶0032, 0037, figs 2-3), wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation ( password processing module 104 can be configured to process the password information for secure transmission by salting and hashing the password multiple times. For example, the password can be concatenated with a first salt to generate a first salted password) (Chen, ¶0032, 0037, figs 2-3); generate either a random or pseudo-random salt (The first salted password (e.g., the concatenation of the password and the first salt) can be passed through a hashing algorithm to generate a first password hash) (Chen, 0032, 0037, figs 2-3);
concatenating each UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step (The first password hash can be concatenated with a second salt to generate a second salted password (i.e. salted UUID)) (Chen, 0032, 0037, figs 2-3); and hashing each salted UUID to produce the personal data key corresponding to each of the specific data items ( The first password hash can be concatenated with a second salt to generate a second salted password) (Chen, 0032, 0037, figs 2-3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Chen teachings into Edison’s teaching of create a personal data key for each of the specific data items by generating a universal unique identifier (UUID) as an intermediate identifier corresponding to each of the specific data items, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation; concatenating each UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step. This combination effectively provides secure transmission by salting and hashing the password multiple times.
Claim 6 list all the same elements of claim 5, but in a personal data workflow method (Edison, ¶ 0023, fig. 1) to carry out method steps of the system form. Therefore, the supporting rationale of the rejection to claim 5 applies equally as well to claim 6.
As to claim 7, Edison discloses the method of claim 6, Edison disclose further comprising the step of reading the set of parsed Edison-Park records and transferring at least one of the parsed records in the set of parsed records to a personal data transformation service (the cleansed data (set of parsed records) is loaded into (transferring) and stored within respective storage or databases of an extract, transform, and load "ETL" zone 116 (personal data transformation service) of the secure facility computing environment 108;) (Edison, ¶ 0025-0028).
As to claim 8, Edison discloses the method of claim 7, Edison disclose wherein the personal data transformation service replaces personal data in the at least one parsed record (prior to the cleansed data being stored in storage databases it may be processed to change (replace) encounter IDs, provider IDs, and facility IDs (personal data), provided by the data contributor computing environments 102, into sequential alternate IDs) (Edison, ¶0025-0028).
As to claim 9, Edison discloses the method of claim 7, Edison disclose further comprising the step of performing a second hash using a second hash key that is specific to a destination platform (once the hashed values are communicated to and received by the secure facility computing environment 108, the hashed values are salted using a "private salt" (second hash key) and the salted values are salted a second time, where the private salt refers to a salt maintained within and used solely (specific to) by the secure facility computing environment 108 (destination platform)) (Edison, ¶ 0040-0041).
As to claim 10, Edison discloses the method of claim 9, Edison disclose further comprising the step of sending the parsed record to the destination platform corresponding to the second hash key (private salt (second hash key) is maintained within and used solely by (corresponding) the secure facility computing environment 108 (destination platform), and the cleansed data (parsed record) is loaded into (sending) and stored within a de-identified claims storage 112 and a de-identified clinical storage 114 of an extract, transform, and load "ETL" zone 116 of the secure facility computing environment 108) (Edison, ¶ 0040-0041, fig. 1).
As to claim 12, Edison discloses a method for producing a personal data key corresponding to a specific data item (methods for storage, processing, and transmission of sensitive, such as personal/private, information) (Edison, ¶ 0005, 0023), the method comprising the steps of:
receiving one of the specific data items at a processor (each data contributor computing environment 102 (data controller) includes data storage 104 that houses (receive) clear text data such as healthcare claims and clinical data (a plurality of data records) that are each partially made up of personal information) (Edison, ¶ 0023-0032, fig. 1);
generating a universally unique identifier (UUID) corresponding to the specific data item (personal information (specific data item) includes social security number "SSN", first name, last name, and address, contributor IDs, Medicare ID, Medicaid recipient number, and Medicaid family number, and each data contributor computing environment 102 sanitizes the personal information clear text using specific rules/logic (generate); table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2);
wherein the UUID is generated independently of content of the specific data item (see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2);
generating at the processor either a random or pseudo-random salt (the standardized/sanitized text is salted using a "common salt" where "Salting" is a cryptography concept that involves providing (generating) additional data, such as a common random number (random salt)) (Edison, ¶ 0025-0037, fig. 1);
concatenating the UUID with the salt at the processor to produce a salted UUID (the concatenation of the salt and sanitized clear text (unique identifier) of the personal information becomes the message digest (salted unique identifier) (the concatenation of the salt and sanitized clear text (unique identifier) of the personal information becomes the message digest (salted unique identifier;) see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-2)); and
hashing at the processor to hash the salted UUID to produce the personal data key corresponding to the specific data item (the message digest (salted unique identifier) is input to and hashed using a hashing algorithm and the hashed data values, are concatenated for each record/file to generate (produce) a unique ID (personal data key), where a unique ID is generated and associated with the stored hashed persona! information (original specific data item); Tables 1, 2 (the message digest (salted unique identifier) is input to and hashed using a hashing algorithm and the hashed data values, are concatenated for each record/file to generate (produce) a unique ID, where a unique ID is generated and associated with the stored hashed personal information (original specific data item); see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3)).
However Edison, does not explicitly disclose generating a universally unique identifier (UUID) as an intermediate identifier corresponding to the specific data item, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation;
concatenating the UUID with the salt at the processor to produce a salted UUID, wherein the salted UUID serves as input to a hashing step; and hashing at the processor to hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the specific data item.
In an analogous art, Chen discloses generating a universally unique identifier (UUID) as an intermediate identifier corresponding to the specific data item (the password can be concatenated with a first salt to generate a first salted password (i.e. intermediate identifier)) (Chen, ¶0032, 0037, figs 2-3), wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation ( password processing module 104 can be configured to process the password information for secure transmission by salting and hashing the password multiple times. For example, the password can be concatenated with a first salt to generate a first salted password) (Chen, ¶0032, 0037, figs 2-3); generating at the processor either a random or pseudo-random salt (The first salted password (e.g., the concatenation of the password and the first salt) can be passed through a hashing algorithm to generate a first password hash) (Chen, 0032, 0037, figs 2-3); concatenating the UUID with the salt at the processor to produce a salted UUID, wherein the salted UUID serves as input to a hashing step (The first password hash can be concatenated with a second salt to generate a second salted password (i.e. salted UUID)) (Chen, 0032, 0037, figs 2-3); and hashing at the processor to hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the specific data item ( The first password hash can be concatenated with a second salt to generate a second salted password) (Chen, 0032, 0037, figs 2-3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Chen teachings into Edison’s teaching of generating a universally unique identifier (UUID) as an intermediate identifier corresponding to the specific data item, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation;
concatenating the UUID with the salt at the processor to produce a salted UUID, wherein the salted UUID serves as input to a hashing step; and hashing at the processor to hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the specific data item. This combination effectively provides secure transmission by salting and hashing the password multiple times.
As to claim 15, Edison discloses a personal data key engine (Edison, ¶ 0005, 0023, fig. 1), comprising: one or more processors; and a non-transitory computer-readable medium storing instructions that, when executed by the one or more processors (Edison, ¶ 0005, 0023, fig. 1), cause the one or more processors to:
receive a specific data item (data controller, private zone) includes data storage 104 that houses clear text data (raw) such as healthcare claims and clinical data (personal data) that are each partially made up of personal information; personal information (specific data item) includes social security number "SSN", first name, last name, and address, contributor IDs, Medicare ID, Medicaid recipient number, and Medicaid family number (unique identifier), and each data contributor computing environment 102 sanitizes the personal information clear text using specific rules/logic (producing); ) (Edison, ¶ 0023-0025, 0036-0038, fig. 1);
generate a universally unique identifier (UUID) corresponding to the specific data item (personal information (specific data item) includes social security number "SSN", first name, last name, and address, contributor IDs, Medicare ID, Medicaid recipient number, and Medicaid family number, and each data contributor computing environment 102 sanitizes the personal information clear text using specific rules/logic (generate); table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2);
wherein the UUID is generated independently of content of the specific data item (see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0038-0045, figs. 5-6, Tables 1-2)
generate a pseudo-random salt (the standardized/sanitized text is salted using a "common salt" where "Salting" is a cryptography concept that involves providing (generating) additional data, such as a common random number (random salt)) (Edison, ¶ 0025-0037, fig. 1);
concatenate the UUID with the salt to produce a salted UUID (the concatenation of the salt and sanitized clear text (unique identifier) of the personal information becomes the message digest (salted unique identifier) (the concatenation of the salt and sanitized clear text (unique identifier) of the personal information becomes the message digest (salted unique identifier;) see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-2); and hash the salted UUID to produce the personal data key corresponding to the original specific data item (the message digest (salted unique identifier) is input to and hashed using a hashing algorithm and the hashed data values, are concatenated for each record/file to generate (produce) a unique ID (personal data key), where a unique ID is generated and associated with the stored hashed personal information (original specific data item); Tables 1, 2;(the message digest (salted unique identifier) is input to and hashed using a hashing algorithm and the hashed data values, are concatenated for each record/file to generate (produce) a unique ID, where a unique ID is generated and associated with the stored hashed personal information (original specific data item); see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3)).
However Edison, does not explicitly disclose generate a universally unique identifier (UUID) as an intermediate identifier corresponding to the specific data item, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation; concatenate the UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step; and hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the original specific data item.
In an analogous art, Chen discloses generate a universally unique identifier (UUID) as an intermediate identifier corresponding to the specific data item (the password can be concatenated with a first salt to generate a first salted password (i.e. intermediate identifier)) (Chen, ¶0032, 0037, figs 2-3), wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation ( password processing module 104 can be configured to process the password information for secure transmission by salting and hashing the password multiple times. For example, the password can be concatenated with a first salt to generate a first salted password) (Chen, ¶0032, 0037, figs 2-3); generate a pseudo-random salt (The first salted password (e.g., the concatenation of the password and the first salt) can be passed through a hashing algorithm to generate a first password hash) (Chen, 0032, 0037, figs 2-3); concatenate the UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step (The first password hash can be concatenated with a second salt to generate a second salted password (i.e. salted UUID)) (Chen, 0032, 0037, figs 2-3); and hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the original specific data item ( The first password hash can be concatenated with a second salt to generate a second salted password) (Chen, 0032, 0037, figs 2-3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Chen teachings into Edison’s teaching of generate a universally unique identifier (UUID) as an intermediate identifier corresponding to the specific data item, wherein the UUID is generated independently of content of the specific data item using a method that does not use any portion of the specific data item as an input to the UUID generation; concatenate the UUID with the salt to produce a salted UUID, wherein the salted UUID serves as input to a hashing step; and hash the salted UUID, rather than the specific data item, to produce the personal data key corresponding to the original specific data item. This combination effectively provides secure transmission by salting and hashing the password multiple times.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Edison (US 2017/0249481 A1), in view of Chen (US 2018/0191688 A1) as applied above in further view of Fukuda (US 2020/0065523 A1).
As to claim 11, Edison-Chen discloses the method of claim 10, Edison disclose storing the second hash key corresponding to a destination platform (a private salt is maintained within (storing) and used solely by (corresponding) the secure facility computing environment 108 (destination platform)) (Edison, ¶ 0025-0041, fig. 1). but does not explicitly disclose further comprising the step of storing the second hash key corresponding to each of a plurality of destination platforms.
In an analogous art, Fukuda discloses comprising the step of storing the key corresponding to each of a plurality of destination platforms (the filtering process unit 54 may encrypt the sensitive information character string or the entirety of the chat data subject to filtering by using a public key of (corresponding) the destination device (destination platform)) (Fukuda, ¶0054-0057).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Fukuda teachings into Edison’s-Chen’s teaching of step of storing the key corresponding to each of a plurality of destination platforms. This combination effectively provide a chat system that prohibits leakage of personal information not intended by the user.
Claim(s) 13-14, 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Edison (US 2017/0249481 A1), in view of Chen (US 2018/0191688 A1) as applied above in further view of Jarvis (US 2021/0319116 A1), hereinafter “Jarvis”.
As to claim 13, Edison-Chen discloses the method of claim 12, but does not disclose wherein the UUID comprises a 128 bit label (see table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information (UUID generated for First_name, Last_name and SSN), similar to applicant specification/remarks example UUID for “A. Smith” could be “8399d898-b826-11eb-8529-0242ac130003) (Edison, ¶ 0023-0025, 0030-0045, figs. 5-6, Tables 1-3).
In an analogous art, Jarvis discloses UUID comprises a 128 bit label (UUID is an identifier, e.g., such as a Universally Unique Identifier (UUID) per the UUID identifier standard that uses a 128-bit value.) (Jarvis, ¶0095).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Jarvis teachings into Edison’s-Chen’s teaching of UUID comprises a 128 bit label. This combination effectively provide access control can be performed to selectively permit users to access and move into spaces.
As to claim 14, Edison-Chen-Jarvis discloses the method of claim 13, Edison discloses wherein the hashing step is performed using a SHA-256 hash algorithm (the hashing algorithm may be a one-way hashing algorithm such as SHA-256;) (Edison, ¶ 0038).
As to claim 16, Edison-Chen discloses the personal data key engine of claim 15, but does not disclose wherein the UUID comprises a 128 bit label.
In an analogous art, Jarvis discloses UUID comprises a 128 bit label (UUID is an identifier, e.g., such as a Universally Unique Identifier (UUID) per the UUID identifier standard that uses a 128-bit value.) (Jarvis, ¶0095).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Jarvis teachings into Edison’s-Chen’s teaching of UUID comprises a 128 bit label. This combination effectively provide access control can be performed to selectively permit users to access and move into spaces.
As to claim 17, Edison-Chen-Jarvis disclose the personal data key engine of claim 16, Edison discloses wherein the instructions further comprise a SHA-256 hash coding to hash the salted UUID. (the hashing algorithm may be a one-way hashing algorithm such as SHA-256;) (Edison, ¶ 0038).
Response to Arguments
Response to 102 rejections applicant’s amendments to the claim change the scope. Therefore, amended claims necessitated new ground(s) of rejections presented in this office action in view of Chen (US 2018/0191688 A1), have been introduced to address amended. Applicant’s arguments have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Abhyankar et al. (US 2021/0165916 A1) disclose A method of authenticated encryption and decryption includes generating a first digital signature with an encryption circuit of a first processor component. Concatenating the first digital signature to a plaintext message to generate a concatenated message. Encrypting the concatenated message into a ciphertext. Transmitting the ciphertext via a communications channel to a second processor component. Decrypting the ciphertext into a decrypted first digital signature and a decrypted plaintext message with a decryption circuit in the second processor component. Comparing, with the decryption circuit, the decrypted first digital signature with a second digital signature, thereby authenticating the decrypted plaintext message.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HITESH R PATEL whose telephone number is (571)270-5442. The examiner can normally be reached Monday-Friday 7am-3pm.
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, James Trammell can be reached at 571-272-6712. 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.
/Hitesh Patel/Supervisory Patent Examiner, Art Unit 3667
2/24/26