Patent Application Titled “Systems And Methods For Cloud-Based Federated Records Retention Compliance Orchestration, Validation And Enforcement” Published Online (USPTO 20230136439): Patent Application

2023 MAY 22 (NewsRx) -- By a News Reporter-Staff News Editor at Insurance Daily News -- According to news reporting originating from Washington, D.C., by NewsRx journalists, a patent application by the inventors Anctil, Peter Joseph (Long Beach, CA, US); Gerasimov, Alexander (Kanata, CA); Humby, David (Richmond, CA), filed on December 28, 2022, was made available online on May 4, 2023.

No assignee for this patent application has been made.

Reporters obtained the following quote from the background information supplied by the inventors: “Information technology and the Internet have made it easier to collect personal data, sell personal data for profit, or exploit personal data to stalk a person, harass a person, or steal the identity of a person. Accordingly, data protection laws, which concern the security of the electronic transmission of personal data, evolve over time to govern how personal data should be handled. Records management technologies used by companies, organizations, enterprises, and the like (which are hereinafter collectively referred to as “entities”) must follow suit as non-compliant entities can face very strict fines.

“For example, to comply with the European (EU) General Data Protection Regulation (GDPR), which went into effect in 2018, many entities, particularly those that handle personal data of European individuals, must make operational changes and/or have security built into their products and processes. This is because the EU GDPR applies to any entity collecting and/or processing EU citizen’s personal data regardless of where the entity’s physical offices are located. This means that a non-EU company must also comply with the EU GDPR if that non-EU company handles the personal data of EU individuals, even if the non-EU company does not have any physical office in any EU country. In the EU GDPR, “personal data” broadly covers “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”

“Entities that handle the personal data of EU individuals are referred to as “controllers” (or data controllers) and “processors” (or data processors) in the EU GDPR. A “controller” is defined in the EU GDPR as “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data” and a “processor” is defined in the EU GDPR as “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.”

“An example of a data controller would be a company that specifies how and why personal data is processed. Another company that conducts the actual processing of the data would be the data processor. The controller is responsible for ensuring their processor abides by the EU GDPR and the processor must follow the regulations and maintain records of their processing activities. With the EU GDPR, if a processor is involved in a data breach, it is far more liable than under the previous data protection law. Thus, compliance with the EU GDPR is a must for processors and non-compliance has severe real world consequences.

“In the U.S., the protection of personal data of U.S. residents is regulated by laws enacted on both the national and the state level. Here, the term “personal data” is also known as personal information, personally identifying information (PII), or sensitive personal information (SPI) and generally refers to “any information relating to an identifiable person.” PII is defined by the National Institute of Standards and Technology (NIST), Special Publication 800-122, as “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.” So, for example, a user’s Internet Protocol (IP) address is not classed as PII on its own, but can be classified as linked PII. However, in the EU GDPR, the IP address of an Internet subscriber may be classified as personal data.

“Regulations of PII apply to many different industries in the U.S. For example, Health Insurance Portability and Accountability Act (HIPPA) is a 1996 Federal law that restricts access to individuals’ private medical information. HIPAA requires that business associates (BA) and covered entities (CE) retain certain information (e.g., a written or electronic record of a designation of an organization as a CE or BA, accounting of disclosures of protected health information (PHI), etc.) for at least six years from creation date or last effective date, whichever is later. This is referred to as a “retention period.” At the state level, the required retention period of medical records can be even longer and/or more varied.

“For global entities, they will also need to comply with data protection and/or privacy laws and regulations enacted by individual countries. For instance, the Personal Information Protection and Electronic Documents Act (PIPEDA) is a 2000 Canadian law that governs private sector organizations and corporations alike in how they collect, use, and disclose personal information in electronic commerce.

“For many entities, it can be important to ensure that their repositories and processes are in compliance with the many legal requirements of various data protection laws and regulations across the globe, as exemplified above. However, as entities grow and data protection laws evolve, existing records retention solutions have become inadequate. For instance, for a processor to scale up to service (e.g., orchestrate, validate, and enforce records retention compliance) one hundred billion objects per a controller is technically unattainable based on current architectures. Consequently, there is room for innovations and improvements in records retention compliance orchestration, validation, and enforcement.”

In addition to obtaining background information on this patent application, NewsRx editors also obtained the inventors’ summary information for this patent application: “Embodiments disclosed herein can address the aforementioned drawbacks and provide additional technical solutions and benefits. An object of the invention is to provide a scalable, efficient, and cost-effective solution for orchestrating records and compliance across multiple repositories. This solution represents a fundamental shift from prior records management approaches in that it includes Software as a Service (SaaS) operations with on-premises (also known as on-premise, and abbreviated as “on-prem”) components to access on-prem data repositories where sensitive and/or high risk data such as PII is stored, while compliance repositories can be external and centrally managed through an administrative interface hosted in a cloud computing environment.

