Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/75—Indicating network or usage conditions on the user display
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
  • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
  • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
  • G06F3/0482—Interaction with lists of selectable items, e.g. menus
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/451—Execution arrangements for user interfaces
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/445—Program loading or initiating
  • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
  • G06F9/44526—Plug-ins; Add-ons

Definitions

• the declarative metadata may be received a client device from a server device.
• the server device can be configured to generate the declarative metadata.
• the generation of the declarative metadata by the server device may be triggered by a request from the client device for a component of a modular interface provided by the server device and/or a request from the client device for data relating to a component of the modular interface.
• the request may be transmitted by the client device to the server device.
• the server device may simultaneously serve a plurality of client devices like the client device, where each of the plurality of client devices separately requests component(s) of the modular interface and/or data relating to component(s) of the modular interface. [0005] Aspects of the present disclosure further include distributed data sharing across separate devices.
• the selected components of the dashboard data may then be used to generate the declarative metadata for building and displaying the dashboard.
• Aspects of the present disclosure relate to utilizing service metrics and measures as a portion of components for display on a dashboard interface.
• An example method comprises the steps above further comprising receiving service data, the service data corresponding to one or more metrics for one or more services related to the one or more visual components, wherein the one or more sets of rendering data are generated based at least in part on the declarative metadata and the service data.
• Another aspect of the present disclosure comprises a system comprising one or more processors and a non-transitory computer-readable media that includes instructions that when executed by the one or more processors, cause the one or more processors to perform the methods described above.
• FIG. 1 is a block diagram of a distributed infrastructure-as-a service system for generating visual components according to certain embodiments of the present disclosure.
• FIG. 1 is a block diagram of a distributed infrastructure-as-a service system for generating visual components according to certain embodiments of the present disclosure.
• Dashboard display subsystem 121 may be a subsystem operable to display a dashboard and various dashboard components on an electronic display.
• Client engine system 120 may further comprise input handling subsystem 122.
• Input handling subsystem 122 may be a subsystem operable to detect and respond to interactive inputs made by a client and corresponding to a displayed dashboard.
• input handling subsystem 122 may implement one or more input listeners as separate subsystems to detection one or more type of input and/or input contexts.
• Client engine system 120 may further comprise dashboard engine subsystem 123.
• Dashboard engine subsystem 123 may be a subsystem operable to parse one or more declarative definitions of a component and generate rendering data for creating a digital dashboard.
• input handling subsystem 123 may implement one or more multi-use agents for processing and creating dashboard components in parallel.
• a more detailed diagram of client engine system 120 is depicted in FIG. 3.
• Network 160 may be further communicatively coupled to component facilitation system 140.
• Component facilitation system 140 may be implemented by server 130.
• Server 130 may be any type of device operating in any format necessary to perform the embodiment described herein, and the number of server devices that may comprise an embodiment is not limited.
• a server 130 is a device operable by a service provider and/or administrator to store, send, receive, render, generate, and manage generated data relating to a component-based interface.
• Component facilitation system 140 may comprise catalog subsystem 141.
• Catalog subsystem 141 may comprise component cataloger 200.
• a component cataloger may be a subsystem which catalogs a number of components to create a component list.
• the component list may correspond to a number of visual components which will be displayed on a dashboard as part of an interface.
• the component cataloger 200 may be communicatively coupled to a component manifest intake module and a number of plugins which store components.
• the component cataloger may use a component manifest to identify a number of components in the plugins to create a component list.
• the component list may be a listing of components to receive from a component repository.
• Catalog subsystem 141 may further comprise component repository 210.
• Component repository 210 may be a repository of components or component information which are implementable in a dashboard interface.
• component repository 210 receives a component list from component cataloger 200.
• Component repository 210 or a similar entity may then identify and group one or more sets of declarative metadata relating to the visual components identified on the component list.
• component cataloger 200 may send a component list to component repository 210 specifying a component for a digital component “widget” to be generated for display on a dashboard interface.
• the component repository 210 may identify declarative metadata relating to the function of that digital component for further processing.
• Component facilitation system 140 may comprise service data subsystem 142.
• Service data subsystem 142 may comprise query instructions 220.
• Service data sharing instructions 230 may identify the relevant services executing at a service provider, retrieve metrics related to operation of the services, and transmit the service data back to the querying entity.
• Component facilitation system 140 may comprise dashboard creation subsystem 143.
• Dashboard creation subsystem 143 may comprise dashboard component display instructions 240.
• Component display instructions 240 may be a set of instructions that cause display of a component on a visual dashboard interface or the creation of data to do the same.
• dashboard component display instructions 240 received display, such as display data generated by query instructions 220.
• Dashboard component display instructions 240 may cause sending of the display data to a device comprising a digital display, such as client device 120. The display data may then be used to display the components on the digital display.
• input handling subsystem 122 may generate data corresponding to a detected input and send the data to a system for causing an update of a corresponding component. For example, in response to detecting input corresponding to a particular component displayed on a dashboard interface, input handling subsystem may generate interaction metadata and send the interaction metadata to a module for causing a responsive update, such as update instructions 230.
• Client engine system 120 may further comprise local storage subsystem 300.
• Local storage 300 may be a storage or repository storing one or more sets of data related to a client device.
• local storage subsystem 300 comprises data relating to one or more sets of information relevant to the function of one or more components.
• client engine system 120 in response to the client engine system 120 receiving declarative metadata, such as metadata from a component facilitation system 140, client engine system 120 instantiates a component agent 320 within the dashboard engine subsystem 123.
• component agent 320 receives and parses the declarative metadata to begin a component generation process.
• Component agent 320 may comprise metadata parsing instructions 322.
• Metadata parsing instructions 322 may be instructions utilizable by the component agent 320 to parse metadata, such as declarative metadata.
• Component agent 320 may further comprise component generation instructions 324.
• Component generation instructions 324 may be instructions for generating a component based on parsed declarative metadata.
• an instantiated component agent may be replicated at least once for each component to be generated.
• a user of client device 110 may utilize client engine system 120 to query for a listing of components that may be displayed as part of a user-personalized dashboard interface.
• Catalog subsystem 410 may receive the query and return a listing of cataloged components to client engine 120. Client engine 120 may then select components from the component catalog for inclusion in the user-personalized dashboard interface.
• the catalog subsystem 410 is a widget catalog subsystem. The widget catalog subsystem may store and send, to the client engine system 120, a list of available widgets for a user of the client device 110 to select from, add to a widget component dashboard, configure, or otherwise utilize.
• Client engine system 120 may be further communicatively coupled to dashboard creation subsystem 143 of component facilitation system 140.
• Each particular replicated multi-use agent may be delegated a subset of the declarative metadata for generating a corresponding visual component.
• the particular multi-use agent may use the received subset of the declarative metadata to generate rendering data.
• a multi-use agent may receive a subset of declarative metadata describing a visual component to be generated and a portion of service data to populate variable metadata within the subset of declarative metadata.
• the multi-use agent will utilize the data to generate the corresponding subset of rendering data as a set of rendering data.
• the multi-use agent may generate the component based on the subset of declarative metadata and local data from a client device.
• FIG. 6 depicts an example flowchart of a distributed system and process for interface component generation using a multi-use agent according to certain embodiments of the present disclosure. Specifically, FIG. 6 depicts a distributed system implementing a multi- agent-facilitated process 600 for displaying and monitoring a component interface as part of a client-side rendering configuration of systems.
• the client engine system 120 receives the declarative metadata from the component facilitation system 140 and parses the declarative metadata to determine one or more visual components. This may be similar to steps 510 and 520 in process 500.
• the client engine system 120 replicates a component agent into one or more instances of a component agent. This may be similar to step 430 described in process 400.
• the client engine system 120 generates a request for service data that will be used for facilitating the dashboard interface. The request is sent to component facilitation system 140, which tracks and records metrics relating to performance of the services.
• the component facilitation system 140 retrieves the service data for completing the visual components.
• the component facilitation system 140 may use the request generated in block 635 to identify services executing at a service provider system and extract metric data to be sent to client engine system 120.
• the client engine system 120 receives the service data from component facilitation system 140 and generates rendering data for rendering complete components on a dashboard interface.
• client engine system 120 and the multi- use agents replicated therein may use the declarative metadata and the service data to compile one or more instances of complete components and generate rendering data for the complete components.
• the client engine system 120 utilizes the generated rendering data to display the interface comprising the component dashboard.
• the client engine system 120 has previously received a shell dashboard which will be populated with the dashboard interface.
• the shell dashboard is populated in real-time with interface data as it is generated.
• the component facilitation system 140 may generate one or more sets of interface data in parallel as the rendering data is generated by the client engine system 120 in a client-side rendering configuration.
• the dashboard components are displayed as they are received from component facilitation system 140 and executed by client engine system 120.
• the client engine system 120 monitors the displayed interface in real- time to determine any changes or interactions with the interface. Monitoring the interface in real-time may allow for real-time updates to the interface.
• the client engine system 120 may monitor the interface to detect user interactions with the interface. The user interactions may cause an update of a particular component on the dashboard.
• the component cataloger 200 may be communicatively coupled to a component repository 210, which receives the component catalog and retrieves one or more component datasets corresponding to the component catalog.
• the retrieved one or more component datasets may be compiled into declarative metadata.
• the declarative metadata may comprise some static data, which is taken directly from the plugins, and fields for variable data, which will be filled by local data stored at a client device.
• each of the previously described entities may be stored at a component facilitation system.
• the component repository 210 may be communicatively coupled to a dashboard engine subsystem 123, which receives declarative metadata from the one or more retrieved components.
• the dashboard engine subsystem 123 may be stored at a client engine system which is separate from the aforementioned component facilitation system.
• Components 753A-753N may be interactive components. Interactive components may change in some way or cause some functionality to execute when interaction with the component is detected. For example, as depicted in FIG. 7, component 753A is highlighted with a border indicating that a client has interacted with component 753A using a digital interface. The agent instances 710A-710N may actively monitor and update their corresponding components in real-time using local data accessible by the dashboard engine subsystem 123.
• console application 740 may further comprise component editing interface 760.
• Component editing interface 760 may be an interface through which a client may change some aspect of a current component 753 or create a new component.
• a user of a client device 110 implementing client engine system 120 on which the interface may be displayed may specify display of the dashboard “MY VIRTUAL MACHINE DASHBOARD.”
• the user may interact with new component 810 to request creation of a new component through editing interface 760.
• the client engine system 120 may query a catalog subsystem 141 of a component facilitation system 140 to retrieve and send a listing of cataloged components.
• One such component from the cataloged components may be displayed as a facsimile component on component editing interface 760.
• client engine system may send dashboard data corresponding to the new configuration to a dashboard creation subsystem 143 of component facilitation system 140.
• IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet).
• a cloud computing provider can host the infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., a hypervisor layer), or the like).
• an IaaS provider may also supply a variety of services to accompany those infrastructure components (e.g., billing, monitoring, logging, load balancing and clustering, etc.).
• these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.
• the cloud provider may, but need not be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS.
• An entity might also opt to deploy a private cloud, becoming its own provider of infrastructure services.
• IaaS deployment is the process of putting a new application, or a new version of an application, onto a prepared application server or the like. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider, below the hypervisor layer (e.g., the servers, storage, network hardware, and virtualization).
• IaaS provisioning may refer to acquiring computers or virtual hosts for use, and even installing needed libraries or services on them. In most cases, deployment does not include provisioning, and the provisioning may need to be performed first.
• IaaS provisioning there are two different challenges for IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is running. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.) once everything has been provisioned.
• an infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on- demand pool of configurable and/or shared computing resources), also known as a core network.
• VPCs virtual private clouds
• inbound/outbound traffic group rules provisioned to define how the inbound and/or outbound traffic of the network will be set up and one or more virtual machines (VMs).
• VMs virtual machines
• Other infrastructure elements may also be provisioned, such as a load balancer, a database, or the like. As more and more infrastructure elements are desired and/or added, the infrastructure may incrementally evolve.
• continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques can enable infrastructure management within these environments.
• service teams can write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across various different geographic locations, sometimes spanning the entire world).
• FIG. 9 is a block diagram 900 illustrating an example pattern of an IaaS architecture, according to at least one embodiment.
• Service operators 902 can be communicatively coupled to a secure host tenancy 904 that can include a virtual cloud network (VCN) 906 and a secure host subnet 908.
• VCN virtual cloud network
• the client computing devices can be workstation computers running any of a variety of commercially-available UNIX® or UNIX-like operating systems, including without limitation the variety of GNU/Linux operating systems, such as for example, Google Chrome OS.
• client computing devices may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and/or a personal messaging device, capable of communicating over a network that can access the VCN 906 and/or the Internet.
• the VCN 906 can include a local peering gateway (LPG) 910 that can be communicatively coupled to a secure shell (SSH) VCN 912 via an LPG 910 contained in the SSH VCN 912.
• the SSH VCN 912 can include an SSH subnet 914, and the SSH VCN 912 can be communicatively coupled to a control plane VCN 916 via the LPG 910 contained in the control plane VCN 916.
• the SSH VCN 912 can be communicatively coupled to a data plane VCN 918 via an LPG 910.
• the control plane VCN 916 and the data plane VCN 918 can be contained in a service tenancy 919 that can be owned and/or operated by the IaaS provider.
• the data plane DMZ tier 948 can include LB subnet(s) 922 that can be communicatively coupled to the app subnet(s) 926 of the data plane app tier 946 and the Internet gateway 934 of the data plane VCN 918.
• the app subnet(s) 926 can be communicatively coupled to the service gateway 936 of the data plane VCN 918 and the NAT gateway 938 of the data plane VCN 918.
• the data plane data tier 950 can also include the DB subnet(s) 930 that can be communicatively coupled to the app subnet(s) 926 of the data plane app tier 946.
• the call to public Internet 954 may be transmitted to the NAT gateway 938 that can make the call to public Internet 954.
• Memory that may be desired to be stored by the request can be stored in the DB subnet(s) 930.
• the data plane mirror app tier 940 can facilitate direct communication between the control plane VCN 916 and the data plane VCN 918. For example, changes, updates, or other suitable modifications to configuration may be desired to be applied to the resources contained in the data plane VCN 918. Via a VNIC 942, the control plane VCN 916 can directly communicate with, and can thereby execute the changes, updates, or other suitable modifications to configuration to, resources contained in the data plane VCN 918.
• control plane VCN 916 and the data plane VCN 918 can be contained in the service tenancy 919.
• the user, or the customer, of the system may not own or operate either the control plane VCN 916 or the data plane VCN 918.
• the IaaS provider may own or operate the control plane VCN 916 and the data plane VCN 918, both of which may be contained in the service tenancy 919.
• This embodiment can enable isolation of networks that may prevent users or customers from interacting with other users’, or other customers’, resources. Also, this embodiment may allow users or customers of the system to store databases privately without needing to rely on public Internet 954, which may not have a desired level of threat prevention, for storage.
• a secure host tenancy 1004 (e.g. the secure host tenancy 904 of FIG. 9) can include a virtual cloud network (VCN) 1006 (e.g. the VCN 906 of FIG. 9) and a secure host subnet 1008 (e.g. the secure host subnet 908 of FIG. 9).
• the VCN 1006 can include a local peering gateway (LPG) 1010 (e.g. the LPG 910 of FIG. 9) that can be communicatively coupled to a secure shell (SSH) VCN 1012 (e.g. the SSH VCN 912 of FIG. 9) via an LPG 910 contained in the SSH VCN 1012.
• LPG local peering gateway
• SSH secure shell
• Each compute instance 1044 may allow communication between the control plane VCN 1016, contained in the service tenancy 1019, and the data plane VCN 1018 that is contained in the customer tenancy 1021.
• the compute instance 1044 may allow resources, that are provisioned in the control plane VCN 1016 that is contained in the service tenancy 1019, to be deployed or otherwise used in the data plane VCN 1018 that is contained in the customer tenancy 1021.
• the customer of the IaaS provider may have databases that live in the customer tenancy 1021.
• the control plane VCN 1016 can include the data plane mirror app tier 1040 that can include app subnet(s) 1026.
• the customer may desire to deploy or otherwise use resources in the data plane VCN 1018 that are provisioned in the control plane VCN 1016, and the data plane mirror app tier 1040 can facilitate the desired deployment, or other usage of resources, of the customer.
• the customer of the IaaS provider can apply filters to the data plane VCN 1018.
• the customer can determine what the data plane VCN 1018 can access, and the customer may restrict access to public Internet 1054 from the data plane VCN 1018.
• the IaaS provider may not be able to apply filters or otherwise control access of the data plane VCN 1018 to any outside networks or databases.
• the control plane VCN 1216 can include the service gateway 1236 and the NAT gateway 1238.
• the data plane VCN 1218 can include a data plane app tier 1246 (e.g. the data plane app tier 946 of FIG. 9), a data plane DMZ tier 1248 (e.g. the data plane DMZ tier 948 of FIG. 9), and a data plane data tier 1250 (e.g. the data plane data tier 950 of FIG. 9).
• the data plane DMZ tier 1248 can include LB subnet(s) 1222 that can be communicatively coupled to trusted app subnet(s) 1260 (e.g. trusted app subnet(s) 1060 of FIG.
• a basic input/output system containing the basic routines that help to transfer information between elements within computer system 1300, such as during start-up, may typically be stored in the ROM.
• system memory 1310 also illustrates application programs 1312, which may include client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), etc., program data 1314, and an operating system 1316.
• application programs 1312 may include client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), etc.
• program data 1314 and an operating system 1316.
• Computer system 1300 can be one of various types, including a handheld portable device (e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.
• a handheld portable device e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA
• a wearable device e.g., a Google Glass® head mounted display
• PC personal computer system
• workstation e.g., a workstation
• mainframe e.g., a mainframe
• a kiosk e.g., a server rack
• server rack e.g., a server rack
• Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is intended to be understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.
• Preferred embodiments of this disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• General Engineering & Computer Science (AREA)
• Human Computer Interaction (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Stored Programmes (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=81307911

Family Applications (1)

Country Status (5)

Families Citing this family (4)

Citations (2)

Family Cites Families (46)

• 2021
  • 2021-07-29 US US17/389,116 patent/US11949761B2/en active Active
• 2022
  • 2022-03-09 WO PCT/US2022/019566 patent/WO2023009179A1/en not_active Ceased
  • 2022-03-09 CN CN202280050591.6A patent/CN117751347A/zh active Pending
  • 2022-03-09 JP JP2024505083A patent/JP7813868B2/ja active Active
  • 2022-03-09 EP EP22716605.5A patent/EP4377789B1/en active Active
• 2024
  • 2024-02-13 US US18/440,079 patent/US12348599B2/en active Active

Patent Citations (2)

Also Published As

Similar Documents

Legal Events