Content-based user interface, apparatus and method

Abstract

A Policy- and Relevance-based User Interface (UI) for an enterprise suite Console provides a Console Operator access to information about systems on a network under management. By means of such UI, a user experience is dynamically constructed within product domains particular to the system under management using content elements that flow from content sites into the user environment, populating user interface and driving the Operator experience. Specifications distributed with the content determine how the local Console UI organizes and presents information. The UI is further determined by each Console operator's content access rights. The UI allows for re-flowing the Console UI without reinstalling or updating the Console application, seamlessly integrating new content in to the UI and targeting language to specific working areas.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to customizing a user interface to a current user and a current task. More particularly, the present invention relates to a method and apparatus for dynamically updating a content-based user interface.

2. Background Discussion

Conventionally, software user interfaces are only modified with great difficulty. For example, modifying user interfaces to desktop applications, such as word processors, may require that large portions of the application source code be rewritten. After the source code is rewritten, new object code and machine code must be generated. Following that, the new version of the software must be distributed to the user base. Additionally, because the user interface (UI) cannot be readily modified, users must devise and use workarounds for them, at least until a patch can be distributed or, possibly, until a new release of the software. In dynamic environments, such as unified network management platforms, the profusion of tasks, roles, types and sources of content and environment render the overall task of management of the environment extremely burdensome with a conventional static UI.

SUMMARY

A Policy- and Relevance-based User Interface (UI) for an enterprise suite Console provides a Console Operator access to information about systems on a network under management. By means of such UI, a user experience is dynamically constructed within product domains particular to the system under management using content elements that flow from content sites into the Operator environment, populating the UI and driving the Operator experience. Specifications distributed with the content determine how the local Console UI organizes and presents information. The UI is further determined by each Console Operator's content access rights. The UI allows for re-flowing the Console UI without reinstalling or updating the Console application, seamlessly integrating new content into the UI and targeting language to specific domains.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 provides a diagram of a machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one of the methodologies discussed herein below, may be executed;

FIG. 2 provides a block diagram of a unified platform for policy-driven communication and management;

FIG. 3 provides a screenshot of a content-driven interface in the platform of FIG. 1;

FIG. 4 provides a diagram of content flow in the platform of FIG. 2;

FIG. 5 provides a diagram illustrating how domain specifications from sites and users' site access permissions interact to produce the end-user UI experience in the platform of FIG. 1;

FIG. 6 provides a diagram illustrating several ways a domain's interface could be organized based on the domain specification included with the content;

FIG. 7 provides a diagram of an import process in an automated content generator from the platform of FIG. 2;

FIG. 8 provides a diagram of an export process in an automated content generator from the platform of FIG. 2;

FIG. 9 provides a diagram of a reporting module from the platform of FIG. 2

DETAILED DESCRIPTION

Definitions

• Action: actions are typically scripts that can customize a specific solution for each Client, using Relevance expressions. Although the Relevance language itself can't alter a Client, it can be used to direct actions in a way that parallels the original trigger. For instance, a Fixlet might use the Relevance language to inspect a file in the system folder. Using a similar Relevance clause, an Action associated with the Fixlet can then target that same file without knowing explicitly where that folder resides. This allows the Action author (and issuer) to concentrate on the issue at hand without worrying about the vagaries of each individual computer system.
• Agent: Software that resides on Client and acts as a universal policy engine capable of delivering multiple management services. A single Agent can execute a diverse and extensible array of management services ranging from real-time Client status reporting, to patch and software distribution, to security policy enforcement. By assigning responsibility for reporting and management actions to endpoints themselves, the Platform enables visibility and management of IT infrastructures ranging from hundreds to hundreds of thousands of desktop, mobile and Server computers.
• Client: an endpoint device in a network under management by a Platform for policy-driven communication and management infrastructure.
• Console: an operations control center for administrators, that includes graphical displays of device, group, and enterprise-wide device status and dashboards for executing management actions through the infrastructure. The Console also includes reporting functions and templates that enable graphical and tabular views of infrastructure status.
• Dashboard: Dashboards are content-defined UI elements that users interact with in the main window of the Console. Dashboards tap into the Platform Database to provide the Operator with timely and compact high-level views of the network. They use session relevance to access and display a subset of all data stored in the database. For example, the BES License and Inventory site contains the Application Usage Dashboard, which shows constantly updated statistics about various executables on client computers. Other Dashboards may report on the BES Deployment, or the status of Patch rollouts, for example.
• Fixlet or Fixlet message: a piece of content included in sites that contains two major parts. First, a Fixlet contains relevance that assesses the status of the client with regards to specific questions, such as the version of a given file or the value of a given registry key. Secondly, a Fixlet contains an action definition that describes changes to be made on the endpoint. The relevance is evaluated on the client by the agent; console operators can create Actions from the Fixlet action definition, which are then distributed to targeted clients via the agent.
• Relay: A Relay is a software module that executes as a shared service on non-dedicated hardware. Alternatively, “Relay” can refer to the hardware on which Relay software is running. Relays act as concentration points for Fixlet messages on network infrastructures and help reduce network bandwidth requirements for distribution of Fixlets and content such as software, patches, updates, and other information. Relays also offer a failover mechanism to keep managed Clients in touch with the Console should normal communications channels go dark or become overloaded with other traffic.
• Relevance: a human-readable language for querying properties of the client. Relevance is evaluated by the agent on the client. Agents evaluate the relevance included in Fixlets and Analyses and report the results to the Server. The Console reports aggregated results of these Fixlets and Analyses to Console Operators. Relevance can also be used to customize and target Actions to the specific circumstances of the client. Thus one can feel confident that only broken machines are being fixed and that the rest are never bothered.
• Session Relevance allows for the inspection of information stored in the System Database. Session relevance allows for the inspection of concepts beyond computer properties, such as properties associated with Sites, Operators, Fixlets, and Actions; for example, a Session Relevance expression can be written to return true if a specific piece of content (a Fixlet) is applicable on any computer on the network.
• Server: Software that provides a control center and repository for managed system configuration data, software updates and patches, and other management information. In the alternative, “Server” can denote a computing machine running such software within a network under management.
• Site: Sites are collections of Fixlet messages, Dashboards, Wizards, and other content to which an Operator of a Platform deployment may subscribe one or more Clients in the Operator's network. Sites may be created by the Platform manufacturer or by one or more third parties. Additionally, deployment Operators may create custom sites that contain internally generated content.
• Wizards: Content that provides an interface for the creation of new Fixlet messages or settings. They generally involve a step-through question and answer interface.Computing Environment

The invention operates within a computing environment. One embodiment of a suitable computing environment is described here.

Referring now to FIG. 1, shown is a diagrammatic representation of a machine in the exemplary form of a computer system (100) within which a set of instructions for causing the machine to perform any one of the methodologies discussed herein below may be executed. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, personal digital assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.

The computer system (100) includes a processor (102), a main memory (104) and a static memory (106), which communicate with each other via a bus 108. The computer system (100) may further include a display unit 110, for example, a liquid crystal display (LCD) or a cathode ray tube (CRT). The computer system (100) also includes an alphanumeric input device (112), for example, a keyboard; a cursor control device (114), for example, a mouse; a disk drive unit (116), a signal generation device (118), for example, a speaker, and a network interface device (128).

The disk drive unit (116) includes a machine-readable medium (124) on which is stored a set of executable instructions, i.e. software, (126) embodying any one, or all, of the methodologies described herein below. The software (126) is also shown to reside, completely or at least partially, within the main memory (104) and/or within the processor (102). The software (126) may further be transmitted or received over a network (130) by means of a network interface device (128).

In contrast to the system (100) discussed above, a different embodiment of the invention uses logic circuitry instead of computer-executed instructions to implement processing offers. Depending upon the particular requirements of the application in the areas of speed, expense, tooling costs, and the like, this logic may be implemented by constructing an application-specific integrated circuit (ASIC) having thousands of tiny integrated transistors. Such an ASIC may be implemented with CMOS (complementary metal oxide semiconductor), TTL (transistor-transistor logic), VLSI (very large scale integration), or another suitable construction. Other alternatives include a digital signal processing chip (DSP), discrete circuitry (such as resistors, capacitors, diodes, inductors, and transistors), field programmable gate array (FPGA), programmable logic array (PLA), programmable logic device (PLD), and the like. It is to be understood that embodiments of this invention may be used as or to support software programs executed upon some form of processing core (such as the Central Processing Unit of a computer) or otherwise implemented or realized upon or within a machine or computer readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine, e.g. a computer. For example, a machine readable medium includes read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals, for example, carrier waves, infrared signals, digital signals, etc.; or any other type of media suitable for storing or transmitting information.

Unified Management Platform

An embodiment of the invention operates in the context of an enterprise management platform, as described in this section.

Referring now to FIG. 2, shown is a unified management Platform (200) for creating a policy-driven, communications and management infrastructure for delivery of security and management services to networked computational devices, such as desktop, laptop/notebook and Server computers. In an embodiment, components of the Platform may include at least one Client (202) running an Agent, at least one Server and Console (204), Fixlet messages (indicated by the arrows showing data flow between elements), and at least one Relay (206). In addition to the Relays (206), a Relay hierarchy typically includes a top-level Relay (208) that directly interacts with the Server (204).

Key components of the Platform include the Agent (202), the Server and Console (204), the Fixlet messages, and the Relays (206), (208). The Platform creates a lightweight communications and management infrastructure for delivery of security and system management services to networked desktop, laptop/notebook and Server computers. By assigning responsibility for reporting and management actions on endpoints themselves, the Platform enables visibility and management of IT infrastructures ranging from hundreds to hundreds of thousands of desktop, mobile and Server computers.

The Agent (202) resides on managed devices and acts as a universal policy engine capable of delivering multiple management services. A single Agent (202) can execute a diverse and extensible array of management services that range from real-time Client status reporting, to patch and software distribution, to security policy enforcement.

The Agent's role in the Platform may be described as that of a Policy Engine: a piece of software and a computational context for evaluating content. Thus, the Agent constitutes a computational resource that uses one or more inspectors to examine its context, decide what is relevant, report properties, take Action in that environment, and report on the success or failure of the actions. Thus, the Agent gives an administrator visibility into the context and controls it. The motivation for provision of a policy engine thus may be the realization that any computing resource, including physical or virtual machines, or a machine, that is a delegate for another machine or a piece of hardware can benefit from management by having a policy engine that can inspect properties of the entity that is being managed, apply changes to the environment and report on the fact that those changes were effective or not.

The Agent also automatically, notifies the Server and Console (204) of changes in managed device configuration, providing a real-time view of device status. In addition to a standard array of management services, customers and developers can create custom policies and services using a published authoring language. In various embodiments, the Agent runs on all versions of the MICROSOFT WINDOWS (Microsoft Corporation, Redmond Wash.) operating system since WINDOWS 95, UNIX, LINUX and MAC OS (APPLE, INC., Cupertino Calif.) Client systems, enabling administrators to consolidate management of heterogeneous infrastructures from the Console.

The Server (204) is a software-based package that provides a control center and repository for managed system configuration data, software updates and patches, and other management information. In an embodiment, the Console (204), provides an operations control center for administrators that includes graphical displays of device, group, and enterprise-wide device status and dashboards for executing management actions through the management infrastructure. The Console may also include reporting functions and templates that enable graphical and tabular views on infrastructure status.

Fixlet messages contain relevance based queries regarding client properties. These queries are interpreted by the Agent (202), and the results are reported back to the server. As noted above, in an embodiment, users have the option of writing custom Fixlet messages.

Relays (206), (208) act as concentration points for Fixlet messages on network infrastructures. Relays are a software module that execute as a shared service on non-dedicated hardware. Relays help reduce network bandwidth requirements for distribution of Fixlets and content such as software, patches, updates, and other information. In an embodiment, Relays (206), (208) include a failover mechanism to keep managed Clients in touch with the Console should normal communications channels go dark or become overloaded with other traffic. In an embodiment, Relays allow an N-tier hierarchy to be created for the transmission of information from the Clients to the Server in the enterprise.

The unified management Platform provides real-time visibility and control of IT systems through a. single infrastructure, single agent and unified Console. The Platform is designed to continuously discover, assess, remediate, and enforce the health and security of servers, desktops, and roaming laptops in real-time via a single policy-driven Agent and single Console. The aspects of IT systems that are evaluated are determined in part by content on sites to which the Platform is subscribed. Sites can be distributed to the Platform by external entities, or created from within the Platform itself. Each site contains a variety of related content that can be evaluated by Agents installed on local systems. The Console aggregates data reported from clients on the local deployment. The Platform distributes content from a variety of Sites, ranging, for example, from operating system patching to power management to anti-virus. Each site contains a variety of content in different domains. Local deployments are subscribed to a given subset of sites, and Console users can have access to all or a subset of the deployment's Sites.

The Console interface described herein provides an overall structure for the presentation of subscribed sites. The sites include information regarding how their contents will be organized in the interface, from how individual documents are grouped together, to the language used to present content, to how different sites are combined into one top-level container, called a domain. This means that to a large degree, the Console interface is determined not by the local application but by the sites to which the user is subscribed.

Content-Driven Interface

FIG. 3 shows a screenshot of the Content-driven interface (300). The left half of the image shows the sections of the interface that are defined by content. Domains (302) are abstract containers for multiple sites. Selecting a domain in the lower-left of the interface displays the domain's Dashboard Filters (304) and Tree lists (306) in the upper-left of the interface. The layout, organization, and naming of these Dashboard Filters and Tree lists is defined by the specifications included with the content sites. Selections made in the Tree lists and Dashboard Filters drive the Content List (308) and Content Pane (310) located on the right side of the interface. The Content List displays lists of content, and the Content Pane displays details of individual pieces of content.

Domains (302) aggregate content from an arbitrary number of sites. Only sites to which the operator is given access are displayed in the console. Tree lists (306) are hierarchical organizations of the sites' contents. The naming and ordering of nodes in the Tree lists, as well as the elements contained by the nodes, are defined by content, not by the locally installed application. The Dashboard Filter (304), which is part of a site, allows for the further manipulation of the tree list. By means of a domain specification, sites (not shown) define the naming, ordering, and elements of each container in the Tree List, as well as how Tree lists and Dashboard Filters are arranged. Filters (e.g. “Tasks” as shown in the Tree list (306)) present content in the Content List. Folders (e.g. “Wizards” as shown in the Tree list (306)) present individual pieces of content or filters.

FIG. 4 represents an abstract schematic of the flow (400) of interface information. Fixlet Servers (402) outside the customer environment send out content sites (404) containing the domain specifications, which define both how Sites are combined into functional domains, and how the sites' Content is presented within the domains. In local deployments (408), a local server (410) is subscribed to a set of these sites. Sites to which a customer is subscribed are downloaded to the local server (410). Each Console Operator (412) is given access to a subset of subscribed sites, according to the Operator's profile. On the Console (414), a Domain combines content from different sites into folders and lists whose structure is determined by its Sites' domain specifications. The Console (414) only presents Operators with Domains containing sites to which they have been given access.

The Console UI an Operator views depends on the specific content to which the Operator has access. This means different operators on the same deployment will have different experiences when using the console. FIG. 5 shows a diagram (500) of how domain specifications from sites and users' site access permissions interact to produce the end-user UI experience. Sites define the UI of domains (502), and users (504) are given access to particular sites. In the Console (506), users only see domains that contain sites to which they have access. So each Operator sees a UI that is appropriate to the role the Operator has within their environment. Accordingly, a single UI can serve both, for example, the Chief Security Officer who wants to see the network's status relative to a set of compliance measures or the systems administrator who wants to see the network's status relative to the installation of operating system updates.

Each domain provides language and user interface elements that map directly to that particular problem domain. Domains also allow for focusing the UI. An undifferentiated list of the Fixlets in a deployment can number in the tens of thousands. Domains can narrow that number to less than one hundred. FIG. 6 shows how a Tree List in an exemplar domain, “Patch Management”, can be organized in several different ways according to the customer environment (600). This domain contains UI content related to operating system and application patches. In the Windows Only version (602) of the Tree List, the Operator would only see content related to Windows Patches. All nodes use language appropriate to Windows Operating Systems. For example, under the “Updates” folder, there is a node for “Rollups and Fixlets.” An operator who is only responsible for updating Windows computers might see this view, as they are only subscribed to Windows content.

A second version of the Tree List (604) shows the view of an operator with access to both Windows and Red Hat patching sites. There is an evident difference in the number of security bulletins for example −24 37 vs. 2567. Another key difference to see here is that the “Updates” folder now has nodes with language specific to the Red Hat environment, such as “Redhat Enhancements.” An operator responsible for patching both Windows and Red Hat operating systems might see this view.

The final version shows a Tree List using that does not use language that is specified to any specific operating system (606). This generic interface contains a greater number of Fixlets, indicating it is consolidating patches from additional operating system sites.

This exemplifies several key points. First, the UI is determined by the sites to which the user has access, and uses language that is appropriate to the tasks of the individual operator. Thus role-specific UIs are dynamically provisioned. Secondly, while the organization of 602 and 604 is distinct from the organization of 606, these differences are defined in the sites themselves, and can thus be changed dynamically without modifying the code base of the locally installed application.

The domain specification may be based, at least in part, on the notion of session relevance. Session relevance is used to describe both the contents of each node in the Tree list, as described above, and in determining whether or not a particular content type or a particular piece of content is displayed. The latter allows the UI to change, not only according to User and task, but also according to changes in a deployment.

For example, if a new type of computer shows up in a customer's deployment, in response, a new section of the Patch Management UI shows up. Thus, the UI customizes itself to the environment it finds itself in by examining characteristics of the deployment that is being interacted with.

It is apparent that these notions are applicable to all, or nearly all, domains, such as security configuration management and endpoint protection. So in that domain, one is interested in the conformance of all machines to a set of security policies such as password complexity, or perhaps, patch status or anti-virus status. Certain content types may fall into several domains, which can be achieved in this paradigm.

Content-Driven Interface Embodiment Notes

As noted above, the practice of relevance evaluation, which previously has been limited to Agents running on Clients, as first described in U.S. Pat. No. 6,256,664, now extends beyond the Agent. While earlier work is concerned with relevance in the context of a machine or properties of the network around the machine, as describe herein, relevance evaluation is now applied in the context of the Console and the context of deployment. Where previously decision making was performed on the endpoint by an Agent running on the endpoint, decision making is now distributed to Consoles in addition to Agents. One or more Domain Specifications are included with a content site. Each domain specification uses session relevance to describe the contents of each UI entity. The console interprets the domain specifications, and merges the definitions from multiple sites into a single coherent UI. Multiple sites can place contents in single containers, and individual sites can place content in nodes of multiple domains. Thus, as content comes in, it signals to the Console the circumstances in which it is relevant and how it should be presented to the user.

Properties and Data

The session relevance used by the interface paradigm described here inspects properties of the content distributed with the sites as well as properties associated with the clients, as reported by the agents. Some of these properties are inherent to the content itself, such as the severity value of a Fixlet, which is a part of the Fixlet itself. Others are based on reported values by many computers, for example the number of computers on which a specific Fixlet is applicable.

Session Relevance, described above, is used to query these properties and plays a large part in the definition of the interface by the sites' domain specifications.

Domain Specification

As above, a domain specification XML (eXtensible Markup Language) document is included with each site. This specification contains a section for each domain in which the site places content. The domain specification contains the information that fully describes how the site's contents should be presented within the UI. The domain specifications from sites to which the Operator has access are interpreted by the console.

Each domain is assigned a code that allows it to be recognized by the Console, a name the Console uses to display the domain, and an icon used to represent the name.

Domain specifications can define tree lists. These lists contain hierarchical nodes of a variety of types, such as folders, lists, and drill-down lists. The names of these nodes are defined in the specification, and the contents of each node are defined by means of session relevance. The domain specification may identify Dashboard Filters to be included in the interface. These are arbitrary HTML documents that can include session relevance, and are also distributed with the site This allows a variety of functionality. The dashboard can allow for further refining of the tree-list. For example, a checkbox in the dashboard could tell the tree-list to only present nodes and fixlets containing content relevant to Windows operating systems. The dashboard could also query the database to prominently display important information, for example out of date licenses.

Two additional important concepts are sort order and conditions. A numerical sort order value for each node describes the order in which it should be presented. Lower numbers are presented above higher numbers. These can be defined for nodes in the tree list. Sort order is also used to describe the order in which domains should be presented, and the order in which Tree Lists and Dashboard Filters are presented.

Conditions are relevance queries that allow the domain specification to define when it should and should not be presented in the interface. For example, a filter node may have a condition that only makes it visible when any of its content is relevant on any machine. Conditions can be used on any node in a tree list, as well as on dashboards.

To present an interface to the user, the Console must merge the domain specifications from the different sites. It does this by combining the definitions of each UI element that are included in the different domain specifications to which it is subscribed. Referring again to FIG. 6, in the Traditional Organization (606), the “Fixlets” container for example combines the contents of multiple sites. A domain specification from each site uses session relevance to define the site's contribution to the node. The console combines the contents from all sites into a single node. It only uses specifications from the sites to which the logged in operator has access.

Advantages

A major advantage of this UI paradigm is that the interface can be modified without changing the locally installed applications. This has a variety of benefits, including at least the following:

• Arbitrarily combining information from multiple sources: Customers have multiple sources of information available to them in the form of sites produced outside their environment or ones produced by their own users. The paradigm presented here allows these disparate sources to be presented to users in a unified manner.
• Seamless integration of new content: In this paradigm, new content can be integrated into the current interface in a variety of ways. If it is highly related to existing content, it can be automatically placed within nodes previously defined in the domain specification. If the new content provides additional functionality but resides within the same domain, a new node can be created in a tree-list. If the new content is completely new, a new domain can be created.
• Rapidly Refreshing Interface: This paradigm allows for rapidly enhancing the interface without requiring customers to install new software. If improvements are made, the new domain specifications are automatically sent to the customer, whose Consoles immediately display the new interface.
• Linguistic Specificity: As all language is defined outside the Console, the language presented to the user does not rely on any pre-set taxonomy. Instead it can be content-specific, addressing users' workflow. As new content is produced, appropriate organizational language can be sent along with the content itself.Use Cases
• Restricting view for newly subscribed content: When a customer has just subscribed to a site, there are often a restricted set of setup tasks that must be completed before they can benefit from the full functionality of the site. These setup tasks can be hidden among the large quantity of content distributed with the site. Using relevance queries, the domain specification can determine whether the site needs to be setup at the customer site. If it does, the domain can hide all non-related content, making it easier to find the appropriate setup content. It can also organize the setup content into easy steps.
• Patching for different users: Patching of operating systems and software is one of the most powerful features of the Platform. Content may be split up across different Operating System sites, such as windows OS languages, RedHat Linux, and the like. The domain specs can be modified to target patching language, as shown in FIG. 5, example 502, or they can be written to organize content according to more generic Platform concepts, as in FIG. 5 example 504. Both examples can be distributed with the same content, and the user can select which one they want to see.

If users have limited access to sites, they will see a limited version of the Console. For example, if they only have access to one site, a dashboard filtering Windows and Linux sites could be hidden from the user as it would be unnecessary.

Content Factory Summary

The content-driven interface described above has substantial advantages in the case where all of the UI-defining content is supplied directly through sites external to the customer's deployment. However, a further refinement is possible.

In the content factory model, the content factory contains logic to dynamically generate content based on input supplied by the user. In addition to generating content, a domain specification can be created to define the UI within the console. This UI can rely on the structure inherent to the input stream. Thus, UI is automatically generated alongside new content without modifying the local application code.

As an example, a user might interact with a dashboard A to express requirements specific to their environment, and based on those requirements, a dashboard B might be generated which addresses those requirements. Dashboard B, which by itself is a dynamically generated UI, will then be placed in a tree list in the console by an automatically created domain specification.

The content factory might be traditional platform content, or it might be hosted in another environment, as described in the example embodiment below.

Decision Support System (DSS)

As background for the example Content Factory Embodiment discussed below, it is helpful to understand the BigFix concept of a Decision Support System.

In an embodiment, a decision support and reporting system (DSS) may include its own data warehouse, web interface, data connector and associated administrative functions, providing the ability to move easily from an executive level macro view of the entire environment through domain and role-specific lenses and into a granular view micro view of specific problem sets. The purpose is to add a level of decision support and intelligence on top of the abstracted data. The DSS includes federation and reconciliation functions that allow us to move beyond a particular data source, such as data from the unified management platform described above and to incorporate other areas of IT, such as network context, application and user provisioning.

Using the DSS, it is possible to convert data into meaningful information to support optimized systems and security operations and risk and compliance management for the enterprise, and additionally support federation and reconciliation of data.

Capabilities:

• • Data integration and normalization across computers that allows organization to integrate and correlate information silos;
  • Data warehouse that allows for trending/persistent store for reporting;
  • Providing comparative and trended information to empower enterprise management to be able to see, act and optimize their systems and security;
  • Framing aggregated information into specific views aligned w/ business, operations, risk, security and compliance environments;
  • Ability to drill down by various dimension for reports—in aggregate, by business unit, by asset, by geography class, or whatever is defined and required by the customer;
  • Ability to add business value parameters as to asset value, and network configuration context;
  • Ability to add information about current threat environment;
  • Ability to synthesize asset, vulnerability, and threat data into risk assessment and remediation policy;
  • Distilling complex granular information synthesized for domain and role-specific consumers; and
  • Dashboard capable of delivering unified, real-time visibility and control.

