Patent Description:
Enterprises and organizations rely increasingly on cloud service providers to furnish computing resources and platforms for their operational needs. Technical components for cloud hosting, such as data storage layers and virtual machines for web servers, application servers, and databases servers are frequently requested and commissioned by remote operators authorized within an organizational unit through, e.g., a central cloud resource control system. Improvements in communication among the authorized operators regarding the control, monitoring and operation of technical components will further enhance the technical capabilities of cloud computing systems.

In International Patent Application Publication <CIT>, there are described techniques and mechanisms that enable collection of various types of data from cloud computing services and the generation of various dashboards and visualizations to view information about collections of cloud computing resources.

In United States Patent Application Publication <CIT>, there are described examples of virtualization management using a centralized server. In one example, a centralized server obtains metadata of an operating system and information on provisioning computing resources from a software vendor. The centralized server is deployed within an internal network of a customer of the software vendor, where the internal network further includes a set of at least one physical machine.

Enterprises and their individual organizational units (collectively referred to as OUs) rely increasingly on technical components such as virtual machines, webservers, and databases hosted by cloud computer service providers. Computing the cost to an OU attributable to technical components in the cloud may be directly tied to the number of actively commissioned technical components and their capabilities. The capability of a technical component typically correlates with the types and amounts of cloud resources the technical component includes. A commissioned technical component may become idle or under-used over time as the computing tasks it handles for the OU evolve or end. While actual usage of such a technical component may be monitored, a decision to decommission or reconfigure may depend on other business or operational considerations of the OU not readily reflected in monitored usage information. For example, decommission or reconfiguration decisions for the technical component may depend on future plans and thus may need input from multiple responsible parties for the OU associated with the technical component. Such decisions thus involve various rounds of communications and conversations among the multiple operators using isolated communication tools such as email and instant messaging. Invoking separate communication tools amidst tasks of controlling and provisioning the technical components has in the past been cumbersome, leading to delay or omission of important communications. Yet, timely and efficient decommission and reconfiguration decisions are critical for reducing computing cost for the OU.

As described below, communications about the technical components among operators may be integrated in a central resource controller for cloud resources. Specifically, a technical component allocated to an OU may be controlled and provisioned through the central resource controller by the remote operators associated with the technical component and authorized by the OU. Each operator authorized to carry out control tasks of the technical component may be given a control account in the central resource controller for accessing the control account remotely. Conversation related to the technical component may be automatically processed by the central resource controller while the technical component is being controlled or provisioned by the remote operators using tagging data in the form of notes. These notes may be unstructured in that they do not have any predefined required sections, components, or formatting, and may be freely input by the remote operators while controlling or provisioning the technical component. These unstructured notes may be alternatively referred to as tagging data, unstructured tagging data, metadata tags, unstructured tags, and the like. Each unstructured note may be associated with a particular technical component and entered by a particular authorized operator. As such, an operator does not need to switch to any separate and isolated communication tool, leading to improvement in communication and decision efficiency. The conversation and ultimate decision about a technical component is thus brought closer to the computing resources via the central resource controller. Recording of the unstructured notes provides a conversational history of the technical components which, in combination with control, provisioning actions taken, may provide more thorough audit trails of the technical components than any other compilation of purely technical or transactional data such as a configuration history.

For example, an operator, while monitoring and controlling a technical component in the central resource controller, may notice that the technical component has become idle and the operator is aware of no immediate future task that could be assigned to the technical component. Rather than invoking a separate communication tool, e.g., an email client, to communicate a message recommending decommission of the technical component to other operators associated with the technical component, the operator may use the central resource controller for tagging the technical component with unstructured notes containing her recommendation. The unstructured note may further trigger automatic actions, including automatic communication of her recommendation to other operators associated with the technical component, and other provisioning or control actions for the technical component. The actions may be automatically triggered either while the unstructured notes is being entered or after the unstructured note is entered in its entirety.

The disclosure below describes several exemplary implementations of tagging technical components using unstructured notes by remote operators in communication with the central resource controller. While the description below may focus on creation of unstructured notes and communication actions of information and recommendations among the operators triggered by the unstructured notes, the underlying principles and solutions apply to other control and provisioning actions of the technical component. In addition, the implementations below may refer to a particular technical component as an example. These implementations, however, are applicable to many different types of technical components hosted by cloud providers.

<FIG> illustrates a cloud computing environment in which a central resource controller and a separate tagging data controller may be implemented. The example in <FIG> shows one of many possible different implementation contexts. In that respect, the technical solutions below are not limited in their application to the architecture and system shown in <FIG>, but are applicable to many other cloud computing implementations, architectures, and connectivity.

<FIG> shows an exemplary cloud computing environment as a global cloud hosting and control system <NUM>. Distributed through the global cloud hosting and control system <NUM> are cloud computing service providers, e.g., the service providers <NUM>, <NUM>, <NUM>, and <NUM> and various technical components hosted by the service providers in the form Infrastructure as a Service (IaaS) or Platform as a Service (PaaS), such as Virtual Machines (VMs), webservers, and databases. The global cloud hosting and control system <NUM> further includes remote operators and remote operator devices <NUM> associated with OUs <NUM>; a Central Resource Controller (CRC) <NUM>; and a tagging data controller <NUM>. These distributed components of the global cloud hosting and control system <NUM> are interconnected by networks <NUM>. The networks <NUM> may include private and public networks defined over any predetermined and possibly dynamic internet protocol (IP) address ranges.

The service providers <NUM>, <NUM>, <NUM>, and <NUM> may be located in any geographic region, e.g., United States (US) East, US West, or Central Europe. The geographic regions that characterize the service providers may be defined according to any desired distinctions to be made with respect to location. A service provider may provide cloud computing infrastructure in multiple geographic locations.

The service providers <NUM>, <NUM>, <NUM>, and <NUM> may further provide computing resources in the form of IaaS or PaaS via hosting platforms. Each service provider has a widely varying set of technical characteristics in the individual target hosting platforms. Service providers <NUM>, <NUM>, <NUM>, and <NUM> may support hosting platforms of similar or different characteristics for providing computing resources.

For instance, <FIG> shows a target hosting platform implemented by a data center <NUM> for the service provider <NUM>. The data center <NUM> supports running many different virtual machines (VMs). The data center <NUM> may include a high density array of network devices, including routers and switches <NUM>, and host servers <NUM>. The host servers <NUM> support a particular set of computing functionality offered by the service provider <NUM> from the data center <NUM>.

As just one of many examples, the service provider <NUM>, through the data center <NUM> and its other infrastructure, may support many different types of VMs, differing by number of processors, amount of RAM, and size of disk, graphics processors, encryption hardware, or other properties; multiple different types of web front ends (e.g., different types and functionality for websites). The service provider <NUM> may further support several different types of database solutions (e.g., SQL database platforms); secure data storage solutions, e.g., payment card industry (PCI) data (or any other secure data standard) compliant storage; several different types of application servers; and many different types of data tiers. Further, the service provider <NUM> and the data center <NUM> may have various characteristics, including whether the data center <NUM> is an on-premise or public location; which networks can provide connectivity to the data center <NUM>; which assets the service provider <NUM> supports; and other characteristics.

Examples of service providers <NUM>, <NUM>, <NUM> and <NUM> include Amazon, Google, Microsoft, and Accenture, who offer different target hosting platforms, e.g., Amazon Web Services (AWS), Google Compute Engine (GCE), Microsoft Azure (Azure), Accenture Cloud Platform (ACP), and Windows Azure Stack (WAS).

The global cloud hosting and control system <NUM> may further include OUs, such as the example OU <NUM> illustrated in <FIG>. The OU <NUM> may be in need of computing services for their business and operations and may request and obtain various technical components each including a set of computing resources hosted by the service providers. A technical component, may, for example, be a VM as an infrastructure or a webserver offered as platform. Each technical component may be requested by the OU <NUM> and instantiated by the service provider to include a requested amount of hardware computing resources such as CPUs, Storage spaces, and memories. Operating system and other software stacks for these technical components may be installed by the OU after the requested technical component is instantiated or may be provided by the service provider with the technical component upon request.

The OU <NUM> may request technical components from more than one service providers of <NUM>, <NUM>, <NUM>, and <NUM>, depending on its various computing needs of different characteristics and the characteristics of the hosting platform provided by the various service providers. These request may be made via the CRC <NUM>. Once a group of technical components are instantiated by the service providers for the OU <NUM>, a team of operators <NUM> of the OU <NUM> may be given authority by the OU to control, monitor, and perform complex cloud architectural provisioning of the allocated technical components via the CRC <NUM>. The authority, may be given in the form of control accounts each assigned to an authorized operator.

The control accounts may be accessed by the operators <NUM> remotely via remote operator devices including but not limited to personal computers, tablets, and mobile phones. The remote operator devices may be also referred to as remote operators even though a remote operator may access his/her control account via different remote operator devices and similarly, one remote operator device may be used by different remote operators to access their control accounts. A remote operator or remote operator device may be simply referred to below as an operator or operator device, e.g., the operators <NUM>. An operator <NUM> may be given access to all technical components allocated to the OU. Alternatively, an operator <NUM> may be given access to a subset of the technical components of the OU. The OU may further restrict the scope of control and provisioning that an operator can perform.

As shown in <FIG>, the global cloud hosting and control system <NUM> may further include the CRC <NUM>, which provides a central point for the OU and the remote operators to make complex cloud architectural provisioning and execute decisions across multiple cloud services, taking into account the global network architecture <NUM>, the various service provider locations and capabilities, and other factors. CRC <NUM> may include resource controller processing circuitry <NUM>. The resource controller processing circuitry <NUM> is configured, among other functions, to provide a user interface to the remote operator <NUM> for controlling and provisioning various technical components hosted in the cloud. In particular, the resource controller circuitry <NUM> is configured to provide a user interface to the operator <NUM> for creating tagging data in the form of unstructured notes for technical components. The user interface, for example may be hosted in a webserver of the CRC <NUM> and provided to the remote operator <NUM> as, e.g., a dashboard, viewed and operated via a web browser application on the remote operator device <NUM>. Alternatively, the user interface may be provided by an interface server of the CRC <NUM> and provided to the remote operator <NUM> as a dashboard via a client-end application installed on the operator device <NUM>.

