Title:

Techniques and System to Monitor and Log Access of Information Based on System and User Context Using Policies

Document Type and Number:

United States Patent Application 20080060051

Kind Code:

Abstract:

An information management system approves or denies user requests to access information of the system. The information includes all types of information including documents and e-mail. The information management system is driven using a policy language having policies and policy abstractions. The information management system may approve or deny many different types of requests including opening a document or file, copying a file, printing a file, sending an e-mail, reading an e-mail, cut and paste of a portion of a document, saving a document, executing an application on a file, and many others.

Inventors:

Lim, Keng (Atherton, CA, US)

Plaque It!

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 11/615,604, filed Dec. 22, 2006, which claims the benefit of U.S. provisional patent applications 60/755,019 and 60/776,036, filed Dec. 29, 2005; 60/743,121, filed Jan. 11, 2006; 60/821,050, filed Aug. 1, 2006; and 60/870,195, filed Dec. 15, 2006. U.S. patent application Ser. No. 11/615,604 is also a continuation-in-part of U.S. patent application Ser. Nos. 11/383,159, 11/383,161, and 11/383,164, filed May 12, 2006. These applications are incorporated by reference along with all other references cited in this application.

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates to field of information and document management, and more specifically, a policy language system for managing information.

Networked computer systems have evolved over the years from simple serially connected computer systems to massively networked computer systems connected via large internal networks, intranets, and the Internet. During this evolution, many different concepts were developed to manage how users are granted access to electronic information stored in the computer systems. How a computer system determines if a user or an application has permission to access information (such as a file) has been a complex problem to solve.

Some operating systems use a simple approach to determining whether a user has permission to access a file. For example the Unix® operating system gives the system administrator or file owner the ability to attach access permissions to directories and files. Unix is a trademark of the Open Group. There are three types of access permissions that the system administrator or file owner can select from. The permissions are: read, write, and execute. These permissions can then be limited to three types of users: the owner of the file, the group that the owner belongs to, and other users. Each permission and user type has two states: allowed or denied.

Whenever a user accesses a file, the Unix operating system first checks the permissions set for a file against the user's type. The operating system checks if the user falls into any of the three user types. If the user is a member of any of the user types and the user type has been specified as allowed, then the operating system checks which of the permissions are set as allowed. The user is then allowed to perform any access that falls under an allowed permission.

This approach does not offer much flexibility to the system administrator. The system administrator cannot specify particular users other than the owner or particular groups. The permissions are limited to directories and files within the file system and do not cover nonfile system objects such as e-mails and Web pages. Further, the operating system checks permissions for file accesses based only on user and it does not restrict file accesses based on application programs.

A more advanced approach that is commonly used is called access control lists (ACL). An access control list uses a language that allows the system administrator or file owner to set read, write, and execute permissions for specific users and groups of users for accesses to files. In some approaches, each set of access control lists for a particular directory resides in a file stored in that directory. The access control lists apply to files that are contained within that directory.

When a user attempts to access a file in a directory, the operating system loads the access control list file and reads the access control list rules that were created by the system administrator or user. The operating system determines if the user is allowed to access the file by parsing the access control list rule. In other approaches, a set of access control lists associated with a file is stored as one or more extended file system attributes of the file. In another implementation, access control and auditing access control lists are stored in a security descriptor associated with a file or a directory.

There are many drawbacks to the access control list approach. The access control list approach applies only to files within a file system and does not apply to nonfile system objects such as e-mails and Web pages. The access control list support is built into the operating system kernel and cannot be extended.

The access control list approach is not very portable because it is file system specific and is therefore not universal which means that not all file systems support the same access control list and not all operating systems have the same interpretation of an access control list. When a file is copied from one file system to another (or from one operating system to another), some of the control information may be lost due to compatibility issues. Further, an access control list is difficult to apply to users outside of a company's file system (e.g., a customer). Finally, as with the operating system example above, an access control list is capable of controlling file accesses by a user but is not capable of controlling file accesses by a particular application program or at a particular time or location.

Applications such as document management systems require a user to check a document in and out of a library system. Once the document has been checked out, it can be distributed and modified in any manner. This means that there is no control over how a document is used once the document leaves the document management system.

An information management system should control access by users or applications, or a combination of these to information of the system. The information being controlled should include not only files and document, but also e-mails, access to Web sites, access to applications, instant messenger messages, databases, and much more. The information management system should have a flexible rule or policy language that allows for implementing simple or relatively complex controls on many aspects to the information. The information management system should also be capable of being used to secure the information to ensure confidentiality, to implement ethical walls, and more.

Therefore, there is a need for improved techniques and systems for managing information of a network, where this information includes documents and e-mail.

BRIEF SUMMARY OF THE INVENTION

In an implementation, the invention is a method of managing information including providing an organization having an information management system with a policy server having one or more rules and policy abstractions to manage information of the organization, where a rule has an expression having a policy abstraction. Within the organization, there is a user and a confidential document managed by the information management system. When the user attempts to access the confidential document, approval is sought from the policy server. If approved, the user is permitted to access the confidential document. If not approved, the user is blocked from accessing the confidential document.

In an implementation, the invention is a method of managing information including providing an organization having an information management system with a policy server having one or more rules having a context expression to manage information of the organization. Within the organization, there is a user and a confidential document managed by the information management system. When the user attempts to access the confidential document, approval is sought from the policy server. If approved, the user is permitted to access the confidential document. If not approved, the user is blocked from accessing the confidential document.

In an implementation, the invention is a method of managing information including providing an organization having an information management system with a policy server having one or more rules to manage information of the organization. Within the organization, there is a user logged onto a device and a confidential document managed by the information management system. A subset of the one or more rules of the policy server on the device is stored, where the subset of the one or more rules are not embedded in the confidential document. When the user attempts to access the confidential document, the method includes evaluating on the device whether to approve access to the confidential document. If approved, the user is permitted to access the confidential document. If not approved, the user is blocked from accessing the confidential document.

In an implementation, the invention is a method of managing information including providing an organization having an information management system with one or more rules and policy abstractions to manage information of the organization, where a rule includes an expression having a policy abstraction. Within the organization, there is a user and a confidential document managed by the information management system. When the user attempts to perform an operation on the confidential document, the method includes evaluating the one or more rules to determine whether to store information regarding the attempted operation in a storage location.

In an implementation, the invention is a method of managing information includes providing an organization having an information management system having one or more rules including a context expression to manage information of the organization. Within the organization, there is a user and a confidential document managed by the information management system. When the user attempts to perform an operation on the confidential document, the method includes evaluating the one or more rules to determine whether to store information regarding the attempted operation in a storage location.

In an implementation, the invention is a method of managing information including providing an organization with an information management system including a policy server having one or more rules to manage information of the organization. Within the organization, there is a user logged onto a device and a confidential document managed by the information management system. A subset of the one or more rules of the policy server is stored on the device. When the user attempts to perform an operation on the confidential document, the method includes evaluating the one or more rules to determine whether to store information regarding the attempted operation in a storage location.

Other objects, features, and advantages of the present invention will become apparent upon consideration of the following detailed description and the accompanying drawings, in which like reference designations represent like features throughout the figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a diagram of distributed computing network connecting a server and clients.

FIG. 2 shows a more detailed diagram of a computer system which may be a client or server.

FIG. 3 shows a system block diagram of a computer system.

FIG. 4 shows a block diagram of a policy server that centrally manages policies that are used by workstations and servers according to a specific implementation of the invention.

FIG. 5 shows a block diagram of a number of workstations and document servers with policy enforcers installed and coexist within a system according to a specific implementation of the invention.

FIG. 6 shows a block diagram of minimal embodiments that utilize a number of workstations each with policy enforcers installed or a number of document servers each with policy enforcers installed according to a specific implementation of the invention.

FIG. 7 shows a block diagram of internal components of a policy server according to a specific implementation of the invention.

FIG. 8 shows a block diagram of the internal components of an intelligence server according to a specific implementation of the invention.

FIG. 9 shows a block diagram of an interceptor and a consequence applicator in a policy enforcement point (PEP) module according to a specific implementation of the invention.

FIG. 10 shows a block diagram of a policy enforcer that implements interception and enforcement functions using a PEP plug-in architecture according to a specific implementation of the invention.

FIG. 11 shows a block diagram of a policy enforcer installed on a workstation that controls access to files on the workstation according to the invention.

FIG. 12 shows a block diagram of a policy enforcer on a workstation enforcing access control to a nonfile system object according to the invention.

FIG. 13 shows a layer description of an implementation of a policy language system of the invention.

FIG. 14 shows the functional modes of an information system of the invention.