Accordingly, the DSS gives high-level analytics of any systems management situation. Thus, an existing platform such as the unified management platform described above gives a real time live view of what's going on in the enterprise and the ability to control it. DSS then takes that information and builds on top of it an analytics layer.

DSS has a data warehousing capability and a Web application stack capability married with a data feed, such as a unified management platform described above data feed and the practice of having domains flow down to the customer's deployment in content.

Thus, rather than it being a traditional, central software service model, it is out at the endpoint with applications that flow down from a central server into their environment to actually sample the properties of the environment, such as actual properties of machines, for example, the fact that there's a file named Excel.exe that's sitting on a certain machine in a certain location with certain properties, like a version number and a date that it was created.

Taking such raw information and then being able to process it into a form that is consumable by somebody who wants to understand what sets of software they've purchased and where it exists in their environment requires a complex process to figure out, for example, that someone purchased a version of Microsoft Office that included that executable with those properties and installed it on a particular machine.

Since the foregoing constitutes automatic creation of policies, it can also automate creation of all the content that a particular domain needs, as described herein below. Such automated content creation may include the domain specification and how the UI should look, being incorporated into a tool that allows, for example, a high-level person or a person who is not an operations person or even someone who knows what the platforms are, to create a description of what they want, do little more than push a button, and that specification flows, with the appropriate UI and workflow, to each person in the operations chain who needs to be involved. It is not just policies for the endpoint. It can be polices for the Console, it can be appropriate reports in other reporting environments. It can be that entire content stream.

Example Content Factory Embodiment

An example embodiment of a content factory addresses the use case of Systems and Configuration Management against third-party security standards. In this use case, a non-operational user needs to review an enterprise security and compliance posture against published third party standards, and make policy decisions based on that information. Those policy decisions are translated into generated platform content according to the content factory model, resulting in new, dynamically generated UI components being presented to the Console operator.

In this embodiment, types of supported inputs include at least:

• • SCAP (Security Content Automation Protocol) XML Stream;
  • INF (Setup Information File) Export from a Microsoft Windows Domain Policy/Computer Policy;
  • Unix Script Library; and
  • Custom Defined OVAL (Open Vulnerability and Assessment Language) Definitions.

The process is broken down into separate phases, for example:

• • Import of a standard into DSS; and
  • Export of BigFix Fixlet Messages from DSS into BES.Import Summary

In an embodiment, a tool in the unified platform imports content from arbitrary streams directly into the platform, translating the streams into Fixlets, Analyses, and Specifications that describe how the content should be presented in the Console UI.

In another embodiment, the import process (700) may be called by DSS (702) or run stand-alone command line (704). It will accept a variety of inputs based on the format of the content to import. For INF imports, a metadata content file is usually available. To ease the import process, a DSS catalog Operator may match checks up to an internal ID before import using some UI in DSS. The process works by the following flow:

• • Controller calls for import (706):
    • Type of Import:
      • INF (712)
        • Load Metadata;
        • Load INF;
      • SCAP Parser (710)
        • Resolve XCCDF Document;
        • Iterate over defined and selected Rules;
        • Attach OVAL to Rule Definitions and simplify OVAL;
      • Unix Importer (708)
        • Load Unix script library;
        • Convert to custom XML Namespace*;
        • Attach Metadata;
      • Raw OVAL (716)
        • Load Metadata (714);
  • Attach defined checks to existing control definitions if possible using a Metadata management library; and
  • Insert specific metadata for standard; and
  • Call OVAL Processor to generator OVAL; and
  • Call DSS Inserter (718) to insert OVAL definitions.Export Summary

In this embodiment, the export process (800) may be called from DSS (702) to the SCM Export Controller (802). The controller reads in the defined policy (804) from the DSS (702) database and pulls out all required information to create content. There exist several types of content created with options on some of the content, for example:

Per policy:

• • Analysis (812)
    • The analysis created returns the values for the controls only;
    • The targeting of the analysis is may be to all computers managed by the policy in question;
  • Fixlet Message (814)
    • The Fixlet Messages may have options for including remediation or not;
    • Each Fixlet may have its Relevance contained within a constraining relevance statement determined by the targeting, done by DSS.

In this embodiment, during the generation process the controller script may verify whether or not a policy has been propagated before, if so it may update the existing content. The controller script can also be used to remove a policy if desired.

The export process is as follows:

• • Export Controller (802) called by DSS (702);
  • Controller reads in policy (804) information;
  • Loads targeting information for the policy;
  • Loads controls:
    • Loads metadata (806) for each control;
    • Generates relevance from loaded OVAL;
    • Applies targeting relevance to check relevance (808);
  • Verify whether or not this policy has been propagated before;
  • Build Fixlet objects with relevance and description metadata; and
  • Insert new policy objects (Fixlets, analyses) into site (816) per policy.Script Functional Details
