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 . In communications filed on 01/29/2026. Claims 1, 15, and 20 are amended. Claims 2, and 16 are cancelled. Claims 1, 3-15, and 17-20 are pending in this examination.
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. This examination is in response to US Patent Application No. 18/112,946.
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 1, 3-15, and 17-20 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.
The independent claims 1, 15, and 20 “encrypting the modified data with a combination of both the public key of the first device and the public key of the second device to produce a single encrypted result wherein the encrypting is performed after the first device and the second device have exchanged private keys such that the single encrypted result is decryptable using a combination of both the private key of the first device and the private key of the second device” , renders the claim indefinite because specification in paragraph 206 states that “The devices may then use these joint/common keys for deciphering the data and then encrypting it before storing it after it has been modified.”, and in paragraph 215 , In one embodiment each device that needs access to the data on the storage server has a joint private key and a joint public key to use for deciphering and encrypting the data on the storage server. In one embodiment, the method further comprises: establishing the joint private key and the joint public key; and exchanging the joint private key and the joint public key with each device that needs access to the data on the storage server.” These statements contradict what is claimed in claims 1, 15, and 20 of exchanging private keys.
The dependent 3-14, and 17-19 which depend on the independent claims inherits the same deficiency and are rejected for the same reason. Examiner maps the claims limitations based on the broadest reasonable interpretation.
The claims 4, and 16 recite” wherein the second device uses the private key of the second device and the private key of the first device to access the modified data stored on the storage server by the first device”, renders the claims indefinite because specification in paragraph 206 states that “The devices may then use these joint/common keys for deciphering the data and then encrypting it before storing it after it has been modified.”, and in paragraph 215 , In one embodiment each device that needs access to the data on the storage server has a joint private key and a joint public key to use for deciphering and encrypting the data on the storage server. In one embodiment, the method further comprises: establishing the joint private key and the joint public key; and exchanging the joint private key and the joint public key with each device that needs access to the data on the storage server.” These statements contradict what is claimed in claims 4, and 16 of the second device uses the private key of the second device and the private key of the first device to access the modified data.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-15, and 17-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The independent claims 1, 15, and 20 recite “encrypting the modified data with a combination of both the public key of the first device and the public key of the second device to produce a single encrypted result wherein the encrypting is performed after the first device and the second device have exchanged private keys such that the single encrypted result is decryptable using a combination of both the private key of the first device and the private key of the second device” , which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. Specification in paragraph 206 states that “The devices may then use these joint/common keys for deciphering the data and then encrypting it before storing it after it has been modified.”, and in paragraph 215 , In one embodiment each device that needs access to the data on the storage server has a joint private key and a joint public key to use for deciphering and encrypting the data on the storage server. In one embodiment, the method further comprises: establishing the joint private key and the joint public key; and exchanging the joint private key and the joint public key with each device that needs access to the data on the storage server.” These statements contradict what is claimed in claims 1, 15, and 20 of exchanging private keys.
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
The dependent 3-14, and 17-19 which depend on the independent claims inherits the same deficiency and are rejected for the same reason.
The claims 4, and 16 recite” wherein the second device uses the private key of the second device and the private key of the first device to access the modified data stored on the storage server by the first device”, which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. Specification in paragraph 206 states that “The devices may then use these joint/common keys for deciphering the data and then encrypting it before storing it after it has been modified.”, and in paragraph 215 , In one embodiment each device that needs access to the data on the storage server has a joint private key and a joint public key to use for deciphering and encrypting the data on the storage server. In one embodiment, the method further comprises: establishing the joint private key and the joint public key; and exchanging the joint private key and the joint public key with each device that needs access to the data on the storage server.” These statements contradict what is claimed in claims 4, and 16 of the second- device uses the private key of the second device and the private key of the first device to access the modified data.
Response to Arguments
Applicant’s amendment to claims 1, 15, and 20 obviates previously raised claims 1, 3-15, and 17-20 U.S.C .112(b), second paragraph rejection.
Applicant’s amendment to claims 1, 15, and 20 obviates previously raised claims 1, 3-15, and 17-20 U.S.C .112(a), first paragraph rejection.
Applicant's arguments filed 01/29/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 12-16 of remarks filed on 01/29/2026 regarding claim 1 that the combination of Mehta, Ackerly, Doerner, and Fukuda fails to teach at least “encrypting the modified data with a combination of both the public key of the first device and the public key of the second device to produce a single encrypted result wherein the encrypting is performed after the first device and the second device have exchanged private keys such that the single encrypted result is decryptable using a combination of both the private key of the first device and the private key of the second device”.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 01/29/2026 on pages 12-16 of remarks. Examiner maintains the rejection.
Doerner discloses these limitations as:
[ see Figs 3-4 and corresponding text for more detail, [¶¶36-37, Process 400 further describes the operation illustrated by FIG. 3, from the point of view of key pair server 340. As previously described with respect to S230, key pair server 340 may, at S410, receive a request for an encryption key pair from sender device 310. The request specifies a future event and may also specify one or more intended recipients. In response, key pair server 340 generates the encryption key pair at S420 and transmits the public encryption key to sender device 310 at S430. A file encrypted using the public encryption key is received at S440. The file is also encrypted using a public encryption key of an intended recipient…], and [ see FIG 7 and corresponding text for more details, ¶52, file server 750 may provide the twice-encrypted files to the appropriate ones of recipient devices 720, 722 and 724 as described above. Moreover, file server 750 may perform the detection of the event and the transmission of the private key to each of recipient devices].
Please note that furthermore, Fukuda discloses these limitations as: [ see Figs 2-3 and corresponding text for more details, ¶¶31-42…the client 111 encrypts the data 211 using the decrypted public key 136 at step S302 to thereby create encrypted data 212 (step S303) … The server 101 then encrypts the encrypted data 212 again by the decrypted public key 134 at step S306 to create multi-encrypted data 213 (step S307) and saves the multi-encrypted data 213 in the storage device 201 (step S308)], and [Abstract, A data management system for managing data on a network in which a client device which requests data management transmits encrypted data obtained by encrypting data by a key for the client device, then a server device receives the encrypted data and stores multi-encrypted data obtained by encrypting the encrypted data by a key for the server device], and [¶44, the storage device 201, data 211, encrypted data 212 and multi-encrypted data 213 are the same as those described above in connection with FIG. 2].
Same argument applies for independent claims 15, and 20.
Double Patenting
With regard to the rejection of Claims 1-20 on the basis of provisional non-statutory Double Patenting over 18/112,935 (Reference / co-pending application), Examiner will maintain the Double Patenting rejection is held in obeyance.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 7-11, 15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. US 2016/0080149 A1 issued to Mehta, and in view of (US10523646) issued to Ackerly, and further in view of US Patent No. (US2016/0330031) issued to Doerner (US2012/0110327), and further in view of Fukuda (US2001/0042046).
Regarding claim 1, Mehta discloses receiving, at a first device, an encrypted private key of a second device encrypted using a public key of the first device [ see FIG, 4, ¶43 The computing device 402(second device) obtains the device 2(first device) public key 414 from the user key store 126, and encrypts the data protection private key using the device 2 (first device) public key 414], and [¶¶37-38], and
wherein the second device encrypts data into encrypted data using a public key of the second device [ see FIG 4, ¶34, the content is encrypted with the data protection public key (act 308). The data protection public key is used to encrypt the content by using the data protection public key as the key of a public key cryptography process. Thus, the data protection public/private key pair of which the data protection public key is used to encrypt the content can be used to protect the data without any use of a symmetric key], and [¶32], and
and stored the encrypted data on a storage server [see FIG. 3, ¶35, the protected content is copied to cloud storage (act 310)], and [¶41, Each computing device 402 and 404 has a content protection system 406 and 408, respectively, as discussed above. Protected content 410 is provided to the cloud storage 112 by the computing device 402, and copied to the computing device 404 from the cloud storage 112], and
decrypting, by the first device, a private key of the second device from the encrypted private key using a private key of the first device [¶43, The encrypted data protection private key is provided 418 to the computing device 404 (First device), allowing the computing device 404 to decrypt the protected content 410], and [¶39]; and
and accessing, by the first device, the encrypted data on the storage server by utilizing the private key of the second device [¶25, The cloud storage 122 allows content to be shared or roamed among the computing device 102 and other computing devices 124(1), . . ., 124(M). Protected content refers to content that has been encrypted, and protected content can be transferred to the cloud storage 122 by one of computing devices 102 or 124, as well as received by others of the computing devices 102 or 124], and [ ¶43, The encrypted data protection private key is provided 418 to the computing device 404 (First device), allowing the computing device 404 to decrypt the protected content 410], and [¶39].
and storing the modified data on the storage server. [¶24, The cloud storage 122 can optionally be implemented as one of multiple different services (also referred to as cloud services). These cloud services can include, for example, content storage services, content editing services, communication (e.g., email or messaging) services, and so forth].
Mehta does not explicitly disclose, however Ackerly discloses:
modifying, by the first device, the data accessed from the storage server into modified data) [ Col. 14 lines 38-45, In one embodiment, the access control management system 202 provides an interface with which the user of the first client device 102a can modify the information 208 stored by the access control management system 202. In another embodiment, the user of the first client device 102a generates a modified version of the information 208 and transmits the modified version to the access control management system 202.].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, by incorporating “cryptographic data distribution in an architecture”, as taught by Ackerly. One could have been motivated to do so in order to implement access control management system which may include functionality for analyzing the received information to determine whether the information includes an identifier of the user, and furthermore may include functionality for analyzing an access control list included in the received information to determine whether the user is on the access control list, and provides an interface with which the user of the first client device can modify the information stored by the access control management system [ Ackerly ,Col. 10, lines 59-64, Col. 14 lines 38-45].
Mehta, and Ackerly do not explicitly disclose, however, Doerner discloses:
encrypting the modified data with a combination of both the public key of the first device and the public key of the second device to produce a single encrypted result wherein the encrypting is performed after the first device and the second device have exchanged private keys such that the single encrypted result is decryptable using a combination of both the private key of the first device and the private key of the second device [ see Figs 3-4 and corresponding text for more detail, [¶¶36-37, Process 400 further describes the operation illustrated by FIG. 3, from the point of view of key pair server 340. As previously described with respect to S230, key pair server 340 may, at S410, receive a request for an encryption key pair from sender device 310. The request specifies a future event and may also specify one or more intended recipients. In response, key pair server 340 generates the encryption key pair at S420 and transmits the public encryption key to sender device 310 at S430. A file encrypted using the public encryption key is received at S440. The file is also encrypted using a public encryption key of an intended recipient…], and [ see FIG 7 and corresponding text for more details, ¶52, file server 750 may provide the twice-encrypted files to the appropriate ones of recipient devices 720, 722 and 724 as described above. Moreover, file server 750 may perform the detection of the event and the transmission of the private key to each of recipient devices].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, and Ackerly by incorporating “public key encryption principles”, as taught by Doerner. One could have been motivated to do so in order for data encrypted using a public encryption key may only be decrypted using a private encryption key that corresponds to the public encryption key. A public encryption key and its corresponding private encryption key are referred to as an encryption key pair [ Doerner, ¶¶4, 36-37].
Mehta, Ackerly, and, Doerner do not explicitly disclose, however Fukuda discloses storing the modified data on the storage server as the signal encrypted [ see Figs 2-3 and corresponding text for more details, ¶¶31-42…the client 111 encrypts the data 211 using the decrypted public key 136 at step S302 to thereby create encrypted data 212 (step S303) … The server 101 then encrypts the encrypted data 212 again by the decrypted public key 134 at step S306 to create multi-encrypted data 213 (step S307) and saves the multi-encrypted data 213 in the storage device 201 (step S308)], and [Abstract, A data management system for managing data on a network in which a client device which requests data management transmits encrypted data obtained by encrypting data by a key for the client device, then a server device receives the encrypted data and stores multi-encrypted data obtained by encrypting the encrypted data by a key for the server device], and [¶44, the storage device 201, data 211, encrypted data 212 and multi-encrypted data 213 are the same as those described above in connection with FIG. 2].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, Ackerly, and Doerner by incorporating “data management system for managing and storing multi-encrypted data”, as taught by Fukuda. One could have been motivated to do so in order to manage data transmission over a network with a high level of security. [ Fukuda, Abstract, ¶75].
Regarding claims 7, and 19, Mehta discloses , wherein each device that needs access to the data on the storage server has a joint private key and a joint public key to use for deciphering and encrypting the data on the storage server [each of the computing devices 102, 104 has keys for decryption and encryption, ¶¶25-26, which includes a public/private key pair, ¶29, including data protection public/private key pair, ¶44, ¶51) to use for deciphering and encrypting the data on the storage server (data protection public/private key pair is used for encryption and decryption, ¶36, ¶39].
Regarding claim 8, Mehta discloses, further comprising: receiving the joint private key and the joint public key from the second device [key management module generates keys that are used for content, ¶19, including data protection public/private key pair, ¶42) and the joint public key (public keys are made available to other computing devices, ¶36); and exchanging the joint private key and the joint public key with each device that needs access to the data on the storage server (data protection public/private key pair is shared between user devices, ¶44, ¶51)].
Regarding claim 9, Mehta discloses, wherein the first device and the second device belong to a same user [¶10, Protected content can be transferred to other ones of the user’s devices].
Regarding claim 10, Mehta discloses, wherein the first device and the second device belong to different owners with established trust [Computing devices are other computing devices of the user, or another computing devices that the user has logged into, ¶25; data can be shared among different user identities, ¶42; the techniques discussed herein allow a user to share protected content with other users, ¶¶50-51].
Regarding claim 11, Mehta discloses sending the public key of the first device to the second device [data protection public/private key pair is provided to other user devices, ¶51], and
and receiving the public key of the second device from the second device (Public key of the target device is obtained, for example through direct exchange, ¶36)
Regarding claims 15, and 20, these claims are interpreted and rejected for the same rational set forth in claim 1.
Claims 3, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. US 2016/0080149 A1 issued to Mehta (Mehta), and in view of (US10523646) issued to Ackerly, and further in view of US Patent No. (US2016/0330031) issued to Doerner (US2012/0110327), and further in view of Fukuda (US2001/0042046), and further in view of Gottschalk (US2023/0208621).
Regarding claims 3, and 17, Mehta discloses encrypting the private key of the first device with the public key of the second device; and sending the private key of the first device encrypted with the public key of the second device to the second device to enable the second device to use the private key of the second device to decipher the private key of the first device.
while Mehta discloses these limitations as: [key management module generates keys that are used for content, ¶19, including data protection public/private key pair, ¶42) and the joint public key (public keys are made available to other computing devices, ¶36); and exchanging the joint private key and the joint public key with each device that needs access to the data on the storage server (data protection public/private key pair is shared between user devices, ¶44, ¶51)], and [¶26].
Mehta, Ackerly, Doerner, and Fukuda do not explicitly disclose however, Gottschalk discloses: [ Abstract, A method for producing a control device includes the following steps: generating, by the control device, a first asymmetric cryptographic key pair with a first private key and a first public key; transmitting the first public key to an external entity; generating, by the external entity, a second asymmetric cryptographic key pair with a second private key and a second public key; encrypting, by the external entity, the second private key using the first public key; transmitting the encrypted second private key from the external entity to the control device; and decrypting, by the control device, the encrypted second private key using the first private key].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, Ackerly, Doerner, and Fukuda by incorporating “cryptographically protected communication”, as taught by Gottschalk. One could have been motivated to do so for preparation of the control apparatus for cryptographically protected communication with a predetermined entity. [ Gottschalk, Pages 1625-1630].
Claims 4, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. US 2016/0080149 A1 issued to Mehta, and in view of (US10523646) issued to Ackerly, and further in view of US Patent No. (US2016/0330031) issued to Doerner (US2012/0110327), and further in view of Fukuda (US2001/0042046), and in view of Gottschalk (US2023/0208621), and further in view of Paya (US11501370).
Regarding claim 4, Mehta, Ackerly Doerner, Fukuda and Gottschalk, do not explicitly disclose however, Paya discloses wherein the second device uses the private key of the second device and the private key of the first device to access the modified data stored on the storage server by the first device. [ Col. 83 lines 31-48, Multiple private keys may be required to access a digital wallet. Multiple keys may be stored in the same manner as key segments. In embodiments, where a second private key is required, the one or more individuals or systems providing the second key may be located in different administrative portals, different rooms, and/or different geographies from the one or more individuals or systems providing the first private key. Accordingly, a plurality of administrative portals may be employed by secure digital asset storage systems in accordance with the present invention. In embodiments, a plurality of portals may be used for retrieval of stored digital assets (e.g., by requiring a signature or private key from at least two individuals located in at least two different portals). In embodiments, one portal may be used for re-assembling key segments and thus providing one private key, and an individual in a second location may be required to provide a second key or signature before a digital wallet may be accessed], and [ Col.90 lines 18-25, In embodiments, the digital wallet is activated by a private key, which is mathematically related to a public address in a one-way function. In embodiments, the digital wallet includes a multi-signature account which requires plurality of private keys to access the digital assets held by the multi-signature account. In embodiments, more keys are generated for the multi-signature account than are required to access and/or use an account], and [ Col. 75 lines 9-42; Col. 113 lines 30-46; Col. 155 lines 39-46; Col. 117 lines 9-32; Col.135 lines 19-30].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, Ackerly Doerner, Fukuda, and Gottschalk by incorporating “Muli-signature account”, as taught by Paya. One could have been motivated to do so in order for providing security risk option to access digital asset account by implementing multi-signature transaction approval [Paya, col.30 lines 42-53].
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. US 2016/0080149 A1 issued to Mehta (Mehta), and in view of (US10523646) issued to Ackerly, and further in view of US Patent No. (US2016/0330031) issued to Doerner, (US2012/0110327), and further in view of Fukuda (US2001/0042046), and further in view of Bliss (US2017/0337226).
Regarding claim 5, Mehta, Ackerly, Doerner, and Fukuda do not explicitly disclose, however Bliss discloses wherein a notification is sent to the second device when the data is modified by the first device so that the second device may retrieve the modified data from the storage server before the second device remodifies the data [¶¶62-63, In the case of data logs, when the historian system 402 discovers a data log on an industrial controller having an associated historize metadata attribute set, the historian system 402 will configure itself to collect and store data records associated with the data log. In such scenarios, when the controller adds a new data record to the log, the historian system 402 will receive a notification from the controller indicating that the new record has been added (or detect the addition based on a monitoring of the controller), and in response to the notification, retrieve and store a copy of the data record in historian memory. In some embodiments, rather than being dependent on a discovery mode to be initiated at the historian system, the industrial controller itself may send a notification signal to the network when a metadata attribute associated with one of its data tags has been changed. The notification signal may include, for example, an identification of the controller as well as the data tag that has been modified. Upon receipt of the notification, the historian system can retrieve the metadata attribute for the affected tag and update its configuration information accordingly].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, Akerley, Doerner, and Fukudaby incorporating “a data historian system”, as taught by Bliss. One could have been motivated to do so in order for data historian system to cause the data historian system to collect and store data associated with the subset of the data item with the data log which receives notification from the controller indicating that the new record has been added (or detect the addition based on a monitoring of the controller), and in response to the notification, retrieve and store a copy of the data record in historian memory. [ Bliss, ¶¶4, 62-63].
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. US 2016/0080149 A1 issued to Mehta, and in view of (US10523646) issued to Ackerly, and further in view of US Patent No. (US2016/0330031) issued to Doerner (US2012/0110327), and further in view of Fukuda (US2001/0042046), and further in view of Erofeev (US2014/0281545).
Regarding claim 6 Mehta, Akerly, Doerner, and Fukuda do not explicitly disclose, however, Erofeev discloses retrieving the data from the storage server before remodifying the data every time the data is remodified [¶¶81-90], and [¶184, A backup operation creates a copy of primary data 112 at a particular point in time. Each subsequent backup copy may be maintained independently of the first. Further, a backup copy in some embodiments is stored in a backup format. This can be in contrast to the version in primary data 112 from which the backup copy is derived, and which may instead be stored in a native format of the source application(s) 110. In various cases, backup copies can be stored in a format in which the data is compressed, encrypted, deduplicated, and/or otherwise modified from the original application format. For example, a backup copy may be stored in a backup format that facilitates compression and/or efficient long-term storage], and [¶186, Backup operations can include full, synthetic or incremental backups. A full backup in some embodiments is generally a complete image of the data to be protected. However, because full backup copies can consume a relatively large amount of storage, it can be useful to use a full backup copy as a baseline and only store changes relative to the full backup copy for subsequent backup copies].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Mehta, and Doerner by incorporating “full-back up or incremental backup operation”, as taught by Erofeev. One could have been motivated to do so in order for creating a copy of primary data at a particular point in time where each subsequent backup copy may be maintained independently of the first. [ Erofeev, ¶¶81-90, 184,186].
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta, in view of Ackerly, Doerner and Fukuda as applied to claim 1, and further in view of US 2016/0342774 A1 to Henkel-Wallace et al. (Henkel-Wallace)
Regarding claims 12-13, receiving the encrypted private key to the second device using an optical transfer exchange, and further comprising: utilizing a QR code to facilitate the optical transfer exchange.
Mehta discloses communicating the encrypted private key over a wireless communication channel, but lacks communicating the encrypted private key to the second device using an optical transfer exchange and utilizing a QR code to facilitate the optical transfer exchange. However, Henkel-Wallace teaches that it was known to utilize a QR code to transfer encrypted key information between devices to improve security (¶32). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Mehta to include communicating the encrypted private key to the second device using an optical transfer exchange and utilizing a QR code to facilitate the optical transfer exchange. One of ordinary skill in the art would have been motivated to perform such a modification to utilize short-range communication to improve security, as taught by Henkel-Wallace.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentablee over Mehta, in view of Ackerly, Doerner, and Fukuda as applied to claim 1, and further in view of US 2012/0331529 A1 to Ibel et al. (Ibel).
Regarding claim 14, receiving a hash of the data from the second device; and providing the hash to the storage server to prove the first device is authorized to modify the data. Mehta lacks generating a hash of the data; and sending the hash to the second device, wherein the second device provides the hash to the storage server to prove the second device is authorized to modify the data. However, Ibel, in an analogous art (sharing data with a user, ¶59) teaches that it was known to provide a content hash to a storage server to prove access to content (¶59), including generating a hash (generating authorization token, ¶59) and sending the authorization token/hash to a second user (¶60) for inclusion in a request for the content (¶62). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Mehta to include generating a hash of the data and sending the hash to the second device, wherein the second device provides the hash to the storage server to prove the second device is authorized to modify the data. One of ordinary skill in the art would have been motivated to perform such a modification to restrict downloading of the content to authorized users, as taught by Ibel.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
Spalka(US2011/0185177) [0096] Data objects 130 are preferably saved individually encrypted in the database 134. Even in the case of a set of semantically associated data objects, each individual data object is preferably saved encrypted on its own in database 134, so that in case of retrieval of a single data object, transmission of this encrypted data object 130 to the data processing system 100 takes place, whereupon its decryption is undertaken there. In contrast, if for semantically associated data objects that were combined, encrypted and stored in a single data object, one were to undertake the decryption in the database in order to minimize the volume of data being transported, the operator would have access to the decrypted data objects. The procedure described above has the advantage that at no point in time does the database 134 or its operator obtain access to the decrypted keys or data objects.
Ebrahimi (US2019/0182042) [ see FIG 1A-1B, ¶48, Once all the handles/keys are generated, the data may be backed up and stored as encrypted data items 133. In particular, data items (e.g., piecemeal or combined into one or more data items) are encrypted using the DATAKEY. Once encrypted, each encrypted data item is then delivered to the back-end server 200 for storing at the data storage 130. In one embodiment, the data items are stored piece by piece, as illustrated in FIG. 1B. In other embodiments, the one or more data items are combined, and the combined data items are encrypted and stored. For purposes of illustration, data items are stored separately as is shown in FIG. 1B, and include encrypted data item #1 (132a), encrypted data item #2 (132b), encrypted data item #3 (132c) . . . encrypted data item #N (132N).].
Emigh (US8412837) [ (121) A data storer 2105 may store the combined encrypted or tokenized data in storage 2108. Storage 2108 may be any form of storage, including volatile storage such as random-access memory, or nonvolatile storage such as flash memory, magnetic memory or optical memory. A data transmitter 2107 may transmit stored encrypted or tokenized data from storage 2108, for example as part of a request for a transaction over a network such as network 102 of FIG. 1.
NGUYEN SANG (WO 2020076234 A1) [Abstract, An apparatus and a method for controlling data access, wherein the method comprises obtaining a data access key to gain access to a data storage for storing data to be transferred between a first device and a second device; storing the obtained data access key in a memory; obtaining a first public key associated with the first device; obtaining a second public key associated with the second device; encrypting the data access key with the first public key to form a first encrypted key; encrypting the data access key with the second public key to form a second encrypted key; and removing the data access key from the memory permanently. The data access key is accessible by decrypting the first or second encrypted key using a corresponding first or second private key of the respective first or second public key].
Han (US2006/0177066) [ Abstract, A key management, user registration and deregistration for a digital rights management (DRM) system in a home network, using a hierarchical node topology. In the key management, node information is generated by allocating a pair of keys (a public key and a private key) to each node. A node tree is made by generating link information using the pair of keys and a content key. The link information is delivered from an upper node to a lower node using the node tree. The link information is obtained by encrypting a private key of a `TO` node using a public key of a `FROM` node], and [ [0104] 1. When a "FROM" node is a device node, link information LI is generated by encrypting a sharing private key PRIV_shar_to of a `TO` node using a public confidentiality key PUB_conf_from of the `FROM` node or by encrypting a sharing symmetrical key SEC_shar_to of the `TO` node using the public confidentiality key PUB_conf_from of the `FROM` node. In this case, generation of the link information LI is given by: LI=E(PUB_conf_from, PRIV_shar_to), or LI=E(PUB_conf_from, SEC_shar_to) (1)], and [0105] 2. When a `FROM` node is not a device node, the link information LI is generated by encrypting a sharing private key PRIV_shar_to of the `TO` node using a sharing public key PUB_shar_from of the `FROM` node or by encrypting the sharing symmetrical key SEC_shar_to of the `TO` node using a sharing public key PUB_shar_from of the `FROM` node. In this case, generation of the link information LI is given by: LI=E(PUB_shar_from, PRIV_shar_to) or LI=E(PUB_conf_from, SEC_shar_to) (2)], and [0110] Next, the device obtains a sharing private key PRIV_shar_to of the `TO` node by decrypting the link information LI using its private confidentiality key PRIV_conf_from (840)].
Verheyem (US11159312) [(171) Because the public user device key is used to write encrypted data and the private user device key is used to read data, the encrypted data may be stored at a backup server and may be successfully transitioned to another device as necessary], and [(177) To retrieve data from backup, a device copies the backup records back onto the local device. This is useful for obtaining data from the Local Encrypted set, or restoring lost data from the local record. However, the local record data-set itself is often retrieved from backup if it was lost somehow on the device. If this happens, the app no longer runs and the user has to restore the device first].
Cohen (US2006/0143443) [0004] Many schemes have been developed to generate backup data. One data backup scheme is to generate point-in-time (PIT) copies of data. PIT copies which are generated are either hardware-based or software-based. A hardware-based PIT copy is a mirror of a primary volume which has been saved onto a secondary volume. A software-based PIT copy, called a "snapshot," is a "picture" of a volume at the block level or a file system at the operating system level. Another data backup scheme is where a backup application sends full or incremental copies of data to tape].
Challener (US2023/0009355) claim 6. The method according to claim 1, wherein at least one of the following is true: the PrimaryOS periodically performs incremental back-up of files to writable portions on the non-transitory storage medium during runtime; the authorization is verified by a password-based system, a D-RTM operation, or a TrustZone operation; the one or more data backups and the further backup include one or more of: (i) a full backup of all system data, (ii) a backup of the PrimaryOS and system applications, including user settings, or (iii) a backup user of user data; and the one or more backups comprise an initial backup and one or more incremental backups, and the further backup is an incremental backup.
Borshchova (US2019/0333395) [ [0018] According to another embodiment, the encrypting step first encrypts the message with the first entity private key to generate a first encrypted message and then encrypts the first encrypted message with the second entity public key to generate the encrypted message and wherein said unique set of keys comprise the first entity private key and the second entity public key. Alternatively, the encrypting step first encrypts the message with the second entity public key to generate a first encrypted message and then encrypts the first encrypted message with the first entity private key to generate the encrypted message and wherein said unique set of keys comprise the first entity private key and the second entity public key], and [0022] In the system described above, said first entity is one of a ground station and an Authorities control station and said second entity is one of an aircraft], and [0023] The unique set of keys of the system may comprise a private key of the first entity and a public key of the second entity.
US 7484104 B2 (Masui; Takanori et al.) teaches a second process description encrypted using a second public key corresponding to a private key of the second job processor, and a first process description and the second process description encrypted by the second public key are further encrypted using a first public key corresponding to a private key of the first job processor (claim 3). b.
US 20230308263 A1 (Eldefrawy; Karim) teaches “first encrypted message is further encrypted by a second public encryption key associated with the user of the second computing device” (¶243).
US 20130086691 A1 (Fielder; Guy) teaches obtaining a file, decrypting, modifying, re-encrypting and deleting the file after upload (¶159).
Gillen (US20190012637) [ 0050] In certain embodiments, a distributed ledger system may store information/data indicative of various transactions occurring between multiple computing devices (e.g., multiple transaction computing devices). The distributed ledger system may be embodied as a blockchain ledger system, comprising a plurality of “blocks” each representing one or more discrete transaction(s) occurring between computing devices. Each block may comprise information/data linking to a previous generated block, thereby providing a complete chain between the generation of information/data stored in the distributed ledger and the later use of the same information/data (e.g., to establish a complete chain-of-possession of information/data). The information/data stored in the various transactions/blocks may be encrypted/hashed/or otherwise protected from unauthorized access (e.g., read access, write access, and/or delete access). In a non-limiting example, information stored in the various blocks may be irreversibly hashed, such that the hashed information/data may be used to verify the authenticity of transactions, but the hashed data may not be reverse-engineered to ascertain substantive information based on the hashed information alone. Moreover, information/data transmitted between various computing devices may be encrypted (e.g., using public/private key pairs to digitally sign and/or verify data) such that blocks/transactions stored within the block chain may be verified by multiple computing nodes 100 having access to the public and/or private keys. Upon verification of the information/data to be stored in the blockchain, the information/data may be hashed and stored as noted herein.
Guan (US2020/0304303) [ [0004] Many blockchains (e.g., the Ethereum blockchain) have enabled blockchain contracts (also referred to as smart contracts) that are executed through blockchain transactions. Blockchain transactions are signed messages originated by externally owned accounts (e.g., blockchain accounts), transmitted by the blockchain network, and recorded in the blockchain. The blockchain contracts may be written to achieve various functions, such as adding data to blockchain accounts, changing data in the blockchain, etc. Thus, the blockchain can be maintained and updated by executing various blockchain transactions.], and [ 4. The method of claim 1, wherein: obtaining the one or more requests for updating the plurality of pieces of data in the one or more blockchains comprises: obtaining the one or more requests for updating the plurality of pieces of data of one local account respectively in a plurality of blockchains; the one or more requests comprise a plurality of unsigned blockchain transactions corresponding to the plurality of blockchains; the one or more blockchain addresses comprise a plurality of blockchain addresses respectively on the plurality of blockchains, the plurality of blockchain addresses corresponding to the one local account; adding the one or more blockchain addresses respectively to the one or more unsigned blockchain transactions to obtain one or more updated blockchain transactions comprises: adding the plurality of blockchain addresses respectively to the plurality of unsigned blockchain transactions to obtain a plurality of updated blockchain transactions; obtaining the one or more private keys respectively associated with the one or more blockchain addresses comprises: obtaining a plurality of private keys respectively corresponding to the plurality of blockchain addresses; signing the one or more updated blockchain transactions respectively with the one or more private keys comprises: signing in the plurality of updated blockchain transactions respectively with the plurality of private keys; and adding the signed one or more blockchain transactions to the one or more blockchains comprises: adding in a batch the signed plurality of blockchain transactions respectively to the plurality of blockchains by transmitting the signed one or more blockchain transactions respectively to a plurality of blockchain nodes of the plurality of blockchains for execution].
Campero ( US9858781) (41) Referring now to FIG. 2, the distributed ledger system 14 is shown. As mentioned, the distributed ledger system 14 is a sequential transaction database. The distributed ledger system 14 thus includes distributed databases 32a-32n that are typically existing in the “Cloud.” The distributed database comprise storage devices 34a-34n that are attached to different interconnected computers 36a-36n. The distributed databases are controlled by a distributed database management system that controls storage of data over a network 38 of the interconnected computers and execute corresponding replication and duplication processes. Replication software (not shown) detects changes in the distributed database contents and once the changes have been detected, replicates the changes to have all the databases the same. Duplication software (not shown) identifies one database (not shown) as a master and then duplicates that database across other databases. Replication and duplication keep the data current in all distributed storage locations. (42) Each of the distributed databases 32a-32n that form the distributed ledger system 14 store encrypted information records. An exemplary record 40 is shown below. The record 40 is stored in each of the distributed databases 32a-32n that form the distributed ledger system 14, which stores the record 40 in an encrypted form in the distributed ledger system 14.
(183) In the above implementation of secured access, a user, e.g., a manager approves the access by reviewing and signing request with its private key. Thus, secured access would involve two or more key set (two private-public key sets)].
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights