Attribute-based encryption system for selective document security

Abstract

The present disclosure provides a method for selectively encrypting and decrypting portions of a document. The method includes receiving a document containing plaintext, analyzing the document using an artificial intelligence system to identify portions containing sensitive information, assigning predefined security levels or attributes to the identified portions, sending an encrypt file content request to a cryptographic engine, receiving an encrypted file content response, building an encrypted document by replacing portions with masking symbols and storing encrypted portions as metadata, and sending the encrypted document to a client device. The artificial intelligence system uses machine learning models trained on domain-specific data and employs pattern recognition and contextual analysis to identify sensitive content based on semantic understanding and classification rules.

Description

ATTRIBUTE-BASED ENCRYPTION SYSTEM FORSELECTIVE DOCUMENT SECURITY

[0001] CROSS-REFERENCE TO RELATED APPLICATION

[0002] This application claims the benefit ofU.S. Provisional Application Ser. No. 63 / 670,692 filed July 12, 2024, the content of which is incorporated by reference herein in its entirety for all purposes.

[0003] FIELD OF INVENTION

[0004] The present disclosure relates to document security systems, and more particularly to an attribute-based encryption system for selectively encrypting and decrypting portions of documents based on user attributes and access policies.

[0005] BACKGROUND

[0006] Document security has been a critical concern for organizations and individuals alike since the advent of digital information systems. As the volume and sensitivity of digital documents have increased exponentially over the years, so too has the need for sophisticated security measures to protect this valuable information from unauthorized access, modification, or distribution. The challenge has become particularly acute in environments where documents contain varying levels of sensitive information that must be selectively accessible to users with different security clearances, organizational roles, and compartment access rights.

[0007] Traditional document security methods have primarily relied on access control lists (ACLs) and role-based access control (RBAC) systems to manage user permissions. While these approaches have been effective in controlling access at a file or folder level, they lack the granularity required for protecting specific portions of documents that may contain varying levels of sensitive information. The all-or-nothing approach of traditional systems fails to address scenarios where a single document may contain Top Secret, Secret, Confidential, and Unclassified information that should be selectively accessible based on user attributes such as security clearance, organizational affiliation, and compartment access.

[0008] The concept of data classification has emerged as a crucial component in modern information security frameworks. Organizations typically categorize their data into different levels of sensitivity, such as public, internal, confidential, and highly confidential. However, implementing these classifications within individual documents has proven to be a significant challenge, particularly when dealing with complex, multi-section documents that may contain information of varying sensitivity levels. Traditional approaches require manual identification andmarking of sensitive content, a process that is time-consuming, error-prone, and impractical for large volumes of documents or frequently updated content.

[0009] Encryption has long been recognized as a powerful tool for protecting sensitive information. Symmetric key encryption algorithms, such as the Advanced Encryption Standard (AES), provide robust protection for data at rest and in transit. However, traditional encryption methods typically encrypt entire files or documents, which can be problematic when different users require access to different portions of the same document based on their security clearance or role within an organization. This limitation becomes particularly evident in collaborative environments where multiple users with varying access levels need to work on the same document simultaneously while maintaining strict security boundaries.

[0010] Attribute-Based Encryption (ABE) has emerged as a promising solution to address the limitations of traditional encryption methods. ABE allows for fine-grained access control by encrypting data based on a set of attributes or policies. This approach enables more flexible and expressive access control policies compared to traditional methods. However, the implementation of ABE in real-world document security systems has been hindered by several factors, including the complexity of key management, performance overhead, the lack of user-friendly interfaces for specifying encryption policies, and the absence of automated systems for identifying sensitive content within documents. The manual process of marking sensitive sections has remained a significant barrier to widespread adoption of ABE technologies.

[0011] The integration of encryption technologies with widely used document formats, such as those used in Microsoft Office applications, has been an ongoing challenge. While these applications often provide basic password protection features, they lack the sophistication required for implementing granular, attribute-based access control within documents. This limitation has forced organizations to rely on separate, often cumbersome, document management systems to enforce their security policies. The need for seamless integration with existing document workflows, including the ability to operate as Microsoft Office add-ins that side-load with applications, has become increasingly important for user adoption and operational efficiency.

[0012] One of the key challenges in implementing advanced document security measures is maintaining the usability and readability of protected documents. When portions of a document are encrypted or redacted, the overall structure and formatting of the document can be significantly altered, making it difficult for users to work with the document effectively. This is particularlyproblematic in collaborative environments where multiple users with different access levels need to work on the same document simultaneously. The concept of "spill-proof documents" has emerged as a solution, where sensitive content is replaced with width-adjusted masking symbols that preserve the original document layout while protecting unauthorized information from disclosure.

[0013] The visual representation of encrypted or redacted content within documents has also been a persistent issue. Traditional methods often replace sensitive content with obvious placeholders or blank spaces, which can disrupt the flow of the document and potentially reveal the presence and extent of hidden information. This can be particularly problematic in situations where the mere knowledge of the existence of sensitive information could be valuable to unauthorized parties. Advanced masking techniques that adjust symbol width to match original text dimensions while using different symbols to indicate varying security levels have been developed to address these concerns.

[0014] Furthermore, the process of specifying which portions of a document should be encrypted and at what security level has traditionally been a manual and time-consuming task. Document authors or security administrators often need to manually mark or tag sensitive sections, which is prone to human error and can be impractical for large volumes of documents. This process becomes even more complex when dealing with dynamic documents that are frequently updated or when security classifications need to be changed over time. The development of artificial intelligence systems capable of automatically identifying sensitive content using machine learning models trained on domain-specific data, including classification markings, compartment identifiers, and security level indicators, represents a significant advancement in addressing these challenges.

[0015] Existing solutions have attempted to address these challenges through various means, such as specialized document viewers, custom file formats, or complex document management systems. However, these approaches often require significant changes to existing workflows, extensive user training, and may not integrate well with standard office productivity tools. This has led to resistance in adoption and reduced effectiveness of security measures in practice. The need for solutions that can convert legacy Department of Defense (DoD) classification markings to modern attribute-based encryption policies while maintaining compatibility with existingdocument formats has become increasingly important for organizations transitioning from traditional security frameworks.

[0016] The lack of intuitive user interfaces for managing document security has been a significant barrier to the widespread adoption of advanced security measures. Many existing systems require users to have a deep understanding of cryptographic concepts or to navigate complex policy definition interfaces. This complexity not only increases the likelihood of misconfiguration but also discourages users from fully utilizing the security features available to them. The development of text decoration methods for specifying security levels, such as using strikethrough formatting, underline styles, font color variations, or font size modifications to indicate different attributes, provides a more intuitive approach that leverages familiar document editing techniques.

[0017] Additionally, the management of encryption keys and access policies across large organizations with dynamic user roles and responsibilities has proven to be a significant challenge. The need for frequent updates to access rights, the onboarding and offboarding of users, and the management of temporary access grants all contribute to the complexity of maintaining an effective document security system. The implementation of offline decryption capabilities with secure hardware modules for local key storage has become essential for maintaining operational continuity while ensuring security in disconnected environments.

[0018] Another critical issue is the performance impact of encryption and decryption operations, particularly when dealing with large documents or high volumes of access requests. The computational overhead of these operations can lead to noticeable delays in document access and editing, potentially impacting user productivity and satisfaction. The development of efficient cryptographic engines that can process selective encryption and decryption requests while maintaining real-time performance has become a key requirement for practical implementation of advanced document security systems.

[0019] In light of these challenges, there is a clear need for innovative solutions that can provide granular, attribute-based encryption for documents while maintaining ease of use, preserving document structure and readability, and integrating seamlessly with existing document workflows. Such solutions must strike a delicate balance between robust security and user-friendly operation, enabling organizations to protect their sensitive information effectively without imposing undue burdens on their users or IT infrastructure. The integration of artificial intelligencefor automated content classification, combined with intuitive user interfaces for manual specification of security attributes, represents a comprehensive approach to addressing these complex requirements.

[0020] The prior art has thus far failed to provide a comprehensive solution that addresses all of these concerns. In particular, existing systems have struggled to offer an easy-to-use interface for identifying which portions of a document should have specific security levels while simultaneously maintaining the appearance and usability of encrypted documents. The absence of automated artificial intelligence systems capable of identifying sensitive content, combined with the lack of seamless integration with popular document editing platforms and offline decryption capabilities, has created a significant gap in the technology landscape. This gap presents a substantial opportunity for innovation in the field of document security, with the potential to revolutionize how organizations manage and protect their sensitive information assets through the implementation of comprehensive attribute-based encryption systems that combine automated content analysis, intuitive user interfaces, and robust security mechanisms.

[0021] SUMMARY

[0022] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0023] According to aspects of the present disclosure, a method, system, and non-transitory computer-readable medium are provided for selectively encrypting and decrypting portions of a document. The method, system, and non-transitory computer-readable medium include receiving a document containing plaintext. The document is analyzed using an artificial intelligence system to identify portions of the plaintext containing sensitive information. The artificial intelligence system comprises machine learning models trained on domain-specific data including classification markings, compartment identifiers, and security level indicators. The artificial intelligence system uses pattern recognition and contextual analysis to identify sensitive content based on semantic understanding and classification rules, employing natural language processing techniques to parse document structure and content, applying multi-layered analysis including syntactic parsing and named entity recognition, generating confidence scores for identified sensitive portions using statistical classification algorithms, and utilizing hierarchical classificationschemes that categorize content based on both explicit security markings and implicit contextual indicators. Predefined security levels or attributes are assigned to the identified portions of plaintext using the artificial intelligence system. The assigning is based on confidence scoring against the domain-specific training data, pattern matching against known classification markings, and semantic analysis of compartment-specific terminology. An encrypt file content request is sent to a cryptographic engine, the request including the document and the assigned security levels or attributes. An encrypted file content response is received from the cryptographic engine, the response including encrypted portions of the plaintext corresponding to the assigned security levels or attributes. An encrypted document is built by replacing the portions of the plaintext corresponding to the assigned security levels or attributes with masking symbols, wherein a width of the masking symbols is adjusted to be approximately the same as a width of the original plaintext, and storing the encrypted portions of the plaintext as metadata in custom properties of the encrypted document. The encrypted document is sent to a client device.

[0024] According to other aspects of the present disclosure, the method, system, and non- transitory computer-readable medium may include one or more of the following features. A request to decrypt the encrypted document may be received. A user associated with the request may be authenticated. Attributes associated with the authenticated user may be determined. A decrypt file content request may be sent to the cryptographic engine, the request including the encrypted document and the user attributes. A decrypted file content response may be received from the cryptographic engine, the response including decrypted portions of the plaintext corresponding to the user attributes. A decrypted document may be built by replacing the masking symbols with the decrypted portions of the plaintext for which the user is authorized. Building the decrypted document may further comprise maintaining the masking symbols for portions of the plaintext for which the user is not authorized. The system may log each instance of decryption and access to encrypted portions of the document, including user identification, accessed portions, and timestamp, to maintain an audit trail of document access.

[0025] The method, system, and non-transitory computer-readable medium may include receiving a document containing Department of Defense (DoD) classification markings. The document may be parsed to identify the DoD classification markings including at least one of Top Secret, Secret, Confidential, or Unclassified designations. The identified DoD classification markings may be converted to corresponding attribute-based encryption policies. The convertedpolicies may be applied to encrypt portions of the document according to the original DoD classification levels. This conversion capability enables organizations to transition from legacy classification systems to modern attribute-based encryption while preserving existing security hierarchies and ensuring compatibility with established document handling procedures.

[0026] The method, system, and non-transitory computer-readable medium may be configured to operate in an offline mode. The offline mode may comprise storing decryption keys locally in a secure hardware module, performing decryption operations without network connectivity, and synchronizing access logs with a central server upon reconnection to a network. The secure hardware module may provide tamper-resistant storage for cryptographic keys and may implement additional security measures such as key expiration and automatic key revocation upon detection of unauthorized access attempts. The offline capability ensures operational continuity in disconnected environments while maintaining strict security controls.

[0027] The masking symbols may be different for different security levels or attributes. Adjusting the width of the masking symbols to be approximately the same as the width of the original plaintext may comprise calculating a width of each portion of the original plaintext to be encrypted, determining a number and type of masking symbols needed to approximate the calculated width, and inserting the determined number and type of masking symbols in place of the original plaintext. The masking symbols may include at least one of solid rectangles, diagonal patterns, dotted patterns, or specialized Unicode characters, with each symbol type corresponding to specific security levels or attributes. The width adjustment process may achieve precision within 10% of the original text width to maintain document formatting and readability.

[0028] The method, system, and non-transitory computer-readable medium may include logging each instance of decryption and access to encrypted portions of the document, including user identification, accessed portions, and timestamp, to maintain an audit trail of document access. Password protection may be applied to the decrypted document. Forensic metadata may be embedded in the decrypted document identifying the user who performed the decryption and the time of decryption. The audit trail may be stored using tamper-evident technologies such as blockchain or distributed ledger systems to ensure integrity and non-repudiation of access records. The logging system may also capture contextual information such as device characteristics, network location, and environmental factors that may influence access control decisions.

[0029] The method, system, and non-transitory computer-readable medium may operate as a Microsoft Office add-in that side-loads with Microsoft Office applications. The add-in may provide encryption and decryption functionality directly within the Microsoft Office application interface without requiring external web-based services. The add-in may integrate seamlessly with existing document workflows, allowing users to apply security attributes through familiar interface elements such as toolbar buttons, context menus, or ribbon controls. The add-in may support realtime collaboration features while maintaining security boundaries, enabling multiple users with different access levels to work on the same document simultaneously.

[0030] The artificial intelligence system may be further configured to identify text decorations applied to portions of the plaintext within the document, wherein the text decorations include at least one of strikethrough formatting, underline styles, font color variations, or font size modifications. The identified text decorations may be mapped to predefined security levels or attributes based on a hierarchical classification scheme. Security levels or attributes may be assigned to the decorated portions of plaintext based on the mapped text decorations. The text decoration mapping may support complex combinations, such as double strikethrough with red font color indicating Top Secret information, while single strikethrough with blue font color may indicate Secret information. The system may provide configurable mapping rules that allow organizations to customize the relationship between text decorations and security attributes according to their specific requirements.

[0031] The artificial intelligence system may employ natural language processing techniques to parse document structure and content, apply multi-layered analysis including syntactic parsing and named entity recognition, generate confidence scores for identified sensitive portions using statistical classification algorithms, and utilize hierarchical classification schemes that categorize content based on both explicit security markings and implicit contextual indicators. The machine learning models may be trained on domain-specific datasets that include government classification standards, industry-specific terminology, and organizational security policies. The Al system may continuously learn and adapt to new patterns of sensitive information through feedback mechanisms and regular model updates, improving accuracy and reducing false positives over time. The confidence scoring mechanism may provide threshold-based filtering to ensure that only content meeting specified certainty levels is automatically classified, with borderline cases flagged for manual review.

