DETAILED ACTION
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 action is responsive to Applicant’s Amendment filed on 3/3/2026.
Claims 1-3, 5-8, 10-20 and 22-24 are presented for examination. Claims 1, 3, 7-8, 10-15, 17 and 22-24 have been amended.
Applicant’s amendments to the claims have overcome 112 rejections set forth in the non-Final Office Action mailed 12/2/2025.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 12 and 23 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding to claim 12, the meaning of “a token value” at line 4 is not clear. Claim 12 depends on claim 8 and claim 8 already includes “a tokenization value”. It is not clear that whether “a tokenization value” from claim 8 is same or different value from “a token value” from claim 12. For the purpose of examination, examiner interprets “a token value” from claim 12 as: the tokenization value.
Regarding to claim 23, claim 23 is rejected under the same reason set forth in the rejection of claim 12 above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 3, 6-8, 12, 14, 15, 17 and 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Rawalkshatriya et al. (US 20200280547 A1, hereafter Rawalkshatriya) in view of Vogel et al. (US 20080216174 A1, hereafter Vogel), Dutta (US 20150324592 A1), Jarlstrom et al. (US 9268947 B1, hereafter Jarlstrom), Masi et al. (US 20190068687 A1, hereafter Masi) and Wada et al. (JPH10177531A, hereafter Wada. English translated provided by Google Patents).
Rawalkshatriya, Vogel, Dutta, Masi and Wada were cited on the previous office action.
Regarding to Claim 1, Rawalkshatriya discloses: An apparatus (see Figs. 1, 2, 5; “user device 102”), comprising:
a processing circuit (see Fig. 2 and [0026]; “The plurality of user devices 102 a-102 n can include one or more processors”); and
logic stored in computer memory and executed on the processing circuit, the logic operative to cause the processing circuit (see Fig. 2 and [0026]; “The plurality of user devices 102 a-102 n can include one or more processors, a memory” and “the plurality of user devices 102 a-102 n can be configured to encrypt the data objects using the encrypt function of the PRE and upload the encrypted data objects to the at least one cloud device 106 a-106 n”. It is understood to one with ordinary skill in the art that a user device as shown on Fig. 2 and described by [0026] should utilize logic or code stored in the memory and executed on the processor to cause the processor to execute the functionalities or features written on the logic or code) to:
access configuration information associated with migrating file data to a cloud storage service over a network, the configuration information comprising settings directed towards storing the file data in a storage location of the cloud storage service (see Fig. 2, [0032] and [0037]; “the key generation module 202 generates a random master secret key (MSK)” and “The encryption module 204 can be configured to encrypt the data objects when the user device 102 wants to upload the data objects to the at least one cloud device 106 a-106 n. For encrypting the data objects, the encryption module 204 derives a file encryption key (FEK) using the MSK”. Accessing certain configuration information containing the MSK information associated with migrating the data objects of user devices to a cloud device, such MSK information is certain settings used for encrypting such data objects to be stored to the cloud storage device, and thus it is reasonable to consider such MSK information as one of the claimed settings directed towards storing the file data in the cloud storage service);
convert the file data into a migration dataset in accordance with the settings in the configuration information, wherein the configuration information includes at least an address directing a first server to the storage location (see Figs. 2, 5, [0023], [0032] and [0037]; “Examples of the data objects/content/data can be, but not limited to, files, content of files, text/messages, documents, media files (audio files, image files, video files or the like) and so on” and “The encryption module 204 can be configured to encrypt the data objects when the user device 102 wants to upload the data objects to the at least one cloud device 106 a-106 n. For encrypting the data objects, the encryption module 204 derives a file encryption key (FEK) using the MSK”. Encrypting the data objects to be uploaded to one of the cloud devices into encrypted data objects in accordance with the MSK information, i.e., claimed converting; in addition, in order to allow the system to upload the encrypted data objects to one of the cloud devices, the system is required to access the address information of the cloud devices, i.e., claimed the configuration information includes at least an address);
the logic including instructions to use the settings to modify one or more second portions of the file data to ensure that [the script] successfully loads the migrations dataset into the cloud storage service (see the rejection and explanation to the converting limitation above. Such “modify one or more second portions of the file data” is broad and can be interpreted as the claimed converting limitation above; in addition, the converting limitation above is one of the steps/actions performed to load the migrations database into the cloud storage server, and thus the logic performs such converting step/action in accordance with the settings inherently means “the logic including instructions to use the settings to modify one or more second portions of the file data to ensure successfully loads the migrations dataset into the cloud storage service”);
Note: claimed “one or more second portions of the file data” is also a very broad limitation that can be interpreted as the whole claimed file data including the claimed “a first portion of the file having sensitive information.
communicate [the script and] the migration dataset in a control directive sent to the first server associated with the cloud storage service, the first server configured to [execute the script and] store the migration dataset in the storage location in accordance with the settings in the configuration information (see Figs. 1, 5 and [0084]-[0085]; “The re-encryption module 304 re-encrypts the encrypted data objects of the user device 102 c with the re-key (the re-key from the user device 102 c to the user device 102 b) received from the user device 102 c. The re-encrypted data object(s) can be pushed to the at least one cloud device 106 a-106 n preferred/selected by the user device 102 b”).
Rawalkshatriya does not discloses:
the configuration information comprising settings directed towards including identifying a byte address indicating a location of a first portion of the file data having sensitive information;
wherein the settings include a compression scheme for compressing the file data and a tokenization value;
apply a tokenization mechanism, using the tokenization value and in accordance with the settings n the configuration information, to tokenize sensitive information of a first portion of the migration dataset corresponding to the first portion of the file data, the settings in the configuration information including instructions for which tokenization mechanism to use to tokenize the first portion of the migration dataset;
generate a script having operations for directing the first server how or where to store the migration dataset, as tokenized, in the cloud storage service, the script being generated based upon the settings in the configuration information,
ensure that the script successfully loads the migration dataset, as tokenized; and
communicate the script and the migration dataset, as tokenized, in the control directive sent to the first server, the first server configured to execute the script and store the migration dataset, as tokenized.
However, Vogel discloses: access configuration information associated with migrating file data to a storage service over a network, the configuration information comprising settings directed towards including a byte address indicating a location of a first portion of the file having sensitive information; apply a data security mechanism, in accordance with the settings in the configuration information to modify sensitive information of a first portion of the file data (see [0031], [0061] and [0071]-[0072]; “sending the collected data from the client to a server via a network. In another embodiment, the collected data may include a modified version of the identified sensitive data. As used herein, a modified version of data is a version of the data that is changed such that it still indicates the data without disclosing the data in full, and includes a version of the data that has been masked, redacted, truncated, and/or encrypted”, “metadata for each given data file in which an element and/or instance of sensitive data is identified … data about each element and/or instance of sensitive data identified on the client station 14, such as a location of each identified sensitive data element/instance (e.g., a location within a given data file such as a line number, a position in terms of bytes, a memory address, a cell indicator in a spreadsheet, etc.), a type of each identified sensitive data element/instance (e.g., PAN data, magnetic stripe data, SSN, etc.), and/or a version of each identified sensitive data element/instance itself, which may be modified (e.g., masked, redacted, truncated, encrypted, etc.)”, “As a result of identifying sensitive data stored in data storage (and collecting data thereon), the scanner may also cause the client station 14 to carry out preventive measures based on the identified sensitive data. For example, the scanner may cause the client station 14 to modify the identified sensitive data stored in the data storage … after collecting the data based on the identified sensitive data (and optionally performing other operations as described above), the scanner may cause the client station 14 to report the collected data, preferably to the sensitive data server 12. In this respect, the scanner will preferably cause the client station 14 to send the collected data (or a portion thereof) to the sensitive data server 12 via the network 16 in either encrypted or unencrypted form”, emphasis added. Also see [0024]; “Data may be organized into various forms, including data elements, data instances, and/or data files”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the encryption process on the data to be uploaded to the remote cloud location from Rawalkshatriya by including processes scanning sensitive information within a file or data for modifying the sensitive information and sending the modified file to remote server from Vogel, since it is well-known and understood sensitive information should be modified for security purpose (see [0003]-[0004] from Vogel; “it would be desirable to have a scanner that performs various functions in response to identifying sensitive data on a system component, such as alerting the user and/or owner of the system component or modifying the sensitive data”).
In addition, Dutta discloses:
wherein the settings of configuration information associated with migrating file data to a cloud storage service include a compression scheme for compressing the file data (see [0050] and [0055]; “In accordance with one embodiment, any suitable data storage technique may be utilized to store data … using data sets stored in individual files using a hierarchical filing system; data sets stored as records in a single file (including compression … and/or other proprietary techniques that may include fractal compression methods, image compression methods” and “for security reasons, any databases, systems, devices, servers or other components of the system may consist of any combination thereof at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, decryption, compression, decompression, and/or the like”. Also see [0002] and [0025]; “a user of a web-client 102 may upload the document to a cloud application 106 residing within a cloud computing environment and/or a gateway 104 (step 202A)”. At one of the reasonable embodiments, before the file data to be uploaded to cloud storage location or cloud application (no matter when the file data is located or stored at the web-client 102 or gateway 104), the storage or database of such file data would include certain configuration information having settings to include compression scheme (at least compression scheme of fractal compression methods) for compressing any of the file data stored) and a tokenization value (see [0004], [0014]; “encrypting sensitive data, generating a token comprising a data identifier, tokenizing the encrypted sensitive data, and/or storing the encrypted sensitive data in association with the token to a token vault”, “Data may likewise be tokenized by associating an identifier or “token” with the data. A token may, in various embodiments, comprise a random number, which may be associated with the data”);
apply a tokenization mechanism, using the tokenization value and in accordance with the settings in the configuration information, to tokenize sensitive information of a first portion of the migration dataset corresponding to the first portion of the file data (see [0004]; “encrypting sensitive data, generating a token comprising a data identifier, tokenizing the encrypted sensitive data, and/or storing the encrypted sensitive data in association with the token to a token vault”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the data security modification operations performed on data having sensitive information from the combination of Rawalkshatriya and Vogel by including method of compressing file data and applying tokenization mechanism on encrypted sensitive data from Dutta, and thus the combination of Rawalkshatriya, Vogel and Dutta would disclose limitations related to compression scheme and part of applying the tokenization mechanism (note: Dutta alone may only discuss tokenizing the encrypted sensitive data; however, the combination of Rawalkshatriya and Vogel already discloses feature of encrypted file data having sensitive data that the sensitive data identified by settings of configuration information associated with the file data, and thus after combining teachings/feature from Dutta into the combination of Rawlkshatrya and Vogel, the new combination system would disclose feature of tokenizing the portion of encrypted file data, i.e., claimed migration dataset, having sensitive information based on the settings in the configuration information that are used to identify the sensitive data in the file data or encrypted file data), since it provides higher security on sensitive information via both of encryption mechanism and tokenization mechanism on the sensitive information (see [0003]-[0004] from Dutta; “various enterprises have stored unencrypted documents and/or data to a local data storage system (e.g., a token vault or file system) through the use of a tokenization system … Disadvantages exist here as well … encrypting sensitive data, generating a token comprising a data identifier, tokenizing the encrypted sensitive data, and/or storing the encrypted sensitive data in association with the token to a token vault”) and compression is well-known and understood technique to be performed on data at the storage fields (see [0050] and [0055] from Dutta; “Data sets may be stored using any suitable technique, including, for example … data sets stored as records in a single file (including compression, SQL accessible, hashed via one or more keys, numeric, alphabetical by first tuple, etc.) … and/or other proprietary techniques that may include fractal compression methods, image compression methods” and “wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, decryption, compression, decompression, and/or the like”).
In addition, Jarlstrom discloses: apply a tokenization mechanism, using the tokenization value and in accordance with the settings in the configuration information, to tokenize sensitive information of a first portion of the dataset, the settings in the configuration information including instructions for which tokenization mechanism to use to tokenize the first portion of the dataset (see lines 33-41 of col. 7; “Status of the data stores containing the sensitive information may indicate measures adopted to protect the sensitive information and the type of encryption or masking, if any, used to protect the sensitive information”. At least the status or metadata of the data stores can be considered as the claimed configuration information having settings associated with the file having sensitive data/information, while such status or metadata would include certain instructions or information indicating the type of masking/tokenization mechanism to use to tokenize the sensitive portion. Also see, lines 4-15 of col. 3 and lines 8-29 of col. 6; “The one or more policies can be policies defined for identifying and treating sensitive data in a variety of data stores. For example, actions such as discovery, masking, encryption and quarantining of sensitive data within said data stores can be executed based on the policies defined” and “After searching the data stores to locate sensitive information, at step 108, the sensitive information may be masked. Masking of the sensitive information may be done to prevent exposure of the sensitive information and to comply with security policies such as PCI DSS, PII, and HIPAA … Masking in this case may involve replacing the original data with realistic but not real data while maintaining the format of the original data”. These policies defined for identifying and treating sensitive data can also be considered as the configuration information having settings indicating the type of masking/tokenization mechanism to use to tokenize the sensitive portion. In addition, the masking/tokenization is performed via replacing the original data with certain realistic but not real data, i.e., claimed “the tokenization value”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the configuration or metadata of the files/data having sensitive information to be tokenized from the combination of Rawalkshatriya, Vogel and Dutta by including a system that including configuration information indicating the type of encryption or masking to be performed on the identified data having sensitive information from Jarlstrom, since it would provide data storage service without potential security risk (see lines 33-41 of col. 7 from Jarlstrom. Note: although either of Vogel or Dutta also provides masking or tokenizing the sensitive data feature, the masking or tokenizing feature and/or corresponding type of masking from Vogel is actually triggered or request by client/user, see [0046]-[0047] and the masking or tokenizing feature from Dutta is performing by a gateway that functioning an intermedia between client/user and storage service, see Fig. 1B, [0018] from Dutta. Combining the feature from Jarlstrom would enhance the security of the new combination system via enabling masking/tokenizing feature at either one of the client/user domain, intermediary domain or data storage domain).
In addition, Masi discloses:
wherein the configuration information includes at least an address directing a first server to the storage location (see [0132]; “local folders F2 and F3 are mapped to the network addresses of remote computing devices 2604 and 2605, respectively” and “a custom data structure or script can be configured to transfer the contents of a local folder to a destination network address”. The mapping feature results such network address of corresponding remote computing device as configuration information of each local folders);
generate a script having operations for directing the first server how or where to store data to be migrated in the remote storage service, the script being generated based upon the settings in the configuration information; execute the script to store the data to be migrated in the storage location in accordance with the settings in the configuration information (see [0132]; “a custom data structure or script can be configured to transfer the contents of a local folder to a destination network address. The script can interface with the network connection (such as the web socket) in order to effectuate the transfer”. The script is configured or generated in a manner of transferring data to be migrated to a destination network address, and thus such script is configured or generated based on the destination network address in the configuration information of the data to be migrated; in addition, the script contains at least operations for directing a server to store the data to a destination storage via web socket, i.e., operations for directing a server how to store the data to the destination storage. Also see [0126]-[0127] and [0130]; “one or more live folders are generated by mapping the one or more local folders to the one or more IP addresses”. Although [0126]-[0127] and [0130] does not exactly specify a script contains operations to direct the server to store/transfer the local folders to the destination storage/location, based on [0126]-[0127] and [0130], it is reasonable to one with ordinary skill in the art to conclude the script discussed at [0132] at Masi invention would transfer the contents of a local folder to a destination network address based on the IP address of the destination network address, and thus this script discussed at [0132] contains operations for directing a server where to store the data or local folders).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the function/process of pushing or transferring the encrypted and then tokenized data object to one of the cloud storage devices from the combination of Rawalkshatriya, Vogel, Dutta and Jarlstrom by including mechanism of utilizing a script to transfer data to a specified destination network address from Masi, and thus the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom and Masi would disclose limitations of “the logic including instructions to use the settings to modify one or more second portions of the file data to ensure that the script successfully loads the migration data set into the cloud storage service” (note: At the new combination system, the system would perform a tokenization mechanism to tokenize or replacing the sensitive portions of encrypted file data, i.e., migration dataset version of the file or file data to be migrated/uploaded to cloud storage location based on the configuration information/settings of the file or file data, then generate a script having instructions to migrate or upload the encrypted and tokenized file or file data, i.e., claimed “the migration dataset, as tokenized” to the cloud storage location in a manner of the migrated/uploaded file or file data that the script handle encrypted and tokenized file or file data, and thus it is to “use the settings (of the configuration information associated with the file or file data to be migrated/uploaded) to modify portions of the file data to ensure that the script successfully loads the migration data set into the cloud storage service”), since a script is well-known and understood mechanism to one with ordinary skill in the art to perform certain computing tasks automatically without human intervention.
Furthermore, Wada discloses:
generate a script having operations for directing the first server how or where to store data in [cloud] storage service, communicate the script and the data in a control directive sent to the first server associated with the [cloud] storage service, the first server configured to execute the script and store the data in the storage location (see Figs. 1-2, [0021]-[0022]; “a script execution device 1 includes a script execution engine unit 2 that interprets and executes a script, a script reception unit 3 that receives a script from another terminal or a server via a network”, “The script receiving unit 3 of the script execution device 1 receives a script program via a network (S1)” and “When the multimedia data is also received, the multimedia data may be stored in the script program storage unit 4 or stored in a storage device such as an internal memory or an external disk that can be referred to by the script execution engine unit 2”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the generation and execution processes of a script performing a data handling task from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom and Masi by including the mechanism of generating and executing a script at two different computing devices from Wada, and thus the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada would disclose the missing limitations from Rawalkshatriya (note: the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom and Masi already discloses generating a script and executing the script to store the migration dataset to a cloud storage, and thus all missing from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom and Masi is whether it is known to communicate to another server the generated script for the another server to execute the script. Wada provides such mechanism, i.e., the device to generate a script and the device to execute the generated script can be two different devices), since it is well-known and understood to one of ordinary skill in the art that utilizing different devices perform two different functionalities to reduce workloads of the devices.
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: wherein the first server is a dedicated proxy server of the cloud storage service (see Figs. 1, 5 and [0084]-[0085] from Rawalkshatriya; “The re-encryption module 304 re-encrypts the encrypted data objects of the user device 102 c with the re-key (the re-key from the user device 102 c to the user device 102 b) received from the user device 102 c. The re-encrypted data object(s) can be pushed to the at least one cloud device 106 a-106 n preferred/selected by the user device 102 b”. Also see [0132] from Masi and Figs. 1-2, [0021]-[0022] from Wada. At the combination system, the script generated by user device is provided to the dedicated proxy/key server for uploading the encrypted data object to one of the destination network addresses hosted by the cloud devices).
Regarding to Claim 6, the rejection of Claim 1 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: comprising logic operative to cause the processing circuit to convert the file data according to an encoding format, the encoding format being based upon the settings in the configuration information (see Fig. 2, [0032] and [0037] from Rawalkshatriya; “the key generation module 202 generates a random master secret key (MSK)” and “The encryption module 204 can be configured to encrypt the data objects when the user device 102 wants to upload the data objects to the at least one cloud device 106 a-106 n. For encrypting the data objects, the encryption module 204 derives a file encryption key (FEK) using the MSK”. The file data or the data objects are encrypted, i.e., encoding, according to the format using the MSK information).
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: comprising logic operative to cause the processing circuit to access the settings comprising information to identify the sensitive information within the file data (see [0061] and [0071]-[0072] from Vogel; “data about each element and/or instance of sensitive data identified on the client station 14, such as a location of each identified sensitive data element/instance (e.g., a location within a given data file such as a line number, a position in terms of bytes, a memory address, a cell indicator in a spreadsheet, etc.), a type of each identified sensitive data element/instance (e.g., PAN data, magnetic stripe data, SSN, etc.), and/or a version of each identified sensitive data element/instance itself, which may be modified (e.g., masked, redacted, truncated, encrypted, etc.)”, “As a result of identifying sensitive data stored in data storage (and collecting data thereon), the scanner may also cause the client station 14 to carry out preventive measures based on the identified sensitive data).
Regarding to Claim 8, Claim 8 and is rejected for the same reason set forth in the rejections of Claim 1 above.
Regarding to Claim 12, the rejection of Claim 8 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: wherein the first portion of the migration dataset comprises a bank account number, and wherein applying the tokenization mechanism includes replacing the first portion of the migration dataset with a token value (see [0027] from Vogel, [0004] from Dutta and lines 45-47 of col. 6 from Jarlstrom; “sensitive data is data that represents sensitive information … the sensitive data described herein may include financial data and personal identification data … financial data may include bank account data such as routing number and/or account number data”, “generating a token comprising a data identifier, tokenizing the encrypted sensitive data” and “replacing the original data with realistic but not real data while maintaining the format of the original data”).
Regarding to Claim 14, the rejection of Claim 8 is incorporated and further the combination of combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: wherein the sensitive information of the migration dataset to tokenize is within a database record (see [0024], [0061] from Vogel and [0004] from Dutta; “Data may be organized into various forms … a data instance is a group of related data elements, such as a line of related data elements in a database”, “the collected data may include data about each element and/or instance of sensitive data identified on the client station 14, such as a location of each identified sensitive data element/instance (e.g., a location within a given data file such as a line number, a position in terms of bytes, a memory address, a cell indicator in a spreadsheet, etc.)” and “a modified version of the identified sensitive data. As used herein, a modified version of data is a version of the data that is changed such that it still indicates the data without disclosing the data in full, and includes a version of the data that has been masked, redacted, truncated, and/or encrypted” and “tokenizing the encrypted sensitive data, and/or storing the encrypted sensitive data in association with the token to a token vault”. At the combination system, the identifying sensitive information to be tokenized also comprises identifying such sensitive information within a database record/range).
Regarding to Claim 15, Claim 15 is rejected for the same reason set forth in the rejections of Claim 1 above (note: the claimed data model here is a very broad term, the claim here only requires “a data model for storing the file data in the cloud storage while [0037] from Applicant’s specification describes claimed data model as “a data model identifying a structure of the file data 210”, and thus many different metadata described from [0024] of Vogel can be reasonable to be mapped to such claimed data model, such as, “an identifier of the data file (e.g., name of the binary file)”, “a type of the data file (e.g., program file, text file, etc.)”, “a location of the data file in data storage (e.g., a file path)” or “a size of the data file for instance”. Also see [0120] from Rawalkshatriya or [0064] from Dutta for claimed “computer-readable storage medium”).
Regarding to Claim 17, claim 17 is rejected for the same reason set forth in the rejections of Claim 3 above.
Regarding to Claim 22, the rejection of Claim 8 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: wherein the settings specify an encryption scheme for encrypting the file data for the migration dataset (see Fig. 2, [0032] and [0037] from Rawalkshatriya; “the key generation module 202 generates a random master secret key (MSK)” and “The encryption module 204 can be configured to encrypt the data objects when the user device 102 wants to upload the data objects to the at least one cloud device 106 a-106 n. For encrypting the data objects, the encryption module 204 derives a file encryption key (FEK) using the MSK”. This MSK information is considered as claimed encryption scheme for encrypting the file data to be uploaded or stored to the cloud storage device).
Regarding to Claim 23, claim 23 is rejected for the same reason set forth in the rejections of Claim 12 above.
Regarding to Claim 24, claim 24 is rejected for the same reason set forth in the rejections of Claim 14 above.
Claims 2, 10-11 and 19-20 is rejected under 35 U.S.C. 103 as being unpatentable over Rawalkshatriya et al. (US 20200280547 A1, hereafter Rawalkshatriya) in view of Vogel et al. (US 20080216174 A1, hereafter Vogel), Dutta (US 20150324592 A1), Masi et al. (US 20190068687 A1, hereafter Masi) and Wada et al. (JPH10177531A, hereafter Wada. English translated provided by Google Patents) and further in view of Iijima et al. (US 20200387387 A1, hereafter Iijima).
Rawalkshatriya, Vogel, Dutta, Masi, Wada, Iijima were cited on the previous office action.
Regarding to Claim 2, the rejection of Claim 1 is incorporated, the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: convert the file data in response to receiving the file data over the network (see [0030]-[0031] and [0060] from Vogel; “the client searching the data stored in data storage for recognizable patterns that indicate sensitive data”, “a modified version of the identified sensitive data. As used herein, a modified version of data is a version of the data that is changed such that it still indicates the data without disclosing the data in full, and includes a version of the data that has been masked, redacted, truncated, and/or encrypted” and “the client station 14 to collect data based on the identified sensitive data”, emphasis added. Also see [0025] and [0044] from Vogel; “data storage refers to one or more internal and/or external hardware components of a computing device for storing data”. The client station 14 to receive the collected data from the external data storage via the network and modify the collected data having sensitive information).
The combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada does not disclose: generate an executable pipeline based upon the settings in the configuration information and apply the executable pipeline to perform the convert operation.
However, Iijima discloses: logic operative to cause the processing circuit to generate an executable pipeline based upon the settings in the configuration information and apply the executable pipeline to perform corresponding operations (see [0008]; “automatically generates executable analytic pipelines for various execution engines based on analytical solution module metadata and user customization” and “deploys and executes analytic pipelines … on edge servers”. Also see [0042], [0050] and [0062]; “the standard description of the analytical operators and data pipeline (e.g., data flow) used”, “Flow Definition describes how to connect and integrate multiple operators in a pipeline or iteration” and “The Flow Wrapper Code Generator 207 generates the wrapper code for flow pipelining that can be executed on the targeted analytic platform”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of encryption module from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada by including mechanism of implementing data operation task by executable pipeline from Iijima, and thus the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi, Wada and Iijima would disclose the missing limitations from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada, since executable pipeline is a well-known and understood implementation for executing a sequence of computing processes to be executed in parallel that the output stream of one process can be automatically fed as the input stream of the next one at the computing fields.
Regarding to claim 10, claim 10 is rejected for the same reason set forth in the rejections of Claim 2 above.
Regarding to Claim 11, the rejection of Claim 10 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi, Wada and Iijima discloses: comprising adding or removing computing modules to the executable pipeline (see [0007]-[0008] from Iijima; “(1) automatically generate customizable analytical solution module templates; (2) generate deployable analytical solution modules after instantiations” and “a system that automatically generates executable analytic pipelines for various execution engines based on analytical solution module metadata and user customization; (2) standard interfaces and protocols to bridge all pieces of work done by multiple roles in the development of industrial analytical applications; (3) a system that manages, deploys and executes analytic pipelines on cloud or edge servers”. If a system implementing the software module via executable pipelines, then the execution of the software module would inherently include adding the software module(s) to the executable pipeline for proper executions).
Regarding to Claim 19, Claim 19 is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 20, Claim 20 is rejected for the same reason set forth in the rejection of Claim 11 above.
Claims 5, 13 and 16 is rejected under 35 U.S.C. 103 as being unpatentable over Rawalkshatriya et al. (US 20200280547 A1, hereafter Rawalkshatriya) in view of Vogel et al. (US 20080216174 A1, hereafter Vogel), Dutta (US 20150324592 A1), Masi et al. (US 20190068687 A1, hereafter Masi) and Wada et al. (JPH10177531A, hereafter Wada. English translated provided by Google Patents) and further in view of Zhou et al. (US 20200151122 A1, hereafter Zhou).
Rawalkshatriya, Vogel, Dutta, Masi, Wada and Zhou were cited on the previous office action.
Regarding to Claim 5, the rejection of Claim 1 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: comprising logic operative to cause the processing circuit to generate the script using a network address, the network address based upon the settings in the configuration information (see [0132] and [0136]-[0137] from Masi; “a custom data structure or script can be configured to transfer the contents of a local folder to a destination network address. The script can interface with the network connection (such as the web socket) in order to effectuate the transfer” and “transmit the at least one file to the network address of the remote computing device over the web socket connection (or other network connection)”. The script is configured or generated according to at least configuration information related to the destination address).
The combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada does not disclose the script is further generated using a data module corresponding to the storage location, wherein the data model delineates byte address where data items from the file data are stored in the migration dataset.
However, Zhou discloses: a process of storing a file data to a remote storage location using a data module corresponding to the storage location, wherein the data model delineates byte address where data items from the file data are stored in the file (see [0090]-[0091]; “configures the mapping relationship table between the logical address of the shared cache apparatus 104 and the destination address of the shared cache apparatus 104 for the shared cache apparatus 104”, “and store the data in the storage space to which the destination address of the shared cache apparatus 104 points” and “determines, based on the foregoing mapping relationship table that is between the logical address of the shared cache apparatus 104 and the destination address of the shared cache apparatus 104 and that is configured by the first controller 102 for the shared cache apparatus 104, an offset, relative to a start logical address, of the logical address at which the data is to be stored in the global storage space, and determines, based on the offset, the physical address at which the data is to be stored in the shared cache apparatus 104, and finally stores the data in the storage space, of the shared cache apparatus 104, to which the physical address points”. A process having operations of storing a file data to a remote storage location using a data module that specifies offset, i.e., byte address of the file data to be stored and a storage address mapping between the source system having the file data to be stored and the destination system to store the file data).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the process of script uploads file data to the cloud service storage location from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada by including the process of storing file data to a remote storage location via storage address mapping information from Zhou, and thus the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi, Wada and Zhou would disclose the missing limitation from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada, since it would provide a mechanism of allowing the system to know the storage address correspondences between the source system and destination system (see [0090]-[0091] from Zhou).
Regarding to claim 13, claim 13 is rejected for the same reason set forth in the rejections of Claim 5 above.
Regarding to Claim 16, Claim 16 is rejected for the same reason set forth in the rejection of Claim 5 above.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Rawalkshatriya et al. (US 20200280547 A1, hereafter Rawalkshatriya) in view of Vogel et al. (US 20080216174 A1, hereafter Vogel), Dutta (US 20150324592 A1), Masi et al. (US 20190068687 A1, hereafter Masi) and Wada et al. (JPH10177531A, hereafter Wada. English translated provided by Google Patents) and further in view of and further in view of Li (US 20210108972 A1).
Rawalkshatriya, Vogel, Dutta, Masi, Wada and Li were cited on the previous office action.
Regarding to Claim 18, the rejection of Claim 15 is incorporated and further the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada discloses: comprising processor-executable instructions that when executed, cause the system to: generate the script to load the data into a destination [database] (see [0132] from Masi).
The combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada does not disclose: the script is to load database records into a destination database.
However, Li discloses: a method of uploading a file to a cloud storage comprising: operations of loading database records of the file into a destination database of the cloud storage (see [0011]; “transmits the local records of the local database directly/indirectly to the cloud server and synchronizes the local records of the local database with the global records of the cloud database of the cloud server”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the process of generating a script to perform action of loading data to a destination cloud storage device from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada by including the system having module to perform action of loading local databases records to a destination cloud database from Li, and thus the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi, Wada and Li would disclose the missing limitations from the combination of Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi and Wada, since it would provide a system of transferring the source/local data object to a same type storage component to keep data consistence (see [0011] from Li).
Response to Arguments
Applicant’s arguments, filed 3/4/2026, with respect to rejections of claims 1-3, 5-8, 10-20 and 22-24 under 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 10-13 are summarized as the following:
“There is no discussion in the cited references of the settings of the configuration information for migrating the file including a tokenization value for tokenization of the sensitive data. As such, the combination of references fails to teach, suggest, or otherwise render obvious at least these features” (see last paragraph of page 11 from the Remarks).
“Applicant further respectfully submits that the use of the specific byte address within the configurations settings to drive script generation also renders the claims non-obvious in view of the cited references. In particular, Vogel and Dutta do not suggest using a byte address in the specific manner claimed above to facilitate a cloud migration process” (see 1st paragraph of page 12 from the Remarks).
“The Examiner argues that paragraphs [0002], [0025], [0050] and [0055] of Dutta discloses these features” related to “the settings including a compression scheme for compressing the file data”. “Applicant respectfully disagrees. Paragraph [0002] of Dutta is part of the background and does not discuss settings from configuration information. Likewise, paragraph [0025] of Dutta also does not discuss compression or configuration settings. While paragraphs [0050] and [0055] of Dutta mention compression in passing, there is not disclosure in these passages of configuration settings that that include a compress scheme for compressing the file data” (see 2nd paragraph of page 12 from the Remarks).
“The rejection of claim 1 relies on a complex combination of references, namely, Rawalkshatriya, Vogel, Dutta, Jarlstrom, Masi, and Wada, which are based on a combination of desperate technologies, ranging from proxy re-encryption and data scanning to web-socket scripting and tokenization. Applicant respectfully submits that no person having ordinary skill in the art would be motivated to combinate the references, as alleged by the Examiner, because doing so would require the person to look across a set of diverse fields, including combining lower-lever socket script with high-level tokenization, that are so different that they do not address or resolve the same problem. Instead, the Examiner has cited a hindsight driven mosaic of scattered elements and attempted to combine them into one single system” (see third paragraph of page 12 from the Remarks).
The examiner respectively disagrees.
For reference Dutta, [0004] and [0014] discuss there is a token value is used at the tokenization process to tokenizing encrypted sensitive information of file data, and then the system of Dutta would store such sensitive information after tokenized to certain storage location. In this way, such token value from Dutta is reasonable to be considered as “the settings of the configuration information for migrating the file including a tokenization value for tokenization of the sensitive data” as argued. Note: either settings or configuration information is broad term, any settings/data/parameters used to perform certain step/action or object correctly can be considered as settings/configuration information. The token value from [0004] and [0014] from Dutta is such type of data to perform the tokenization and later migration processes correctly. In this way, it is reasonable to consider the token value as settings of the configuration information.
In view of the current claimed language, one with ordinary skill in the art would not understand Applicant’s argument on “the use of the specific byte address within the configurations settings to drive script generation” since the current claimed invention does not require using the specific byte address to drive script generation. According to the current claimed language, the specific byte address within the configuration information is used to drive identifying sensitive information and then tokenization mechanism later; the claimed invention does not specify the specific byte address is used for the script generation (see claimed limitations “generate a script having operations for directing the first server how or where to store the migration dataset, as tokenized, in the cloud storage service, the script being generated based upon the settings in the configuration information”).
As explained at the response a) above, either settings or configuration information is broad term, any settings/data/parameters used to perform certain step/action or object correctly can be considered as settings/configuration information. [0002] and [0025] from Dutta discuss features of storing file or document to a gateway storage location before uploading such file or document to cloud storage location while there is some security operations performed on such file or document to modify such file or document at the gateway storage location. [0050] and [0055] from Dutta discuss any storage or database from the system would contain compression method or technique to perform compression operation for the data to be stored at the storage or database. In this way, the compression scheme discussed at [0050] and [0055] is reasonable to be considered to be included at the claimed settings of configuration information associated with migrating file data to a cloud storage service.
Most of the references used are related to upload local file or file data to remote/network or cloud or another storage location. Such as, [0037] from Rawalkshatriya discusses: “The encryption module 204 can be configured to encrypt the data objects when the user device 102 wants to upload the data objects to the at least one cloud device 106 a-106 n”, [0031] from Vogel discusses: “sending the collected data from the client to a server via a network. In another embodiment, the collected data may include a modified version of the identified sensitive data”; [0004] from Dutta discusses: “tokenizing the encrypted sensitive data, and/or storing the encrypted sensitive data in association with the token to a token vault”; [0132] from Masi discusses “local folders F2 and F3 are mapped to the network addresses of remote computing devices 2604 and 2605, respectively”, [0021]-[0022] from Wada discusses: “When the multimedia data is also received, the multimedia data may be stored in the script program storage unit 4 or stored in a storage device such as an internal memory or an external disk that can be referred to by the script execution engine unit 2”. In this way, it is not clear that how does Applicant conclude that the combination of references is “combination of desperate technologies”. Proxy re-encryption, data scanning, web-socket scripting, tokenization are some different techniques performed before or during uploading the file or document. In addition, some of these techniques are overlapped to each other. Such as, proxy re-encryption and tokenization may not be properly performed without data scanning. In addition, “In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).”
Therefore, Claims 1-3, 5-8, 10-20 and 22-24 are rejected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights