The present application, filed on or after March 16, 2013, is being examined under first to invent provisions of the AIA .
DETAILED ACTION
This Action is in response to communications filed 6/12/2026.
Claims 1, 3, 6, 11, 13, 18 and 20 are amended. Claims 14-15 are cancelled. Claims 21 and 22 are new.
Claims 1-13 and 16-22 are pending.
Claims 1-13 and 16-22 are rejected.
Response to Arguments
Applicant`s arguments filed June 12, 2026 have been fully considered and they are persuasive with respect to prior art rejection.
As per the 103 rejection of claims 1, 11 and 18, Applicant argued Sharon fails to disclose or suggest the feature of " the prefetch trigger including an operation on a content portion of content provided by an application; in response to detecting the prefetch trigger: encrypt the content portion; wherein the encrypted search results are a processed output of the encrypted content portion maintained in an encrypted state; obtain decrypted search results by decrypting the encrypted search results; and in response to receiving a search request based on the content portion, provide the decrypted search results"; where examiner relies on a newly cited reference Wagenaar and Schaad to disclose the claimed limitation.
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 of this title, 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.
8. Claims 1-2, 11-12 and 18-19 are rejected under 35 U.S.C. 103(a) as being unpatentable by Lemsitzer et al. (US PGPUB 2021/0360395 hereinafter referred to as Lemsitzer), in view of Wagenaar et al. (US PGPUB 2016/0182466) (hereinafter Wagenaar), in view of Hotchkies et al. (US 9,424,357) (hereinafter Hotchkies), and further in view of Schaad et al. (WO 2018/103830) (hereinafter Schaad).
As per independent claim 1, Lemsitzer discloses a computer program product, the computer program product being tangibly embodied on a non-transitory computer-readable storage medium and comprising instructions that, when executed by at least one computing device, are configured to cause the at least one computing device to: detect a prefetch trigger [(Paragraph 0037; Figs. 1-3) where Lemsitzer teaches where the UWB device may be triggered to fetch the session key with a the sub-session identifier corresponding to the new responder address of the multicast list. On the side of the responder (e.g., a phone), which has taken the role of controlee, the session key with the session identifier associated with the multicast session is fetched when said multicast session is started. Furthermore, the UWB device may retrieve a responder-specific session key for each responder from the secure element via the SUS applet by providing the sub-session identifier. The session key may be used to derive all required keys to encrypt/decrypt STSs and payloads. Furthermore, the session key may be used to derive all required keys to encrypt STSs and commands from the controller. Furthermore, the responder-specific session keys may be used to decrypt STSs and payloads from the responders to correspond to the claimed limitation]; encrypt the content portion, in response to the prefetch trigger, to obtain an encrypted content portion [(Paragraph 0037; Figs. 1-3) where Lemsitzer teaches where the session key may be used to derive all required keys to encrypt/decrypt STSs and payloads. Furthermore, the session key may be used to derive all required keys to encrypt STSs and commands from the controller. Furthermore, the responder-specific session keys may be used to decrypt STSs and payloads from the responders to correspond to the claimed limitation].
Lemsitzer does not appear to explicitly disclose the prefetch trigger including an operation on a content portion of content provided by an application; in response to detecting the prefetch trigger: encrypt the content portion.
However, Wagenaar discloses the prefetch trigger including an operation on a content portion of content provided by an application; in response to detecting the prefetch trigger: encrypt the content portion [(Paragraph 0029; Figs. 2A and 2B) where Hotchkies teaches wherein Fetching the server manifest file 115 from the CMS 120 is a secure methodology when data on a locally stored system providing the server manifest (e.g., on disk at the origin 110) is unsecure or may be compromised. This may be the case also when content providers (e.g., broadcasters) want to ensure and manage the security of their content, for example, by controlling oversight and use of certificates, key and rights included or identified in the server manifest file 115 on the CMS 120. The fetching is dynamic in the sense that the mapping created from the ismproxypass fetches the server manifest 115 from the location as it is needed. For instance, responsive to a request from a client that triggers a fetch of the server manifest 115. The returned server manifest 115 then can be same or different, based on implemented business rules in the CMS 120. For example, the server manifest fetched may be dynamically updated by the CMS to identify different DRM's (listed in the server manifest) which the origin 110 can retrieve the encrypted content as it is streaming media to correspond to the claimed limitation].
Lemsitzer and Wagenaar are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer and Wagenaar before him or her, to modify the method of Lemsitzer to include the fetching trigger of Wagenaar because it will enhance data access.
The motivation for doing so would be [“provides authorization and a location to retrieve the media” (Paragraph 0005 by Wagenaar)].
Lemsitzer does not appear to explicitly disclose transmit the encrypted content portion to a search server; receive encrypted search results from the search server; receive a search request based on the content portion.
However, Hotchkies discloses transmit the encrypted content portion to a search server; receive encrypted search results from the search server [(Column 7, lines 40-64; Figs. 3D and 4A) where Hotchkies teaches wherein at box 403 in FIG. 4A, the browser 151 captures text as it is entered by a user into a search query component 303 within a search results network page 139. The browser 151 periodically provides the text to the computing device 103, for processing by the search term suggestion engine 121, at box 406. Next, at box 409 the browser 151 receives one or more suggested search terms from the computing device 103. Having received at least one suggested search term, the browser 151 determines whether a prediction can be made, with confidence, that one of the suggested search terms will be accepted by the user. Once a confident prediction is available, a speculative search query can be issued for the suggested search term, before the user actually chooses the search term and executes a search. The prediction of whether a suggested search term will be selected by the user at a particular point in time is based on the number of characters in the search query at that time, as follows. At box 412 the browser 151 evaluates the entered text in accordance with one or more text characteristics confidence criteria. Such criteria may include, for example: number of characters in the entered text exceeds a predefined threshold; number of characters in the entered text exceeds a predefined percentage of the first search term suggested by the search term suggestion engine 121; and identity of characters within the entered text. Some embodiments may combine multiple text size criteria to correspond to the claimed limitation]; receive a search request based on the content portion [(Column 8, lines 55-67 and Column 7, lines 1-28; Figs. 3D and 4A) where Hotchkies teaches where Box 427 is executed if the browser 151 next receives results from the speculative search query issued in box 421, while box 430 is executed if the browser 151 next receives a user instruction to execute a search query. Once the speculative search results are received at box 427, the rendering code 145 executes in the browser 151 at box 433 to render speculative search results in a hidden portion of the browser 151. In the embodiment discussed here in connection with FIGS. 4A and 4B, the speculative search results provided by the computing device 103 represent only a portion of the entire results, with the remainder being fetched later. In other embodiments, the computing device 103 provides the entire search result set at one. Having hidden the speculative search results, processing then continues at box 430. Box 430 is executed when the browser 151 receives a user instruction to execute a search query, which may occur before or after speculative search results are received. Next, at box 436 the browser 151 determines whether the query executed by the user corresponds to the suggested search term used in the speculative search results, or to a different search term. If the user did not execute a query for the speculative search term, then at box 439 the browser 151 provides the user's search term to the computing device 103. Since the speculative search query was incorrect (a “miss”) the search results are processed in a conventional manner, and the search query process of FIGS. 4A and 4B is complete to correspond to the claimed limitation].
Lemsitzer and Hotchkies are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer and Hotchkies before him or her, to modify the method of Lemsitzer to include the of Hotchkies because it will enhance data access.
The motivation for doing so would be [“the user experience is enhanced by making a prediction about which search queries the user will perform and speculative issuing those queries, since the pre-fetched results can be rendered when the user commits to the query” (Column 5, lines 60-65 by Hotchkies)].
Lemsitzer does not appear to explicitly disclose wherein the encrypted search results are a processed output of the encrypted content portion maintained in an encrypted state; obtain decrypted search results by decrypting the encrypted search results; and in response to receiving a search request based on the content portion, provide the decrypted search results.
However, Schaad discloses wherein the encrypted search results are a processed output of the encrypted content portion maintained in an encrypted state [(Page 6, lines 23-29 and Page 7, lines 13-25) where Schaad teaches wherein the application may encrypt the data element with any encryption known in the art, for example keyed encryption, and encrypt the plaintext tag using the current invention as described below in FIG. 1. The application may transmit the encrypted data element and encrypted plaintext tag to be stored on a cloud storage provider to correspond to the claimed limitation]; obtain decrypted search results by decrypting the encrypted search results; and in response to receiving a search request based on the content portion, provide the decrypted search results [(Page 13, lines 21-33 and Page 15, lines 6-15) where Schaad teaches wherein the user may enter a search for a data element that is associated with an encrypted dataset index entry, for example by a lookup table. The associated encrypted dataset index entry may be transferred to a database, for example database 220, which is adapted to respond to client requests, and the associated encrypted data element is transmitted to system 220, for example via network 230. The data element is then decrypted and displayed to the user; FIG. 6, a schematic illustration of a user device for encrypting, storing and searching for a data element, according to some embodiments of the current invention. As shown in 601, the user device, for example user device 260, is equipped with a camera which creates an image file. The image file is encrypted and the encrypted dataset index entry is generated as described above. As shown in 602, a user initiates a search for a plaintext tag that is associated with the image file, as described above. As shown in 603, the encrypted dataset index entry associated with the plaintext tag is located and sent as a query to database 220 in cloud storage 240. As shown in 604, the encrypted image file is received from cloud storage 240 and decrypted with the encryption key stored on user device 260 to correspond to the claimed limitation].
Lemsitzer and Schaad are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer and Schaad before him or her, to modify the method of Lemsitzer to include the of Schaad because it will enhance data access.
The motivation for doing so would be [“reduces the opportunity for decrypting plaintext tags through statistical analysis of queries and responses” (Page 7, lines 26-30 by Schaad)].
Lemsitzer further discloses provide the decrypted search results at the application [(Paragraph 0052-0055; Figs. 1-3) where Lemsitzer teaches transmitting, by an ultra-wideband communication unit comprised in a communication node, one or more messages to a plurality of external responder nodes and receiving, by said communication unit, responses from said responder nodes. 204 using, by a processing unit comprised in the communication node, a common cryptographic session key to encrypt said messages, wherein said common cryptographic session key is a key shared between the ultra-wideband communication node and all the external responder nodes. 206 using, by said processing unit, responder-specific cryptographic session keys to decrypt the responses and/or to encrypt further messages to the responder nodes, wherein each individual one of said responder-specific session keys is a key shared between the ultra-wideband communication node and one of the external responder nodes to correspond to the claimed limitation].
Therefore, it would have been obvious to combine Lemsitzer and Hotchkies to obtain the invention as specified in the instant claim.
As per dependent claim 2, Lemsitzer discloses receive a selection of the content portion; and detect the prefetch trigger, based on the selection [(Paragraphs 0036-0037; Figs. 1-3) where Lemsitzer teaches wherein, once the UWB session is started, a UWB subsystem may fetch the session key associated with the session identifier from the secure element. In an example, this may applied in an access control use case. The UWB device may fetch the session key when the multicast session is started on a reader device, which has taken the role of controller/initiator. Subsequently, when new responders are added to the multicast list, the UWB device may be triggered to fetch the session key with the sub-session identifier corresponding to the new responder address of the multicast list to correspond to the claimed limitation].
As for independent claims 11 and 18, the applicant is directed to the rejections to claim 1 set forth above, as they are rejected based on the same rationale.
As for dependent claims 12 and 19, the applicant is directed to the rejections to claim 2 set forth above, as they are rejected based on the same rationale.
Claims 3, 13 and 20 are rejected under 35 U.S.C. 103(a) as being disclosed by Stoller in view of Lemsitzer/ Hotchkies/ Wagenaar/Schaad, as applied to claims 1, 11 and 18, and further in view of Farkash et al. (US PGPUB 2018/0137303 hereinafter referred to as Farkash).
As per dependent claim 3, Lemsitzer/ Hotchkies discloses the computer program product of claim 1.
Lemsitzer/ Hotchkies does not appear to explicitly disclose detect a loading of the content provided by the application, the content including the content portion; perform a classification of text of the content, including the content portion, in response to the loading; and detect the prefetch trigger, based on the classification.
However, Farkash discloses detect a loading of the content provided by the application, the content including the content portion; perform a classification of text of the content, including the content portion, in response to the loading; and detect the prefetch trigger, based on the classification [(Paragraphs 0004, 0035-0036 and 0045-0047; FIGs. 1-3) where the processor may also scan the detected input text or the detected output text to detect a candidate based on the text classifiers; the processor also receives hashed sensitive data including attributes, hashing functions, and text classifiers. For example, attributes may include trusted URLs, sensitivity levels, for each sensitive data type. In some examples, the processor may update the received sensitive information in response to detecting that a password does not match. For example, a configuration file can be created dynamically by a trusted server and then signed and received by the processor. If any data changes, the signature of the configuration will not match. The processor may accordingly fetch the updated configuration in response to detecting the signature mismatch. In some examples, the processor may also validate a configuration file. For example, the configuration file may include the hashed sensitive data, hashing function, and text classifiers. In some examples, validating the configuration file may include receiving an encrypted signature of the configuration file and decrypting the encrypted signature using a public key, and validating content of the configuration file using the decrypted signature to correspond to the claimed limitation].
Lemsitzer/ Hotchkies and Farkash are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer/ Hotchkies and Farkash before him or her, to modify the method of Lemsitzer/ Hotchkies to include the classification of Farkash because it will enhance data access.
The motivation for doing so would be [“prevent a malicious attacker in control of the browser from changing the configuration file and rendering it useless, and thus ensure that the configuration file has not been tampered with by a malware” (Paragraph 0047 by Farkash)].
Therefore, it would have been obvious to combine Lemsitzer/ Hotchkies and Farkash to obtain the invention as specified in the instant claim.
As for dependent claims 13 and 20, the applicant is directed to the rejections to claim 3 set forth above, as they are rejected based on the same rationale.
Claim 4 is rejected under 35 U.S.C. 103(a) as being disclosed by Stoller in view of Lemsitzer/ Hotchkies/ Wagenaar/Schaad, as applied to claim 1, and further in view of Hill et al. (US PGPUB 2021/0304120 hereinafter referred to as Hill).
As per dependent claim 4, Lemsitzer/ Hotchkies discloses the computer program product of claim 1.
Lemsitzer/ Hotchkies does not appear to explicitly disclose perform a validation of the content portion with respect to stored validation parameters; and detect the prefetch trigger, based on the validation.
However, Hill discloses perform a validation of the content portion with respect to stored validation parameters; and detect the prefetch trigger, based on the validation [(Paragraphs 0010; FIGs. 1-3) where the detect that a threshold amount of time has passed since resource tracking data has been received or detect that an triggering event has occurred based on validated data records; and trigger the resource tracking system to compile a report for validated data for one or more of the multiple resources to correspond to the claimed limitation].
Lemsitzer/ Hotchkies and Hill are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer/ Hotchkies and Hill before him or her, to modify the method of Lemsitzer/ Hotchkies to include the validation of Hill because it will enhance data access.
The motivation for doing so would be [“efficient and error-free way to conduct the inventory assessment process” (Paragraph 0002 by Hill)].
Therefore, it would have been obvious to combine Lemsitzer/ Hotchkies and Hill to obtain the invention as specified in the instant claim.
Claim 5 is rejected under 35 U.S.C. 103(a) as being disclosed by Stoller in view of Lemsitzer/ Hotchkies/ Wagenaar/Schaad, as applied to claim 1, and further in view of Cha et al. (US PGPUB 2013/0229945 hereinafter referred to as Cha).
As per dependent claim 5, Lemsitzer/ Hotchkies discloses the computer program product of claim 1.
Lemsitzer/ Hotchkies does not appear to explicitly disclose classify the content portion as having a type; and select the search server, based on the type.
However, Cha discloses classify the content portion as having a type; and select the search server, based on the type [(Paragraphs 0063; FIGs. 1 and 8A) where the subordinate MCD is provisioned by the dispatcher with a content access profile that is based upon transport mechanism type, 800A, similar to 500A of FIG. 5A or 700 of FIG. 7. The content access profile provisioned at 800A includes both (i) the proxy server selection criteria based on transport mechanism type as in the content access profile of 500A of FIG. 5A to correspond to the claimed limitation].
Lemsitzer/ Hotchkies and Cha are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer/ Hotchkies and Cha before him or her, to modify the method of Lemsitzer/ Hotchkies to include the server selection of Cha because it will enhance data access.
The motivation for doing so would be [“to provide different degrees of support for Internet-based services to the SMCD” (Paragraph 0007 by Cha)].
Therefore, it would have been obvious to combine Lemsitzer/ Hotchkies and Cha to obtain the invention as specified in the instant claim.
Claim 6 is rejected under 35 U.S.C. 103(a) as being disclosed by Stoller in view of Lemsitzer/ Hotchkies/ Wagenaar/Schaad, as applied to claim 1, and further in view of Trepetin et al. (US 12,045,364 hereinafter referred to as Trepetin).
As per dependent claim 6, Lemsitzer/ Hotchkies discloses the computer program product of claim 1.
Lemsitzer/ Hotchkies does not appear to explicitly disclose determine a search parameter associated with the content portion; encrypt the search parameter to obtain an encrypted search parameter; and transmit the encrypted search parameter with the encrypted content portion to the search server to obtain the encrypted search results based thereon.
However, Trepetin discloses determine a search parameter associated with the content portion; encrypt the search parameter to obtain an encrypted search parameter; and transmit the encrypted search parameter with the encrypted content portion to the search server to obtain the encrypted search results based thereon [(Column 163, lines 1-40) where, during initial message processing, we traverse the message once more to find all cases when there are special characters immediately in front of or behind words. We see in our sentence we have one instance where there is a period at the end of a word, i.e. “singing.” (e.g., at end of sentence). We remove the period from the word and place its position into the prefix area—along with the label of the special character (“period”) that was removed. Here is an example of the overall construct now: Prefix area: CAPITAL LETTERS AT INDICES. We will see in step B.i below how to use the above construct do search when the search sub-system ignores leading or trailing special characters in words. Finally we deterministically encrypt each of the components in the prefix area, along with all the individual words of the message, on the client—and send the full construct to the server. The bellow is an illustration of the encrypted construct, using E( )to designate the deterministic encryption function: E(Prefix area:) E(CAPITAL LETTERS AT INDICES: 1) E(WORDS WITHOUT SPECIAL ENDINGS:) E(wa) E(sing) E(START-WITH SUBSTRINGS:) E(b) E(bi) E(bil) E(w) E(wa) E(s) E(si) E(sin) E(sing) E(singi) E(singin) E(SPECIAL CHARACTERS:) E(PERIOD AT INDICES: 17) E(Message:) E(bill) E(was) E(singing). (Note that, if needed, we can have further special or unique leading letters or symbols for each of the main sections above so that an encrypted search argument only finds actual message data rather than for example accidentally finding the encrypted meta-data to correspond to the claimed limitation].
Lemsitzer/ Hotchkies and Trepetin are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer/ Hotchkies and Trepetin before him or her, to modify the method of Lemsitzer/ Hotchkies to include the encryption of metadata of Trepetin because it will enhance database search/access.
The motivation for doing so would be [“allows the querying of anonymized electronic databases while obtaining the same results as if performing the queries against the original, unencrypted data with little actual impact to query speed is provided” (Column 2, lines 19-23 by Trepetin)].
Therefore, it would have been obvious to combine Lemsitzer/ Hotchkies and Trepetin to obtain the invention as specified in the instant claim.
Claims 7-10, 16-17 are rejected under 35 U.S.C. 103(a) as being disclosed by Stoller in view of Lemsitzer/ Hotchkies/ Wagenaar/Schaad, as applied to claims 1 and 11, and further in view of Lahav et al. (US PGPUB 2019/0384931 hereinafter referred to as Lahav).
As per dependent claim 7, Lemsitzer/ Hotchkies discloses the computer program product of claim 1.
Lemsitzer/ Hotchkies does not appear to explicitly disclose receive the search request after receipt of the encrypted search results.
However, Lahav discloses receive the search request after receipt of the encrypted search results [(Paragraphs 0125, 0185 and 0205) where the storage front-end controller 171 is applied to facilitate and control the connection between the service application 170 and the database 126. In addition to fetching and storing encrypted (data) records in the database 126, the storage front-end controller 171 is adapted to search the encrypted records. As such, the storage front-end controller 171 may support searching for a match of one or more features, for example, an expression, a character, a string of characters, a sub-string of characters, a symbol, a value, a numeric value and/or the like in the encrypted records of the database 126. Each feature may be represented by a respective bit sequence. The slow searcher 182 may further issue a fetch request comprising the record identifier(s) of the matching encrypted record(s) for fetching the matching encrypted record(s) to correspond to the claimed limitation].
Lemsitzer/ Hotchkies and Lahav are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer/ Hotchkies and Lahav before him or her, to modify the method of Lemsitzer/ Hotchkies to include the fetching of encrypted record of Lahav because it will enhance data access.
The motivation for doing so would be [“to improve overall response time for searching a database such as the database 126” (Paragraph 0200 by Lahav)].
Therefore, it would have been obvious to combine Lemsitzer/ Hotchkies and Lahav to obtain the invention as specified in the instant claim.
As per dependent claim 8, Lahav discloses receive the search request after the detecting of the prefetch trigger and prior to receipt of the encrypted search results [(Paragraphs 0025, 0125, 0166, 0185 and 0205-0206) where the record fetcher such as the record fetcher 176 may receive the fetch request for fetching one or more of the encrypted records from the database 126. The record fetcher 76 may retrieve one or more encrypted records each comprising a record key and one or more ciphertext values. The record fetcher 176 may generate a download wrapper for each of the encrypted records based on the record key and on the ciphertext value(s) of the encrypted record, The record fetcher 176 may include an identifier in the download wrapper, for example a prefix string, a prefix string and a suffix string and/or the like. The record fetcher 176 may output the download wrapper. For example, the record fetcher 176 may output (provide or transmit) the encrypted record(s) and their associated download wrapper(s) to the client device 102 which issued the query to the unified searcher. A decryptor such as the decryptor 162 of the querying client device 102 may receive, from the record fetcher 176, the download wrapper(s) and may extract and a decryption key from each of the download wrappers. The decryptor 162 may decrypt the ciphertext value(s) included in the downloaded wrapper using the decryption key to obtain the respective plain-text value(s) to correspond to the claimed limitation].
As per dependent claim 9, Lahav discloses pre-render the decrypted search results, prior to receipt of the search request [(Paragraphs 0025, 0125, 0166, 0185 and 0205-0206) where the record fetcher such as the record fetcher 176 may receive the fetch request for fetching one or more of the encrypted records from the database 126. The record fetcher 76 may retrieve one or more encrypted records each comprising a record key and one or more ciphertext values. The record fetcher 176 may generate a download wrapper for each of the encrypted records based on the record key and on the ciphertext value(s) of the encrypted record, The record fetcher 176 may include an identifier in the download wrapper, for example a prefix string, a prefix string and a suffix string and/or the like. The record fetcher 176 may output the download wrapper. For example, the record fetcher 176 may output (provide or transmit) the encrypted record(s) and their associated download wrapper(s) to the client device 102 which issued the query to the unified searcher. A decryptor such as the decryptor 162 of the querying client device 102 may receive, from the record fetcher 176, the download wrapper(s) and may extract and a decryption key from each of the download wrappers. The decryptor 162 may decrypt the ciphertext value(s) included in the downloaded wrapper using the decryption key to obtain the respective plain-text value(s) to correspond to the claimed limitation].
As per dependent claim 10, Lahav discloses select the decrypted search results from among previously-prefetched search results, based on the search request [(Paragraphs 0025, 0125, 0166, 0185 and 0205-0206) where the storage front-end controller 171 is applied to facilitate and control the connection between the service application 170 and the database 126. In addition to fetching and storing encrypted (data) records in the database 126, the storage front-end controller 171 is adapted to search the encrypted records. As such, the storage front-end controller 171 may support searching for a match of one or more features, for example, an expression, a character, a string of characters, a sub-string of characters, a symbol, a value, a numeric value and/or the like in the encrypted records of the database 126. Each feature may be represented by a respective bit sequence. The slow searcher 182 may further issue a fetch request comprising the record identifier(s) of the matching encrypted record(s) for fetching the matching encrypted record(s) to correspond to the claimed limitation].
As for dependent claim 16, the applicant is directed to the rejections to claim 9 set forth above, as they are rejected based on the same rationale.
As for dependent claim 17, the applicant is directed to the rejections to claim 10 set forth above, as they are rejected based on the same rationale.
Claims 14 and 15 are rejected under 35 U.S.C. 103(a) as being disclosed by Stoller in view of Lemsitzer/ Hotchkies/ Wagenaar/Schaad, as applied to claim 1, and further in view of Thumparthy et al. (US PGPUB 2022/0094520 hereinafter referred to as Thumparthy).
As per dependent claim 14, Lemsitzer/ Hotchkies discloses the computer program product of claim 1.
Lemsitzer/ Hotchkies does not appear to explicitly disclose wherein encrypting the content portion includes encrypting the content portion using a homomorphic encryption scheme, and the encrypted search results are an output of homomorphic mathematical operations performed on the encrypted content portion.
However, Thumparthy discloses wherein encrypting the content portion includes encrypting the content portion using a homomorphic encryption scheme, and the encrypted search results are an output of homomorphic mathematical operations performed on the encrypted content portion [(Paragraphs 0041-0045 and 0129-0135) where, Homomorphic encryption (“HE”) is now explained in FIG. 4 in more detail. Not all encryption schemes are homomorphic. Those that are homomorphic and desirable for use in the proposed system include the Brakerski-Gentry-Vaikuntanathan (BGV) scheme, the Gentry-Sahay-Waters (GSW) scheme and the Brakerski/Fan-Vercauteren (BFV) scheme, although any homomorphic encryption scheme that supports ciphertext packing (in particular for matrix multiplication) may also be used. As shown in the communicative diagram of FIG. 4, a certain data item m is given in plaintext in plain text domain PD. The data item m may be subjected to a certain operation f to obtain (4) a result in plain text f(m) in the plain text domain PD. Operation f may for instance be an arithmetical operation, such as multiplication or addition or a combination of those to form linear combinations, in particular a dot product operation, or a matrix multiplication, etc. “Homomorphic” encryption means that the encryption operation enc(.) respects or supports the plain text operation f. That is, the same result f(m) can be achieved by first encrypting (1) m to obtain ciphertext enc(m) in ciphertext domain CD, applying (2) a corresponding homomorphic operation F there to obtain a result F(enc(f(m))) in ciphertext domain, and to then decrypting (3) that result to recover the earlier plaintext result f(m). The exact nature and functioning of the corresponding ciphertext domain operation F will depend on i) operation f and ii) the particular homomorphic encryption algorithm. For example, as will be explained in more detail, the plaintext operation includes matrix multiplication and the encryption implemented by encryptor ENC is preferably chosen to support this operation f. The above mentioned encryption schemes BGV, GSW, BFV and variants thereof (in particular those that are based on the Learning With Errors (LWE) problem) are suitable to support matrix multiplication, linear combinations etc, and give rise to a suitable counterpart ciphertext domain operator F to correspond to the claimed limitation].
Lemsitzer/ Hotchkies and Thumparthy are analogous art because they are from the same field of endeavor of data storage management.
Before the effective filing date of the claimed inventions, it would have been obvious to one of ordinary skill in the art, having the teachings of Lemsitzer/ Hotchkies and Thumparthy before him or her, to modify the method of Lemsitzer/ Hotchkies to include the encryption schemas of Thumparthy because it will enhance database search/access.
The motivation for doing so would be [“need for improved handling of encrypted data” (Paragraph 0010 by Thumparthy)].
Therefore, it would have been obvious to combine Lemsitzer/ Hotchkies and Thumparthy to obtain the invention as specified in the instant claim.
As per dependent claim 15, Thumparthy discloses wherein the encrypted search results are an output of a matrix multiplication of the encrypted content portion against encrypted search data [(Paragraphs 0041-0045 and 0129-0135) where, Homomorphic encryption (“HE”) is now explained in FIG. 4 in more detail. Not all encryption schemes are homomorphic. Those that are homomorphic and desirable for use in the proposed system include the Brakerski-Gentry-Vaikuntanathan (BGV) scheme, the Gentry-Sahay-Waters (GSW) scheme and the Brakerski/Fan-Vercauteren (BFV) scheme, although any homomorphic encryption scheme that supports ciphertext packing (in particular for matrix multiplication) may also be used. As shown in the communicative diagram of FIG. 4, a certain data item m is given in plaintext in plain text domain PD. The data item m may be subjected to a certain operation f to obtain (4) a result in plain text f(m) in the plain text domain PD. Operation f may for instance be an arithmetical operation, such as multiplication or addition or a combination of those to form linear combinations, in particular a dot product operation, or a matrix multiplication, etc. “Homomorphic” encryption means that the encryption operation enc(.) respects or supports the plain text operation f. That is, the same result f(m) can be achieved by first encrypting (1) m to obtain ciphertext enc(m) in ciphertext domain CD, applying (2) a corresponding homomorphic operation F there to obtain a result F(enc(f(m))) in ciphertext domain, and to then decrypting (3) that result to recover the earlier plaintext result f(m). The exact nature and functioning of the corresponding ciphertext domain operation F will depend on i) operation f and ii) the particular homomorphic encryption algorithm. For example, as will be explained in more detail, the plaintext operation includes matrix multiplication and the encryption implemented by encryptor ENC is preferably chosen to support this operation f. The above mentioned encryption schemes BGV, GSW, BFV and variants thereof (in particular those that are based on the Learning With Errors (LWE) problem) are suitable to support matrix multiplication, linear combinations etc, and give rise to a suitable counterpart ciphertext domain operator F to correspond to the claimed limitation].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 extension fee 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 Mohamed Gebril whose telephone number is (571)270-1857 and email address is mohamed.gebril @uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am-5:00pm.ALT. Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jared Rutz can be reached on 571-272-5535. The fax phone number for the organization where this application or proceeding is assigned is 571-270-2857.
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.
/MOHAMED M GEBRIL/Primary Examiner, Art Unit 2135