[0032] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

[0033] BRIEF DESCRIPTION OF FIGURES

[0034] Non-limiting and non-exhaustive examples are described with reference to the following figures.

[0035] FIG. 1 illustrates a system diagram of a document security system, according to aspects of the present disclosure.

[0036] FIG. 2 depicts an integrated access control policy manager architecture, in accordance with example embodiments.

[0037] FIG. 3 shows a document generation flow diagram, according to an embodiment.

[0038] FIG. 4 illustrates a flowchart for converting classified documents to encrypted documents, according to aspects of the present disclosure.

[0039] FIG. 5 depicts a decryption workflow sequence diagram, in accordance with example embodiments.

[0040] FIG. 6 shows a sequence diagram for encrypting and decrypting document content, according to an embodiment.

[0041] FIG. 7 illustrates an example classified memorandum document, according to aspects of the present disclosure.

[0042] FIG. 8 depicts the memorandum document of FIG. 7 with redacted content, in accordance with example embodiments.

[0043] FIG. 9 shows the memorandum document of FIG. 7 with selective redaction, according to an embodiment.

[0044] FIG. 10 illustrates a flowchart for encrypting a document, according to aspects of the present disclosure.

[0045] FIG. 11 depicts a flowchart for a document decryption process, in accordance with example embodiments.

[0046] FIG. 12 shows a flowchart for converting classification markings to encryption policies, according to an embodiment.

[0047] FIG. 13 illustrates a flowchart for an offline decryption process, according to aspects of the present disclosure.

[0048] FIG. 14 depicts a sequence diagram for secure document generation, in accordance with example embodiments.

[0049] FIG. 15 shows a sequence diagram for document decryption, according to an embodiment.

[0050] FIG. 16 illustrates a detailed system diagram of a document security manager, according to aspects of the present disclosure.

[0051] FIG. 17 depicts a system diagram of an offline decryption system, in accordance with example embodiments.

[0052] FIG. 18 shows a client computing architecture, according to an embodiment.

[0053] FIG. 19 illustrates a server-client network architecture, according to aspects of the present disclosure.

[0054] DETAILED DESCRIPTION

[0055] The following description sets forth exemplary aspects of the present disclosure. It should be recognized, however, that such description is not intended as a limitation on the scope of the present disclosure. Rather, the description also encompasses combinations and modifications to those exemplary aspects described herein.

[0056] A detailed description of systems, devices, and methods consistent with embodiments of the present disclosure is provided below. While several embodiments are described, it should be understood that disclosure is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed herein, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the disclosure.

[0057] In some cases, a document security system may be implemented to selectively encrypt and decrypt portions of documents containing sensitive information. FIG. 1 illustrates an exemplary architecture for such a document security system.

[0058] The document security system may include a Document Security Manager 500. The Document Security Manager 500 may serve as the central component for coordinating document processing, analysis, and security operations. In some cases, the Document Security Manager 500 may receive documents containing plaintext from various sources for processing.

[0059] An Al Analysis Module 502 may be incorporated within the Document Security Manager 500. The Al Analysis Module 502 may employ machine learning models trained on domain-specific data, including classification markings, compartment identifiers, and security level indicators. This specialized training may enable the Al Analysis Module 502 to effectively identify portions of plaintext containing sensitive information.

[0060] The Al Analysis Module 502 may comprise two key components: a Pattern Recognition Engine 504 and a Contextual Analysis Engine 506. The Pattern Recognition Engine 504 may be configured to identify specific patterns, keywords, or structures within the document that may indicate sensitive content. The Contextual Analysis Engine 506 may analyze the semantic context surrounding potentially sensitive information to improve accuracy and reduce false positives.

[0061] By combining pattern recognition and contextual analysis, the Al Analysis Module 502 may identify sensitive content based on semantic understanding and classification rules. This multi-faceted approach may allow for more nuanced and accurate identification of sensitive information compared to simple keyword matching.

[0062] A Security Level Assignment Module 508 may work in conjunction with the Al Analysis Module 502 to assign predefined security levels or attributes to the identified portions of plaintext. The assignment process may involve confidence scoring against the domain-specific training data, pattern matching against known classification markings, and semantic analysis of compartment-specific terminology. This comprehensive approach may help ensure that appropriate security levels are applied to different sections of the document.

[0063] Once security levels have been assigned, an Encryption Request Handler 510 may prepare and send encrypt file content requests to a Cryptographic Engine 514. These requests may include the document and the assigned security levels or attributes for each sensitive portion identified.

[0064] The Cryptographic Engine 514 may perform the actual encryption operations on the sensitive portions of the document. After processing, the Cryptographic Engine 514 may return an encrypted file content response to the Document Security Manager 500. This response may include encrypted versions of the plaintext portions corresponding to the assigned security levels or attributes.

[0065] A Document Builder 512 within the Document Security Manager 500 may then construct the final encrypted document. The Document Builder 512 may replace the portions of plaintext corresponding to the assigned security levels with masking symbols. In some cases, the width of these masking symbols may be adjusted to be approximately the same as the width of the original plaintext. This adjustment may help maintain the overall formatting and visual structure of the document.

[0066] Additionally, the Document Builder 512 may store the encrypted portions of the plaintext as metadata within custom properties of the encrypted document. This approach may allow for efficient storage and retrieval of the encrypted content while maintaining the document's structure.

[0067] After the encrypted document has been built, the Document Security Manager 500 may send the encrypted document to a Client Device 516. The Client Device 516 may represent various types of user devices, such as computers, tablets, or smartphones, where authorized users can access and interact with the secured documents.

[0068] This system architecture may provide a comprehensive approach to document security, leveraging advanced Al techniques for sensitive content identification, flexible security level assignment, and secure encryption processes. By integrating these components, the system may offer robust protection for sensitive information while maintaining document usability and structure.

[0069] In some cases, an Integrated Access Control Policy Manager may be implemented to centralize and coordinate various attribute-based access control (ABAC) policies across different components of a document security system. FIG. 2 illustrates an exemplary architecture for such an Integrated Access Control Policy Manager.

[0070] The Integrated Access Control Policy Manager may serve as a central hub for managing and integrating multiple policy stores and components. This centralized approach may allow for more consistent and efficient application of access control policies across different aspects of the document security system.

[0071] One key component that may interface with the Integrated Access Control Policy Manager is the Application and Data Access ABAC Policy. This policy store may contain rules and attributes specifically related to controlling access to applications and data within the system. The Application and Data Access ABAC Policy may connect to the central manager through adedicated Data Access ABAC Policy link, allowing for seamless integration of these policies into the overall access control framework.

[0072] Another important component in the architecture may be the Perimeter (API) ABAC Policy. This policy store may focus on controlling access at the system's perimeter, particularly for API interactions. The Perimeter (API) ABAC Policy may connect to the central Integrated ABAC Policy Manager through an ABAC Policy link, enabling the system to apply consistent access control rules at both the application level and the API level.

[0073] A Data Analytics ABAC Policy Store may also be incorporated into the architecture. This policy store may contain rules specifically tailored for controlling access to data analytics functions and results. The Data Analytics ABAC Policy Store may interface with the central manager through a Data Security and Governance Platform ABAC Policy connection. This integration may allow the system to apply appropriate access controls to sensitive data and analytics outputs, ensuring that only authorized users can access and manipulate this information.

[0074] The architecture may also include an ABE Policy Store, which may contain attributebased encryption policies. The ABE Policy Store may connect to the Integrated ABAC Policy Manager through an ABE Policy link. This connection may allow the system to coordinate attribute-based encryption policies with other access control policies, providing a comprehensive approach to document security.

[0075] By centralizing these various policy stores and components, the Integrated Access Control Policy Manager may enable more efficient and consistent policy management. This centralized approach may allow for easier updates and modifications to access control policies across the entire system. Additionally, it may facilitate the conversion of different types of access control policies, such as Department of Defense (DoD) classification markings, into corresponding attribute-based encryption policies.

[0076] In some cases, the Integrated Access Control Policy Manager may be configured to convert identified DoD classification markings to corresponding attribute-based encryption policies. This conversion process may involve mapping traditional classification levels (such as Top Secret, Secret, Confidential, or Unclassified) to specific attributes or sets of attributes within the ABE framework. By performing this conversion, the system may maintain the security intent of the original classification while leveraging the flexibility and granularity of attribute-based encryption.

[0077] Once the conversion process is complete, the Integrated Access Control Policy Manager may apply the converted policies to encrypt portions of documents according to the original DoD classification levels. This application may involve coordinating with the Document Security Manager to ensure that the appropriate encryption is applied to each section of the document based on its classification level.

[0078] The centralized nature of the Integrated Access Control Policy Manager may allow for more sophisticated policy combinations and interactions. For example, the system may be able to combine rules from the Application and Data Access ABAC Policy with encryption policies from the ABE Policy Store to create comprehensive security protocols for document access and manipulation.

[0079] Furthermore, the architecture's design may allow for scalability and extensibility. Additional policy stores or components may be added to the system and integrated with the central manager as new security requirements or technologies emerge. This flexibility may help ensure that the document security system can adapt to evolving security needs and regulatory requirements over time.

[0080] In summary, the Integrated Access Control Policy Manager architecture illustrated in FIG. 2 may provide a robust and flexible framework for managing various access control and encryption policies within a document security system. By centralizing policy management and enabling the conversion and application of diverse policy types, this architecture may support more comprehensive and adaptable document security measures.

[0081] In some cases, a document generation flow may be implemented to securely create and encrypt documents within a document security system. FIG. 3 illustrates an exemplary sequence diagram depicting the interactions between key components in such a document generation flow.

[0082] The document generation process may begin with a Web Browser initiating authentication. The Web Browser may send username and password credentials to an Attribute- Based Access Control Application. This initial authentication step may help ensure that only authorized users can access the document generation functionality.

[0083] After successful authentication, the Web Browser may send a request for document report generation to a Document Security Manager. This request may initiate the core document creation and encryption process within the system.

[0084] Upon receiving the document generation request, the Document Security Manager may retrieve application data based on the user's authorization level and the specific report content requirements. This step may involve accessing various data sources and compiling the necessary information for the requested document.

[0085] Once the required data has been gathered, the Document Security Manager may send an Encrypt File Content Request to a Cryptographic Engine. This request may include the compiled document content along with any relevant security attributes or encryption parameters.

[0086] The Cryptographic Engine may process the encryption request and perform the necessary cryptographic operations on the document content. After completing the encryption process, the Cryptographic Engine may return an Encrypted File Content Response to the Document Security Manager.

[0087] Upon receiving the encrypted content, the Document Security Manager may proceed to build the final encrypted document. This process may involve incorporating redaction in visible areas of the document while storing the encrypted ciphertext in the document's custom properties metadata. By storing the encrypted content as metadata, the system may maintain the document's structure and formatting while securing sensitive information.

[0088] Finally, the Document Security Manager may send the Encrypted Document Response back to the Web Browser. This response may contain the fully encrypted and formatted document, ready for secure distribution or storage.

[0089] In some cases, the document generation flow may be implemented as part of a Microsoft Office add-in that side-loads with Microsoft Office applications. This add-in approach may allow the Document Security Manager to operate seamlessly within the Microsoft Office environment, providing encryption and decryption functionality directly within the Microsoft Office application interface.

[0090] By integrating the document security features as an add-in, the system may eliminate the need for external web-based services to perform encryption and decryption operations. This integrated approach may offer several advantages, including improved performance, enhanced security, and a more streamlined user experience.

[0091] The add-in implementation may allow users to initiate the document generation and encryption process directly from within their familiar Microsoft Office applications, such as Word,Excel, or PowerPoint. Users may be able to access the document security features through custom ribbon buttons or menu options added by the add-in.

[0092] When a user initiates the document generation process through the add-in interface, the system may follow a similar flow to that illustrated in FIG. 3. However, instead of using a separate Web Browser for interaction, the Microsoft Office application itself may serve as the client interface.

[0093] The add-in may handle the initial authentication process, potentially leveraging existing Microsoft Office authentication mechanisms or implementing custom authentication flows as needed. Once authenticated, the add-in may communicate directly with the Document Security Manager to initiate the document generation and encryption process.

[0094] Throughout the document generation flow, the add-in may provide user feedback and progress indicators within the Microsoft Office application interface. This integrated approach may help maintain a consistent user experience while ensuring that sensitive document operations remain within the controlled environment of the Microsoft Office application.

[0095] By implementing the document generation flow as a Microsoft Office add-in, the system may provide a seamless and secure document creation and encryption process that integrates tightly with users' existing workflows. This approach may help organizations maintain control over sensitive information while minimizing disruption to users' productivity and familiar software environments.

[0096] In some cases, a document security system may implement a process for converting classified documents with Department of Defense (DoD) markings to documents encrypted using attribute-based encryption (ABE) policies. FIG. 4 illustrates an exemplary flowchart depicting this conversion process.

[0097] The process may begin with a Web Browser uploading a document containing DoD classification markings to a Document Security Manager. This initial step may allow users to securely transfer classified documents into the system for processing and encryption.

[0098] Upon receiving the uploaded document, the Document Security Manager may parse the document to identify the DoD classification markings. This parsing process may involve analyzing the document's content and structure to locate and extract specific classification indicators. The Document Security Manager may be configured to recognize various types of DoDclassification markings, including designations such as Top Secret, Secret, Confidential, or Unclassified.

[0099] After identifying the DoD classification markings, the Document Security Manager may proceed to convert these markings into corresponding ABE marking policies. This conversion process may involve mapping traditional DoD classification levels to specific attributes or sets of attributes within the ABE framework. By translating DoD markings to ABE policies, the system may maintain the security intent of the original classification while leveraging the flexibility and granularity of attribute-based encryption.

[0100] Once the ABE marking policies have been established, the Document Security Manager may send an encrypt file content request to a Cryptographic Engine. This request may include the document content along with the newly created ABE policies derived from the original DoD classification markings.

[0101] The Cryptographic Engine may process the encryption request, applying the specified ABE policies to the appropriate sections of the document. This step may ensure that different portions of the document are encrypted according to their corresponding security levels, as determined by the original DoD classification markings.

[0102] After the encryption process is complete, the Cryptographic Engine may return an encrypted file content response to the Document Security Manager. This response may contain the encrypted versions of the document's sensitive sections, secured according to the ABE policies.

[0103] Upon receiving the encrypted content, the Document Security Manager may proceed to build the final encrypted document. This document building process may involve replacing the original text in visible areas with masking symbols. The system may carefully adjust the width of these masking symbols to approximately match the width of the original text, helping to preserve the document's overall formatting and structure.

[0104] In addition to inserting masking symbols, the Document Security Manager may store the encrypted ciphertext as metadata within the document's custom properties. This approach may allow for efficient storage and retrieval of the encrypted content while maintaining the document's visual integrity.

[0105] Finally, the Document Security Manager may send the encrypted document response back to the Web Browser. This response may contain the fully processed document, with sensitive sections masked and encrypted according to the converted ABE policies.

[0106] By implementing this conversion process, the document security system may provide a seamless method for transforming traditional classified documents into more flexible and granular ABE-protected documents. This approach may allow organizations to maintain compatibility with existing classification systems while benefiting from the advanced security features offered by attribute-based encryption.

[0107] In some cases, a document security system may implement a decryption workflow to selectively decrypt encrypted documents based on user attributes and authorization levels. FIG. 5 illustrates an exemplary sequence diagram depicting the interactions between key components in such a decryption workflow.

[0108] The decryption process may begin with a Web Browser uploading an ABE Encrypted Document to a Document Security Manager for decryption. This initial step may allow users to securely transfer encrypted documents into the system for processing and selective decryption.

[0109] Upon receiving the encrypted document, the Document Security Manager may initiate an authentication process. The Document Security Manager may send an authentication request with username and password credentials to an Attribute-Based Access Control Application. This authentication step may help ensure that only authorized users can access the decryption functionality and may allow the system to determine the specific attributes and access rights associated with the authenticated user.

[0110] After successful authentication, the Document Security Manager may proceed to determine the attributes associated with the authenticated user. These attributes may include factors such as security clearance level, organizational role, or specific project assignments. The determination of user attributes may play a crucial role in deciding which portions of the encrypted document the user may be authorized to access.

[0111] Based on the authenticated user's attributes, the Document Security Manager may send a Decrypt KeyGen Request to a Cryptographic Engine. This request may include information about the user's attributes and the specific document to be decrypted. The Cryptographic Engine may process this request and generate a decryption key tailored to the user's access rights.

[0112] Upon receiving the generated decryption key from the Cryptographic Engine, the Document Security Manager may proceed to send a Decrypt File Content Request to the Cryptographic Engine. This request may include the encrypted document along with the user-specific decryption key. By using a key generated based on the user's attributes, the system may ensure that only authorized portions of the document are decrypted.

[0113] The Cryptographic Engine may process the decryption request, applying the userspecific key to decrypt only those portions of the document that match the user's attributes and access rights. After completing the selective decryption process, the Cryptographic Engine may return a Decrypted File Content Response to the Document Security Manager. This response may contain the decrypted portions of the document corresponding to the user's authorized access level.

[0114] Upon receiving the selectively decrypted content, the Document Security Manager may proceed to build the final decrypted document. This document building process may involve replacing the masking symbols with the decrypted portions of the plaintext for which the user is authorized. Importantly, the Document Security Manager may maintain the masking symbols for portions of the plaintext for which the user is not authorized. This selective replacement may ensure that users can only view the content they are permitted to access while maintaining the security of more sensitive information.

[0115] The document building process may involve careful manipulation of the document structure to seamlessly integrate the decrypted content while preserving the overall formatting and layout. The Document Security Manager may need to consider factors such as text flow, page breaks, and embedded objects to ensure that the partially decrypted document remains coherent and visually consistent.

[0116] Finally, the Document Security Manager may send the Decrypted Document File Response back to the Web Browser. This response may contain the selectively decrypted document, with authorized portions visible as clear text and unauthorized portions remaining masked or redacted. The resulting document may provide users with access to the information they are authorized to view while maintaining the confidentiality of more sensitive content.

[0117] In some cases, the decryption workflow may include additional steps to log and audit the decryption process. The Document Security Manager may record details such as the identity of the user requesting decryption, the specific portions of the document that were decrypted, and the timestamp of the decryption event. This logging process may help organizations maintain a comprehensive audit trail of document access and support compliance with security regulations and internal policies.

[0118] The decryption workflow may also incorporate mechanisms to prevent unauthorized redistribution of decrypted content. For example, the Document Security Manager may apply digital watermarks or other tracking mechanisms to the decrypted portions of the document. These measures may help deter unauthorized sharing and provide a means of tracing the source of any potential leaks.

[0119] By implementing this sophisticated decryption workflow, the document security system may provide a robust method for selectively revealing sensitive information based on user attributes and authorization levels. This approach may allow organizations to maintain finegrained control over access to classified or confidential information while enabling authorized users to efficiently access the content they need to perform their duties.

[0120] In some cases, a document security system may implement a process for encrypting and decrypting document content to protect sensitive information while allowing authorized access. FIG. 6 illustrates an exemplary sequence diagram depicting the interactions between a Document Security Manager and a Cryptographic Engine for handling sensitive document data.

[0121] The process may begin with the Document Security Manager receiving a document containing plaintext content. Upon receipt of the document, the Document Security Manager may initiate an authentication process to verify access permissions. The Document Security Manager may send an authentication request containing username and password credentials to an authentication service or module.

[0122] After successful authentication, the Document Security Manager may proceed to prepare the document for encryption. In some cases, the Document Security Manager may incorporate virus scanning functionality to check files for potential security threats before processing. This additional security measure may help prevent the encryption and distribution of malicious content within the protected document ecosystem.

[0123] Once the document has been verified as safe, the Document Security Manager may send a request to encrypt the file content to the Cryptographic Engine. This request may include the document along with any assigned security levels or attributes that determine how different portions of the document should be encrypted.

[0124] The Cryptographic Engine may be implemented as a Python web API that wraps the NTK library for encryption and decryption operations. This implementation may provide a flexibleand efficient interface for performing cryptographic operations while leveraging the robust security features of the NTK library.

[0125] Upon receiving the encryption request, the Cryptographic Engine may process the document, applying the specified encryption algorithms and security attributes to the appropriate portions of the content. After completing the encryption process, the Cryptographic Engine may return an encrypted file content response to the Document Security Manager.

[0126] The Document Security Manager may then proceed to build the encrypted document. This process may involve replacing sensitive portions of the plaintext with masking symbols. The Document Security Manager may carefully adjust the size and positioning of these masking symbols to match the width of the original text, helping to maintain the document's overall formatting and visual structure.

[0127] In addition to inserting masking symbols, the Document Security Manager may store the encrypted content as metadata within the document's custom properties. This approach may allow for efficient storage and retrieval of the encrypted information while preserving the document's visible structure.

[0128] The Document Security Manager may then store the fully encrypted document, complete with its metadata, in a secure repository for later access and distribution.

[0129] When a user requests access to the encrypted document, the decryption process may begin. The Document Security Manager may first authenticate the user and retrieve their associated security attributes. These attributes may determine which portions of the encrypted document the user may be authorized to access.

[0130] Based on the user's attributes, the Document Security Manager may send a decryption request to the Cryptographic Engine. This request may include the encrypted document along with the user's security attributes.

[0131] The Cryptographic Engine may process the decryption request, using the NTK library to selectively decrypt only those portions of the document that match the user's security attributes. After completing the decryption process, the Cryptographic Engine may return a response containing the decrypted content to the Document Security Manager.

[0132] Upon receiving the selectively decrypted content, the Document Security Manager may rebuild the document. This rebuilding process may involve replacing the masking symbols with the decrypted plaintext for sections the user may be authorized to view. For portions of thedocument that the user may not have permission to access, the Document Security Manager may maintain the masking symbols, effectively redacting that content.

[0133] Throughout this process, the Document Security Manager may take care to preserve the original document's formatting, layout, and structure. By maintaining consistent spacing and positioning of both decrypted content and masking symbols, the system may ensure that the partially decrypted document remains visually coherent and usable.

[0134] This encryption and decryption workflow, as illustrated in FIG. 6, may provide a robust method for protecting sensitive document content while enabling flexible, attribute-based access control. By leveraging the capabilities of the Cryptographic Engine and carefully managing document structure, the system may offer a secure and user-friendly approach to handling confidential information in various document formats.

[0135] In some cases, a document security system may utilize example classified documents to demonstrate and test its capabilities without relying on actual classified information. FIG. 7 illustrates an exemplary classified memorandum that may be used for such purposes.

[0136] The document depicted in FIG. 7 represents a memorandum from the Office of the Secretary of Defense in Washington, DC. The memorandum may be marked as "TOP SECRET" at the top of the document, indicating the highest level of classification. This prominent marking may serve as an immediate visual cue to handlers regarding the sensitivity of the document's contents.

[0137] The memorandum may include a header containing "OFFICE OF THE SECRETARY OF DEFENSE WASHINGTON, DC" and may be dated IUNE 15, 2024. This header information may provide context for the document's origin and timeframe.

[0138] The document may be addressed to "DASD (I&S)", which may represent a specific department or individual within the defense structure. The subject line of the memorandum may read "Security Awareness of Classification Markings", directly relating to the document's purpose of explaining different classification levels.

[0139] The main body of the memorandum may contain four numbered paragraphs, each describing a different classification level and how portions of documents may be marked with corresponding designations. This structure may allow the document to serve as both an example of classification markings and an instructional tool for understanding their usage.

[0140] The first paragraph may explain Top Secret information, indicating that such portions may be marked with "TS" in parentheses. The second paragraph may describe Secret information, using "S" as the corresponding marking. The third paragraph may cover Classified information, designated by "C", while the fourth paragraph may address Unclassified information, marked with "U".

[0141] At the bottom of the document, "ASD (C31)" may appear, potentially indicating the author or responsible office. Additionally, classification information may state "Classified by: Multiple Sources Declassify On: OADR", providing metadata about the document's classification status and declassification instructions.

[0142] This example classified memorandum may serve multiple purposes within the document security system. For instance, the Pattern Recognition Engine may use this document to train on identifying specific classification markings and their placement within a document structure. The engine may learn to recognize the "TOP SECRET" header, the individual paragraph markings, and the classification metadata at the document's footer.

[0143] Similarly, the Contextual Analysis Engine may utilize this example to understand the relationship between classification levels and content. By analyzing the explanatory text in each paragraph alongside its corresponding classification marking, the engine may develop a more nuanced understanding of how sensitive information may be described and categorized.

[0144] The Security Level Assignment Module may leverage this example to refine its attribute assignment processes. While the memorandum uses traditional classification levels, the module may adapt these concepts to more specific attributes related to fictional scenarios, such as warp engine compartments in a Star Trek universe. For example, the module may map "TOP SECRET" to the highest level of warp engine access, while "UNCLASSIFIED" may correspond to general crew areas.

[0145] By using synthetic data inspired by fictional scenarios like Star Trek, the document security system may demonstrate its capabilities without risking exposure of actual classified information. This approach may allow for robust testing and training of the system's components while maintaining a clear separation from real-world sensitive data.

[0146] The example memorandum may also illustrate how classification markings may be applied at various levels within a single document. This granularity may be crucial for the system's ability to selectively encrypt and decrypt portions of documents based on user attributes and accesslevels. The Security Level Assignment Module may use this example to develop more sophisticated mapping between traditional classification levels and specific access attributes for crew members in the fictional scenario.

[0147] In practice, the document security system may process documents with similar structures to the example memorandum, identifying classification markings, analyzing content, and assigning appropriate security levels or attributes. This capability may enable the system to handle a wide range of document types and classification schemes, adapting to both real-world and fictional scenarios as needed for demonstration or operational purposes.

[0148] In some cases, a document security system may implement redaction techniques to protect sensitive information while maintaining the overall structure and readability of a document. FIG. 8 illustrates an exemplary redacted memorandum that demonstrates these capabilities.

[0149] The document depicted in FIG. 8 represents a memorandum from the Office of the Secretary of Defense in Washington, DC. The memorandum retains its "TOP SECRET" marking at the top, indicating the highest level of classification. This preservation of the classification marking may ensure that handlers are immediately aware of the document's sensitivity, even in its redacted form.

[0150] The memorandum maintains its structural elements, including the header with "OFFICE OF THE SECRETARY OF DEFENSE WASHINGTON, DC" and the subject line regarding "Security Awareness of Classification Markings". By preserving these non-sensitive portions, the document security system may allow readers to understand the context and origin of the memorandum without exposing protected information.

[0151] The main body of the memorandum contains four numbered paragraphs, each with varying levels of redaction. The Document Security Manager may be configured to analyze the content of each paragraph and determine which portions require redaction based on their sensitivity level. In this example, the system has applied different levels of redaction to each paragraph, demonstrating its ability to handle varying security requirements within a single document.

[0152] To implement the redaction, the Document Security Manager may be configured to replace sensitive text with black rectangular blocks. These redaction blocks may serve multiple purposes within the document security system. Firstly, they may visually indicate to readers that information has been removed due to security concerns. Secondly, they may help maintain the document's overall formatting and structure.

[0153] The Document Security Manager may be configured to calculate the width of each portion of the original plaintext that requires encryption or redaction. This calculation may involve analyzing factors such as font size, character count, and formatting attributes of the original text. By determining the precise dimensions of the text to be redacted, the system may ensure that the redaction blocks accurately represent the space occupied by the sensitive information.

[0154] Based on these calculations, the Document Security Manager may determine the number and type of masking symbols needed to approximate the calculated width of the original text. In the case of the black rectangular blocks seen in FIG. 8, the system may generate redaction symbols that closely match the dimensions of the removed text. This approach may help preserve the document's original layout, including line breaks, paragraph spacing, and overall page structure.

[0155] The Document Security Manager may then insert the determined number and type of masking symbols in place of the original plaintext. This insertion process may involve careful manipulation of the document's content to ensure that the redaction blocks align properly with the surrounding text and maintain consistent spacing.

[0156] In some cases, the masking symbols may be different for different security levels or attributes. While FIG. 8 demonstrates the use of uniform black rectangular blocks, the document security system may be capable of employing various types of redaction symbols. For example, different colors, patterns, or even textual indicators may be used to denote varying levels of classification or different types of protected information.

[0157] By employing these sophisticated redaction techniques, the document security system may achieve a balance between information protection and document usability. The redacted memorandum in FIG. 8 demonstrates how sensitive content can be effectively obscured while maintaining the document's overall structure and readability.

[0158] The preservation of document formatting may be particularly important in scenarios where the layout itself may convey meaningful information. For instance, in the case of the memorandum, the numbered paragraph structure and the relative length of each paragraph may provide context even when the specific content may be redacted. By maintaining these structural elements, the document security system may allow authorized personnel to glean useful information from the document's organization, even if they may not have access to all of the specific details.

[0159] At the bottom of the redacted memorandum, the classification information stating "Classified by: Multiple Sources Declassify On: OADR" remains visible. This retention of metadata may be crucial for document management and compliance purposes, allowing handlers to understand the document's classification status and declassification instructions without exposing the protected content.

[0160] The redaction approach demonstrated in FIG. 8 may offer several advantages for document security. By replacing sensitive text with visually distinct blocks rather than simply removing the content, the system may prevent unauthorized individuals from inferring information based on the absence or presence of redactions. Additionally, the consistent application of redaction blocks may make it more difficult for observers to estimate the amount or nature of the redacted information based on the size or shape of the redactions.

[0161] In practice, the document security system's redaction capabilities may extend beyond simple black-box redactions. The system may be capable of applying more nuanced redaction techniques based on user attributes and access levels. For example, users with different security clearances may see varying levels of redaction when accessing the same document, with the Document Security Manager dynamically adjusting the visible content based on each user's authorization level.

[0162] This flexible approach to redaction may allow organizations to implement granular access control policies while maintaining a single version of a document. Rather than creating multiple versions of a document with different levels of redaction, the system may dynamically apply redactions based on user attributes, potentially reducing administrative overhead and minimizing the risk of version control issues.

[0163] The redaction techniques demonstrated in FIG. 8 may be applicable to a wide range of document types and formats. While the example shows a text-based memorandum, similar principles may be applied to more complex documents containing tables, images, or other nontextual elements. The Document Security Manager may be capable of analyzing and redacting various content types while preserving the overall structure and formatting of the original document.

[0164] In summary, the redacted memorandum example in FIG. 8 illustrates the document security system's ability to protect sensitive information through intelligent redaction techniques. By carefully calculating and applying redaction blocks, the system may maintain documentstructure and readability while effectively obscuring protected content. This approach may offer a flexible and efficient method for managing access to classified or sensitive information across various document types and security levels.

[0165] In some cases, a document security system may implement selective redaction techniques to protect sensitive information while preserving the overall structure and readability of a document. FIG. 9 illustrates an exemplary selectively redacted memorandum that demonstrates these sophisticated capabilities.

[0166] The document depicted in FIG. 9 represents a memorandum from the Office of the Secretary of Defense in Washington, DC. The memorandum retains its "TOP SECRET" marking at the top, indicating the highest level of classification. This preservation of the classification marking may ensure that handlers are immediately aware of the document's sensitivity, even in its partially redacted form.

[0167] The memorandum maintains its structural elements, including the header with "OFFICE OF THE SECRETARY OF DEFENSE WASHINGTON, DC" and the subject line regarding "Security Awareness of Classification Markings". By preserving these non-sensitive portions, the document security system may allow readers to understand the context and origin of the memorandum without exposing all protected information.

[0168] The main body of the memorandum contains four numbered paragraphs, each with varying levels of classification and redaction. This structure demonstrates the system's ability to handle multiple security levels within a single document, a key feature of the Document Security Manager's capabilities.

[0169] The first paragraph appears fully redacted and replaced with black masking symbols. These masking symbols may be carefully sized and positioned to maintain the same width as the original text. This precise replacement may help preserve the document's formatting and prevent unauthorized individuals from inferring information based on the layout or length of redacted sections.

[0170] The second paragraph contains information marked as "Secret", while the third paragraph contains "Classified" information. The fourth paragraph is labeled as "Unclassified". This varying level of classification within a single document may demonstrate the flexibility of the Security Level Assignment Module in applying different security attributes to distinct portions of text.

[0171] The Document Security Manager may be configured to analyze the content of each paragraph using the Al Analysis Module. The Pattern Recognition Engine within the Al Analysis Module may identify specific classification markings or keywords indicating sensitivity levels. Simultaneously, the Contextual Analysis Engine may evaluate the semantic context of each paragraph to determine its appropriate classification level.

[0172] Based on this analysis, the Security Level Assignment Module may assign predefined security levels or attributes to each paragraph. These assignments may then be used by the Encryption Request Handler to determine which portions of the document require encryption or redaction.

[0173] The Document Builder may then construct the redacted document by replacing sensitive text with black masking symbols. In the case of the first paragraph, which may contain the most sensitive information, the entire content may be replaced with these symbols. For the other paragraphs, the visible text may represent content that has been deemed safe for viewing at lower classification levels.

[0174] A classification marker C31 may be visible at the bottom of the document. This marker may serve as an additional indicator of the document's overall classification level or may provide information about the specific compartment or category to which the document belongs. The retention of such markers may be crucial for document management and compliance purposes, allowing handlers to understand the document's classification status without exposing the protected content.

[0175] The Cryptographic Engine may play a crucial role in this process by encrypting the sensitive portions of the document. The encrypted content may be stored as metadata within the document's custom properties, allowing for secure storage and potential future decryption by authorized users.

[0176] The selective redaction approach demonstrated in FIG. 9 may offer several advantages for document security. By applying different levels of redaction based on classification levels, the system may allow for more granular access control. Users with different security clearances may see varying amounts of visible text when accessing the same document, with the Document Security Manager dynamically adjusting the visible content based on each user's authorization level.

[0177] This flexible approach to redaction may allow organizations to implement sophisticated access control policies while maintaining a single version of a document. Rather than creating multiple versions of a document with different levels of redaction, the system may dynamically apply redactions based on user attributes, potentially reducing administrative overhead and minimizing the risk of version control issues.

[0178] The selective redaction techniques demonstrated in FIG. 9 may be applicable to a wide range of document types and formats. While the example shows a text-based memorandum, similar principles may be applied to more complex documents containing tables, images, or other nontextual elements. The Document Security Manager may be capable of analyzing and selectively redacting various content types while preserving the overall structure and formatting of the original document.

[0179] In practice, the Client Device may receive the selectively redacted document from the Document Security Manager. Depending on the user's security clearance and attributes, the Client Device may display different levels of redacted content. For users with the highest level of clearance, the document may appear with minimal or no redaction, while users with lower clearance levels may see more extensive redaction.

[0180] The selective redaction capabilities of the document security system may extend beyond simple black-box redactions. The system may be capable of applying more nuanced redaction techniques based on specific security attributes. For example, certain words or phrases may be redacted while leaving surrounding context visible, or entire sections may be replaced with summary text appropriate for lower clearance levels.

[0181] In summary, the selectively redacted memorandum example in FIG. 9 illustrates the document security system's ability to protect sensitive information through intelligent and flexible redaction techniques. By carefully analyzing document content, assigning security levels, and applying targeted redactions, the system may maintain document structure and readability while effectively managing access to classified or sensitive information across various security levels and user attributes.

[0182] In some cases, a document security system may implement a process for encrypting sensitive documents to protect confidential information. FIG. 10 illustrates an exemplary flowchart depicting the steps involved in such an encryption process.

[0183] The encryption process may begin with a step 100, where a document containing plaintext may be received by the system. This initial step may involve the upload or transfer of an unencrypted document into the secure environment of the document security system.

[0184] Following the receipt of the plaintext document, the process may advance to a step 102, where the Document Security Manager may receive the document containing plaintext. The Document Security Manager may serve as the central component coordinating the various stages of the encryption process.

[0185] Once the Document Security Manager has received the plaintext document, the process may proceed to a step 104, where the document may be analyzed using an Al system. The Al Analysis Module within the Document Security Manager may be responsible for this analysis. In some cases, the Al Analysis Module may utilize Azure OpenAI as the actual Al model subscription for processing the document content. This integration of a sophisticated Al model may enable more nuanced and context-aware analysis of the document's sensitive information.

[0186] The Al Analysis Module may employ both the Pattern Recognition Engine and the Contextual Analysis Engine to identify portions of the document that contain sensitive information. The Pattern Recognition Engine may scan the document for specific keywords, phrases, or structural elements that may indicate the presence of confidential data. Simultaneously, the Contextual Analysis Engine may evaluate the semantic context surrounding potentially sensitive information, helping to reduce false positives and improve the accuracy of the identification process.

[0187] After the Al system has completed its analysis, the process may move to a step 106, where security levels may be assigned to the identified portions of the document. The Security Level Assignment Module may be responsible for this task, leveraging the results from the Al Analysis Module to determine appropriate security classifications for different sections of the document.

[0188] The security level assignment process may involve a complex evaluation of various factors, including the nature of the identified sensitive information, the document's overall context, and predefined security policies. The Security Level Assignment Module may map the identified sensitive content to specific security attributes or levels, which may later guide the encryption process.

[0189] Once security levels have been assigned, the process may advance to a step 108, where an encrypt file content request may be sent. The Encryption Request Handler within the Document Security Manager may be responsible for preparing and sending this request to the Cryptographic Engine. The request may include the document along with the assigned security levels or attributes for each identified sensitive portion.

[0190] Following the encryption request, the process may proceed to a step 110, where an encrypted file content response may be received. The Cryptographic Engine may process the encryption request and return the encrypted versions of the sensitive document portions to the Document Security Manager.

[0191] With the encrypted content in hand, the process may move to a step 112, where an encrypted document may be built. The Document Builder component of the Document Security Manager may be responsible for constructing the final encrypted document. This step may involve replacing the original plaintext of sensitive portions with encrypted content or masking symbols, while maintaining the document's overall structure and formatting.

[0192] In some cases, the Document Security Manager may utilize the Apache POI library for manipulating Microsoft Office suite documents during this building process. The Apache POI library may provide robust capabilities for reading, writing, and modifying various Microsoft Office file formats, allowing the Document Security Manager to seamlessly integrate encrypted content into complex document structures.

[0193] The document building process may involve careful manipulation of the document's content to ensure that encrypted portions are properly integrated without disrupting the overall layout or readability of the document. The Document Builder may need to consider factors such as text flow, page breaks, and embedded objects to maintain the document's visual integrity while securing sensitive information.

[0194] Finally, the encryption process may conclude with a step 114, where the encrypted document may be sent to the Client Device. This step may involve the secure transmission of the newly encrypted document back to the user's device or to a designated secure storage location.

[0195] Throughout this encryption process, the Document Security Manager may maintain strict control over the document's sensitive content, ensuring that each step of the analysis, security level assignment, and encryption is performed within the secure confines of the system. By leveraging advanced Al capabilities and robust document manipulation tools, the system mayprovide a comprehensive approach to protecting sensitive information while maintaining document usability and structure.

[0196] The integration of Azure OpenAI for Al processing and Apache POI for document manipulation may represent a sophisticated combination of cutting-edge technologies within the document security system. This approach may allow for highly accurate identification of sensitive content across a wide range of document types and formats, while ensuring seamless integration of encryption measures into complex document structures.

[0197] In practice, this encryption process may be applied to various types of documents, from simple text files to complex multi-media presentations. The flexibility of the Al Analysis Module and the Document Builder, coupled with the robust encryption capabilities of the Cryptographic Engine, may allow the system to handle a diverse array of document formats and security requirements.

[0198] The encrypted document produced by this process may maintain its original structure and formatting, with sensitive portions either replaced by encrypted content or masked with symbols. This approach may allow authorized users to still understand the general layout and context of the document, even if they may not have access to all encrypted sections. The granular nature of the encryption process, guided by the Al-driven analysis and security level assignment, may enable highly targeted protection of sensitive information within larger documents.

[0199] In some cases, a document security system may implement a process for decrypting encrypted documents while maintaining security and access control. FIG. 11 illustrates an exemplary flowchart depicting the steps involved in such a decryption process.

[0200] The decryption process may begin with a step 200, which leads to a step 202 where a request to decrypt an encrypted document may be received by the Document Security Manager. This initial step may involve a user or system initiating a request to access a previously encrypted document.

[0201] Following the receipt of the decryption request, the process may advance to a step 204, where the Document Security Manager may authenticate a user associated with the request. The authentication process may involve verifying the user's credentials, such as username and password, or utilizing more advanced authentication methods like multi-factor authentication or biometric verification.

[0202] Once the user has been authenticated, the process may proceed to a step 206, where the Document Security Manager may determine attributes of the authenticated user. These attributes may include factors such as the user's security clearance level, organizational role, project assignments, or other relevant access control parameters. The determination of user attributes may play a crucial role in deciding which portions of the encrypted document the user may be authorized to access.

[0203] After the user attributes have been determined, the process may move to a step 208, where the Document Security Manager may send a decrypt file content request to the Cryptographic Engine. This request may include the encrypted document along with the user's attributes, allowing the Cryptographic Engine to selectively decrypt only those portions of the document that match the user's authorization level.

[0204] The process may then advance to a step 210, where the Document Security Manager may receive a decrypted file content response from the Cryptographic Engine. This response may contain the decrypted portions of the document corresponding to the user's authorized access level, while leaving other sections encrypted.

[0205] With the selectively decrypted content in hand, the process may proceed to a step 212, where the Document Security Manager may build a decrypted document. The Document Builder component may be responsible for constructing the final decrypted document, integrating the decrypted portions with any remaining encrypted or redacted sections.

[0206] Finally, the decryption process may conclude with a step 214, where the Document Security Manager may replace masking symbols with authorized content. In this step, the system may carefully substitute the previously inserted masking symbols (used to maintain document structure in the encrypted version) with the corresponding decrypted text that the user may be authorized to view.

[0207] Throughout this decryption process, the Document Security Manager may maintain strict control over the document's sensitive content, ensuring that each step of the authentication, attribute determination, and selective decryption may be performed within the secure confines of the system. By leveraging user attributes and granular access control, the system may provide a comprehensive approach to protecting sensitive information while allowing authorized users to access the content they need.

[0208] In some cases, the Document Security Manager may be configured to apply password protection to the decrypted document. This additional layer of security may help prevent unauthorized access to the decrypted content, even if the document may be inadvertently shared or accessed by an unauthorized user. The password protection may be applied dynamically, based on the user's attributes or organizational security policies.

[0209] The Document Security Manager may also be configured to log each instance of decryption and access to encrypted portions of the document. This logging process may create a comprehensive audit trail, recording details such as the identity of the user requesting decryption, the specific portions of the document that were decrypted, and the timestamp of the decryption event. This detailed logging may help organizations maintain compliance with security regulations and internal policies, as well as provide valuable insights into document access patterns and potential security risks.

[0210] Furthermore, the Document Security Manager may be configured to embed forensic metadata in the decrypted document. This metadata may include information identifying the user who performed the decryption, the time of decryption, and potentially other relevant details such as the user's location or device information. The embedding of forensic metadata may serve multiple purposes, including enhancing traceability, deterring unauthorized sharing, and providing crucial information for potential security investigations.

[0211] The decryption process, as illustrated in FIG. 11, may demonstrate the system's ability to balance security requirements with user access needs. By selectively decrypting only the portions of the document that a user may be authorized to view, the system may maintain the confidentiality of sensitive information while still allowing users to access the content necessary for their work.

[0212] The granular nature of the decryption process, guided by user attributes and sophisticated access control mechanisms, may enable highly targeted revelation of sensitive information within larger documents. This approach may be particularly valuable in scenarios where documents contain information with varying levels of sensitivity, or where different users or roles may require access to different subsets of the document's content.