Among the many control and provisioning functions that may be performed by the operator <NUM> via the user interface, the operator <NUM> may in particular input tagging data in the form of unstructured notes linked to technical components. Accordingly, the global cloud hosting and control system <NUM> may further include a tagging data controller <NUM> for tracking and processing the unstructured notes provided by the operator <NUM> for tagging technical components. In particularly, the tagging data controller <NUM> may include repositories for the tagging data or unstructured notes. For example, the repositories for tagging data may include a soft tag repository <NUM> which stores all unstructured note data, and a hashtag repository <NUM> for maintaining hashtags processed from the unstructured note data. It is further contemplated that other processed data items from the raw unstructured notes may be maintained in various other repositories. Each of these repositories for the unstructured notes and data items processed from the unstructured notes may alternatively be broadly referred to as service items of the tagging data controller <NUM>. A service item thus may refer to the soft tag repository, the hashtag repository, or another repository derived from the unstructured notes. The service items that are processed from the unstructured notes such as the hashtag repository <NUM>, provide processed intermediate data items and thus help speed up response to inquiries for information from the remote operator <NUM>. The various repositories above may be implemented in any type of database.

The tagging data controller <NUM> may further include tagging controller processing circuitry <NUM>. The tagging controller processing circuitry <NUM> may be configured to maintain the soft tag repository, processing the unstructured notes into processed repositories such as the hashtag repository <NUM>. The tagging controller processing circuitry <NUM> may further provide processed tagging data to the remote operator <NUM> either directly or via the CRC <NUM>.

Further, the tagging data controller <NUM> may be configured to process the unstructured notes to identify action triggers. Action triggers may be directly embedded in the unstructured notes as, for example, predefined signaling special characters or symbols that may appear in the unstructured notes. A symbol, as an action trigger, may contain one special character or a special sequence of characters. Alternatively, action triggers may be derived from analyzing one or more unstructured notes and/or the service items against some predefined policies. The policies may include predefined conditions required for each particular predefined action. The policies may further include instructions for performing each particular predefined actions. Accordingly, the tagging data controller <NUM> may further include a policy repository <NUM> for maintaining the policies for deriving action triggers and instructions for actions. The actions being triggered may include any control, provisioning tasks for the technical components hosted in the cloud, and may include automatic communication/conversation actions among remote operators associated with a particular technical component.

Alternative to the implementation above, the CRC <NUM> and the tagging data controller <NUM> may be integrated together rather than being separate entities in communication with one another. Further, some of the action triggers may alternatively be identified within the user interface (e.g., resource dashboard) in the remote operator device rather than by the tagging data controller. For example, predefined special symbols that signify predefined actions may be monitored at the user interface as the unstructured note is being input by the remote operator <NUM>, rather than after the unstructured note is communicated to and being processed by the tagging data controller <NUM>. As such, the user interface on the remote operator device <NUM> may directly perform the triggered actions. In the case where the triggered actions require data or parameters from a backend, such data may be requested by the remote operator device from the backend directly to via the CRC <NUM> or the tagging data controller <NUM>. Such a backend, may be part of or separate from CRC <NUM> or the tagging data controller <NUM>.

<FIG> illustrates a functional block diagram <NUM> for the remote operator device <NUM>, the CRC <NUM>, and the tagging data controller <NUM> above. Specifically, the remote operator device <NUM> provides a user interface to the remote operator. For example, the user interface may include resource dashboard <NUM> for monitoring and controlling technical components hosted in the cloud. The remote operator may use his/her control account to login and access the resource dashboard <NUM>. Other user interfaces may be further provided. For example, an analytics dashboard <NUM> may be provided to the remote operator for viewing and performing analytics of the usage and operation of technical components hosted in the cloud. The dashboards <NUM> and <NUM> may be generated, for example, by a web browser application running on the remote operator device <NUM>. The web browser application may download the dashboard from a web server in the CRS <NUM> via networks <NUM>. As such, the CRC <NUM> may provide a Ul backend <NUM> including a resource dashboard backend <NUM> and an analytics dashboard backend <NUM> such as web servers for hosting the dashboards.

Input from the user interface <NUM> of <FIG>, such as an unstructured note for a technical component, may be communicated to the user interface backend <NUM> of the CSC <NUM>. The unstructured note may be further communicated from CRC112 to a tagging data backend <NUM> of the tagging data controller <NUM>. The tagging data backend <NUM> may include soft tag repository handler <NUM> and hashtag repository handler <NUM> for processing unstructured notes for technical components, creating and serving the service items discussed above. The tagging data backend <NUM> may further include a policy handler <NUM> for maintaining policies and conditions for triggering pre-configured actions and for detecting action triggers in the unstructured notes, and for maintaining or generating instructions for performing the pre-configured actions.

Finally, both the user interface backend <NUM> of the CRC <NUM> and the tagging data backend <NUM> of the tagging data controller <NUM> may further provide APIs <NUM> and <NUM> to the user interface <NUM> for performing functions in the dashboards <NUM> and <NUM>. For example, other data resources not drawn in <FIG> and <FIG> may be provided to the user interface <NUM> via the APIs <NUM> and <NUM>.

<FIG> shows an example implementation of a processing circuitry <NUM> for implementation of the resource controller processing circuitry <NUM>, the tagging controller processing circuitry <NUM>, or a processing circuitry in the remote operator device <NUM> of <FIG>. The processing circuitry <NUM> includes communication interfaces <NUM>, system resources <NUM>, and input/output (I/O) interfaces <NUM>. The I/O interfaces <NUM> may include graphical user interfaces (GUIs), touch sensitive displays, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I/O interfaces <NUM> include microphones, video and still image cameras, headset and microphone input / output jacks, Universal Serial Bus (USB) connectors, memory card slots, and other types of inputs. The I/O interfaces <NUM> may further include magnetic or optical media interfaces (e.g., a CDROM or DVD drive), serial and parallel bus interfaces, and keyboard and mouse interfaces.

The communication interfaces <NUM> may include wireless transmitters and receivers ("transceivers") <NUM> and any antennas <NUM> used by transmission and receiving circuitry of the transceivers <NUM>. The transceivers <NUM> and antennas <NUM> may support Wi-Fi network communications, for instance, under any version of IEEE <NUM>, e.g., <NUM>. 11n or <NUM>. The communication interfaces <NUM> may also include wireline transceivers <NUM>. The wireline transceivers <NUM> may provide physical layer interfaces for any of a wide range of communication protocols, such as any type of Ethernet, data over cable service interface specification (DOCSIS), digital subscriber line (DSL), Synchronous Optical Network (SONET), or other protocol.

The system resources <NUM> may include any combination of hardware, software, firmware, or other logic. The system resources <NUM> may be implemented, for example, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), microprocessors, discrete analog and digital circuits, and other circuitry. The system resources <NUM> is part of the implementation of any desired functionality in the CRC <NUM>, the tagging data controller <NUM>, and the remote operator device <NUM>. As just one example, the system resources <NUM> may include one or more instruction processors <NUM> and memories <NUM>. The memory <NUM> stores, for example, control instructions <NUM> and an operating system <NUM>. The processor <NUM> executes the control instructions <NUM> and the operating system <NUM> to carry out any desired functionality for the CRC <NUM>, the tagging data controller <NUM>, and the remote operator device <NUM>.

<FIG> shows an example user interface <NUM> in the form of a resource dashboard for technical components on a remote operator device <NUM>. A remote operator, e.g., operator <NUM>, may log into the dashboard user interface <NUM>. The user interface <NUM>, for example may include identifier <NUM> for operator <NUM>. Optionally, operator <NUM> may choose to view or control all or a specific type of technical components using drop down menu <NUM>. In this particular example, operator <NUM> chooses to view only VMs and as a result, VMs associated with operator <NUM> are listed in <NUM>. Properties for each VM may be listed, including but not limited to name <NUM> of the VM, operating system <NUM> installed in the VM, service provider <NUM> hosting the VM, and unstructured note <NUM> for the VM. The unstructured note <NUM> for each VM may include the currently active note for the VM, i.e., the most recently entered unstructured note for the VM by all operators.

Operator <NUM> may enter an unstructured note for technical component in various ways. For example, Operator <NUM> may mouse-click one of the editing symbols <NUM> that responds by displaying an input field for entering an unstructured note for a particular technical component. In the example <FIG>, Operator <NUM> may click the editing symbol <NUM> for inputting unstructured note for VM2-<NUM>. As shown in <FIG>, a note input user interface <NUM> may be presented to operator <NUM> upon clicking the editing symbol <NUM>. The note input user interface <NUM> may include an identifier <NUM> for the selected technical component (VM2-<NUM> in this case) and an input box <NUM> for entering unstructured note. Operator <NUM> may enter any unstructured note by typing in the input box <NUM>. The notes may be discarded by selecting the "Cancel" button <NUM> or kept by selecting the "Save" button <NUM>.

Returning to <FIG>, operator <NUM> may enter notes for multiple technical components by first selecting these technical components by checking corresponding checkboxes <NUM> and then click the "Edit Notes" button <NUM>. As a result, a note input user interface <NUM> in <FIG> may be presented to operator <NUM>. Operator <NUM> may be given options <NUM> to enter a same note for all selected technical components or enter separate notes for each selected technical component. In <FIG>, by highlighting the "No" selection, it is set as a default for operator <NUM> to enter the same note for all selected technical components. As such, operator <NUM> may type an unstructured note in the input box <NUM>, either cancel or save the note using button <NUM> and <NUM>. Once the "Save" button <NUM> is selected, the entered unstructured note will be recorded against all selected technical components. Operator <NUM> may alternatively select "Yes" option <NUM> in <FIG>, prompting the note input user interface <NUM> to be presented as shown in <FIG>. In <FIG>, multiple input boxes are provided to operator <NUM> for entering separate unstructured notes for each selected technical component (VM1-<NUM>, and VM2-<NUM> in this case). Again, operator may cancel or keep the entered unstructured notes using buttons <NUM> and <NUM>.

Once notes are entered by operator <NUM> for selected technical components, each of these newly entered notes become an active note and is listed in the user interface <NUM>, as shown in <FIG>. The notes are unstructured and may contain any text or symbols. For example, the notes shown in <NUM> of <FIG> contains normal text as well as symbols such as "#" and "@". As will be descried in detail below, these symbols may be predefined and may be used as triggers for control, provisioning, and automatic communication actions.

The user interface <NUM> of <FIG> may further provide a way to operator <NUM> for viewing notes for each technical component in detail. For example, the user interface <NUM> may be configured such that operator <NUM> may click on any technical component, e.g., technical component VM1-<NUM> labeled as <NUM> in <FIG>, to bring up a technical component interface <NUM> of <FIG> for VM1-<NUM>. The technical component interface <NUM> may, for example, include a menu for operator <NUM> to select one of a set of predefine information categories of the technical component to view. These predefined information categories may, for example, include "summary" <NUM>, "detail" <NUM>, "relationships" <NUM>, and "notes" <NUM>. Operator <NUM> may select an information category by clicking the corresponding menu item. For example, when the category "notes" is selected, detailed note information is presented to operator on sections <NUM> and <NUM> of the technical component interface <NUM>.

In particular, block <NUM> in the technical component interface <NUM> shows information about the active note, i.e., the most recently entered unstructured note for VM1-<NUM>, including the content <NUM> of the active unstructured note, the author and input time <NUM> of the note. Further, if the active note was entered by operator <NUM>, operator <NUM> may be further provided an "update" button <NUM> for updating the active note, and/or a "clear" button <NUM> for removing the active note. If the active note was entered by an operator other than operator <NUM>, these two buttons may or may not be provided. Optionally, a button may be further provided such that when that button is selected, operator <NUM> may be directed to the note input user interface <NUM> of <FIG> for entering a new note, and once entered, the new note becomes active.

Block <NUM> in the technical component interface <NUM> shows history information about notes for VM1-<NUM>, including a list of prior notes <NUM> and <NUM>, and their authors and input times <NUM> and <NUM>. A button <NUM> may be further provided for operator <NUM> to clear the note history for VM1-<NUM>.

The special symbols such as "#" and "@" discussed above and appearing in the list <NUM> of <FIG> may be predefined and used as triggers for control, provisioning, and automatic communication actions. For example, the symbol "#" may be used as an indication of a hashtag. That is, a string of characters following "#" and ending with, e.g., a space or other predefined delimiters, may be recognized as a hashtag. For example, in the note input user interface <NUM> of <FIG>, operator <NUM> types a note <NUM> "This is very #expensive. " The note input user interface may monitor the note while being typed and detect the "#" symbol and recognize "expensive" as a hashtag. Upon, for example, completing the note input by clicking the "Save" button <NUM>, the recognized hashtag may be communicated to the tagging data controller of <FIG> and recorded into the hashtag repository <NUM>. Alternatively, the detection of the "#" symbol and extraction of the hashtag may be performed by the tagging data controller after the entire note is submitted.

As shown in <FIG>, the note input user interface <NUM> may be further configured to provide operator <NUM> a list of recorded hashtags <NUM> as soon as the symbol "#" <NUM> is detected by the note input user interface <NUM>. Specifically, upon detecting the predefined symbol "#", the note input user interface <NUM> recognizes that operator <NUM> is about to input a hashtag and proceeds to proactively and automatically suggest hashtags previously recorded in the hashtag depository <NUM> of <FIG>. These suggested hashtags may be a set of hashtags previously used by operator <NUM>. Alternatively, these suggested hashtags may be a set of hashtags previously used by a group of operators for the particular technical component (VM2-<NUM>, in this case). As another alternative, these suggested hashtags may be hashtags used by other OUs when controlling and provisioning similar technical components. These suggested hashtags may be listed in order of use frequency with the most frequently used hashtag being at the top of the suggested list. Operator <NUM> may select a hashtag from the list and upon such selection, the selected hashtag is automatically filled in the body of the note <NUM>. Operator <NUM> may alternatively ignore the suggestion and continue typing. As operator <NUM> continues to type a set of characters following the "#" symbol, the note input user interface <NUM> further narrows down the suggested list of hashtags <NUM> such that each of the presented hashtags in the list includes a subset of characters that match what have been typed by operator <NUM> following symbol "#". The note input user interface <NUM> may remove the suggested list of hashtags from being displayed when no matching can be found.

The suggested list of hashtags may be obtained by the note input user interface <NUM> from the tagging data controller <NUM> of <FIG> in real-time by making real-time inquiries to the tagging data controller <NUM>. These inquiries may be made via the API <NUM> of <FIG> provided by the tagging data controller. Upon receiving the real-time inquiries, the tagging data controller may search the hashtag repository <NUM> of <FIG> to determine a list of matching hashtags and return the list to the note input user interface <NUM> of <FIG>.

The note input user interface <NUM> may further show trending of hashtags, as shown by <NUM> of <FIG>. Specifically, upon invoking the note input user interface <NUM>, the tagging data controller <NUM> may be inquired to provide preprocessed or real-time processed trending information of hashtags. The trending information of hashtags may represent the number of times the hashtags have been used by either operator <NUM>, the OU authorizing operator <NUM>, other OUs, or for a particular type of technical components. The trending information block <NUM> may alternatively show trending of a subset of hashtags having higher usage.

Operator <NUM> may further be provided a user interface for viewing a list of technical components associated with a particular hashtag. For example, when viewing the full list of technical components in the user interface <NUM> of <FIG>, operator <NUM> may select the particular hashtag, e.g., hashtag "expensive" <NUM>, to invoke the user interface <NUM> shown in <FIG>. Specifically, in list <NUM> of the user interface <NUM>, only the technical components having notes embedded with hashtag "expensive" are shown. Alternatively, operator <NUM> may select the "#" symbol in list <NUM> of <FIG> and technical components having notes embedded with any hashtag may be presented to operator <NUM> in list <NUM> of the user interface <NUM>.

Certain hashtags may be reserved for triggering automatic provisioning, control, and communication actions. For example, detection of hashtag, e.g., "expensive" following the special symbol "#" may be trigger an automated alerts, such as email to members of the OU, alerting them that the technical components has been tagged with the hashtag "expensive". For another example, detection of hashtag, e.g., "expensive" may trigger a provisional action that places the technical component in a resource group with restricted access. In a further example, a hash tag "zombie" following the special symbol "#" may trigger decommission the technical component, and a hash tag "glutton" may trigger automatic resizing of the technical component.

As another example, a special symbol "@" may be predefined. The symbol "@" may be used to trigger any pre-defined actions. For instance, the predefined symbol "@" may be used for triggering communication actions via email. As shown in the note input user interface <NUM> of <FIG> for technical component VM2-<NUM>, when the symbol "@" <NUM> is detected by the note input user interface <NUM> as it is being typed by operator <NUM>, a list of suggested entities associated with VM2-<NUM> may be presented in menu <NUM>. The entities may be identified by email addresses for specific individuals, group email address, or other communication channels. These entities may include among others, other operators of the OU. Operator <NUM> may choose one, more, or all items listed in the menu <NUM>. The chosen entities may be populated in the input box <NUM> and operator <NUM> may continue to type the unstructured note, as shown in the input box <NUM> of <FIG>. Operator <NUM> may alternatively ignore the suggestion and continue typing. As operator <NUM> continues to type a set of characters following the "@" symbol, the note input user interface <NUM> further narrow down the suggested list of suggested entities such that the presented entities in the list include a subset of characters that match what have been typed by operator <NUM>, as shown by the typed content <NUM> and the list of suggested entities <NUM> of <FIG>. The note input user interface <NUM> may remove the menu of suggested list of entities from being displayed when no matching entities can be found.

The suggested list of entities may be obtained by the note input user interface <NUM> from the CSC <NUM> of <FIG> in real-time by making real-time inquiries to the CSC <NUM>. These inquiries may be made via the API <NUM> of <FIG> provided by the CSC <NUM>. Upon receiving the real-time inquiries, the CSC <NUM> may search an entity database (not shown in <FIG>) to obtain a list of suggested entities. The entity data base, for example, my include a database for the operators authorized by the OU. The entity database may reside with and be part of the CSC <NUM>. Alternatively, the entity database may reside on a separate and independent server that provides a list of suggested entities to the CSC112 upon request. In some implementation, the returned list of entities may include IDs, names, and/or email addresses.

Upon completing entering a note <NUM> of <FIG> including the "@" symbol, operator <NUM> may click the "Save" button <NUM>. Thereafter, the remote operator device <NUM> via the user interface <NUM> of <FIG> may detect the "@" symbols in the unstructured note <NUM> entered by operator <NUM> and trigger automatic sending of emails to entities specified after the @symbols and before predetermined delimiters. If the email addresses of the specified entities have not yet been inquired by the operator device from the CRC <NUM>, they may now be obtained from the CRC <NUM> via additional inquiries. The operator database containing email address of entities may be maintained by the CRC <NUM> or may alternatively be maintained by a separate and independent server.

Alternatively, the automatic emails may be triggered and sent by the CRC <NUM> rather than the remote operator device <NUM>. Specifically, the unstructured note <NUM> of <FIG> entered by operator <NUM> may be communicated to the CRC <NUM> and the tagging data controller <NUM> of <FIG>. The tagging data controller <NUM> may process the unstructured note <NUM> in similar manner as described above. The CRC <NUM> may process the unstructured note <NUM>, detect "@" symbols contained therein, obtain email addresses of the entities specified after the "@" symbols and before the predetermined delimiters, and automatically send emails to the specified entities.

Exemplary content of the emails sent either by the remote operator device <NUM> or the CRC <NUM> is shown in <NUM> of <FIG>. The content, for example, may include the entire unstructured note. Context information including the name of the technical component (VM2-<NUM> in this exemplary case) and the author of the note (Operator <NUM> in this exemplary case) may be further included in the content of the email <NUM>.

