Method and system for securely embedding a dashboard into a content management system
阅读说明：本技术 用于将仪表板安全嵌入内容管理系统的方法及系统 (Method and system for securely embedding a dashboard into a content management system ) 是由 A.邓恩 于 2017-12-21 设计创作，主要内容包括：在说明性实施例中,用于安全访问动态分析内容的系统和方法包含：从计算设备处的用户接收对分析信息的请求,确认用户的访问权限,将访问凭证嵌入用于访问可视化内容的资源链接内,以及将资源链接供给用户的计算设备以用于获得分析信息,其中,在计算设备跟随资源链接时,确认访问凭证并且向用户提供可视化内容。(In an illustrative embodiment, a system and method for secure access to dynamically analyzed content includes: the method includes receiving a request for analysis information from a user at a computing device, confirming access rights of the user, embedding access credentials within a resource link for accessing the visual content, and supplying the resource link to the computing device of the user for obtaining the analysis information, wherein, when the computing device follows the resource link, the access credentials are confirmed and the visual content is provided to the user.)
1. A system for secure authentication within a data analysis environment, comprising:
a web portal application to:
a request is received from a user at a computing device for analysis information,
issuing a request for access credentials for accessing the visual content, an
Upon receipt, providing the access credential within a request for visual content;
a content provision system for:
receiving a request for access credentials from the web portal application,
confirming access rights of at least one of the user and the computing device, an
Embedding an access credential in a resource link for accessing the visual content;
wherein providing the access credential within the request comprises following the resource link including the embedded access credential.
2. The system of claim 1, wherein the request includes a username and password.
3. The system of claim 1, wherein requesting access credentials comprises requesting access credentials from an access manager configured as a security gatekeeper within the content provisioning system.
4. The system of claim 1, wherein the request for analysis information comprises selecting a visualization from a plurality of available visualizations.
5. The system of claim 1, wherein the content provision system comprises a content development system to:
confirming that the user has permission to access the analysis information;
generating a security ticket for accessing the analysis information; and
providing the security ticket for use by the computing device, wherein providing the access credential comprises providing the security ticket.
6. The system of claim 5, wherein the content development system is further configured to validate the security ticket when the computing device follows the resource link.
7. The system of claim 6, wherein:
the security ticket is a time-limited security ticket; and is
Verifying the security ticket includes confirming that the security ticket has not expired.
8. The system of claim 1, wherein prior to embedding access credentials within the resource link, the content development system determines appropriate visual content based on a user role that matches the user credentials, wherein
Different visual content permissions are associated with different user roles within the data analysis environment.
9. The system of claim 1, wherein the content provision system comprises a content management system.
10. The system of claim 1, wherein the resource link is a uniform resource locator for accessing web content.
11. A method for secure authentication within a data analysis environment, comprising:
receiving, from a computing device via a network, a request on behalf of a user to access one or more visualizations within a data analysis platform;
issuing, by a processing circuit, a security ticket in response to the request;
embedding, by the processing circuitry, the security ticket in a resource identifier for accessing the one or more visualizations;
providing the resource identifier to the computing device via the network;
identifying, by the processing circuitry, an access attempt by the computing device using the resource identifier;
validating, by the processing circuit, the security ticket; and
returning, to the computing device via the network, information for generating at least a first visualization of the one or more visualizations.
12. The method of claim 11, wherein returning information for generating the first visualization comprises: returning a uniform resource locator or a uniform resource identifier linked at least to the first visualization.
13. The method of claim 11, wherein:
the request includes user identification information; and is
The method also includes confirming user permission to access the one or more visualizations using the user identification information.
14. The method of claim 11, wherein the security ticket is valid for only a single access to the data analysis content.
15. The method of claim 11, wherein receiving the request comprises receiving a query at a content management system.
16. The method of claim 11, further comprising: authenticating the user by confirming a user role associated with the user prior to receiving the request, wherein the one or more visualizations are related to the user role.
17. The method of claim 11, wherein the request is received at a content management system and the security ticket is issued by a content development system that offers dynamic content to a user of the content development system.
18. The method of claim 17, wherein subsequent interactions by the user within the first visualization are enabled by the content development system without involvement of the content management system when using the information for generating the first visualization.
19. A non-transitory computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing circuit, cause the processing circuit to:
receiving a request from a requesting computing system to access a visualization on behalf of a user;
issuing a security ticket to the requesting computing system in response to the request;
identifying an access attempt by a user computing system using a resource identifier embedded with the security ticket;
validating the security ticket;
returning a link to the user computing system for accessing the visualization;
wherein the requesting computing system is different from the user computing system.
20. The non-transitory computer-readable medium of claim 19, wherein the visualization comprises a visualization template provided by a content management system and designed to support content supplied by a content development system, wherein hooks provided within the visualization template provide metadata for use by the content development system in supplying interactive, dynamic content.
Background
Typically, the content management platform will provide an integration tool for seamless integration with popular third party applications. However, in the case where the content management platform does not provide these custom hooks (hooks), information technology teams that manage the content management platform for organizations must solve the integration problem through common integration devices such as original Application Programming Interfaces (APIs) and controls contained within the content management platform. Examples provided for such integration often assume open integration with publicly available tools or data sources, leaving security issues unresolved, such as third party utilization of the platform and potential access to unprocessed confidential or sensitive data.
For example, some popular CMS solutions that are ready-to-install (Out of the box) can be integrated with key popular software tools, leaving all other API solutions to developers to solve with a small number of options, such as open APIs such as REST APIs, integrated buses, and/or by integrating custom application code with CMS application code and calling original APIs and controls from within the CMS. Furthermore, if the CMS cuts off its relationship to popular software tools, the end-user may struggle to select from the small number of options available to keep the platform going on.
Some third party software tools utilize the popular CMS platform for integration work for end customers, such as by developing a framework for integrating third party applications into their CMS. However, third party solutions that rely on linking the CMS to a limited set of software tools lack flexibility and provide a piecemeal solution where different third party applications must "join" to generate a complete solution. Furthermore, reliance on third party solutions involves reliance on third party security mechanisms, thereby losing direct control over security measures.
The inventors have recognized a need to create a solution to establish trusted authentication and seamless integration between an organization's content management system and third party applications. This solution requires control over the security mechanism to ensure data integrity and system robustness.
Disclosure of Invention
The foregoing general description of illustrative embodiments and the following detailed description are merely exemplary aspects of the teachings of the present disclosure and are not limiting.
The inventors devised methods and systems for establishing trusted authentication and seamless integration between an organization's Content Management System (CMS) and third party applications by nesting the content management system within a core portal application. The CMS may contain, for example, API interfaces (interfaces), accept custom web parts, modules, providers, event handlers, and other extensions. To use the CMS, a developer can customize a page template and enhance the page template using controls and web parts, allowing data originating from external systems such as an analytics data store to be displayed and even modified.
In some embodiments, the solution is designed to host static content such as text or static media (e.g., images, video) as well as high impact content such as a dynamic interactive dashboard interface within a data analytics ecosystem. In particular, the solution may support self-service deployment of high impact content, such as Single Page Applications (SPAs) and dynamic interactive analysis workbooks, to the CMS. For example, an analysis workbook developed using an analysis development platform requires intervention by Information Technology (IT) personnel to be published into the CMS before an integrated solution is developed.
In some embodiments, the solution supports establishing trusted certificates with high impact content development tools (data analytics development systems), such as tablet of tablet software, inc. of seattle, washington or JasperSoft, TIBCO, san francisco, ca, that provide seamless delivery of dynamic interactive visualizations (e.g., dashboards) to end users and seamless interactions (e.g., database queries) between data analytics development systems and end systems. The creation, management, and/or rendering of dynamic interactive visualizations (e.g., dashboards) may depend in part on the role of the user within the CMS.
In some embodiments, the solution allows analysis developers to quickly change content without requiring software platform version releases.
In some embodiments, the solution supports user-level trusted authentication between the CMS and the analytics development system.
In some embodiments, the solution supports user dashboard level security verification, refining dynamic interactive content delivered to end users as appropriate.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. The figures are not necessarily to scale. Any numerical dimensions shown in the accompanying figures and drawings are for illustrative purposes only and may or may not represent actual or preferred values or dimensions. Where applicable, some or all features may not be shown to help describe the underlying features. In the drawings:
FIG. 1A is a flowchart of an example operational procedure for enabling a user to receive interactive content via a content management system with a securely embedded dashboard;
FIG. 1B is a swim lane diagram of an example process for enabling a user to receive interactive content via an analytic reporting system with a securely embedded dashboard;
FIG. 2 is a flow diagram of an example method for developing support for a security embedded dashboard within a content management system;
FIG. 3 is an example custom template for providing a menu for collecting screenshots during user navigation;
FIG. 4 is a diagram of an example environment of a dashboard system;
FIG. 5 is a flow diagram of an example method for providing a screenshot capture feature in a dashboard environment;
FIG. 6 is a block diagram of an example computing system; and
FIG. 7 is a block diagram of an example distributed computing environment including a cloud computing environment.
Detailed Description
The description set forth below in connection with the appended drawings is intended to describe various illustrative embodiments of the disclosed subject matter. The specific features and functions are described in connection with each illustrative embodiment; it will be apparent, however, to one skilled in the art that the disclosed embodiments may be practiced without each of these specific features and functions.
Reference throughout the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Further, embodiments of the disclosed subject matter are intended to cover modifications and variations thereof.
It must be noted that, as used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. That is, as used herein, the words "a", "an", "the" and the like have the meaning of "one or more", unless expressly specified otherwise. In addition, it should be understood that terms such as "left," "right," "top," "bottom," "front," "back," "side," "height," "length," "width," "upper," "lower," "inner," "outer," and the like, as may be used herein, merely describe reference points and do not necessarily limit embodiments of the present disclosure to any particular orientation or configuration. Moreover, terms such as "first," "second," "third," and the like, merely identify one of a number of portions, components, steps, operations, functions, and/or reference points as disclosed herein, and as such, do not necessarily limit embodiments of the present disclosure to any particular configuration or orientation.
Further, in certain embodiments, the terms "approximately," "about," "approximately," "slight variations," and the like generally refer to an identified value that is contained within a margin of 20%, 10%, or preferably 5%, and any range of values therebetween.
All functions described in connection with one embodiment are intended to apply to the further embodiments described below, except where explicitly stated or where a feature or function is incompatible with the further embodiments. For example, where a given feature or function is explicitly described in connection with one embodiment but not explicitly mentioned in connection with an alternative embodiment, it should be understood that the inventors intend that the feature or function may be deployed, utilized, or implemented in connection with the alternative embodiment unless the feature or function is incompatible with the alternative embodiment.
A flow diagram illustrating a method of communication within a system with a content management platform nested within a core portal application is shown in fig. 1A. For example, the operational flow 100 depicted in fig. 1A guides the reader through a behind-the-scenes operation triggered by the user 104 accessing a graphical user interface dashboard via a computing device 102 (e.g., a laptop) and requesting a particular visualization (e.g., dashboard content). For example, a web portal application installed or accessed by the computing device 102 may submit a request entered via the user 104. The operational flow 100 assumes that the user 102 has authenticated (e.g., logged in) to a Content Management System (CMS) 106.
Turning to FIG. 1A, in some embodiments, the operational flow 100 begins with a user submitting a request for a list of available visualizations to the CMS 106 (120). The request 120 may be submitted, for example, in the form of a query. The user computing device 102 may, for example, request to view a link of the user's dynamic interactive content dashboard as part of initial access (e.g., post-user authentication) to the analysis ecosystem. The request 120 may be triggered when the user 104 logs into the data analysis dashboard portal.
In some implementations, the CMS 106 checks the CMS permissions of the user (122). For example, the CMS 106 may access a CMS data store 110 containing user information to determine the permissions of the users 104. Permissions may include user roles and other permissions.
In a general sense, when authenticating a user, the CMS 106 may authenticate the user in all trusted domains and any third party integration within the content management system. For example, the CMS 106 may use cloud-based data sources, widget (widget) providers, and other trusted CMS partner tools to authenticate users. In this manner, the tools that can be used for centralized user management under the CMS 106 can be seamlessly accessed with a single login of a user.
Upon authenticating the user's permissions, in some embodiments, the CMS 106 returns a list of available visualizations to the user 104 (124). For example, the available visualizations may be based on the user information itself, or a combination of information (e.g., user organization, user roles within the CMS 106, user permissions established in the CMS 106, etc.). In a particular example, a particular user may be associated with a role having membership of multiple team members and permissions associated with a given role of the user. Further, the basic user interface can be customized for a particular role such that certain portions of the interface are activated while other portions of the interface are deactivated for members sharing the particular role. For example, certain portions of the user interface that are exposed and/or rejected to the user's role may be selected based on the module (e.g., enabling/disabling visualization of individual conversations forming a dashboard interface). In another example, dynamic interactive applications developed for presentation within a given dashboard may be selectively enabled/disabled based on the role of the user.
In some implementations, the user 104 submits a request for a particular visualization to the CMS 106 (126). For example, the visualization may be a dashboard interface that may be customized for presenting information related to the user's role. The visualization may be rendered by a Single Page Application (SPA) or a dynamic interactive analysis workbook. For example, a user may click on a selectable control within a portal interface to request a particular dashboard visualization.
In some implementations, the CMS 106 requests a security ticket (ticket) for the user 104 from the content development system 108 (128). For example, the content development system 108 can be a server-based system or a cloud-hosted system for developing and deploying analytics content for a dashboard interface. For example, the content development system 108 may interface with an analytics data store, pulling content generated in real-time into a graphical user interface for presentation to the end user 104. The content development system 108 may provide tools for integrating data source, computation, metadata, and data field information with the encoded web parts to generate real-time dynamic interactive content.
To request a security ticket from the content development system 108, the CMS 106 content retrieval mechanism may be modified to interface with the content development system 108 through representational state transfer (REST) API communications. The REST API is a web service that allows black-box (e.g., platform/language independent) interworking using universal identifiers (URIs). The REST API decouples communication interactions (e.g., session-free state) by operating in a stateless set of predefined operations, allowing for greater scalability. Predefined operations such as GET, POST, PUT, and DELETE allow a requesting system to access and manipulate a textual representation of a web resource.
In particular, the REST API communication may be implemented using Hypertext Application Language (HAL) endpoints, allowing the CMS 106 and the content development system 108 to communicate through two hypermedia types: extensible markup language (XML) and JavaScript object notation (JSON). The HAL communication type is useful in representing any data source used in a web service.
To request a security ticket, the CMS 106 content loading event may be manipulated (e.g., extended) with a custom component designed to record and pass authentication metadata to the content development system 108. For example, CMS page loading events may be customized to create custom template pages with embedded APIs to communicate with the content development system 108. This allows the custom template page to "drop" or "host" authentication metadata (e.g., supplied by user authentication performed by the CMS 106 prior to the start of the method) to the HAL endpoint of the REST API interface of the content development system 108.
In some implementations, the content development system 108 receives the authentication metadata via REST API communication and determines that the specified user has permission to access the requested content (130). For example, the content development system 108 may access the content development system data store 112 containing user information (including permissions) to determine permissions for the user 104. As with CMS permissions, the authentication metadata may identify specific roles and/or permissions associated with a particular user 104. For example, the licenses in the content development system 108 may mirror the licenses established in the CMS 106.
Since the CMS 106 has challenged and verified the user credentials, the request for the security ticket from the CMS 106 should be sufficient for authentication of the user 104 within the content development system 108, thereby also allowing the method to bypass authentication of user information at the content development system level. For example, the content development system 108 may not recognize that the user 104 is logged into the data analysis ecosystem.
Upon verifying the user license, in some implementations, content development system 108 generates a security ticket 114 (132). In some embodiments, security ticket 114 is valid for a limited time. For example, security ticket 114 may be valid within 3 minutes from the time of generation. The restricted validity of security ticket 114 provides a security mechanism to avoid unauthorized access, for example, by reusing a previously generated security ticket by an external API interface.
In some implementations, the content development system 108 returns the security ticket 114 to the CMS 106 (134). For example, the security ticket 114 may be a resource maintained by the content development system 108 and linked back to the CMS 106 via a URI. Security ticket 114 may, for example, identify a particular user request for content (126). For example, the HAL endpoint can communicate an array of information within a single URI such that the security ticket identifier, the user identifier, and/or additional information (e.g., a timestamp, user permissions, etc.) can be communicated via the single URI. In particular illustration, the content development system 108 may "push" the security ticket 114 to the CMS 106 via a HAL endpoint provided by a custom template page.
In some embodiments, upon receiving the security ticket 114, the CMS 106 constructs a content access link containing the security ticket 114 and returns the content access link to the user's computing device 102 (136). For example, the custom template page may contain functionality to interface with a custom web part designed to convert the provided security ticket 114 into a content access link that can communicate directly with the content development system 108 to obtain the requested dashboard interface. For example, the content access link may be a Universal Resource Locator (URL) for accessing web-based content, for example, within a browser-based dashboard interface.
In some implementations, the user's computing device 102 follows (follow) the access link to request the visualization directly from the content development system 108 (138). For example, when a URL becomes available for a user interface (e.g., a browser-based dashboard), the user's computing device 102 may load the URL with an embedded security ticket 114. For example, the client platform interface may be designed to automatically load the content access links provided in response to a request for a particular visualization (described with respect to step 126).
In some embodiments, content development system 108 validates and redeems security ticket 114 embedded in the access link (140). For example, the content development system 108 may parse the security ticket 114 from the URL and determine that the security ticket information matches the security ticket information maintained by the content development system 108. In response to the authentication and security ticket 114, content development system 108 may further verify that security ticket 114 is still valid (e.g., has not timed out). In another example, content development system 108 may automatically remove the security ticket information for the timeout such that if security ticket 114 expires, content development system 108 will not be able to match the security ticket information.
In some implementations, in response to verifying security ticket 114, content development system 108 returns a final access link for the requested visualization (142). For example, the final access link may be a URL for retrieving and displaying dynamic interactive content provided by the content development system 108. The URL may generate a complete interface (e.g., a browser page) or a portion of a dashboard interface (e.g., a content pane integrated with additional content served by the content management system without contribution from the content development system).
In some implementations, the user's computing device 102 uses the final access link to access the requested visualization (144). For example, the dashboard interface of the user may automatically open the delivered access link to access content provided by the content development system 108.
In some implementations, the content development system 108 returns the visualization to the user's computing device 102 and renders the visualization on a display interface of the user's computing device 102 (146). In one example, the visualization is rendered within a browser-based dashboard system. The visualization may contain, for example, web renderable code, such as hypertext markup language (HTML), Cascading Style Sheets (CSS), and/or Java code in some examples.
In a particular example, the visualization may contain analytical information, for example, in a graph, chart, or other data summary display derived by a larger data analysis ecosystem. For example, the content development system 108 may be designed to generate content in real-time based on web parts developed to pick (sell) up-to-date information from one or more data stores (e.g., relational databases, cubes, cloud databases, and other multidimensional data storage structures). For example, a web part may contain a plurality of queries defined by an analysis developer for deriving analysis information for a user dashboard. Further, the web parts may contain mathematical calculations and/or other data merging instructions for formatting the query results (e.g., rounding, comparison, etc.). In another example, a web part may contain custom visualization layouts (e.g., graphical interfaces customized by an analysis developer), custom text, and/or custom multimedia content linked to the outcome of a data query (e.g., outcome scope, specific analysis results, etc.).
Some portions of the visualization may be dynamic. For example, the query may be run on a periodic (e.g., every 10 seconds, every minute, every 5 minutes, etc.) basis to provide a real-time presentation of the analysis results. In another example, the updated analysis may be pushed to the user interface when available (e.g., when a third-party data source releases updated information, when a backend system makes a system-wide analysis update, etc.).
Some portions of the visualization may be interactive. For example, graphics, charts and/or other visual analysis displays may be selectable to adjust information depth, filter information, and/or provide context for a user to understand information.
At this point, the content development system 108 visualization is securely embedded within the dashboard, and the user 104 can interact with the visualization in a manner that bypasses the CMS 106 until the user 104 navigates away from the current visualization. For example, the visualization may provide real-time data updates, data filtering, and other user interface interactions while maintaining direct communication between the user's computing device 102 and the content development system 108.
Steps 128 through 144 may not be visible to the end user. For example, a dashboard interface executing on the user's computing device 102 may automatically load URLs pushed from the CMS 106 (step 136) and the content development system 108 (step 142). From the user's perspective, the request will appear similar to a typical request for information via a dashboard interface or other dynamic interactive content visualization system. For example, the entire operational flow 100 will be undertaken quickly so that the end user 104 is unaware of what other than typical page loading actions.
FIG. 1B illustrates a swim lane diagram of an example process 150 for enabling a user at a computing device 154 to receive interactive content via an analytics reporting system 156 with a security embedded dashboard. For example, TIBCO from Palo alto, Calif. may be usedTMOf software companies
Turning to FIG. 1B, in some embodiments, the process 150 begins with the user device 154 requesting 160 a user access header from the access manager 152. The request may contain, for example, login information such as a username and password. In some embodiments, an automatic secure single sign-on (SSO) may be provided to an internal user of the system that is identified by its signature of the computing system as being connected to an inline park network or other private network environment. Initially, the internal user will log in locally at the computing device. Subsequently, based on the identification of the authenticated user's login at the computing device in the private network environment, the signature of the computing device being used by the user may be used to support automatic SSO. For example, as long as an internal user logs into a first system, access to subsequent systems may be established via computing device signatures without supplying username and password credentials. For example, the requested header may contain a computing device signature in this case, such as an IP address to access the computing system.
In some implementations, the access manager 152 receives the request and accesses (162) the user credentials. For example, the access manager 152 may be designed to support single sign-on by storing and providing provider header information that contains a username, a list of one or more email addresses, and an organization associated with each user. For example, the access credentials may be stored in a secure storage area accessible by the access manager 152. The access manager 152 may match the login information and/or computing device signature with access credentials maintained in the secure storage area.
In some implementations, the access manager 152 provides (164) user credentials to the user device 154. For example, the user credentials may be embedded in the message header.
In some implementations, the user device 154 requests (166) a visualization from the analytics reporting system 156 using the user credentials. For example, the analytics reporting system 156 may be one of a plurality of systems available when the user device 154 first logs in using the access manager 152. For example, the access manager 152 may gate the initial access rights of both the analytics reporting system 156 of fig. 1B and the CMS 106 of fig. 1A. For example, the visualization request may be similar to the visualization request submitted in step 126 of FIG. 1A. For example, the visualization request (166) may contain at least a portion of the access credential supplied by the access manager 152. For example, the access credential may be added to the visualization request as a security token, similar to the security ticket provided to the user device 102 in step 136 of fig. 1A. For example, as discussed with respect to fig. 1A, the security token may be embedded in a URL constructed for the user by the analytics reporting system 156 (step not shown).
In some implementations, upon receiving the visualization request (166), the analytics reporting system 156 extracts (168) the security token to obtain user credentials. For example, the security token may be extracted from a URL of a header or link of the message.
In some implementations, the analytics reporting system 156 determines (170) whether the user credentials match known users of the analytics reporting system 156. For example, a user may be added to the top-level access manager 152 without having to have populated additional systems within the platform or computing environment that the user is accessing. The analytics reporting system 156 may cross-reference access credentials with an Analytics Reporting System (ARS) database 158. As shown, analytics reporting system 156 determines (170) that the access credentials do not match the existing user, and thus, the requestor is a new user of analytics reporting system 156.
In this case, in some implementations, the analytics reporting system 156 creates (172) user information that matches the incoming user credentials. However, users may be created using a default role that lacks access permissions to the analysis reporting system 156 resources. In some examples, the resources may be domains and data sources available to fully registered users of analytics reporting system 156. Conversely, if the user credentials from step 164 contain user role information, the role information may be populated by analysis reporting system 156 during user detail creation (172).
In some embodiments, the analytics reporting system 156 synchronizes the new user information with the analytics reporting system database 158 (174). For example, when a request from a user of computing device 154 is completed, the user may be added to a database for a subsequent lookup. In some embodiments, an Analytics Reporting System (ARS) database 158 contains user information that is shared with additional systems within the platform that the user of the computing device 154 is accessing.
In some implementations, the analytics reporting system 156 provides (176) the requested visualization to a user of the computing device 154. As discussed with respect to fig. 1A, the visualization may be provided via a visit URL that allows a user of the computing device 154 to obtain information from the analytics reporting system 156 (e.g., see step 136 of fig. 1A). The access URL may contain access credentials that match information synchronized to the ARS database 158. In some embodiments, if the user is added a default role, the requested visualization will be a default visualization presented to users not authorized to access available resources via the analytic reporting system 156.
In some implementations, the computing device 154 presents (178) the visualization to the user. As discussed with respect to fig. 1A, presenting the visualization may include following the URL supplied by the analytics reporting system 156 to obtain the resource managed by the ARS database 158, and loading the resource for viewing by the user (e.g., see steps 144 and 146 of fig. 1A).
At this point, computing device 154 may proceed to embed the user credentials in further requests (such as request 166) into the analytics reporting system.
In some embodiments, rather than incorporating the content management system and the content development system into a single environment for coordinated security key communication on behalf of the end user 104, the content management system may access the content development system via a plug-in utility. For example, a content management system, such as the CMS 106, may interface with the content development system 108 using an Application Programming Interface (API). In this variation, turning to the example of fig. 1A, the API or other plug-in interface may receive communications from the external CMS and perform the operations as described with respect to steps 122, 128, 130, 132, 140 and 142.
Turning to FIG. 2, a flow diagram illustrates an example method 200 for developing support for a security embedded dashboard within a content management system integrated with a data analytics ecosystem.
In some embodiments, the method begins by downloading CMS source code and submitting the source code to a data analysis platform repository (202). Appropriate building steps can be added to the data analysis ecosystem to tie the application with the ecosystem. For example, the CMS may be configured to interface with a database server for presenting queries to collect analytics data for combination with web content. In another example, the CMS may be configured to interface with a cloud computing service to scalably perform functions. Further, the CMS may be configured to access a storage device, such as a web-based storage infrastructure. Each system interface configuration may contain authentication information so that the CMS can authenticate its access to other systems in the analytics ecosystem.
In another illustration, the CMS may interface with systems and/or services through API integration. For example, the CMS may be designed to interface with custom web parts and widgets, custom modules, and/or custom providers through APIs. For example, custom web parts and widgets may be developed to extend over content provided by the CMS by offering custom web functionality such as content editing functionality, graphical user interface layout functionality, and/or interactive control functionality. The custom module allows for extending other aspects of the system, such as custom data objects and/or database tables, custom event handlers, and custom management interfaces in some examples. The custom provider may override built-in service functionality, for example, by transferring functionality to a third party provider. This may include information providers, data providers, email providers, search providers, and/or file system providers. Further, the custom provider may include a secure authentication provider, payment provider, or other gateway service integrated into the CMS environment.
For example, CMS source code may be bundled into a continuous integration server to enable nesting of CMS systems within a data analysis ecosystem. The persistent integration server supports the proactive incorporation of analytics developer products into mainline analytics ecosystem functions. This allows for automation of the update without interrupting the analysis services provided by the analysis ecosystem. For example, the CMS may support synchronization and source control of integrated content to maintain consistency and data integrity. To ensure functionality, the entire CMS system may be tied into the source control of the persistent integration server.
In some embodiments, CMS documents and codebases are examined to track the interaction model between the CMS kernel and its front-end (e.g., web) applications (204). Hook points in the CMS software are identified to customize interaction model behavior for interoperation with other components of the data analytics ecosystem. For example, the hook point allows overriding default behavior and redirecting some portions of the CMS functionality to other systems in the analytics ecosystem. As indicated above, the hook point can be used to override the default page generation behavior, redirecting a portion of the content offering to the content development system.
In some embodiments, the CMS front-end algorithm is extended with custom code through a hook point to override the default behavior (206). As described with respect to fig. 1A, the hooking point may be used to integrate custom code (e.g., custom web parts) that records metadata related to the CMS user authentication process. In a specific example, in response to a page load event, a template page generated by the CMS may be extended with a custom web part for the metadata record.
The custom component may contain an API for interfacing with the content development system, thereby creating hooks to allow a portion of the content of the CMS service to be supplemented by content provided by the content development system. The HAL endpoint may be used to provide an API interface so that the custom web part of the template page can communicate rich information (e.g., user information, security authentication information, timestamp information, etc.) with the content development system in a stateless, black-box fashion.
Using the user license lookup and security ticket as described with respect to FIG. 1A, the customization component extends existing content management system behavior by securely embedding dynamic interactive user dashboard content provided by the content development system. For example, end users cannot use the client-side API to hijack and utilize data due to the security ticket mechanism.
In some implementations, after the custom component is developed and integrated with the hook points in the CMS software, a verification is made to confirm that the custom component allows CMS editor users (e.g., analysis developers) to register dynamic interactive content (such as a dynamic interactive dashboard) as content within the data analysis ecosystem (208).
At this point, the custom template page acts as a "blank canvas," allowing any new content to be automatically added to the system without IT intervention. Multiple custom template pages may be designed for a particular usage scenario. For example, a custom template page may be developed that collects screenshots presented for analysis as a user navigates dynamic interactive content.
In some implementations, the dynamic interactive content includes a dashboard feature for capturing screenshots of the analysis dashboard presentation and downloading the screenshots as a report document. For example, screenshots may be collected as a user navigates the dashboard interface via a menu system dynamically depicted within the dashboard interface. A flowchart of an example method 500 for capturing screenshots of an analytic display via a dynamically rendered menu system is presented in fig. 5.
Turning to fig. 5, in some embodiments, a screenshot capture menu is presented to a user (502). As shown in the user dashboard window 300 of FIG. 3, for example, a custom template may be designed to provide menu options (such as menu 302) to link screenshot collection features to the dashboard interface so that a user may selectively collect screenshots of the dashboard interface and then export those screenshots as the user navigates. The menu 302 may be configured to minimize (stop) to the side of the user dashboard window 300, drop down from the menu, or otherwise remain hidden until the user identifies an analysis interface for adding to a slide show or other derived document.
In some embodiments, the screenshot gathering feature is executed as a runtime executable application, such as a Cascading Style Sheet (CSS) application, designed to access currently presented image information, convert it to a downloadable file format, and use it to generate reports. In another example, the screenshot gathering feature can be performed as an interpretive programming interface, such as a JavaScript interface. In a specific example, the screenshot gathering feature may use a D3 JavaScript library feature for converting a rendered analysis dashboard into an image format suitable for download as a rendered file.
In some implementations, the user actuates a control (504) to activate screenshot capture. For example, the user may select control 308 of FIG. 3 to collect a screenshot of the current dashboard interface. In some embodiments, the user may select to collect a series of screenshots (e.g., record the user's navigation history via the screenshots) during a browsing session through a single control or menu option.
In some embodiments, metadata associated with the current analytics display is captured (506). In some embodiments, the screenshot gathering feature obtains metadata values from page templates to apply as custom settings for image capture and/or presentation formatting. For presentation formatting, in one example, the metadata may contain one or more settings, such as data filter selections, that the user applied when obtaining the current analytics presentation. In another example, the presentation formatting metadata value may contain a header value used to title the screenshot within the generated presentation. For image capture, the metadata value may indicate a style setting to apply to formatting the captured image data. In some embodiments, the metadata value indicates a rule or option for executing the runtime executable application. For example, a runtime executable application may contain multiple branch paths optimized for different styles of analytic presentations. In a particular example, a first path may be optimized for complex shape processing while a second path may be optimized to process text-intensive dashboard displays.
In some implementations, the current screenshot is captured as image data (508). In some embodiments, to enable capture of such content without accessing image files or other files used to generate the screen content, screenshots may be captured in a vector image format, such as a Scalable Vector Graphics (SVG) file, through a screenshot collection feature. For example, vector image formatting allows for improved scalability of the image to fit printed reports. In other embodiments, the screenshot gathering feature may capture the screenshots as raster graphics (e.g., a bitmap). For example, the screenshot collection feature may use a Canvas (Canvas) element of HTML5 to collect the displayed information. For dashboard interfaces that involve complex shapes such as geographic map presentations, a canvas that functions with a raster graphic may be less desirable. However, if the dashboard interface is directly accessible as HTML code, the canvas may be executed faster and simpler. In a further embodiment, the screenshot collection feature may transform the vector graphics file into a file compatible with the canvas element of HTML5 for additional processing. For example, the canvas may be used to merge the collected dashboard interface image with additional elements included for reporting, such as a representation of the filter values applied by the user and/or header information accessed from the metadata content of the dashboard interface.
In collecting the screenshots, in some embodiments, the screenshot collection feature stores the downloaded image data and metadata values in a session store accessible to the web browser for accessing the dashboard interface. In other embodiments, the screenshot gathering feature transmits the image data to a remote storage for further processing. For example, the screenshot gathering features may interface with a cloud-based application for analyzing the manipulation and packaging of dashboard image data.
In some implementations, the screenshot collection feature presents thumbnail images of the collected screenshots (510), such as thumbnail image 306 of fig. 3. As shown in menu 302, the user may be presented with thumbnail images 306a, 306b of analysis visualizations that have been captured through a screen capture mechanism provided within menu 302. For example, the thumbnail image 306 may be rendered as an HTML-based image, such as a resized image of the original HTML presentation.
In some implementations, upon selection of the download control 304 (512), the image data collected by the screenshot collection feature (and optionally the presentation settings derived by the dashboard interface metadata) is converted to a report format (514). For example, the image data may be provided to a report generation API for conversion to a report format. In some embodiments, multiple report generating APIs may be available, each API customized to handle a particular style of dashboard interface. As described above with respect to image downloading, one report generating API may be optimized to handle complex shapes (e.g., maps), while another report generating API may be optimized to handle resizing and reformatting of textual information for legibility in printed reports.
In some implementations, a screenshot collection feature or report generation API determines the sizing and placement of each screenshot. For example, the screenshot gathering feature or report generation API may detect image data size and transform the image data for lateral rendering and/or printing on standard print paper (e.g., letter, legal, A4, etc.). The screenshot gathering feature or report generation API may take into account the legibility of the text-based content (e.g., maintaining any text in a font of 6 points or larger) when transitioning images.
In some implementations, the report document is built using the captured screenshots and associated metadata (516). Different report generation APIs may be provided based on the report format. In some examples, the report may be generated as a slide presentation such as Microsoft PowerPoint (PPT) format or a document such as Adobe Portable Document Format (PDF) or Microsoft Office document format. The download control 304, when activated, may present download formatting options to the user via a dashboard interface.
In some implementations, the image data is formatted for inclusion in a base report template, such as a base PPT template file. In other embodiments, the screenshot collection feature or report generation API accesses a user-specific template file (e.g., formatted with an entity name, logo, etc. associated with the user of the dashboard interface). In a further embodiment, the screenshot collection feature presents a plurality of options for report templates that are selectable by the user. For example, the download control 304, when activated, can present a report template option to the user via a dashboard interface.
In some implementations, a screenshot collection feature or report generation API collects additional information for inclusion within a report file. For example, a screenshot collection feature or report generation API may capture the current timestamp and apply the date (and optionally time) to the report file. In addition, the screenshot gathering feature or report generation API may access user specific information (such as entity name, entity flag, user name, user department, etc.) for inclusion in the header page, header, footer, etc. of the report file.
In some embodiments, the report document is provided to the user (518). In some embodiments, a screenshot collection feature or report generation API creates a report file for a user in real-time. For example, upon activation of the download control 304, a screenshot gathering feature may initiate report preparation and provide a report file to the user via a browser interface in near real-time. For example, a file download feature of a browser used to access the dashboard interface may be used to provide the report file to the user. In other embodiments, the report file may be emailed to the user when preparation is complete or stored in the user's account information for later access via the dashboard interface.
FIG. 4 is a diagram of an example environment 400 for a dashboard system 408 for implementing the processes previously described herein. The figure shows external users (e.g., subscribers 402, providers 404, and intermediate participants 406) of a dashboard system 408. The provider 404 may contain industry participants such as insurance and/or reinsurance providers, the subscribers 402 contain one or more subscribers 402 that receive products and/or services such as insurance protection from the provider 404, and the intermediary participants 406 may manage interactions between the subscribers 402 and the provider 404 such as a broker or coordinator. In some implementations, the dashboard system 408 manages the processing of participant requests to present a dashboard interface to participants in real-time in response to receiving requests from the participants. For example, dashboard system 408 may control how cloud computing resources are allocated within a multi-tiered cloud computing environment in order to improve processing efficiency and execution speed. At least a portion of the dashboard system 408 may be implemented by a content management system, such as the CMS 106 described with respect to fig. 1A.
The subscribers 402, providers 404, and intermediary participants 406 contain a plurality of computing devices and databases distributed over a widely dispersed network, which may be distributed over a large international geographic area. The network for each of the subscriber 402, provider 404, and intermediary participant 406 may be separate and independent from any network associated with any other participant in the dashboard environment 400. Additionally, the data processed and stored by each of the subscribers 402, providers 404, and intermediate participants 406 may have a different format than the data processed and stored by the other participants in the dashboard environment 400. The subscriber 402, provider 404, and intermediate participants 406 provide input to the dashboard system 408 that may include a request to access the dashboard system 108 to view the analysis information through a dashboard customized to each participant's user profile. The data provided from each participant to the dashboard system 408 may be independent of the other participants and in a different format than the data provided by the intermediate participants 406 and the provider 404.
The dashboard system 408 contains an engine or application that performs processes associated with aggregating transactional data and generating transactional metrics for display to the subscribers 402, providers 404, and intermediate participants 406 via a dashboard interface on a computing device. References throughout this disclosure to engines or modules are intended to refer to software processes performed by circuitry of one or more processing circuits, which may also be referred to interchangeably as processing circuits. In some implementations, the processes associated with the engines of dashboard system 408 are performed by one or more cloud computing resources in a cloud computing environment. Additionally, the processes performed by the engines of dashboard system 408 may be performed in real-time to provide an immediate response to system inputs. The process may also be automated in response to a process trigger, which may include receiving data from a data repository, a participant, or another processing engine.
In some embodiments, the dashboard system 408 includes a control engine 430 that provides a high level of control over the interaction between the subscribers 402, providers 404, and intermediate participants 406, as well as the computing resources associated with the other processing engines of the dashboard system. For example, upon receiving a request from a participant to view the dashboard, the control engine 430 can parse the request into one or more processing tasks distributed among the computing resources of the dashboard system 408. As discussed in further detail herein, the dashboard system 408 may be implemented in a cloud computing environment having computing resources distributed over one or more Available Zones (AZ) within a geographic area. When a request to access the dashboard interface is received from a participant, the control engine 430 may determine which AZ to route the associated processing task to based on the availability of computing resources within the AZ and the current processing requirements for the computing resources. Control engine 430 may also control the allocation of one or more processing tasks associated with requests for computing resources within AZ.
In some embodiments, the dashboard system 408 contains an access/navigation engine 410 that provides a portal for participants to access the dashboard system 408, such as through a web browser. In some implementations, the access/navigation engine 430 uses a role-based access control (RBAC) model to determine which types of dashboards and data a particular participant can access. The access/navigation engine 430 may control the generation of a user profile for each participant that is used to populate the participant's RBAC table, which is stored as access/navigation data 428 in the data repository 420 (e.g., such as the CMS user store 110 of fig. 1A). For example, the RBAC table entry for a given provider 404 may indicate the provider's 404 permission to access a particular insurance company's associated dashboard interface, as well as the provider's 404 custom dashboard displaying custom data customized for the particular provider 404. In response to receiving a participant login request to access the dashboard interface, the access/navigation engine 410 may verify authentication information input by the participant and control information accessible to the participant and the dashboard interface via the web interface based on the verified authentication information. For example, the access/navigation engine 410 may limit access by retrieving content related to the RBAC license, such as a dashboard template designed for presentation to users of a particular role.
In some embodiments, the dashboard system 408 includes a visualization engine 412 that generates graphical and visual tools associated with the transaction data and metrics displayed on the dashboard interface. The visualization engine 412 may generate various types of charts, graphics, and the like, which may be determined based on the type data displayed to the user via the dashboard interface screen or the visualization preferences of the user requesting the information presented on the dashboard interface. For example, the dashboard interface of FIG. 3 illustrates an example data presentation. The visualization engine 412 may also determine a color scheme, visual contrast, and other visual properties of the graphical representations displayed on the dashboard interface based on the size of the graphical representations, other graphical representations included in the dashboard interface, and the like. In one example, the visualization engine 412 is provided by the content development system 108 of FIG. 1A on the part.
In some implementations, the dashboard system 408 also includes a dashboard Graphical User Interface (GUI) engine 414 that controls the propagation and receipt of data from the subscribers 402, providers 404, and intermediate participants 406 through one or more dashboard GUI screens output to the external device 458. In some implementations, in response to detecting that the input field of the dashboard interface has been filled or that the submit control has been clicked, the dashboard GUI engine 414 extracts the data entered by the user at the dashboard interface and stores the data in the data repository 420 or passes the data to another processing engine of the dashboard system 408. For example, the dashboard GUI engine 414 receives the transactional data parameters entered by the intermediate participants 406 at the dashboard interface and stores the transactional data parameters for each intermediate participant 406 as participant data 432 in the data repository 420. In some implementations, the participant data 432 may be stored in the data repository 420 along with the access/navigation data 428. The dashboard GUI engine 414 also controls the propagation of information on dashboard interfaces requested by the subscribers 402, providers 404, and intermediate participants 406. For example, in response to receiving a request for a dashboard interface from a participant, the dashboard GUI engine 414 may access the applicable analytics data 422 from the data repository 420 associated with the requested information based on the participant's access/navigation data 428 determined by the access/navigation engine 410 and determine statistics or metrics associated with the request. In some implementations, the dashboard GUI engine 414 passes the determined statistics or metrics to the visualization engine 412, which is used to generate a graphical representation of the statistics or metrics. The dashboard GUI engine may receive the generated graphical representation from the visualization engine 412 and output the generated graphical representation along with any other applicable data onto the requested dashboard interface of the participant's computing device 458. The dashboard GUI engine 414 may contain components of the CMS 106 of FIG. 1A and/or the content development system 108 of FIG. 1A.
In some embodiments, the dashboard GUI engine 414 includes one or more sub-engines that are directly accessed by the dashboard GUI engine 414 in the web browser displayed to the participant. For example, the participant function engine 416 provides specific dashboard functions for each type of participant (e.g., subscriber 402, provider 404, and intermediate participant 3606) as well as user-specific dashboard functions indicated in the user profile. In some implementations, the participant function engine 416 determines the dashboard function of a particular participant based on the access/navigation data 428 and participant data 432 stored in the data repository 420. In response to receiving a request to view the portal, the participant function engine 416 determines what type of data is displayed in various portions of the portal based on data accessible to the participant and the participant indicated preferences. In some examples, the participant may indicate a preferred news website, social media platform, and the like. For example, the subscriber 402, provider 404, and intermediary 406 may have different priorities related to what type of data is displayed in the portion of the portal.
Another example of a sub-engine associated with the dashboard GUI engine 414 is an analysis sub-engine 418, which in some embodiments provides specific analysis functionality to participants interacting with the dashboard system 408. Analysis sub-engine 418 may perform one or more software processes associated with computing any metrics or statistics displayed on the dashboard interface described herein.
In some implementations, data associated with processes performed by the dashboard system 408 is stored in one or more data repositories of the dashboard environment 400, such as data repository 420. Data received by the dashboard system 408 from one or more data sources may be received and stored in real-time as to when the data is received from the various data sources. Additionally, data may be automatically stored in response to receiving one or more data files from a data source. In some implementations, the data stored in the data repository 420 may include analysis data 422, dashboard GUI templates 424, visualization templates/data 426, access/navigation data 428, and participant data 432.
In some implementations, the analytics data 422 stored in the data repository 420 is processed by the analytics sub-engine 418 to generate a graphical display of the transaction data and metrics based on the type of dashboard requested by the participant. In some implementations, the analytics data 422 may include data from one or more data sources that are used to generate statistics and metrics that are displayed on a dashboard interface. For example, the analytics data 422 may include insurance market data received from public data sources and transactional data associated with each participant received from the computing devices 458 of the subscribers 402, providers 404, and intermediary participants 406.
In some implementations, the data repository 420 also stores dashboard GUI templates 424 that are accessed by the dashboard GUI engine 414 to generate one or more dashboard interfaces that are output to the external devices 458 to interact with participants in the dashboard environment 400. In some implementations, the dashboard GUI template 424 contains one or more stored software processes and data files associated with generating the requested dashboard interface displayed on the participant's computing device 458.
In some implementations, the data repository 420 also stores visualization templates/data 426, which visualization templates/data 426 are used by the visualization engine 412 to generate various visual representations of the transaction data and metrics that are displayed on a dashboard interface that is output to the participant's external device 458. In some embodiments, the visualization templates/data 426 contain one or more stored software processes and data files associated with generating the various graphics, charts and other graphical representations displayed on the requested dashboard interface.
In some embodiments, the data repository 420 also stores access/navigation data 428, which access/navigation data 428 is accessed by the access/navigation engine 420 to control the types of data and dashboards accessible to participants. In some implementations, the access/navigation data 428 may contain a list of registered participants and corresponding permissions for the participants, as well as configuration information that controls how data is processed and transferred between computing resources in the cloud computing environment based on the participants' access permissions. For example, the access/navigation data 428 may contain a RBAC table indicating access permissions associated with a particular participant. The access/navigation data 428 may also contain web state information used to synchronize state and caching between the servers of the access/navigation engine 410.
In some embodiments, the data repository 420 also stores participant data 432 extracted by the dashboard GUI engine 414 from one or more input dashboard interfaces of participants (e.g., the subscriber 402, the provider 404, and the intermediate participants 406) inputting transaction data parameters (e.g., fig. 9), visualization preferences, data type preferences, and any other information describing the participants. For example, the participant data 432 may contain preferences of the participant related to the type of data that the participant wishes to see displayed in various sections of the portal, such as the industry Risk News section. In some implementations, the participant can enter preferences, which can be stored as participant data 432 in the data repository 420. In some implementations, the participant data 432 may be combined with the access/navigation data 428 of a particular participant.
Next, a hardware description of a computing device, mobile computing device, or server according to an example embodiment is described with reference to fig. 6. In fig. 6, a computing device, mobile computing device, or server includes a CPU 600 that performs the above-described process. Process data and instructions may be stored in memory 602. The processes and instructions may also be stored on a storage media disk 604, such as a Hard Disk Drive (HDD) or portable storage media, or may be stored remotely. Furthermore, the claimed advancements are not limited by the form of computer readable media storing the instructions of the inventive process. For example, the instructions may be stored on a CD, DVD, flash memory, RAM, ROM, PROM, EPROM, EEPROM, hard disk, or any other information processing device (such as a server or computer) with which the computing device, mobile computing device, or server is in communication.
Furthermore, a portion of the claimed advancements may be provided as a component of, or in combination with, a utility application, a background daemon, or an operating system, executing with the CPU 600 and an operating system such as Microsoft Windows 6, UNIX, Solaris, LINUX, Apple MAC-OS, and other systems known to those skilled in the art.
CPU 600 may be a Xeron or Core processor from Intel, USA, or an Opteron processor from AMD, USA, or may be other processor types as will be appreciated by those of ordinary skill in the art. Alternatively, as one of ordinary skill in the art will recognize, CPU 600 may be implemented on an FPGA, an ASIC, a PLD, or using discrete logic circuitry. Further, CPU 600 may be implemented as multiple processors working in conjunction in parallel to execute the instructions of the inventive processes described above.
The computing device, mobile computing device, or server of fig. 6 also contains a network controller 606, such as an Intel Ethernet PRO network interface card from Intel corporation of america, for interfacing with the network 628. As can be appreciated, the network 628 may be a public network, such as the internet, or a private network, such as a LAN or WAN network, or any combination thereof, and may also contain PSTN or ISDN sub-networks. The network 628 may also be wired, such as ethernet, or may be wireless, such as a cellular network including EDGE, 3G, and 4G wireless cellular systems. The wireless network may also be Wi-Fi, Bluetooth, or any other form of wireless communication known.
The computing device, mobile computing device or server further comprises a displayA display controller 608, such as an NVIDIA GeForce GTX or Quadro graphics adapter from Invitroda, USA, for use with a device such as Hewlett Packard (Hewlett Packard) HPL2445wfThe display 610 of the LCD monitor. The general purpose I/O interface 612 interfaces with a keyboard and/or mouse 614 and a touch screen panel 616 on or separate from the display 610. The general purpose I/O interfaces also connect to various peripheral devices 618, including printers and scanners, such as OfficeJet or DeskJet from Hewlett packard, Inc.
A Sound controller 620, such as Sound blast X-Fi Titanium from innovative technologies, inc.
The general purpose storage controller 624 connects the storage media disk 604 with a communication bus 626, which communication bus 626 may be an ISA, EISA, VESA, PCI, or the like, used to interconnect all of the components of a computing device, mobile computing device, or server. For the sake of brevity, descriptions of the general features and functionality of the display 610, keyboard and/or mouse 614, as well as the display controller 608, storage controller 624, network controller 606, sound controller 620, and general purpose I/O interface 612 are omitted herein, as these features are known.
Unless specifically stated otherwise, one or more processors may be utilized to implement the various functions and/or algorithms described herein. Additionally, unless explicitly stated otherwise, any functions and/or algorithms described herein may be performed on one or more virtual processors, for example, on one or more physical computing systems such as a computer farm or cloud drive.
Reference has been made to flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments of the present disclosure. Aspects of which are implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Moreover, the present disclosure is not limited to the specific circuit elements described herein, nor is the present disclosure limited to a particular size and classification of these elements. For example, those skilled in the art will appreciate that the circuits described herein may be adjusted based on changes in battery size and chemistry, or based on the requirements of the intended back-up load to be powered.
The functions and features described herein may also be performed by various distributed components of the system. For example, one or more processors may perform these system functions, where the processors are distributed across multiple components that communicate over a network. In addition to various human machine interfaces and communication devices (e.g., display monitors, smart phones, tablet computers, Personal Digital Assistants (PDAs)), the distributed components may include one or more client and server machines that may share processing, as shown in fig. 7. The network may be a private network such as a LAN or WAN, or may be a public network such as the internet. Input to the system may be received via direct user input and may be received in real-time or remotely as a batch process. Additionally, some implementations may be performed on different modules or hardware than those described. Accordingly, other embodiments are within the scope of what may be claimed.
At one endIn some embodiments, the methods described herein may be used with a cloud platform such as GoogleTMTo perform at least a portion of the methods or algorithms detailed above. The processes associated with the methods described herein can be executed by the data center 734 on a computing processor, such as a google computing engine. For example, the data center 734 may also contain an application processor, such as a google application engine, which may serve as an interface with the systems described herein to receive data and output corresponding information. The cloud computing environment 730 may also contain one or more databases 738 or other data stores, such as cloud storage and query databases. In some implementations, cloud storage database 738, such as google cloud storage, may store processed and unprocessed data supplied by the systems described herein.
The system described herein may communicate with cloud computing environment 730 through security gateway 732. In some embodiments, security gateway 732 contains a database query interface, such as google BigQuery platform.
The cloud computing environment 102 may contain a provisioning tool 740 for resource management. The supply tools 740 may be connected to computing devices of the data center 734 in order to provide computing resources of the data center 734. The provisioning tool 740 may receive a request for a computing resource via the security gateway 732 or the cloud controller 736. The provisioning tool 740 may facilitate connection with a particular computing device of the data center 734.
Network 702 represents one or more networks, such as the internet, connecting cloud environment 730 to a plurality of client devices, such as, in some examples, cellular phone 710, tablet computer 712, mobile computing device 714, and desktop computing device 716. The network 702 may also communicate via wireless networks using various mobile network services 720, such as Wi-Fi, bluetooth, cellular networks including EDGE, 3G, and 8G wireless cellular systems, or any other form of wireless communication known. In some embodiments, the network 702 is agnostic to local interfaces and networks associated with the client devices to allow integration of local interfaces and networks configured to perform the processes described herein.
While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the disclosure. Indeed, the novel methods, apparatus and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods, devices, and systems described herein may be made without departing from the spirit of the disclosure. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the disclosure.