[0213] In practice, the decryption process may be applied to various types of documents, from simple text files to complex multi-media presentations. The flexibility of the Document SecurityManager, coupled with the robust decryption capabilities of the Cryptographic Engine, may allow the system to handle a diverse array of document formats and security requirements.

[0214] The decrypted document produced by this process may maintain the original structure and formatting of the encrypted version, with previously masked or encrypted portions now replaced with the authorized decrypted content. This approach may allow users to seamlessly work with the decrypted document, maintaining the context and layout of the original while only revealing the information they may be authorized to access.

[0215] In some cases, a document security system may implement a process for converting Department of Defense (DoD) classification markings to attribute-based encryption (ABE) policies. FIG. 12 illustrates an exemplary flowchart depicting the steps involved in such a conversion process.

[0216] The conversion process may begin with a step 300, which leads to a step 302 where a document with DoD classification markings may be received by the Document Security Manager. This initial step may involve the upload or transfer of a classified document into the secure environment of the document security system. The document may contain various levels of classification markings, such as Top Secret, Secret, Confidential, or Unclassified, as well as additional compartment or handling instructions.

[0217] Following the receipt of the classified document, the process may advance to a step 304, where the Document Security Manager may parse the document to identify the DoD classification markings. The parsing process may involve a detailed analysis of the document's content, structure, and metadata to locate and extract specific classification indicators. The Al Analysis Module may play a crucial role in this step, leveraging both the Pattern Recognition Engine and the Contextual Analysis Engine to accurately identify and categorize the various classification markings within the document.

[0218] The Pattern Recognition Engine may be configured to scan the document for specific keywords, phrases, or structural elements that indicate different levels of classification. For example, the engine may be trained to recognize standard DoD classification headers, paragraph markings, or footer notations. Simultaneously, the Contextual Analysis Engine may evaluate the semantic context surrounding these markings, helping to disambiguate potential classification indicators and reduce false positives.

[0219] Once the DoD classification markings have been identified, the process may proceed to a step 306, where the identified markings may be converted to ABE policies. This conversion step may be a complex process that involves mapping traditional DoD classification levels and compartments to corresponding attributes within the ABE framework. The Security Level Assignment Module may be responsible for this conversion, utilizing predefined mapping rules and potentially leveraging machine learning algorithms to determine the most appropriate ABE policies for each identified classification marking.

[0220] The conversion process may involve more than a simple one-to-one mapping of classification levels to attributes. In some cases, a single DoD classification marking may translate to multiple ABE attributes, or conversely, multiple DoD markings may be consolidated into a single, more complex ABE policy. The system may need to consider not only the explicit classification levels but also any additional handling instructions, dissemination controls, or compartment designations present in the original DoD markings.

[0221] After the ABE policies have been generated, the process may advance to a step 308, where the converted policies may be applied to encrypt portions of the document. The Encryption Request Handler may prepare and send encryption requests to the Cryptographic Engine, specifying which portions of the document should be encrypted according to which ABE policies. This step may involve a granular approach to encryption, where different sections, paragraphs, or even individual sentences within the document may be encrypted with different ABE policies based on their original DoD classification markings.

[0222] The Cryptographic Engine may process these encryption requests, applying the specified ABE policies to the appropriate sections of the document. This encryption process may ensure that different portions of the document are secured according to their corresponding security levels, as determined by the original DoD classification markings and the converted ABE policies.

[0223] Finally, the conversion process may conclude with a step 310, where the Document Security Manager may generate an encrypted document with the ABE policies applied. The Document Builder may be responsible for constructing this final encrypted document, integrating the encrypted portions with any unclassified or lower-sensitivity content that may remain in plaintext.

[0224] The resulting document may maintain its original structure and formatting, with classified sections either replaced by encrypted content or masked with symbols. The ABE policiesmay be embedded within the document's metadata or associated with the document in the system's secure storage. This approach may allow for flexible access control, where users with different sets of attributes may be able to decrypt and view different portions of the document based on their authorization level.

[0225] Throughout this conversion process, the Document Security Manager may maintain strict control over the document's sensitive content, ensuring that each step of the analysis, conversion, and encryption may be performed within the secure confines of the system. By leveraging advanced Al capabilities for classification marking identification and sophisticated ABE policy mapping, the system may provide a comprehensive approach to translating traditional DoD security classifications into more flexible and granular attribute-based access controls.

[0226] The conversion from DoD classification markings to ABE policies may offer several advantages for document security and access control. ABE policies may allow for more nuanced and dynamic access control decisions, potentially reducing over-classification and enabling more efficient information sharing within authorized groups. Additionally, the ABE framework may be more easily integrated with modem digital systems and may provide greater flexibility in managing access across different platforms and organizational boundaries.

[0227] Tn practice, this conversion process may be applied to a wide range of classified documents, from simple memos to complex technical reports or operational plans. The flexibility of the Al Analysis Module in identifying various types of classification markings, coupled with the sophisticated policy conversion and encryption capabilities, may allow the system to handle diverse document formats and complex classification schemes.

[0228] The resulting ABE-encrypted document may offer enhanced security and access control capabilities compared to traditional classified documents. For example, access to specific portions of the document may be dynamically granted or revoked based on changes in user attributes or security policies, without the need to re-classify or re-distribute the entire document. This granular control may help organizations balance security requirements with the need for efficient information sharing and collaboration.

[0229] In some cases, a document security system may implement an offline decryption process to enable secure access to encrypted documents without requiring constant network connectivity. FIG. 13 illustrates an exemplary flowchart depicting the steps involved in such an offline decryption process.

[0230] The offline decryption process may begin with a step 400, which leads to a step 402 where the system may enter offline mode. This initial step may involve the Document Security Manager recognizing a loss of network connectivity or deliberately switching to an offline state to enable secure document access in environments where network access may be restricted or unavailable.

[0231] Following the entry into offline mode, the process may advance to a step 404, where decryption keys may be stored in secure hardware. The Document Security Manager may be configured to store these decryption keys locally in a secure hardware module. This secure storage may be crucial for maintaining the confidentiality and integrity of the decryption keys even when the system may be operating in potentially vulnerable offline environments.

[0232] The secure hardware module may employ various security measures to protect the stored decryption keys. These measures may include hardware-based encryption, tamper-resistant packaging, or secure enclaves within the processor architecture. By leveraging specialized hardware security features, the Document Security Manager may provide a robust layer of protection for the sensitive decryption keys, mitigating the risk of unauthorized access or key extraction attempts.

[0233] Once the decryption keys have been securely stored, the process may proceed to a step 406, where the system may perform decryption without network connectivity. The Document Security Manager may be configured to carry out decryption operations entirely within the local environment, without requiring any communication with external servers or services.

[0234] This offline decryption capability may be particularly valuable in scenarios where network access may be unreliable, restricted, or potentially compromised. For example, in military or government applications, personnel may need to access classified documents in field operations where secure network connectivity cannot be guaranteed. Similarly, in corporate environments, employees may require access to sensitive documents while traveling or working in locations with limited internet access.

[0235] The offline decryption process may leverage the locally stored decryption keys and the secure hardware module to decrypt document content. The Document Security Manager may implement sophisticated key management and access control mechanisms to ensure that only authorized users can initiate decryption operations, even in the offline state. These mechanismsmay include local authentication processes, such as password verification or biometric checks, to validate the user's identity and access rights before allowing decryption to proceed.

[0236] From the decryption step, the process may flow to a decision point 408 that checks whether a network connection may be available. This decision point may represent an ongoing monitoring process where the Document Security Manager periodically checks for the restoration of network connectivity.

[0237] If no network connection may be available (following the "No" path from decision point 408), the process may return to step 406 to continue performing decryption operations without connectivity. This loop may allow the system to maintain offline functionality for extended periods, enabling users to access and work with encrypted documents as needed, regardless of network status.

[0238] When a network connection becomes available (following the "Yes" path from decision point 408), the process may advance to a step 410, where access logs may be synchronized with a central server. The Document Security Manager may be configured to perform this synchronization process, ensuring that all offline document access and decryption activities may be properly recorded and centralized for auditing and security monitoring purposes.

[0239] The synchronization of access logs may involve transmitting detailed records of all decryption events that occurred during the offline period. These logs may include information such as the identity of users who accessed encrypted documents, the specific documents or portions of documents that were decrypted, timestamps of decryption events, and potentially other relevant metadata such as the device used for decryption or the physical location where the decryption occurred.

[0240] By maintaining and synchronizing these comprehensive access logs, the document security system may provide organizations with a complete audit trail of document access, even when users may be operating in offline environments. This capability may be crucial for maintaining regulatory compliance, detecting potential security breaches, and ensuring accountability in the handling of sensitive information.

[0241] The offline decryption process, as illustrated in FIG. 13, may demonstrate the system's ability to balance security requirements with the need for flexible document access across various operational scenarios. By enabling secure offline decryption while maintaining rigorous access controls and comprehensive logging, the Document Security Manager may provide a robustsolution for organizations that need to protect sensitive information while supporting mobile or disconnected workflows.

[0242] In practice, the offline decryption process may be applied to various types of encrypted documents, from simple text files to complex multi-media presentations. The flexibility of the Document Security Manager, coupled with the secure hardware-based key storage and offline decryption capabilities, may allow the system to handle a diverse array of document formats and security requirements, even in challenging network environments.

[0243] The ability to perform decryption operations without network connectivity, while still maintaining strong security measures and comprehensive audit trails, may represent a significant advancement in document security systems. This capability may enable organizations to extend the reach of their secure document ecosystems beyond the confines of traditional network boundaries, supporting secure information access and collaboration in a wide range of operational contexts.

[0244] In some cases, a document security system may implement a secure document generation process to create and encrypt sensitive documents while maintaining strict access controls. FIG. 14 illustrates an exemplary sequence diagram depicting the interactions between key components in such a secure document generation workflow.

[0245] The secure document generation process may begin with an authentication step. The Web Browser may initiate this process by sending authentication credentials, typically a username and password, to the Attribute-Based Access Control Application. This initial authentication step may serve as a crucial security measure, ensuring that only authorized users can access the document generation functionality. The Attribute-Based Access Control Application may verify the provided credentials against its user database, potentially employing additional security measures such as multi-factor authentication or checking for specific user attributes required for document creation.

[0246] Following successful authentication, the Web Browser may proceed to send a request for document report generation to the Document Security Manager. This request may contain specific parameters or criteria for the document to be generated, such as the type of report, date ranges, or other relevant data points. The Document Security Manager may serve as the central coordinator for the document generation and encryption process, orchestrating the interactions between various system components.

[0247] Upon receiving the document generation request, the Document Security Manager may initiate a data retrieval process. The Document Security Manager may access various data sources and compile the necessary information based on the user's authorization level and the specific report content requirements. This step may involve complex data aggregation and filtering processes to ensure that only appropriate and authorized information may be included in the generated document.

[0248] Once the required data has been gathered and processed, the Document Security Manager may prepare the document for encryption. The Document Security Manager may send an Encrypt File Content Request to the Cryptographic Engine. This request may include the compiled document content along with any relevant security attributes or encryption parameters derived from the user's access rights and the nature of the information contained in the document.

[0249] The Cryptographic Engine may serve as the system's dedicated component for performing cryptographic operations. Upon receiving the encryption request, the Cryptographic Engine may apply sophisticated encryption algorithms to secure the sensitive portions of the document content. The encryption process may involve the use of advanced cryptographic techniques, potentially including attribute-based encryption (ABE) to enable fine-grained access control based on user attributes.

[0250] After completing the encryption process, the Cryptographic Engine may return an Encrypted File Content Response to the Document Security Manager. This response may contain the encrypted versions of the sensitive document portions, secured according to the specified encryption parameters and security attributes.

[0251] Upon receiving the encrypted content, the Document Security Manager may proceed to build the final encrypted document. This document building process may involve several complex steps to ensure the security and usability of the resulting document. The Document Security Manager may incorporate redaction in visible areas of the document, replacing sensitive plaintext with masking symbols or other visual indicators of encrypted content. These redactions may be carefully applied to maintain the document's overall structure and readability while clearly indicating the presence of protected information.

[0252] Simultaneously, the Document Security Manager may store the encrypted ciphertext in the document's custom properties metadata. This approach may allow for the secure storage of encrypted content within the document itself, without exposing the sensitive information in thevisible document structure. By utilizing custom properties, the system may maintain a seamless integration between the visible document content and the encrypted data, facilitating easier management and distribution of secure documents.

[0253] The document building process may require careful handling of various document elements, including text, images, tables, and other formatting features. The Document Security Manager may need to ensure that the incorporation of redacted areas and the storage of encrypted content do not disrupt the document's layout or compromise its integrity.

[0254] Finally, after the encrypted document has been fully constructed, the Document Security Manager may send the Encrypted Document Response back to the Web Browser. This response may contain the completed secure document, with sensitive areas redacted in the visible content and the corresponding encrypted data securely stored within the document's metadata.

[0255] The secure document generation process, as illustrated in FIG. 14, may demonstrate the system's ability to create highly secure documents while maintaining usability and preserving document structure. By leveraging the specialized capabilities of each component - from the access control application to the cryptographic engine - the system may provide a robust method for generating sensitive documents with granular security controls.

[0256] This process may be particularly valuable in scenarios where organizations need to create reports or documents containing varying levels of sensitive information, potentially accessible to users with different security clearances or attribute-based access rights. The resulting encrypted documents may allow for flexible distribution and access control, where different users may see different levels of content based on their specific attributes and authorization levels.

[0257] In practice, this secure document generation process may be applied to a wide range of document types and formats, from simple text reports to complex multimedia presentations. The flexibility of the Document Security Manager in handling various content types, coupled with the robust encryption capabilities of the Cryptographic Engine, may allow the system to address diverse document security requirements across different industries and use cases.

[0258] In some cases, a document security system may implement a sophisticated decryption workflow to selectively decrypt encrypted documents while maintaining strict access controls. FIG. 15 illustrates an exemplary sequence diagram depicting the interactions between key components in such a document decryption workflow.

[0259] The decryption process may begin with an authentication step. The Web Browser may initiate this process by sending authentication credentials, typically a username and password, to the Attribute-Based Access Control Application. This initial authentication step may serve as a crucial security measure, ensuring that only authorized users can access the decryption functionality. The Attribute-Based Access Control Application may verify the provided credentials against its user database, potentially employing additional security measures such as multi-factor authentication or checking for specific user attributes required for document access.

[0260] Following successful authentication, the Web Browser may proceed to upload an ABE Encrypted Document for decryption to the Document Security Manager. This step may involve the secure transfer of the encrypted document from the user's local environment to the Document Security Manager's secure processing environment. The uploaded document may contain various encrypted sections, each potentially secured with different attribute-based encryption policies.

[0261] Upon receiving the encrypted document, the Document Security Manager may initiate the decryption process by sending a Decrypt KeyGen Request to the Cryptographic Engine. This request may include information about the authenticated user's attributes and the specific document to be decrypted. The Cryptographic Engine may use this information to generate a decryption key tailored to the user's access rights and the document's encryption policies.

[0262] The Cryptographic Engine may process the key generation request, applying complex cryptographic algorithms to create a unique decryption key. This key may be designed to only decrypt portions of the document that match the user's attributes and access rights. After generating the appropriate key, the Cryptographic Engine may return the Decrypt Key to the Document Security Manager.

[0263] With the decryption key in hand, the Document Security Manager may proceed to send a Decrypt File Content Request to the Cryptographic Engine. This request may include the encrypted document along with the newly generated decryption key. By separating the key generation and decryption steps, the system may provide an additional layer of security and flexibility in managing access to encrypted content.

[0264] The Cryptographic Engine may then process the decryption request, applying the userspecific key to selectively decrypt portions of the document. This process may involve complex cryptographic operations to reveal only those sections of the document that match the user'sattributes and access rights. After completing the selective decryption process, the Cryptographic Engine may return a Decrypted File Content Response to the Document Security Manager.

[0265] Upon receiving the selectively decrypted content, the Document Security Manager may proceed to build the final decrypted document. This document building process may involve carefully reconstructing the document structure, replacing encrypted sections with their decrypted counterparts where authorized, while maintaining redaction or encryption for sections the user may not have permission to access.

[0266] The document building step may require sophisticated handling of various document elements, including text, images, tables, and other formatting features. The Document Security Manager may need to ensure that the incorporation of decrypted content and the maintenance of still-encrypted sections do not disrupt the document's layout or compromise its integrity.

[0267] In building the decrypted document, the Document Security Manager may apply redaction to unauthorized portions, effectively creating a customized view of the document tailored to the user's specific access rights. This approach may allow for granular access control, where different users may see different levels of content within the same document based on their individual attributes and authorization levels.

[0268] Finally, after the selectively decrypted document has been fully constructed, the Document Security Manager may send the Decrypted Document File Response back to the Web Browser. This response may contain the completed document with authorized portions decrypted and unauthorized portions remaining redacted or encrypted.

[0269] The decryption workflow, as illustrated in FIG. 15, may demonstrate the system's ability to provide secure and granular access to encrypted documents. By leveraging attributebased encryption and sophisticated key management techniques, the system may offer a flexible and robust method for controlling access to sensitive information within complex documents.

[0270] This process may be particularly valuable in scenarios where organizations need to manage access to documents containing varying levels of sensitive information, potentially accessible to users with different security clearances or attribute-based access rights. The resulting selectively decrypted documents may allow for efficient information sharing while maintaining strict control over who can access specific portions of sensitive content.

[0271] In practice, this decryption workflow may be applied to a wide range of document types and formats, from simple text reports to complex multimedia presentations. The flexibilityof the Document Security Manager in handling various content types, coupled with the robust decryption capabilities of the Cryptographic Engine, may allow the system to address diverse document security requirements across different industries and use cases.

[0272] In some cases, a document security system may implement a sophisticated architecture to process, analyze, and secure sensitive documents. FIG. 16 illustrates an exemplary system diagram of such a document security system.

[0273] The document security system may include a Document Security Manager 500. The Document Security Manager 500 may serve as the central component for coordinating document processing, analysis, and security operations. In some cases, the Document Security Manager 500 may receive documents containing plaintext from various sources for processing.

[0274] An Al Analysis Module 502 may be incorporated within the Document Security Manager 500. The Al Analysis Module 502 may employ machine learning models trained on domain-specific data, including classification markings, compartment identifiers, and security level indicators. This specialized training may enable the Al Analysis Module 502 to effectively identify portions of plaintext containing sensitive information.

[0275] The Al Analysis Module 502 may comprise two key components: a Pattern Recognition Engine 504 and a Contextual Analysis Engine 506. The Pattern Recognition Engine 504 may be configured to identify specific patterns, keywords, or structures within the document that may indicate sensitive content. The Contextual Analysis Engine 506 may analyze the semantic context surrounding potentially sensitive information to improve accuracy and reduce false positives.

[0276] In some cases, the Al Analysis Module 502 may apply multi-layered analysis techniques to thoroughly examine document content. These techniques may include syntactic parsing to understand the grammatical structure of sentences and named entity recognition to identify and classify specific elements within the text, such as names of persons, organizations, or locations. By combining these advanced natural language processing methods, the Al Analysis Module 502 may achieve a more nuanced understanding of the document's content and context.

[0277] The Al Analysis Module 502 may utilize retrieval augmented generation (RAG) with a vector database to enhance prompts with contextual data for improved analysis. This approach may involve storing relevant contextual information in a vector database, which may then be used to augment the input prompts for the Al models. By incorporating this additional context, the AlAnalysis Module 502 may generate more accurate and relevant analyses of document content, particularly when dealing with domain-specific or specialized information.

[0278] To further refine the identification of sensitive content, the Al Analysis Module 502 may generate confidence scores for identified sensitive portions using statistical classification algorithms. These confidence scores may provide a quantitative measure of the likelihood that a particular section of text contains sensitive information. By employing statistical methods, the Al Analysis Module 502 may offer a more robust and reliable assessment of document sensitivity, potentially reducing false positives and improving overall accuracy.

[0279] The Al Analysis Module 502 may also utilize hierarchical classification schemes that categorize content based on both explicit security markings and implicit contextual indicators. This multi-faceted approach may allow the system to consider not only overt classification labels but also subtle contextual clues that may suggest sensitivity. By leveraging these hierarchical schemes, the Al Analysis Module 502 may provide a more comprehensive and nuanced assessment of document security requirements.

[0280] Natural language processing techniques may be employed by the Al Analysis Module 502 to parse document structure and content. These techniques may enable the module to understand the logical organization of the document, identify key sections or headings, and analyze the relationships between different parts of the text. By comprehensively parsing the document's structure and content, the Al Analysis Module 502 may more effectively identify sensitive information within its proper context.

[0281] A Security Level Assignment Module 508 may work in conjunction with the Al Analysis Module 502 to assign predefined security levels or attributes to the identified portions of plaintext. The assignment process may involve confidence scoring against the domain-specific training data, pattern matching against known classification markings, and semantic analysis of compartment-specific terminology. This comprehensive approach may help ensure that appropriate security levels are applied to different sections of the document.

[0282] Once security levels have been assigned, an Encryption Request Handler 510 may prepare and send encrypt file content requests to a Cryptographic Engine 514. These requests may include the document and the assigned security levels or attributes for each sensitive portion identified.

[0283] The Cryptographic Engine 514 may perform the actual encryption operations on the sensitive portions of the document. After processing, the Cryptographic Engine 514 may return an encrypted file content response to the Document Security Manager 500. This response may include encrypted versions of the plaintext portions corresponding to the assigned security levels or attributes.

[0284] A Document Builder 512 within the Document Security Manager 500 may then construct the final encrypted document. The Document Builder 512 may replace the portions of plaintext corresponding to the assigned security levels with masking symbols. In some cases, the width of these masking symbols may be adjusted to be approximately the same as the width of the original plaintext. This adjustment may help maintain the overall formatting and visual structure of the document.

[0285] Additionally, the Document Builder 512 may store the encrypted portions of the plaintext as metadata within custom properties of the encrypted document. This approach may allow for efficient storage and retrieval of the encrypted content while maintaining the document's structure.

[0286] After the encrypted document has been built, the Document Security Manager 500 may send the encrypted document to a Client Device 516. The Client Device 516 may represent various types of user devices, such as computers, tablets, or smartphones, where authorized users can access and interact with the secured documents.

[0287] This system architecture may provide a comprehensive approach to document security, leveraging advanced Al techniques for sensitive content identification, flexible security level assignment, and secure encryption processes. By integrating these components, the system may offer robust protection for sensitive information while maintaining document usability and structure.

[0288] In some cases, a document security system may implement an Offline Decryption System to enable secure access to encrypted documents without requiring constant network connectivity. FIG. 17 illustrates an exemplary system diagram of such an Offline Decryption System 600.

[0289] The Offline Decryption System 600 may comprise several interconnected components designed to facilitate secure document decryption in environments where network access may be limited or unavailable. At the core of the system, a Secure Hardware Module 602 may serve as acritical component for maintaining the security and integrity of decryption operations in offline scenarios.

[0290] The Secure Hardware Module 602 may contain Local Key Storage 604, which may be designed to securely store decryption keys and other sensitive cryptographic materials. This local storage capability may enable the system to perform decryption operations without the need to retrieve keys from a remote server, thus allowing for offline functionality. The Secure Hardware Module 602 may employ various security measures to protect the stored keys, potentially including hardware-based encryption, tamper-resistant packaging, or secure enclaves within the processor architecture.

[0291] Connected to the Secure Hardware Module 602, an Offline Decryption Module 606 may be responsible for carrying out the actual decryption operations on encrypted documents. This module may leverage the locally stored keys from the Secure Hardware Module 602 to decrypt document content without requiring network connectivity. The Offline Decryption Module 606 may implement sophisticated algorithms to ensure that decryption operations are performed securely and efficiently, even in resource-constrained offline environments.

[0292] An Access Log Manager 608 may be integrated into the Offline Decryption System 600 to maintain a comprehensive record of all decryption activities and access events. This component may be crucial for ensuring accountability and maintaining an audit trail, even when the system may be operating in an offline state. The Access Log Manager 608 may record detailed information about each decryption event, potentially including user identities, timestamps, document identifiers, and specific portions of documents that were decrypted.

[0293] The Offline Decryption System 600 may be designed to synchronize with a Central Server 610 when network connectivity becomes available. This synchronization capability may be facilitated through a Network Connection 612, which may represent any type of network interface that allows the Offline Decryption System 600 to communicate with the Central Server 610.

[0294] The Network Connection 612 may serve multiple purposes within the system architecture. When a connection may be established, the Offline Decryption System 600 may use this link to synchronize access logs stored in the Access Log Manager 608 with the Central Server 610. This synchronization process may ensure that all offline decryption activities are properly recorded and centralized for auditing and security monitoring purposes.

[0295] Additionally, the Network Connection 612 may enable the Offline Decryption System 600 to receive updates to its decryption keys, security policies, or software components from the Central Server 610. This capability may allow organizations to maintain control over their offline decryption systems, ensuring that security measures remain up-to-date even when devices may operate in disconnected environments for extended periods.

[0296] The Central Server 610 may play a vital role in the overall document security ecosystem, serving as a centralized management and control point for the Offline Decryption System 600. The Central Server 610 may be responsible for tasks such as key management, policy distribution, and aggregation of access logs from multiple Offline Decryption Systems.

[0297] In operation, when a user requests access to an encrypted document in an offline environment, the Offline Decryption Module 606 may interact with the Secure Hardware Module 602 to retrieve the necessary decryption keys from the Local Key Storage 604. The decryption process may then be performed locally, with the Access Log Manager 608 recording the details of the operation.

[0298] Upon reestablishing a network connection, the Offline Decryption System 600 may initiate a synchronization process with the Central Server 610. During this process, the Access Log Manager 608 may transmit its stored logs to the Central Server 610, ensuring that all offline activities are properly accounted for in the centralized system. Simultaneously, the Offline Decryption System 600 may receive any updates or new security policies from the Central Server 610, helping to maintain the system's security posture.

[0299] The architecture of the Offline Decryption System 600, as illustrated in FIG. 17, may provide a robust solution for organizations that need to enable secure document access in environments with limited or intermittent network connectivity. By combining local key storage, offline decryption capabilities, and synchronized logging, the system may offer a balance between security, functionality, and auditability in challenging operational scenarios.

[0300] In some cases, a document security system may implement a client computing architecture to enable secure document processing and access on user devices. FIG. 18 illustrates an exemplary client computing architecture 1100 that may be utilized in such a system.

[0301] The client computing architecture 1100 may comprise several interconnected subsystems, each designed to perform specific functions within the overall computingenvironment. At the core of the architecture, a processing subsystem 1105 may serve as the primary computational engine for the client device.

[0302] The processing subsystem 1105 may include a central processing unit 1110, which may be responsible for executing instructions and performing calculations necessary for document processing, encryption, and decryption operations. In some cases, the central processing unit 1110 may be a multi-core processor capable of handling multiple threads simultaneously, enabling efficient parallel processing of complex document security tasks.

[0303] Connected to the central processing unit 1110, a memory management unit 1115 may be responsible for managing the flow of data between the processor and various memory components. The memory management unit 1115 may handle tasks such as virtual memory management, memory protection, and cache coherency, ensuring efficient and secure access to stored data and instructions.

[0304] The processing subsystem 1105 may also include cache memory 1120, which may provide high-speed temporary storage for frequently accessed data and instructions. The cache memory 1120 may be organized in multiple levels, potentially including separate instruction and data caches, to optimize processing speed and reduce latency in document handling operations.

[0305] A graphics processing unit 1125 may be incorporated into the processing subsystem 1105 to handle complex visual rendering tasks. In the context of a document security system, the graphics processing unit 1125 may be utilized for tasks such as rendering encrypted documents with redacted sections, displaying visual security indicators, or generating graphical user interfaces for document management and access control.

[0306] An AI / ML processing unit 1130 may also be included in the processing subsystem 1105. This specialized processing unit may be designed to accelerate artificial intelligence and machine learning computations, potentially enhancing the performance of the Al Analysis Module in identifying sensitive content within documents.

[0307] The client computing architecture 1100 may include a memory subsystem 1135 for storing data and instructions. The memory subsystem 1135 may comprise system memory 1140, which may be implemented as high-speed random access memory (RAM) for active data processing. Additionally, the memory subsystem 1135 may include non-volatile memory 1145, which may provide persistent storage for critical system data, encryption keys, and security policies even when the device may be powered off.

[0308] A storage subsystem 1150 may be incorporated into the client computing architecture 1100 to provide larger-capacity, long-term data storage. The storage subsystem 1150 may include a storage controller 1155 that manages data access and storage operations. The storage subsystem 1150 may utilize both solid state storage 1160 and hard disk storage 1165, potentially in a hybrid configuration to balance performance and capacity requirements for secure document storage.

[0309] To facilitate interaction with users and external systems, the client computing architecture 1100 may include a client I / O subsystem 1170. An I / O controller 1175 within this subsystem may manage the flow of data between the client device and various input / output interfaces. A network interface controller 1180 may enable secure communication with remote servers and other devices, potentially facilitating the synchronization of encrypted documents and security policies.

[0310] The client I / O subsystem 1170 may also include a display interface 1185 for connecting to monitors or other visual output devices. This interface may be crucial for presenting decrypted documents, security warnings, and user interface elements related to document access and management. User input devices 1190 may be connected to the client I / O subsystem 1170, allowing users to interact with the document security system through keyboards, mice, touchscreens, or other input mechanisms.

