Patent Description:
Every year millions of people, businesses, and organizations around the world utilize software applications to assist with countless aspects of life. In many cases, sensitive information may be processed and transmitted by software applications in order to provide various functions, such as management of health information, finances, schedules, employment records, and the like. Sensitive information, such as personally identifiable information (PII), is protected by various laws and regulations, and must generally be protected from unauthorized access by software purveyors and associated parties.

One manner in which sensitive information may be left vulnerable to unauthorized access is the storage and transmission of sensitive information in documents. For instance, a document containing sensitive user data may be sent to a support professional for help in resolving an issue, and the support professional may have no need and/or authorization to view the sensitive data, instead needing only to view non-sensitive data in the same document. In another example, a document containing sensitive information may be stored for future use in association with an application, and the stored document may be accessible to various parties, such as information technology (IT) professionals. As such, it is important to determine if documents contain sensitive information so that the sensitive information can be protected.

While there are existing techniques for encrypting documents that contain sensitive information, these techniques generally involve encrypting an entire document, and thus the entire document (e.g., including non-sensitive portions) can only be accessed by a party that is able to decrypt the document. Furthermore, existing techniques generally require each application or service that transmits or receives documents to natively implement encryption functionality, including rules for detecting sensitive information (which are generally hard-coded into an application), encryption techniques (e.g., algorithms used to encrypt sensitive information), exchange of encryption keys, and/or decryption of encrypted content. Thus, existing techniques may involve re-inventing encryption-related logic with the development of each new application or service as well as significant additional overhead for data sharing.

Therefore, what is needed is a solution for improved detection and encryption of sensitive information in documents.

Certain embodiments provide a method for rule-based document security as defined in independent claim <NUM>.

Other embodiments provide a method for secure document reconstruction as defined in independent claim <NUM>.

Other embodiments provide a system as defined in appended claim <NUM> and a computer readable medium as defined in appended claim <NUM>.

<CIT> discloses a data security system and method adjunct to e-mail, browser or telecom program.

Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable mediums for improved detection and encryption of sensitive information in documents.

According to certain embodiments, a set of rules specifies criteria for identifying various type of sensitive information in documents and, in some embodiments, specifies actions to perform to secure particular types of sensitive information. For example, a rule may involve detection of patterns (e.g., regular expression), identification of structural components in structured documents, such as extensible markup language (XML) documents, JavaScript object notation (JSON) objects, and/or the like, and other types of criteria that may indicate the presence of sensitive information. Rules may also indicate how certain types of sensitive information, when detected, are to be secured. For example, rules may indicate types of transforms to apply to sensitive information within a document (e.g., masking, complete redaction, or the like), particular encryption algorithms and/or encryption/signing keys to use for the sensitive information, and/or the like. Rules may be defined by an administrator, developer, subject matter expert, and/or other party familiar with encryption requirements, and/or may be learned automatically. For example, rules may be learned based on historical documents known to contain sensitive information, such as though supervised learning processes.

Advantageously, as described in more detail below with respect to <FIG>, rather than encrypting an entire document that contains sensitive information, techniques described herein involve targeted encryption of sensitive components identified within a document, and storing/transmitting encrypted sensitive components separately from an amended version of the document in which the sensitive components have been replaced with non-sensitive placeholders. In an example, if a bank account number is detected in a financial document based on one or more rules, the bank account number is encrypted using an encryption technique (e.g., which may be specified by a rule), and an amended version of the document is produced by replacing the bank account number with a non-sensitive placeholder, such as a generic number. In some embodiments, placeholders are selected to conform to the style of the sensitive information that they replace, such as including the same number and/or types of characters, so that the amended document can be processed in a manner similar to the original document (e.g., so that any automated processing performed on the document that expects particular types of content will still generally function correctly). The encrypted bank account number is then sent with the amended document to one or more endpoints, along with information (e.g., metadata) related to reconstructing the original document. For example, metadata transmitted with the encrypted bank account number and the amended document may indicate a location in the amended document to which the bank account number corresponds so that, once the bank account number is decrypted by an authorized endpoint, the decrypted bank account number can be restored to its proper place in the document (e.g., replacing the placeholder).