FIG. 15 shows an example of interactions between multiple policies and multiples policy abstractions and their interaction.

FIG. 16 shows an example of one policy and multiple policy abstractions, where one policy abstractions references other policy abstractions.

FIG. 17 shows accessing confidential document, seeking approval, with centralized decision.

FIG. 18 shows accessing confidential document, seeking approval, with distributed decision.

FIG. 19 shows blocking sending of a confidential document outside the company.

FIG. 20 shows encrypting a confidential document when copying to a removable device.

FIG. 21 shows sending of a confidential document between users who should observe separation of duties.

FIG. 22 shows an example of a deployment operation to a workstation of an information management system.

FIG. 23 shows an example of a deployment operation of rules associated with a user.

FIG. 24 shows an example of a push operation, pushing one set of rules to a workstation and another set of rules to a server.

FIGS. 25-50 show syntax diagrams for a specific implementation of a policy language, the Compliant Enterprise Active Control Policy Language (ACPL).

FIG. 51 provides a legend explaining the nodes used in FIGS. 25-50.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a simplified block diagram of a distributed computer network 100 incorporating an embodiment of the present invention. Computer network 100 includes a number of client systems 113, 116, and 119, and a server system 122 coupled to a communication network 124 via a number of communication links 128. Communication network 124 provides a mechanism for allowing the various components of distributed network 100 to communicate and exchange information with each other.

Communication network 124 may itself be comprised of many interconnected computer systems and communication links. Communication links 128 may be hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information. Various communication protocols may be used to facilitate communication between the various systems shown in FIG. 1. These communication protocols may include TCP/IP, HTTP protocols, wireless application protocol (WAP), vendor-specific protocols, customized protocols, and others. While in one embodiment, communication network 124 is the Internet, in other embodiments, communication network 124 may be any suitable communication network including a local area network (LAN), a wide area network (WAN), a wireless network, a intranet, a private network, a public network, a switched network, and combinations of these, and the like.

Distributed computer network 100 in FIG. 1 is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, more than one server system 122 may be connected to communication network 124. As another example, a number of client systems 113, 116, and 119 may be coupled to communication network 124 via an access provider (not shown) or via some other server system.

Client systems 113, 116, and 119 typically request information from a server computer system which provides the information. For this reason, servers typically have more computing and storage capacity than client systems. However, a particular computer system may act as both as a client or a server depending on whether the computer system is requesting or providing information. Additionally, although the invention has been described using a client-server environment, it should be apparent that the invention may also be embodied in a stand-alone computer system.

Server 122 is responsible for receiving information requests from client systems 113, 116, and 119, performing processing required to satisfy the requests, and for forwarding the results corresponding to the requests back to the requesting client system. The processing required to satisfy the request may be performed by server 122 or may alternatively be delegated to other servers connected to communication network 124.

Client systems 113, 116, and 119 enable users to access and query information stored by server system 122. In a specific embodiment, a “web browser” application executing on a client system enables users to select, access, retrieve, or query information stored by server system 122. Examples of web browsers include the Internet Explorer browser by Microsoft Corporation, the Firefox® browser by Mozilla Foundation, and others.

FIG. 2 shows a more detailed diagram of a computer system which may be a client or server. FIG. 2 shows a computer system 201 that includes a monitor 203, screen 205, cabinet 207, keyboard 209, and mouse 211. Mouse 211 may have one or more buttons such as mouse buttons 213. Cabinet 207 houses familiar computer components, some of which are not shown, such as a processor, memory, mass storage devices 217, and the like. Mass storage devices 217 may include mass disk drives, floppy disks, Iomega ZIP™ disks, USB removable storage, magnetic disks, fixed disks, hard disks, hard drives including both magnetic and flash storage in a single drive unit, CD-ROMs, recordable CDs, DVDs, DVD-R, DVD-RW, HD-DVD, Blu-ray DVD, flash and other nonvolatile solid-state storage, tape storage, reader, and other similar media, and combinations of these.

A computer-implemented or computer-executable version of the invention may be embodied using, stored on, or associated with computer-readable medium. A computer-readable medium may include any medium that participates in providing instructions to one or more processors for execution. Such a medium may take many forms including, but not limited to, nonvolatile, volatile, and transmission media. Nonvolatile media includes, for example, flash memory, or optical or magnetic disks. Volatile media includes static or dynamic memory, such as cache memory or RAM. Transmission media includes coaxial cables, copper wire, fiber optic lines, and wires arranged in a bus. Transmission media can also take the form of electromagnetic, radio frequency, acoustic, or light waves, such as those generated during radio wave and infrared data communications.

For example, a binary, machine-executable version, of the software of the present invention may be stored or reside in RAM or cache memory, or on mass storage device 217. The source code of the software of the present invention may also be stored or reside on mass storage device 217 (e.g., hard disk, magnetic disk, tape, or CD-ROM). As a further example, code of the invention may be transmitted via wires, radio waves, or through a network such as the Internet.

FIG. 3 shows a system block diagram of computer system 201 used to execute the software of the present invention. As in FIG. 2, computer system 201 includes monitor 203, keyboard 209, and mass storage devices 217. Computer system 201 further includes subsystems such as central processor 302, system memory 304, input/output (I/O) controller 306, display adapter 308, serial or universal serial bus (USB) port 312, network interface 318, and speaker 320. The invention may also be used with computer systems with additional or fewer subsystems. For example, a computer system could include more than one processor 302 (i.e., a multiprocessor system) or a system may include a cache memory. The processor may be a multicore processor, such as the Intel Core 2 Duo, Intel Pentium® D, AMD Athlon™ 64 X2 Dual-Core, or Microsoft Xbox 360 central processing unit (CPU).

Arrows such as 322 represent the system bus architecture of computer system 201. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems. For example, speaker 320 could be connected to the other subsystems through a port or have an internal direct connection to central processor 302. Computer system 201 shown in FIG. 2 is but an example of a computer system suitable for use with the present invention. Other configurations of subsystems suitable for use with the present invention will be readily apparent to one of ordinary skill in the art.

Computer software products may be written in any of various suitable programming languages, such as C, C++, C#, Pascal, Fortran, Perl, Matlab (from MathWorks, www.mathworks.com), SAS, SPSS, JavaScript, AJAX, and Java. The computer software product may be an independent application with data input and data display modules. Alternatively, the computer software products may be classes that may be instantiated as distributed objects. The computer software products may also be component software such as Java Beans (from Sun Microsystems) or Enterprise Java Beans (EJB from Sun Microsystems). An operating system for the system may be one of the Microsoft Windows® family of operating systems (e.g., Windows 95, 98, Me, Windows NT, Windows 2000, Windows XP, Windows Vista, Windows CE, Windows Mobile), Linux, UNIX, Sun OS, Ubuntu, or Macintosh OS X. Other operating systems may be used. Microsoft Windows is a trademark of Microsoft Corporation.

FIG. 4 shows an overall architecture of an information management system of the invention. An embodiment of the invention centrally manages policies or rules pertaining to the controlling of access to and usage of information including documents. Documents can be file system or nonfile system objects. For example, a file system object may be an Excel spreadsheet. A nonfile system object may be an e-mail message or data delivered to an SAP Frontend client application (e.g., information about an employee) by an SAP human resource module running on a server. Some examples of disk file systems include FAT, NTFS, HFS, ext2, ext3, ISO 9660, ODS-5, and UDF.

A document may encompass objects such as a file, an e-mail message, a Web page, an on-line report, an on-line form, a discussion thread, a result set generated by a database query, an on-line form, a bitmap, a file system object, a data object managed by a document management system, a data object managed by a content management server, a data object in a product lifecycle management system, a source code file or a code fragment managed by a source code management system, a data object managed by a configuration management system, a data object managed by a project management system, a data object in an enterprise resource planning system, a data object in a customer relationship management system, a data object managed or served, or both, by a portal server, a data object served by a Web server, a data object managed or served by any application server, or any unit of information content stored using volatile or nonvolatile memory.

The policies allow policy enforcers (which may be called agents in specific embodiments) to make decisions on whether to allow or deny access to a particular information, execute a particular application function, or operate on a particular application data object or fragment. The policy enforcers are able to perform information access control for operations resulted from user action through an application program and execution of application program logic.

Referring to FIG. 4, policies are created and managed by a policy server 401. As discussed below, a policy may define to whom and under what conditions (or conditions) access to a document is granted or denied. The policies are stored and manipulated by the policy author and policy administrator in the policy repository 402. Policies or subsets of policies, or both, are transmitted to workstations 403 and document servers 405 to control local and remote document accesses and information usage.

Some examples of a workstation include a desktop computer, laptop computer, personal digital assistant (PDA), smart phone, thin client (e.g., HP Consolidated Client Infrastructure client or Wyse terminal), an instance of client operating environment running on a terminal server (e.g., Microsoft Windows 2003 Terminal Services and Citrix MetaFrame), a guest operating system running on a virtual machine (e.g., VMWare Workstation and Microsoft Virtual Server 2005), a server making document access or information usage request (i.e., acting as a client in the context of the request), Internet kiosk, and information kiosk. A workstation may be any computing device and computing environment from which document access or information usage request is originated.

Some examples of a document server include a file server, network attached storage (NAS), virtual NAS device (e.g., a NAS switch device such as Acopia Adaptive Resource Switch, NeoPath File Director, or Rainfinity RainStorage), edge file gateway (e.g., a wide area file service (WAFS) device such as Cisco File Engine series appliances or Tacit IShared products or Riverbed Steelhead appliances), Web server, e-mail server, document management system, content management server, portal server, or database server. A document server may be other document repository.

A policy enforcer can be installed on a workstation 403 to provide document access and information usage control at a point-of-use. The policies can be stored locally on the workstation. Objectives of implementing point-of-use control include preventing unauthorized access to documents anywhere on the network and preventing unauthorized information usage and operation on application data or usage of application functions. One may think of an aspect of point-of-use access control as building a firewall around a user.

Some details on policy enforcement are described in U.S. provisional application 60/755,019, filed Dec. 29, 2005. More details on policy enforcement are described in the U.S. patent application Ser. Nos. 11/383,159, 11/383,161, and 11/383,164, filed May 12, 2006. These applications are incorporated by reference along with all other references cited in this application.

Similarly, a policy enforcer can be installed on a document server 405 (e.g., file server and e-mail server) to provide protection to the documents on (accessible by or managed by) the document server. Information may reside on different places of the network. For example, documents or information may reside on disk arrays in a separate server enclosure that is physically separate from a document server. In particular, direct attached storage (DAS) has multiple disk arrays and storage area network (SAN) has file server volumes that are virtualized. An objective of implementing server-based protection is to prevent unauthorized access to documents in a particular repository (or on a server) from any computer on a network. In other words, one may think of this aspect of the invention as building a firewall around a server. Besides, an application server policy enforcer such as Microsoft Exchange policy enforcer can also control usage of application data and application functions (e.g., copying an e-mail message, deleting a contact and modifying a calendar entry).

The control and protection functions can be achieved either through one policy or multiple policies defined centrally. The policy server 401 is an intelligent system that has the ability to decide if a single or multiple policies or subset of policies are applicable to each policy enforcer. At least a subset of all policies defined is distributed to each policy enforcer.

Controlling document access can have different meanings when operating on different document types. For example, if a document type is a file, then document accesses are file accesses that includes: opening/reading a file, reading a file when connected using VPN, opening a file at a particular time of a day, writing/saving a file, deleting a file, reading a file's permission (or security setting), changing a file's permission, reading a file's attribute, or changing a file's attribute. Another example is when a document type is an e-mail message on a mail server then document access refers to application program internal operations that can include: opening an e-mail, deleting an e-mail, reading an e-mail's attribute, or changing an e-mail's attribute.

Controlling information usage can have different meanings when applied to different applications. For example, if an application is word processing software, then information usage includes creating a file, opening a file, saving a file, saving a document as a different file, exporting or converting a file to a different format, printing a file, sending a file to a recipient via e-mail, publishing a file in a shared folder, cutting data to clipboard, pasting data from clipboard, performing drag-and-drop operation, adding macro or script to a document, or modifying macro or script in a document. In another example where an application is mail client software, information usage includes creating an e-mail, opening an e-mail, copying an e-mail, moving an e-mail, archiving an e-mail, saving an e-mail into a file, deleting an e-mail, sending an e-mail, forward an e-mail, attaching a file to an e-mail, cutting data to clipboard, pasting data from clipboard, performing drag-and-drop operation, or changing e-mail attributes.

In yet another example, if an application is an enterprise resource planning (ERP) application, information usage includes: creating a quote, converting a quote to an order, viewing customer information, viewing an order, viewing product pricing and discounts, viewing sales data, viewing reports, or viewing employee information.

To control document access and information usage, a policy enforcer may control user interface elements such as visual and input elements of an application program, commands and functionalities of an application program, and information presented to a user. For example, a visual element of an application program includes any of: a menu, a menu item, a button, a list box, a list item, a check box, a tab, a scroll bar, a slider, an icon, an image or a hypertext link. An input element of an application program includes any of: a key event handler, a mouse event handler, or any event handler associated with a visual element.

An application program may support a large number of commands. A command can be invoked by selecting a menu item, pressing a button (shown on a screen), pressing one or more keys, or pressing one or more mouse buttons. A command can also be invoked by a macro or script, or invoked by a code module that calls a function (or method) in an application program interface (API) library. For example, a command can perform a task such as opening a file, sending an e-mail message, editing a cell in a spreadsheet, editing a macro, changing text format, or more.

A function of an application program generally maps to a function or method in a high level programming language. For example, a function in an application program may correspond to a command such as saving a file, sending an e-mail message, or editing a cell formula in a spreadsheet. A function may also represent an internal application program operation such as a call to operating system library function fopen( ).

If information to be displayed contains personal information such as a social security number, personal identification number (PIN) or account balance, then controlling information usage includes: filtering out or obscuring the personal information.

If information to be displayed contains actionable data or objects such as a button, a hypertext link, or a clickable image, then controlling information usage includes: disabling the button, removing the hypertext link, or removing the link associated with the image.

In addition to providing control or protection, a policy enforcer can also perform obligation and remediation operations (described further below) as a result of a document access or information usage attempt (whether successful or not) as dictated by an active policy or policies. Obligation refers to tasks related to an action that a policy engine is currently processing and that the policy engine is obliged to complete such tasks. Remediation refers to tasks not directly related to an action that a policy engine is currently processing and that the policy engine ought to carry out.

Different levels of control and protection are achieved by distributing policy enforcers to workstations or document servers, or both. For example, by using workstation policy enforcers only, such as on workstation 403, one can achieve document access and information usage control that covers access to documents on local disks 404 (i.e., local files), access to documents on a protected document server 405 (i.e., protected by document server policy enforcer), and access to documents on an unprotected document server 406.

In an implementation where only document server policy enforcers are used, such as document server 405, one can achieve document access protection and information usage control for documents on protected servers. The documents are accessed from workstations with a workstation policy enforcer installed 403 and workstations without a workstation policy enforcer installed 407.

When both workstation policy enforcers and document server policy enforcers are installed, the combined benefit of both installations as described above will be obtained.

The policy server 401 allows policies to be centrally managed and automatically distributed and updated to policy enforcers. In a specific embodiment, policies are not tied to (or stored with) documents. The policies are evaluated when an action is taken by a user (or an application) to access a document. The action is intercepted and relevant policies are applied before the action is allowed to be carried out.

There are reaction policies and maintenance policies. A reaction policy is a policy which is triggered by an action such as a user opening a file or sending an e-mail. A maintenance policy is a policy which is triggered by a scheduler, such as a program that causes the maintenance policy to execute at a certain time, such as daily, weekly, or monthly, upon another nonaction event, or triggered by (or invoked by) a reaction policy. Implementations of the invention may include reaction policies or maintenance policies, or both.