[0311] All of these subsystems and components may be interconnected through a system bus 1195. The system bus 1195 may provide a high-speed data pathway that enables communication and data transfer between the various elements of the client computing architecture 1100. In some cases, the system bus 1195 may utilize advanced bus architectures to optimize data throughput and minimize latency in security-critical operations.

[0312] The client computing architecture 1100, as illustrated in FIG. 18, may provide a robust and flexible platform for implementing secure document handling capabilities on user devices. By integrating specialized processing units, secure storage mechanisms, and advanced I / O capabilities, this architecture may enable efficient and secure document encryption, decryption, and access control operations in both online and offline scenarios.

[0313] In operation, when a user requests access to an encrypted document, the central processing unit 1110 may coordinate with the AI / ML processing unit 1130 to analyze the document content and user attributes. The memory management unit 1115 may efficiently retrieve encrypted document data from the storage subsystem 1150 and load it into system memory 1140for processing. The Cryptographic Engine may leverage the processing power of the central processing unit 1110 and potentially the AI / ML processing unit 1130 to perform decryption operations, while the graphics processing unit 1125 may handle the rendering of the decrypted document with appropriate redactions.

[0314] Throughout this process, the client VO subsystem 1170 may manage user interactions and display updates, while the network interface controller 1180 may handle any necessary communications with remote servers for policy updates or access log synchronization. The tight integration of these components through the system bus 1195 may enable the client computing architecture 1100 to provide a seamless and secure document handling experience for users of the document security system.

[0315] In some cases, a document security system may implement a server-client network architecture to facilitate secure document processing and access across distributed environments. FIG. 19 illustrates an exemplary server client network architecture 1200 that may be utilized in such a system.

[0316] The server client network architecture 1200 may comprise three main sections: client systems 1205, server systems 1255, and cloud services 1280. These sections may work together to form a comprehensive distributed system capable of processing client requests through both local servers and cloud-based services.

[0317] The client systems 1205 section may include various types of client devices that users may employ to access and interact with the document security system. A mobile client 1210 may represent smartphones or tablets, enabling users to access secure documents on-the-go. A desktop client 1215 may provide a more traditional computing environment for document processing and security operations. A web browser client 1220 may allow users to access the document security system through standard web interfaces, potentially without requiring specialized software installation. An loT edge client 1225 may represent Internet of Things devices or edge computing nodes that may interact with the document security system, potentially for specialized document handling or security monitoring tasks.

[0318] These client systems may connect to a network infrastructure 1230, which may serve as the communication backbone of the server client network architecture 1200. Within the network infrastructure 1230, a router gateway 1235 may manage the flow of data between different network segments. The router gateway 1235 may connect to both a local area network 1240 and a widearea network 1245, enabling communication between local resources and geographically distributed components of the system.

[0319] A content delivery network 1250 may be integrated into the network infrastructure 1230 to optimize the delivery of static content and potentially improve the performance of document access and distribution across wide geographic areas.

[0320] The server systems 1255 section may comprise various types of servers that handle different aspects of document processing and security operations. An application server 1260 may host the core logic of the document security system, potentially including components such as the Document Security Manager and the Al Analysis Module. A web server 1265 may handle HTTP requests from web browser clients and serve web-based interfaces for the document security system.

[0321] A database server 1270 may manage structured data storage for the system, potentially including user information, access control policies, and document metadata. A file storage server 1275 may provide secure storage for encrypted documents and associated files.

[0322] The cloud services 1280 section may extend the capabilities of the document security system through scalable and flexible cloud-based resources. A load balancer 1285 may distribute incoming requests across multiple cloud resources to optimize performance and ensure high availability.

[0323] The cloud compute 1290 component may provide scalable processing power for computationally intensive tasks within the document security system. This may include virtual machines 1295 for running various system components, container services 1300 for deploying and managing containerized applications, and serverless functions 1305 for executing specific tasks without managing underlying infrastructure.

[0324] An API gateway 1310 may manage and secure the APIs that enable communication between different components of the system, as well as integration with external services. Cloud storage 1315 may provide scalable and redundant storage for encrypted documents and system data, complementing or extending the capabilities of the file storage server 1275.

[0325] A database service 1320 may offer cloud-based database management, potentially providing additional scalability and reliability for data storage and retrieval operations within the document security system.

[0326] The architecture may also include data flow services 1325 to manage the movement and processing of data within the system. A message queue 1330 may facilitate asynchronous communication between different components of the system, enabling efficient handling of tasks such as document encryption requests or access log processing. Stream processing 1335 capabilities may allow for real-time analysis of data flows, potentially enabling immediate detection of security events or anomalies in document access patterns.

[0327] Batch processing 1340 may handle large-scale data operations that may not require real-time processing, such as generating comprehensive security reports or performing system- wide policy updates. An ETL (Extract, Transform, Load) pipeline 1345 may manage the movement and transformation of data between different storage systems or data formats within the document security ecosystem.

[0328] The server client network architecture 1200, as illustrated in FIG. 19, may provide a flexible and scalable foundation for implementing secure document handling capabilities across diverse computing environments. By integrating local server resources with cloud-based services, the architecture may enable efficient and secure document encryption, decryption, and access control operations while accommodating varying scales of deployment and performance requirements.

[0329] In operation, when a user initiates a request from one of the client systems 1205, such as accessing an encrypted document, the request may be routed through the network infrastructure 1230 to the appropriate server systems 1255 or cloud services 1280. The application server 1260 or cloud compute 1290 resources may process the request, potentially leveraging the Al Analysis Module for content analysis and the Cryptographic Engine for decryption operations.

[0330] Throughout this process, the various components of the server client network architecture 1200 may work in concert to ensure secure and efficient handling of sensitive documents. The distributed nature of the architecture may allow for load balancing, redundancy, and scalability, while the integration of cloud services may provide flexibility in resource allocation and management for the document security system.

[0331] Throughout this disclosure, various terms and phrases are used to describe features of the disclosed technology. It is to be understood that these terms and phrases may encompass a variety of meanings and definitions, as is common in the field of technology and patent law. Thedefinitions of these terms may vary depending on the context in which they are used, the specific embodiment being described, or the interpretation of the technology by those skilled in the art.

[0332] In various embodiments, certain variable names, symbols, or labels may be used in the claims to represent various elements, components, or steps of the described methods, systems, and apparatuses. These variable names, symbols, or labels are provided for convenience and clarity in describing the claimed subject matter. However, it should be understood that the use of such variable names, symbols, or labels in the claims does not necessarily limit these elements, components, or steps to being the same specific entities described in the specification or in other parts of the disclosure. The variable names, symbols, or labels used in the claims should be interpreted broadly and may encompass various implementations, variations, or equivalents of the described elements, components, or steps, unless explicitly stated otherwise or clearly limited by the context of the claim. As such, the scope of the claims is not confined to the specific examples or embodiments described in the specification, but rather extends to the full breadth of the inventive concepts disclosed herein.

[0333] For instance, terms such as "computing device," "processor," "memory," and "network" may refer to a wide range of devices, components, systems, and configurations known in the art, and their specific definitions may differ based on the implementation or design of the system. Similarly, phrases like "securely storing," "computing a vector," and "generating a message" may involve various methods, techniques, and processes that achieve the same or similar outcomes but may be executed in different manners.

[0334] It is also to be understood that the use of terms in the singular or plural form is not intended to limit the scope of the claims. For example, the mention of "a computing device" does not preclude the presence of multiple computing devices within a system. Likewise, references to "a network" may include various interconnected networks or a single network comprising multiple segments or layers.

[0335] Furthermore, the use of the term "may" in relation to an action or feature indicates that the action or feature is possible, but not necessarily mandatory. This term is used to describe optional or alternative aspects of the disclosed technology that provide flexibility in how the technology may be implemented or utilized.

[0336] The definitions provided herein are intended to serve as examples and are not exhaustive. Those skilled in the art may ascribe different meanings to these terms based on thecontext, the specific technology being described, or the advancements in the field. Therefore, the definitions of the terms and phrases used in this disclosure and the claims are to be interpreted broadly and in a manner consistent with the understanding of those skilled in the relevant art.

[0337] The use of the word "a" or "an" when used in conjunction with the claims herein is to be interpreted as including one or more than one of the element it introduces. Similarly, the use of the term "or" is intended to be inclusive, such that the phrase "A or B" is intended to include A, B, or both A and B, unless explicitly stated otherwise.

[0338] Reference throughout the specification to "one embodiment," "another embodiment," "an embodiment," and so forth, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure, and may not necessarily be present in all embodiments. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments without limitation.

[0339] The use of the terms "first," "second," and the like does not imply any order or sequence, but are used to distinguish one element from another, and the terms "top," "bottom," "front," "back," "leading," "trailing," and the like are used for descriptive purposes and are not necessarily to be construed as limiting.

[0340] As used herein, the term "processor" refers to any computing entity capable of executing instructions to perform a specific set of operations, whether implemented in hardware, firmware, software, or any combination thereof. This definition includes a broad range of processing technologies and architectures. The term encompasses general-purpose processors such as Central Processing Units (CPUs), specialized processors such as Graphics Processing Units (GPUs), as well as highly specialized hardware accelerators such as Neural Processing Units (NPUs) for artificial intelligence applications and Tensor Processing Units (TPUs) for machine learning workloads.

[0341] The term also encompasses reconfigurable computing architectures such as Field- Programmable Gate Arrays (FPGAs) for applications requiring specialized processing configurations, Application-Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Systolic Array Processors, and emerging computing paradigms such as Quantum Processors that leverage principles of quantum mechanics. System on Chip (SoC) designs, heterogeneous computing systems, Edge Computing Processors for distributed networkapplications, cloud-based and distributed processors, multi-core and parallel processors, and Neuromorphic processors that draw inspiration from biological neural architectures are all encompassed within this definition.

[0342] The term "processor" also encompasses the associated memory hierarchies, including primary memory (such as RAM), secondary storage (such as hard drives and SSDs), and cache memory, which work in conjunction with the processor to store and retrieve data necessary for executing instructions. In this patent application, any reference to a "processor" should be interpreted broadly to include any type of processing unit capable of performing the described functions, regardless of its specific implementation, architecture, or physical form.

[0343] As used herein, the term "messages" may refer to any form of data or information that can be processed, transmitted, or stored in a digital format. Messages may include arbitrary-length plaintext messages, pre-hashed messages, concatenated messages, binary data, network protocol messages, database records, and time-stamped messages. Messages may be composed of characters, symbols, or binary data and may represent various forms of content such as text, numbers, multimedia, executable code, or any other data that can be digitally encoded. Messages may be used as input for cryptographic functions, such as keyed hash functions, where they are transformed into a fixed-size hash value influenced by a secret cryptographic key.

[0344] The term "messages" encompasses a wide range of data types and structures, from simple text strings to complex structured data, and may include metadata, headers, footers, or other information that facilitates the processing, transmission, or interpretation of the content. Messages may be generated by users, systems, or processes and may be intended for various purposes, including communication, authentication, verification, logging, or any other function that involves the use of digital data.

[0345] Messages may also include data formats specific to artificial intelligence and machine learning applications, such as tensors, feature vectors, embeddings, model parameters, activation maps, training examples, and inference requests. In distributed and edge computing contexts, the term "messages" further extends to include event streams, state updates, service requests, synchronization messages, and smart contract transactions used in blockchain platforms.

[0346] As used herein, the terms "store," "storing," "storage," or variants thereof refer to any means, methods, systems, or processes for recording, retaining, or preserving data in a retrievableformat. This terminology encompasses a broad spectrum of technologies and mechanisms that may be employed to maintain information for future access or reference.

[0347] The term "storing" or "storage" as used in this specification may encompass both persistent and transient data retention. In some cases, the storage may be entirely ephemeral, lasting only for the duration of a specific operation or process. The use of these terms does not imply any particular time period for data retention or any level of permanence. Storage and storing may be as brief as a few microseconds or indefinitely long, depending on the specific implementation and requirements of the system.

[0348] The term includes traditional electronic storage technologies such as magnetic storage (including hard disk drives, magnetic tape, and floppy disks), optical storage (including optical discs, holographic storage, and optical tape), and solid-state storage (including solid-state drives, flash memory, static random-access memory, dynamic random-access memory, and read-only memory). It also encompasses emerging storage technologies such as DNA storage, molecular storage, quantum storage, and photonic storage.

[0349] Storage terminology may refer to various architectural organizations and hierarchies of data repositories. This includes primary storage (main memory, cache memory) designed for rapid access during processing operations; secondary storage providing non-volatile retention of larger data volumes; and tertiary storage for archival purposes. The terminology extends to distributed storage architectures such as network-attached storage (NAS), storage area networks (SAN), direct-attached storage (DAS), and object storage systems. It also includes cloud-based storage configurations, including public, private, and hybrid cloud storage implementations; edge storage systems located at network peripheries; and fog storage systems distributed between centralized and edge locations.

[0350] The definition encompasses storage virtualization technologies that abstract physical storage resources and present them as logical storage units, including virtual disks, software- defined storage, and storage hypervisors. It also includes storage orchestration systems that manage data placement, replication, and migration across distributed infrastructures.

[0351] The terminology extends to various data organization and management paradigms. This includes file systems that organize data into files and directories; block storage systems that manage data as fixed-sized blocks; object storage systems that handle data as discrete objects with metadata; and content-addressable storage systems that retrieve data based on content rather thanlocation. It also includes specialized storage structures such as databases, data lakes, data warehouses, and knowledge repositories.

[0352] Storage terminology encompasses various operational characteristics and capabilities of storage systems. This includes persistent storage that maintains data integrity across power cycles; volatile storage that requires continuous power to retain data; and non-volatile storage that preserves data without power. It also includes immutable storage that prevents modification of stored data; append-only storage that allows additions but not modifications; and version- controlled storage that maintains historical states of data. The term further encompasses encrypted storage that protects data confidentiality; redundant storage that duplicates data to prevent loss; and resilient storage that maintains availability despite component failures.

[0353] In specialized computing contexts, storage terminology may refer to domain-specific storage mechanisms. For blockchain and distributed ledger technologies, this includes on-chain storage within the blockchain itself and off-chain storage that maintains references to externally stored data. For neural networks and artificial intelligence systems, it includes weight storage for maintaining learned parameters and activation storage for intermediate computational results. For quantum computing systems, it refers to quantum state storage that preserves quantum information, while for edge computing, it includes transient storage for temporary data processing at network boundaries.

[0354] The term "storage" also encompasses the protocols, interfaces, and access methods used to interact with stored data. This includes file access protocols (such as NFS, SMB, and HDFS), block access protocols (such as iSCSI, Fibre Channel, and ATA), and object access protocols (such as S3, Swift, and CDMI). It also includes direct memory access mechanisms, memory -mapped file interfaces, and storage controller interfaces.