“To realize this solution, embodiments disclosed herein provide systems, methods, and computer program products for cloud-based federated compliance orchestration, validation, and enforcement of records retention polices across disparate repositories. Such repositories can be characterized as being disparate at least because they have different metadata, schemas, and/or structures for how they manage records retention. While interconnecting multiple types of repositories of systems can be technically complex in and by itself, an additional challenge here is to provide metadata mapping between/among the disparate repositories so it becomes a functional SaaS solution over time without overly burdening administrative users.

“In some embodiments, a federated compliance system having a federated retention policy mapper and a cloud-based centralized user interface on a user device is adapted for presenting through the cloud-based centralized user interface, a policy of interest and representations of disparate systems that match the policy of interest. The disparate systems can include cloud based repositories and off-cloud repositories that operate in a distributed network computing environment and that employ different repository schemas.

“The federated compliance system is further adapted for prompting, through the cloud-based centralized user interface, a user to provide information on the policy of interest. The user-provided information on the policy of interest is utilized in determining attributes from the different repository schemas employed by the disparate systems in the distributed network computing environment. Using a data model, the federated retention policy mapper maps the attributes from the different repository schemas employed by the disparate systems to a common schema. This mapping produces a federated retention policy having the common schema. The federated retention policy is then stored in a federated space or common storage in the distributed network computing environment.

“In some embodiments, the federated compliance system further comprises a cloud orchestrator and an off-cloud orchestrator. The federated retention policy can be synced with the plurality of cloud-based repositories through the cloud orchestrator and also synced with the plurality of off-cloud repositories through the off-cloud orchestrator, for instance, via a secure tunnel provided by a tunnel server.

“In some embodiments, the federated retention policy mapper can be implemented as a compliance service. The compliance server can be one of a plurality of microservices provided by a computing platform particularly suitable for federated compliance and control of content. In some embodiments, the compliance service is adapted for communicating the federated retention policy directly to a retention policy service which, in turn, stores the federated retention policy in the federated space.

“The attributes required by the disparate systems can be categorized as those that are common in the disparate systems to which the policy of interest is applicable, those that are common in a repository type; those that are common across a single repository type; and those that are specific to a single repository.

“The federated retention policy thus created can be used to centrally automatically propagate changes across disparate systems. For instance, the federated compliance system may receive, through the cloud-based centralized user interface, an indication of a change to the policy of interest. The federated retention policy can be modified to reflect the change and the modified federated retention policy can be synced with the disparate systems by, for instance, mapping a data field in the common schema with a mapped data field in each repository schema.

“The federated retention policy thus created can also be used to centrally automatically associate a new policy with disparate systems. When a new policy is created, a set of attributes can be determined from the new policy and mapped to the federated retention policy, which is already associated with the disparate systems.

“In some embodiments, the federated compliance system is adapted for supporting single-phase and multi-phase policies. For instance, a determination can be made as to whether a repository of the disparate systems requires a data field for indicating a phase of a multi-phase policy. If such a data field is not required by the repository, the repository is mapped to a default value (e.g., single phase). Otherwise, it is mapped to a corresponding data field in the common schema for the federated retention policy.

“One embodiment comprises a system comprising a processor and a non-transitory computer-readable storage medium that stores computer instructions translatable by the processor to perform a method substantially as described herein. Another embodiment comprises a computer program product having a non-transitory computer-readable storage medium that stores computer instructions translatable by a processor to perform a method substantially as described herein. Numerous other embodiments are also possible.

“These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions and/or rearrangements.”

The claims supplied by the inventors are:

“1. A method, comprising: receiving, by a computer through a user interface, a change to a retention period specified in a federated retention policy that utilizes a common schema to describe attributes across disparate repositories associated with the federated retention policy, the disparate repositories residing in a distributed network computing environment and employing different repository schemas comprising the attributes; and automatically propagating, by the computer, the change to the retention period to the disparate repositories, the automatically propagating including updating the federated retention policy to reflect the change to the retention period, communicating the updated federated retention policy to a retention policy service which stores the updated federated retention policy in a federated storage, wherein the updated federated retention policy is pushed through an orchestrator to the disparate repositories.

“2. The method according to claim 1, wherein the common schema comprises data fields having names consistent across different repository types.

“3. The method according to claim 2, further comprising: creating the federated retention policy by: mapping any data fields in the common schema to attributes that are common to the disparate repositories; mapping any data fields in the common schema to attributes that are common to one or more repository types of the disparate repositories; mapping any data fields in the common schema to attributes that are common across a single repository type among the one or more repository types of the disparate repositories; and mapping any data fields in the common schema that are common in a single repository of the disparate repositories.

“4. The method according to claim 3, wherein an attribute of the attributes is not mapped to any of the data fields in the common schema and wherein the creating the federated retention policy further comprises: creating a data field in the common schema; and mapping the data field in the common schema to the attribute.

“5. The method according to claim 1, wherein the disparate repositories comprise a first repository that requires a data field for indicating a phase of a multi-phase policy and a second repository that does not have a data field for indicating a phase of a multi-phase policy.

“6. The method according to claim 1, wherein the disparate repositories comprise at least two different repository types.

“7. The method according to claim 1, wherein the disparate repositories are located in disparate physical locations.

“8. A system, comprising: a processor; a non-transitory computer-readable medium; and instructions stored on the non-transitory computer-readable medium and translatable by the processor for: receiving, through a user interface, a change to a retention period specified in a federated retention policy that utilizes a common schema to describe attributes across disparate repositories associated with the federated retention policy, the disparate repositories residing in a distributed network computing environment and employing different repository schemas comprising the attributes; and automatically propagating the change to the retention period to the disparate repositories, the automatically propagating including updating the federated retention policy to reflect the change to the retention period, communicating the updated federated retention policy to a retention policy service which stores the updated federated retention policy in a federated storage, wherein the updated federated retention policy is pushed through an orchestrator to the disparate repositories.

“9. The system of claim 8, wherein the common schema comprises data fields having names consistent across different repository types.

“10. The system of claim 9, wherein the instructions are further translatable by the processor for: creating the federated retention policy by: mapping any data fields in the common schema to attributes that are common to the disparate repositories; mapping any data fields in the common schema to attributes that are common to one or more repository types of the disparate repositories; mapping any data fields in the common schema to attributes that are common across a single repository type among the one or more repository types of the disparate repositories; and mapping any data fields in the common schema that are common in a single repository of the disparate repositories.

“11. The system of claim 10, wherein an attribute of the attributes is not mapped to any of the data fields in the common schema and wherein the creating the federated retention policy further comprises: creating a data field in the common schema; and mapping the data field in the common schema to the attribute.

“12. The system of claim 8, wherein the disparate repositories comprise a first repository that requires a data field for indicating a phase of a multi-phase policy and a second repository that does not have a data field for indicating a phase of a multi-phase policy.

“13. The system of claim 8, wherein the disparate repositories comprise at least two different repository types.

“14. The system of claim 8, wherein the disparate repositories are located in disparate physical locations.

“15. A computer program product comprising a non-transitory computer-readable medium storing instructions translatable by a processor for: receiving, through a user interface, a change to a retention period specified in a federated retention policy that utilizes a common schema to describe attributes across disparate repositories associated with the federated retention policy, the disparate repositories residing in a distributed network computing environment and employing different repository schemas comprising the attributes; and automatically propagating the change to the retention period to the disparate repositories, the automatically propagating including updating the federated retention policy to reflect the change to the retention period, communicating the updated federated retention policy to a retention policy service which stores the updated federated retention policy in a federated storage, wherein the updated federated retention policy is pushed through an orchestrator to the disparate repositories.

“16. The computer program product of claim 15, wherein the common schema comprises data fields having names consistent across different repository types.

“17. The computer program product of claim 16, wherein the instructions are further translatable by the processor for: creating the federated retention policy by: mapping any data fields in the common schema to attributes that are common to the disparate repositories; mapping any data fields in the common schema to attributes that are common to one or more repository types of the disparate repositories; mapping any data fields in the common schema to attributes that are common across a single repository type among the one or more repository types of the disparate repositories; and mapping any data fields in the common schema that are common in a single repository of the disparate repositories.

“18. The computer program product of claim 17, wherein an attribute of the attributes is not mapped to any of the data fields in the common schema and wherein the creating the federated retention policy further comprises: creating a data field in the common schema; and mapping the data field in the common schema to the attribute.

“19. The computer program product of claim 15, wherein the disparate repositories comprise a first repository that requires a data field for indicating a phase of a multi-phase policy and a second repository that does not have a data field for indicating a phase of a multi-phase policy.

“20. The computer program product of claim 15, wherein the disparate repositories comprise at least two different repository types.”

For more information, see this patent application: Anctil, Peter Joseph; Gerasimov, Alexander; Humby, David. Systems And Methods For Cloud-Based Federated Records Retention Compliance Orchestration, Validation And Enforcement. U.S. Patent Application Number 20230136439, filed December 28, 2022 and posted May 4, 2023. Patent URL (for desktop use only): https://ppubs.uspto.gov/pubwebapp/external.html?q=(20230136439)&db=US-PGPUB&type=ids

(Our reports deliver fact-based news of research and discoveries from around the world.)