• INF Generator Script: This script processes INF files that have been exported from a Windows Domain or Local Policy. It reads from CONFIG.INI which defined the many options related to each of the different operating systems. This script processes the INF file by section, and loads an appropriate module per section. That module creates relevance from the items within that section.

The metadata for this script is stored in INI file format, which may be loaded along with the INF file during the import process.

• Modifications Script: This script may be modified by making a different branch of modules. The new modules, instead of generating relevance, generate OVAL definitions.

In an embodiment, the default INF format may be extended to include an Extern section which reads information in from an XML file for the check.

• SCAP Parser Script: In an embodiment, this script processes a folder containing an SCAP XML (eXtensible Markup Language) stream. It processes an XCCDF (eXtensible Configuration Checklist Description Format) document according to standard and resolves the document to a profile defined inside the document. When the list of selected Rules have been determined it then loads up the OVAL objects related to each rule and creates relevance from those OVAL definitions. The metadata from this script is acquired directly from the XCCDF document.
• Unix Importer Script: In this embodiment, this script may receive the location of the Unix scripts and operating system, then build an index of all of the controls covered, after which, associated metadata may be inserted. The information may be stored in an XML namespace of, for example, bigfix-scm-unix. The output may be OVAL. In an embodiment, the OVAL output may be extended by other namespaces.
• Oval Processor Script: The OVAL Processor has at least two uses:
  • verifying internal OVAL and simplifying it; and
  • export relevance from the OVAL definitions created.

Because the OVAL definitions in SCAP are needlessly complex, on import, the script simplifies the definitions considerably.

The export portion may include modules defined for the entire OVAL standard. This portion of the script generates certain QA-specific files for testing.

Each of the modules defined may relate to an OVAL object type, i.e. fileeffectiverights54_object. The module may receive the raw XML as an input and return relevance that evaluates true if the conditions are met and false if they are not. This logic may be inverted when inserted into a Fixlet in order to make writing the relevance easier and the testing clearer.

• Metadata Management Library: In this embodiment, a metadata management module is not a script, but a library. This may control what metadata gets imported and exported from DSS and how it is represented in the Fixlet. In an embodiment, it is library in which the inputs are the DSS database or a standardized representation of all the variables and data associated. In the case of parameters the format may be XSD (XML SCHEMA Document).
• DSS Inserter Script: In this embodiment, the DSS inserter may harness database code from the DSS Rails application to insert the data from the OVAL Processor and Metadata Management module. An embodiment includes code logic to detect if the control has already been defined, or whether a new internal control ID should to be established.
• Content Generator Script: In this embodiment, this is the script that actually creates the different kinds of content in BES. This script may load OVAL definitions via the Rails framework, and load metadata via the Metadata management library. It receives an input of a policy, and some options (for example, defined in the policy itself) to determine whether it is creating an analysis, Fixlets with remediation or Fixlets without. It may use some executable delivered from Platform like the PropagateFiles.exe used in the Trend content to create content. This script generates relevance from the OVAL definitions and creates Fixlets by combining that and the Metadata. The script also gathers targeting information from DSS and creates constraint relevance that encapsulates the actual check relevance. The analysis it creates has constraint relevance as the analysis relevance and is not in each property.Illustrative Spirit of Description

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. In a unified network management platform, a process for modifying a user interface in real time without changing locally-installed applications comprising; receiving, at a console, a plurality of content streams from a server for a plurality of content sites to which a user of the console subscribes, wherein each content site provides a domain specification strictured document containing presentation information for each domain in which the content site places content, the presentation information describing how content is to be presented within a domain in a user interface based on relevance information;determining, by the console, which of the plurality of content sites have relcv to current conditions of use based on the relevance information;creating, by the console, a distinct interface tailored to each relevant content site based on the current conditions and the domain specification structured documents received from the plurality of content sites; anddynamically merging, by the console, the distinct interfaces into a common interface such that the pity, of content streams are presented to the user in a unified manner in at least one domain based on the domain specification structured documents, wherein the at least one domain is a container aggregates content from the plurality of content streams.

2. The process of claim 1, wherein each content site comprises a collection of related content distributed to subscribed entities.

3. The process of claim 1, wherein said conditions of use comprise at least one of: a user's identity;a user's access levela task; ora network environment.

4. The process of claim 1, further comprising at least one of: said Console integrating new content into a current interface by placing said new content within nodes previously defined in a domain specification;said Console integrating new content that provides added function into an existing domain in a new node of a tree list; orintegrating new content into a newly-created domain.

5. The process of claim 1, further comprising: said platform automatically distributing a new domain specification structured document to a subscribed user; andin real-time, said Console updating the interface to reflect the new domain specification structured document.

6. The process of claim 1, comprising: displaying at least one Dashboard filter in the user interface, wherein the dashboard filter is defined by information from at least one content site;displaying at least one Tree List in the user interface, wherein the Tree List is defined by information from at least one content site;displaying at least one Content List in the user interface, wherein the Content List is driven by selections in the at least one Tree List; anddisplaying at least one Content Pane in the user interface, wherein the Content pane displays content from the Content List or the Tree List.

7. The process of claim 6, further comprising: said Tree list providing containers for Content, content including one or more of and Folders.