The user interface at the remote operator device <NUM> may be further configured to display a list of technical components have unstructured notes containing the predefined "@" symbol. For example, operator <NUM> may click an operator name <NUM> in the list of unstructured notes <NUM> of <FIG>. As a result, the user interface <NUM> of <FIG> may be presented to operator <NUM>. The user interface <NUM> may contain technical components having unstructured notes including the clicked operator name, as shown by <NUM> of <FIG>. Alternatively, operator <NUM> may click the "@" symbol in the list <NUM> of <FIG> and a user interface showing any technical component having unstructured notes including the "@" symbol may be presented to operator <NUM>.

It should be noted that an unstructured note may contain any number of predefined symbols, e.g., both the predefined "#" and "@" symbols. The principles of operation described above for the "#" symbol and the "@" symbol both apply. Further, the predefined "#" and "@" symbols are only two examples of possible predefined symbols. Other symbols may be predetermined for triggering other types of control, provisioning, and communication actions either by the remote operator device <NUM> or the CSC <NUM> of <FIG>. Further, the CSC <NUM> may be configured to perform natural language processing on the unstructured notes. Semantic information may be extracted from unstructured notes using a natural language model based on, for example, machine learning algorithms. The natural language model may be a semantic classifier for classifying each unstructured note. Depending on the classification of the one or more unstructured notes related to a technical component, a control, provisioning, or communication action may be triggered. The correspondence between the classification of the one or more unstructured notes and the action to be triggered may be specified in the policy repository <NUM>. For example, a policy may instruct an automatic power-off and power-on schedule for the technical component if more than e.g., half of the unstructured notes associated with the technical component are classified to mean that the technical components is needed only during business hours.

The unstructured notes in the tagging data repositories <NUM> may be processed and optionally combined with the triggered control, provisioning, and communication actions to provide a conversational history of the technical component. The conversational history may be stored and updated in a separate repository and provided to a remote operator via the resource dashboard or the analytics dashboard. Alternatively, the conversational history may be generated from the tagging data repository on demand. The conversational history may provide more thorough audit trails of the technical components than any other compilation of purely technical or transactional data such as a configuration history.

Further analytics on the unstructured notes may be performed. The output of the analytics may be provided to a remote operator via either the resource dashboard or the analytics dashboard. For example, as shown by <NUM> of <FIG>, analytics on trending of usage of hashtags within the OU may be provided to the remote operator via the resource dashboard or analytics dashboard. The trending of usage of the hashtags by the remote operators of the OU may be visually represented by, e.g., font size of the hashtags. For example, larger font size may represent more frequent usage. Alternatively or additionally, colors may be used for visualizing trending of the hashtags. For example, red font may be used to represent higher usage. The hashtags may be arranged in any geometric order. For example, the hashtags may be arranged alphabetically. Alternatively, hashtags with higher usage may be arranged ahead of the hashtags with lower usage. For another example, the hashtags may be arranged in a circle with the more frequently used hashtags located closer to the center of the circle.

As shown by <NUM> of <FIG>, a remote operator may further obtain a list of notes entered by him/her for various technical components via either the resource dashboard or the analytics dashboard. Upon request by the remote operator for such a list using the example "My Notes" option <NUM>, the CRC <NUM> and the tagging data controller <NUM> process the unstructured notes for various technical components to compile a list of notes entered by the remote operator. The list may be ordered by date or in any other manner. The notes in the list may be further organized in groups each for a particular technical component. Each note shown in <NUM> of <FIG> may contain the note itself <NUM> and the ID of the corresponding technical component <NUM>. Each note may contain hyperlinks. For example, clicking on the ID <NUM> of a technical component may redirect the remote operator to a user interface for viewing information of the clicked technical component.

Further, the remote operator may be provided an option to view notes in which the remote operator is mentioned via, e.g., the "@" symbol. For example, selectable option "Mentions" <NUM> may be provided together with the "My Notes" option <NUM>. Upon selecting option <NUM>, a list of notes entered by any remote operator that mention the requesting remote operator may be shown. Again, the list may be ordered by date or in any other manner. The notes in the "Mentions" list may be further organized in groups each for a particular technical component. Each note may contain the note itself and the ID of the corresponding technical component. Each note may contain a hyperlink to the corresponding technical component for, e.g., redirecting the remote operator to a user interface for viewing information of the technical component.

The analytics interfaces above are mere examples that facilitate visualization and organization of information contained in the unstructured notes. These analytics may be provided as widgets in the resource dashboard or analytics dashboard for efficient management of technical components of the OU.

<FIG> shows logic <NUM> that the global cloud hosting and control system <NUM> may implement with respect to the remote operator device <NUM> and the CRC <NUM>/tagging data controller <NUM>. The remote operator device provides a login interface for a remote operator to log into a CRC account of the remote operator (<NUM>). A user interface in the form of, e.g., a dashboard for technical components is displayed by the remote operator device (<NUM>). A note input user interface is invoked by the operator for one or more technical components (<NUM>). Additionally, a hashtag inquiry may be sent to the tagging data controller <NUM> for hashtag trending information (<NUM>). The tagging data controller receives the inquiry and access the hashtag repository (<NUM>). The tagging data controller processes the data from the hashtag repository, extracts trending information for hashtags, and returns the hashtag trending information to the user interface at the remote operator device (<NUM>). The note input user interface at the remote operator device further displays the hashtag trending information (<NUM>).