In some embodiments an encrypted sensitive component and an amended document are sent as separate payloads in the same transmission, while in other embodiments the encrypted sensitive component and the amended document are sent in separate transmissions (e.g., as separate payloads). If the encrypted sensitive component and the amended document are sent in separate transmissions, the metadata indicating how to reconstruct the document may be sent with either or both transmissions. A payload generally refers to the actual data transmitted by communicating endpoints in a packet, as opposed to metadata related to the packet that may be included, for example, in a header of the packet.

Encryption keys and/or associated permission information related to encrypted sensitive components may be stored in a centralized key store and/or may be otherwise shared with authorized parties. In certain embodiments, a key store manages access to encryption keys by applying access control rules to requests for encryption keys received from endpoints. For instance, access control rules may specify which users, groups, applications, and/or endpoints are authorized to access certain types of sensitive information. Thus, if the key store receives a request for an encryption key for a particular type of sensitive information (e.g., employee financial data) from an endpoint associated with a particular user (e.g., an accounting professional), the key store may apply access control rules to determine whether the particular user is authorized to access the particular type of sensitive information, and determine whether to provide the requested encryption key accordingly. In some aspects, access control rules may be defined by an administrator, developer, subject matter expert, and/or other party familiar with security requirements.

Thus, embodiments of the present disclosure allow sensitive components of documents to be protected through rule-based encryption and access control measures while still allowing the documents to be accessed and utilized in an amended, non-sensitive form by parties that are not authorized to access the sensitive components. For example, a support professional may use an amended document to assist a user with resolving an issue (e.g., based on a user's name and address) without being granted access to encrypted sensitive components (e.g., social security number) of the document.

In some embodiments, document security functionality described herein is implemented by one or more components that are independent of the applications that produce, send, receive, and/or process the documents. For example, a proxy or filter component in front of an application (e.g., that receives traffic to and from the application and performs document security functionality with respect to the traffic before sending it on to the application and/or another endpoint), a plugin within an application, a browser extension, and/or the like may be used to implement various aspects of functionality described herein. In some cases, in a client-server architecture, documents associated with an application are transmitted from a server to one or more client devices. On the server side, a proxy component may receive documents sent by an application, and the proxy component may apply rules in order to detect and encrypt sensitive components of the documents, and may generate amended documents and/or metadata as described herein. The proxy component may then transmit the encrypted sensitive components, amended documents, and metadata to one or more client devices, or may return these items to the application so that the application can send them to one or more client devices. The proxy component may also send encryption keys for encrypted sensitive components and/or permission information to a key store and/or directly to one or more client devices, or to the application for transmission to the key store and/or one or more client devices.

On the client side (in this example), a proxy component may receive the encrypted sensitive components, amended documents, and metadata. The proxy component may request and/or receive an encryption key (e.g., from the key store) for the encrypted sensitive components (e.g., based on identifiers of the encrypted sensitive components), use the encryption key to decrypt the sensitive components, and reconstruct the documents by replacing placeholders in the amended documents with the decrypted sensitive components based on information in the metadata. The proxy component may then provide the reconstructed document to the client-side application.

Furthermore, in certain embodiments, data relating to detection and encryption of sensitive document components, generating amended documents, transmitting and receiving these items, requesting encryption keys, decrypting sensitive components, and reconstructing documents may be logged, such as for analysis and/or auditing purposes. Log data may be written by various components involved in the process to a centralized location (e.g., a data store or data lake) and/or may be maintained as metadata associated with the document. For example, data about which entities requested which keys, at what time, for what field or type of sensitive information, and/or the like may be logged by the key store. This log data may be used for security auditing, such as to determine whether unauthorized parties are attempting to access secure information.

Embodiments of the present disclosure improve upon existing security techniques in a variety of ways. For example, unlike techniques that rely only on hard-coded rules in an application for detecting sensitive information, embodiments described herein provide a rules engine that allows rules to be defined and applied in a more dynamic fashion, such as to documents associated with or used by a plurality of different applications. Furthermore, by encrypting only sensitive components of documents, and providing the encrypted sensitive components along with amended versions of documents that include non-sensitive placeholders, techniques described herein allow for more fine-grained access control for the contents of documents. For example, parties not authorized to access certain sensitive components of a document may still be able to access and utilize the parts of the document that they are authorized to access, as a non-sensitive version of the document is provided in an amended and usable format. By transmitting an amended version of the document separately from encrypted sensitive components of the document, with information that allows the original document to be reconstructed by endpoints authorized to access the sensitive components, techniques described herein allow various endpoints to utilize documents to the extent that they are authorized, without unnecessarily restricting access to non-sensitive content.

Additionally, embodiments of the present disclosure provide centralized access control for encryption keys related to encrypted sensitive portions of documents. Thus, rather than requiring applications themselves to individually manage access to secure data, a centralized key store as described herein provides consistent and easily-manageable access control for sensitive content in documents. Furthermore, certain embodiments involve implementing document security functionality separately from the underlying applications, such as in one or more proxy components, thereby allowing applications to achieve the benefits of the present disclosure without modification to underlying application code or redundantly implementing document security logic across multiple applications.

While rule-based encryption, amending of sensitive documents, centralized access control and security management, and other components of the present disclosure each involve various benefits individually (e.g., as described above), the combination of these components described herein provides additional benefits beyond the sum of the benefits provided by each individual component. For example, beyond providing the security of encryption, the security and usability of amended (e.g., redacted) documents, and the efficiency and consistency of centralized access control and security management, the particular combination of these components described herein further enables sending the same information (e.g., encrypted sensitive components, an amended document, and metadata) to all parties while providing each individual party with the precise subset of a document's content that that party is authorized to access.

<FIG> is an illustration <NUM> of an example related to rule-based document security. Illustration <NUM> includes a server <NUM>, one or more client devices <NUM>, and a key store <NUM> (e.g., which may represent one or more computing devices, as described in more detail below with respect to <FIG>).

Server <NUM> generally represents a computing device that serves data related to an application <NUM> to requesting endpoints, such as client device(s) <NUM>. Server <NUM> comprises application <NUM>, which involves the use of a document <NUM>. For instance, application <NUM> may be a financial management application, and document <NUM> may be a tax document relating to a user of application <NUM>. In some embodiments, document <NUM> may include information in various fields having different levels of sensitivity.

Rules engine <NUM> is a component that performs operations related to rule-based document security, such as by applying one or more rules to documents such as document <NUM> in order to identify and encrypt sensitive information. While rules engine <NUM> is depicted separately from application <NUM>, alternative embodiments involve rules engine <NUM> being part of application <NUM>, or being a component (e.g., plugin) that operates within application <NUM>.

Rules engine <NUM> stores rules related to document security, which, for example, may have been defined by an administrator. Rules may specify criteria for detecting sensitive information and, in some embodiments, what actions to take in order to secure certain types of sensitive information when detected. A rule may include, for instance, specify a pattern such as a regular expression known to correspond to a type of sensitive information. One example of a pattern-based rule is searching for the pattern ##/##/#### or ##-##-####, where # indicates any number from <NUM>-<NUM>, when searching for a date of birth. In other embodiments, rules may indicate structural aspects of documents known to be associated with sensitive information, such as an XPath for an XML document or a JSONPath for a JSON object. In some embodiments rules may indicate document coordinates and/or field labels. Rules may also relate to keywords, proximity to certain words or phrases, types of content (e.g., all numbers in a financial document), and/or the like. In some embodiments, rules may be learned and/or refined over time, such as using supervised learning techniques. In one example, a predictive model may be trained to detect certain types of sensitive information based on known instances of those types of sensitive information in historical documents.

Rules applied by rules engine <NUM> may also specify actions to take when certain types of sensitive information are detected in a document. For example, a rule may indicate that if personally identifiable information (PII) is detected in a document, the PII should be encrypted using a particular encryption algorithm (e.g., data encryption standard (DES), triple DES, advanced encryption standard (AES), and/or the like), and should be replaced in the document with a generic non-sensitive placeholder. In another example, a rule may indicate that if classified information is detected in a document, the classified information should be encrypted using a high-security encryption algorithm (e.g., <NUM>-bit AES encryption), and should be replaced in the document with a generic non-sensitive placeholder. In some cases, a rule may include a direct link, such as a uniform resource locator (URL), to an encryption key and/or signing key that is to be used for a particular type of sensitive information. Thus, embodiments of the present disclosure allow for a balance between the higher levels of security provided by certain encryption techniques and the higher amounts of processing resources required for such techniques by only utilizing high-security techniques when appropriate for particular items of data within a document.

Rules engine <NUM> receives document <NUM>, and applies one or more rules to the contents of document <NUM> in order to determine whether there are any sensitive components of document <NUM>. If rules engine <NUM> detects any sensitive components, it may determine what actions to take based on a rule. In other embodiments, rules engine <NUM> always encrypts sensitive components and replaces them in the document with generic non-sensitive placeholders (e.g., regardless of whether a rule indicates to perform these actions). In certain embodiments a document itself may include metadata indicating sensitive components within the document, and rules engine <NUM> may apply rules to determine what actions to take with respect to the sensitive components indicated in the metadata.

In an example, rules engine <NUM> uses a particular encryption key to encrypt a sensitive component detected in document <NUM>, and provides the key and, in some embodiments, permission data (e.g., indicating a type of sensitive information to which the key pertains and/or information related to which entities are authorized to access the key) at <NUM> to key store <NUM>. In some embodiments, rules engine <NUM> uses existing keys for encryption, and the existing keys may already be stored in key store <NUM>. In such embodiments, rules engine <NUM> may provide an indication of the key used along with permission data to key store <NUM>. Keys and permission data are stored in key store <NUM>, and key store <NUM> provides keys to requesting endpoints based on whether the endpoints are authorized to access the keys (e.g., as indicated in the permission data). In some cases, rules engine <NUM> and/or key store <NUM> further encrypt the encryption keys themselves with key encryption keys for additional security in transmission and storage of the keys. For example, rules engine <NUM> may encrypt a key with a key encryption key, and may provide the key encryption key directly to the endpoint (e.g., a client device <NUM>) that it intends to access the key, while sending the encrypted key itself (without the key encryption key) to key store <NUM>.

In some embodiments, key store <NUM> uses rules to determine whether to provide keys to requesting entities. For example, rules may be configured by an administrator (in one example), and may indicate which entities or types of entities are authorized to access which keys or which types of sensitive information associated with keys. In one example, a rule may state that only users in a "human resources" user group may access keys corresponding to sensitive information relating to employees' personal information. Thus, if key store <NUM> receives a request for a key corresponding to a user's social security number from a client device <NUM>, and the request indicates that it is was initiated by a user in the human resources user group (e.g., based on active directory information related to the user that submitted the request), key store <NUM> may provide the requested key based on the rule. In another example, a client device <NUM> may receive a key encryption key from rules engine <NUM>, and may use the key encryption key to decrypt an encryption key it receives from key store <NUM>.

In some embodiments, a signing key or certificate may also be employed. For example, a trusted third party component may receive keys generated by rules engine <NUM> via a secure channel and sign the keys, returning encrypted messages to rules engine <NUM> indicating the keys. The third party may also provide a public key for the encrypted messages to one or more authorized endpoints (e.g., client devices <NUM>) via one or more secure channels. As such, rules engine <NUM> may send the encrypted messages to key store <NUM> and/or directly to the authorized endpoints, and the authorized endpoints (e.g., that receive the encrypted messages either directly from rules engine <NUM> or key store <NUM>) may use the public key from the third party to decrypt the encrypted message, and thereby may trust the integrity of the keys in the decrypted messages based on the trusted nature of the third party.

Rules engine <NUM> also generates an amended document <NUM> by replacing the sensitive component that was encrypted with a non-sensitive placeholder. The placeholder may, for example, be a randomly-generated or otherwise generic string that conforms to one or more characteristics of the sensitive information it is replacing. For instance, the placeholder may include the same type of characters (e.g., letters, numbers, special characters, and/or the like) and/or the same number of characters as the sensitive information it is replacing. In one example, a social security number is replaced with the placeholder "<NUM>-<NUM>-<NUM>" in order to conform to the expected format of a social security number without including sensitive data.

Server <NUM> sends amended document <NUM> along with the encrypted document component <NUM> and metadata <NUM> to one or more client devices <NUM>. In one example, amended document <NUM> and encrypted document <NUM> are sent as separate payloads in the same transmission, along with metadata <NUM>. For example, the message may be organized as a tree, with the two payloads attached to a common parent node (e.g., identifying the document). In another example, amended document <NUM> is sent in a first transmission and encrypted document <NUM> and metadata <NUM> are sent in a second transmission. Metadata <NUM> generally includes information related to reconstructing document <NUM> based on amended document <NUM> and encrypted document component <NUM>. For example, metadata <NUM> may indicate a location within amended document <NUM> to which encrypted document component <NUM> corresponds.

A given client device <NUM> may request a key for encrypted document component <NUM> from key store <NUM>, such as by sending a request for the key. Key store <NUM> (or a related component) may determine whether to provide the key in response to the request based on one or more characteristics indicated in the request, such as based on the user, application, and/or device associated with the request (e.g., based on the permission data <NUM> and/or access control rules).

If the given client device <NUM> receives a key for encrypted document component <NUM>, it uses the key to decrypt encrypted document component <NUM>. The given client device <NUM> may then reconstruct document <NUM> by inserting the decrypted document component into amended document <NUM> at a location indicated by metadata <NUM>, which may involve replacing a placeholder with the original contents of the document.

If the given client device <NUM> does not receive a key, such as if the given client device <NUM> does not request the key or if a request from the given client device <NUM> for the key is denied (e.g., because the given client device <NUM> and/or an associated user and/or application is not authorized to access the sensitive document component), then the given client device <NUM> may utilize and/or store amended document <NUM> as-is. For example, if the given client device <NUM> belongs to a support professional, the support professional may use amended document <NUM> to provide one or more services to a user, such as assisting the user with correcting or submitting the original document or resolving an issue related to creation, use, and/or submission of the document.

<FIG> is an illustration <NUM> of an example of rule-based encryption and replacement of sensitive document components.

Illustration <NUM> includes an amended document <NUM>, which may have been generated by one or more components of a rule-based document security system, such as rules engine <NUM> of <FIG>, based on an original document related to an application.

For example, one or more rules may be applied in order to detect a name and a social security number (SSN) in the document, and the name and SSN may be encrypted based on the one or more rules (e.g., using one or more encryption algorithms or types of encryption algorithms indicated in the one or more rules) in order to produce encrypted name <NUM> and encrypted SSN <NUM>. For example, a first encryption technique <NUM> is used to produce encrypted SSN <NUM> and a second encryption technique <NUM> is used to produce encrypted name <NUM>. In one example, encryption technique <NUM> is a higher-security form of encryption (e.g., <NUM>-bit encryption) than encryption technique <NUM> (e.g., <NUM>-bit encryption), such as due to the higher sensitivity of an SSN as compared to a name. Then, the name and SSN are replaced in the document with placeholders <NUM> and <NUM> in order to produce amended document <NUM>.

Placeholders <NUM> and <NUM> may be non-sensitive placeholders that have one or more characteristics of the sensitive components (e.g., name and SSN) that they are replacing. For example, placeholder <NUM> may be a generic name (e.g., "John Doe") and placeholder <NUM> may be a generic SSN (e.g., <NUM>-<NUM>-<NUM>). Thus, amended document <NUM> may still be able to be utilized by one or more entities not authorized to access the sensitive components (e.g., name and SSN) of the original document.

Metadata <NUM> indicates a mapping <NUM> between encrypted name <NUM> and placeholder <NUM> and a mapping <NUM> between encrypted SSN <NUM> and placeholder <NUM>. For instance, mappings <NUM> and <NUM> may indicate locations in amended document <NUM> (e.g., coordinates relative to an origin, structural components in a structured document, text strings of placeholders <NUM> and <NUM>, and/or the like) that may be used to determine where encrypted SSN <NUM> and encrypted name <NUM> belong in amended document <NUM>. Thus, metadata <NUM> allows the original document to be reconstructed based on amended document <NUM> and encrypted name <NUM> and encrypted SSN <NUM> (e.g., if the encrypted components are decrypted).

<FIG> is an illustration <NUM> of an example related to reconstructing documents based on amended documents, encrypted document components, and associated metadata.

Illustration <NUM> includes amended document <NUM>, encrypted document component <NUM>, metadata <NUM>, key store <NUM>, and a client device <NUM> of <FIG>.

Amended document <NUM>, encrypted document component <NUM>, and metadata <NUM> are received by a proxy <NUM> within client device <NUM>. For example, proxy <NUM> may be a software component separate from a client application <NUM> (e.g., the consumer of the document) that implements decryption and reconstruction operations in order to reconstruct documents for consumption by client application <NUM>. Proxy <NUM> may be implemented as an independent application, a browser add-on or plug-in (e.g., of client application <NUM> is a browser), a component within a network adapted of client device <NUM>, and/or the like. In some cases, proxy <NUM> is implemented in the data path of application <NUM> such it has the ability to receive and process data upstream prior to providing it downstream to application <NUM>.

Proxy <NUM> interacts with key store <NUM> to retrieve a key for decrypting encrypted document component <NUM>, such as by submitting a request for the key (e.g., including one or more characteristics of client device <NUM>, client application <NUM>, and/or a user in the request) and receiving the key in response to the request (e.g., if key store <NUM> determines to grant access to the key based on access control rules).

Proxy <NUM> uses the key to decrypt encrypted document component <NUM>, and then uses metadata <NUM> to produce reconstructed document <NUM> by replacing a placeholder in amended document <NUM> with the decrypted document component (e.g., at a location in the document indicated by metadata <NUM>, as described above with respect to <FIG>).

Proxy <NUM> then provides reconstructed document <NUM> to client application <NUM>, which consumes the document without having any need to know of the encryption, amending, decryption, and/or reconstruction processes related to the document. Thus, the use of proxy <NUM> separates document security logic from the client application itself, allowing techniques described herein to be utilized with applications that do not natively provide such security functionality.

Proxy <NUM> represents an example of an application-external implementation of document security techniques described herein, but other embodiments may involve a plug-in, module, integration, extension, or even native code of an application being configured to perform certain operations described herein for document security. In some embodiments, proxy <NUM> may be a microservice in a microservices-based deployment of an application.

<FIG> depicts example operations <NUM> related to rule-based document security. For example, operations <NUM> may be performed by one or more components of server <NUM>, one or more client devices <NUM>, and/or key store <NUM> of <FIG>.

Operations <NUM> begin at step <NUM>, with identifying a sensitive component of a document based on one or more rules. In some embodiments, identifying the sensitive component of the document based on the one or more rules comprises one or more of: analyzing one or more structural elements of the document based on the one or more rules; or comparing text in the document to one or more patterns based on the rules. The one or more rules may, for example, specify a type of encryption to use for encrypting the sensitive component of the document.

Operations <NUM> continue at step <NUM>, with encrypting the sensitive component of the document to produce an encrypted sensitive component.

Operations <NUM> continue at step <NUM>, with replacing the sensitive component in the document with a placeholder component to produce an amended document.

Operations <NUM> continue at step <NUM>, with transmitting, to one or more endpoints: the amended document; the encrypted sensitive component; and information relating to reconstructing the document based on the amended document and the encrypted sensitive component. In some embodiments, the amended document and the encrypted sensitive component are transmitted to the one or more endpoints as separate payloads. For example, the separate payloads may be associated with a common parent node in a message transmitted to the one or more endpoints.

In certain embodiments, the amended document and the encrypted sensitive component are transmitted to the one or more endpoints as separate transmissions.

In one example, a first endpoint of the one or more endpoints is authorized to access the amended document and not authorized to access the encrypted sensitive component, while a second endpoint of the one or more endpoints is authorized to access the amended document and the encrypted sensitive component.

Some embodiments further include sending an encryption key for the encrypted sensitive component to a key store, wherein the second endpoint is granted access to the encryption key in the key store.

Certain embodiments further comprise identifying an additional sensitive component of the document based on one or more additional rules and encrypting the additional sensitive component using a different type of encryption specified in the one or more additional rules, wherein the different type of encryption is different than the type of encryption used for encrypting the sensitive component of the document.

Note that <FIG> is one example of method <NUM>, but in other examples, fewer, additional, or alternative steps may be included consistent with the various examples described in this disclosure.

<FIG> depicts example operations <NUM> related to secure document reconstruction. For example, operations <NUM> may be performed by one or more components of a client device <NUM> of <FIG>.

Operations <NUM> begin at step <NUM>, with receiving, from a computing device: an amended document; an encrypted sensitive component; and information relating to reconstructing a document based on the amended document and the encrypted sensitive component.

Operations <NUM> continue at step <NUM>, with decrypting the encrypted sensitive component to produce a decrypted sensitive component.

Operations <NUM> continue at step <NUM>, with determining, based on the information relating to reconstructing the document, a document location that corresponds to the decrypted sensitive component.

Operations <NUM> continue at step <NUM>, with reconstructing the document by inserting the decrypted sensitive component into the amended document at the document location.

<FIG> illustrates an example system 600A with which embodiments of the present disclosure may be implemented. For example, system 600A may correspond to server <NUM> of <FIG>, and may be configured to perform operations <NUM> of <FIG>.

System 600A includes a central processing unit (CPU) <NUM>, one or more I/O device interfaces <NUM> that may allow for the connection of various I/O devices (e.g., keyboards, displays, mouse devices, pen input, etc.) to the system 600A, network interface <NUM>, a memory <NUM>, and an interconnect <NUM>. It is contemplated that one or more components of system 600A may be located remotely and accessed via a network <NUM>. It is further contemplated that one or more components of system 600A may comprise physical components or virtualized components.

CPU <NUM> may retrieve and execute programming instructions stored in the memory <NUM>. Similarly, the CPU <NUM> may retrieve and store application data residing in the memory <NUM>. The interconnect <NUM> transmits programming instructions and application data, among the CPU <NUM>, I/O device interface <NUM>, network interface <NUM>, and memory <NUM>. CPU <NUM> is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and other arrangements.

Additionally, the memory <NUM> is included to be representative of a random access memory or the like. In some embodiments, memory <NUM> may comprise a disk drive, solid state drive, or a collection of storage devices distributed across multiple storage systems. Although shown as a single unit, the memory <NUM> may be a combination of fixed and/or removable storage devices, such as fixed disc drives, removable memory cards or optical storage, network attached storage (NAS), or a storage area-network (SAN).

As shown, memory <NUM> includes application <NUM> and rules engine <NUM>, which may be representative of application <NUM> and rules engine <NUM> of <FIG>.

Memory <NUM> further comprises document(s) <NUM>, which may include document <NUM> and amended document <NUM> of <FIG> and amended document <NUM> of <FIG>. Memory <NUM> further comprises rule(s) <NUM>, which may include rules utilized by rules engine <NUM>. Memory <NUM> further comprises encrypted components <NUM>, which may include encrypted document component <NUM> of <FIG>, and encrypted SSN <NUM> and encrypted name <NUM> of <FIG>. Memory <NUM> further comprises key(s)/permission data <NUM>, which may include key/permission data <NUM> of <FIG>.

<FIG> illustrates an example system 600B with which embodiments of the present disclosure may be implemented. For example, system 600B may correspond to a client device <NUM> of <FIG>, and may be configured to perform operations <NUM> of <FIG>.

System 600B includes a central processing unit (CPU) <NUM>, one or more I/O device interfaces <NUM> that may allow for the connection of various I/O devices (e.g., keyboards, displays, mouse devices, pen input, etc.) to the system 600B, network interface <NUM>, a memory <NUM>, and an interconnect <NUM>. It is contemplated that one or more components of system 600B may be located remotely and accessed via a network <NUM>. It is further contemplated that one or more components of system 600B may comprise physical components or virtualized components.

As shown, memory <NUM> includes client application <NUM> and proxy <NUM>, which may be representative of client application <NUM> and proxy <NUM> of <FIG>.

Memory <NUM> further comprises reconstructed document(s) <NUM>, which may include reconstructed document <NUM> of <FIG>. Memory <NUM> further comprises key(s) <NUM>, which may include one or more keys received from key store <NUM> or rules engine <NUM> of <FIG>.

The preceding description provides examples, and is not limiting of the scope, applicability, or embodiments set forth in the claims. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein.

The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein.

For example, "determining" may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and other operations. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and other operations. Also, "determining" may include resolving, selecting, choosing, establishing and other operations.

Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions.

A processing system may be implemented with a bus architecture. The bus may link together various circuits including a processor, machine-readable media, and input/output devices, among others. A user interface (e.g., keypad, display, mouse, joystick, etc.) may also be connected to the bus. The bus may also link various other circuits such as timing sources, peripherals, voltage regulators, power management circuits, and other types of circuits, which are well known in the art, and therefore, will not be described any further.

Computer-readable media include both computer storage media and communication media, such as any medium that facilitates transfer of a computer program from one place to another. The processor may be responsible for managing the bus and general processing, including the execution of software modules stored on the computer-readable storage media. By way of example, the computer-readable media may include a transmission line, a carrier wave modulated by data, and/or a computer readable storage medium with instructions stored thereon separate from the wireless node, all of which may be accessed by the processor through the bus interface. Alternatively, or in addition, the computer-readable media, or any portion thereof, may be integrated into the processor, such as the case may be with cache and/or general register files.

When referring to the functionality of a software module, it will be understood that such functionality is implemented by the processor when executing instructions from that software module.

The following claims are not intended to be limited to the embodiments shown herein, but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more.

Thus, from one perspective, there has now been described techniques for rule-based document security. Embodiments include receiving, from a computing device: an amended document; an encrypted sensitive component; and information relating to reconstructing a document based on the amended document and the encrypted sensitive component. Embodiments include decrypting the encrypted sensitive component to produce a decrypted sensitive component. Embodiments include determining, based on the information relating to reconstructing the document, a document location that corresponds to the decrypted sensitive component. Embodiments include reconstructing the document by inserting the decrypted sensitive component into the amended document at the document location.

Claim 1:
A method for rule-based document security, comprising:
identifying a sensitive component of a document based on one or more rules;
encrypting the sensitive component of the document to produce an encrypted sensitive component;
replacing the sensitive component in the document with a placeholder component to produce an amended document; and
transmitting, to one or more endpoints:
the amended document;
the encrypted sensitive component; and
information relating to reconstructing the document based on the amended document and the encrypted sensitive component
wherein the amended document and the encrypted sensitive component are transmitted to the one or more endpoints as separate transmissions
further comprising sending an encryption key for the encrypted sensitive component to a key store.