The policies that a policy enforcer can handle may be defined based on the type of action, user, user group, user attribute (e.g., department, role, project or status (e.g., full-time, part-time, or consultant), user's business function), e-mail address, mailing list, host, group of computers (e.g., finance department computers), type of computer (e.g., laptop and smart phone), application program (e.g., Word, Excel, PowerPoint, FrontPage, Access, Visio, Outlook, or Internet Explorer), type of application program (e.g., word processor, spreadsheet, database, or browser), application module (e.g., SAP CRM module or Oracle Finance accounting module), location (e.g., New York office versus London office), connectivity (including access mechanism and bandwidth; e.g., LAN, WLAN, VPN, Bluetooth, Internet, DSL, ISDN, dialup, remote desktop protocol (RDP), virtual network computing (VNC) protocol, latency, secure point-to-point, 56 k, broadband, 100 megabit per second, and 1 gigabit per second), time of day, day of the week, file path, file name, document size, document timestamp, document owner, document properties, document type (e.g., file or e-mail), document format (e.g., XLS, PDF, or HTML format), document identifier, document classification (e.g., confidential document or financial report), document characteristics (e.g., contains a watermark), document content (e.g., contains social security number), database query, database query result set, database query result set properties, metadata, and more. Not all of these parameters are required. A policy enforcer can interpret any one or combination of these parameters.

Referring to FIG. 5, a more complex embodiment is shown where both a number of workstations 515 and document servers 517 have policy enforcers 516 and 518 installed and coexist within the system. The interaction between a policy builder 501, policy server 506, and policy repository 507 will be described further below.

A reporting and analysis module 502 acts as a user interface to an intelligence server 510 for displaying reports and results from data analysis functions. A reporting module 503 allows policy author and policy administrator to query and view document access activity, information usage activity and policy enforcement activity. An analysis tool 504 interacts with the intelligence server 510 to perform data analysis which includes trend analysis, resource utilization analysis, workforce productivity analysis, analyze effectiveness of policies, event correlation, anomaly detection, signature (or pattern) detection, threshold violation detection, detect information misuse, or fraud detection. Policy author and policy administrator can use the capabilities offered by the reporting and analysis module 502 to analyze effectiveness of a policy, analyze document access and information usage activity on a document or on a server, analyze policy enforcement activity, investigate cases of potential information misuse, detect information fraud, identify potential workforce productivity improvement, optimize resource utilization, or forecast resource requirement. Intelligence server 510 provides functions including (i) log services, (ii) integrate with external data sources, and (iii) data analysis.

A log and intelligence repository 511 is used by intelligence server 510 to store log data coming from policy enforcers 516 and 518, data from external sources that support event correlation and data analysis, and data generated by data analysis services. Log and intelligence repository 511 is normally implemented as one or more relational databases or sets of log files.

A lightweight directory access protocol (LDAP) server 508 and LDAP repository 509 provide user, user group, and host information to the policy server to assist in composing policy and assembling policy subsets and provide information to intelligence server to support report generation and data analysis. Note that LDAP servers are typically deployed in organizations to provide authentication service and are not critical for the operation of the embodiment.

A management server 512 is responsible for system configuration (not policy configuration), system health monitoring, and system control. It provides centralized management of all the components in the system. The management server provides a single location to view system status, modify system configurations, and manage policy author and policy administrator user accounts. A management console 505 is a user interface for system management via the management server.

The management server provides services such as monitoring other system components including policy servers, intelligence servers, communication servers and policy enforcers; displaying the status of each component; registering new policy enforcers and maintaining a registry of all policy enforcers; managing the configuration for all servers; and managing configuration profiles for policy enforcers.

A communication server 514 is responsible for directing traffic among the policy server, intelligence server, management server, and policy enforcers. The communication server brokers communications between policy enforcers and other servers, including distribution of configuration profiles, policy deployments, and the transfer of log data to the intelligence server. The communication server provides a scalable communication service such that the system can support a large number of workstations and document servers.

Referring to FIG. 6, minimal embodiments are shown that utilize a number of workstations 610, each with policy enforcers 611 installed, or a number of document servers 612, each with policy enforcers 613 installed. An authoring and administration module 601 is a client application running on a workstation. It provides the user interface to create, test, publish, modify, delete, or deploy policies, or any combination of these, manage system configuration, monitor system health and view document access activity, information usage activity and policy enforcement activity. The authoring and administration module 601 is connected to a control center 605. The control center is responsible for policy life cycle management, system management, and log data management, and maintains a central policy and log repository 609.

A policy builder 602 acts as an interface to the policy server 606 and makes it simpler for policy author and policy administrator to create, test, publish, and deploy policy rule statements. The main tasks that can be performed with policy builder 602 are policy authoring and policy administration. Policy authoring functions include creating policy, modifying policy, testing policy, publishing policy (making new policy available for deployment and policy modifications available for redeployment) and retiring policy. Policy administration functions include maintaining policy related configurations and deploying policies to policy enforcers.

A management console 603 acts as an interface to management server 607 and is a user interface for managing system configuration and health of the system.

A policy server 606 transfers policies to the policy enforcers 611 and 613. The policy server 606 determines what policies are to be delivered to the policy enforcers and when policies are to be updated on the policy enforcers. The policy enforcers report status logs such as what documents were accessed or application program functions were used, and by whom (described below) and what enforcement actions have been taken to the log server 608.

In a specific implementation, a policy server deploys policies to devices that make policy decisions. These devices typically have one or more policy engines. A policy engine may be a component of a policy enforcer, policy decision server, or policy simulator.

A reporting module 604 is a user interface element that interacts with the log server to provide report generation and data analysis functions. Policy author and policy administrator can use the reporting module to view document access activity, information usage activity and policy enforcement activity and investigate cases of potential information misuse, understand the effectiveness of a policy, detect information fraud, identify potential workforce productivity improvement, optimize resource utilization, or forecast resource requirement.

Referring to FIG. 7, the internal components of the policy server 701 are shown. The policy server is responsible for policy management, including policy authoring, lifecycle, and deployment. The policy server maintains a policy repository, 402 and 507, for storing policies. A system typically has at least one policy server and can contain multiple policy servers in order to support a large number of policy builders 501 and policy enforcers 516 and 518. The policy server provides the following functions: policy authoring, policy access control, policy lifecycle management, policy management and policy deployment.

Policy authors and policy administrators access the policy server through the policy builder application 501 which provides in a specific implementation, a graphical user interface to author policies and manage the policy lifecycle from creation through retirement. Authored policies are stored in a central policy repository.

A policy lifecycle module 702 provides policy lifecycle support that covers policy development, deployment, and management. For example, policy development uses information about users, user groups, roles of users, user's business functions, recipients, actions, hosts, applications and document resources being supported to compose or update a policy. An environment is also provided to support editing (composition), staging (testing), and deployment of policies.

A policy engine 703 (or policy decision point) is responsible for policy evaluation (or execution). It helps validate a policy and it is part of the staging environment. Additionally, the policy engine can be setup to support proxy policy evaluation. A proxy policy evaluation request may be generated by a policy enforcer under two situations:

(1) A workstation policy enforcer 516 (or document server policy enforcer 518) does not have a policy engine. A policy engine proxy in the policy enforcer relays policy evaluation requests from policy enforcers to a remote policy engine 703 in a policy server 701 that offers policy evaluation services.

(2) A workstation policy enforcer 516 (or document server policy enforcer 518) does have a policy engine, but the local policy engine decides that the local policy subset is not sufficient to make a policy decision and should delegate policy evaluation to a policy engine that has access to wider policy scope, or access to relevant data. A proxy policy evaluation request is made by a local policy engine to a remote policy engine 703 in the policy server 701 to complete the policy evaluation.

A policy optimizer 704 will optimize the run-time performance of policies. The policy optimize can optimize policies prior to deploying to a policy enforcer. A policy optimizer is not necessary for operation of a minimal system, and some implementations of the invention will not include a policy optimizer. However, when a policy optimizer is included, the performance of the system will be enhanced. More specifically, the policies may be reduced in size, thus take less memory, and may also execute faster. More details on optimization are discussed below.

Typically a policy optimizer performs one or more of the following optimizations: (1) common subexpression elimination, (2) constant folding, (3) constant propagation, (4) comparison optimization, (5) dead code or subexpression removal, or (6) redundant policy elimination. These will be discussed in more detail below.

A policy deployment module 705 handles the deployment of policies to policy enforcers, policy decision servers (not shown), and a location where a policy engine resides. During policy deployment, the policy deployment module may invoke policy optimizer 704 to optimize a set of polices. The set of policies can be a full set or subset of policies on the policy server. The deployment function may be initiated by a policy server (which may be referred to as a push operation) or a policy enforcer or target (which may be referred to as a pull operation). In either operational mode, a full set or subset of policies or a set of differences may be transmitted to a target.

In a policy system architecture that distributes full sets of policies to all policy enforcers, the policy deployment module takes a complete set of policies and sends it to a policy enforcer. In a policy system architecture that organizes policies based on one or more specific policy enforcers or policies targets, the policy deployment module receives or locates a policy enforcer's information and delivers the set of policies or a set of differences relevant to that policy enforcer.

In a further implementation, the policy deployment module can deploy policies in different forms depending on the capability of policy engine at the target. For example, the set of polices that is transmitted from the policy server to a policy enforcer (or target) may take one of the following forms: (1) ASCII text, (2) binary (e.g., code or data), (3) XML (e.g., in Extensible Access Control Markup Language—XACML format), or (4) translated or compiled including policies represented in binary form, polices translated into tables (in binary or text form) or policies translated into programming language (such as XML, Java, C#, Perl, or Python in source code format or compiled binaries), or a combination of these. C# is an object-oriented programming language developed by Microsoft as part of their .NET initiative. C# is based on C++ and Java.

In a specific implementation, the deployment module can translate a set of policies and policy abstractions in one policy language to another policy language. For example, an information management policy can be transformed into one or more firewall policies for a target that is a firewall device.

FIG. 8 shows the internal components of the intelligence server 801. The intelligence server provides summary and trend analysis, signature (or pattern), anomaly, and threshold detection on document access activity, information usage activity, and policy enforcement activity. The intelligence server is accessed using the reporting and analysis 502 software tool that allows business users to create graphical reports to demonstrate compliance, understand information usage, investigate cases of information misuse, understand the effectiveness of a policy, detect information fraud, identify potential workforce productivity improvement, optimize resource utilization, forecast resource requirement, or combinations of these. The intelligence server analyzes comprehensive log data captured in a centralized repository, which will provide insight and accountability for information handling. Policy authors can use data captured by the intelligence server to analyze the effectiveness of a policy. Policy enforcers can utilize the log data and information derived from the log data to support policy evaluation.

The log services module 802 is responsible for collecting and managing log data coming from the policy enforcers. Log data is normally generated or collected by a policy enforcer or a policy engine or explicitly by a policy via a log handler (an obligation handler) in a policy enforcer.

The integration services module 803 is responsible for capturing events occur outside the system and provide access to an external data sources when needed. It may collect data produced by other application programs outside of the system or import data stored outside the system into a log and intelligence repository 309. The integration services module can also export log and analysis data to application program or repository outside of the system. It allows the data analysis module 805 to correlate document access activities, information usage activities and policy enforcement activities with events occur external to the system.

The reporting module 804 is responsible for providing support to the reporting and analysis tool 502. Its main function is report generation.

The data analysis module 805 provides data analysis functions such as event (or log) correlation. For example, one of the functions of the event correlation engine in the data analysis module is to correlate separate events that occur within a policy enforcer or across multiple policy enforcers to identify trends, repetitions, fraud, hacking attempts and other attacks, bad policy designs, or bad practices by users. The data analysis module can provide several types of analyses including:

(1) Summary Analysis-document access activity, information usage activity or policy enforcement activity summarized by user, document, host, policy, location, time (e.g., day or week), organization, and more.

(2) Trend Analysis-document access activity, information usage activity, or policy enforcement activity for a given period of time.

(3) Detailed Event Forensics-detailed listing of activities for specific user actions or policy enforcement actions. Detailed reports showing event-level details for document access activity, information usage activity, or policy enforcement activity.

Compliance officers can use event forensics to investigate specific incidents of information misuse. Information security officers can use event forensics to detect information fraud, hacking attempts, unauthorized access to information, change in a user's information usage behavior, change in a group of users' information usage behavior, or anomaly using a reference activity profile. For an information technology (IT) manager, event forensics can be used to understand resource utilization, determine how many software licenses are being used, determine how to allocate training and support resources based on actual information usage, or identify areas of potential productivity improvement.

A policy enforcer provides three functions: interception (or detection), decision, and enforcement.

Interception refers to a function of detecting certain operations (e.g., carried out through altering normal code execution that implements the operation) in an existing application program or operating system to allow the operations to be examined by a policy enforcer before the operation is carried out. Alternatively, interception may refer to a function in an application program or operating system (e.g., the logic is implemented at development time) where the function affects examination of an operation by a policy enforcer before the operation is carried out. For example, the function in an application program is a procedure call to a policy enforcer application program interface (API) library.

Decision refers to a process of evaluating zero or more policies (or rules) relevant to an intercepted (or detected) operation and determine if the operation should be carried out, and if additional actions need to be performed.

The enforcement function is responsible for implementing the outcome (sometimes called a policy effect) produced by the decision function. For example, if a policy effect is DENY, an operation is blocked.

Interception and enforcement are normally functions of a policy enforcement point (PEP) and decision is a function of a policy engine (described further below). Both PEP and policy engine are components of a policy enforcer. In addition, a policy enforcer can carry out audit (or log) function, and obligation and remediation tasks (described below).

There can be at least two types of policy enforcers that can exist in a system in order to provide a multilayer approach to information control and compliance enforcement: document server policy enforcers and workstation policy enforcers. Document server policy enforcers are designed to control access to and usage of documents (or information) on document servers. While workstation policy enforcers are designed to control end-user access to and usage of documents (or information) on workstations and document servers and information usage by end-users at a workstation. Combining both types of policy enforcers in an embodiment provides control over document access from a workstation controlled by a policy enforcer, from a workstation not controlled by a policy enforcer, to a document server controlled by a policy enforcer, and to a document server not controlled by a policy enforcer, and control the usage of information by organization personnel.

Policy enforcers are responsible for both enforcing policy and collecting audit information (document access activities, information usage activities and policy enforcement activities) for their respective host systems. The policy enforcers intercept end-user or system events (or actions) or information usage (e.g., invoking a function in an application program and operating on data in an application) that may be subject to document access or information usage control policies. The context of each of these events is provided by a PEP to a policy engine which is responsible for evaluating policies relevant to the context. The consequence determined by policy evaluation is communicated back to the PEP, which contains application-specific or system-specific logic to carry out the enforcement function. If the policy evaluation results in the requested event being denied, the PEP typically terminates the request and returns an error status that indicates access is denied or the requested action cannot be performed.

Since policy enforcers have access to information regarding document access and information usage, such activity information (or audit information) can be logged by a policy enforcer to a local or central database. The activity data collected by one or more policy enforcers can be correlated, analyzed, and applied to many applications including: (1) auditing or compliance; (2) investigation; (3) detecting information fraud; (4) detecting information misuse; (5) detecting anomalies; (6) understanding and optimizing resource utilization; and (7) understanding and improving workforce productivity.

Document server policy enforcers are server (e.g., file server) or server application program (e.g., mail server) specific policy enforcers. For example, a file server policy enforcer (discussed below) is designed to protect file resources on (or accessible by or managed by) the file server. In a different example, an e-mail server policy enforcer such as Microsoft Exchange Server policy enforcer controls access to and usage of e-mail and other Microsoft Exchange Server application objects on the server. In another example, a document management system (DMS) policy enforcer controls access to and usage of documents stored in a DMS repository and other DMS specific application objects.

Document server policy enforcer is installed on a server computer (e.g., file server) or on the computer where a server application program (e.g., mail server) is installed. Alternatively, some policy enforcer functions including policy engine can be distributed to a separate computer. The interception function carried out by a PEP is server and server application program specific and can occur inside a server application program or at operating system level.

A file server policy enforcer is a type of document server policy enforcer. The file server policy enforcer controls access to and use of (e.g., copy or print) files on file servers. It is installed on a file server machine and enforces document access policies or information usage policies, or both, as organization personnel interact with the file server. Document access policies control whether users or application programs are allowed to access files and folders on (or accessible by or managed by) a file server including: create, read, write, delete, copy, move, and rename files; create, open, encrypt, delete, and rename folders; access and change file or folder attributes; and create, access, change, rename, and delete links or shortcuts associate with files or folders. The policy enforcers also log access to files and folders and information about each enforcement event.

The file server policy enforcer monitors network requests for files and also monitors file system requests. This architecture allows the policy enforcer to evaluate policies based on the greatest amount of context for each request, since it can use both network-level and file system-level information. Certain file access operations can also be intercepted inside a server application program (e.g., a NFS server) and at operating system level.

In a specific file system implementation, both a file server policy enforcer and a workstation policy enforcer (described below) are typically needed to provide thorough protection to the resources managed by the file system. For example, Andrew File System (AFS) uses a client application program to cache file system objects on a workstation. With only an AFS server policy enforcer, file system objects cached on a workstation are not protected. In that case, a workstation policy enforcer can be combined with an AFS server policy enforcer to provide complete file system resource protection.

The file server policy enforcer is self-monitoring and self-protecting. When it is running, a user or process is not permitted to modify, delete, or access the policy enforcer system files including the binaries, configuration files, log files, and policy files. If the policy enforcer is stopped unexpectedly, it is automatically restarted.

Policy enforcers can be installed on some or all file servers within an enterprise, depending on which file servers contain documents that the organization wants to enforce document access policies or information usage policies, or both, on. A file server policy enforcer affects only the file server where it is installed. Alternatively, the policy engine in a policy enforcer can run on a computer different from the server being managed.

The file server policy enforcer is responsible for controlling access to and use of files stored on (or accessible by or managed by) a file server. It can control access to and use of files on a file server by workstations that are controlled or not controlled by policy enforcers.

A workstation policy enforcer controls end-user usage of documents or information on workstations and application program functions. The policy enforcer is installed on a workstation and controls access to and usage of documents or information, whether those documents or information are stored on the workstation or remotely. The policy enforcer detects (or intercept) document access activity, information usage activity and application program operations for each application running on the workstation. Detection can occur inside an application program or at operating system level. For example, the enforcer may be embedded in the application program or in the operating system.

Usage policies control whether users of that workstation are allowed to perform various actions such as sending, printing, or copying documents. Usage policies can also apply to application data to, for example, control cut-and-paste, drag-and-drop, allow only a particular group of users to modify a particular spreadsheet formula, restrict editing of a macro or script by user, restrict editing to a specific region or portion in a document by user, restrict certain application functions based type of connectivity (such as VPN), restrict a particular type edit to a document based on time, and screen capture functions to control misappropriation of data in a document.

Policy enforcers also collect information about each enforcement event for an activity journal or report. The policy enforcer may be self-monitoring and self-protecting. In a specific implementation, when the policy enforcer is running, no user or process can modify, delete, or access the policy enforcer's system files, including the binaries, configuration files, log files, and policy files.

Policy enforcers can be installed on any number of workstations within an enterprise. Each policy enforcer affects only the workstation where it is installed. Policy enforcers may be embedded into a computing device like PDA (such as a Palm Zire™ or Tungsten™, Dell x50v or x51v, or HP IPAQ) or smart phone (such as a Windows Mobile-based smartphone device). A policy enforcer can also be installed on a terminal server (e.g., Microsoft Windows 2003 Terminal Services or Citrix MetaFrame Server) to control document access and information usage in each client session.

Workstation policy enforcer is responsible for document access and information usage at a point-of-use. It has the ability to control access to and usage of documents or information stored locally on the workstation and remotely on document servers, and the document servers may be controlled by policy enforcers or not controlled by policy enforcers. The workstation policy enforcer can also control usage of information and application program functions at a workstation.

Referring to FIGS. 9 and 10, document server and workstation policy enforcers 901 and 1001 have a similar architecture. An interceptor 906 and 1006 is responsible for intercepting (or detecting) document access and application operations (or actions), collecting information about an intercepted operation (e.g., type of action, document or documents associated with the action, and information about the application or module where interception occurred), and forwarding the data collected to a policy engine 902 and 1002 to perform policy evaluation. The consequence of policy evaluation is returned by a policy engine to a consequence applicator 907 and 1007. A consequence applicator is responsible for applying consequence of policy evaluation which includes policy effect and additional tasks.

FIG. 9 illustrates a design where an interceptor and a consequence applicator are components of a policy enforcement point (PEP) module 904 and a policy enforcer includes of at least one PEP 904 and one policy engine 902.

FIG. 10 illustrates a policy enforcer 1001 that implements interception and enforcement functions using PEP plug-in architecture. The policy enforcer includes one PEP 1004 and at least one PEP plug-in module 1005. Both interceptor 1006 and consequence applicator 1007 are components of a PEP plug-in module 1005.

A policy engine may run in a process separate from a policy enforcer. The policy decision process and policy enforcer can run on the same computer or on separate computers.

The interceptor and consequence applicators are functional entities where implementation of the two functions varies from operating system to operating system and application to application. In some cases, the interceptor and consequence applicator functionalities are combined into one code module. In other cases, the interceptor and consequence applicator reside in separate code modules.

To carry out interception and consequence application functions, the interceptors and consequence applicators may function at application program level or operating system level. Application program level interceptors and consequence applicators are application program specific code modules which can be implemented as add-ins, plug-ins, scripts, macros, libraries, or extension programs. Operating system level interceptors and consequence applicators are operating system specific code modules that can be implemented as libraries, filters, or device drivers.

To control application usage, a policy enforcer effects control on application program operations (e.g., blocking an application program operation) or filters results generated by the application program operations (e.g., remove text or disable actionable object in the result), or a combination of these. Normally options such as printing, cut and paste, e-mailing, editing are permitted by a certain application on all documents. However, using the control application usage aspect of the invention, some options may be disabled. For example, controlling application usage may include disabling one or more of an application's operation such as print, cut and paste, e-mail, editing, save as, save to, send to, search and replace, executing a macro or program (e.g., Visual Basic for Applications or VBA program), track changes, show or reveal edits or comments, or other application operations for certain documents. In effect, the policy enforcer will control what operations are permitted or not permitted by applications on particular information for documents, users, or other factors as discussed in this patent application. The policy enforcer may disable usage of some applications altogether. For example, some users may not be allowed to use instant messenger, to play certain program (e.g., games) during certain hours, and so forth.

An application may be any application or program (including built-in functionality of an operating system or BIOS) such as a word processor or application suite (e.g., Microsoft Office, Microsoft Word, OpenOffice, Visio), e-mail program (e.g., Microsoft Outlook or Eurdora), personal information management program (e.g., Microsoft Outlook, Lotus Organizer) Web browser (e.g., Internet Explorer, Firefox, Opera, Safari), RSS reader, instant messenger (e.g., Yahoo! Messenger, AOL Instant Messenger, Windows Live Messenger, Gaim), voice chat (e.g., Skype, Google Talk), web conferencing, text messaging program, media or music player such as an MP3 or video player (e.g., Windows Media player, Winamp, Musicmatch Jukebox, iTunes, RealPlayer, QuickTime, WinDVD, CyberDVD), print programs (Adobe Acrobat, CutePDF), operating system print screen or print to file, archiving program (e.g., Winzip, 7-zip, Winrar), picture viewer (e.g., ACDSee), utilities (e.g., Norton Systemworks, Norton Ghost, AVG Antivirus, Diskeeper defragmentation, OCR program, Adobe Photoshop, GIMP, FTP, PartitionMagic, Nero CD Burning software), financial program (e.g., Quicken, TurboTax, Peachtree), database (Microsoft Access, Oracle), and many more. The program or program may be a commercially available program, shareware, abandonware, or open source software. The application may run under any operating system.

Using interceptors and consequence applicators, an application program operation is intercepted (or detected) and information about the application program operation is provided to a policy engine to make a policy decision, and if the policy decision specifies an enforcement action, the enforcement action is carried out effecting control on the application program operation or filtering of results generated by the application program operation.

A policy enforcer may use one or more methods to implement application usage control. The methods include: (a) blocking or altering an application program operating after it is invoked directly or indirectly by a user but before the application program operation is carried out; (b) disabling or hiding a user interface element responsible for invoking an application program operation so that a user cannot invoke the application program operation through the user interface element; and (c) removing, altering or obscuring a part or all of the result generated by an application program operation making certain information not available to a user. Note that the user interface element described in (b) may be an element of an application program (e.g., a menu item or a button) or an element of the result generated by an application program operation (e.g., a hypertext link, a check box, or a list box).

In a graphical user interface environment, an application program operation may correspond to an operation associated with a user interface element. If a user interface element is a menu item, a corresponding application program operation is an operation that will be carried out when the menu item is selected (e.g., printing a document). If a user interface element is a hypertext link (such as a clickable word or phrase on a Web page), a corresponding application program operation is an operation that will be carried out when the hypertext link is clicked (e.g., loading a new Web page or jumping to another position on a Web page). Other common user interface elements include a: menu, button, list box, list item, check box, scroll bar, key (on the keyboard), and mouse button. An application program operation may also correspond to a command or function that is invoked by a user indirectly (e.g., through a macro or script) or by another application program.

To filter results generated by an application program operation, a consequence applicator may alter, substitute, remove, hide or obscure one or more portions (or all) of the result to be presented to a user. The consequence applicator may also alter, substitute, remove, hide, disable or obscure one or more actionable objects or fragments of text (e.g., menu, tab, buttons, check boxes, list boxes, or hypertext links).

To control document access, a policy enforcer effects control on document access operations. Common document access operations include: read (or open), write (or save), execute (for binary file or script), delete, read permission (or security setting), and change permission. Many document repositories (especially document management systems) support additional document access operations.

Typically, interceptors and consequence applicators intercept (or detect) a document access operation and information about the document access operation is provided to a policy engine to make a policy decision, and if the policy decision specifies an enforcement action, the enforcement action is carried out effecting control on the document access operation. Alternatively, the interceptors and consequence applicators may also integrate with an existing access control system provided by a document repository (e.g., document management system).

Interceptors and consequence applicators that control document access are document repository dependent. They may be installed in a document server application program (e.g., HTTP server, IBM Lotus Notes Server, Microsoft Exchange Server, or Microsoft Sharepoint Portal Server), at an application program interface (e.g., MAPI, JMS, ODBC, JDBC, and Oracle SQL*NET), at an application protocol interface, or act as a application protocol proxy between a client and a server (e.g., HTTP, FTP, or SOAP), at file system libraries, at network file share protocol driver (e.g., CIFS or NFS), or at file system device driver.

Some common document repositories include: file servers, mail servers, document management server, content management server, HTTP or Web servers, FTP servers, WebDAV servers, and database servers.

In one implementation of a policy enforcer, interceptors and consequence applications are installed in an existing application program or operating system to implement interception (or detection) and enforcement functions. The interceptors and consequence applicators are not native elements of the application program or operating system.

In another implementation of a policy enforcer, interceptors and consequence applicators are native elements of an application program or operating system. Interception and enforcement may be implemented through one or more calls to a policy enforcer application program interface (API). For example, a policy enforcer API is provided in the form of a software development kit (SDK).

A workstation policy enforcer installs a number of application program interceptors 906 and 1006 and consequence applicators 907 and 1007 to monitor document access and information usage operations (or action) inside individual application programs and apply enforcement actions. In addition, a workstation policy enforcer also installs operating system interceptors and consequence applicators to monitor file access from application programs and apply enforcement actions. The operating system interceptors can intercept operations from application programs that are monitored by application program interceptors or not monitored by application program interceptors on the workstation.

Interceptors and consequence applicators can be setup during program installation time or any time in a program's life cycle. One method that can be used to set up an interceptor is to perform code analysis on an application program or library module and then modify the stored program code. Another method that can be used to set up an interceptor is through code injection at program start-up time. Yet another method that can be used to set up an interceptor is to perform code injection after the program has been started. Code injection includes any method that modifies exiting program code or inserts new code to existing program code to implement an additional function, or a combination of these two. The existing program code can reside in volatile or nonvolatile memory.

The consequence applicator implements the consequence or outcome produced by the policy engine. The consequence typically includes an effect of policy evaluation and optionally obligation and remediation tasks (described below) to be carried out. Examples of an effect include whether an operation should be allowed or denied; query a user for input; evaluate another set (or sets) of policies; and call a custom effect handler (described below).

The local policy repository holds a copy of policies applicable to a policy enforcer. Depending on the policy system architecture selected, the set of policies in the local policy repository may be a full set of a set of policies on the policy server or a subset. The local policy may be stored locally in a relational database, in one or more files, or in any form that convenient to the policy enforcer. By storing policies for a policy enforcer locally, a workstation policy enforcer can continue to function while a workstation is off-line and the policy server cannot be reached.

The custom effect handler, 908 and 1008, is a code module that implements custom effects and is optional in the policy enforcer.

An obligation handler, 909 and 1009, is a code module that carries out obligations supported by the policy system architecture. An obligation is a task that is related to the intercepted action that a policy enforcer is obligated to take. The tasks may include logging an action being intercepted, sending a notification to an administrator regarding the intercepted action, and archiving or encrypting the document associated with the intercepted action.

For example, a policy says “any e-mail sent to a patient should be maintained in the patient record database; and the obligation action is to send (or “bcc”) a copy of the e-mail to the record management system.” In this case, a policy enforcer will automatically apply the obligation action (i.e., archive) and send a copy of an e-mail to a record management system.

In a second example, obligation can be used to implement regulatory compliance requirements such as “all e-mail communications from an executive should be archived.” A policy can be written to capture all send and forward actions on e-mail and apply an archive obligation action automatically.

Some obligation handlers, 909 and 1009, are executed inside a policy enforcer process (e.g., the log handler) while others are implemented as policy enforcement point components executing inside an application program (e.g., an e-mail delete handler) or an operating system. The obligation handler is optional in the policy enforcer.

The remediation handler, 910 and 1010, is very similar in function to the obligation handler except it performs different functions. Remediation means additional actions taken that are different from what is being intercepted. Such actions are introduced solely by policies defined to “remediate.”

The tamper resistance module, 914 and 1014, is responsible for preventing, blocking, monitoring, and recovering from attempts to disable or alter the function of a policy enforcer. Many techniques can be used to protect program files and configurations from modifications and corruption. Some examples are: (1) Multiple copies of files can be maintained and a missing or corrupted file can be restored from the backup copies. (2) Checksums or signatures can be generated on important files and stored in nonvolatile memory to enable detection of corrupted program and data files. (3) Access to policy enforcer program files and configurations can be restricted. (4) Changes to a policy enforcer's Windows registry entries can also be monitored, blocked, and automatically restored.

The communication and synchronization module, 913 and 1013, is responsible for maintaining one or more connection to the policy server and intelligence server, handling policy updates, and transferring log data to the log and intelligence repository.

The policy scheduler, 912 and 1012, invokes maintenance policies set by the administrator or user. A maintenance policy tells the policy scheduler when to perform an action and what the action is. For example, the policy scheduler can be given a maintenance policy that instructs it to perform a nightly scan of all e-mails and to delete any e-mails older than 90 days.

A maintenance policy uses the same format as a normal policy, but rather than being evaluated in response to an action by a user or application program, the maintenance policy is evaluated at a certain specified date, time, or both. The policy engine performs any specified obligation or remediation action specified in the maintenance policy.

A policy engine, 703, 902, and 1002, is an execution unit that processes and executes rules or policies. The policy engine takes the data collected by an interceptor, historical data from prior interceptions, configuration and environment data, and applies the policy rules supplied by the policy server to the data to produce a consequence. A consequence may include an effect (e.g., ALLOW, DENY, evaluate another policy, query user, or call a custom effect handler) and optionally one or more obligation and remediation tasks. The use of historical data in policy evaluation is optional. As part of policy evaluation process, a policy engine may decide that it needs to obtain input form a user before it can proceed with (or complete) policy evaluation. At that time, a policy engine can invoke user interface elements to query the user for input. For example, such input is related to classifying a document (which produces document attribute values) that is required to complete policy evaluation.

Also, as part of the policy evaluation process, a policy engine may decide that it needs to obtain document classification information in order to complete policy evaluation. The process of obtaining document classification information may involve retrieving stored document classification data or dynamically invoking a document classification engine to classify a document.

The policy engine optionally performs a list of obligation and remediation tasks or invokes a custom effect handler, or a combination of these, if one is defined in a policy. An implementation of the policy engine is policy system architecture specific. Depending on what policy system architecture is selected, the implementation of the policy engine can vary significantly. Some examples include distributing full sets of policies to policy enforcers, organizing policies based on the type of policy enforcer the policies target, using policies defined in XACML format, or using policies defined in Blue Jungle's Compliant Enterprise Active Control Policy Language (ACPL) format that uses a declarative approach to policy specification. More detailed information about the ACPL language may be found in U.S. provisional application 60/870,195, filed Dec. 15, 2006, which is incorporated by reference.

The ACPL language is merely one example of a policy language of the invention and is provided to help one more easily understand the invention. There are many variations to a policy language according to the invention and such a policy language is not limited to what is described for the ACPL language. The invention includes features that are not in the ACPL language implementation presented. A policy language of the invention may include one or more features of the ACPL language. A policy language of the invention features that are not in the ACPL language. A policy language of the invention may include one or more features of the ACPL language in combination with features that are not in the ACPL language.

The policy deployment module 705 in this invention can support different types of policy engine design, allowing the appropriate policy engine design to be selected for an individual device. For example, a smart phone policy enforcer may be limited by the device's computing power and memory available. A policy engine inside the smart phone policy enforcer may be designed to execute precompiled and preoptimized polices that exist in binary form. The policy optimization and compilation steps are performed on the policy server before transmitting (the subset of policies) to the smart phone policy enforcer. In this case, the smart phone policy enforcer receives and evaluates policies exists in binary form which is a semantic equivalent of the original policies resided on the policy server.

A number of design options are available to the design of policy engine 703, the options include: (1) Support distribution of full sets of policies to policy enforcers. (2) Support preoptimized policies at the policy enforcer. (3) Support policies transmitted to a policy enforcer in XACML format. (4) Support policies transmitted to a policy enforcer in Blue Jungle's ACPL format. (5) Support policies compiled into ASCII or binary format. (6) Support policies translated into programming language (e.g., XML, Java, C#, Perl, and Python in source code or binary format). (7) Support policies translated into lookup tables. (8) Support preinstalled, configurable policies and alter preinstalled polices' behavior through configuration changes. (9) Support built-in, configurable policies and alter built-in policies' behavior through configuration changes.

In an implementation of a policy engine, a policy evaluation process can be invoked by an interceptor 906 and 1006, a policy scheduler 912 and 1012, an internal event generated by a policy enforcer or policy server, or an external event generated by another application program.

An internal event is similar to an intercepted user or application program action except that it is generated by a policy engine or other components of a policy enforcement system. An internal event can provide additional information relevant to the event similar to that of intercepted action. In fact, an internal event often includes the information provided by an intercepted action which results in the generation of the internal event. An internal event may be generated as a result of a policy evaluation request or a result of an activity data analysis operation.

An external event is an event generated by another application program outside of a policy enforcement system. This type of application program is typically a third party application integrated with a policy enforcement system (e.g., through a software development kit). Third-party application integration can be extremely useful because in a specific implementation where policy enforcers are deployed company-wide, managing all types of information, the management system has access to information in a distributed environment without having to go through additional authentication and authorization processes. For example, a customer relationship management (CRM) application may instruct a policy enforcement system through an external event to archive all documents related to a customer on the closing of an account. The handling of such an external event may include rolling up: files on file servers and desktop and laptop computers, e-mail messages on mail servers and all mail clients, and documents in document management systems.

The Blue Jungle ACPL is one example of a specific implementation of the invention. However, the present invention has many aspects and an implementation of the invention may have any number of the features discussed in this patent, and not necessarily every feature described.

The policy engine can evaluate policies received from the policy server using the following steps:

(1) Receive data collected by an interceptor or provided by an integrated application program module. The data collected by an interceptor may include an action (or operation) being intercepted, information on the document or documents that are associated with the action, information on the thread, process and application within which the action was taken, and other information which may be useful in policy evaluation. Actions such as cut-and-paste that do not necessarily involve a document may also be intercepted.

(2) Inspect data provided by the interceptor or the integrated application program module and select policies that are applicable. The selection may be based on type of action, who is the user, what is the application, and so on. In some policy system architectures, this policy selection step may not be necessary. In that case, all policies will be evaluated.

(3) Based on the policies selected and data provided by an interceptor or the integrated application program module, obtain additional information that is used to complete policy evaluation. The additional information may include configuration setting and environment data.

(4) Pass the selected policies and data collected through policy evaluation logic to produce a consequence (or outcome). The consequence includes one of the valid policy effects (e.g., ALLOW, DENY, evaluate another set (or sets) of policies, query user and call a custom effect handler), and perform any obligation and remediation tasks.

(5) If the policy evaluation consequence includes any obligation or remediation tasks, call the corresponding obligation or remediation handlers to carry out the obligation tasks, remediation tasks, or both.

(6) If the policy evaluation consequence includes a custom effect, call the corresponding custom effect handler to generate or apply an effect.

The policy engine can reside in a policy enforcer, a policy server, a dedicated policy decision server, or any process or server that is assigned the policy decision function. Note that the policy engine may be an optional module in the policy enforcer.

In an embodiment of the invention, the policy engine can evaluate policies received from the policy server, data provided by a scheduler associated with a scheduled event, data associated with an internal event generated by a policy enforcer or a policy server, or data accompanying an external event generated by a different application program.

In another embodiment of the invention, the policy engine detects the current location of a device (e.g., a laptop computer) and evaluates a selected subset of policies received from the policy server according to the current location. To determine the current location of a device, a policy engine may examine an active connection to the device, wherein examining an active connection includes examining an IP address allocated to the device, or IP address or host name of an access point where the device connects to. In an example where a company has two offices, one in New York and another in Boston. If an access point in New York office has a host name “AP-NY” and an access point in the Boston office has a host name “AP-B.” When a user connects a laptop computer to the network in the Boston office, the policy engine on the laptop computer determines the host name of an access point as “AP-B” whereby evaluating only policies applicable to location “AP-B.”

The policy language syntax used in the following examples is based at least partially on the ACPL language syntax. The ACPL language syntax is described in U.S. provisional application 60/870,195, filed Dec. 15, 2006, and is also described in this application in FIGS. 25-50 and their accompanying description.

In one implementation, a policy directive is used to label the locations where a policy is applicable. In such implementation, policies that are not labeled are applicable to all locations. A location label may refer to one or more locations. A location label may comprise of one or more constants or an expression.



	# Policy 1
	[location.access-point =“AP-NY”] FOR
	document.name=“\server1\legal\hi ghly-confidential\*”
	ON OPEN
	BY user=Legal
	DO (ALLOW AND LOG) OTHERS DENY
	# Policy 2
	[location.access-point=“AP-B”] FOR
	document.name=“\server1\legal\hi ghly-confidential\*”
	ON OPEN
	BY user=Legal
	DO DENY

The policies in the above example are prefixed with location labels. In this case, a location label comprises an expression (e.g., location.access-point=“AP-B”). During policy evaluation, a policy engine evaluates the location labels of “policy 1” and “policy 2” to determine if “policy 1” or “policy 2” is relevant. Further, there may be a catch all policy that is applied when the value of “location.access-point” does not match any other policy having a location label specifying “location.access-point” as a matching criterion. For example, a catch all label may be “[location.access-point=DEFAULT].”

In another implementation, policies are grouped into policy sets and a policy set directive is used to label the locations where a policy set is applicable. A policy set may be named or unnamed. A policy set comprises at least one policy. A policy set may also include another policy set.



	[location.access-point = “AP-NY”] PolicySet “NY-Office-Policies”
	{
	# Policy 3
	FOR document.name=“\server1\legal\highly-confidential\*”
	ON OPEN
	BY user=Legal
	DO (ALLOW AND LOG) OTHERS DENY
	# Policy 4
	FOR document.name=“.xls” OR document.name=“.pdf”
	ON PRINT
	BY user=Finance
	DO DENY
	}

The two policies “policy 3” and “policy 4” in the above example are grouped into a named policy set “NY-Office-Policies.” The policy set is tagged (or prefixed) with a location label [location.access-point=“AP-NY”] making the policies in the policy set applicable only when the label is evaluated to Boolean true.

In yet another implementation, a policy may comprise multiple expressions (or subexpressions) each assigned a different location label. Evaluating such policy includes selecting an expression (or subexpression) associates with the location detected by a policy engine.



	FOR document.name=“\server1\legal\highly-confidential\*”
	ON OPEN
	BY user=legal
	WHERE {
	SWITCH (location.access-point)
	CASE “AP-NY”
	connection.type = “LAN” OR (connection.type = “WLAN”
	AND connection.security = “VPN”)
	DEFAULT
	connection.security = “VPN”
	}
	DO ALLOW OTHERS DENY

In the above example, two expressions (i.e., ‘connection.type=“LAN” OR (connection.type=“WLAN” AND connection.security=“VPN”)’ and ‘connection.security=“VPN”’) are specified in the context component (i.e., the WHERE clause) of a policy. Each of the expressions is assigned a location label where the specific expression associates with a specific label will be evaluated when the value of “location.access-point” matches the specific label.

In another embodiment of the invention, the policy engine evaluates policies received from the policy server, detects the current location of a device and applies policy consequence based on the current location detected. In such implementation, a policy may comprise multiple consequence expressions (or subexpressions) each assigned a different location label.



	FOR document.name=“\server1\legal\highly-confidential\*”
	ON OPEN
	BY user=Legal
	DO {
	SWITCH (location.access-point)
	CASE “AP-NY”
	DO (ALLOW AND LOG)
	CASE “AP-B”
	DO DENY
	DEFAULT
	DO DENY
	} OTHERS DENY

In the above example, multiple consequence subexpressions are specified in a policy where each consequence subexpression is identified by a location label (e.g., “AP-NY” or “AP-B”). The location labels are compared with the value of “location.access-point” during policy evaluation to determine which consequence subexpression (e.g., “DO ALLOW AND LOG” or “DO DENY”) will be applied.

For the purpose of illustration, the following examples show the evaluation of only one policy in the policy evaluation step (by a policy engine). In practice, a policy engine can select one or more policies relevant to an intercepted action or the integrated application program module and the policy evaluation may involve more than one policy. When more than one policy is evaluated by a policy engine in response to an intercepted action or the integrated application program module, policy consequences in the evaluated policies should be combined to form one final policy consequence using one or more combining algorithms (e.g., deny override or permit override). The final policy consequence is then returned to an interceptor and consequence applicator (or an authorization process that invokes policy evaluation). This final policy consequence typically contains a policy effect and optionally one or more obligation tasks or remediation tasks.

FIG. 11 shows an example embodiment of a policy enforcer 1115 is installed on a workstation 1101 where a user's (or application's) OPEN action triggers a file operation (e.g., open( )) on a local disk file. Note that file system objects are handled differently from other documents that are nonfile system objects. The policy definition is:



	FOR document.name = “*.doc”
	ON OPEN
	BY user = NOT Employees
	DO DENY