Continuing with <FIG>, the note input user interface monitors the input of unstructured note by the remote operator (<NUM>). The note input user interface determines whether a predetermined special symbol is input by the remote operator (<NUM>). If no special symbol is detected, the note input user interface repeats <NUM> and continues to monitor the note input. If a special symbol is detected, inquiry may be further made to the CRC <NUM> for obtaining a suggested list of data items (<NUM>). The CRC <NUM> may search for data items according to the detected special symbols (<NUM>). For example, the CRC <NUM> may search for data items (such as specific hashtags) in the hashtag repository if the detected special symbol is "#". For another example, the CRC <NUM> may search for data items (such as operator names and email addresses) in an operator database if the detected special symbol is "@". The CRC <NUM> further returns the searched data items as suggestions to the note input user interface at the remote operator device (<NUM>). The note input user interface of the remote operator device receives the suggested data items from the CSC <NUM> and displays the suggested data items to the remote operator in the note input user interface as selectable list of menu items (<NUM>). The note input user interface in the remote operator device includes suggested data items that are selected by the remote operator from the list of menu items into the unstructured note being entered following the detected special symbol (<NUM>).

Continuing with <FIG>, the note input user interface detects whether a "Save" button included in the note input user interface is selected by the operator (<NUM>). If the "Save" button is not selected, the note input user interface returns to <NUM> and continues monitoring the note input. If the "Save" button is selected, the remote operator device may communicate the entered unstructured note to the CSC <NUM>. Optionally, the remote operator device <NUM> may save the unstructured note locally.

The CSC <NUM> or the tagging data controller <NUM> receives the unstructured note (<NUM>). The tagging data controller <NUM> then processes the unstructured note and updates the soft tag repository <NUM> (<NUM>). The tagging data controller <NUM> extracts hashtags from the unstructured note and updates the hashtag repository (<NUM>). The unstructured note may be further processed to create other service items. The unstructured note may be processed by the tagging data controller along or together with the policy repository to extract predetermined action triggers and instruction for performing predefined actions associated with the triggers (<NUM>). The predefined actions may include, for example, automatic decommission of the technical component after a specified period of time, automatic placement of the technical component on a watch list for later viewing by another remote operator, or automatic placement of the technical component in a resource group with restricted access. These actions for controlling, provisioning of technical components and automatic communication between operators are then triggered by CSC <NUM> or the data tagging controller <NUM> (<NUM>). Alternatively, action triggers may be derived from the unstructured note and the corresponding actions may be triggered by the remote operator device (rather than the CSC <NUM> or the data tagging controller <NUM>) at <NUM>. For the extraction of action triggers and execution of controlling, provisioning and communication actions, the remote operator device may need to communicate with API components of the CSC <NUM> and data tagging controller <NUM> (<NUM>).

The methods, devices, processing, circuitry, and logic described above may be implemented in many different ways and in many different combinations of hardware and software. For example, all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor; or as an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or as circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples.

Accordingly, the circuitry may store or access instructions for execution, or may implement its functionality in hardware alone. The instructions may be stored in a tangible storage medium that is other than a transitory signal, such as a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such as a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and the instructions when executed by the circuitry in a device may cause the device to implement any of the processing described above or illustrated in the drawings.

The implementations may be distributed. For instance, the circuitry may include multiple distinct system components, such as multiple processors and memories, and may span multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and controlled, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways. Example implementations include linked lists, program variables, hash tables, arrays, records (e.g., database records), objects, and implicit storage mechanisms. Instructions may form parts (e.g., subroutines or other code sections) of a single program, may form multiple separate programs, may be distributed across multiple memories and processors, and may be implemented in many different ways. Example implementations include stand-alone programs, and as part of a library, such as a shared library like a Dynamic Link Library (DLL). The library, for example, may contain shared data and one or more shared programs that include instructions that perform any of the processing described above or illustrated in the drawings, when executed by the circuitry.

Claim 1:
A system comprising:
a tag repository configured to store a metadata tag for a virtual machine instantiated by a cloud computing service provider for an organizational unit; and
a central resource controller for provisioning the virtual machine, the central resource controller comprising:
communication circuitry operable to establish a data connection with the cloud computing service provider and the tag repository; and
control circuitry configured to:
provide, via the communication circuitry, a user interface to a remote operator authorized by the organizational unit, the user interface for entering the metadata tag for the virtual machine by the remote operator, for detecting an input of a predefined symbol by the user interface, and for generating at the user interface upon detecting the predefined symbol a menu containing data items as options selectable by the remote operator to include in the metadata tag being entered;
provide the selectable data items to the menu at the user interface in response to the predefined symbol being detected by the user interface;
accept the entered metadata tag for the virtual machine from the user interface;
send the metadata tag to the tag repository for storage;
generate an action trigger upon determining that a condition for a pre-configured action is met for the virtual machine responsive to content in the entered metadata tag, wherein the pre-configured action comprises a provisioning action for the virtual machine; and
automatically perform the pre-configured action for the virtual machine responsive to the action trigger.