8. The process of claim 1, further comprising: displaying in the user interface content that is automatically aggregated or generated by a decision support system (DSS).

9. The process of claim 1, wherein the server is a laical server that is local to the console and wherein the local server subscribes to the plurality of content sites and downloads the plurality of content streams to the local server.

10. The process of claim 1, wherein each domain specification structured document comprises an extensible markup language document.

11. The process of claim 10, wherein each domain specification. structured document contains a section for each domain in which the corresponding content site places content.

12. A computer program product for modifying a user interface in real time without changing locally-installed applications comprising in a unified network management platform comprising a tangible, computer-readable non-transitory storage medium having computer-readable instructions embodied thereon for: receiving, at a console, a plurality of content streams from a server for a plurality of content sites to which a user of the console subscribes, wherein each content site provides a domain specification structured document containing presentation. information for each domain in which the content site places content, the presentation information. describing how content is to be presented within a domain in a user interface based on relevance information;determining, by the console Which of the plurality of content sites have relevance to current conditions of use based on the relevance information;creating, by the console, distinct interfaces each is distinct interface being tailored to a respective relevant content site based on the current conditions and the domain specification structured document received from the plurality of content sites; anddynamically merging, by the console, the distinct, interfaces into a common interface such that the plurality of content streams are presented to the user in a unified manner in at least one domain based on the domain specification structured documents, wherein the at least one domain is a container that aggregates content from, the plurality of content streams.

13. The computer program product of claim 12, wherein each content site comprises a collection of related content distributed to subscribed entities.

14. The computer program product of claim 12, wherein the platform automatically distributes a new domain specification structured document to a subscribed user and in real-time, the console updates the interface to reflect the new domain specification structured document.

15. The computer program product of claim 12, wherein the console displays at least one Dashboard filter defined by information from at least one content site, at least one Tree List defined by information from at least one content site, at Least one Content List driven by selections in the at least one Tree List, and at least one Content Pane that displays content from the Content List or the Tree List.

16. The computer program product of claim 12, wherein the user interface displays content that is automatically aggregated or generated by a decision support system (DSS).

17. The computer program product of claim 12, wherein the server is a local server that is local to the console and wherein the local server subscribes to the plurality of content sites and downloads the plurality of content streams to the local server.

18. The computer program product of claim 12, wherein each domain specification structured document comprises an extensible markup language document.

19. The computer program product of claim 18, wherein each domain specification structured document contains a section for each domain in which the corresponding content site places content.

20. In a unified network management platform, an apparatus for modifying a user interface in real time without changing locally-installed applications comprising: a processor; anda memory coupled to the processor, wherein the memory comprises instructions which, when executed by the processor, cause the processor to:receive, by a console, a plurality of content streams from a server for a plurality of content sites to which a user of the console subscribes, wherein each content site provides a domain specification structured document containing presentation information for each domain in which the content site places content, the presentation information describing how content is to be presented within , domain in a user interface based on relevance information;determine, by the console, which of the plurality of content sites have relevance to current conditions of use based on the relevance information;create, by the console, distinct interfaces, each interface being tailored to a respective relevant content stream based on the current conditions and the domain specification structured documents received from the plurality content sites; anddynamically merge, by the console, the distinct interfaces into a common interface such that the plurality of content streams are presented to a user in a unified manner in at least one domain based on the specification structured documents, wherein the at least one domain is a container that aggregates content from the plurality of content streams.

21. The apparatus of claim 20, wherein each content site comprising a collection of related content distributed to subscribed entities.

22. e apparatus of claim 20, wherein said conditions of use comprise at least one of: a user's identity;a user's access levela task; ora network environment.

23. The apparatus of claim 20, wherein the instructions further cause the processor to: integrate new content into a current interface by placing said new content within nodes previously defined in a domain specification;integrate new content that provides added function into an existing domain in a new node of a tree list; orintegrate new content into a newly-created domain.

24. The apparatus of claim 20, wherein the instructions cause the processor to: automatically distribute, by the platform, a new domain specification structured document to a subscribed user; andupdate, in real-time, the interface to reflect the new domain specification structured document.

25. The apparatus of claim 20, wherein the instructions further cause the processor to display: at least one Dashboard filter in the user interface, wherein the dashboard filter is defined by information from at least one content site;at least one Tree List in the user interface, wherein the Tree List is defined by information from at least one content site;at least one Content List in the user interface, wherein the Content List is driven by selections in the at least one Tree List; andat least one Content Pane in the user interface, wherein the Content pane displays content from the Content List or the Tree List.

26. The apparatus of claim 25, wherein the instructions further cause the processor to: provide containers for Content in said Tree List, content including one or more of Tasks and Folders.

27. The apparatus of claim 20, wherein the instructions further cause the processor to: display in the user interface, content that. is automatically aggregated or generated by a decision support system (DSS).

28. The apparatus of claim 20, wherein the server is a local server that is local to the console and wherein the local server subscribes to the plurality of content sites and downloads the plurality of content streams to the local server.

29. The apparatus of claim 20, wherein each domain specification structured document comprises an extensible markup language document.

30. The apparatus of claim 29, wherein each domain specification structured document contains a section for each domain in which the corresponding content site places content.