Detailed Action
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 in response to Application with case number 18/617,335, filed on 3/26/2024 in which claims 1-20 are presented for examination.
Status of Claims
Claims 1-20 are pending, of which claims 1, 11 and 18 are in independent form.
Specification
The examiner notes that the Specification does not include any URL links and Trademark terms requiring capitalization.
The examiner notes that the abstract is in narrative form and is limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. In addition, the examiner notes that the abstract is not using legal phraseology often used in patent claims.
IDS
References cited in the IDS filed on 3/26/2024 have been considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
In claim 18, Claim limitations (means to store data) in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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-7 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Klapman (US 2022/0121781 A1), in view of Lei et al. (US 2009/0300351 A1) hereinafter Lei.
As to claim 1, Klapman teaches a data storage device (see Fig. 7 data storage device 202 and para. [0101] and [0102]), comprising: a memory device (see para. [0103] “DSD 202 further comprises a non-volatile physical data storage medium 207.”); and a controller coupled to the memory device (see Fig. 7 controller 206 and para. [0102]), wherein the controller is configured to:
place data in a first physical location of the memory device; encrypt the data (see Fig. 7, steps 702-704 (702 write sectors (plain data); 703 encrypt; 704 store); see para. [0140] “Then, host computer system 201 issues 702 a WRITE SECTORS command to send the file data in unencrypted form to DSD 202. Since host computer system 201 maintains the FAT at this stage, host computer system 201 may also perform the allocation of the file data to blocks and specify those blocks or at least the starting block address in the write command. Controller 206 then encrypts 703 the received data with the file key and stores 704 the encrypted data on storage medium 207. The data is now stored, and the DSD 202 can be used for unrelated tasks or powered down. At a later stage, when the data needs to be read, host computer system 201 deactivates decryption 705 by issuing a SECURITY DECRYPT OFF command. Alternatively, decryption may be deactivated by default, so sending the command is not necessary. Host computer system 201 then reads 706 the FAT table by issuing a READ SECTORS command for the predefined sectors where the FAT is stored. In response, controller 206 returns 707 the encrypted FAT to the host computer system 201. Host computer system 201 then decrypts 708 the FAT using the volume_key (which is different from the file key). Alternatively, host computer system 201 can activate decryption and read the FAT in decrypted form.”).
Klapman does not explicitly teach but Lei teaches the following limitations - place keyword metadata of the data in a second physical location of the memory device (see Figs. 6, 7, and 16, where encrypted files and the Encrypted Index are stored separately in different location of the server. The examiner considers the server as equivalent to the memory device.; see par. [0051] “…the data owner encrypts his/her files and associated meta-data, and stores the ciphertext to the server. The files remain encrypted throughout its lifetime at the server. To enable content-based search on the encrypted files, the data owner generates an encrypted index according to each keyword of the files, and stores the encrypted index to the server. The index is an inverted index and remains encrypted as it is stored at the server.”; see also para. [0057]), wherein the first physical location and the second physical location are distinct and different (see Figs. 6, 7, and 16, where encrypted files and the Encrypted Index are stored separately in different location of the server (or storage device).); and encrypt the keyword metadata (see para. [0075] “For each keyword, the index form unit 106 forms a KIS, and at step 304, the index forming unit 106 forms the encrypted index by all KISes.”), wherein the encryption for the data is different from the encryption for the keyword metadata (see para. [0074] and [0075] for encrypting the keywords or keyword metadata; see para. [0057] for encrypting each files including keywords for being used search/query, “At step S202, the encryption/decryption setting unit 102 sets file encryption and decryption keys for each file. The file encryption key is used to encrypt the corresponding file and the file decryption key is used to decrypt the corresponding encrypted file. The file encryption/decryption keys may be set arbitrarily according to any encryption method. In the present invention, the file encryption key and the file decryption key for a file may be set differently with asymmetric encryption scheme. However, a single key may be used as both file encryption key and file decryption key of a file in the invention with symmetric encryption scheme. In such case, the file decryption key and the file encryption key for the same file are the same in the description below.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Klapman and Lei before him or her, to modify the scheme of Klapman by including Lei. The suggestion/motivation for doing so would have been to enable users to use the keyword encryption key in encrypting the keywords and its location data so its encrypted indices are available for searchable encryption indices in a secure way but at the same time the key available to the index searcher is not able to mount a dictionary attack on the storage including the encrypted data with the given keyword encryption key(s).
As to claim 2, in view of claim 1, Lei teaches wherein the encryption for the keyword metadata is deterministic encryption (see para. [0063] “The data owner may keep the algorithm and related parameters necessary to compute the file locator generation and decryption keys, for example, in the encryption/decryption setting unit 102, for later calculation of the file locator generation and decryption keys.”)
As to claim 3, in view of claim 1, Lei teaches wherein the encryption for the data provides a higher level of security than the encryption for the keyword metadata (see para. [0057] for using asymmetric encryption scheme for file encryption/decryption; see para. [0062] for encrypting the file locator in the file index using simpler symmetric key, “EKey_m=DKey_m=Hash(MEK || m)”).
As to claim 4, in view of claim 1, Lei teaches wherein the encrypted keyword metadata is searchable without decrypting the keyword metadata (see Fig. 9 step S602 Searcher send a search request containing a KIS locator to server; S603 Server locates corresponding KIS in the encrypted index; S604 Server sends file locators contained in the KIS to searcher; see also para. [0066] for issuing KIS locator, “FIG. 5 illustrates an example of the process of generating the encrypted inverted index according to the embodiment. For a Keyword KW_i, the KIS locator generation unit 104 generates a unique KIS locator KL_i as a unique identifier of the KIS of the keyword KW_i at step S301. The KIS locator KL_i may be generated arbitrarily as long as it uniquely corresponds to the keyword KW_i and without the help of the data owner, anyone else cannot calculate the keyword KW_i from KL_i. Generally, the KIS locator generation unit 104 maps each keyword to a unique value through any available algorithm to generate the KIS locator for each keyword. For example, the KIS locator KL_i may be generated as follow: KL_i=Hash(MEK || KW_i) (Equation 2)”).
As to claim 5, in view of claim 1, Lei teaches wherein the first physical location is partitioned from the second physical location (see Fig. 6; It is noted Encrypted files are stored separately from Encrypted Index).
As to claim 6, in view of claim 1, Lei teaches wherein the controller is configured to: receive a search command (The examiner considers the server comprising the storage unit 401 and the index sear4ch unit 402 as equivalent to the instant application’s controller.; see Fig. 7 and para. [0081] “the server 400 mainly comprises a storage unit 401 for storing the encrypted files and the encrypted index received from the data owner, an index search unit 402 for performing search in the encrypted index in response to the searcher's request and a file search unit 403 for searching for the encrypted files identified by particular encrypted resource identifiers.”; see para. [0085] “In the searching phase, the searcher terminal generates a search request containing a KIS locator by the search request unit 501 and transmits the search request to the server, as shown in step S602.”); and search the encrypted keyword metadata (see para. [0086] “After the server receives the request containing the KIS locator from the searcher terminal, the server performs search by the index search unit 402 in the encrypted index stored in the storage unit 401 to find out a KIS the KIS locator of which is the same as that received in the request, as shown in step S603. Then, the server sends the file locators contained in the matching KIS to the searcher terminal at step S604.”).
As to claim 7, in view of claim 6, Lei teaches wherein the controller is configured to determine that there is one or more relevant keywords in the encrypted keyword metadata (see para. [0086] “…the server performs search by the index search unit 402 in the encrypted index stored in the storage unit 401 to find out a KIS the KIS locator of which is the same as that received in the request, as shown in step S603. Then, the server sends the file locators contained in the matching KIS to the searcher terminal at step S604.”).
As to claim 18, Klapman teaches a data storage device (see Fig. 7 data storage device 202 and para. [0101] and [0102]), comprising: means to store data (see para. [0103] “DSD 202 further comprises a non-volatile physical data storage medium 207.”); and a controller coupled to the means to store data (see Fig. 7 controller 206 and para. [0102]).
Klapman does not explicitly teach but Lei teches wherein the controller is configured to: detect whether a security risk to data stored in the means to store data is present (see para. [0084] “Firstly, at step S601, if the data owner wants to enable a searcher to search on a keyword, the data owner issues, in a secure manner, to the searcher the KIS locator of the keyword as well as a file locator decryption key of suitable privacy level authorized to the searcher. The data owner may notify each searcher of the respective KIS locator and file locator decryption key via various ways, for example, automatically by electrical message sent via communication networks between the data owner terminal and the searcher terminal, orally or by written form. The authorization may be performed in response to a searcher's request. For example, the searcher may send a request containing one or more keywords he/she wishes to search on to the data owner by, for example, a search capability request unit (not shown). After confirming the identity of the searcher, the data owner may decide the privacy level suitable for the searcher and issue the searcher with the KIS locator(s) of the requested keyword(s) and the file locator decryption key of the decided privacy level. The KIS locators and the file locator decryption key may be retrieved from the tables stored at the data owner terminal, or calculated online by the data owner terminal according to the stored security parameters. The process of authorization may be performed by, for example, an authorization unit (not shown) in the data owner terminal. In some situations, security authentication may be required for the searcher to obtain authorization from the data owner.”; The examiner considers “the data owner issuing to the searcher the KIS locator of the keyword as well as a file locator decryption key of suitable privacy level authorized to the searcher” as equivalent to the instant application’s tracking security risks to the data.); and
change a type of encryption for the data based upon the detecting (see para. [0063] “The data owner may keep the algorithm and related parameters necessary to compute the file locator generation and decryption keys, for example, in the encryption/decryption setting unit 102, for later calculation of the file locator generation and decryption keys.”; It is noted that the encryption algorithm can be switched later and kept consistent for later encrypted keyword search.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Klapman and Lei before him or her, to modify the scheme of Klapman by including Lei. The suggestion/motivation for doing so would have been to enable users to use the keyword encryption key in encrypting the keywords and its location data so its encrypted indices are available for searchable encryption indices in a secure way but at the same time the key available to the index searcher is not able to mount a dictionary attack on the storage including the encrypted data with the given keyword encryption key(s).
As to claim 19, in view of claim 18, Lei teaches wherein the controller is configured to changing the type of encryption to deterministic based upon determining that there is no security risk (see para. [0063] “The data owner may keep the algorithm and related parameters necessary to compute the file locator generation and decryption keys, for example, in the encryption/decryption setting unit 102, for later calculation of the file locator generation and decryption keys.”; It is noted that the encryption algorithm can be switched later and kept consistent for later encrypted keyword search.)
As to claim 20 in view of claim 18, Lei teaches wherein the data comprises a first portion of data comprising logical block addresses (LBAs) and a second portion of data that comprises keyword metadata for the LBAs, and wherein the first portion and the second portion are disposed in separate locations within the means to store data (see Figs. 6, 7, and 16, where encrypted files and the Encrypted Index are stored separately in different location of the server (or storage device).).
Claim(s) 8-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Klapman, in view of Lei, and further in view of Muthiah (US 2023/0359369 A1).
As to claim 8, in view of claim 7, the combination of Klapman and Lei does not explicitly teach but Muthiah teaches wherein the controller is configured to decrypt a portion of the encrypted data (see para. [0023]-[0026] “[0023] In certain applications, a host device may intend to perform data computations, such as data filtering, media processing, data analysis, machine learning, etc. Typically, the host device does not include sufficient memory and resources to dedicate to such computations, and therefore the host device may tend to offload this work to a storage device (e.g., an SSD) interfacing with the host device. The storage device may include a large supply of memory and resources available to apply these computations, and therefore the host device may send the data to the storage device to store and subsequently perform any data computations requested by the host device. [0024] Generally, to prevent this data from being exposed to unauthorized parties over the network interface between the host device and storage device, the host device may first encrypt the data using a key, and then send the encrypted data to the storage device. For example, the key may be a public or private key derived from a standard asymmetric encryption operation performed between the host device and storage device. The storage device may later decrypt the data using the key in order to perform any requested computations. However, this key typically encompasses or protects the entire logical region or namespace storing this data in its entirety, which may include a broad range of logical block addresses (LBAs) potentially encompassing millions of LBAs for example. Such key may be referred to as a “key per logical region” or “key per namespace” throughout this disclosure, an example of which is illustrated in FIG. 6. Thus, the encrypted data in a namespace may include numerous other data that is not relevant to the requested computations. [0025] As a result, if the host device intends the storage device to only perform a computation on a portion of this encrypted data, the storage device may end up having to decrypt the entire namespace or logical region of encrypted data just to process the relevant portion. For example, if the storage device stores encrypted data from multiple sensors, or encrypted data of a media transport stream having multiple video and audio sub-streams, in a logical region or namespace, the storage device would end up having to decrypt the data from all of the sensors or sub-streams in that logical region, even if the storage device is requested only to perform computations on data from one of the multiple sensors or from one of the sub-streams. Such decryption based on a key per logical region may pose a significant security risk, for example, if the storage device is requested to communicate the decrypted data in its entirety to the host device over the network interface for possible disclosure to another host device despite only requesting a portion of this data. [0026] To provide a balance between the storage of encrypted data in a logical region and the security in decrypting data when a portion of this data is relevant for a computation, an exemplary embodiment of the storage device of the present disclosure utilizes a key for encryption or decryption of a data portion rather than for the entire logical region or data itself. For instance, rather than applying a key for a namespace including encrypted data, the storage device may apply a key specifically for the data requested to be computed in a particular application. Thus, different portions of data in a namespace may be encrypted using different keys, and a respective portion of the data in that namespace may be decrypted using one of these keys. Additionally, multiple portions of data in a namespace may be grouped together and encrypted using a key for that particular group, and multiple such groups of data portions may be respectively encrypted and decrypted using different keys for each group.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Klapman, Lei, and Muthiah before him or her, to modify the scheme of Klapman and Lei by including Muthiah. The suggestion/motivation for doing so would have been to use a partial encryption to a searchable keyword group being stored together with the document different from the main region storage key for the purpose of determining match between the search query keywords and the keywords found in the document without decrypting the entire document including other sensitive information.
As to claim 9, in view of claim 8, Muthiah teaches wherein the portion is encrypted data corresponding to the one or more relevant keywords (see explanation presented in the rejection of claim 8 along with para. [0023]-[0026]).
As to claim 10, in view of claim 9, Lei teaches wherein the controller is configured to search the portion for an exact match corresponding to the search command (see para. [0086] “After the server receives the request containing the KIS locator from the searcher terminal, the server performs search by the index search unit 402 in the encrypted index stored in the storage unit 401 to find out a KIS the KIS locator of which is the same as that received in the request, as shown in step S603. Then, the server sends the file locators contained in the matching KIS to the searcher terminal at step S604.”).
As to claim 11, Klapman teaches a data storage device (see Fig. 7 data storage device 202 and para. [0101] and [0102]), comprising: a memory device (see para. [0103] “DSD 202 further comprises a non-volatile physical data storage medium 207.”); and a controller coupled to the memory device (see Fig. 7 controller 206 and para. [0102]).
Klapman does not explicitly teach but Lei teaches wherein the controller is configured to:
search encrypted keyword metadata (see Fig. 9 step S602 Searcher send a search request containing a KIS locator to server; S603 Server locates corresponding KIS in the encrypted index; S604 Server sends file locators contained in the KIS to searcher; see also para. [0066] for issuing KIS locator, “FIG. 5 illustrates an example of the process of generating the encrypted inverted index according to the embodiment. For a Keyword KW_i, the KIS locator generation unit 104 generates a unique KIS locator KL_i as a unique identifier of the KIS of the keyword KW_i at step S301. The KIS locator KL_i may be generated arbitrarily as long as it uniquely corresponds to the keyword KW_i and without the help of the data owner, anyone else cannot calculate the keyword KW_i from KL_i. Generally, the KIS locator generation unit 104 maps each keyword to a unique value through any available algorithm to generate the KIS locator for each keyword. For example, the KIS locator KL_i may be generated as follow: KL_i=Hash(MEK || KW_i) (Equation 2)”), wherein the keyword metadata is disposed in a first partition of the memory device (see Figs. 6, 7, and 16, where encrypted files and the Encrypted Index are stored separately in different location of the server (or storage device).);
determine that the encrypted keyword metadata has relevant keywords (see para. [0086] “After the server receives the request containing the KIS locator from the searcher terminal, the server performs search by the index search unit 402 in the encrypted index stored in the storage unit 401 to find out a KIS the KIS locator of which is the same as that received in the request, as shown in step S603. Then, the server sends the file locators contained in the matching KIS to the searcher terminal at step S604.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Klapman and Lei before him or her, to modify the scheme of Klapman by including Lei. The suggestion/motivation for doing so would have been to enable users to use the keyword encryption key in encrypting the keywords and its location data so its encrypted indices are available for searchable encryption indices in a secure way but at the same time the key available to the index searcher is not able to mount a dictionary attack on the storage including the encrypted data with the given keyword encryption key(s).
The combination of Klapman and Lei does not explicitly teach but Muthiah teaches the following –
decrypt logical block addresses (LBAs) corresponding to the relevant keywords ; and search the decrypted LBAs.
(see para. [0024]-[0026] “ [0024] Generally, to prevent this data from being exposed to unauthorized parties over the network interface between the host device and storage device, the host device may first encrypt the data using a key, and then send the encrypted data to the storage device. For example, the key may be a public or private key derived from a standard asymmetric encryption operation performed between the host device and storage device. The storage device may later decrypt the data using the key in order to perform any requested computations. However, this key typically encompasses or protects the entire logical region or namespace storing this data in its entirety, which may include a broad range of logical block addresses (LBAs) potentially encompassing millions of LBAs for example. Such key may be referred to as a “key per logical region” or “key per namespace” throughout this disclosure, an example of which is illustrated in FIG. 6. Thus, the encrypted data in a namespace may include numerous other data that is not relevant to the requested computations. [0025] As a result, if the host device intends the storage device to only perform a computation on a portion of this encrypted data, the storage device may end up having to decrypt the entire namespace or logical region of encrypted data just to process the relevant portion. For example, if the storage device stores encrypted data from multiple sensors, or encrypted data of a media transport stream having multiple video and audio sub-streams, in a logical region or namespace, the storage device would end up having to decrypt the data from all of the sensors or sub-streams in that logical region, even if the storage device is requested only to perform computations on data from one of the multiple sensors or from one of the sub-streams. Such decryption based on a key per logical region may pose a significant security risk, for example, if the storage device is requested to communicate the decrypted data in its entirety to the host device over the network interface for possible disclosure to another host device despite only requesting a portion of this data. [0026] To provide a balance between the storage of encrypted data in a logical region and the security in decrypting data when a portion of this data is relevant for a computation, an exemplary embodiment of the storage device of the present disclosure utilizes a key for encryption or decryption of a data portion rather than for the entire logical region or data itself. For instance, rather than applying a key for a namespace including encrypted data, the storage device may apply a key specifically for the data requested to be computed in a particular application. Thus, different portions of data in a namespace may be encrypted using different keys, and a respective portion of the data in that namespace may be decrypted using one of these keys. Additionally, multiple portions of data in a namespace may be grouped together and encrypted using a key for that particular group, and multiple such groups of data portions may be respectively encrypted and decrypted using different keys for each group.”; The examiner considers performing an operation on a decrypted portion of the LBA as equivalent to or including “searching the decrypted LBAs.” )
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Klapman, Lei, and Muthiah before him or her, to modify the scheme of Klapman and Lei by including Muthiah. The suggestion/motivation for doing so would have been to use a partial encryption to a searchable keyword group being stored together with the document different from the main region storage key for the purpose of determining match between the search query keywords and the keywords found in the document without decrypting the entire document including other sensitive information.
As to claim 12, in view of claim 11, Lei teaches wherein the LBAs are disposed in a second partition of the memory device that is partitioned from the first partition (see Figs. 6, 7, and 16, where encrypted files and the Encrypted Index are stored separately in different location of the server (or storage device).).
As to claim 13, in view of claim 11, Lei teaches wherein the searching of encrypted keyword metadata is in response to a search command received internally from the data storage device (see para. [0086] “After the server receives the request containing the KIS locator from the searcher terminal, the server performs search by the index search unit 402 in the encrypted index stored in the storage unit 401 to find out a KIS the KIS locator of which is the same as that received in the request, as shown in step S603. Then, the server sends the file locators contained in the matching KIS to the searcher terminal at step S604.”).
As to claim 14, in view of claim 11, Lei teaches wherein the encrypted keyword metadata and the LBAs are encrypted differently (see para. [0074] and [0075] for encrypting the keywords or keyword metadata; see para. [0057] for encrypting each files including keywords for being used search/query, “At step S202, the encryption/decryption setting unit 102 sets file encryption and decryption keys for each file. The file encryption key is used to encrypt the corresponding file and the file decryption key is used to decrypt the corresponding encrypted file. The file encryption/decryption keys may be set arbitrarily according to any encryption method. In the present invention, the file encryption key and the file decryption key for a file may be set differently with asymmetric encryption scheme. However, a single key may be used as both file encryption key and file decryption key of a file in the invention with symmetric encryption scheme. In such case, the file decryption key and the file encryption key for the same file are the same in the description below.”.
As to claim 15, in view of claim 11, Lei teaches wherein the controller is configured to track security risks to data (see para. [0084] “Firstly, at step S601, if the data owner wants to enable a searcher to search on a keyword, the data owner issues, in a secure manner, to the searcher the KIS locator of the keyword as well as a file locator decryption key of suitable privacy level authorized to the searcher. The data owner may notify each searcher of the respective KIS locator and file locator decryption key via various ways, for example, automatically by electrical message sent via communication networks between the data owner terminal and the searcher terminal, orally or by written form. The authorization may be performed in response to a searcher's request. For example, the searcher may send a request containing one or more keywords he/she wishes to search on to the data owner by, for example, a search capability request unit (not shown). After confirming the identity of the searcher, the data owner may decide the privacy level suitable for the searcher and issue the searcher with the KIS locator(s) of the requested keyword(s) and the file locator decryption key of the decided privacy level. The KIS locators and the file locator decryption key may be retrieved from the tables stored at the data owner terminal, or calculated online by the data owner terminal according to the stored security parameters. The process of authorization may be performed by, for example, an authorization unit (not shown) in the data owner terminal. In some situations, security authentication may be required for the searcher to obtain authorization from the data owner.”; The examiner considers “the data owner issuing to the searcher the KIS locator of the keyword as well as a file locator decryption key of suitable privacy level authorized to the searcher” as equivalent to the instant application’s tracking security risks to the data.).
As to claim 16, in view of claim 11, Lei teaches wherein the controller is configured to change encryption for the encrypted keyword metadata from deterministic encryption to a different encryption (see para. [0063] “The data owner may keep the algorithm and related parameters necessary to compute the file locator generation and decryption keys, for example, in the encryption/decryption setting unit 102, for later calculation of the file locator generation and decryption keys.”; It is noted that the encryption algorithm can be switched later and kept consistent for later encrypted keyword search.)
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Klapman, in view of Lei, in view of Muthiah, and further in view of Fan et al. (WO 2017/055261 A1) hereinafter Fan.
As to claim 17, in view of claim 11, the combination of Klapman, Lei, and Muthiah does not explicitly teach but Fan teaches wherein the encrypted keyword metadata is disposed in cache and the LBAs are disposed in the memory device (see para. [0022] “The client 104 stores the local search index 136 in the client memory 120 to enable identification of keyword values that are also present in at least one of the encrypted files 178 that are stored in the memory 170 of the server 154. In the embodiment of the system 100, the local search index 136 enables the client 104 to identify keyword values that are verified to be included in a search entry of the encrypted search index 174 and at least one encrypted file 178 stored in the memory 170 of the server 154. The client 104 uses the local search index 136 to ensure that any search query that is transmitted to the server 154 should return a non-null result with matching files, which prevents the server 154 from generating a false response to the search query in which the server 154 indicates there are no files that match the search query for the encrypted keyword.”; The examiner considers the local search index proximate to the searcher as equivalent to the encrypted keyword metadata disposed in cache.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Klapman, Lei, Muthiah, and Fan before him or her, to modify the scheme of Klapman, Lei an Muthiah by including Fan. The suggestion/motivation for doing so would have been to perform the swift secure index searching such that the return of distally located file or document are positively affirmed prior to performing the file or document retrieval using the encrypted keyword based search and retrieval.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE K SONG whose telephone number is (571)270-3260. The examiner can normally be reached on M-F 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on (571)272-3867 . The fax phone number for the organization where this application or proceeding is assigned is 571-273-7291.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE K SONG/PRIMARY Examiner, Art Unit 2497