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 .
Detailed Action
Continuation
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 1, 2025 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1 – 3 and 19 – 20 are rejected under 35 U.S.C. 103(a) as being unpatentable over AAPA (Applicant Admitted Art as disclosed in Figures 1A, 2A, 2B and associated text) in view of Lango (US Patent No. 9953168 B1).
Per claim 1, AAPA is relied upon to teach a computer based system for controlling access to data for a customer of a multi-tenant software as a service (SaaS) system comprising (reads on a SaaS provider that provides software to customers, see AAPA Figure 2A and page 1 lines 10 – 14): a multi-tenant software as a service (SaaS) system cloud further comprising (reads on block 100 of AAPA Figure 2A and page 1 lines 10 – 14): a metadata store (see AAPA Figure 2A block 270); a SaaS encrypted data storage (see AAPA Figure 2A block 165 and page 2 lines 11 – 16); a SaaS user facing application interface (API) (see AAPA Figure 2A blocks 280 and 230 and page 3 lines 9 – 22); and an agent facing API (see AAPA Figure 2A block 220); the SaaS system cloud (see AAPA Figure 2A block 100), a key management system and a hardware security module (reads on a key management system implemented in software or tamper-resistant hardware security module, see AAPA page 2 lines 17 – 21); a user endpoint (reads on the combination of an exemplary computer and the SaaS agent 120 is installed locally at the endpoint 130, see AAPA Figure 2A block 130 and page 1 line 15 – page 2 line 5) in communication with (reads on the arrow leaving block 120 and block 220 of AAPA Figure 2A) the SaaS system cloud (reads on block 100 of AAPA Figure 2A) further comprising: an endpoint processor (reads on the necessary processor of the computer of User Endpoint 130, see AAPA page 1 line 15 – page 2 line 5 and Figure 2A block 130) and an endpoint data store configured to store non-transient instructions (reads on the necessary if not obvious memory/storage of the computer of User Endpoint 130, see AAPA page 1 line 15 – page 2 line 5 and Figure 2A block 130) that when executed operate a SaaS agent configured to perform the steps of (reads on the SaaS Agent resident in the computer, see AAPA Figure 2A block 120 and page 1 line 15 – page 2 line 5): identifying customer data for storage in (reads on the SaaS Agent transmits the customer data to the data store using the received storage credentials, see AAPA page 3 lines 9 – 22 and Figure 2A arrow leaving block 120 and entering block 165) the SaaS encrypted data store (reads on the data store encrypts the customer data using DEK, see AAPA page 3 lines 9 – 22); transmitting metadata and telemetry information related to the customer data to (reads on the arrow leaving AAPA Figure 2A block 120 and entering block 220 and page 7 lines 10 – 21) the agent facing API (see AAPA Figure 2A block 220); receiving storage access credentials from the agent facing API (reads on the key management system provides storage credentials for the data store to the SaaS agent via the agent-facing SaaS APIs, see AAPA page 3 lines 9 – 22); and storing the customer data in the SaaS encrypted data store using the received storage credentials (reads on the SaaS agent transmits the customer data to the data store using the KMS received storage credentials and the data store encrypts the customer data, see AAPA page 3 lines 9 – 22), wherein the KMS is configured to controllably enable key access to the SaaS system cloud (reads on the KMS stores the key encryption keys used to encrypt the data encryption keys and controls permissions for the data encryption keys, see AAPA page 2 lines 17 – 21, page 3 lines 4 – 8, and Figure 2B) and the SaaS agent (reads on the function of the key management system providing storage credentials/access authorization for the SaaS data store to the agent, see AAPA page 3 lines 9 – 22), the key access comprises access to a Data Encryption Key (DEK) used to encrypt the customer data (see AAPA page 2 lines 17 – 21) and a Key Encryption Key (KEK) used to encrypt the DEK (see AAPA page 2 lines 17 – 21), and the HSM comprises a hardware system configured to encapsulate the KEK (reads on the KMS/HSM which encapsulates key encryption keys, see AAPA page 3 lines 4 – 8) and provide encryption/decryption of the DEK (see AAPA page 2 lines 17 – 21). The prior art of record is silent on explicitly stating a customer-controlled cloud in communication with the SaaS system cloud, wherein the customer-controlled cloud comprises a key management system and a hardware security module (HSM).
[AAPA page 1 lines 10 – 14]
Software as a service (SaaS) providers provide software to customers and typically manage storage of customer data associated with the software. For example, insider threat management solutions store large amounts of customer data and process it in several iterations for intelligent reports, search, and archiving purposes. The data is potentially stored for months or years to satisfy compliance requirements.
[AAPA page 1 line 15 – page 2 line 5]
FIG. 1 is a schematic diagram of an exemplary distributed implementation of a SaaS system100. The SaaS System100 includes a SaaS agent120 that is resident in a user endpoint (computer)130, and a SaaS backend110, which as implemented here is remote from the endpoint130, for example, in communication with the agent120 via a wired or wireless communication network such as a local area network, a wide area network, or via the internet, for example, a cloud based server. The agent120 may be configured to communicate with the operating system135 of the endpoint130, for example, the agent120 may register for notifications from the operating system135. The agent120 may communicate data regarding activity of a customer user to the SaaS backend for monitoring and compliance. The SaaS system may store the activity data in a data store165. The SaaS data store165 is typically located at remote data centers, for example, in a cloud storage.
[AAPA page 2 lines 6 – 10]
The agent120 may be tailored to communicate with a specific operating system135 resident on the endpoint130. For example, the agent120 may be specific to Windows OS, MacOS, or Unix/Linux, among others. While FIG. 1 shows a single SaaS backend110, the SaaS backend110 may be distributed across two or more physical server devices. Likewise, the SaaS data store165 may be distributed across two or more physical storage devices.
[AAPA page 2 lines 11 – 16]
The SaaS agent120 is installed locally at the endpoint130. Due to sensitivity of information, most SaaS providers transfer and store customer data in encrypted form. For example, the data transferred from the agent120 to the SaaS backend110 may be encrypted, data transferred from the SaaS backend110 to the agent120 may be encrypted (TLS/SSL), and data stored in the agent data store262 and/or the server data store263 may be encrypted, for example using standard encryption methods like AES protocol or other encryption methods.
[AAPA page 2 lines 17 – 21]
Most SaaS providers store the data encryption keys (DEK) used to encrypt the data, for later data retrieval. Data encryption keys (DEK) themselves are usually encrypted using one or more master keys or key encryption keys (KEK). Under some practices the master keys themselves are stored in Key Management Systems (KMS) implemented in software or tamper- resistant hardware (Hardware Security Module - HSM).
[AAPA page 3 lines 1 – 3]
Encrypted data is unusable without the data encryption key(s). When stored in encrypted form, data encryption keys are useless without the ability to decrypt them using KEK stored in KMS/HSM.
[AAPA page 3 lines 4 – 8]
Throughout the data lifecycle, the SaaS providers may maintain all three aspects of these protection (encrypted data, data encryption keys (DEKs) as well as access to KMS/HSM which encapsulate key encryption keys KEKs). SaaS providers generally have multiple compliance and security controls in place to prevent misuse of the fact that they do possess access to all of the above.
[AAPA page 3 lines 9 – 22]
For example, FIG. 2A is a schematic diagram of a prior art system for SaaS provider managed storage and keys. To store customer data in the SaaS data store165, the SaaS Agent120 transmits activity data (metadata and binary content, such as screenshot images) to the agent-facing SaaS application interfaces (APIs)120. The SaaS backend stores the metadata in a metadata store270 and binary content in designated data store, and a SaaS controlled key management system265 provides storage credentials (access authorization code) for the SaaS data store165 to the SaaS agent120 via the agent-facing SaaS APIs120. The SaaS Agent120 transmits the customer data to the SaaS data store165 using the received storage credentials. The SaaS data store encrypts the customer data using DEK. DEK is then encrypted with KEK and stored appropriately. The SaaS user may likewise access data in the SaaS data store265 via the user interface280. The application, such as the user interface280, queries the SaaS system100 via externally facing APIs230, and the SaaS System100 returns access credentials to the application380, so the user may then use the credentials (coupled with a data request) to access the stored encrypted data from the SaaS data store165.
[AAPA page 4 lines 1 – 5]
In the above example, the SaaS exclusively manages the encryption keys. Certain customers, however, may not be satisfied with relying only on a SaaS provider's compliance and security controls to prevent unauthorized access to the sometimes highly sensitive, personal, or confidential data they store with the SaaS provider. Therefore, there is a need in the industry to address the abovementioned issue.
[AAPA page 7 lines 10 – 21]
As used within this disclosure, "telemetry" refers to the process of monitoring, collecting, and/or analyzing data from a computer and/or system to track user activity in a networked device, for example, to determine inappropriate or potentially harmful access to and/or use of system resources. Telemetry may involve the collection of measurements or other data at remote points ("endpoints") and their automatic transmission to receiving equipment for monitoring. The telemetry may be collected by an agent installed at the endpoint working in conjunction with the operating system of the endpoint computer/system to monitor user activity such as data usage (bandwidth), file/resource access, internet activity, keystrokes, mouse/keypad movements and clicks, and/or use of external devices (such as USB drives), among others. Telemetry data refers to data (or metadata) collected via or for telemetry. Embodiments of the present invention include a mechanism to onboard and use Customer-controlled Keys (DEK and KEK), storage or both to alleviate the risk of unauthorized access to customer data.
PNG
media_image1.png
1120
752
media_image1.png
Greyscale
PNG
media_image2.png
1026
822
media_image2.png
Greyscale
Lango (US Patent No. 9953168 B1) is relied upon to teach a customer-controlled cloud (reads on an on-premises device that may include management device which hosts a key-management service where the management device HSM combination comprises the key-management service, see Lango col. 2 line 59 – col. 3 line 7 and col. 3 lines 18 – 37. The Examiner construes the combination of on-premise device, management device, HSM and key-management service to be the customer-controlled cloud because it is a customer’s own networked computing environment which is reasonably scoped as a customer-controlled/private cloud) in communication with (reads on the communication lines between the on-premises device/customer-controlled cloud and the Virtual Data Center/VDC/SaaS system cloud, see Lango Figure 1 and col. 2 line 59 – col. 3 line 7) the SaaS system cloud (reads on the Virtual Data Center/VDC/SaaS system cloud, see Lango Figure 1 and col. 6 line 51 – col. 7 line 15), wherein the customer-controlled cloud comprises (reads on an on-premises device that may include management device which hosts a key-management service where the management device HSM combination comprises the key-management service, see Lango col. 2 line 59 – col. 3 line 7 and col. 3 lines 18 – 37. The Examiner construes the combination of on-premise device, management device, HSM and key-management service to be the customer-controlled cloud) a key management system and a hardware security module (reads on the management device and HSM combination that hosts a key management service, see Lango col. 2 line 59 – col. 3 line 7 and col. 3 lines 18 – 37); and the HSM comprises a hardware system configured to (reads on anti-tampering hardware such as hardware security modules that secure the account root key and the account root key is used to wrap the KEK, see Lango col. 3 lines 18 – 37) encapsulate the KEK (reads on the account root key is used to wrap the KEK, see Lango col. 3 lines 18 – 37).
[col. 2 line 59 – col. 3 line 7]
To protect the KEK, the on-premises device establishes a secure connection to a management device which hosts a key management service and which holds an account root key (ARK) for the customer/enterprise of the on-premises device. For example, this may be accomplished through sharing a client certificate and setting up a Transport Layer Security (TLS) connection. Once the secure connection is established, the on-premises device sends a request to the management device to wrap the KEK using the account root key. In response, the on-premises device wraps the KEK using the account root key to produce {KEK}.sub.ARK and sends {KEK}.sub.ARK back to the on-premises device. The on-premises device then writes the wrapped DEK, {DEK}.sub.KEK, and the wrapped KEK, {KEK}.sub.ARK, onto the label of the encrypted operating system image {OSI}.sub.DEK and uploads {OSI}.sub.DEK to the VDC.
[col. 3 lines 8 – 17]
In an embodiment, the KEK is used to wrap a DEK, in part, to facilitate future updates or changes in the encryption key. For example, the KEK may be based upon a user password or some other information that may be updated by a user. Rather than requiring the OSI to be re-encrypted (which could require a significant amount of time if the image is very large) instead only the DEK needs to be re-encrypted under the new KEK. Since the DEK is typically small in relation to the size of the OSI, this results in a far more efficient re-keying operation.
[col. 3 lines 18 – 37]
Furthermore, one reason that the account root key is used to wrap the KEK is because the account root key remains secured by the management device and is never sent across the network either in the clear or in encrypted form. Instead, the key remains in the management device and is used to encrypt other data items on-site by the management device with only the resulting encrypted data items being passed over the networks, thus reducing risk that the account root key could be revealed or deciphered by malicious actors. The account root key may also be secured by the management device via anti-tampering hardware, such as hardware security modules (HSMs). Furthermore, although the management device is described as separate from the on-premises device and the VDC, this is an implementation detail and not a requirement. Other embodiments may include an on-premises device that includes a key-management service that manages an account root key or alternatively a VDC which has an instance executed by a trusted third party which acts as a virtual management device which runs the key management service.
[col. 6 line 51 – col. 7 line 15]
In an embodiment, the virtual data center 103 represents a collection of computer systems and storage systems that are configured to execute virtual machine instances which host guest operating systems. For example, virtual data center 103 may represent a VDC executing a cloud service such as Amazon Web Services, Google Cloud, and so forth. In some embodiments, virtual data center 103 includes machine image storage 104 which stores machine images which represent templates of virtual machines which may be executed as virtual machine instances. The machine image storage 104 broadly represents storage using any of a plurality of different kinds of data storage systems, such as cloud storage, a NAS system, a SAN system, or a set of one or more non-volatile storage devices, such as a collection of hard drive disks. As one of the template images, the machine image storage 104 includes intermediary guest manager image 105 which represents the machine image for the intermediary guest manager. In addition, the virtual data center 103 includes instance launch module 106 which represents logic for launching instances based on a given machine image. For example, the instance launch module 106 may receive requests which identify a particular machine image, such as by ID number or by storage location within the machine image storage 104, reserves resources within the virtual data center 103 to launch the instance, and then boots up the instance based on the stored image. In some embodiments, the instance launch module 106 may also receive metadata along with the request which is passed on to the component within the machine image responsible for booting up guest operating systems (for example, the intermediary guest manager).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the KMS/HSM teachings of the prior art of record (see AAPA Figures 2A, 2B and associated text) by integrating the KMS/HSM teachings of Lango (see Lango col. 2 line 59 – col. 3 line 7, col. 3 lines 18 – 37 and Figure 1) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Lango would have yielded predictable results and resulted in an improved system. It would have been recognized that moving the KMS/HSM to the customer’s premises device/customer-controlled cloud, as taught by Lango, within the system of AAPA would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such KMS/HSM into similar systems, resulting in an improved system that uses all available known in the art techniques to improve the customer control of the encryption keys. The integration is straightforward: the SaaS backend connects to the customer’s on-premises HSM, as Lango teaches, to obtain the wrapped DEK when needed for decryption. This results in a high-assurance SaaS system where the provider has encrypted data and DEKs but cannot decrypt customer data because the KEK never leaves the customer’s HSM. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests an application in communication with (reads on the application such as the user interface, see AAPA page 3 lines 9 – 22) the SaaS system cloud configured to (reads on AAPA Figure 2A block 280 and AAPA page 3 lines 9 – 22): provide metadata and management queries to the SaaS user facing API to identify the customer data (see arrow leaving AAPA Figure 2A block 280);receive the storage access credentials (reads on the key management system provides storage credentials for the SaaS data store to the SaaS agent via the agent-facing SaaS APIs, see AAPA page 3 lines 9 – 22) from the KMS (reads on the management device HSM combination comprises the key-management service, see Lango col. 2 line 59 – col. 3 line 7 and col. 3 lines 18 – 37) via the customer facing API (see arrow entering AAPA Figure 2A block 280); and access the customer data in the SaaS encrypted data store using the received storage access credentials (reads on transmit the customer data to the SaaS data store using the received storage access credentials from the owner/customer controlled key manager, see AAPA page 3 lines 9 – 22 and Lango col. 2 line 59 – col. 3 line 7 and col. 3 lines 18 – 37).
Per claim 3, the prior art of record further suggests a key facilitation service configured to provide storage access credentials (reads on the key management system provides storage credentials for the SaaS data store to the SaaS agent via the agent-facing SaaS APIs, see AAPA page 3 lines 9 – 22) for the SaaS data store to the SaaS agent via the agent-facing SaaS API (see AAPA Figure 2A arrows entering block 120 from block 220).
Claim 20 is analyzed with respect to claim 1.
Claim 19 is analyzed with respect to claim 20.
Claims 4 – 8 and 13 – 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over AAPA in view of Ancin (US Patent 9251114 B1) in view of Shetty (US Pub. No. 20170286697 A1) in view of Stainback (US Pub. No. 20180109563).
Per claim 4, AAPA is relied upon to teach a computer based system for controlling access to data for a customer of a multi-tenant software as a service (SaaS) system comprising : a multi-tenant software as a service (SaaS) system cloud, further comprising (reads on block 100 of AAPA Figure 2A and page 1 lines 10 – 14): a metadata store (see AAPA Figure 2A block 270); a SaaS customer facing application interface (API) (see AAPA Figure 2A blocks 280 and 230 and page 3 lines 9 – 22); and an agent facing API (see AAPA Figure 2A block 220); a user endpoint (reads on the combination of an exemplary computer and the SaaS agent 120 is installed locally at the endpoint 130, see AAPA Figure 2A block 130 and page 1 line 15 – page 2 line 5) in communication with (reads on the arrow leaving block 120 and block 220 of AAPA Figure 2A) the SaaS system cloud (reads on block 100 of AAPA Figure 2A) comprising an endpoint processor (reads on the necessary processor of the computer of User Endpoint 130, see AAPA page 1 line 15 – page 2 line 5 and Figure 2A block 130) and an endpoint data store configured to store non-transient instructions (reads on the necessary if not obvious memory/storage of the computer of User Endpoint 130, see AAPA page 1 line 15 – page 2 line 5 and Figure 2A block 130) that when executed instantiate and maintain a SaaS agent configured to perform the steps of (reads on the SaaS Agent resident in the computer, see AAPA Figure 2A block 120 and page 1 line 15 – page 2 line 5): identifying customer data for storage in (reads on the SaaS Agent transmits the customer data to the data store using the received storage credentials, see AAPA page 3 lines 9 – 22 and Figure 2A arrow leaving block 120 and entering block 165) the data store (reads on the functionality of the data store encrypts the customer data using DEK, see AAPA page 3 lines 9 – 22); transmitting metadata and telemetry information related to the customer data to (reads on the arrow leaving AAPA Figure 2A block 120 and entering block 220 and page 7 lines 10 – 21) the agent facing API (see AAPA Figure 2A block 220); wherein the SaaS agent is pre-configured with credentials from the KMS for storing customer data objects (reads on the key management system provides storage credentials/access authorization code to the SaaS agent and the SaaS Agent transmits the customer data using the received storage credentials, see AAPA page 3 lines 9 – 22).The prior art of record is silent on explicitly stating a customer-controlled storage realm, further comprising :a customer-controlled key management system (KMS); and a customer-controlled data store for storing encrypted customer data objects; identifying customer data for storage in the customer-controlled data store; and providing a storage reference for the metadata store associated with the metadata; wherein the SaaS agent is pre-configured with credentials from the KMS for storing customer data objects in the customer-controlled data store, and the customer-controlled storage realm is not in direct communication with the SaaS system cloud.
Ancin (US Patent 9251114 B1) is relied upon to teach a customer-controlled storage realm, further comprising (reads on off-site client storage system, see Ancin col. 6 lines 1 – 21. The Examiner asserts client is reasonably scoped as customer-controlled and off-site storage system is reasonably scoped as storage realm) :a customer-controlled data store for storing (reads on off-site client storage system, see Ancin col. 6 lines 1 – 21 and claim 35) encrypted customer data objects (reads on keep data encrypted on premises to maintain the confidentiality of the associated file, see Ancin col. 9 line 53 – col. 10 line 3 and col. 15 line 63 – col. 16 line 3); identifying customer data (reads on the policy evaluation/determining if the data/file in the request is designated as private and belongs in the off-site private file system/customer-controlled store, see Ancin col.5 lines 59 – 67) for storage (The Examiner construes this to be an obvious if not necessary limitation of the prior art’s providing the requested access because the “provides access” is inclusive of write/storage operates which is facilitating the storage of the data object, see Ancin col. 4 lines 59 – 67) in the customer-controlled data store (reads on the private file system on the off-site client storage system, see Ancin col. 6 lines 1 – 20. The Examiner asserts the identifying/policy evaluation explicitly routes the data to the private file system which is the customer-controlled data store, see Ancin col. 5 lines 59 – 67 and col. 6 lines 1 – 21);related to the customer data (reads on the cloud metadata being transmitted describes the private data files/customer data which is related to the data stored in the customer realm, see Ancin col. 6 lines 1 – 21); and providing (reads on combining client metadata for each of a plurality of private data files stored at off-site client storage system with attributes to generate cloud metadata for the private data files and storing the cloud metadata but not the plurality of private data files on the cloud storage system, see Ancin col. 6 lines 1 – 27. The Examiner construes the storing to be the same as providing) a storage reference for (reads on the combination of client metadata and connection information which is a reference, pointer or locator that tells the system where to find the data, see Ancin col. 6 lines 1 – 27, col. 21 lines 13 – 42, col. 21 lines 43 – 55 and col. 23 lines 14 – 21) the metadata store associated with the metadata (reads on the cloud storage system/metadata store, see Ancin col. 6 lines 1 – 21 and lines 22 – 27) and the customer-controlled storage realm is not in direct communication with the SaaS system cloud (reads on private client data is securely maintained behind firewall, see Ancin col. 15 lines 28 – 35. The Examiner asserts a firewall separates the two realms).
[col. 1 lines 20 – 28]
This invention relates generally to cloud storage systems, and more particularly to systems and methods for providing clients access to files via a remote cloud storage system. Even more particularly, the invention relates to systems and methods for facilitating data security, providing users access to files stored at a client site using the remote cloud storage system, to provide efficient browsing and file access, and to provide faster synchronization in hybrid cloud storage solutions.
[col. 1 lines 49 – 54]
Security is one of the major hurdles in moving to the cloud. While each company and industry vertical has different needs, certain data sets and use cases preclude data being stored in the cloud. In such cases organizations prefer to keep data on premises in order to meet specific security and compliance needs.
[col. 2 lines 36 – 43]
Current vendor offerings force IT to choose different solutions for different use cases, thereby increasing complexity and costs. IT has to characterize files and use cases along Red and Green categories, where Green file sets can be hosted in the public cloud but Red files need to strictly stay on-premises. IT then has the option to implement a Private Cloud solution for Red files and use cases, while opting for public cloud in the case of Green files and use cases.
[col. 5 lines 19 – 38]
A related client storage system for providing access to a client's files is also disclosed. The client storage system includes a network interface, a storage device for storing data and code, and at least one processing unit operative to execute the code. The data includes a client file system to be accessed remotely, where the client file system includes a first portion synchronized with a cloud storage system located remotely from the client storage system and a second portion retained in the storage but not on the cloud storage system. Furthermore, the code includes a synchronizer operative to synchronize the first portion of the client file system with the cloud storage system and a storage connect appliance operative to provide access information (e.g., connection information, HTTP(S) endpoint information associated with the appliance) to the cloud storage system to enable a remote user to directly access the private file system. In a particular embodiment, each retained file includes a data file and associated client metadata and the client metadata associated with at least some of the retained files can be stored in the cloud storage system.
[col. 5 lines 39 – 58]
According to a particular embodiment, the network interface is further operative to establish a connection with a local user and establish a second connection with the cloud storage system. The storage connect appliance is also further operative to access a client namespace via the second connection, where the client namespace represents objects stored on the cloud storage system and objects stored on the at least one client storage system, and is also operative to request access to one of the objects of the client namespace behalf of the local user. The requested object can be stored on a second client storage system associated with the client and located remotely from the cloud storage system. If so, the storage connect appliance can receive connection information associated with the second client storage system from the cloud storage system, use the connection information to establish a third connection with the second client storage system, and request access to the requested object on the second client storage system. Alternatively, the storage connect appliance can be operative to obtain access to the requested object on the second client storage system via the cloud storage system.
[col. 5 lines 59 - 67]
In another particular embodiment, the network interface establishes a connection with a mobile user associated with the client and the storage connect appliance receives an access request (e.g., at an HTTP(S) endpoint) from the mobile user requesting access to the private file system and provides the requested access via the connection. The storage connect appliance can also authenticates the mobile user with the storage device and provide the requested access in accordance with access control policies of the storage device.
[col. 6 lines 1 – 21]
Another method for providing access to files via a cloud storage system is also disclosed. The method includes accessing client metadata for each of a plurality of private data files stored on at least one off-site client storage system, combining the client metadata with attributes to generate cloud metadata for the private data files, storing the cloud metadata, but not the plurality of private data files, on the cloud storage system, establishing a connection with a user over a network, and providing a namespace associated with the client to the user based on the cloud metadata, where the namespace includes the private data files and data files stored on the cloud storage system. The attributes can specify one or more off-site client storage systems having the private data files stored thereon. A particular method further includes receiving a request from the user to access a private data file of the namespace, accessing the cloud metadata associated with the requested private data file for connection information (e.g., IP address, HTTP(S) endpoint(s), etc.) associated with at least one off-site client storage system, and providing the connection information to the user.
[col. 6 lines 22 – 27]
The attributes can also include other types information. For example, the attributes can include connection information associated with the at least one off-site client storage location. The attributes can also include search tags, access control information, replication policies, and/or blobs associated with at least some of the private data files.
[col. 9 line 53 – col. 10 line 3]
Unified client namespace 100 advantageously facilitates three cloud use cases that clients desire. For example, cloud file system 118 is associated with the “green” use case, where the client wants to store and access files only on the remote cloud 102. Synchronized file system 114(A-B) is associated with the “yellow” use case, where client files are maintained both on-premise and in the cloud. The on-premise synchronized file system 114(A) enables fast local access to those files as well as access when a connection to remote cloud 102 cannot be established. The remote synchronized file system 114(B) on remote cloud 102 further provides remote access to the synchronized files and also provides backup protection. Each of private file systems 112 and 116 represent the “red” use case, where the private file system must remain on-premise on a private storage system associated with the client due to security and confidentiality reasons and/or because the private files are too large to migrate to the remote cloud 102.
[col. 15 line 63 – col. 16 line 3]
Accordingly, remote cloud 102 can be used as a conduit for providing red file access to remote user without permanently storing any files or red file metadata on remote cloud. While data does not flow outside remote cloud 102 in this embodiment, red data can be encrypted for added security. The current embodiment would be useful in a case where very large files (e.g., image files, etc.) are being migrated to remote cloud 102 over time.
[col. 12 lines 13 - 42]
FIG. 9B shows an exemplary folders table 900 that includes information associated with a folder object or a red node in client namespace 100 for the client. Each record in folders table 900 includes a folder ID field 912, a client ID field 914, a private field 916, a CLUE ID field 918, a parent folder ID field 920, and a folder name field 922. Folder ID field 912 includes data uniquely identifying a folder record. Client ID field 914 includes data corresponding to a client identifier 902 in table 900. Together, fields 912 and 914 uniquely identify a folder record. Private field 916 includes data (e.g., a flag, etc.) indicating if the folder record is associated with private (red) file system object. In other words, private field 916 includes data indicating if the folder object is a red node in client file system 100. CLUE ID field 918 associates the folder record with a Cloud Location Unique Entry (CLUE) record in cloud metadata 310. As will be discussed below, the associated CLUE record will include information facilitating access to a red namespace portion on a private storage system associated with the client. Parent folder ID field 920 includes a folder identifier identifying the parent folder record of the current folder record. Folder name field 922 includes data indicating the name of the folder associated with the folder record. For a red node, folder name field 922 will contain the name of the associated red namespace pointer (150-155). Folders table can include additional fields as desired. If a folder record is associated with a red node (e.g., red nodes 140-148), the information contained in the record will likely be minimal to maintain confidentiality. There are likely to be many folder records associated with a client.
[col. 21 lines 43 – 55]
FIG. 9C shows an exemplary file table 930 that includes information associated with a file object in client namespace 100. Each file record in table 930 can include a file ID field 932, a client file ID field 934, a private field 936, a folder ID field 938, a first CLUE ID field 940(1), a first replication policy field 942(1), a last CLUE ID field 940(x), and a last replication policy field 942(x). Each record in table 930 can also includes a file name field 944, a last modified time field 946, a file size field 948, a hash of file content field 950, a last sync time field 952, a file owner field 954, an access control information field 956, a UUID field 958, and one or more extendible attribute ID fields 958(1-x). There are likely to be many file records associated with a client.
[col. 23 lines 14 - 21]
CLUE ID records provide location information and/or access information that can be used to locate and access resources within hybrid cloud storage system 200. For example, CLUE's can serve as red namespace pointers for red nodes within client namespace 100. CLUEs also are used to access storage locations storing different copies of client files (client metadata and/or data) within hybrid cloud storage system.
35. A method for providing access to files associated with a particular client, said method comprising: identifying a client file system to be accessed remotely, said client file system being stored on at least one client storage system; synchronizing a first portion of said client file system with a cloud storage system located remotely from said client storage system; retaining a second portion of said client file system on said client storage system as a private file system but not on said cloud storage system; providing access information to said cloud storage system to enable a remote user to directly access said private file system; establishing a connection with a local user associated with said client; establishing a second connection with said cloud storage system; accessing a client namespace associated with said client via said second connection, said client namespace representing objects stored on said cloud storage system and objects stored on said at least one client storage system; and requesting access to one of said objects of said client namespace on behalf of said local user.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the SaaS security teachings of the prior art of record by integrating SaaS security teachings of Ancin to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known keeping sensitive data on customer-controlled storage/off-site from the cloud while maintaining the searchable metadata in the cloud technique of Ancin to the SaaS architecture where customer-control of sensitive data is a concern would have yielded predictable results and resulted in an improved system. It would have been recognized that the combined system directly solves the customer’s concerns about unauthorized access by SaaS personnel. This is a straightforward application of a known solution to a known problem. The motivation to combine the references is applied to all claims below this heading.
Shetty (US Pub. No. 20170286697 A1) is relied upon to teach a customer-controlled storage realm (reads on combination of local cloud 116, HSM 124 and Firewall 122 of customer 2, see Shetty Figure 1), further comprising :a customer-controlled key management system (KMS) (reads on CSM provides key management services on behalf of the customer, see Shetty para 0012, 0015 – 0016 and 0032 - 0033) wherein the SaaS agent is (reads on the HSM proxy to use when interacting with the HSM, see Shetty para 0121 and 0270) pre-configured with credentials (reads on the proxy is deployed with the credentials to access the customer’s HSM, see Shetty para 0121) from the KMS (reads on the CSM /HSM which provides key management services on behalf of the customer, see Shetty para 0015, 0076, 0121) and the customer-controlled storage realm is not in direct communication with the SaaS system cloud.
[Abstract]
Methods in a cloud object store facilitate strong data encryption, customer-management of object (encryption) keys, reductions in latency, globally-distributed object storage, and handling of streamed uploads. A method for encrypting objects stored in a cloud includes encrypting each object with a unique encryption (object) key. The plaintext object keys are generated in advance of uploads. The plaintext object keys can be stored in an object database in the cloud. Alternatively, the plaintext object keys can be provided to a customer's HSM, encrypted, and returned to the cloud, such that encrypted object keys, encrypted by the customer, are stored in the cloud. The cloud can alternatively encrypt the customer's object keys with a master key for the customer, which is then encrypted by the customer's HSM before being stored in the cloud. Proxies are also deployed for efficiently communicating with customer security modules.
[0005] The present invention overcomes the problems associated with the prior art by providing a cloud object store that facilitates strong data encryption and facilitates efficient customer-management of object keys in cases where the customer does not want the cloud service provider to be able to decrypt its stored content without the customer's authorization. Additionally, the invention improves cloud performance in various respects, including reducing latency, object storage requirements, and handling of special uploads.
[0009] Yet another particular method includes providing an object database storing a plurality of object records associated with stored digital objects, wherein each of the object records includes information facilitating the decryption of an encrypted one of the unique encryption keys used to encrypt a stored digital object associated with the object record from a security module (e.g., a hardware security module) of the customer.
[0012] Another particular method includes a step of communicating with at least one remote customer security module (CSM) associated with the customer, where the remote CSM provides key management services for the customer on behalf of the customer. A more particular method further includes the steps of providing the first and the second encryption keys to the remote [0013] CSM such that the remote CSM encrypts the first and the second encryption keys, receiving an encrypted first encryption key and an encrypted second encryption key from the CSM, and discarding the first and the second encryption keys locally. Still more particularly, the method can further include the steps of receiving a request to download the first encrypted digital object from a requesting client device associated with the customer, obtaining the first encryption key from the remote CSM in response to the request to download the first encrypted digital object, decrypting the first encrypted digital object using the first encryption key, and serving the first digital object to the requesting client device. Another more particular method can include deploying at least one customer security module (CSM) proxy for the customer, and configuring the CSM proxy to securely communicate with the remote CSM such that the step of communicating with the remote CSM occurs via the CSM proxy.
[0015] A more particular method further includes communicating with at least one remote customer security module (CSM), which provides key management services on behalf of the customer, providing the master key to the remote CSM, and discarding the master key locally. Still more particularly, the method includes receiving an encrypted master key associated with the customer from the remote CSM and storing the encrypted master key in association with the customer. Even more particularly, the method includes receiving an upload request associated with the first digital object from the client device after the master key has been discarded locally, providing the encrypted master key to the remote CSM, receiving the decrypted master key from the remote CSM, encrypting the first encryption key using the master key received from the [0016] CSM, storing the encrypted first encryption key such that the encrypted first encryption key is associated with the first digital object, and discarding the master key locally again. A yet even more particular method includes receiving a request to download the first encrypted digital object from a requesting client device associated with the customer after the step of discarding the master key locally again, providing the encrypted master key to the remote CSM, receiving the master key from the remote CSM, the master key being decrypted, decrypting the encrypted first encryption key using the master key received from the remote CSM, decrypting the first encrypted digital object using the first encryption key, serving the first digital object to the requesting client device, and discarding the master key again locally.
[0023] In still another particular method, the step of opening the first connection comprises establishing an HTTPS connection, and the step of opening the second connection comprises establishing a private network connection with the CSM via a private network of the customer.
[0063] FIG. 15 is a flowchart summarizing a method for proxying encryption key communications between a cloud storage system and an HSM according to the invention;
[0076] FIG. 1 further shows that a local file system stored on a local cloud 116 of a second customer 118 is also synchronized with cloud object store 102 via the Internet 106. Local clients 120 of second customer 118 can access the local file system stored on local cloud 116 via a local network 120, which is protected by a firewall 122. Unlike first customer 108, second customer 118 also operates one or more security module(s) 124, which are coupled to its local network 120. In this example, security module(s) 124 comprise hardware security module(s) (HSMs), which safeguard and manage digital keys for strong authentication and cryptographic processing, as will be discussed in more detail below. However, software based security modules might also be employed.
[0121] To handle communications with a plurality of HSMs associated with a plurality of customers, the present invention modularizes accessing components and configurations for a particular HSM in an HSM proxy 704, which is deployed between cloud object store 102 and the customer's HSM 702 as shown generally in FIG. 7B. More specifically, the customer will provision an HSM key in their HSM that is dedicated to the cloud service provider, and provide its HSM details (e.g., an identifier for the HSM key assigned to the cloud service provider, a security provider and credentials for the HSM proxy 704 to use when interacting with the HSM 702, etc.) to the cloud service provider (e.g., during service setup). The cloud service provider will accordingly deploy at least one HSM proxy 704 for that customer with the credentials and secure network connection to access the customer's HSM 702. The cloud service provider will also delegate HSM calls to the deployed customer-specific HSM proxy(ies) 704. The HSM proxies 704 of the present invention can be used with different types of existing HSMs, including (1) Microsoft Cloud Deployed Azure HSM, (2) Customer Premise deployed Safenet Luna HSMs and KeySecure HSMs, and (3) Amazon Web Service (AWS)-Deployed CloudHSM.
[0177] FIG. 15 is a flowchart summarizing a method for proxying encryption key communications between a cloud storage system and an HSM 702. In a first step 1502, HSM proxy 704 opens a first connection with an object store node 230 of cloud storage system via server application 1418 and object store interface 1426. Then, in a second step 1504, proxy application 1422 receives a request for key processing from the object store node 230 via the first connection, where the request for key processing is associated with the encryption of