[0355] The term "database" should be construed to mean a blockchain, distributed ledger technology, key-value store, document-oriented database, graph database, time-series database, inmemory database, columnar database, object-oriented database, hierarchical database, network database, or any other structured data storage system capable of storing and retrieving information. This may include traditional relational database management systems (RDBMS), NoSQL databases, NewSQL databases, or hybrid database systems that combine multiple database paradigms. The database may be centralized, distributed, or decentralized, and may employ various data models, indexing strategies, and query languages to organize and access the storedinformation. It may also incorporate features such as ACID (Atomicity, Consistency, Isolation, Durability) compliance, eventual consistency, sharding, replication, or partitioning to ensure data integrity, availability, and scalability. The database may be hosted on-premises, in the cloud, or in a hybrid environment, and may support various access methods including direct queries, API calls, or event-driven architectures.

[0356] The term "database" further encompasses specialized data storage and management systems designed for particular domains or use cases. This includes blockchain and distributed ledger technologies used for secure, decentralized transaction records, edge databases optimized for resource-constrained environments, vector databases for high-dimensional data, time-series databases for temporal data management, knowledge graphs for representing interconnected information, federated databases for integrating autonomous systems, and emerging paradigms such as quantum databases that leverage quantum computing principles.

[0357] The terms "connected," "coupled," or any variant thereof, mean any direct or indirect connection or coupling between two or more elements, and may encompass the presence of one or more intermediate elements between the two elements that are connected or coupled to each other.

[0358] In the context of modern computing architectures and network topologies, these terms may also refer to various connection modalities. This includes physical connections through wired or wireless interfaces, logical connections operating independently of the physical layer, API connections allowing software components to communicate, and microservice connections in distributed architectures. The terminology extends to edge-to-cloud connections for distributed processing environments, blockchain connections for distributed ledger systems, quantum connections for secure communication, and neural network connections for artificial intelligence systems.

[0359] As used herein, the term "display" or "displaying" refers to any means, method, apparatus, or process for visually presenting or otherwise conveying information to a user. This terminology encompasses a broad spectrum of technologies and presentation modalities that may be employed to render content perceivable by a user. The term includes traditional display technologies such as cathode ray tubes (CRTs), liquid crystal displays (LCDs), light-emitting diode (LED) displays, organic light-emitting diode (OLED) displays, micro-LED displays, and electronic paper displays. It also encompasses specialized display types such as transparent displays, flexible displays, foldable displays, stretchable displays, and holographic displays.

[0360] The term "display" may also refer to projection systems, including traditional projectors, laser projectors, pico projectors, and holographic projection systems. It further includes immersive display technologies such as head-mounted displays (HMDs), virtual reality (VR) headsets, augmented reality (AR) glasses, mixed reality (MR) systems, and smart contact lenses. The terminology extends to ambient display methods that integrate visual information into the environment, such as smart mirrors, interactive surfaces, projection mapping systems, and volumetric displays.

[0361] The definition also encompasses non-visual display modalities that may complement or substitute for visual displays. This includes auditory displays such as speech output systems, sonification interfaces, and spatial audio; haptic displays that communicate through tactile feedback, vibration patterns, or force feedback; and other sensory output mechanisms such as olfactory displays and thermotactile interfaces. Multimodal displays that combine multiple sensory channels for information presentation are also included within this terminology.

[0362] The term "display" further encompasses the software and computational components involved in rendering information. This includes rendering engines, graphics processing pipelines, display servers, and compositing systems. It also includes specialized display rendering techniques such as rasterization, ray tracing, vector graphics, procedural generation, and neural rendering. The term extends to user interface paradigms such as graphical user interfaces (GUIs), natural user interfaces (NUIs), voice user interfaces (VUIs), brain-computer interfaces (BCIs), and ambient intelligence systems.

[0363] In the context of accessibility, the term "display" includes assistive technologies and alternative display methods designed to accommodate diverse user needs. This encompasses screen readers, braille displays, audio descriptions, high-contrast modes, color-shifted presentations, and other adaptive display mechanisms. The terminology also includes display personalization techniques such as adaptive interfaces, contextual displays, and user-specific rendering optimizations.

[0364] The description of the embodiments of the present disclosure is intended to be illustrative, and not to limit the scope of the claims. Many alternatives, modifications, and variations will be apparent to those skilled in the art. A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made withoutdeparting from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claims

CLAIMS1. A method for selectively encrypting and decrypting portions of a document, comprising: receiving, by a document security manager, a document containing plaintext; analyzing, by the document security manager, the document using an artificial intelligence system to identify portions of the plaintext containing sensitive information, wherein the artificial intelligence system comprises machine learning models trained on domain-specific data including classification markings, compartment identifiers, and security level indicators, wherein the artificial intelligence system uses pattern recognition and contextual analysis to identify sensitive content based on semantic understanding and classification rules; assigning, by the document security manager, predefined security levels or attributes to the identified portions of plaintext using the artificial intelligence system, wherein the assigning is based on confidence scoring against the domain-specific training data, pattern matching against known classification markings, and semantic analysis of compartmentspecific terminology; sending, by the document security manager, an encrypt file content request to a cryptographic engine, the request including the document and the assigned security levels or attributes; receiving, by the document security manager, an encrypted file content response from the cryptographic engine, the response including encrypted portions of the plaintext corresponding to the assigned security levels or attributes; building, by the document security manager, an encrypted document by: replacing the portions of the plaintext corresponding to the assigned security levels or attributes with masking symbols, wherein a width of the masking symbols is adjusted to be approximately the same as a width of the original plaintext, and storing the encrypted portions of the plaintext as metadata in custom properties of the encrypted document; and sending, by the document security manager, the encrypted document to a client device.

2. The method of claim 1, further comprising: receiving, by the document security manager, a request to decrypt the encrypted document;authenticating, by the document security manager, a user associated with the request; determining, by the document security manager, attributes associated with the authenticated user; sending, by the document security manager, a decrypt file content request to the cryptographic engine, the request including the encrypted document and the user attributes; receiving, by the document security manager, a decrypted file content response from the cryptographic engine, the response including decrypted portions of the plaintext corresponding to the user attributes; and building, by the document security manager, a decrypted document by replacing the masking symbols with the decrypted portions of the plaintext for which the user is authorized.

3. The method of claim 2, wherein building the decrypted document further comprises maintaining the masking symbols for portions of the plaintext for which the user is not authorized.

4. The method of claim 1, further comprising: receiving, by the document security manager, a document containing Department of Defense (DoD) classification markings; parsing, by the document security manager, the document to identify the DoD classification markings including at least one of Top Secret, Secret, Confidential, or Unclassified designations; converting, by the document security manager, the identified DoD classification markings to corresponding attribute-based encryption policies; and applying, by the document security manager, the converted policies to encrypt portions of the document according to the original DoD classification levels.

5. The method of claim 1, wherein the document security manager is configured to operate in an offline mode, wherein the offline mode comprises: storing decryption keys locally in a secure hardware module; performing decryption operations without network connectivity; and synchronizing access logs with a central server upon reconnection to a network.

6. The method of claim 1, wherein the masking symbols are different for different security levels or attributes, wherein adjusting the width of the masking symbols to be approximately the same as the width of the original plaintext comprises: calculating a width of each portion of the original plaintext to be encrypted; determining a number and type of masking symbols needed to approximate the calculated width; and inserting the determined number and type of masking symbols in place of the original plaintext.

7. The method of claim 1, further comprising: logging, by the document security manager, each instance of decryption and access to encrypted portions of the document, including user identification, accessed portions, and timestamp, to maintain an audit trail of document access; applying, by the document security manager, password protection to the decrypted document; and embedding, by the document security manager, forensic metadata in the decrypted document identifying the user who performed the decryption and the time of decryption.

8. The method of claim 1 , wherein the document security manager operates as a Microsoft Office add-in that side-loads with Microsoft Office applications, and wherein the add-in provides encryption and decryption functionality directly within the Microsoft Office application interface without requiring external web-based services.

9. The method of claim 1, wherein the artificial intelligence system is further configured to: identify text decorations applied to portions of the plaintext within the document, wherein the text decorations include at least one of strikethrough formatting, underline styles, font color variations, or font size modifications; map the identified text decorations to predefined security levels or attributes based on a hierarchical classification scheme; and assign security levels or attributes to the decorated portions of plaintext based on the mapped text decorations.

10. A system for selectively encrypting and decrypting portions of a document, comprising:a document security manager configured to receive a document containing plaintext; the document security manager configured to analyze the document using an artificial intelligence system to identify portions of the plaintext containing sensitive information, wherein the artificial intelligence system comprises machine learning models trained on domainspecific data including classification markings, compartment identifiers, and security level indicators, wherein the artificial intelligence system uses pattern recognition and contextual analysis to identify sensitive content based on semantic understanding and classification rules; the document security manager configured to assign predefined security levels or attributes to the identified portions of plaintext using the artificial intelligence system, wherein the assigning is based on confidence scoring against the domain-specific training data, pattern matching against known classification markings, and semantic analysis of compartmentspecific terminology; the document security manager configured to send an encrypt file content request to a cryptographic engine, the request including the document and the assigned security levels or attributes; the document security manager configured to receive an encrypted file content response from the cryptographic engine, the response including encrypted portions of the plaintext corresponding to the assigned security levels or attributes; the document security manager configured to build an encrypted document by: replacing the portions of the plaintext corresponding to the assigned security levels or attributes with masking symbols, wherein a width of the masking symbols is adjusted to be approximately the same as a width of the original plaintext, and storing the encrypted portions of the plaintext as metadata in custom properties of the encrypted document; and the document security manager configured to send the encrypted document to a client device.

11. The system of claim 10, wherein: the document security manager is further configured to receive a request to decrypt the encrypted document;the document security manager is further configured to authenticate a user associated with the request; the document security manager is further configured to determine attributes associated with the authenticated user; the document security manager is further configured to send a decrypt file content request to the cryptographic engine, the request including the encrypted document and the user attributes; the document security manager is further configured to receive a decrypted file content response from the cryptographic engine, the response including decrypted portions of the plaintext corresponding to the user attributes; and the document security manager is further configured to build a decrypted document by replacing the masking symbols with the decrypted portions of the plaintext for which the user is authorized.

12. The system of claim 11, wherein the document security manager configured to build the decrypted document is further configured to maintain the masking symbols for portions of the plaintext for which the user is not authorized.

13. The system of claim 10, wherein: the document security manager is further configured to receive a document containing Department of Defense (DoD) classification markings; the document security manager is further configured to parse the document to identify the DoD classification markings including at least one of Top Secret, Secret, Confidential, or Unclassified designations; the document security manager is further configured to convert the identified DoD classification markings to corresponding attribute-based encryption policies; and the document security manager is further configured to apply the converted policies to encrypt portions of the document according to the original DoD classification levels.

14. The system of claim 10, wherein the document security manager is configured to operate in an offline mode, wherein the offline mode comprises:the document security manager configured to store decryption keys locally in a secure hardware module; the document security manager configured to perform decryption operations without network connectivity; and the document security manager configured to synchronize access logs with a central server upon reconnection to a network.

15. The system of claim 10, wherein the masking symbols are different for different security levels or attributes, wherein the document security manager configured to adjust the width of the masking symbols to be approximately the same as the width of the original plaintext is configured to: calculate a width of each portion of the original plaintext to be encrypted; determine a number and type of masking symbols needed to approximate the calculated width; and insert the determined number and type of masking symbols in place of the original plaintext.

16. The system of claim 10, wherein: the document security manager is further configured to log each instance of decryption and access to encrypted portions of the document, including user identification, accessed portions, and timestamp, to maintain an audit trail of document access; the document security manager is further configured to apply password protection to the decrypted document; and the document security manager is further configured to embed forensic metadata in the decrypted document identifying the user who performed the decryption and the time of decryption.

17. The system of claim 10, wherein the document security manager is configured to operate as aMicrosoft Office add-in that side-loads with Microsoft Office applications, and wherein the add-in is configured to provide encryption and decryption functionality directly within the Microsoft Office application interface without requiring external web-based services.

18. The system of claim 10, wherein the artificial intelligence system is further configured to:identify text decorations applied to portions of the plaintext within the document, wherein the text decorations include at least one of strikethrough formatting, underline styles, font color variations, or font size modifications; map the identified text decorations to predefined security levels or attributes based on a hierarchical classification scheme; and assign security levels or attributes to the decorated portions of plaintext based on the mapped text decorations.

19. A non-transitoiy computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method comprising: receiving, by a document security manager, a document containing plaintext; analyzing, by the document security manager, the document using an artificial intelligence system to identify portions of the plaintext containing sensitive information, wherein the artificial intelligence system comprises machine learning models trained on domain-specific data including classification markings, compartment identifiers, and security level indicators, wherein the artificial intelligence system uses pattern recognition and contextual analysis to identify sensitive content based on semantic understanding and classification rules, wherein the artificial intelligence system employs natural language processing techniques to parse document structure and content, applies multi-layered analysis including syntactic parsing and named entity recognition, generates confidence scores for identified sensitive portions using statistical classification algorithms, and utilizes hierarchical classification schemes that categorize content based on both explicit security markings and implicit contextual indicators; assigning, by the document security manager, predefined security levels or attributes to the identified portions of plaintext using the artificial intelligence system, wherein the assigning is based on confidence scoring against the domain-specific training data, pattern matching against known classification markings, and semantic analysis of compartmentspecific terminology; sending, by the document security manager, an encrypt file content request to a cryptographic engine, the request including the document and the assigned security levels or attributes;receiving, by the document security manager, an encrypted file content response from the cryptographic engine, the response including encrypted portions of the plaintext corresponding to the assigned security levels or attributes; building, by the document security manager, an encrypted document by: replacing the portions of the plaintext corresponding to the assigned security levels or attributes with masking symbols, wherein a width of the masking symbols is adjusted to be approximately the same as a width of the original plaintext, and storing the encrypted portions of the plaintext as metadata in custom properties of the encrypted document; and sending, by the document security manager, the encrypted document to a client device.

20. The non-transitory computer-readable medium of claim 19, wherein the method further comprises: receiving, by the document security manager, a request to decrypt the encrypted document; authenticating, by the document security manager, a user associated with the request; determining, by the document security manager, attributes associated with the authenticated user; sending, by the document security manager, a decrypt file content request to the cryptographic engine, the request including the encrypted document and the user attributes; receiving, by the document security manager, a decrypted file content response from the cryptographic engine, the response including decrypted portions of the plaintext corresponding to the user attributes; and building, by the document security manager, a decrypted document by replacing the masking symbols with the decrypted portions of the plaintext for which the user is authorized.

Images