Patent Publication Number: US-10326748-B1

Title: Systems and methods for event-based authentication

Description:
BACKGROUND 
     Technical Field 
     The present disclosure relates generally to data security and more particularly, but not by way of limitation, to systems and methods for event-based authentication. 
     History of Related Art 
     It is often desirable to protect network resources with rigorous security while also allowing for easy access by users. However, these two ideals are typically in conflict. For example, improved security for a network resource often results in difficult-to-remember passwords and extra steps to log-in. 
     Moreover, as the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems. 
     SUMMARY OF THE INVENTION 
     In one embodiment, a method is performed by a computer system. The method includes receiving a request to authenticate a user of an enterprise computing system. The method further includes, responsive to the request, selecting a set of previous user-initiated events of the user on the enterprise computing platform. Further, the method includes accessing user-specific event information related to the selected set of previous user-initiated events. In addition, the method includes generating, from at least a portion of the user-specific event information, a user-specific authentication sequence comprising a plurality of event-information requests. Additionally, the method includes administering the user-specific authentication sequence to the user, the administering comprising requiring the user to provide a valid response to each of the event-information requests as a precondition to successful authentication. 
     In one embodiment, an information handling system includes at least one processor, wherein the at least one processor is operable to implement a method. The method includes receiving a request to authenticate a user of an enterprise computing system. The method further includes, responsive to the request, selecting a set of previous user-initiated events of the user on the enterprise computing platform. Further, the method includes accessing user-specific event information related to the selected set of previous user-initiated events. In addition, the method includes generating, from at least a portion of the user-specific event information, a user-specific authentication sequence comprising a plurality of event-information requests. Additionally, the method includes administering the user-specific authentication sequence to the user, the administering comprising requiring the user to provide a valid response to each of the event-information requests as a precondition to successful authentication. 
     In one embodiment, a computer-program product includes a non-transitory computer-usable medium having computer-readable program code embodied therein. The computer-readable program code is adapted to be executed to implement a method. The method includes receiving a request to authenticate a user of an enterprise computing system. The method further includes, responsive to the request, selecting a set of previous user-initiated events of the user on the enterprise computing platform. Further, the method includes accessing user-specific event information related to the selected set of previous user-initiated events. In addition, the method includes generating, from at least a portion of the user-specific event information, a user-specific authentication sequence comprising a plurality of event-information requests. Additionally, the method includes administering the user-specific authentication sequence to the user, the administering comprising requiring the user to provide a valid response to each of the event-information requests as a precondition to successful authentication. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A more complete understanding of the method and apparatus of the present invention may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein: 
         FIG. 1  illustrates an embodiment of a networked computing environment. 
         FIG. 2  illustrates an embodiment of a Business Insight on Messaging (BIM) system. 
         FIG. 3  presents a flowchart of an example of a data collection process. 
         FIG. 4  presents a flowchart of an example of a data classification process. 
         FIG. 5  presents a flowchart of an example of a data query process. 
         FIG. 6  illustrates an example of a heuristics engine. 
         FIG. 7  presents a flowchart of an example of a heuristics process. 
         FIG. 8  presents a flowchart of an example of a data query process. 
         FIG. 9  illustrates an example of a user interface. 
         FIG. 10  illustrates an example of a user interface. 
         FIG. 11  illustrates an embodiment of an implementation of a system for performing data loss prevention (DLP). 
         FIG. 12  illustrates an embodiment of an implementation of a cross-platform DLP system. 
         FIG. 13  illustrates an example of a process for cross-platform DLP implementation. 
         FIG. 14  illustrates an example of a process for creating a cross-platform DLP policy. 
         FIG. 15  illustrates an example of a process for dynamically acquiring context information. 
         FIG. 16  illustrates an example of a process for publishing violation information. 
         FIG. 17  illustrates an example of an access profile. 
         FIG. 18  illustrates an embodiment of a system for user-context-based analysis of communications. 
         FIG. 19  presents a flowchart of an example of a process for performing user-context-based analysis of communication events. 
         FIG. 20  presents a flowchart of an example of a process for performing dynamic DLP via a real-time user-context-based analysis. 
         FIG. 21  presents a flowchart of an example of a process for configuring a dynamic DLP policy and/or a user context responsive to user input. 
         FIG. 22  illustrates an example of a system for performing dynamic event-based authentication. 
         FIG. 23  illustrates an example of a process for dynamic event-based authentication. 
     
    
    
     DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS OF THE INVENTION 
     This disclosure describes several non-limiting examples of processes for collecting information or data from multiple sources and analyzing the information to classify the data and to extract or determine additional information based on the collected data. The data sources can be internal to the business and/or external to the business. For example, the data sources can include sales databases, business or internal email systems, non-business or external email systems, social networking accounts, inventory databases, file directories, enterprise systems, customer relationship management (CRM) systems, organizational directories, collaboration systems (e.g., SharePoint™ servers), etc. 
     As used herein, the term “business,” in addition to having its ordinary meaning, is intended to include any type of organization or entity. For example, a business can include a charitable organization, a governmental organization, an educational institution, or any other entity that may have one or more sources of data to analyze. Further, the user of any of the above terms may be used interchangeably unless explicitly used otherwise or unless the context makes clear otherwise. In addition, as used herein, the term “data” generally refers to electronic data or any type of data that can be accessed by a computing system. 
     I. Systems and Methods for Collecting, Classifying, and Querying Data 
     Example of a Networked Computing Environment 
       FIG. 1  illustrates an embodiment of a networked computing environment  100 . The networked computing environment  100  can include a computing environment  102  that is associated with a business or organization. The computing environment  102  may vary based on the type of organization or business. However, generally, the computing environment  102  may include at least a number of computing systems. For example, the computing environment may include clients, servers, databases, mobile computing devices (e.g., tablets, laptops, smartphones, etc.), virtual computing devices, shared computing devices, networked computing devices, and the like. Further, the computing environment  102  may include one or more networks, such as intranet  104 . 
     The computing environment  102  includes a Business Insights on Messaging (BIM) system  130 . Using the BIM system  130 , a user can examine the data available to a business regardless of where the data was generated or is stored. Further, in some embodiments, the user can use the BIM system  130  to identify trends and/or metadata associated with the data available to the BIM system  130 . In certain embodiments, the BIM system  130  can access the data from internal data sources  120 , external data sources  122 , or a combination of the two. The data that can be accessed from the internal data sources  120  can include any data that is stored within the computing environment  102  or is accessed by a computing system that is associated with the computing environment  102 . For example, the data may include information stored in employee created files, log files, archived files, internal emails, outgoing emails, received emails, received files, data downloaded from an external network or the Internet, not-yet-transmitted emails in a drafts folder, etc. The type of data is not limited and may depend on the organization or business associated with the computing environment  102 . For example, the data can include sales numbers, contact information, vendor costs, product designs, meeting minutes, the identity of file creators, the identity of file owners, the identity of users who have accessed a file or are authorized to access a file, etc. 
     The data that can be accessed from the external data sources  122  can include any data that is stored outside of the computing environment  102  and is publicly accessible or otherwise accessible to the BIM system  130 . For example, the data can include data from social networking sites, customer sites, Internet sites, or any other data source that is publicly accessible or which the BIM system  130  has been granted access. In some cases, a subset of the data may be unavailable to the BIM system  130 . For example, portions of the computing environment  102  may be configured for private use. 
     The internal data sources  120  can include any type of computing system that is part of or associated with the computing environment  102  and is available to the BIM system  130 . These computing systems can include database systems or repositories, servers (e.g., authentication servers, file servers, email servers, collaboration servers), clients, mobile computing systems (including e.g., tablets, laptops, smartphones, etc.), virtual machines, CRM systems, directory services, such as lightweight directory access protocol (LDAP) systems, and the like. Further, in some cases, the internal data sources  120  can include the clients  114  and  116 . The external data sources  122  can include any type of computing system that is not associated with the computing environment  102 , but is accessible to the BIM system  130 . For example, the external data sources  122  can include any computing systems associated with cloud services, social media services, hosted applications, etc. 
     The BIM system  130  can communicate with the internal data sources  120  via the intranet  104 . The intranet  104  can include any type of wired and/or wireless network that enables computing systems associated with the computing environment  102  to communicate with each other. For example, the intranet  104  can include any type of a LAN, a WAN, an Ethernet network, a wireless network, a cellular network, a virtual private network (VPN) and an ad hoc network. In some embodiments, the intranet  104  may include an extranet that is accessible by customers or other users who are external to the business or organization associated with the computing environment  102 . 
     The BIM system  130  can communicate with the external data sources  122  via the network  106 . The network  106  can include any type of wired, wireless, or cellular network that enables one or more computing systems associated with the computing environment  102  to communicate with the external data sources  122  and/or any computing system that is not associated with the computing environment  102 . In some cases, the network  106  can include the Internet. 
     A user can access the BIM system  130  using any computing system that can communicate with the BIM system  130 . For example, the user can access the BIM system  130  using the client  114 , which can communicate with the BIM system  130  via the intranet  104 , the client  116 , which can communicate via a direct communication connection with the BIM system  130 , or the client  118 , which can communicate with the BIM system  130  via the network  106 . As illustrated in  FIG. 1 , in some embodiments the client  118  may not be associated with the computing environment  102 . In such embodiments, the client  118  and/or a user associated with the client  118  may be granted access to the BIM system  130 . The clients  114 ,  116 , and  118  may include any type of computing system including, for example, a laptop, desktop, smartphone, tablet, or the like. In some embodiments, the BIM system  130  may determine whether the user is authorized to access the BIM system  130  as described in further detail below. 
     The BIM system  130  can include a data collection system  132 , a data classification system  134 , and a BIM access system  136 . The data collection system  132  can collect data or information from one or more data sources for processing by the BIM system  130 . In some embodiments, the data collection system  132  can reformat the collected data to facilitate processing by the BIM system  130 . Further, in some cases, the data collection system  132  may reformat collected data into a consistent or defined format that enables the comparison or processing of data that is of the same or a similar type, but which may be formatted differently because, for example, the data is obtained from different sources. The data collection system  132  is described in more detail below with reference to  FIG. 2 . 
     The data classification system  134  can store and classify the data obtained by the data collection system  132 . In addition to predefined classifications, the data classification system  134  can identify and develop new classifications and associations between data using, for example, heuristics and probabilistic algorithms. The data classification system  134  is described in more detail below with reference to  FIG. 3 . 
     The BIM access system  136  can provide users with access to the BIM system  130 . In some embodiments, the BIM access system  136  determines whether a user is authorized to access the BIM system  130 . The BIM access system  136  enables a user to query one or more databases (not shown) of the data classification system  134  to obtain access to the data collected by the data collection system  132 . Further, the BIM access system  136  enables a user to mine the data and/or to extract metadata by, for example, creating queries based on the data and the data classifications. Advantageously, in certain embodiments, because the data classification system  134  can classify data obtained from a number of data sources, more complex queries can be created compared to a system that can only query its own database or a single data source. 
     Additionally, in certain embodiments, the BIM access system  136  can enable users to create, share, and access query packages. As described in greater detail below, a query package can encapsulate one or more pre-defined queries, one or more visualizations of queried data, and other package attributes. When a user selects a query package, the query package can be executed in a determined manner in similar fashion to other queries. As an additional advantage, in some embodiments, because the data classification system  134  can use heuristics and probabilistic algorithms to develop and modify data classifications over time, user queries are not limited to a set of predefined search variables. The BIM access system  136  is described in more detail below with reference to  FIG. 3 . 
     Example Implementation of a BIM System 
       FIG. 2  illustrates an embodiment of an implementation of the BIM system  130 . As previously described above, the BIM system  130  can include a data collection system  132  configured to, among other things, collect data from the internal data sources  120  and/or the external data sources  122 . The data collection system  132  can include a collection engine  202 , an access manager  204 , a business logic engine  206 , and a business logic security manager  208 . 
     Generally, the collection engine  202  may access the internal data sources  120  thereby providing the BIM system  130  with access to data that is stored by or generated by the internal data sources  120 . This data can include any data that may be created, accessed, or received by a user or in response to the actions of a user who is associated with the computing environment  102 . Further, in some embodiments, the collection engine  202  can access the external data sources  122  thereby providing the BIM system  130  with access to data from the external data sources  122 . In some embodiments, the data can include metadata. For example, supposing that the collection engine  202  accesses a file server, the data can include metadata associated with the files stored on the file server, such as the file name, file author, file owner, time created, last time edited, etc. 
     In some cases, a number of internal data sources  120  and/or external data sources  122  may require a user or system to be identified and/or authenticated before access to the data source is granted. Authentication may be required for a number of reasons. For example, the data source may provide individual accounts to users, such as a social networking account, email account, or collaboration system account. As another example, the data source may provide different features based on the authorization level of a user. For example, a billing system may be configured to allow all employees of an organization to view invoices, but to only allow employees of the accounting department to modify invoices. 
     For data sources that require authentication or identification of a specific user, the access manager  204  can facilitate access to the data sources. The access manager  204  can manage and control credentials for accessing the data sources. For example, the access manager  204  can store and manage user names, passwords, account identifiers, certificates, tokens, and any other information that can be used to access accounts associated with one or more internal data sources  120  and/or external data sources  122 . For instance, the access manager  204  may have access to credentials associated with a business&#39;s Facebook™ or Twitter™ account. As another example, the access manager may have access to credentials associated with an LDAP directory, a file management system, or employee work email accounts. 
     In some embodiments, the access manager  204  may have credentials or authentication information associated with a master or super user account enabling access to some or all of the user accounts without requiring credentials or authentication information associated with each of the users. In some cases, the collection engine  202  can use the access manager  204  to facilitate accessing internal data sources  120  and/or external data sources  122 . 
     The business logic engine  206  can include any system that can modify or transform the data collected by the collection engine  202  into a standardized format. In some embodiments, the standardized format may differ based on the data source accessed and/or the type of data accessed. For example, the business logic engine  206  may format data associated with emails, data associated with files stored at the computing environment  102 , data associated with web pages, and data associated with research files differently. However, each type of data may be formatted consistently. Thus, for example, data associated with product design files may be transformed or abstracted into a common format regardless of whether the product design files are of the same type. As a second example, suppose that the business logic engine  206  is configured to record time using a 24-hour clock format. In this second example, if one email application records the time an email was sent using a 24-hour clock format, and a second email application uses a 12-hour clock format, the business logic engine  206  may reformat the data from the second email application to use a 24-hour clock format 
     In some embodiments, a user may define the format for processing and storing different types of data. In other embodiments, the business logic engine  206  may identify a standard format to use for each type of data based on, for example, the format that is most common among similar types of data sources, the format that reduces the size of the information, or any other basis that can be used to decide a data format. 
     The business logic security manager  208  can include any system that can implement security and data access policies for data accessed by the collection engine  202 . In some embodiments, the business logic security manager  208  may apply the security and data access policies to data before the data is collected as part of a determination of whether to collect particular data. For example, an organization may designate a private folder or directory for each employee and the data access policies may include a policy to not access any files or data stored in the private directory. Alternatively, or in addition, the business logic security manager  208  may apply the security and data access policies to data after it is collected by the collection engine  202 . Further, in some cases, the business logic security manager  208  may apply the security and data access policies to the abstracted and/or reformatted data produced by the business logic engine  206 . For example, suppose the organization associated with the computing environment  102  has adopted a policy of not collecting emails designated as personal. In this example, the business logic security manager  208  may examine email to determine whether it is addressed to an email address designated as personal (e.g., email addressed to family members) and if the email is identified as personal, the email may be discarded by the data collection system  132  or not processed any further by the BIM system  130 . 
     In some embodiments, the business logic security manager  208  may apply a set of security and data access policies to any data or metadata provided to the classification system  134  for processing and storage. These security and data access policies can include any policy for regulating the storage and access of data obtained or generated by the data collection system  132 . For example, the security and data access policies may identify the users who can access the data provided to the data classification system  134 . The determination of which users can access the data may be based on the type of data. The business logic security manager  208  may tag the data with an identity of the users, or class or role of users (e.g., mid-level managers and more senior) who can access the data. As another example, of a security and data access policy, the business logic security manager  208  may determine how long the data can be stored by the data classification system  134  based on, for example, the type of data or the source of the data. 
     After the data collection system  132  has collected and, in some cases, processed the data obtained from the internal data sources  120  and/or the external data sources  122 , the data may be provided to the data classification system  134  for further processing and storage. The data classification system  134  can include a data repository engine  222 , a task scheduler  224 , an a priori classification engine  226 , an a posteriori classification engine  228 , a heuristics engine  230  and a set of databases  232 . 
     The data repository engine  222  can include any system for storing and indexing the data received from the data collection system  132 . The data repository engine  222  can store the data, including any generated indexes, at the set of databases  232 , which can include one or more databases or repositories for storing data. In some cases, the set of databases  232  can store data in separate databases based on any factor including, for example, the type of data, the source of data, or the security level or authorization class associated with the data and the class of users who can access the data. 
     In some implementations, the set of databases  232  can dynamically expand and, in some cases, the set of databases  232  may be dynamically structured. For example, if the data repository engine  222  receives a new type of data that includes metadata fields not supported by the existing databases of the set of databases  232 , the data repository engine  222  can create and initialize a new database that includes the metadata fields as part of the set of databases  232 . For instance, suppose the organization associated with the computing environment  102  creates its first social media account for the organization to expand its marketing initiatives. Although the databases  232  may have fields for customer information and vendor information, it may not have a field identifying whether a customer or vendor has indicated they “like” or “follow” the organization on its social media page. The data repository engine  222  can create a new field in the databases  232  to store this information and/or create a new database to capture information extracted from the social media account including information that relates to the organization&#39;s customers and vendors. 
     In certain embodiments, the data repository engine  222  can create abstractions of and/or classify the data received from the data collection system  132  using, for example, the task scheduler  224 , the a priori classification engine  226 , the a posteriori classification engine  228 , and the heuristics engine  230 . The task scheduler  224  can include any system that can manage the abstraction and classification of the data received from the data collection system  132 . In some embodiments, the task scheduler  224  can be included as part of the data repository engine  222 . 
     Data that is to be classified and/or abstracted can be supplied to the task scheduler  224 . The task scheduler  224  can supply the data to the a priori classification engine  226 , which can include any system that can classify data based on a set of user-defined, predefined, or predetermined classifications. These classifications may be provided by a user (e.g., an administrator) or may be provided by the developer of the BIM system  130 . Although not limited as such, the predetermined classifications generally include objective classifications that can be determined based on attributes associated with the data. For example, the a priori classification engine  226  can classify communications based on whether the communication is an email, an instant message, or a voice mail. As a second example, files may be classified based on the file type, such as whether the file is a drawing file (e.g., an AutoCAD™ file), a presentation file (e.g., a PowerPoint™ file), a spreadsheet (e.g., an Excel™ file), a word processing file (e.g., a Word™ file), etc. Although not limited as such, the a priori classification engine  226  generally classifies data at or substantially near the time of collection by the collection engine  202 . The a priori classification engine  226  can classify the data prior to the data being stored in the databases  232 . However, in some cases, the data may be stored prior to or simultaneously with the a priori classification engine  226  classifying the data. The data may be classified based on one or more characteristics or pieces of metadata associated with the data. For example, an email may be classified based on the email address, a domain or provider associated with the email (e.g., a Yahoo® email address or a corporate email address), or the recipient of the email. 
     In addition to, or instead of, using the a priori classification engine  226 , the task scheduler  224  can provide the data to the a posteriori classification engine  228  for classification or further classification. The a posteriori classification engine  228  can include any system that can determine trends with respect to the collected data. Although not limited as such, the a posteriori classification engine  228  generally classifies data after the data has been collected and stored at the databases  232 . However, in some cases, the a posteriori classification engine  228  can also be used to classify data as it is collected by the collection engine  202 . Data may be processed and classified or reclassified multiple times by the a posteriori classification engine  228 . In some cases, the classification and reclassification of the data occurs on a continuing basis. In other cases, the classification and reclassification of data occurs during specific time periods of events. For example, data may be reclassified each day at midnight or once a week. As another example, data may be reclassified each time one or more of the a posteriori algorithms is modified or after the collection of new data. 
     In some cases, the a posteriori classification engine  228  classifies data based on one or more probabilistic algorithms. The probabilistic algorithms may be based on any type of statistical analysis of the collected data. For example, the probabilistic algorithms may be based on Bayesian analysis or probabilities. Further, Bayesian inferences may be used to update the probability estimates calculated by the a posteriori classification engine  228 . In some implementations, the a posteriori classification engine  228  may use machine learning techniques to optimize or update the a posteriori algorithms. In some embodiments, some of the a posteriori algorithms may determine the probability that a piece or set of data (e.g., an email) should have a particular classification based on an analysis of the data as a whole. Alternatively, or in addition, some of the a posteriori algorithms may determine the probability that a set of data should have a particular classification based on the combination of probabilistic determinations associated with subsets of the data, parameters, or metadata associated with the data (e.g., classifications associated with the content of the email, the recipient of the email, the sender of the email, etc.). 
     For example, continuing with the email example, one probabilistic algorithm may be based on the combination of the classification or determination of four characteristics associated with the email, which may be used to determine whether to classify the email as a personal email, or non-work related. The first characteristic can include the probability that an email address associated with a participant (e.g., sender, recipient, BCC recipient, etc.) of the email conversation is used by a single employee. This determination may be based on the email address itself (e.g., topic based versus name based email address), the creator of the email address, or any other factor that can be used to determine whether an email address is shared or associated with a particular individual. The second characteristic can include the probability that keywords within the email are not associated with peer-to-peer or work-related communications. For example, terms of endearment and discussion of children and children&#39;s activities are less likely to be included in work-related communications. The third characteristic can include the probability that the email address is associated with a participant domain or public service provider (e.g., Yahoo® email or Google® email) as opposed to a corporate or work email account. The fourth characteristic can include determining the probability that the message or email thread can be classified as conversational as opposed to, for example, formal. For example, a series of quick questions in a thread of emails, the use of a number of slang words, or excessive typographical errors may indicate that an email is likely conversational. The a posteriori classification engine  228  can use the determined probabilities for the above four characteristics to determine the probability that the email communication is personal as opposed to, for example, work-related, or spam email. 
     The combination of probabilities may not total 100%. Further, the combination may itself be a probability and the classification can be based on a threshold determination. For example, the threshold may be set such that an email is classified as personal if there is a 90% probability for three of the four above parameters indicating the email is personal (e.g., email address is used by a single employee, the keywords are not typical of peer-to-peer communication, at least some of the participant domains are from known public service providers, and the message thread is conversational). 
     As another example of the a posteriori classification engine  228  classifying data, the a posteriori classification engine  228  can use a probabilistic algorithm to determine whether a participant of an email is a customer. The a posteriori classification engine  228  can use the participant&#39;s identity (e.g., a customer) to facilitate classifying data that is associated with the participant (e.g., emails, files, etc.). To determine whether the participant should be classified as a customer, the a posteriori classification engine  228  can examiner a number of parameters including a relevant Active Directory Organizational Unit (e.g., sales, support, finance) associated with the participant and/or other participants in communication with the participant, the participant&#39;s presence in forum discussions, etc. In some cases, characteristics used to classify data may be weighted differently as part of the probabilistic algorithm. For example, email domain may be a poor characteristic to classify a participant in some cases because the email domain may be associated with multiple roles. For instance, Microsoft® may be a partner, a customer, and a competitor. 
     In some implementations, a user (e.g., an administrator) can define the probabilistic algorithms used by the a posteriori classification engine  228 . For example, suppose customer Y is a customer of business X and that the management of business X is interested in tracking the percentage of communication between business X and customer Y that relates to sales. Further, suppose that a number of employees from business X and a number of employees from business Y are in communication via email. Some of these employees may be in communication to discuss sales. However, it is also possible that some of the employees may be in communication for technical support issues, invoicing, or for personal reasons (e.g., a spouse of a business X employee may work at customer Y). Thus, in this example, to track the percentage of communication between business X and customer Y that relates to sales the user may define a probabilistic algorithm that classifies communications based on the probability that the communication relates to sales. The algorithm for determining the probability may be based on a number of pieces of metadata associated with each communication. For example, the metadata may include the sender&#39;s job title, the recipient&#39;s job title, the name of the sender, the name of the recipient, whether the communication identifies a product number or an order number, the time of communication, a set of keywords in the content of the communication, etc. 
     Using the a posteriori classification engine  228 , data may be classified based on metadata associated with the data. For example, the communication in the above example can be classified based on whether it relates to sales, supplies, project development, management, personnel, or is personal. The determination of what the data relates to can be based on any criteria. For example, the determination may be based on keywords associated with the data, the data owner, the data author, the identity or roles of users who have accessed the data, the type of data file, the size of the file, the data the file was created, etc. 
     In certain embodiments, the a posteriori classification engine  228  can use the heuristics engine  230  to facilitate classifying data. Further, in some cases, the a posteriori classification engine  228  can use the heuristics engine  230  to validate classifications, to develop probable associations between potentially related content, and to validate the associations as the data collection system  132  collects more data. In certain embodiments, the a posteriori classification engine  228  may base the classifications of data on the associations between potentially related content. In some implementations, the heuristic engine  230  may use machine learning techniques to optimize or update the heuristic algorithms. 
     In some embodiments, a user (e.g., an administrator) can verify whether the data or metadata has been correctly classified. Based on the result of this verification, in some cases, the a posteriori classification engine  228  may correct or update one or more classifications of previously processed or classified data. Further, in some implementations, the user can verify whether two or more pieces of data or metadata have been correctly associated with each other. Based on the result of this verification, the a posteriori classification engine  228  using, for example, the heuristics engine  230  can correct one or more associations between previously processed data or metadata. Further, in certain embodiments, one or more of the a posteriori classification engine  228  and the heuristics engine  230  may update one or more algorithms used for processing the data provided by the data collection system  132  based on the verifications provided by the user. 
     In some embodiments, the heuristics engine  230  may be used as a separate classification engine from the a priori classification engine  226  and the a posteriori classification engine  228 . Alternatively, the heuristics engine  230  may be used in concert with one or more of the a priori classification engine  226  and the a posteriori classification engine  228 . Similar to the a posteriori classification engine  228 , the heuristics engine  230  generally classifies data after the data has been collected and stored at the databases  232 . However, in some cases, the heuristics engine  230  can also be used to classify data as it is collected by the collection engine  202 . 
     The heuristics engine  230  can use any type of heuristic algorithm for classifying data. For example, the heuristics engine  230  can determine whether a number of characteristics are associated with the data and based on the determination, classify the data. For example, data that mentions a product, includes price information, addresses (e.g., billing and shipping addresses), and quantity information may be classified as sales data. In some cases, the heuristics engine  230  can classify data based on a subset of characteristics. For example, if a majority or two-thirds of characteristics associated with a particular classification are identified as existing in a set of data, the heuristics engine  230  can associate the classification with the set of data. In some cases, the heuristics engine  230  determines whether one or more characteristics are associated with the data. In other words, the heuristics engine can determine whether a particular characteristic is or is not associated with the data. Alternatively, or in addition, the heuristics engine  230  can determine the value or attribute of a particular characteristic associated with the data. The value or attribute of the characteristic may then be used to determine a classification for the data. For example, one characteristic that may be used to classify data is the length of the data. For instance, in some cases, a long email may make one classification more likely that a short email. 
     The a priori classification engine  226  and the a posteriori classification engine  228  can store the data classification at the databases  232 . Further, the a posteriori classification engine  228  and the heuristics engine  230  can store the probable associations between potentially related data at the databases  232 . In some cases, as classifications and associations are updated based on, for example, user verifications or updates to the a posteriori and heuristic classification and association algorithms, the data or metadata stored at the databases  232  can be modified to reflect the updates. 
     Users can communicate with the BIM system  130  using a client computing system (e.g., client  114 , client  116 , or client  118 ). In some cases, access to the BIM system  130 , or to some features of the BIM system  130 , may be restricted to users who are using clients associated with the computing environment  102 . As described above, in some cases, at least some users can access the BIM system  130  to verify classifications and associations of data by the data classification system  134 . In addition, in some cases, at least some users can access at least some of the data and/or metadata stored at the data classification system  134  using the BIM access system  136 . The BIM access system  136  can include a user interface  240 , a query manager  242 , and a query security manager  244 . 
     The user interface  240  can generally include any system that enables a user to communicate with the BIM system  130 . Further, the user interface  240  enables the user to submit a query to the BIM system  130  to access the data or metadata stored at the databases  232 . Moreover, the query can be based on any number of or type of data or metadata fields or variables. Advantageously, in certain embodiments, by enabling, a user to create a query based on any number or type of fields, complex queries can be generated. Further, because the BIM system  130  can collect and analyze data from a number of internal and external data sources, a user of the BIM system  130  can extract data that is not typically available by accessing a single data source. For example, a user can query the BIM system  130  to locate all personal messages sent by the members of the user&#39;s department within the last month. As a second example, a user can query the BIM system  130  to locate all helpdesk requests received in a specific month outside of business hours that were sent by customers from Europe. As an additional example, a product manager may create a query to examine customer reactions to a new product release or the pitfalls associated with a new marketing campaign. The query may return data that is based on a number of sources including, for example, emails received from customers or users, Facebook® posts, Twitter® feeds, forum posts, quantity of returned products, etc. 
     Further, in some cases, a user can create a relatively simple query to obtain a larger picture of an organization&#39;s knowledge compared to systems that are incapable of integrating the potentially large number of information sources used by some businesses or organizations. For example, a user can query the BIM system  130  for information associated with customer X over a time range. In response, the BIM system  130  may provide the user with all information associated with customer X over the time range, which can include who communicated with customer X, the percentage of communications relating to specific topics (e.g., sales, support, etc.), the products designed for customer X, the employees who performed any work relating to customer X and the employees&#39; roles, etc. This information may not be captured by a single source. For example, the communications may be obtained from an email server, the products may be identified from product drawings, and the employees and their roles may be identified by examining who accessed specific files in combination with the employees&#39; human resources (HR) records. 
     The query manager  242  can include any system that enables the user to create the query. The query manager  242  can cause the available types of search parameters for searching the databases  232  to be presented to a user via the user interface  240 . These search parameter types can include any type of search parameter that can be used to form a query for searching the databases  232 . For example, the search parameter types can include names (e.g., employee names, customer names, vendor names, etc.), data categories (e.g., sales, invoices, communications, designs, miscellaneous, etc.), stored data types (e.g., strings, integers, dates, times, etc.), data sources (e.g., internal data sources, external data sources, communication sources, sales department sources, product design sources, etc.), dates, etc. In some cases, the query manager  242  can also parse a query provided by a user. For example, some queries may be provided using a text-based interface or using a text-field in a Graphical User Interface (GUI). In such cases, the query manager  242  may be configured to parse the query. 
     The query manager  242  can further include any system that enables the user to create or select a query package that serves as the query. In certain embodiments, the query manager  242  can maintain query packages for each user, group of users, and/or the like. The query packages can be stored, for example, in a SQL database that maintains each user&#39;s query packages in a table by a unique identifier. In some embodiments, each user may have a profile that includes a list of package identifiers for that user. The query manager  242  can cause query packages associated with the user to be presented and made selectable via the user interface  240 . In various embodiments, the query manager  242  can also facilitate creation of new query packages. New query packages can be made accessible to users in various ways. For example, the new query packages can be created by the user, shared with the user by another user, pushed to the user by an administrator, or created in another fashion. 
     Further, the query manager  242  can cause any type of additional options for querying the databases  232  to be presented to the user via the user interface  240 . These additional options can include, for example, options relating to how query results are displayed or stored. 
     In some cases, access to the data stored in the BIM system  130  may be limited to specific users or specific roles. For example, access to the data may be limited to “Bob” or to senior managers. Further, some data may be accessible by some users, but not others. For example, sales managers may be limited to accessing information relating to sales, invoicing, and marketing, technical managers may be limited to accessing information relating to product development, design and manufacture, and executive officers may have access to both types of data, and possibly more. In certain embodiments, the query manager  242  can limit the search parameter options that are presented to a user for forming a query based on the user&#39;s identity and/or role. 
     The query security manager  244  can include any system for regulating who can access the data or subsets of data. The query security manager  244  can regulate access to the databases  232  and/or a subset of the information stored at the databases  232  based on any number and/or types of factors. For example, these factors can include a user&#39;s identity, a user&#39;s role, a source of the data, a time associated with the data (e.g., the time the data was created, a time the data was last accessed, an expiration time, etc.), whether the data is historical or current, etc. 
     Further, the query security manager  244  can regulate access to the databases  232  and/or a subset of the information stored at the databases  232  based on security restrictions or data access policies implemented by the business logic security manager  208 . For example, the business logic security manager  208  may identify all data that is “sensitive” based on a set of rules, such as whether the data mentions one or more keywords relating to an unannounced product in development. Continuing this example, the business logic security manager  208  may label the sensitive data as, for example, sensitive, and may identify which users or roles, which are associated with a set of users, can access data labeled as sensitive. The query security manager  244  can then regulate access to the data labeled as sensitive based on the user or the role associated with the user who is accessing the databases  232 . 
     Although illustrated separately, in some embodiments, the query security manager  244  can be included as part of the query manager  242 . Further, in some cases, one or both of the query security manager  244  and the query manager  242  can be included as part of the user interface  240 . In certain embodiments, some or all of the previously described systems can be combined or further divided into additional systems. Further, some or all of the previously described systems may be implemented in hardware, software, or a combination of hardware and software. 
     Example Data Collection Process 
       FIG. 3  presents a flowchart of an example of a data collection process  300 . The process  300  can be implemented by any system that can access one or more data sources to collect data for storage and analysis. For example, the process  300 , in whole or in part, can be implemented by one or more of the data collection system  132 , the collection engine  202 , the access manager  204 , the business logic engine  206 , and the business logic security manager  208 . In some cases, the process  300  can be performed generally by the BIM system  130 . Although any number of systems, in whole or in part, can implement the process  300 , to simplify discussion, the process  300  will be described in relation to specific systems or subsystems of the BIM system  130 . 
     The process  300  begins at block  302  where, for example, the collection engine  202  accesses data from the internal data sources  120 . At block  304 , the collection engine  202  accesses data from the external data sources  122 . In some cases, either the block  302  or  304  may be optional. Accessing the data may include obtaining the data or a copy of the data from the internal data sources  120 . Further, accessing the data may include accessing metadata associated with the data. In some embodiments, the collection engine  202  may obtain copies of the metadata or access the data to obtain or determine metadata associated with the data without obtaining a copy of the data. For example, in some cases, the collection engine  202  may access email from an email server to obtain metadata (e.g., sender, recipient, time sent, whether files are attached, etc.) associated with email messages with or, in some cases, without obtaining a copy of the email. 
     As previously described, accessing one or more of the internal data sources  120  and the external data sources  122  may involve using one or more credentials or accessing one or more accounts associated with the data sources. In such embodiments, the collection engine  202  may use the access manager  204  to access the credentials and/or to facilitate accessing the data sources. 
     Generally, although not necessarily, the data obtained at blocks  302  and  304  is raw data that is obtained in the format that the data is stored at the data sources with little to no modification. At block  306 , the business logic engine  206 , as described above, can reformat or transform the accessed or collected data for analysis and/or storage. Reformatting the accessed or collected data can include formatting the data to enable further processing by the BIM system  130 . Further, reformatting the accessed or collected data can include formatting the data in a format specified by a user (e.g., an administrator). In addition, in certain cases, reformatting the data can include extracting metadata from the accessed or collected data. In some cases, block  306  can include abstracting the data to facilitate analysis. For example, assuming the data under analysis is an email, a number of users may be identified. For instance, an email may include a sender, one or more recipients, which may also include users that are carbon copied, or listed on the CC line, and Blind Carbon Copied, or listed on the BCC line, and, in some cases, non-user recipients, such as lists or email addresses that result in a copy of the email being placed in an electronic folder for storage. Each of these users can be abstracted as “communication participant.” The data can then be analyzed and/or stored with each user identified, for example, as a “communication participant.” As another example of abstracting the data, the text content of each type of message can be abstracted as “message body.” Thus, an email, a Twitter® post, and a Facebook® post, and a forum post, and a product review can all be abstracted as “message body.” By abstracting data, the BIM system  130  enables more in-depth searching across multiple data sources. For example, a user can search for all messages associated with communication participant X. The result of the search can include any type of message that is associated with user X including emails sent by user X, emails received by user X, product review by user X, Twitter® posts by user X, etc. In some embodiments, the databases  232  may store the abstracted or transformed data and the original data or references to the original sources of data. In other embodiments, the databases  232  may store the abstracted or transformed data in place of the original data. 
     In some cases, reformatting the data may be optional. For example, in cases where the collection engine  202  collects metadata from sources that share a common or substantially similar data storage format, the block  306  may be unnecessary. 
     At block  308 , the business logic security manager  208  applies a security or data access policy to the collected data. Applying the security policy can include preventing the collection engine  202  from accessing some data. For example, applying the security policy can include preventing the collection engine  202  from accessing encrypted files, files associated with a specific project or user, or files marked private. Further, applying the security policy can include marking or identifying data, based on the security policy, that should not be stored at the databases  232 , that should be accessible by a set of users or roles, or that should be inaccessible by a set of users or roles. The business logic security manager  208  can filter any data marked for exclusion from storage in the databases  232  at block  310 . Further, the business logic security manager  208  and/or the business logic engine  206  can filter out any data to be excluded based on a data access policy, which can be based on any type of factor for excluding data. For example, data may be filtered based on the age of the data, such as files created more than five years ago or emails more than two years old. 
     At block  312 , the business logic engine  206  or the business logic security manager  208  may classify the collected and/or filtered data. The data may be classified based on, for example, who can access the data, the type of data, the source of the data, or any other factor that can be used to classify data. In some embodiments, the data may be provided to the data classification system  134  for classification. Some non-limiting embodiments of a process for classifying the data are described in further detail below with respect to the process  400 , which is illustrated in  FIG. 4 . 
     The business logic engine  206  further formats the data for storage at block  314 . Formatting the data for storage can include creating a low-level abstraction of the data, transforming the data, or extracting metadata for storage in place of the data. In some cases, block  314  can include some or all of the embodiments described above with respect to the block  306 . In some embodiments, data may go through one abstraction or transformation process at the block  306  to optimize the data for analysis and go through another abstraction or transformation process at the block  314  to optimize the data for storage and/or query access. In some embodiments, the metadata may be stored in addition to the data. Further, the metadata, in some cases, may be used for querying the databases  232 . For example, a user can search the databases  232  for information based on one or more metadata fields. In some embodiments, one or more of the blocks  306  and  314  may be optional. 
     At block  316 , the data collection system  132  can cause the data to be stored at, for example, the databases  232 . This stored data can include one or more of the collected data, the metadata, and the abstracted data. In some embodiments, storing the data can include providing the data to the data repository  222  for indexing. In such embodiments, the data repository  222  can store the indexed data at the databases  232 . 
     Although the process  300  was presented above in a specific order, it is possible for the operations of the process  300  to be performed in a different order or in parallel. For example, the business logic security manager  208  may perform the block  308 , at least in part, prior to or in parallel with the blocks  302  and  304 . As a second example, the business logic engine  206  may perform the block  306  as each item of data is accessed or after a set of data is accessed at the blocks  302  and  304 . 
     Example Data Classification Process 
       FIG. 4  presents a flowchart of an example of a data classification process  400 . The process  400  can be implemented by any system that can classify data and/or metadata. For example, the process  400 , in whole or in part, can be implemented by one or more of the data classification system  134 , the data repository engine  222 , the task scheduler  224 , the a priori classification engine  226 , the a posteriori classification engine  228 , and the heuristics engine  230 . In some cases, the process  400  can be performed generally by the BIM system  130 . Although any number of systems, in whole or in part, can implement the process  400 , to simplify discussion, the process  400  will be described in relation to specific systems or subsystems of the BIM system  130 . 
     The process  400  begins at block  402  where, for example, the data collection system  132  accesses data from one or more of the internal data sources  120  and the external data sources  122 . The data collection system  132  may use the collection engine  202  to access the data. Further, the block  402  can include some or all of the embodiments described above with respect to the blocks  302  and  304 . Moreover, some or all of the process  300  described above can be performed as part of the process performed at block  402 . In some embodiments, the process  400  can be performed as part of the block  312  above. In such embodiments, the block  402  may include the data collection system  132  providing the data, a reformatted version of the data, an abstraction of the data, and/or metadata to the data classification system  134 . In some implementations, the process  400  may be performed separately or independently of the data collection process. In such embodiments, the block  402  may include accessing the data from the databases  232 . In some cases, the databases  232  may include a database for classified data and a separate database for data that has not yet been classified. 
     At block  404 , the a priori classification engine  226  classifies the data based on a set of user-specified classification rules. As previously mentioned, a developer of the BIM system  130  or a user (e.g., an administrator) may specify the classification rules. Further, the classification rules can include any rules for classifying data based on the data or metadata associated with the data. For example, data may be classified based on the author of the data, the owner of the data, the time the data was created, etc. 
     At block  406 , the a posteriori classification engine  228  classifies the data using a posteriori analysis. This may include the a posteriori classification engine  228  using one or more probabilistic algorithms to determine one or more classifications for the data. The a posteriori classification engine  228  can use any type of probabilistic algorithm for classifying the data. For example, the classification may be based on one or more Bayesian probability algorithms. As another example, the a posteriori classification may be based on clustering of similar or dissimilar pieces of data. One example of such an approach that can be adapted for use herein is the Braun-Blanquet method that is sometimes used in vegetation science. One or both of the a priori classification and the a posteriori classification may be based on one or more variables or criteria associated with the data or metadata. 
     In some embodiments, the a posteriori classification engine  228  may use the heuristics engine  230  to facilitate calculating the probabilistic classifications of the data. For example, the a posteriori classification engine  228  can modify the probabilities used to classify the data based on a determination of the heuristics engine  230  of the accuracy of the classification of previously classified data. The heuristics engine  230  may determine the accuracy of the classification of previously classified data based on, for example, feedback by the user. This feedback may include, for example, manual reclassification of data, indications by a user of the accuracy of prior classifications, indications of the accuracy or usefulness of query results from querying the databases  232  that include the classified data, etc. Further, the heuristics engine  230  may determine the accuracy of the classification of previously classified data based on, for example, the classifications of data accessed more recently than the previously classified data. In some cases, the more recent data may have been accessed before or at the same time as the previously classified data, but may be classified after the previously classified data. 
     At block  408 , the heuristics engine  230  can classify data using a heuristics analysis. As previously described, in some cases, the heuristics engine  230  can classify the data based on the number or percentage of characteristics or attributes associated with the data that match a particular classification. 
     In some embodiments, the task scheduler  224  schedules one or more of the blocks  404 ,  406 , and  408 . Further, in some cases, the task scheduler  224  may determine whether to perform the process  400  and/or one or more of the blocks  404 ,  406 , and  408 . In some cases, one or more of the blocks  404 ,  406 , and  408  may be optional. For instance, an initial classification may be associated with data when it is collected via the process associated with the block  404 . The data may then be further classified or reclassified at collection, or at a later time, using the process associated with the block  406 , the block  408 , or a combination of the blocks  406  and  408 . 
     At block  410 , the data repository engine  222  stores or causes to be stored the data and the data classifications at the databases  232 . In some cases, the data repository engine  222  may store metadata associated with the data at the databases  232  instead of, or in addition to, storing the data. 
     At block  412 , the data repository engine  222  can update the a posteriori algorithms based on the classifications determined for the data. In addition, or alternatively, the a posteriori algorithms may be updated based on previously classified data. The a posteriori algorithms may be updated based on customer feedback and/or the determination of the heuristics engine  230  as described above with respect to the block  406 . Further, updating the a posteriori algorithms may include modifying the probabilistic weights applied to one or more variables or pieces of metadata used to determine the one or more classifications of the data. Moreover, updating the a posteriori algorithms may include modifying the one or more variables or pieces of metadata used to determine the one or more classifications of the data. In some cases, the block  412  can include modifying the heuristic algorithms used at the block  408 . For example, the number of characteristics required to classify the data with a particular classification may be modified. In addition, or alternatively, the weight applied to each of the characteristics may be modified at the block  412 . 
     As with the process  300 , it is possible for the operations of the process  400  to be performed in a different order or in parallel. For example, the blocks  404  and  406  may be performed in a different order or in parallel. 
     Example Data Query Process Using User-Provided Query 
       FIG. 5  presents a flowchart of an example of a data query process  500 . The process  500  can be implemented by any system that can process a query provided by a user or another system and cause the results of the query to be presented to the user or provided to the other system. For example, the process  500 , in whole or in part, can be implemented by one or more of the BIM access system  136 , the user interface  240 , the query manager  242 , and the query security manager  244 . In some cases, the process  500  can be performed generally by the BIM system  130 . Although any number of systems, in whole or in part, can implement the process  500 , to simplify discussion, the process  500  will be described in relation to specific systems or subsystems of the BIM system  130 . 
     The process  500  begins at block  502  where, for example, the user interface  240  receives a set of one or more search parameters from a user via a client (e.g., the client  114 ). In some embodiments, the search parameters may be provided by another computing system. For example, in some embodiments, an application running on a server (not shown) or a client (e.g., the client  116 ) may be configured to query the BIM system  130  in response to an event or at a predetermined time. The application can then use the result of the query to perform an application-specific process. For instance, an application or script may be configured to query the BIM system  130  every month to determine the workload of each employee or of the employees in a specific department of an organization to determine, for example, whether additional employees are needed or whether the allocation of human resources within different departments should be redistributed. In this example, the application can determine whether to alert a user based on the result of the determination. 
     In some implementations, a user can provide a text-based query to the user interface  240 . This text-based query can be parsed by, for example, the user interface  240  and/or the query manager  242 . Alternatively, or in addition, the user interface  240  can provide a set of query options and/or fields that a user can use to formulate a query of the BIM system  130 . The query options or fields can include any type of option or field that can be used to form a query of the BIM system  130 . For example, the query options or fields can include tags, classifications, time ranges, keywords, user identifiers, user roles, customer identifiers, vendor identifiers, corporate locations, geographic locations, etc. In some embodiments, the query options and/or search fields presented to a user may be generated based on the data stored in the databases  232 . For example, if the databases  232  includes email data, a sender field and a recipient field may be available for generating a query. However, if the databases  232  lacks any email data, the sender and recipient fields may not be available for generating a query. 
     In some cases, the query security manager  244  can limit or determine the fields or options that the user interface  240  can present to the user based on, for example, the user&#39;s permissions or the user&#39;s role. For example, fields relating to querying the BIM system  130  regarding the content of a business&#39;s email may be unavailable to a user who is not authorized to search the contents of collected email. For instance, searching the content of emails may be limited to the legal department for compliance purposes. Other users may be prohibited from searching the email content for privacy reasons. 
     At block  504 , the query manager  242  formats a query based on the search parameters received at block  502 . Formatting the query may include transforming the search parameters and query options provided by the user into a form that can be processed by the data repository engine  222 . In certain embodiments, the block  504  may be optional. For example, in some cases the search parameters may be provided by the user in a form of a query that can be processed by the BIM system  130  without modification. 
     At block  506 , the user interface  240  receives one or more user credentials from the user. In some cases, the user credentials may be received from an application. The user credentials can include any type of credential or identifier that can be used to identify a user and/or determine a set of permissions or a level of authorization associated with the user. At block  508 , the query security manager  244  can validate the user, or application, based at least in part on the user credentials received at the user interface  240 . Validating the user can include identifying the user, identifying permissions associated with the user, the user&#39;s role, and/or an authorization level associated with the user. In some embodiments, if the query security manager  244  is unable to validate the user or determines that the user lacks authorization to access the BIM system  130  and/or query the databases  232 , the query security manager  244  may reject the user&#39;s query. Further, the user interface  240  may inform the user that the user is not authorized to access the BIM system  130  or to query the databases  232 . In some implementations, if the user identifies as a guest or if the query security manager  244  is unable to validate the guest, the user may be associated with a guest identity and/or a set of guest permissions, which may permit limited access to the BIM system  130  or the data stored at the databases  232 . In some cases, a guest may receive full access to the BIM system  130 . However, the actions of the guest may be logged or logged differently than the actions of an identified user. 
     At block  510 , the query security manager  244  attaches the user permissions to the query. Alternatively, or in addition, the query security manager may attach the user&#39;s identity, role, and/or authorization level to the query. In some embodiments, one or more of the blocks  506 ,  508 , and  510  may be optional. 
     At block  512 , the query manager  242  retrieves data, and/or metadata, satisfying the query. In some implementations, the block  512  may include providing the query to the data repository engine  222  for processing. The data repository engine  222  can then query the databases  232  to obtain data that satisfies the query. This data can then be provided to the query manager  242 . 
     At decision block  514 , the query security manager  244  can determine whether the user has permission, or is authorized, to access the data that satisfies the query. Determining whether the user has permission to access the data may be based on any type of factor that can be used to determine whether a user can access data. For example, the determination may be based, at least in part, on the user&#39;s credentials, the user&#39;s permissions, a security level associated with the data, etc. In some cases, the data repository engine  222  may perform the decision block  514  as part of the process associated with the block  512 . 
     If the query security manager  244  determines that the user does not have permission to access the data, the query security manager  244  rejects the user query at block  516 . In some cases, rejecting the user query may include informing the user that the query is not authorized and/or that the user is not authorized to access the data associated with the query. In other cases, rejecting the user query may include doing nothing or presenting an indication to the user that no data satisfies the user&#39;s query. 
     If the query security manager  244  determines that the user does have permission to access the data, the user interface  240  provides the user with access to the data at block  518 . Providing the user with access to the data can include presenting the data on a webpage, in an application-generated window, in a file, in an email, or any other method for providing data to a user. In some cases, the data may be copied to a file and the user may be informed that the data is ready for access by, for example, providing the user with a copy of the file, a link to the file, or a location associated with the file. 
     With some queries, a user may be authorized to access some data that satisfies the query, but not other data that satisfies the query. In such cases, the user may be presented with the data that the user is authorized to access. Further, the user may be informed that additional data exists that was not provided because, for example, the user was not authorized to access the data. In other cases, the user may not be informed that additional data exists that was not provided. 
     In some embodiments, the decision block  514  and block  516  may be optional. For example, in some cases where the search parameters available to a user are based on the user&#39;s permissions, decision block  514  may be superfluous. However, in other embodiments, both the search parameters available to the user and the data the user can access are independently determined based on the user&#39;s permissions. 
     Advantageously, in certain embodiments, the process  500  can be used to identify new information and/or to determine trends that would be more difficult or identify or not possible to identify based on a single data source. For example, the process  500  can be used to identify the most productive and least productive employees of an organization based on a variety of metrics. Examining a single data source may not provide this information because employees serve different roles. Further, different employees are unproductive in different ways. For example, some employees may spend time an inordinate amount of time on social networking sites or emailing friends. Other employees may procrastinate by playing games or by talking in the kitchen. Thus, examining only email use or Internet activity may not provide an accurate determination of which employees are more productive. In addition, some employees can accomplish more work in less time than other employees. Thus, to determine which employees are the most productive during working hours requires examining a number of data sources. The BIM system  130  makes this possible by enabling a user to generate a query that relates the amount of time in the office to the amount of time spent procrastinating at different types of activities to the number of work-related tasks that are accomplished. 
     As a second example, the BIM system  130  can be used to identify the salespersons and the communications techniques that are most effective for each customer. For instance, a user can generate a query that relates sales, the method of communication, the content of communication, the salespersons contacting each of the customers, and the customers. Based on the result of this query, a manager may be able to determine that certain salespersons generate larger sales when using a particular communication method with a particular customer while other salespersons may be more effective with a different communication method with the particular customer or may be more effective with other customers. 
     An additional example of an application of the BIM system  130  can include gauging employee reaction to an executive memorandum or a reorganization announcement. Queries can be generated to access all communications associated with the memorandum or announcement. Alternatively, or in addition, queries can be generated to identify the general mood of employees post memorandum or announcement. These queries can examine the tone of emails and other communications (e.g., social networking posts, etc.). Additional examples of applications for using the BIM system  130  can include determining whether employees are communicating with external sources in a manner that adheres to corporate policies, communicating with customers in a timely fashion, or accessing data that is unrelated to their job role. 
     Example of a Heuristics Engine 
       FIG. 6  illustrates an example of a heuristics engine  602 . In a typical embodiment, the heuristics engine  602  operates as described with respect to the heuristics engine  230  of  FIG. 2 . In a typical embodiment, the heuristics engine  602  is operable to perform a heuristics analysis for each of a plurality of different classifications and thereby reach a classification result for each classification. The classification result may be, for example, an indication whether a given classification should be assigned to given data. For purposes of simplicity, the heuristics engine  602  may be periodically described, by way of example, with respect to a single classification. 
     The heuristics engine  602  includes a profiling engine  604  and a comparison engine  606 . In a typical embodiment, the profiling engine  604  is operable to develop one or more profiles  608  by performing, for example, a multivariate analysis. For example, in certain embodiments, the one or more profiles  608  may relate to what constitutes a personal message. In these embodiments, the profiling engine  604  can perform a multivariate analysis of communications known to be personal messages in order to develop the one or more profiles  608 . In some embodiments, the one or more profiles  608  can also be manually established. 
     In typical embodiment, the one or more profiles  608  can each include an inclusion list  610  and a filter list  612 . The inclusion list  610  can include a list of tokens such as, for example, words, that have been determined to be associated with the classification to which the profile corresponds (e.g., personal message, business message, etc.). In a typical embodiment, for each token in the inclusion list  610 , the appearance of the token in a communication makes it more likely that the communication should be assigned the classification. The filter list  612  can include a list of tokens such as, for example, words, that have been determined to have little to no bearing on whether a given communication should be assigned the classification. In some embodiments, the filter list  612  may be common across all classifications. 
     In certain embodiments, the inclusion list  610  may be associated with statistical data that is maintained by the profiling engine  604 . Based on the statistical data, the one or more profiles  608  can provide means, or expected values, relative to the inclusion list  610 . In some embodiments, the expected value may be based on an input such as a length of a given communication (e.g., a number of characters or words). According to this example, the expected value may be an expected number of “hits” on the inclusion list  610  for a personal message of a particular length. The particular length may correspond to a length of the given communication. By way of further example, the expected value may be an expected percentage of words of a personal message that are “hits” on the inclusion list  610 . Optionally, the expected percentage may be based on a length of the given communication in similar fashion to that described above with respect to the expected number of “hits.” 
     The comparison engine  606  is operable to compare data to the one or more profiles  108  based on configurations  614 . The configurations  614  typically include heuristics for establishing whether data should be classified into the classification. In particular, the configurations  614  can include one or more thresholds that are established relative to the statistical data maintained by the profiling engine  604 . For example, each threshold can be established as a number of standard deviations relative to an expected value. 
     For example, continuing the personal-message classification example described above, the configurations  614  may require that an actual value of a given metric for a new communication not be more than two standard deviations below the expected value of the given metric. In this fashion, if the actual value is not more than two standard deviations below the expected value, the new communication may be assigned the classification. The given metric may be, for example, a number or percentage of “hits” as described above. 
     Example of a Heuristics Process 
       FIG. 7  presents a flowchart of an example of a heuristics process  700  for classifying data into a classification. The process  700  can be implemented by any system that can classify data and/or metadata. For example, the process  700 , in whole or in part, can be implemented by a heuristics engine such as, for example, the heuristics engine  230  of  FIG. 2  or the heuristics engine  602  of  FIG. 6 . In some cases, the process  700  can be performed generally by the BIM system  130 . Although any number of systems, in whole or in part, can implement the process  700 , to simplify discussion, the process  700  will be described in relation to the heuristics engine. The process  700  begins at step  702 . 
     At step  702 , the heuristics engine receives new data. The new data may be considered to be representative of any data, inclusive of metadata, for which classification is desired. The new data may be, for example, a new communication. From step  702 , the process  700  proceeds to step  704 . At step  704 , the heuristics engine identifies one or more comparison attributes in the new data. For example, the one or more comparison attributes may be actual values for given metrics such as, for example, a number or percentage of “hits” on an inclusion list such as the inclusion list  610  of  FIG. 6 . From step  704 , the process  700  proceeds to step  706 . 
     At step  706 , the heuristics engine compares the one or more comparison attributes with one or more thresholds. The one or more thresholds may be defined as part of configurations such as, for example, the configurations  614  of  FIG. 6 . From step  706 , the process  700  proceeds to step  708 . At step  708 , the heuristics engine determines whether classification criteria has been satisfied. In a typical embodiment, the classification criteria is representative of criteria for determining whether the new data should be assigned the classification. The classification criteria may specify, for example, that all or a particular combination of the one or more thresholds be satisfied. 
     If it is determined at step  708  that the classification criteria not been satisfied, the process  700  proceeds to step  712  where the process  700  ends without the new data being assigned the classification. If it is determined at step  708  that the classification criteria has been satisfied, the process  700  proceeds to step  710 . At step  710 , the heuristics engine assigns the classification to the new data. From step  710 , the process  700  proceeds to step  712 . At step  712 , the process  700  ends. 
     Example of Query Packages 
     In certain embodiments, data queries as described with respect to  FIGS. 1-5  may also be accomplished using query packages. A query package generally encapsulates package attributes such as, for example, search parameters as described above with respect to queries, as long with other package attributes that enable enhanced functionality. For example, a query package can further encapsulate a package attribute that specifies a type of data visualization that is to be created using the queried data. The type of data visualization can include, for example, scatterplots, pie charts, tables, bar charts, geospatial representations, heat maps, chord charts, interactive graphs, bubble charts, candlestick charts, stoplight charts, spring graphs, and/or other types of charts, graphs, or manners of displaying data. 
     In some embodiments, query packages may run one specific query. In various other embodiments, query packages may run multiple queries. Table 1 below lists exemplary package attributes that can be included in a given query package. 
     
       
         
           
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 PACKAGE  
                   
               
               
                 ATTRIBUTE(S) 
                 DESCRIPTION 
               
               
                   
               
             
            
               
                 Package Name 
                 A name by which the query package can be 
               
               
                   
                 referenced. 
               
               
                 Package  
                 A description of the query package&#39;s operation. 
               
               
                 Description 
                   
               
               
                 Security Scope 
                 Optionally specify a security and data access policy 
               
               
                   
                 as described with respect to FIG. 2. 
               
               
                 Visualization 
                 Specifies a type of data visualization such as, for 
               
               
                   
                 example, scatterplots, pie charts, tables, bar charts, 
               
               
                   
                 geospatial representations, heat maps, chord charts, 
               
               
                   
                 interactive graphs, bubble charts, candlestick charts, 
               
               
                   
                 stoplight charts, spring graphs, and/or other types of 
               
               
                   
                 charts, graphs, or manners of displaying data. 
               
               
                   
                 In cases where the package is representative of 
               
               
                   
                 multiple queries, the visualization attribute may be 
               
               
                   
                 represented as an array of visualizations that can 
               
               
                   
                 each have a visualization type, a data source, and a 
               
               
                   
                 target entity (e.g., entity that is being counted such 
               
               
                   
                 as, for example, messages, message participants, 
               
               
                   
                 etc.) 
               
               
                 Default Group-  
                 Retrieves data according to, for example, one or 
               
               
                 By Field 
                 more data columns (e.g., by location, department, 
               
               
                   
                 etc.). 
               
               
                 Aggregation  
                 A time period such as, for example, daily, hourly, 
               
               
                 Period 
                 etc. 
               
               
                 Data-Smoothing  
                 Specifies one or more algorithms that attempt to 
               
               
                 Attributes 
                 capture important patterns in the data, while leaving 
               
               
                   
                 out noise or other fine-scale structures/rapid 
               
               
                   
                 phenomena. 
               
               
                 Visualization-  
                 Certain types of visualizations may require 
               
               
                 Specific 
                 additional attributes such as, for example, 
               
               
                 Attributes 
                 specification of settings for sorting, number of 
               
               
                   
                 elements in a data series, etc. 
               
               
                 Facet Names 
                 Data (or fields) related to the query that can be used 
               
               
                   
                 to categorize data. Particular values of facets can be 
               
               
                   
                 used, for example, to constrain query results. 
               
               
                 Array of Entities 
                 An array of entities that can each have, for example, 
               
               
                   
                 a name, entity type (e.g., message), filter expression, 
               
               
                   
                 and a parent-entity property. 
               
               
                 Array of Facets 
                 An array of facets that can each have, for example, a 
               
               
                   
                 name, group-by field, and a minimum/maximum 
               
               
                   
                 number of results to show. 
               
               
                   
               
            
           
         
       
     
     In a typical embodiment, query packages can be shared among users or distributed to users, for example, by an administrator. In a typical embodiment, one user may share a particular query package with another user or group of users via the user interface  240 . In similar fashion the other user or group of users can accept the query package via the user interface  240 . Therefore, the query manager  242  can add the shared query package for the user or group of users. As described above, the query manager  242  generally maintains each user&#39;s query packages in a table by a unique identifier. In a typical embodiment, query packages further facilitate sharing by specifying data and data sources in a relative fashion that is, for example, relative to a user running the query. For example, package attributes can refer to data owned by a user running the query or to data that is owned by users under the supervision of the user running the query rather than to specific data or users. 
     Example Data Query Process Using Query Packages 
       FIG. 8  presents a flowchart of an example of a data query process  800  that uses query packages. The process  800  can be implemented by any system that can process a query package provided by a user or another system and cause the results of a query encapsulated therein to be presented to the user or provided to the other system. For example, the process  800 , in whole or in part, can be implemented by one or more of the BIM access system  136 , the user interface  240 , the query manager  242 , and the query security manager  244 . In some cases, the process  800  can be performed generally by the BIM system  130 . Although any number of systems, in whole or in part, can implement the process  800 , to simplify discussion, the process  800  will be described in relation to specific systems or subsystems of the BIM system  130 . 
     The process  800  begins at block  802  where, for example, the user interface  240  from a user a selection of a query package. In various embodiments, the query package may be selected from a list or graphical representation of query packages. As described above, the query package typically specifies a data visualization based on a data query. In various embodiments, the query package may specify more than one data visualization and/or be based on more than one data query. At block  804 , the query manager  242  formats one or more queries based on the query package selected at block  802 . In certain embodiments, the block  804  may be optional. For example, in some cases the query package may already include a query that can be processed by the BIM system  130  without modification. 
     At block  806 , the user interface  240  receives one or more user credentials from the user. In some cases, the user credentials may be received from an application. The user credentials can include any type of credential or identifier that can be used to identify a user and/or determine a set of permissions or a level of authorization associated with the user. At block  808 , the query security manager  244  can validate the user, or application, based at least in part on the user credentials received at the user interface  240 . Validating the user can include identifying the user, identifying permissions associated with the user, the user&#39;s role, and/or an authorization level associated with the user. In some embodiments, if the query security manager  244  is unable to validate the user or determines that the user lacks authorization to access the BIM system  130  and/or query the databases  232 , the query security manager  244  may reject the one or more queries. Further, the user interface  240  may inform the user that the user is not authorized to access the BIM system  130  or to query the databases  232 . In some implementations, if the user identifies as a guest or if the query security manager  244  is unable to validate the guest, the user may be associated with a guest identity and/or a set of guest permissions, which may permit limited access to the BIM system  130  or the data stored at the databases  232 . In some cases, a guest may receive full access to the BIM system  130 . However, the actions of the guest may be logged or logged differently than the actions of an identified user. 
     At block  810 , the query security manager  244  attaches the user permissions to the one or more queries. Alternatively, or in addition, the query security manager may attach the user&#39;s identity, role, and/or authorization level to the one or more queries. In some embodiments, one or more of the blocks  806 ,  808 , and  810  may be optional. 
     At block  812 , the query manager  242  retrieves data, and/or metadata, satisfying the one or more queries. In some implementations, the block  812  may include providing the one or more queries to the data repository engine  222  for processing. The data repository engine  222  can then query the databases  232  to obtain data that satisfies the one or more queries. This data can then be provided to the query manager  242 . 
     At decision block  814 , the query security manager  244  can determine whether the user has permission, or is authorized, to access the data that satisfies the one or more queries. Determining whether the user has permission to access the data may be based on any type of factor that can be used to determine whether a user can access data. For example, the determination may be based, at least in part, on the user&#39;s credentials, the user&#39;s permissions, a security level associated with the data, etc. In some cases, the data repository engine  222  may perform the decision block  814  as part of the process associated with the block  812 . 
     If the query security manager  244  determines that the user does not have permission to access the data, the query security manager  244  rejects the one or more queries at block  816 . In some cases, rejecting the one or more queries may include informing the user that the query package not authorized and/or that the user is not authorized to access the data associated with the query package. In other cases, rejecting the one or more queries may include doing nothing or presenting an indication to the user that no data satisfies the query package. 
     If the query security manager  244  determines that the user does have permission to access the data, the query manager  242  (or a separate visualization component) generates the data visualization at block  818 . At block  820 , the user interface  240  provides the data visualization to the user. Providing the user the data visualization can include presenting the data visualization on a webpage, in an application-generated window, in a file, in an email, or any other method for providing data to a user. In some cases, the data visualization may be copied to a file and the user may be informed that the data visualization is ready for access by, for example, providing the user with a copy of the file, a link to the file, or a location associated with the file. 
       FIG. 9  illustrates an example of a user interface that can be used by a user to select a query package. 
       FIG. 10  illustrates an example of a user interface that can be used by a user to create or modify a query package. 
     Example of a Data Model 
     Table 2 below provides an example of a data model that can be utilized by a BIM system such as, for example, the BIM system  130 . In particular, Table 2 illustrates several entities that can be used to model communications such as, for example, personal communications or business communications. 
                             TABLE 2               ENTITY   FIELD   DATA TYPE                  Message   Body   String           Classifications   Strings           Content   String           Date   Date Time           External Recipients   Entities (Message Participant)           File Attachments   Entities (File)           In reply to   Entity (Message)           Internal Recipients   Entities (Message Participant)           Is Encrypted   Boolean           Message Attachments   Entities (Messages)           Message IDs   Strings           Original Message ID   String           Participants   Entities (Message Participant)           Platform   Enum (Message Platform type)           Recipients   Entities (Message Participant)           Send Date   Date Time           Send Time of Day   Time           Sender   Entity (Message Participant)           Size   Integer           Subject   String           Thread   Entity (Message Thread)           Type   Enum (Message Address Type)       Message   Date   Date Time       Participant   Deletion Date   Date Time           Delivery Time   Time Span           Has Been Delivered   Boolean           ID   String           Is Addressed in BCC   Boolean           Is Addressed in CC   Boolean           Is Addressed in TO   Boolean           Is External Recipient   Boolean           Is Internal Recipient   Boolean           Is Recipient   Boolean           Is Sender   Boolean           MessgeAsSender   Entity (Message)           MessageAsInternalRecipient   Entity (Message)           MessageAsExternalRecipient   Entity (Message)           Message Address   Entity (Message Address)           Person   Entity (Person Snapshot)           Receipt Date   Date Time           Receipt Time of Day   Time           Responses   Entity (Message)           Response Time   Time Span       Message   Domain   Entity (ONS Domain)       Address   Is External   Boolean           Is Internal   Boolean           Name   String           Platform   Enum (Message Platform                Type)           Type   Enum (Message Address Type       DNS    Name   String       Domain   Address   Entities (Messaging Address)       Person    All Reports   Entities (Person Snapshot)       Snapshot   Company   String           Department   String           Direct Reports   Entities (Person Snapshot)           First Name   String           Full Name   String           History   Entity (Person History)           ID   String           Initials   String           Job Title   String           Last Name   String           Manager   Entity (Person Snapshot)           Managers   Entities (Person Snapshot)           Messaging Addresses   Entities (Message Address)           Message Participants               Office   String           OU   String           Snapshot Date   Date Time           Street Address   Complex Type (Street Address)           Telephone Numbers   Strings       Street    City   String       Address   Country or Region   String           PO Box   String           State or Province   String           Street   String           Zip or Postal Code   String       Person   Current   Entity (Person)       History   Historic   Entities (Person)           ID   String           Messages   Entities (Message)           Timestamp   Date Time       Message   ID   String       Thread   Messages   Entities (Message)           Participants   Entities (Message Participant           Thread subject   String           Timestamp   Date Time       File   Filename   String           ID   String           Messages   Entities (Message)           Modified Date   Date Time           Size   Integer           Hash   String                    
Examples of Utilization of a BIM Access System
 
     Table 3, Table 4, and Table 5 below provide several examples of how a BIM access system such as, for example, the BIM access system  136 , can be utilized. In various embodiments, each example may be implemented as user-generated queries or query packages as described above. In particular, Table 3 illustrates uses cases for gleaning operational insights. Table 4 illustrates use cases for gleaning business insights. Table 5 illustrates uses cases for gleaning compliance insights. 
     
       
         
           
               
               
               
               
               
             
               
                 TABLE 3 
               
               
                   
               
               
                   
                 USER 
                   
                   
                   
               
               
                 USE CASE 
                 PERSONA 
                 POTENTIAL OBJECTIVE(S) 
                 INPUT 
                 OUTPUT 
               
               
                   
               
             
            
               
                 Find Lost 
                 Helpdesk 
                 1. Help a mail user unders7tand 
                 Sender name, 
                 Indication 
               
               
                 Message 
                 Personnel 
                 why they (or a recipient) apparently 
                 recipient name, 
                 whether message 
               
               
                 (Helpdesk) 
                   
                 didn&#39;t receive a message; 
                 message date 
                 was delivered 
               
               
                   
                   
                 2. Help that user prove whether the 
                 range, and 
                 and, if not, a 
               
               
                   
                   
                 message was delivered or not, or 
                 message subject. 
                 location of where 
               
               
                   
                   
                 whether message was caught by junk 
                   
                 message was last 
               
               
                   
                   
                 filter; and 
                   
                 located. 
               
               
                   
                   
                 3. Escalate the problem to IT if 
                   
                   
               
               
                   
                   
                 there is a system problem. 
                   
                   
               
               
                 Find Lost 
                 Mail User 
                 1 Understand why someone 
                 Sender name, 
                 Was message 
               
               
                 Message (Self- 
                   
                 apparently didn&#39;t receive a message I 
                 recipient name, 
                 delivered or is it 
               
               
                 Service) 
                   
                 sent them. 
                 message date/time, 
                 in transit 
               
               
                   
                   
                 2. Discover whether the message 
                 message subject 
                   
               
               
                   
                   
                 was actually delivered. 
                   
                   
               
               
                   
                   
                 3. Report a system problem to IT if 
                   
                   
               
               
                   
                   
                 necessary. 
                   
                   
               
               
                 Track 
                 Mail User 
                 1. Determine whether a specific 
                 Sender name, 
                 Was message sent 
               
               
                 Anticipated 
                   
                 person sent a message that was expected 
                 recipient name, 
                 and delivered or is 
               
               
                 Message 
                   
                 to be sent. 
                 message date range 
                 it in transit 
               
               
                   
                   
                 2. Determine whether the message 
                   
                   
               
               
                   
                   
                 was actually sent, or lost in transit. 
                   
                   
               
               
                 Measure 
                 IT Manager 
                 1. Track the average and maximum 
                 Source (mailbox/ 
                 Textual output of 
               
               
                 Internal Mail 
                   
                 message delivery times of internal mail 
                 site), target 
                 compliance 
               
               
                 Delivery time 
                   
                 system. 
                 (mailbox/site) 
                 results, drill-into 
               
               
                 Compliance 
                   
                   
                   
                 the “Analyze 
               
               
                   
                   
                   
                   
                 Internal Mail 
               
               
                   
                   
                   
                   
                 Delivery Times” 
               
               
                   
                   
                   
                   
                 scenario (and 
               
               
                   
                   
                   
                   
                 accompanying 
               
               
                   
                   
                   
                   
                 charts) to find out 
               
               
                   
                   
                   
                   
                 where your SLA 
               
               
                   
                   
                   
                   
                 was NOT met. 
               
               
                 Analyze 
                 Messaging 
                 1. Show and trend the delivery times 
                 Source (mailbox/ 
                 Trend charts of 
               
               
                 Internal Mail 
                 Administrator 
                 between internal servers. 
                 site), target 
                 overall, site to 
               
               
                 Delivery 
                   
                 2. Identify problem areas, or future 
                 (mailbox/site), 
                 site, or server to 
               
               
                 Times 
                   
                 problem areas, regarding inter- 
                 filter (maximum 
                 server average/ 
               
               
                   
                   
                 organization mail delivery. 
                 delivery time 
                 maximum 
               
               
                   
                   
                   
                 between 2 end- 
                 delivery times 
               
               
                   
                   
                   
                 points) 
                   
               
               
                 Diagnose Slow 
                 Messaging 
                 1. Investigate why a particular 
                 Sender, recipient, 
                 Details of 
               
               
                 or Lost 
                 Administrator 
                 message was slow to be delivered. 
                 message date/ 
                 message delivery 
               
               
                 Delivery for a 
                   
                 2. Determine whether there is a 
                 time, subject 
                 path and timing 
               
               
                 Particular 
                   
                 problem with the mail system 
                 wildcard, Filter on 
                   
               
               
                 Message 
                   
                 3. Take any necessary corrective 
                 message header 
                   
               
               
                   
                   
                 action, 
                 (including x- 
                   
               
               
                   
                   
                   
                 headers) 
                   
               
               
                 Compare and 
                 IT Manager, 
                 1. Regularly compare and trend the 
                 Date range, data 
                 Trend of relative 
               
               
                 Trend Usage 
                 Executive 
                 usage of different communications 
                 sources (Exchange, 
                 platform usage 
               
               
                 across 
                   
                 systems. 
                 Lync/OCS), users 
                 over time, point- 
               
               
                 Communication 
                   
                 2. Perform capacity planning and 
                 (department/site) 
                 in-time chart 
               
               
                 Systems 
                   
                 make infrastructure investment 
                   
                   
               
               
                   
                   
                 decisions. 
                   
                   
               
               
                   
                   
                 3. Track changes in user behavior 
                   
                   
               
               
                   
                   
                 to communication usage directives. 
                   
                   
               
               
                 Analyze Non- 
                 Messaging and 
                 1. Show point-in-time, and trending, 
                 Date time range, 
                 Table with 
               
               
                 Delivery 
                 Messaging 
                 of an aggregate number and type of 
                 target domain, site, 
                 aggregate 
               
               
                 Reports 
                 Administrator 
                 NDRs (e.g., rejected, bounced, blocked, 
                 server, sender 
                 numbers by type, 
               
               
                 (NDR&#39;s) 
                   
                 email error). 
                   
                 Charts for 
               
               
                   
                   
                 2. Detect and troubleshoot NDR 
                   
                 trending of NDRs 
               
               
                   
                   
                 issues with my messaging system, and 
                   
                 by type, Optimal: 
               
               
                   
                   
                 identify trends BIM 
                   
                 Pivot Viewer to 
               
               
                   
                   
                   
                   
                 slice- and-dice the 
               
               
                   
                   
                   
                   
                 data (which 
               
               
                   
                   
                   
                   
                 senders are 
               
               
                   
                   
                   
                   
                 generating NDR&#39;s, 
               
               
                   
                   
                   
                   
                 etc . . . to help you 
               
               
                   
                   
                   
                   
                 diagnose the 
               
               
                   
                   
                   
                   
                 problem) 
               
               
                 View List of 
                 Messaging 
                 1. Drill into the details of a message 
                 Date range, 
                 List of messages 
               
               
                 Messages 
                 Administrator, 
                 report to see a list of messages sent or 
                 mailbox, type of 
                 and corresponding 
               
               
                 Details of a 
                 Management 
                 received by a particular user. 
                 message (sent or 
                 details 
               
               
                 Message Stats 
                   
                 2. Perform light-weight auditing and 
                 received) 
                   
               
               
                 Report 
                   
                 forensics. 
                   
                   
               
               
                   
                   
                 3. Further understand the message 
                   
                   
               
               
                   
                   
                 report (e.g., what is the subject of 
                   
                   
               
               
                   
                   
                 messages going to a particular email 
                   
                   
               
               
                   
                   
                 domain). 
                   
                   
               
               
                 Ensure 
                 Messaging 
                 1. Understand who and how many 
                 “Network” 
                 Show me all 
               
               
                 Encrypted 
                 Administrator, 
                 encrypted messages are being sent on 
                 (identified by 
                 encrypted 
               
               
                 Message 
                 Management 
                 which network. 
                 domain, ip-subnet, 
                 messages that 
               
               
                 Usage 
                   
                 2. Track adherence to corporate 
                 ip-address). 
                 didn&#39;t meet the 
               
               
                   
                   
                 policy on encrypted message use. 
                 Recipient, date 
                 criteria. Volume 
               
               
                   
                   
                   
                 range. 
                 number + textual 
               
               
                   
                   
                   
                   
                 output of 
               
               
                   
                   
                   
                   
                 messages in 
               
               
                   
                   
                   
                   
                 violation 
               
               
                 Understand 
                 Messaging 
                 1. See aggregate number of messages 
                 Filter (DSN or 
                 Aggregate 
               
               
                 Connector 
                 Administrator 
                 and specific message-level details being 
                 NDR, External vs. 
                 message counts 
               
               
                 Capacity and 
                   
                 sent or received over a particular MTA, 
                 Internal), Date 
                 by connector 
               
               
                 Distribution 
                   
                 where MTA can be, for example, an 
                 time range, 
                 (chart), individual 
               
               
                   
                   
                 Exchange Server (2003 Front-End or 
                 Exchange Server 
                 message details 
               
               
                   
                   
                 2007 HUB Transport) or Exchange 
                 or Connector and 
                 (including client- 
               
               
                   
                   
                 HUB Receive Connector. 
                 Edge servers 
                 ip, client- 
               
               
                   
                   
                 2. Understand how busy the 
                   
                 hostname, server- 
               
               
                   
                   
                 connectors are and plan for over/under 
                   
                 ip, server- 
               
               
                   
                   
                 saturated connectors accordingly. 
                   
                 hostname, 
               
               
                   
                   
                 3. Report on which external 
                   
                 connector-id, 
               
               
                   
                   
                 peripheral mail servers and other 
                   
                 event-id, 
               
               
                   
                   
                 systems are sending messages over 
                   
                 recipient-address, 
               
               
                   
                   
                 which connectors. 
                   
                 total-bytes, 
               
               
                   
                   
                   
                   
                 recipient-count, 
               
               
                   
                   
                   
                   
                 sender-address, 
               
               
                   
                   
                   
                   
                 message-subject), 
               
               
                   
                   
                   
                   
                 Topology 
               
               
                   
                   
                   
                   
                 Visualization 
               
               
                 Troubleshoot 
                 Messaging 
                 1. See real-time message activity 
                 Exchange Server 
                 Aggregate 
               
               
                 Connector 
                 Administrator 
                 across connectors. 
                 or Connector and 
                 message counts 
               
               
                 Message Flow 
                   
                 2. Troubleshoot a message flow issue 
                 Edge servers, 
                 by connector 
               
               
                   
                   
                 which could be caused by either a 
                 inbound or 
                 (chart), individual 
               
               
                   
                   
                 connector issue or an external event  
                 outbound, domain 
                 message details 
               
               
                   
                   
                 (e.g. DOS attack, SPAM, looping  
                 or queue 
                 (including client- 
               
               
                   
                   
                 message). 
                 (associated with 
                 ip, client- 
               
               
                   
                   
                   
                 the connector). 
                 hostname, server- 
               
               
                   
                   
                   
                   
                 ip, server- 
               
               
                   
                   
                   
                   
                 hostname, 
               
               
                   
                   
                   
                   
                 connector-id, 
               
               
                   
                   
                   
                   
                 event-id, 
               
               
                   
                   
                   
                   
                 recipient-address, 
               
               
                   
                   
                   
                   
                 total-bytes, 
               
               
                   
                   
                   
                   
                 recipient-count, 
               
               
                   
                   
                   
                   
                 sender-address, 
               
               
                   
                   
                   
                   
                 message-subject), 
               
               
                   
                   
                   
                   
                 Topology 
               
               
                   
                   
                   
                   
                 Visualization 
               
               
                 Understand 
                 IT Manager, 
                 1. Compare usage across messaging 
                 Date time range, 
                 Aggregate 
               
               
                 User Client 
                 Messaging 
                 clients (Outlook/OWA/BlackBerry/ 
                 users, groups, 
                 numbers for users 
               
               
                 Usage 
                 Administrator, 
                 ActiveSync). 
                 devices 
                 and groups, 
               
               
                   
                 Executives 
                 Understand usage of desktop vs. mobile 
                   
                 Charting, 
               
               
                   
                   
                 and justify ROI where necessary, 
                   
                 Trending, 
               
               
                   
                   
                 possible risk mobile assessment usage. 
                   
                 Comparison 
               
               
                   
                   
                 2. Determine whether people are 
                   
                 across users and 
               
               
                   
                   
                 trending towards not using desktop 
                   
                 groups, Pivot 
               
               
                   
                   
                 computers. 
                   
                 Viewer 
               
               
                 Understand 
                 Messaging 
                 1. Understand mobile (e.g., 
                 Server End-points, 
                 Overall aggregate 
               
               
                 Mobile 
                 Administrator 
                 BlackBerry, ActiveSync) usage on my 
                 Date time range, 
                 numbers for end- 
               
               
                 Infrastructure 
                   
                 messaging infrastructure Perform 
                 devices 
                 point, Trending 
               
               
                 Usage 
                   
                 capacity planning for my mobile 
                   
                   
               
               
                   
                   
                 growth 
                   
                   
               
               
                 Understand 
                 Messaging 
                 1. Find all the messages that have 
                 Date time range, 
                 Charts, pivots of 
               
               
                 Usage of 
                 Administrator 
                 originated from specific end-user mail 
                 users, specific 
                 aggregate 
               
               
                 “Special” 
                   
                 clients or servers. 
                 message header 
                 numbers, 
               
               
                 Messages 
                   
                 2. Assess risks or determine usage. 
                 information 
                 aggregate trends, 
               
               
                 (using 
                   
                 Special messages generally have 
                   
                 List of messages 
               
               
                 message 
                   
                 particular metadata in the X-Headers 
                   
                 and details, 
               
               
                 headers) 
                   
                 such as mail classification. 
                   
                 message volumes 
               
               
                   
                   
                   
                   
                 grouped by header 
               
               
                   
                   
                   
                   
                 information. 
               
               
                 Search for 
                 Messaging 
                 1. Find all the messages that have 
                 Date time range, 
                 List of messages 
               
               
                 “Special 
                 Administrator 
                 particular message header criteria 
                 major header fields 
                 and details 
               
               
                 Messages” 
                   
                 2. Discover messages sent from non- 
                 (date/time, sender, 
                   
               
               
                 (customer 
                   
                 Exchange servers and flexible specific 
                 recipient(s), 
                   
               
               
                 defined) 
                   
                 message searches. 
                 subject, etc . . . ) 
                   
               
               
                 Alert on 
                 Messaging 
                 1. Learn about abnormal message 
                 Date time range, 
                 Notification 
               
               
                 Abnormal 
                 Administrator 
                 volumes for a user, server, connector, or 
                 server/queue, 
                   
               
               
                 Message 
                   
                 queue. 
                 connector, use 
                   
               
               
                 Volume 
                   
                 2, Be alerted of a potential problem 
                   
                   
               
               
                   
                   
                 and investigate (see next scenario). 
                   
                   
               
               
                 Investigate 
                 Messaging 
                 1. Investigate a period of abnormal 
                 Date time range, 
                 Topology, list of 
               
               
                 Abnormal 
                 Administrator 
                 message volume (could be on a user, 
                 target filter (server, 
                 messages with 
               
               
                 Message 
                   
                 server, connector, or a queue). 
                 queue, user, filter) 
                 details, message 
               
               
                 Volume 
                   
                 Determine if its spam being received or 
                   
                 volumes grouped 
               
               
                   
                   
                 sent or some other problem that needs to 
                   
                 by time 
               
               
                   
                   
                 be addressed. 
                   
                   
               
               
                 Investigate 
                 Messaging 
                 1. Investigate suspicious messages 
                 Date time range 
                 List of messages 
               
               
                 Potential Spam 
                 Administrator 
                 being sent from within my organization 
                   
                 and message 
               
               
                 Messages 
                   
                 (open relay or spoofed header). Are 
                   
                 details, 
               
               
                 Originating 
                   
                 messages being sent with open relays 
                   
                 server/relay 
               
               
                 from my 
                   
                 within my organization? 
                   
                 involved, client 
               
               
                 Organization 
                   
                 2. Stop abusive behavior by users. 
                   
                 IPs 
               
               
                 View Internal 
                 IT Manager, 
                 1. Understand the load distribution of 
                 Infrastructure 
                 Topological 
               
               
                 Infrastructure 
                 Messaging 
                 my internal messaging infrastructure 
                 components (user 
                 View, Charts for 
               
               
                 Distribution 
                 Administrator 
                 components (servers, stores, 
                 defined), date 
                 trending of 
               
               
                   
                   
                 connectors). Budget for growth 
                 range 
                 messages load 
               
               
                   
                   
                 accordingly and optimize performance. 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
               
               
               
             
               
                 TABLE 4 
               
               
                   
               
               
                   
                 USER 
                   
                   
                   
               
               
                 USE CASE 
                 PERSONA 
                 POTENTIAL OBJECTIVE(S) 
                 INPUT 
                 OUTPUT 
               
               
                   
               
             
            
               
                 Understand 
                 Manager 
                 1. Track average and maximum 
                 List of mailboxes, 
                 Trending with 
               
               
                 User Response 
                   
                 response times of members of my 
                 AD groups, filters 
                 charts with 
               
               
                 Times 
                   
                 department (or another group) to 
                 (such as types of 
                 overall or 
               
               
                   
                   
                 “customer” messages overtime. 
                 messages, internal 
                 individual 
               
               
                   
                   
                 2. Track compliance against my 
                 vs. external, 
                 response times, 
               
               
                   
                   
                 customer SLA&#39;s. 
                 recipient 
                 list of messages 
               
               
                   
                   
                 3. Identify areas for improvement 
                 domains), date 
                 (including 
               
               
                   
                   
                 and measure performance. 
                 range 
                 message level 
               
               
                   
                   
                   
                   
                 details), Pivot 
               
               
                   
                   
                   
                   
                 Table to explore 
               
               
                 Investigate 
                 Manager, 
                 1. Review all communications 
                 Target user, types 
                 Details of all 
               
               
                 Employee 
                 Messaging 
                 between one of my employees and 
                 of messages to 
                 communications 
               
               
                 Communications 
                 Administrator 
                 another user or domain Respond to a 
                 include/exclude, 
                 by my employee 
               
               
                   
                   
                 complaint or review the usage of my 
                 date range 
                 (list of messages 
               
               
                   
                   
                 employee for HR purposes 
                   
                 and the ability to 
               
               
                   
                   
                   
                   
                 access message 
               
               
                   
                   
                   
                   
                 level details) 
               
               
                 Measure User 
                 Manager 
                 1. Track and compare the 
                 List of mailboxes 
                 Productivity 
               
               
                 Productivity 
                   
                 productivity profiles (volume of 
                 or AD groups, a 
                 report (message 
               
               
                   
                   
                 messages sent and received and the 
                 selected group of 
                 volumes and 
               
               
                   
                   
                 response times) of my employees and 
                 employees that 
                 response times) 
               
               
                   
                   
                 groups of employees. 
                 can be compared 
                 and trending, 
               
               
                   
                   
                 2. Gain insight into my employees&#39; 
                   
                 statistics such as 
               
               
                   
                   
                 time and performance as it pertains to 
                   
                 averages, pivot 
               
               
                   
                   
                 messaging usage. 
                   
                 for exploring 
               
               
                   
                   
                 3. Compare productivity from a 
                   
                   
               
               
                   
                   
                 messaging perspective of users within 
                   
                   
               
               
                   
                   
                 a group. 
                   
                   
               
               
                   
                   
                 Identify areas for improvement. 
                   
                   
               
               
                 Track After- 
                 Manager, 
                 1. Regularly review a list of 
                 Customer 
                 Text - list of 
               
               
                 Hours 
                 Administrator 
                 messages that arrive during a certain 
                 Definition of 
                 messages (with 
               
               
                 Communications 
                   
                 time of day. 
                 ‘Time of Day’, 
                 details), volume 
               
               
                   
                   
                 2. Bill my customers extra for 
                 Senders, 
                 report, ability 
               
               
                   
                   
                 after-hours support. 
                 recipients, 
                 export 
               
               
                   
                   
                 3. Audit the usage of the messaging 
                 message date 
                   
               
               
                   
                   
                 system after hours. 
                 range, time of day 
                   
               
               
                   
                   
                 4. Look at my messaging load 
                 range, message 
                   
               
               
                   
                   
                 during a specific time of day. 
                 filter defining 
                   
               
               
                   
                   
                   
                 what types 
                   
               
               
                   
                   
                   
                 messages to 
                   
               
               
                   
                   
                   
                 include (i.e. don&#39;t 
                   
               
               
                   
                   
                   
                 include SPAM 
                   
               
               
                   
                   
                   
                 messages) 
                   
               
               
                 Track Outlook 
                 Manager 
                 Report on user Outlook Category and 
                 Recipients, 
                 Aggregate ratios, 
               
               
                 Categorization 
                   
                 Flag usage. 
                 Category and/or 
                 Charts to trend of 
               
               
                 &amp; Flag 
                   
                 Measure adherence to business or 
                 Flag, Date Range, 
                 overall or 
               
               
                   
                   
                 workflow processes and directives. 
                 Message Filter 
                 individual 
               
               
                   
                   
                   
                 (type of messages 
                 Outlook category 
               
               
                   
                   
                   
                 to include) 
                 usage, trend 
               
               
                   
                   
                   
                   
                 individual 
               
               
                   
                   
                   
                   
                 Categories, 
               
               
                   
                   
                   
                   
                 ability to drill 
               
               
                   
                   
                   
                   
                 into individual 
               
               
                   
                   
                   
                   
                 messages, Pivot 
               
               
                   
                   
                   
                   
                 Table to explore 
               
               
                   
                   
                   
                   
                 the categories use 
               
               
                   
                   
                   
                   
                 among groups 
               
               
                   
                   
                   
                   
                 and individuals. 
               
               
                 Track User 
                   
                 1. Track by status of tasks (usage 
                   
                   
               
               
                 Outlook 
                   
                 number per each status available). 
                   
                   
               
               
                 Actions 
                   
                 2. Track task of attaching pictures, 
                   
                   
               
               
                   
                   
                 images and attachments to a task in 
                   
                   
               
               
                   
                   
                 Outlook. 
                   
                   
               
               
                   
                   
                 3. Track by address types and 
                   
                   
               
               
                   
                   
                 phone types (usage number per each 
                   
                   
               
               
                   
                   
                 address/phone type. 
                   
                   
               
               
                   
                   
                 4. Track Untimed tasks in Outlook 
                   
                   
               
               
                   
                   
                 (e.g., where start date and due date is 
                   
                   
               
               
                   
                   
                 equal to none. 
                   
                   
               
               
                   
                   
                 5. Determine average activities and 
                   
                   
               
               
                   
                   
                 tasks created per day. 
                   
                   
               
               
                   
                   
                 6. Ascertain the current usage of 
                   
                   
               
               
                   
                   
                 notes in Outlook. For example, can we 
                   
                   
               
               
                   
                   
                 get examples of what people are 
                   
                   
               
               
                   
                   
                 putting 
                   
                   
               
               
                   
                   
                 in the notes section? 
                   
                   
               
               
                   
                   
                 7. Track the journal capability 
                   
                   
               
               
                   
                   
                 attached to contacts in Outlook. Is 
                   
                   
               
               
                   
                   
                 anyone using this? Can we get 
                   
                   
               
               
                   
                   
                 examples of 
                   
                   
               
               
                   
                   
                 this? 
                   
                   
               
               
                 Audit 
                 Manager 
                 1. Check if a particular type of 
                 Type of message 
                 List of messages 
               
               
                 Adherence to 
                   
                 message (TBD by the customer) is 
                 (i.e. class 
                 (daily/weekly 
               
               
                 Message 
                   
                 being sent to the appropriate people as 
                 definition, e.g. 
                 reports), list of 
               
               
                 Addressing 
                   
                 per a predefined 
                 subject string 
                 non-compliant 
               
               
                 Rules 
                   
                 business process 
                 identifier), 
                 users, aggregate 
               
               
                   
                   
                 2. Track adherence to company 
                 recipient, 
                 volume 
               
               
                   
                   
                 policy 
                 recipient 
                   
               
               
                   
                   
                   
                 addressing type 
                   
               
               
                   
                   
                   
                 (BCC, CC), 
                   
               
               
                   
                   
                   
                 sender, date range 
                   
               
               
                   
                   
                   
                 List of messages 
                   
               
               
                   
                   
                   
                 (daily/weekly 
                   
               
               
                   
                   
                   
                 reports), list of 
                   
               
               
                   
                   
                   
                 non-compliant 
                   
               
               
                   
                   
                   
                 users, aggregate 
                   
               
               
                   
                   
                   
                 volume 
                   
               
               
                 View 
                 Manager, 
                 1. View the distribution of 
                 Recipients, 
                 Charts for trend 
               
               
                 Customer, 
                 Executive 
                 messages for specified recipients and 
                 sender, date 
                 of messages 
               
               
                 Partner and 
                   
                 external domains over a given period. 
                 range, defined 
                 volume (all or 
               
               
                 Competitive 
                   
                 2. Understand my communications 
                 recipient groups 
                 top 10), 
               
               
                 Communications 
                   
                 with Customers, Partners, and 
                 and/or external 
                 messages from 
               
               
                 (Distribution &amp; 
                   
                 Competitors. For example, determine 
                 domains 
                 pre-defined 
               
               
                 Trends) 
                   
                 who is my 
                   
                 group, group by 
               
               
                   
                   
                 business talking to and why. 
                   
                 recipients or 
               
               
                   
                   
                 3. Understand the relationship with 
                   
                 domains, Pivot 
               
               
                   
                   
                 your customers, partners, and 
                   
                 Viewer for 
               
               
                   
                   
                 competitors. 
                   
                 exploring the 
               
               
                   
                   
                   
                   
                 data. 
               
               
                 Audit 
                 Manager, 
                 1. View message details of 
                 Recipients, 
                 Message List and 
               
               
                 Customer, 
                 Executive 
                 communication with a specific 
                 sender, date 
                 Details 
               
               
                 Partner or 
                   
                 partner, customer, or competitor 
                 range, defined 
                   
               
               
                 Competitive 
                   
                 2. Audit or understand my 
                 recipient groups 
                   
               
               
                 Communications 
                   
                 company&#39;s communication on a 
                 and/or external 
                   
               
               
                   
                   
                 particular partner, customer, or 
                 domains 
                   
               
               
                   
                   
                 competitor event or issue. 
                   
                   
               
               
                 Understand 
                 Management, 
                 1. Understand the distribution of 
                 Personal 
                 Charts for trend 
               
               
                 Personal 
                 Messaging 
                 messages going to and from personal 
                 messaging system 
                 of messages 
               
               
                 Messaging 
                 Administrator 
                 messaging systems such as Yahoo!, 
                 (as defined by the 
                 volume (all or 
               
               
                 System Use 
                   
                 Hotmail, and Gmail. 
                 user), recipients, 
                 top 10), 
               
               
                   
                   
                 2. Measure employee productivity 
                 sender, date 
                 messages from 
               
               
                   
                   
                 and gauge use and misuse of the 
                 range, defined 
                 pre-defined 
               
               
                   
                   
                 corporate messaging system. 
                 recipient groups 
                 group, group by 
               
               
                   
                   
                 3. Identify usage trends. 
                 and/or external 
                 recipients or 
               
               
                   
                   
                   
                 domains 
                 domains, Pivot 
               
               
                   
                   
                   
                   
                 Viewer to find 
               
               
                   
                   
                   
                   
                 out top personal 
               
               
                   
                   
                   
                   
                 messaging 
               
               
                   
                   
                   
                   
                 users/groups, etc. 
               
               
                 View Relayed 
                 Management 
                 1. As a messaging provider, 
                 Message type 
                 Charts for 
               
               
                 Traffic 
                   
                 understand volumes of re-routed 
                 (filter of messages 
                 trending 
               
               
                   
                   
                 messages. 
                 to include), Date 
                 aggregate 
               
               
                   
                   
                 2. Understand how my messaging 
                 range 
                 volume 
               
               
                   
                   
                 business is performing. 
                   
                   
               
               
                 Understand 
                 Manager 
                 1. View communication trends 
                 Target Users and 
                 Charts for 
               
               
                 Communication 
                   
                 between users and groups in my 
                 Groups, date 
                 trending of 
               
               
                 Patterns in 
                   
                 organization; includes multiple 
                 range, Message 
                 messages 
               
               
                 my 
                   
                 communication platforms. 2. 
                 Type Filter 
                 volume, 
               
               
                 Organization 
                   
                 Compare the number of 
                   
                 Topological 
               
               
                   
                   
                 messages sent to a particular users, 
                   
                 Views, Pivot 
               
               
                   
                   
                 divided by TO:, CC:, BCC: 
                   
                 View 
               
               
                   
                   
                 3. Understand how my business is 
                   
                   
               
               
                   
                   
                 operating (e.g. what “silo groups” 
                   
                   
               
               
                   
                   
                 exist, which groups are talking to  
                   
                   
               
               
                   
                   
                 most to each other). 
                   
                   
               
               
                   
                   
                 4. Understand how my business is 
                   
                   
               
               
                   
                   
                 adhering to corporate directives. 
                   
                   
               
               
                 Understand the 
                 Management, 
                 1. Trend and see the use of 
                 Message Type 
                 Charts for trends 
               
               
                 Usage of 
                 IT Manager 
                 different types of messages in my 
                 (user defined), 
                 of different types 
               
               
                 Different 
                   
                 messaging system. 
                 Date range 
                 of messages, 
               
               
                 Types of 
                   
                 2. Determine the ratio of internal 
                   
                 Pivot Viewer 
               
               
                 Messages 
                   
                 vs. external communication. 
                   
                   
               
               
                   
                   
                 3. Get insight into specific business 
                   
                   
               
               
                   
                   
                 usage of my messaging system. 
                   
                   
               
               
                 Assess Mobile 
                 Management 
                 1. See what messages were stored 
                 Date range, 
                 List of message 
               
               
                 Data Leakage 
                   
                 or sent from a mobile device. 
                 inbound/outbound, 
                 and message 
               
               
                 Risk 
                   
                 2. Perform a mobile device data 
                 message type 
                 details. Charts 
               
               
                   
                   
                 leakage audit. 
                 (sender, recipient, 
                 for mobile 
               
               
                   
                   
                   
                 etc . . . , “mobile  
                 message usage 
               
               
                   
                   
                   
                 message” is 
                   
               
               
                   
                   
                   
                 inherent) 
                   
               
               
                 Track Implicit 
                 IT Manager, 
                 1. Track the percentage of 
                 Message subject, 
                 Distribution of 
               
               
                 Acknowledge- 
                 Management 
                 employees that have received and read 
                 sender 
                 message status 
               
               
                 ment of 
                   
                 an important message. 
                   
                 (received, read, 
               
               
                 Important 
                   
                 2. Report to HR or legal the 
                   
                 deleted without 
               
               
                 Message 
                   
                 progress and completion of the 
                   
                 being read), with 
               
               
                   
                   
                 distribution of the message. 
                   
                 the option of 
               
               
                   
                   
                   
                   
                 detailed list of 
               
               
                   
                   
                   
                   
                 status per people 
               
               
                 Track 
                 HR Manager, 
                 1. Track the distribution path of a 
                 Message subject, 
                 Full message 
               
               
                 Sensitive 
                 IT Manager, 
                 sensitive message. 
                 sender, date time 
                 delivery path 
               
               
                 Message 
                 Management 
                 2. Audit unauthorized distribution 
                 range, type 
                 (people &amp; 
               
               
                 Leakage 
                   
                 of sensitive information, 
                 (FWD, etc.) 
                 endpoint) of the 
               
               
                   
                   
                   
                   
                 message 
               
               
                   
                   
                   
                   
                 forwarding and 
               
               
                   
                   
                   
                   
                 delivery, and 
               
               
                   
                   
                   
                   
                 actions taken by 
               
               
                   
                   
                   
                   
                 users 
               
               
                 Analyze Usage 
                 Messaging 
                 1. Understand who, and how many 
                 Recipient(s), date 
                 Count/ratio of 
               
               
                 of Encrypted 
                 Administrator, 
                 encrypted messages are being sent 
                 range 
                 encrypted 
               
               
                 Message 
                 Management 
                 2. Ensure that the correct format is 
                   
                 messages, 
               
               
                   
                   
                 being used on my classified/non- 
                   
                 message-detail 
               
               
                   
                   
                 classified networks 
                   
                 on encrypted 
               
               
                   
                   
                   
                   
                 messages. 
               
               
                   
               
            
           
         
       
     
                                     TABLE 5                   USER                   USE CASE   PERSONA   POTENTIAL OBJECTIVE(S)   INPUT   OUTPUT                  Track CAN-   IT Manager,   1. Alert or report whenever external   Configure report   Alert (email       SPAM   Management   messages are sent with potentially   (domain and other   notification,       Message       false header information (for example,   routing   dashboard).       Header       From, To, Reply To or other routing   specifications)   Report (sender,       Compliance       information that doesn&#39;t match       recipient, # of               corporate domains or other server       recipients,               configurations).       message               2. Ensure that my company is       contents)               adhering to CAN-SPAM requirements               Track CAN-   IT Manager,   1. Alert or report whenever external   Configure report   Alert (email       SPAM   Management   messages are sent without obligatory   (enter “static”   notification,       Message       information (Physical postal address,   search strings)   dashboard),       Content       disclosure that message is an ad,       Report (sender,       Omissions       information on opting out of mailing       recipient,               list).       message               2. Ensure that my company is       contents, which               adhering to CAN-SPAM       string(s) missing)               requirements.               Audit CAN-   IT Manager,   1. Ensure that a 3rd party   Domains, routing   Report (sender,       SPAM   Management   contractor who&#39;s sending marketing   info, required   recipient,       Compliance       messages on my (ensure verified   strings   message       for 3rd Party       header information and required       contents, which       Mailers       content strings).       string(s) missing)               2. Ensure that my company is                       adhering to CAN-SPAM                       requirements.               Monitor   IT Manager,   1. Alert or report whenever   Configure report   Alert (email       Outgoing/In-   Management   outgoing or incoming messages are   (specify likely   notification,       coming Messages       sent containing unauthorized personal   string formats)   dashboard),       for Credit Card       data (such as CC numbers).       Report (sender,       #s (PCI-DSS)       2. Ensure adherence to PCI-DSS       recipient, flagged               requirements.       string, report/                       allow)       Monitor   IT Manager,   1. Alert or report whenever   Configure report   Alert (email       Routing of   Management   outgoing or incoming messages are   (specify identity   notification,       Sensitive       sent containing specific corporate   strings)   dashboard),       Information       information not intended for       Report (sender,               distribution (Financial disclosures,       recipient, flagged               trade secrets, IPR).       string)               2. Ensure adherence to the                       USAPATRIOT requirements.               Monitor   IT Manager,   1. Audit the messaging   Report criteria,   Executive/       Overall   Management   infrastructure for the purpose of   specify network   Detailed Report       Messaging       general risk-management and   components,   for risk areas,       Environment       mitigation against system health   compliance   overall risk       to Identify       Identify failures, threats, intrusions,   benchmarks   benchmark,       Potential       viruses, or other vulnerabilities that       export       Vulnerabilities       may impact confidence in the integrity                       of the system.                       2. Perform regular assessments of                       risk will assist in meeting corporate                       commitments for Sarbanes-Oxley/                       Gramm-Leach-Billey, Basel, etc.                    
II. Data Loss Prevention
 
     In various embodiments, many of the principles described above can be further leveraged to facilitate data loss prevention (DLP). In a typical embodiment, a cross-platform DLP system as described herein enables utilization of cross-platform DLP policies. For purposes of this patent application, a DLP policy refers to a standard or guideline designed, at least in part, to prevent, detect, or mitigate data loss. By way of example, DLP policies can restrict a number or size of communications, participants in communications, contents of communications, particular communication patterns, etc. 
     For purposes of this patent application, a cross platform DLP policy refers to a DLP policy that can be enforced, monitored, and/or applied across multiple heterogeneous communications platforms. In many cases, the heterogeneous communications platforms may provide a certain degree of native DLP functionality. In other cases, some or all of the heterogeneous platforms may provide no native DLP functionality. To the extent native DLP functionality is provided, the heterogeneous communications platforms generally use an assortment of non-standard data structures and formats to contain a DLP policy. 
       FIG. 11  illustrates an embodiment of an implementation of a system  1100  for performing DLP. The system  1100  includes the BIM system  130 , the internal data sources  120 , the intranet  104 , the network  106 , and the external data sources  122 . In a typical embodiment, the BIM system  130 , the internal data sources  120 , the intranet  104 , the network  106 , and the external data sources  122  operate as described above with respect to  FIGS. 1-2 . The system  1100  additionally includes a cross-platform DLP system  1146 . 
     In general, each of the internal data sources  120  and each of the external data sources  122  can be considered a distinct communications platform that is internal and external, respectively. The cross-platform DLP system  1146  communicates with the internal data sources  120  over the intranet  104  and with the external data sources  122  over the network  106 . In certain embodiments, the cross-platform DLP system  1146  is operable to interact with the BIM system  130  over either the intranet  104  or the network  106  as illustrated. In certain other embodiments, the cross-platform DLP system  1146  can be contained within the BIM system  130  such that no communication over the intranet  104  or the network  106  needs to occur. In general, the cross-platform DLP system  1146  collaborates with the BIM system  130 , the internal data sources  120 , and the external data sources  122  to implement cross-platform DLP policies. An example of the cross-platform DLP system  1146  will be described in greater detail with respect to  FIG. 12 . 
       FIG. 12  illustrates an embodiment of an implementation of the cross-platform DLP system  1146 . The cross-platform DLP system  1146  includes a DLP detection engine  1248  and a DLP management console  1260 . The DLP detection engine  1248  typically performs operations that create and/or activate cross-platform DLP policies. The DLP detection engine  1248  can also monitor communications to identify violations of those cross-platform DLP policies. In a typical embodiments, the DLP management console  1260  performs operations that report and/or enforce cross-platform DLP policies responsive, for example, to violations detected by the DLP detection engine  1248 . 
     As part of performing their respective functionality, the DLP detection engine  1248  and the DLP management console  1260  are operable to communicate with communications platforms  1276 . The communications platforms  1276 , in general, are representative of the internal data sources  120  and the external data sources  122  as illustrated in  FIG. 11 . For ease of illustration and description, the internal data sources  120  and the external data sources  122  are shown collectively as the communications platforms  1276 . 
     In the illustrated embodiment, the communications platforms  1276  include an application programming interface (API) A  1274   a , an API B  1274   b , and an API C  1274   c  (collectively, APIs  1274 ). The APIs  1274  may each be considered a logical encapsulation of functions and operations provided by a distinct communications platform of the communications platforms  1276 . In many cases, it may be that such functions and operations are not exposed by each of the communications platforms  1276  via a common API but rather via a plurality of native APIs and/or access interfaces. It should be appreciated that some or all of the communications platforms may not provide any API. Likewise, although the APIs  1274  are shown for illustrative purposes, it should be appreciated that the communications platforms  1276  can include any number of APIs and any number of communications platforms. 
     Each of the APIs  1274  provides an interface to native DLP support provided by a given communications platform of the communications platforms  1276 . Examples of native DLP support that can be provided by the given communications platform include specifying a native DLP policy in a structure and format understood by that communications platform, activating a native DLP policy, implementing enforcement actions allowed by that communications platform (e.g., placing restrictions on a user or group of users), and/or the like. It should be appreciated that the APIs  1274  may not provide homogenous functionality. For example, the API A  1274   a  might permit certain enforcement actions but might not include any functionality for specifying and/or activating native DLP policies. Continuing this example, the API B  1274   b  might include all such functionality. By way of further example, different APIs of the APIs  1274  may enable different enforcement actions and/or specification or selection of different types of native DLP policies. 
     In a typical embodiment, the cross-platform DLP system  1146  enables a common interface into the APIs  1274  via a platform adaptor A  1272   a , a platform adaptor B  1272   b , and a platform adaptor C  1272   c  (collectively, platform adaptors  1272 ). In similar fashion to the APIs  1274 , the number of platform adaptors  1272  is illustrative in nature. Each of the platform adaptors  1272  typically maps a standard set of functionality to corresponding sets of calls to the APIs  1274 . In that way, the platform adaptors  1272  can be collectively considered a standard API that is operable to be called, for example, by components of the DLP detection engine  1248  and the DLP management console  1260 . The standard API of the platform adaptors  1272  can include, for example, functions that specify a native DLP policy on a given communications platform, functions that activate a native DLP policy, functions that implement specific enforcement actions, etc. By way of example, the platform adaptor A  1272   a  can map each call of the standard API to a corresponding API call on the API A  1274   a  to the extent such a corresponding API call exists. The platform adaptor A  1272   a  can include, for example, a capabilities call that results in all capabilities of the API A  1274   a  being returned. The capabilities can include, for example, features of the standard API that the API A  1274   a  supports. The platform adaptor B  1272   b  and the platform adaptor C  1272   c  can be similarly configured relative to the API B  1274   b  and the API C  1274   c , respectively. 
     In the illustrated embodiment, the DLP detection engine  1248  includes a native DLP detector  1250 , a policy abstraction module  1252 , a custom DLP detector  1254 , a DLP risk profiler  1256 , and a DLP context module  1258 . The policy abstraction module  1252  provides an interface for an appropriate user such as, for example, an administrator, to create and/or activate cross-platform DLP policies. The policy abstraction module  1252  typically creates the cross-platform DLP policies in a standardized policy format. The standardized policy format can generally be any format for specifying rules and/or Boolean conditions. In some cases, the standardized policy format may correspond to a format natively supported by one or more of the communications platforms  1276 . In a typical embodiment, how the cross-platform DLP policies are activated on the communications platforms  1276  can depend on, among other things, an extent to which each of the communications platforms  1276  provides DLP support, administrator preference, etc. 
     In many cases, some or all of the communications platforms  1276  may provide at least some native DLP support. In these cases, if it is desired to activate a given cross-platform DLP policy natively on the communications platforms  1276 , the policy abstraction module  1252  can provide the given cross-platform DLP policy in a corresponding call to the platform adaptors  1272 . In a typical embodiment, the platform adaptors  1272  are operable to receive the given cross-platform DLP policy in the standardized policy format and re-specify it in a respective native format expected by each of the communications platforms  1276 , for example, by translating the given cross-platform DLP policy from the standardized policy format to the respective native format. In some cases, some of the communications platforms  1276  may have a pre-existing native DLP policy that is deemed equivalent to a given cross-platform DLP policy. In these cases, no new native DLP policy usually needs to be specified. Rather, a corresponding platform adaptor of the platform adaptors  1272  can maintain a mapping to the equivalent native DLP policy. Once the given cross-platform DLP policy has been created and/or natively activated, as appropriate, the native DLP detector  1250  can perform DLP detection. Operation of the native DLP detector  1250  will be described in greater detail below. 
     As mentioned above, some or all of the communications platforms  1276  may either provide no DLP support or provide DLP support that is insufficient in some respect for natively activating the given cross-platform DLP policy. In addition, even if sufficient DLP support is provided by the communications platforms  1276 , it may otherwise be desirable by the administrator for the cross-platform DLP system  1146  to centrally activate the given cross-platform DLP policy for a particular set of communications platforms of the communications platforms  1276 . Central activation typically means that, as to the particular set of communications platforms, violation detection is performed centrally by the cross-platform DLP system  1146  without relying on native DLP functionality, if any, of the particular set of communications platforms. Under these circumstances, the policy abstraction module  1252  can provide the given cross-platform DLP policy to the custom DLP detector  1254  for storage and implementation. The custom DLP detector  1254  will be described in greater detail below. 
     In a typical embodiment, the policy abstraction module  1252  centrally maintains all cross-platform DLP policies, for example, in a database, persistent file-based storage, and/or the like. In some cases, all cross-platform DLP policies can be maintained on the BIM system  130 , for example, in one or more of the databases  232 . In addition, the policy abstraction module  1252  generally tracks how each cross-platform DLP policy is activated on each of the communications platforms  1276 . As described above, cross-platform DLP policies can be activated natively on the communications platforms  1276 , centrally activated by the cross-platform DLP system  1146 , and/or a combination thereof. The manner of activation can be maintained by the policy abstraction module  1252  as part of its tracking functionality. 
     The native DLP detector  1250  typically manages violation detection for native activations of cross-platform DLP policies. In a typical embodiment, the native DLP detector  1250  can import violations of native DLP policies, for example, from logs that are generated by such platforms. In some cases, the logs can be accessed via, for example, the platform adaptors  1272  and the APIs  1274 . In other cases, it may be possible to access such logs without the platform adaptors  1272  and/or the APIs  1274  if, for example, a network storage location of the logs is known. 
     The custom DLP detector  1254  typically manages violation detection for central activations of cross-platform DLP policies. In a typical embodiment, the custom DLP detector  1254  centrally performs violation detection on communications centrally collected and stored by the BIM system  130  as described above. In this fashion, with respect to the central activations, the cross-platform DLP policy can be applied and evaluated against such communications for purposes of identifying violations. 
     The DLP risk profiler  1256  is operable to identify quasi-violations, assess risk of cross-platform DLP policies being violated and/or quasi-violated, and/or the like. A quasi-violation, as used herein, refers to user activity or behavior that does not literally violate a given policy but that is measurably and configurably close to doing so. An actual violation, as used herein, refers to user activity or behavior that literally violates a given policy. For purposes of this disclosure, the term violation can encompass both actual violations and quasi-violations. What constitutes measurably close can be empirically defined, for example, via statistical, mathematical, and/or rule-based methods. 
     For instance, a particular cross-platform DLP policy could prohibit sending files (e.g., email attachments) that are larger than a maximum size (e.g., ten megabytes). According to this example, measurably close could be empirically defined as being within a certain percentage of the maximum size (e.g., five percent), being within a certain numeric range relative to the maximum size (e.g., greater than nine megabytes but less than ten megabytes), etc. Measurably close could be further defined to include a repetition factor. For example, quasi-violations could be limited to cases where a given user has met the above-described empirical definition at least a specified number of times (e.g., five) within a specified window of time (e.g., one hour, one day, one week, etc.). Quasi-violations could also be limited to such cases where a number of times that the user has sent such files is within a certain number of standard deviations of an expected value for the specified window of time. It should be appreciated that similar principles could be applied to automatically identify quasi-violations for other types of cross-platform DLP policies that specify, for example, values and/or thresholds. 
     In various embodiments, the DLP risk profiler  1256  can also trigger a quasi-violation based on, for example, an assessment that a cross-platform DLP policy is in imminent risk of being violated. For example, certain DLP policies may relate to values that tend to increase over time or that exhibit a pattern (e.g., linear or exponential). For example, a given policy could limit each user to a certain quantity of instant messages per day (e.g., 100). If it appears that a particular user is projected to reach the certain quantity (e.g., based on a linear trend) or is within a defined range of the certain quantity (e.g., ninety-five instant messages before 2:00 pm local time), a quasi-violation could be triggered. A quasi-violation could also be triggered if, for example, a characteristic precursor to an actual violation has been detected. For example, a particular cross-platform DLP policy could specify that communications to customer A cannot occur via email. In that case, a characteristic precursor to an actual violation could be the appearance in a user&#39;s email contacts of an email address specifying Customer A&#39;s domain (e.g., example.com). 
     In various embodiments, the DLP risk profiler  1256  can also be utilized for on-demand risk assessment. For example, designated users (as described further below), administrators, and/or the like can use the DLP risk profiler  1256  to perform a risk query. In various embodiments, the risk query can be equivalent to a cross-platform DLP policy. For example, the risk query can be embody a prospective cross-platform DLP policy. An administrator, for example, could use the risk query to search communications collected by the BIM system  130  to determine a business impact of implementing the cross-platform DLP policy. The risk query is typically tailored to identify information related to the business impact. After execution of the risk query, the information is returned to the administrator. Based on the information returned by the risk query, the administrator could determine, inter alia, a volume of users exhibiting behaviors prohibited by the prospective cross-platform DLP policy, an overall number of past communications within a certain period of time that would have been implicated by the prospective cross-platform DLP policy, which departments or organizational units would be most impacted by the prospective cross-platform DLP policy, etc. 
     The DLP context module  1258  is operable to dynamically acquire context information responsive, for example, to a detected violation. In various embodiments, what constitutes context information for a violation of a given cross-platform DLP policy can be pre-defined as a query package as described above. Responsive to a violation of the given cross-platform DLP policy, the query package can be executed to yield the context information. An example of defining and executing a query package will be described in greater detail with respect to  FIGS. 14 and 16 . Also, in some embodiments, all or part of what constitutes context information can be specified, for example, by designated users upon receipt of an alert. In these embodiments, the designated users can request particular data points that are of interest given the contents of the alert. It should be appreciated that the context information can be acquired from any of the communications platforms  1276 . For example, if a user were to violate the cross-platform DLP policy on an email platform, the context information could include information related to the user&#39;s contemporaneous communications on each of an instant-messaging platform, an enterprise social-networking platform, and/or any of the communications platforms  1276 . 
     The DLP management console  1260  includes a user permission manager  1262 , a reporting module  1264 , and a credentials module  1270 . In a typical embodiment, the user permission manager  1262  maintains an access profile for each user of the cross-platform DLP system  1146 . The access profile can be created based on, for example, directory information (e.g., Active Directory). In some embodiments, the access profile can be created by an administrator. 
     The access profile typically specifies a scope of violations that the user is authorized to view and/or for which the user should receive alerts or reports (e.g., all staff, all employees beneath the user in an employee hierarchy, etc.). The access profile also typically specifies enforcement actions that the user is allowed to take if, for example, DLP violations have occurred. In some cases, the user&#39;s ability to take the enforcement action may be conditioned on violation(s) having occurred. In other cases, some or all of the enforcement actions may be available to the user unconditionally. For purposes of this disclosure, a given user may be considered a designated user with respect to those cross-platform DLP policies for which the given user is authorized to view violations, receive reports or alerts on violations, and/or take enforcement actions. 
     The reporting module  1264  provides an interface to display to designated users information pertaining to violations of cross-platform DLP policies and any context information. In various embodiments, the reporting module  1264  is operable to initiate alerts or present reports using, for example, any of the communications platforms  1276 . The reports and/or alerts can be presented using, for example, SMS text message, email, instant message, a dashboard interface, social media messages, web pages, etc. The reporting module  1264  can also provide via, for example, a dashboard interface, any enforcement actions that each designated user is authorized to take. The enforcement actions can include, for example, blocking particular domains (e.g., example.com), suspending a user account on all or selected ones of the communications platforms  1276 , blocking sending communications, blocking receiving communications, and/or the like. In some embodiments, the enforcement actions, can include a “kill” option that suspends a user or group of users&#39; access to all of the communications platforms  1276 . 
     The credentials module  1270  typically stores administrative credentials for accessing each of the communications platforms  1276  via, for example, the APIs  1274 . In various embodiments, the credentials module  1270  enables designated users to execute administrative actions (e.g., enforcement actions) that the designated users would ordinarily lack permission to perform, thereby saving time and resources of administrators. The user permission manager  1262  can determine, via access profiles, enforcement actions that the designated users are authorized to perform. Responsive to selections by the designated users, the credentials module  1270  can execute those enforcement actions on the communications platforms  1276  using the stored administrative credentials. 
       FIG. 13  presents a flowchart of an example of a process  1300  for cross-platform DLP implementation. The process  1300  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  1300 , in whole or in part, can be implemented by one or more of the BIM system  130 , the DLP detection engine  1248 , the DLP management console  1260 , and/or components thereof. Although any number of systems, in whole or in part, can implement the process  1300 , to simplify discussion, the process  1300  will be described in relation to specific systems or subsystems of the system  1100  of  FIG. 11  and/or the cross-platform DLP system  1146 . For illustrative purposes, the process  1300  will be described with respect to a single cross-platform DLP policy. However, it should be appreciated that the process  1300  can be repeated relative to numerous cross-platform DLP policies that will be maintained by the cross-platform DLP system  1146 . 
     At block  1302 , the DLP detection engine  1248  activates a cross-platform DLP policy on a set of communications platforms of the communications platforms  1276  for enforcement against a set of users (e.g., a user or group of users). In typical embodiment, the block  1302  includes the policy abstraction module  1252  interacting with an administrator to select and/or create the cross-platform DLP policy, select the set of users, and choose the set of communications platforms. In some cases, the set of communications platforms may include only one of the communications platforms  1276 . As described above, relative to the set of communications platforms, the cross-platform DLP policy can be centrally activated, natively activated, or a combination thereof. In the case of native activation, the cross-platform DLP policy can include initiating a native DLP policy on one or more of the set of communications platforms. An example of how the cross-platform DLP policy can be created will be described with respect to  FIG. 14 . 
     At block  1304 , the DLP detection engine  1248  monitors communications of the set of users on the set of communications platforms for violations of the cross-platform DLP policy. In various embodiments, the block  1304  can include monitoring for actual violations, quasi-violations, or both. In a typical embodiment, as part of the block  1304 , the native DLP detector  1250  tracks violations of any native activations of the cross-platform DLP policy. The native activations can include, for example, native DLP policies that are a translated form of or are deemed equivalent to the cross-platform DLP policy. In a typical embodiment, the custom DLP detector  1254  centrally detects violations of any central activations of the cross-platform DLP policy. The central detection typically includes evaluating, against the cross-platform DLP policy, communications collected by the BIM system  130  that correspond to the central activations. In addition, the block  1304  can also include the DLP risk profiler  1256  monitoring for quasi-violations of the cross-platform DLP policy as described above. 
     At decision block  1306 , the DLP detection engine  1248  determines whether a violation has been detected, for example, by the native DLP detector  1250 , the custom DLP detector  1254 , and/or the DLP risk profiler  1256 . Responsive to a detected violation, the process  1300  proceeds to block  1308 . Otherwise, the process  1300  returns to the block  1304  and proceeds as described above. At the block  1308 , the DLP context module  1258  dynamically acquires context information for the detected violation. An example of how context information can be specified will be described with respect to  FIG. 14 . An example of dynamically acquiring context information will be described with respect to  FIG. 15 . 
     At block  1310 , the DLP management console  1260  publishes violation information to at least one designated user. The at least one designated user can include, for example, a manager of a user who initiated the violation. The violation information can include, for example, information associated with the detected violation, the context information, and/or the like. The information associated with the detected violation can include, for example, user-identification information (e.g., name, user name, ID, etc.), violation type (e.g., identification of the particular violation if multiple violation types are allowed by the cross-platform DLP policy), a time of the violation, a communication that constituted the violation, a communication identifier for the communication that constituted the violation, and/or other information that is readily accessible at a time of violation detection. In a typical embodiment, the block  1310  results in the violation information being made accessible to the at least one designated user. In many cases, the block  1310  may include providing the at least one designated user with options for selecting one or more enforcement actions as a result of the detected violation. An example of publishing violation information will be described with respect to  FIG. 16 . 
       FIG. 14  presents a flowchart of an example of a process  1400  for creating a cross-platform DLP policy. The process  1400  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  1400 , in whole or in part, can be implemented by one or more of the BIM system  130 , the DLP detection engine  1248 , the DLP management console  1260 , and/or components thereof. Although any number of systems, in whole or in part, can implement the process  1400 , to simplify discussion, the process  1400  will be described in relation to specific systems or subsystems of the system  1100  of  FIG. 11  and/or the cross-platform DLP system  1146 . It various embodiments, the process  1400  can be performed as part of the block  1302  of  FIG. 13 . 
     At block  1402 , the policy abstraction module  1252  defines a cross-platform DLP policy. The block  1402  can include the policy abstraction module  1252  interacting with an administrator to establish, for example, a name and/or unique identifier for the cross-platform DLP policy. The block  1402  can include, for example, empirically defining how the cross-platform DLP policy can be violated responsive to input from the administrator. The empirical definition can include defining both actual violations and quasi-violations. In some embodiments, definitions of quasi-violations can be automatically derived from the definitions of actual violations (e.g., as percentages, ranges, standard deviations relative to expected values, etc.). In some embodiments, the cross-platform DLP policy can be defined in terms of a native DLP policy of a particular communications platform of the communications platforms  1276 . In these embodiments, the administrator can be permitted to identify or provide the native DLP policy, which policy the policy abstraction module  1252  can then import and re-specify in a standardized format (e.g., by translation). 
     At block  1404 , the policy abstraction module  1252  identifies one or more contextual parameters. The contextual parameters generally represent variable, violation-specification information that will be used as a basis for generating context information. The contextual parameters can include, for example, user-identification information (e.g., name, user name, ID, etc.), violation type (e.g., identification of the particular violation if multiple violation types are allowed by the cross-platform DLP policy), a time of the violation, a communication that constituted the violation, a communication identifier for the communication that constituted the violation, and/or other information that is readily accessible at a time of violation detection. 
     At block  1406 , the policy abstraction module  1252  generates a query package that can be used to dynamically generate context information responsive to a detected violation. The query package can be specified, for example, as described above with respect to  FIGS. 1-12 . In general, the query package is tailored to request, in terms of the contextual parameters, context information for violations of the cross-platform DLP policy. The requested context information can include, for example, prior violations by a violating user within a certain period of time, communications by or to the violating user within a certain period of time before and/or after the violation (e.g., including communications on any of the communications platforms  1276 ), the violating user&#39;s communication patterns (e.g., who the violating user communicates with most, the violating user&#39;s volume of communications, top topics discussed in communications, etc.), and/or the like. The requested context information can also include aggregated context information such as, for example, a number of violations of the cross-platform DLP platform across a given organization or enterprise, a number of violations within the violating user&#39;s department or organization unit, most frequently taken enforcement actions by other managers responsive to violations of the cross-platform DLP policy, and/or the like. 
     At block  1408 , the policy abstraction module  1252  configures a reporting workflow for violations of the cross-platform DLP policy. The configuring can include, for example, defining one or more designated users who can view violations, receive alerts or reports of violations, and/or take enforcement actions responsive to violations. In some cases, the one or more designated users may be defined generally using, for example, directory services (e.g., Active Directory). For example, the one or more designated users could include each direct manager of a violating user. In other cases, the one or more designated users can be defined as specific users for each user that is to be covered by the policy (e.g., a manually designated user for each user or group users impacted by the cross-platform DLP policy). The configuration at the block  1408  can also include, for example, establishing one or more enforcement actions that can be taken by the one or more designated users. In various embodiments, an access profile for each of the designated users can be used to establish which enforcement actions each designated user is permitted to take. 
     At block  1410 , the policy abstraction module stores the cross-platform DLP policy. The storage can include, for example, storage of the query package as linked to the cross-platform DLP policy. In various embodiments, the storage at the block  1410  can be in memory accessible to the policy abstraction module  1252 , in the databases  232  of  FIG. 11 , and/or the like. 
       FIG. 15  presents a flowchart of an example of a process  1500  for dynamically acquiring context information responsive to a detected violation of a cross-platform DLP policy. The detected violation may have been detected, for example, via the native DLP detector  1250 , the custom DLP detector  1254 , and/or the DLP risk profiler  1256 . The process  1500  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  1500 , in whole or in part, can be implemented by one or more of the BIM system  130 , the DLP detection engine  1248 , the DLP management console  1260 , and/or components thereof. Although any number of systems, in whole or in part, can implement the process  1500 , to simplify discussion, the process  1500  will be described in relation to specific systems or subsystems of the system  1100  of  FIG. 11  and/or the cross-platform DLP system  1146 . It various embodiments, the process  1500  can be performed as part of the block  1308  of  FIG. 13 . 
     At block  1502 , the DLP context module  1258  retrieves a query package that is linked to the cross-platform DLP policy. In a typical embodiment, the query package may have been generated at the block  1406  of  FIG. 14 . At block  1504 , the DLP context module  1258  accesses values of contextual parameters that are needed for the query package. The values can typically be obtained from information associated with the detected violation. The information associated with the detected violation is typically obtained by the native DLP detector  1250 , the custom DLP detector  1254 , and/or the DLP risk profiler  1256 , as appropriate. At block  1506 , the DLP context module  1258  executes the query package, for example, on the BIM system  130 . At block  1508 , the DLP context module  1258  receives the context information responsive to the execution of the query package. 
       FIG. 16  presents a flowchart of an example of a process  1600  for publishing violation information to one or more designated users responsive, for example, to a detected violation. The detected violation may have been detected, for example, via the native DLP detector  1250 , the custom DLP detector  1254 , and/or the DLP risk profiler  1256 . The process  1600  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  1600 , in whole or in part, can be implemented by one or more of the BIM system  130 , the DLP detection engine  1248 , the DLP management console  1260 , and/or components thereof. Although any number of systems, in whole or in part, can implement the process  1600 , to simplify discussion, the process  1600  will be described in relation to specific systems or subsystems of the system  1100  of  FIG. 11  and/or the cross-platform DLP system  1146 . It various embodiments, the process  1600  can be performed as part of the block  1310  of  FIG. 13 . 
     At block  1602 , the user permission manager  1262  determines which enforcement actions that each designated user has permission to perform. In a typical embodiment, the determination can be made by ascertaining which enforcement actions of a set of potential enforcement actions are allowed by each designated user&#39;s access profile. At block  1604 , the reporting module  1264  provides an interface for each designated user to select the determined enforcement actions. The interface can be, for example, a web interface, an interface on one of the communications platforms  1276 , and/or the like. At decision block  1606 , the reporting module  1264  determines whether a designated user has selected one of the determined enforcement actions. If not, the process  1600  returns to the block  1604  and proceeds as described above. If it is determined at the decision block  1606  that the designated user has selected one of the determined enforcement actions, the process  1600  proceeds to block  1608 . In a typical embodiment, the selected enforcement action can be made with respect to one or more communications platforms of the communications platforms  1276 . At block  1608 , the credentials module  1270  causes the selected enforcement action to be executed with administrator privileges on each of the one or more communications platforms. At block  1610 , the executed enforcement action is recorded, for example, in one or more of the databases  232 . The block  1610  can include recording, for example, the executed enforcement, information associated with the detected violation, any context information, and/or the like. 
       FIG. 17  illustrates an example of an access profile  1776 . In the depicted embodiment, the access profile grants a “Manager X” a right to perform enforcement actions of “block sending,” “block receiving,” “suspend account,” and “report abuse.” As illustrated, the access profile  1776  grants the above-mentioned enforcement actions for “all his/her staff,” which, in a typical embodiment, can be determined using, for example, directory services (e.g., Active Directory). In some cases, the access profile  1776  can include other enforcement actions such as, for example, “allow with warning.” In these embodiments, any users impacted by the enforcement actions can be presented a warning that must be explicitly acknowledged and disregarded before the cross-platform DLP policy can be violated in the future. 
     Table 6 below provides examples of laws and standards from which, in various embodiments, cross-platform DLP standards can be derived and implemented. 
                                 TABLE 6               USE CASE   DESCRIPTION   APPLIES TO   DLP OPPORTUNITY                  Sarbanes-   Enacted in the US in 2002. It   US/Global   Provide monitoring and assessment for       Oxley (Sarbox)   targets any company that is   Publicly traded   messaging security, virus protection,           publicly traded on an   companies   intrusion detection, vulnerability           American stock exchange. Its       management, and user authentication.           purpose is to ensure the       Provide audit trails for error logs, system           accuracy of the company&#39;s       health, and asset management (?).           financial information and the       Monitoring of business-critical messaging/           reliability of the systems that       collaboration software helps provide           generate it. The challenge to       increased confidence in the integrity of the           IT is to manage a secure and       network infrastructure.           controlled infrastructure for                   data, processes, and historical                   information. While this act                   applies to large or established                   enterprises, it is high profile                   around the world has had a                   significant impact as to how                   all businesses conduct                   themselves.               Gramm-Leach-   Gramm-Leach-Billey (GLBA)   US Finance   24x7 detection of security breaches and       Billey (GLBA)   is a US act from 1999. It   sector, Global   vulnerabilities and integrating with industry           applies to any American   finance   standards such as Microsoft Baseline           financial institution, large and       Security Analyzer (MBSA) or other           small. Its purpose is to ensure       enterprise-class security platforms.           the integrity of financial and       Dashboards, alerts and notifications help           client data. The role of IT is to       ensure communications availability, Patch           implement systems for       assessment and management (?).           security and authorized access,       Infrastructure reports are integral for           and to build safeguards against       capacity and disaster planning.           threats and hazards. Globally,                   similar requirements are found                   in The New Capital Accord                   (Basel II) 1998/2005.               USA   USAPATRIOT Act of 2001   US Any   Identify potential vulnerabilities to       PATRIOT Act   applies to all US-based   company/   messaging access points. Identify       (USA   companies and attempts to   individual   messaging to unauthorized destinations.       PATRIOT)   prevent the support and       Detect unauthorized access. Track the flow           financing of terrorists. It also       of sensitive information.           aims to prevent intellectual                   property/trade secrets from                   being sent to certain                   international locations.               Federal Food   Federal Food &amp; Drug 21-   US Healthcare   Help managers to ensure secure       &amp; Drug 21-   CFR-11(21-CFR-11) is a US   sector   environments and authenticated users.       CFR-11(21-   law applies to any company       Infrastructure reports give       CFR-11   that is regulated by the Food       overall messaging network health checks to           and Drug Administration       ensure the availability of data.           (FDA). Its goal is to ensure the                   security, integrity, and                   availability of information.                   This is of particular concern to                   the health care industry that                   relies on the accuracy of                   patient/product information.               Payment Card   Payment Card Industry Data   Any global   Monitor 24x7 any intrusion, or       Industry Data   Security Standard (PCI-DSS)   company   unauthorized access, as well as system       Security   was created in 2004 by the   accepting   failures that could impact prompt response.       Standard (PCI-   major credit card companies to   credit card   Ensure compliance of communications-       DSS)   ensure that their merchants   payments   based transactions.           adhered to certain network                   standards to protect against                   vulnerabilities, and to protect                   cardholders from fraud. The                   standard applies to any CC-                   processing merchant, and has                   5 general goals: Build and                   maintain a secure network;                   Protect transaction data; Guard                   against vulnerabilities;                   Implement strong Access                   Control measures; and                   Regularly monitor and test                   networks. Global Credit card                   merchants               Notification of   The purpose of the act is to   Any US/   Detect, investigate, and notify unauthorized       Risk to   ensure that any agency notifies   European   access, Remote management of       Personal Data   authorities if any personal   company   environments allow       Act (NORPDA -   information has been acquired       for rapid action against intrusion. Report       US 2003)   by an unauthorized source.       regular security audits, health checks.           The impact to IT is to improve                   security and reporting                   systems. Similar laws in                   Europe include the European                   Data Protection Directive of                   1995, among others.               Health   This act applies to all US-   Any company   Ensure security and availability of       Information   based health care providers. Its   handling   messaging systems, as well as protecting       Portability &amp;   purpose is to improve health   personal   them from unauthorized use.       Accountability   care operations and to ensure   information &amp;           Act (HIPAA)   patient record privacy. The   US Healthcare           from 1996   impact to IT is to improve   sector               security and interoperability of                   information systems, as well                   as improve reporting systems.                   Related to this is the Personal                   Information Protection and                   Electronic Documents Act                   (PIPEDA - Canada 2000).                   Applying to all Canadian                   companies and agencies, it                   limits the use and disclosure of                   personal information obtained                   during the course of doing                   business The onus on                   management is to ensure                   proper use of personal                   information. {There is also a                   significant EURO privacy act)               CAN-SPAM   This act establishes email   US companies   Ensure Can-Spam laws are met.       Controlling the   standards for US-based               Assault of   companies. The act protects               Non-Solicited   users against false or               Pornography   misleading message headers,               And Marketing   and deceptive subject lines.               Act from 2003   Senders must identify                   outgoing mail as a commercial                   (ad) message. Sender                   identification must be accurate                   and traceable (no spoof). Mail                   cannot be sent using harvested                   mail addresses. The message                   must contain details about                   where the message is                   originating from, as well as                   information on how the                   recipient can “unsubscribe” to                   future messages. Opt-out                   requests from recipients must                   be processed within 10                   business days. No fees can be                   charged to unsubscribe a                   recipient.               SAS-70   General compliance guidelines   US/global   Ensure SAS-70 compliance.       Compliance   have been compiled by the   companies           requirements   auditing sector and published               that can be   as SAS-70. The directive               delivered   highlights 7 areas that apply to               efficiently and   IT Information and Systems               effectively   Management.                    
III. User Context Analysis and Context-Based DLP
 
     In various embodiments, many of the principles described above can also be leveraged to generate intelligence regarding how user behavior on a remote computer system differs based, at least in part, on user context. In general, a user context is representative of one or more conditions under which one or more user-initiated events occur. A user-initiated event can be, for example, a user-initiated communication event on a communications platform. Examples of user-initiated communication events include a user creating, drafting, receiving, viewing, opening, editing, transmitting, or otherwise accessing or acting upon a communication. Communications can include, for example, emails, blogs, wikis, documents, presentations, social-media messages, and/or the like. User-initiated events can also include other user behaviors such as, for example, a user accessing or manipulating non-communication computer resources and artifacts thereof. 
     In various embodiments, user-initiated events can be originated via a user device in communication with a remote computer system or resource such as, for example, a communications platform. For a given user-initiated event, a corresponding user context can be defined by event-context information. The event-context information can include temporal data about the event such as, for example, information usable to identify a specific user or attributes thereof (i.e., user-identification information), information related to a physical location of a user device or attributes thereof (i.e., user-location information), information related to when a user-initiated event occurred (i.e., event-timing information), information usable to identify a user device or attributes thereof (i.e., user-device identification information), and/or the like. 
     In certain embodiments, a user-context-based analysis of user-initiated events can occur on demand responsive to requests from a user or system, automatically at certain scheduled times or intervals, etc. In particular, in some embodiments, a user-context-based analysis can be performed in real-time as information becomes available in order to facilitate dynamic implementation of DLP policies based, at least in part, on user context. In addition, in various embodiments, user devices can be enabled to configure the dynamic implementation based on user attestation of a risk or lack thereof. For illustrative purposes, examples will be described below relative to user-initiated communication events, often referred to herein simply as communication events. It should be appreciated, however, that the principles described can similarly be applied to other types of user-initiated events or user behaviors. 
       FIG. 18  illustrates an embodiment of a system  1800  for user-context-based analysis of communications. The system  1800  includes communications platforms  1876 , a BIM system  1830 , a cross-platform DLP system  1846 , and a user-context analytics system  1880 . As shown, the communications platforms  1876 , the BIM system  1830 , the cross-platform DLP system  1846 , and the user-context analytics system  1880  are operable to communicate over a network  1805 . 
     The communications platforms  1876 , the BIM system  1830 , and the cross-platform DLP system  1846  can operate as described above with respect to the BIM system  130 , the cross-platform DLP system  1146 , and the communications platforms  1276 , respectively. In a typical embodiment, the network  1805  can be representative of a plurality of networks such as, for example, the intranet  104  and the network  106  described above. In certain embodiments, the communications platforms  1876 , the BIM system  1830 , and the user-context analytics system  1880  can collaborate to generate intelligence related to how user behavior differs based, at least in part, on user context. 
     More particularly, the communications platforms  1876  may be considered specific examples of one or more of the internal data sources  120  and/or one or more of the external data sources  122  described above. In that way, in certain embodiments, the BIM system  1830  is operable to collect and/or generate, inter alia, information related to communications on the communications platforms  1876 . It should be appreciated that, in many cases, such communications may be the result of communication events such as, for example, a user creating, drafting, receiving, viewing, opening, editing, transmitting, or otherwise accessing or acting upon the communications. For simplicity of description, information collected or generated by the BIM system  1830  with respect to the communications platforms  1876  may be referred to herein as event-assessment data. 
     For example, the event-assessment data can include information related to a classification assigned to particular communications. As described above, communications can be assigned classifications, for example, by components such as the a priori classification engine  226 , the a posteriori classification engine  228 , and the heuristics engine  230 . In an example, the event-assessment data can include content-based classifications such as classifications indicative of a particular topic or classifications based on whether a communication is conversational, formal, personal, work-related, sales-related, etc. By way of further example, the event-assessment data can include participant-based classifications that are based on, for example, an email address or domain of a communication participant, whether the communication includes customers as participants, whether the communication includes internal participants, roles of the communication participants, etc. Additional examples of content-based and participant-based classifications are described in U.S. patent application Ser. No. 14/047,162 in the context of identifying subject-matter experts. U.S. patent application Ser. No. 14/047,162 is hereby incorporated by reference. As still further examples, the event-assessment data can include classifications based on a type of communication (e.g., email, instant message, voicemail, etc.), length of communication, and/or the like. Numerous other examples of event-assessment data will be apparent to one skilled in the art after reviewing the present disclosure. 
     The user-context analytics system  1880  can include a user-context correlation engine  1882 , a user-context analytics engine  1884 , a context-analytics access interface  1886 , an active policy agent  1890 , and a data store  1888 . In certain embodiments, the user-context correlation engine  1882  is operable to determine event-context information for certain user-initiated communication events. In some cases, determining the event-context information can involve requesting and receiving, from the communications platforms  1876 , user-log data. The user-log data can include, for example, stored information related to each user session, such as, for example, an IP address, a user&#39;s client application (e.g., a user&#39;s choice of web browser), network or security settings of the user&#39;s device, other characteristics of the user&#39;s device (e.g., manufacturer, model, operating system, etc.), combinations of the same, and/or the like. In a typical embodiment, the user-context analytics system  1880  can also correlate the event-context information to one or more user contexts. In various embodiments, event-context information and/or correlated event-context information can be stored in the data store  1888 . Example operation of the user-context analytics system  1880  will be described in greater detail with respect to  FIGS. 19-21 . 
     In a typical embodiment, the user-context analytics engine  1884  uses correlated event-context information as described above to associate user-communication pattern(s) with user contexts. Each user-communication pattern typically characterizes activity that takes place for a given user context. In an example, consider a particular user context that aggregates all of a particular user&#39;s communication events that originate from a public location. The public location may be indicative, for example, of the user using publicly available network access offered by a place of business (e.g., restaurant, hotel, etc.), governmental unit, and/or the like. According to this example, a user-communication pattern could indicate: 
     (1) A level of personal activity. In an example, personal activity can be measured based, at least in part, on a number of communication events involving personal messages as described above. A given communication pattern could indicate a number, percentage, statistical evaluation, or other analysis of the number or distribution of personal messages. 
     (2) Types of communication participants. In an example, a given communication pattern could indicate communication events involving particular communication-participant types such as: customer participants, internal participants, participants in certain business units (e.g., executive management, legal, etc.), participants having certain roles as indicated by directory services, and/or the like. A communication-participant type can also aggregate groups of communication participants. For example, a “strategic” group could aggregate communication participants in executive management and research and development. For each communication-participant type, a given communication pattern could indicate a number, percentage, statistical evaluation, or other analysis of a number or distribution of communications involving the communication-participant type. 
     (3) Content classifications. In an example, a given communication pattern could indicate communication events involving communications that involve certain topics (e.g., sales). In another example, a given communication pattern could indicate communication events involving communications that are deemed conversational, formal, work-related, etc. For each content classification, a given communication pattern could indicate a number, percentage, statistical evaluation, or other analysis of a number of communications involving the content classification. 
     (4) Communication type. In an example, a given communication pattern could indicate communication events by communication type such as, for example, email, instant message, document, voicemail, etc. For each communication type, a given communication pattern could indicate a number, percentage, statistical evaluation, or other analysis of a number of communications involving the communication type. 
     It should be appreciated that the foregoing examples are merely illustrative of information that can at least partially form the basis for a communication pattern. Numerous other examples will be apparent to one skilled in the art after reviewing the present disclosure. 
     In certain embodiments, the user-context analytics engine  1884  can generate a communication profile based, at least in part, on a communication pattern(s) for one or more user contexts. In certain embodiments, the communication profile can include comparative communication-pattern information related to a plurality of user contexts. For example, one user context could be defined by communication events originating from a public location and a another user context could be defined by communication events originating from all other locations. 
     In certain embodiments, the comparative communication-pattern information can include information summarizing or otherwise indicative of communication patterns associated with each user context. In some cases, the communication profile can include a report (e.g., a chart or graph) that facilitates a side-by-side comparison of the plurality of user contexts. In various embodiments, the communication profile can further indicate differences among the plurality of user contexts. For example, the communication profile could indicate differences in degree, number, and/or the like for each of personal activity, types of communication participants, content classifications, and communication types as described above. In various embodiments, differences can be indicated by sorting and ranking according to one or more representative metrics, providing an evaluation of one or more representative metrics (e.g., indicating which is highest or lowest), etc. In general, the representative metric can relate to any number, percentage, statistical evaluation, or other analysis generated as part of a given communication pattern as described above. 
     The context-analytics access interface  1886  is operable to interact with users of a client information handling system over a network such as, for example, an intranet, the Internet, etc. In a typical embodiment, the context-analytics access interface  1886  receives and services communication-analytics requests from users. The context-analytics access interface  1886  typically serves the communication-analytics requests via interaction with the user-context analytics engine  1884 . In certain embodiments, the context-analytics access interface  1886  can trigger the operation of the user-context correlation engine  1882  and the user-context analytics engine  1884  described above. Further examples of operation of the context-analytics access interface  1886  will be described in greater detail with respect to  FIGS. 19-21 . 
     The active policy agent  1890  is typically operable to facilitate real-time user-context analysis and DLP implementation. In a typical embodiment, the active policy agent  1890  can determine a user context for each user session with one of the communications platforms  1876 . Based, at least in part, on the user context, the active policy agent  1890  can select a dynamic DLP policy. In certain embodiments, the dynamic DLP policy can include a cross-platform DLP policy, which policy can be implemented by the cross-platform DLP system  1846  as described above. 
     In addition to optionally including a cross-platform DLP policy, the dynamic DLP policy can specify one or more communication events of interest. In general, each user session is established between a user device and one or more of the communications platforms  1876 . The active policy agent  1890  can monitor communication events originated by each such user device for the communication events of interest. For example, the communication events of interest may include a user creating, drafting, receiving, viewing, opening, editing, transmitting, or otherwise accessing or acting upon a communication in a specified manner. 
     If a communication underlying a particular communication event of interest meets risk-assessment criteria specified by the dynamic DLP policy, certain action can be taken. The risk-assessment criteria may target, for example, communications that involve particular types of communication participants, that have particular content classifications, that are of particular communication types, and/or the like. The actions that can be taken may include publishing a warning to the user, alerting an administrator or other designated user, preventing further actions by the user, forcing user log off, etc. In addition, in various embodiments, risk assessments of communication events of interest can be published to a real-time risk-evaluation dashboard that is visible to the user. 
     In a particular example, the communication events of interest can include pre-transmission communication events. Pre-transmission communication events can include the user drafting or editing a communication that has not been sent. In various embodiments, draft communications are maintained in a designated folder or other location that is resident on or otherwise accessible to at least one of the communications platforms  1876 . In various embodiments, the draft communications can be accessed and classified in similar fashion to any other communication. Responsive to certain risk-assessment criteria being met as described above, transmission of such draft communications can be prevented. Further examples of operation of the active policy agent  1890  will be described below. 
       FIG. 19  presents a flowchart of an example of a process  1900  for performing user-context-based analysis of communication events. The process  1900  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  1900 , in whole or in part, can be implemented by one or more of the BIM system  1830 , the communications platforms  1876 , the cross-platform DLP system  1846 , the user-context analytics system  1880 , the user-context correlation engine  1882 , the user-context analytics engine  1884 , the context-analytics access interface  1886 , the data store  1888 , and/or the active policy agent  1890 . The process  1900  can also be performed generally by the system  1800 . Although any number of systems, in whole or in part, can implement the process  1900 , to simplify discussion, the process  1900  will be described in relation to specific systems or subsystems of the system  1800  and/or the user-context analytics system  1880 . In various embodiments, the process  1900  can be initiated via a communication-analytics request received via the context-analytics access interface  1886 . Such a request can be received from a user device, a computer system, or another entity. 
     At block  1902 , the user-context correlation engine  1882  accesses event-assessment data for a plurality of communication events. In some cases, the plurality of user-initiated communication events can include all communication events of a given user (or set of users) over a certain period of time (e.g., a preceding one year, six months, etc.). It should be appreciated that the plurality of communication events may relate to different ones of the communication platforms  1876 . In that way, the plurality of user-initiated communication events may be considered cross-platform communication events. In various embodiments, the plurality of user-initiated communication events, or criteria for identifying the plurality of user-initiated communication events, can be specified in a communication-analytics request. 
     At block  1904 , the user-context correlation engine  1882  determines event-context information for each of the plurality of communication events. The event-context information can include, for example, user-identification information, user-location information, event-timing information, user-device identification information, anomalous-event information, and/or the like as described above. 
     In general, the user-identification information can be any information usable to identify a user or some attribute of a user who is associated with a given communication event. User-identification information can include, for example, a user name, employee identifier, or other data. In many cases, the user-identification information may be determined from the event-assessment data. In other cases, additional user-identification information may be retrieved from another system such as, for example, one or more of the communications platforms  1876 . For example, in some embodiments, if a user identifier is known, the user identifier can be used to retrieve, from one or more of the communications platforms  1876 , information about a corresponding user&#39;s role or responsibilities in an organization (e.g., using directory services). 
     In general, the user-location information can be any information related to a physical location of the user device, or attributes thereof, at a time that a given communication event occurs. The given communication event is typically originated on one of the communications platforms  1876  via a user device under control of a user. The user-location information can include multiple levels of descriptive information. 
     In certain embodiments, at least a portion of the user-location information can be determined by resolving an IP address associated with the user to a physical location. The IP address can be accessed, for example, from the event-assessment data and/or retrieved from a particular one of the communications platforms  1876  on which the given communication event occurred. In some cases, the IP address can be obtained from user-log data as described above. In an example, the IP address can be resolved to a city, state, province, country, etc. In addition, in various embodiments, it can be determined directly from the IP address via what network provider the user device is accessing one or more of the communications platforms  1876 , whether the user device is inside or outside of a particular enterprise network, whether the user device is inside or outside of a particular city, state, province, country, etc. 
     In addition, or alternatively, the IP address may be looked up in an IP address registry to determine at least a portion of the user-location information. The IP address registry can associate certain network-location attributes (e.g., network addresses and network-address ranges) with a particular user&#39;s home, a public place of business (e.g., network access at a coffee shop, mall, airport, etc.), and/or the like. In embodiments that utilize the IP address registry, the user-context correlation engine  1882  can determine, as part of the event-context information, whether the user device was in a public location (e.g., coffee shop, mall, or airport), at the user&#39;s home, etc. at the time of the given communication event. In some embodiments, the IP address registry may be stored in the data store  1888  or in memory. In these embodiments, users or administrators may register the network-location attributes. In other embodiments, all or part of the IP address registry can be provided by a third-party service provider. 
     In general, the user-device identification information can include information descriptive of the user device, hardware or software of the user device, and/or attributes thereof. For example, the user-device identification information can include information related to a client application on the user device that is used to access one or more of the communications platforms (e.g., a user&#39;s choice of web browser), network or security settings of the user device or an application executing thereon, other characteristics of the user device (e.g., manufacturer, model, operating system, etc.), and/or the like. In many cases, some or all of the user-device identification information can be accessed from the event-assessment data. In other cases, at least a portion of the user-device identification information can be retrieved from one or more of the communications platforms  1876  (e.g., via user-log data as described above). 
     The event-timing information can include, for each communication event, information descriptive of when the communication event occurred. For example, the event-timing information can include time classifications such as, for example, whether the communication event occurred in the morning, in the evening, on the weekend and/or the like as measured by a corresponding user&#39;s local time. The event-timing information can also indicate whether the communication event occurred during or outside of the user&#39;s working hours. In various embodiments, the event-timing information can be determined from a timestamp for the communication event. The timestamp can be obtained, for example, from the event-assessment data or retrieved from another system such as one of the communications platforms  1876 . 
     The anomalous-event information can indicate, for each communication event, whether the communication event is deemed anomalous. In a typical embodiment, the communication event may be considered anomalous if it is determined to be of questionable authenticity. For example, the communication event may be considered anomalous if another communication event occurred within a certain period of time (e.g., 30 minutes) of that communication event and is deemed to involve a same user (e.g., using the same user credentials), on a different user device, in a sufficiently distant physical location (e.g., two-hundred kilometers away as determined via IP address). In various embodiments, what constitutes a sufficiently distant physical location can be varied according to a period of time separating two communication events (e.g., allowing for a distance of no greater than one kilometer per minute elapsed). In various embodiments, the anomalous-event information can be determined from other event-context information. For example, the user-context correlation engine  1882  can aggregately analyze a location and timing of all of the plurality of communication events. Based, at least in part, on the analysis, the user-context correlation engine  1882  can identify anomalous communication events as described above. 
     At block  1906 , the user-context correlation engine  1882  correlates the event-assessment data to one or more user contexts. In some cases, the one or more user contexts can be specified in a communication-analytics request as described above. In a typical embodiment, each user context is defined by a distinct subset of the event-context information. In a typical embodiment, the user-context correlation engine  1882  correlates the event-assessment data to user contexts on an event-by-event basis. That is, the event-assessment data for a given communication event is correlated to a given user context if the communication satisfies each constraint of the user context. For example, if a particular user context is directed to communication events occurring during non-working hours and at public locations, the event-assessment data for a particular communication event would be correlated to the particular user context only if the particular communication event is deemed to have occurred during non-working hours (relative to the local time of a corresponding user) and in a public location. 
     Each user context can include any combination of event-context information described above. For example, user-context constraints can be defined in terms of user-identification information, event-timing information, user-device identification information, user-location information, anomalous-event information, and/or other information. In the case of event-timing information, a given user context may specify one or more recurring periods of time such as, for example, time periods deemed working hours, non-working hours, etc. In addition, in some embodiments, each user context may specify a static non-overlapping period of time for a particular user (e.g., 2010-2012 for a first user context and 2013-present for a second user context). In these embodiments, the non-overlapping periods of time can enable measurement of communication-pattern evolution of users over time. 
     In some cases, each user context can be mutually exclusive of each other user context. In an example, one user context could be directed to communication events deemed to occur in a public location while another user context could be directed to communication events deemed to occur in all other locations. In another example, one user context could be directed to communication events deemed to occur during working hours while another user context could be directed to communication events deemed to occur during non-working hours. It should be appreciated, however, that each user context need not be mutually exclusive other user contexts. For example, one user context could be directed to communication events occurring during non-working hours, another user context could be directed to communication events occurring during working hours, and yet another user context could be directed to communication events originating from a user&#39;s home. 
     At block  1908 , the user-context correlation engine  1882  associates one or more communication patterns with each of the one or more user contexts. In general, each communication pattern can include any of the communication-pattern information described above with respect to  FIG. 18 . At block  1910 , the user-context correlation engine  1882  generates a communication profile for at least one user. In various embodiments, the block  1910  can include generating a communication profile for each user responsible for one of the plurality of user-initiated communication events. In general, each communication profile can include any of the information (e.g., comparative communication-pattern information) described above with respect to  FIG. 18 . 
     At block  1912 , the user-context correlation engine  1882  performs actions based on the one or more communication profiles. In some embodiments, the block  1912  can include publishing the one or more communication profiles (e.g., in the form of reports) to an administrator or other designated user. In additional embodiments, the block  1912  can include performing an automated risk evaluation of comparative communication-pattern information contained in the one or more communication profiles. In various embodiments, the automated risk evaluation may use risk-assessment criteria to target certain communication profiles deemed dangerous. In various cases, the risk-assessment criteria can be maintained in the data store  1888  or in memory. 
     For example, the risk-assessment criteria may target communication events that involve communications to customers and are originated from a public location. The risk-assessment criteria can specify, for example, a threshold number of communication events. Responsive to the comparative communication-pattern information for a particular communication profile meeting the risk-assessment criteria, an alert can be transmitted to a designated user. Other examples of risk-assessment criteria and of automated risk evaluation will be apparent to one skilled in the art after reviewing the present disclosure. 
     At block  1914 , resultant data is stored in the data store  1888  or in memory. The resultant data can include, for example, the accessed event-assessment data, the determined event-context information, the correlated event-assessment data, information related to user-communication patterns, the one or more communication profiles, and/or other data. 
       FIG. 20  presents a flowchart of an example of a process  2000  for performing dynamic DLP via a real-time user-context-based analysis. The process  2000  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  2000 , in whole or in part, can be implemented by one or more of the BIM system  1830 , the communications platforms  1876 , the cross-platform DLP system  1846 , the user-context analytics system  1880 , the user-context correlation engine  1882 , the user-context analytics engine  1884 , the context-analytics access interface  1886 , the data store  1888 , and/or the active policy agent  1890 . The process  2000  can also be performed generally by the system  1800 . Although any number of systems, in whole or in part, can implement the process  2000 , to simplify discussion, the process  2000  will be described in relation to specific systems or subsystems of the system  1800  and/or the user-context analytics system  1880 . 
     At block  2002 , the active policy agent  1890  determines a current user context of at least one user device currently accessing one of the communications platforms  1876 . In general, the current user context can include any combination of information described above relative to event-context information. 
     At block  2004 , the active policy agent  1890  selects a dynamic DLP policy based on the user context. In a typical embodiment, the dynamic DLP policy may include a cross-platform DLP policy that is implemented as described above. In addition, the dynamic DLP policy may include DLP risk-assessment criteria. In certain embodiments, the DLP risk-assessment criteria are used to assess a riskiness of communication events. If, for example, the user context indicates that the at least one user device is currently inside a given corporate firewall, the DLP risk-assessment criteria may be relaxed or nonexistent. Conversely, if, for example, the user context indicates that the at least one user device is in a public location, the DLP risk-assessment criteria may be more stringent. 
     More particularly, in a typical embodiment, the DLP risk-assessment criteria specifies one or more rules for determining whether a given communication event is deemed risky. In certain embodiments, the risk-assessment criteria can be based, at least in part, on content-based classifications of communications associated with communications event of interest. For example, in certain embodiments, communications related to a topic of sales may be deemed risky if the user context indicates that the at least one user device is in a public location. According to this example, communications related to the topic of sales could be specified as risky in the risk-assessment criteria. In contrast, communications related to the topic of sales may not be deemed risky if, for example, the at least one user device is determined to be at a corresponding user&#39;s home. According to this alternative example, the risk-assessment criteria may not specifically identify the topic of sales. The risk-assessment criteria can also specify other criteria such as, for example, particular communication-participant types. Other examples will be apparent to one skilled in the art after reviewing the present disclosure. 
     At block  2006 , the active policy agent  1890  monitors communication events originated by the at least one user device. Advantageously, in certain embodiments, the block  2006  can include monitoring pre-transmission communication events as described above relative to  FIG. 18 . At decision block  2008 , the active policy agent  1890  determines whether a communication event of interest has occurred. If not, the process  2000  returns to block  2006  and proceeds as described above. Otherwise, if it is determined at the decision block  2008  that a communication event of interest has occurred, the process  2000  proceeds to block  2010 . 
     At block  2010 , the active policy agent  1890  evaluates the communication event of interest according to the DLP risk-assessment criteria. At decision block  2012 , the active policy agent  1890  determines whether the DLP risk-assessment criteria is met. If not, the process  2000  returns to block  2006  and proceeds as described above. Otherwise, if the active policy agent  1890  determines at the decision block  2012  that the DLP risk-assessment criteria is met, the process  2000  proceeds to block  2014 . At block  2014 , the active policy agent  1890  takes action specified by the dynamic DLP policy. For example, in the case of pre-transmission communication events, the active policy agent  1890  may prevent transmission of a communication in the fashion described above. By way of further example, the action taken can also include publishing a warning to the user, alerting an administrator or other designated user, preventing further actions by the user, forcing user log off, etc. 
     At block  2016 , the active policy agent  1890  publishes a risk assessment to a real-time risk-evaluation dashboard on the at least one user device. In various embodiments, the risk assessment can indicate whether the communication event of interest is deemed risky, not risky, etc. In some cases, the risk assessment can be a scaled metric indicating a degree to which the communication event of interest is deemed risky. In various embodiments, the block  2016  can be omitted such that no risk assessment is published. From block  2016 , the process  2000  returns to block  2006  and proceeds as described above. The process  2000  can continue indefinitely (e.g., until terminated by rule or by an administrator or other user). 
       FIG. 21  presents a flowchart of an example of a process  2100  for configuring a dynamic DLP policy and/or a user context responsive to user input. The process  2100  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  2100 , in whole or in part, can be implemented by one or more of the BIM system  1830 , the communications platforms  1876 , the cross-platform DLP system  1846 , the user-context analytics system  1880 , the user-context correlation engine  1882 , the user-context analytics engine  1884 , the context-analytics access interface  1886 , the data store  1888 , and/or the active policy agent  1890 . The process  2100  can also be performed generally by the system  1800 . Although any number of systems, in whole or in part, can implement the process  2100 , to simplify discussion, the process  2100  will be described in relation to specific systems or subsystems of the system  1800  and/or the user-context analytics system  1880 . 
     At block  2102 , the active policy agent  1890  provides an attestation interface to at least one user device. In a typical embodiment, the attestation interface may be provided on, or be accessible from, a real-time risk-evaluation dashboard as described with respect to  FIG. 18  and with respect to block  2016  of  FIG. 20 . In general, the real-time risk-evaluation dashboard may indicate a determined user context of the at least one user. In addition, as described above, the real-time risk-evaluation dashboard may indicate risk assessments provided by the active policy agent  1890 . In many cases, as described above relative to  FIG. 20 , the active policy agent  1890  may have already taken action based on the risk assessments and the determined user context. 
     In certain embodiments, the attestation interface can allow the user to provide attestation input that modifies how the active policy agent  1890  reacts to communication events of interest. In an example, an attestation input can allow the user to indicate that the determined user context is incorrect in determining the at least one user device to be in a public location. In another example, an attestation input can allow the user to indicate that a determined assessment of “risky” or “not risky” for a communication event of interest is incorrect. 
     At block  2104 , the active policy agent  1890  monitors for attestation inputs. At decision block  2106 , the active policy agent  1890  determines whether an attestation input has been received from the at least one user device. If not, the process  2100  returns to block  2104  and proceeds as described above. Otherwise, if it is determined at the decision block  2106  that an attestation input has been received, the process  2100  proceeds to block  2108 . 
     At block  2108 , the active policy agent  1890  adjusts at least one of the user context and the dynamic DLP policy responsive to the attestation input. In typical embodiment, the attestation input serves as a user certification, for example, that the determined user context is incorrect or that a communication event of interest has been inaccurately assessed as risky. For example, if the at least one user device is at the user&#39;s home and not in public location as suggested by the determined user context, the attestation input may so indicate and the active policy agent  1890  can modify the user context accordingly. By way of further example, if the attestation input indicates that a specific communication event of interest is incorrectly assessed as “risky,” the active policy agent  1890  can modify the dynamic DLP policy to allow the communication event of interest (e.g., by adjusting a trigger threshold). In some cases, allowing the communication event of interest can involve performing an action that was previously prevented (e.g., transmitting a communication). 
     At block  2110 , the active policy agent  1890  records the user attestation input in the data store  1888  or in memory. In various embodiments, the recordation can facilitate auditing of user attestations by administrators or other users. In some cases, all user attestations may be provided immediately to an administrator or designated user as an alert. In other cases, all user attestations can be provided in periodic reports and/or in an on-demand fashion. From block  2110 , the process  2100  returns to block  2104  and proceeds as described above. The process  2100  can continue indefinitely (e.g., until terminated by rule or by an administrator or other user). 
     IV. Examples of Event-Based Authentication 
     In certain embodiments, the user context analysis described above can facilitate dynamic authentication of users. In general, users can be presumed to have knowledge of recent user-initiated events for which they are responsible (e.g., events within the last week). In various embodiments, user-specific event information can serve as an effective authentication basis. In general, for a given user, user-specific event information can include event-assessment data, event-context information, correlated event-assessment data, information related to user-communication patterns, user communication profiles, any other event information described above, combinations of same, and/or the like. 
     In an example, instead of, or in addition to, logging into a network resource (e.g., system, device or application) with a standard password, a user can be authenticated using dynamically generated authentication sequences. The dynamically generated authentication sequences can include a plurality of event-information requests that require a user to supply a specific combination of information related to their previous user-initiated events. In an example, the user can be presented with three multiple choice questions that all must be answered correctly to gain access. The questions can ask, for example, “which of the following file names corresponds to a file recently created by you?,” “which of the following images are not in your pictures folder?,” “with which of the following individuals did you have a meeting last week?,” “which of the following corporate applications have you not accessed this month?,” etc. According to this example, a different set of questions and answers can be used for each authentication. 
       FIG. 22  illustrates an example of a system  2200  for performing dynamic event-based authentication. In particular, the system  2200  adds an authentication system  2292  to the system  1800  shown in  FIG. 18 . In general, the authentication system  2292  is operable to authenticate, or validate, that a user has an asserted identity (e.g., as indicated by a user name, email address, etc.). 
     More specifically, the authentication system  2292  can use user-specific event information relating to the user&#39;s user-initiated events to dynamically generate an authentication sequence. For a particular authentication of a particular user, the authentication sequence can include a plurality of event-information requests. Each event-information request can be, for example, a question or prompt that asks for an element of the particular user&#39;s user-specific event information. In various cases, if the particular user provides a valid response to each event-information request, the particular user can be successfully authenticated as having the asserted identity. In certain embodiments, each authentication sequence generated by the authentication system  2292  can be single-use, i.e., usable for one-time authentication of a particular user. 
     As illustrated, the authentication system  2292  can include a data store  2294 . In some embodiments, the data store  2294  can store one or more authentication templates. In general, an authentication template can specify a form or format of an authentication sequence. For example, a given authentication template could specify constraints, or guidance, on user-initiated events that should be used to generate authentication sequences. For example, the given authentication template could express the constraints by specifying particular event types (e.g., events associated with particular content-based classifications as described above), particular event-timing information (e.g., the past two weeks), etc. By way of further example, the given authentication template could specify the exclusion of particular event types or classifications such as, for example, events deemed confidential, strategic, and/or the like. 
     By way of more specific example, an example authentication template could specify a plurality of user-initiated event types (e.g., classifications) and a corresponding event-information request for each user-initiated event type. According to this example, a particular event-information request could specify email communication events and ask “To whom have you not sent an email from your work email address over the past week?” The particular event-information request could specify a format of four answers, three which correspond to people, or email addresses, whom the particular user has contacted over the past week, and a fourth which corresponds to a person, or email address, whom the user has not contacted over the past week. In various cases, the fourth answer can be selected from among the user&#39;s contacts, excluding those contacts whom the user has contacted over the past two weeks. Other event-information requests of the given authentication template can be specified in a similar fashion. 
       FIG. 23  presents a flowchart of an example of a process  2300  for dynamic event-based authentication. The process  2300  can be implemented by any system that can access data, evaluate data, and/or interact with users. For example, the process  2300 , in whole or in part, can be implemented by one or more of the BIM system  1830 , the communications platforms  1876 , the cross-platform DLP system  1846 , the user-context analytics system  1880 , the user-context correlation engine  1882 , the user-context analytics engine  1884 , the context-analytics access interface  1886 , the data store  1888 , the active policy agent  1890 , and/or the authentication system  2292 . The process  2300  can also be performed generally by the system  2200 . Although any number of systems, in whole or in part, can implement the process  2300 , to simplify discussion, the process  2300  will be described in relation to specific systems or subsystems of the system  2200 . 
     At block  2302 , the authentication system  2292  receives a request to authenticate a user of an enterprise computing system. In many cases, the request can be received in connection with the user&#39;s request to access a network resource such as a system, computer, application, etc. In some cases, the authentication system  2292  can provide authentication as a service in support of other computer systems that receive such user requests for access. In these cases, the authentication system  2292  may receive the request independently of any user request to access a network resource. In general, the request identifies an asserted identity of the user (e.g., an email address, user ID, etc.). 
     At block  2304 , the authentication system  2292  determines an authentication context for the authentication request. In a typical embodiment, the authentication context includes characteristics or attributes that may impact a level of security that is warranted. In that way, an authentication sequence that is eventually generated can be variable based, at least in part, on the authentication context. 
     The authentication context can include, for example, any aspects related to a current user context of the user as described above with respect to  FIGS. 18-21  (e.g., user-location information, user-device information, etc.). For example, if the user is in a public location, an unrecognized location, or is using a mobile device or an unrecognized device, a higher level of security can be warranted (e.g., an authentication sequence that includes a greater number of event-information requests). The authentication context can also include details related to a network resource requested by the user, if available. For example, resources or applications that access secure content (e.g., content classified as such in the fashion described above) may also warrant a higher level of security. In embodiments utilizing authentication templates, the block  2304  can include selecting an applicable authentication template that corresponds to the authentication context. For example, in various embodiments, the data store  2294  can include a plurality of authentication templates that each corresponds to a discrete level of security. 
     At block  2306 , the authentication system  2292  selects a set of previous user-initiated events of the user on the enterprise computing system. For example, in embodiments in which authentication templates are utilized, the selected set can be based on a plurality of user-initiated event types specified in the applicable authentication template. In some cases, the user-initiated event types specified by the applicable authentication template can correspond to classifications (e.g., classifications of communications underlying communication events) as described above. In these embodiments, the authentication system  2292  can select the set of previous user-initiated events in conformance to the applicable authentication template. In various cases, the authentication system  2292  can select the set randomly subject to one or more constraints. For example, the set of previous user-initiated events can include a random user-initiated event for each user-initiated event type specified by the applicable authentication template. In general, the set of previous user-initiated events also satisfy any constraints on event-timing information (e.g., the past two weeks, the past month, etc.). 
     At block  2308 , the authentication system  2292  accesses user-specific event information related to the selected set of previous user-initiated events. For example, the authentication system  2292  can access event-assessment data, event-context information, correlated event-assessment data, information related to user-communication patterns, user communication profiles, any other event information described above, combinations of same, and/or the like. The accessed user-specific event information can be stored by the user-context analytics system  1880  (e.g., in the data store  1888 ), the BIM system  1830 , the cross-platform DLP system  1846 , combinations of same, and/or the like. In some embodiments, the applicable authentication template can indicate one or more fields for specific elements of user-specific event information (e.g., a name field for individuals contacted within the last two weeks). In these embodiments, the accessed user-specific event information can include information specified by the applicable authentication template. 
     At block  2310 , the authentication system  2292  generates, from at least a portion of the accessed user-specific event information, a user-specific authentication sequence. In a typical embodiment, the user-specific authentication sequence includes a plurality of event-information requests. Each event-information request can be a question or prompt that asks for a portion of the information contained in the user-specific event information. In some embodiments, the block  2310  can include generating the user-specific authentication sequence in the fashion set forth by the applicable authentication template. In these embodiments, the block  2310  can include populating, for example, fields of the authentication template with particular portions of the accessed user-specific event information. 
     At block  2312 , the authentication system  2292  administers the user-specific authentication sequence to the user. The block  2312  can include publishing the user-specific authentication sequence to the user, for example, via one or more web pages, a dashboard, pop-up prompts, combinations of same, and/or the like. The user-specific authentication sequence can be published all-at-once or progressively (e.g., one-at-a-time). In typical embodiment, the authentication system  2292  requires the user to provide a valid response to each event-information request of the user-specific authentication sequence as a precondition to successful authentication. A failure to do so can constitute unsuccessful authentication. In certain embodiments, successful authentication can result in the user being granted access to a requested network resource. In certain embodiments, unsuccessful authentication can result in the user be denied access to a requested network resource. 
     Although various embodiments of the method and apparatus of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth herein.