U.S. patent application number 15/344385 was filed with the patent office on 2017-02-23 for managing technology resources across multiple platforms.
The applicant listed for this patent is Microsoft Technology Licensing, LLC. Invention is credited to Todd J. Abel, Steven P. Burns, Amit Flashner, Vadim Meleshuk, Dov Sheinker, Weiqing Tu.
Application Number | 20170054599 15/344385 |
Document ID | / |
Family ID | 50975992 |
Filed Date | 2017-02-23 |
United States Patent
Application |
20170054599 |
Kind Code |
A1 |
Burns; Steven P. ; et
al. |
February 23, 2017 |
MANAGING TECHNOLOGY RESOURCES ACROSS MULTIPLE PLATFORMS
Abstract
The present invention extends to methods, systems, and computer
program products for managing technology resources across multiple
platforms. Embodiments of the invention can be used to manage the
configuration of a plurality of different devices. A management
server/service can utilize native management capabilities of
different devices to provide configuration management without
requiring agents to be installed on the devices. In general, the
management server/service adapts to the unique characteristics and
behaviors of different devices, platforms, and external systems to
provide configuration management for the different devices,
platforms, and external systems. As such, configuration management
can be provided in a unified fashion across different platforms,
both on-premise and off-premise, and indirectly. When client agents
are present, the management server/service can adjust to compatibly
operate with the client agents.
Inventors: |
Burns; Steven P.; (Redmond,
WA) ; Abel; Todd J.; (Redmond, WA) ; Meleshuk;
Vadim; (Seattle, WA) ; Tu; Weiqing; (Redmond,
WA) ; Sheinker; Dov; (Ra'anana, IL) ;
Flashner; Amit; (Ness-Zionna, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Technology Licensing, LLC |
Redmond |
WA |
US |
|
|
Family ID: |
50975992 |
Appl. No.: |
15/344385 |
Filed: |
November 4, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14866832 |
Sep 25, 2015 |
9509564 |
|
|
15344385 |
|
|
|
|
13721042 |
Dec 20, 2012 |
9172773 |
|
|
14866832 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 41/0813 20130101;
H04L 41/0803 20130101; H04L 67/28 20130101; H04L 67/2823 20130101;
H04L 69/08 20130101; G06F 9/541 20130101; H04L 67/34 20130101; H04L
41/08 20130101 |
International
Class: |
H04L 12/24 20060101
H04L012/24; H04L 29/06 20060101 H04L029/06; H04L 29/08 20060101
H04L029/08 |
Claims
1. A computer system, the computer system comprising: one or more
hardware processors; system memory coupled to the one or more
hardware processors, the system memory storing instructions that
are executable by the one or more hardware processors; the one or
more hardware processors executing the instructions stored in the
system memory to manage a device, including the following: receive
a device-neutral configuration directive, the device-neutral
configuration directive having been modified based on operational
data from one or more other devices, the operational data including
information relevant to the success or failure of applying the
device-neutral configuration directive at the one or more other
devices; translate the device-neutral directive into a
device-specific configuration directive for the device; and send
the device-specific configuration directive to implement a
configuration change for the device.
2. The computer system of claim 1, wherein the one or more hardware
processors executing the instructions stored in the system memory
to receive a device-neutral configuration comprise the one or more
hardware processors executing the instructions stored in the system
memory to receive the device-neutral configuration, wherein one or
more directive processors have modified the device-neutral
configuration by one or more of: tabulating results, analyzing the
device-neutral configuration directive, predicting the impact of
implementing the device-neutral configuration directive, and
determining an historical trend with respect to the device-neutral
configuration directive.
3. The computer system of claim 1, wherein the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a
device-specific configuration comprises the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a form
suitable for execution by a legacy device agent.
4. The computer system of claim 1, wherein the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a
device-specific configuration comprises the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a form
suitable for execution by a 3.sup.rd party intermediary, the
3.sup.rd party intermediary in communication with a 3.sup.rd party
device agent.
5. The computer system of claim 1, wherein the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a
device-specific configuration comprises the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a form
suitable for execution by an off-premises external system.
6. The computer system of claim 1, wherein the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a
device-specific configuration comprises the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a form
suitable for execution by an on-premises adaptor, the on-premises
adaptor in communication with an on-premises external system.
7. The computer system of claim 1, wherein the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a
device-specific configuration comprises the one or more hardware
processors executing the instructions stored in the system memory
to translate the device-neutral configuration directive into a form
suitable for execution by a native device agent.
8. A computer system, the computer system comprising: one or more
hardware processors; system memory coupled to the one or more
hardware processors, the system memory storing instructions that
are executable by the one or more hardware processors; the one or
more hardware processors executing the instructions stored in the
system memory to manage a device, including the following: collect
operational data in a device-specific format from the device in
response to the device attempting to apply a configuration
directive to change configuration, the device-specific operational
data including information relevant to the success or failure of
applying the configuration directive at the device; translate the
operational data in the device-specific format into operational
data in a device-neutral format; and send the operational data in
the device-neutral format for storage, the operational data
providing feedback for use in modifying the device-neutral
configuration directive for implementation at one or more other
devices.
8. The computer system of claim 7, wherein the one or more hardware
processors executing the instructions stored in the system memory
to collect operational data in a device-specific format from the
device comprises the one or more hardware processors executing the
instructions stored in the system memory to collect operational
data in the device-specific format including details related to the
success or failure of the device attempting to apply a
device-specific configuration directive at the device.
9. The computer system of claim 7, wherein the one or more hardware
processors executing the instructions stored in the system memory
to translate the operational data in the device-specific format
into operational data in a device-neutral format comprises the one
or more hardware processors executing the instructions stored in
the system memory to translate the operational data from a device
client agent into the device-neutral data format.
10. The computer system of claim 7, wherein the one or more
hardware processors executing the instructions stored in the system
memory to translate the operational data in the device-specific
format into operational data in a device-neutral format comprises
the one or more hardware processors executing the instructions
stored in the system memory to translate the operational data from
an external system into the device-neutral data format.
11. The computer system of claim 7, wherein the one or more
hardware processors executing the instructions stored in the system
memory to translate the operational data in the device-specific
format into operational data in a device-neutral format comprises
the one or more hardware processors executing the instructions
stored in the system memory to translate the operational data in
accordance with a device-neutral data schema.
12. The computer system of claim 7, wherein the one or more
hardware processors executing the instructions stored in the system
memory to send the operational data in the device-neutral format
comprises the one or more hardware processors executing the
instructions stored in the system memory to send operational data
providing feedback for use in modifying one or more device-neutral
configuration directives.
13. The computer system of claim 7, wherein the one or more
hardware processors executing the instructions stored in the system
memory to send operational data in the device-neutral format
comprises the one or more hardware processors executing the
instructions stored in the system memory to send operational data
in the device-neutral format to provide feedback for use in
modifying one or more device-neutral configuration directives by
one or more of: tabulating results, analyzing the device-neutral
configuration directive, predicting the impact of implementing the
device-neutral configuration directive, and determining an
historical trend with respect to the device-neutral configuration
directive.
14. A processor implemented method for use a computer system, the
processor implementing method for managing a device, the processor
implemented method comprising: a gateway adaptor collecting
operational data in a device-specific format from the device in
response to the device attempting to apply a configuration
directive to change configuration, the device-specific operational
data including information relevant to the success or failure of
applying the configuration directive at the device; the gateway
adaptor translating the operational data in the device-specific
format into operational data in a device-neutral format; and the
gateway adaptor sending the operational data in the device-neutral
format for storage, the operational data providing feedback for use
in modifying the device-neutral configuration directive for
implementation at one or more other devices.
15. The method of claim 14, wherein a gateway adaptor collecting
operational data in a device-specific format comprises the gateway
adaptor collect operational data in the device-specific format
including details related to the success or failure of the device
attempting to apply a device-specific configuration directive at
the device
16. The method of claim 14, wherein the gateway adaptor translating
the operational data in the device-specific format into operational
data in a device-neutral format comprises the gateway adaptor
translating operational data from an external system into the
device-neutral data format.
17. The method of claim 14, wherein the gateway adaptor translating
the operational data in the device-specific format into operational
data in a device-neutral format comprises the gateway adaptor
translating the operational data in accordance with a
device-neutral data schema.
18. The method of claim 14, wherein the gateway adaptor translating
the operational data in the device-specific format into operational
data in a device-neutral format comprises the gateway adaptor
translating the operational data from a device client agent into
the device-neutral data format.
19. The method of claim 14, wherein the gateway adaptor sending the
operational data in the device-neutral format comprises the gateway
adaptor sending the operational data in the device-neutral format
for use by one or more of: a policy computation directive
processor, a remote task directive processor, and a software
distribution directive processor.
20. The method of claim 14, wherein the gateway adaptor sending the
operational data in the device-neutral format for storage comprises
the gateway adaptor sending the send operational data in the
device-neutral format to provide feedback for use in modifying one
or more device-neutral configuration directives by one or more of:
tabulating results, analyzing the device-neutral configuration
directive, predicting the impact of implementing the device-neutral
configuration directive, and determining an historical trend with
respect to the device-neutral configuration directive.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of and claims the benefit
of and priority to U.S. patent application Ser. No. 14/866,832
entitled "Managing Technology Resources Across Multiple Platforms",
filed Sep. 25, 2015 by Steven P. Burns et al., the entire contents
of which are expressly incorporated by reference. That application
is a continuation of and claims the benefit of and priority to U.S.
patent application Ser. No. 13/721,042, now U.S. Pat. No.
9,172,773, entitled "Managing Technology Resources Across Multiple
Platforms", filed Dec. 20, 2012 by Steven P. Burns et al., the
entire contents of which are expressly incorporated by
reference.
BACKGROUND
Background and Relevant Art
[0002] Computer systems and related technology affect many aspects
of society. Indeed, the computer system's ability to process
information has transformed the way we live and work. Computer
systems now commonly perform a host of tasks (e.g., word
processing, scheduling, accounting, etc.) that prior to the advent
of the computer system were performed manually. More recently,
computer systems have been coupled to one another and to other
electronic devices to form both wired and wireless computer
networks over which the computer systems and other electronic
devices can transfer electronic data. Accordingly, the performance
of many computing tasks is distributed across a number of different
computer systems and/or a number of different computing
environments.
[0003] In enterprise network environments, an information
technology (IT) management group typically manages the
configuration of computing devices for an entity (e.g., a
corporation). Larger networks can include 100s or even 1000's
computing devices, including personal computers, phones, tablets,
etc. Different computing devices can have different and unique
technologies and implementation details, such as, different
hardware and software. As a result, the required configuration
management for the different computing devices can also vary.
[0004] Some computing devices may be more easily managed than other
computing devices. For example, a widely adopted design for
personal computer configuration management system is a
client-server design. That is, a server (or service) is contacted
by an accompanying client, which is typically a software process
(an `agent`) running on the computer being managed. The client
periodically contacts the server to receive configuration
directives and to submit data regarding the management of the
computer running the agent. The server and the client to be
developed in tandem to increase interoperability.
[0005] On the other hand, when managing a mobile device (e.g., a
slate/tablet/phone or similar), the client-server design often does
not work. For example, on many mobile devices the device operating
platform does not allow for an agent to be installed on the device.
Alternatively, a device manufacturer, distributor, supplier,
carrier, or licensing entity may not allow under the terms of the
use of the device, the installation of an agent on the device (even
if the operating platform does allow installation of an agent). For
either of these configurations, it is typically for a device
platform to already include some form of remote device management.
That is, the device may already have some sort of management agent
supplied by the device manufacturer. Additionally, the development
of an agent for the device platform may be redundant with
functionality already present on the device. Thus, even if the
device lends itself to the installation of a management agent, it
may not be attractive to develop one since doing so would provide
little value over functionality already present.
[0006] Further, some configuration management directives are not
realized on a device at all. Rather, such directives are to manage
the configuration of other software systems on behalf of a user or
device that utilizes those systems. For example, an IT admin may
desire to manage a user's email in-box. However, the in-box is an
artifact of the email system--separate from an IT configuration
management system. That is, devices access the email system to
retrieve the email for a given user. These devices, in the context
of email retrieval, respond to the configuration of the email
system. Nonetheless, the IT admin would like to specify management
directives for the device's behavior that is governed by the email
system. However, the email system is merely an intermediary for the
indirect management of services.
[0007] Moreover, it is often the case that enterprises have
existing and several systems in place that are installed "on
premises," meaning, that the enterprise owns and operates the
equipment on which those systems run. Likewise, it is increasingly
the case that enterprises utilize services provided over
communications networks such as the Internet. These Internet
services owned and operated by a third party. However, it can be
difficult to manage these external systems using a client-server
design.
[0008] It can also be difficult to manage a computing device when
the client or server component in a client-server design changes.
For example, it may be that a managed device has a native device
client agent designed to work with a given IT management system. If
the IT management system changes (e.g., due to an upgrade), the
device client agent may become incompatible and require changes. In
some environments, it may not even be possible to change the device
client agent. For example, the device client agent may be embedded
in hardware (e.g., an embedded system) and cannot be revised.
BRIEF SUMMARY
[0009] The present invention extends to methods, systems, and
computer program products for managing technology resources across
multiple platforms. In some embodiments, a directive dispatcher
issues an abstract-device neutral directive to a specified (and
possible one of many different) device(s). The abstract
device-neutral directive directs the specified target device to
implement a configuration change. A platform-specific gateway
(possibly one of a plurality of different platform-specific
gateways) for the specified target device receives the abstract
device-neutral directive from a distribution component. The
platform-specific gateway translates the abstract device-neutral
directive into a form suitable for execution at the specified
target device to implement the configuration change. The
platform-specific gateway sends the form suitable for execution at
the specified target device to the specified target device so as to
realize the configuration change at the specified target
device.
[0010] In other embodiments, a platform-specific gateway collects
operational data from a specified target device. The operational
data is in a device-specific data format and relates to a
previously issued directive from a directive dispatcher. The
platform-specific gateway translates the operational data from the
device-specific data format into the device-neutral data format in
accordance with a device-neutral data schema. The platform-specific
gateway submits the operational data in the device-neutral data
format to a data collection service for storage in a data
persistence store. The operational data is available for subsequent
use by business logic when processing issued directives from the
directive dispatcher.
[0011] This summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used as an aid in determining the scope of
the claimed subject matter.
[0012] Additional features and advantages of the invention will be
set forth in the description which follows, and in part will be
obvious from the description, or may be learned by the practice of
the invention. The features and advantages of the invention may be
realized and obtained by means of the instruments and combinations
particularly pointed out in the appended claims. These and other
features of the present invention will become more fully apparent
from the following description and appended claims, or may be
learned by the practice of the invention as set forth
hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] In order to describe the manner in which the above-recited
and other advantages and features of the invention can be obtained,
a more particular description of the invention briefly described
above will be rendered by reference to specific embodiments thereof
which are illustrated in the appended drawings. Understanding that
these drawings depict only typical embodiments of the invention and
are not therefore to be considered to be limiting of its scope, the
invention will be described and explained with additional
specificity and detail through the use of the accompanying drawings
in which:
[0014] FIG. 1 illustrates an example computer architecture that
facilitates translating a device-neutral directive.
[0015] FIG. 2 illustrates a flow chart of an example method for
translating a device-neutral directive.
[0016] FIG. 3 illustrates an example computer architecture that
facilitates translating a device-specific operational data.
[0017] FIG. 4 illustrates a flow chart of an example method for
translating device-specific operational data.
[0018] FIG. 5 illustrates an example computer architecture that
facilitates managing technology resources across multiple
platforms.
DETAILED DESCRIPTION
[0019] The present invention extends to methods, systems, and
computer program products for managing technology resources across
multiple platforms. In some embodiments, a directive dispatcher
issues an abstract-device neutral directive to a specified (and
possible one of many different) device(s). The abstract
device-neutral directive directs the specified target device to
implement a configuration change. A platform-specific gateway
(possibly one of a plurality of different platform-specific
gateways) for the specified target device receives the abstract
device-neutral directive from a distribution component. The
platform-specific gateway translates the abstract device-neutral
directive into a form suitable for execution at the specified
target device to implement the configuration change. The
platform-specific gateway sends the form suitable for execution at
the specified target device to the specified target device so as to
realize the configuration change at the specified target
device.
[0020] In other embodiments, a platform-specific gateway collects
operational data from a specified target device. The operational
data is in a device-specific data format and relates to a
previously issued directive from a directive dispatcher. The
platform-specific gateway translates the operational data from the
device-specific data format into the device-neutral data format in
accordance with a device-neutral data schema. The platform-specific
gateway submits the operational data in the device-neutral data
format to a data collection service for storage in a data
persistence store. The operational data is available for subsequent
use by business logic when processing issued directives from the
directive dispatcher.
[0021] Embodiments of the present invention may comprise or utilize
a special purpose or general-purpose computer including computer
hardware, such as, for example, one or more processors and system
memory, as discussed in greater detail below. Embodiments within
the scope of the present invention also include physical and other
computer-readable media for carrying or storing computer-executable
instructions and/or data structures. Such computer-readable media
can be any available media that can be accessed by a general
purpose or special purpose computer system. Computer-readable media
that store computer-executable instructions are computer storage
media (devices). Computer-readable media that carry
computer-executable instructions are transmission media. Thus, by
way of example, and not limitation, embodiments of the invention
can comprise at least two distinctly different kinds of
computer-readable media: computer storage media (devices) and
transmission media.
[0022] Computer storage media (devices) includes RAM, ROM, EEPROM,
CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash
memory, phase-change memory ("PCM"), other types of memory, other
optical disk storage, magnetic disk storage or other magnetic
storage devices, or any other medium which can be used to store
desired program code means in the form of computer-executable
instructions or data structures and which can be accessed by a
general purpose or special purpose computer.
[0023] A "network" is defined as one or more data links that enable
the transport of electronic data between computer systems and/or
modules and/or other electronic devices. When information is
transferred or provided over a network or another communications
connection (either hardwired, wireless, or a combination of
hardwired or wireless) to a computer, the computer properly views
the connection as a transmission medium. Transmissions media can
include a network and/or data links which can be used to carry
desired program code means in the form of computer-executable
instructions or data structures and which can be accessed by a
general purpose or special purpose computer. Combinations of the
above should also be included within the scope of computer-readable
media.
[0024] Further, upon reaching various computer system components,
program code means in the form of computer-executable instructions
or data structures can be transferred automatically from
transmission media to computer storage media (devices) (or vice
versa). For example, computer-executable instructions or data
structures received over a network or data link can be buffered in
RAM within a network interface module (e.g., a "NIC"), and then
eventually transferred to computer system RAM and/or to less
volatile computer storage media (devices) at a computer system.
Thus, it should be understood that computer storage media (devices)
can be included in computer system components that also (or even
primarily) utilize transmission media.
[0025] Computer-executable instructions comprise, for example,
instructions and data which, when executed at a processor, cause a
general purpose computer, special purpose computer, or special
purpose processing device to perform a certain function or group of
functions. The computer executable instructions may be, for
example, binaries, intermediate format instructions such as
assembly language, or even source code. Although the subject matter
has been described in language specific to structural features
and/or methodological acts, it is to be understood that the subject
matter defined in the appended claims is not necessarily limited to
the described features or acts described above. Rather, the
described features and acts are disclosed as example forms of
implementing the claims.
[0026] Those skilled in the art will appreciate that the invention
may be practiced in network computing environments with many types
of computer system configurations, including, personal computers,
desktop computers, laptop computers, message processors, hand-held
devices, multi-processor systems, microprocessor-based or
programmable consumer electronics, network PCs, minicomputers,
mainframe computers, mobile telephones, PDAs, tablets, pagers,
routers, switches, and the like. The invention may also be
practiced in distributed system environments where local and remote
computer systems, which are linked (either by hardwired data links,
wireless data links, or by a combination of hardwired and wireless
data links) through a network, both perform tasks. In a distributed
system environment, program modules may be located in both local
and remote memory storage devices.
[0027] Embodiments of the invention can also be implemented in
cloud computing environments. In this description and the following
claims, "cloud computing" is defined as a model for enabling
on-demand network access to a shared pool of configurable computing
resources. For example, cloud computing can be employed in the
marketplace to offer ubiquitous and convenient on-demand access to
the shared pool of configurable computing resources. The shared
pool of configurable computing resources can be rapidly provisioned
via virtualization and released with low management effort or
service provider interaction, and then scaled accordingly.
[0028] A cloud computing model can be composed of various
characteristics such as, for example, on-demand self-service, broad
network access, resource pooling, rapid elasticity, measured
service, and so forth. A cloud computing model can also expose
various service models, such as, for example, Software as a Service
("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a
Service ("IaaS"). A cloud computing model can also be deployed
using different deployment models such as private cloud, community
cloud, public cloud, hybrid cloud, and so forth. In this
description and in the claims, a "cloud computing environment" is
an environment in which cloud computing is employed.
[0029] Embodiments of the invention can be used to manage the
configuration of a plurality of different devices. A management
server/service can utilize native management capabilities of
different devices to provide configuration management without
requiring agents to be installed on the devices. In general, the
management server/service adapts to the unique characteristics and
behaviors of different devices, platforms, and external systems to
provide configuration management for the different devices,
platforms, and external systems. As such, configuration management
can be provided in a unified fashion across different platforms,
both on-premise and off-premise, and indirectly. When client agents
are present, the management server/service can adjust to compatibly
operate with the client agents.
[0030] A data model design models managed devices in a
device-neutral manner Service/server-side logic processes
management directives in a device-neutral format. Gateway adaptors
reconcile platform-specifics to management service generalisms. For
example, gateway adaptors can translate device-neutral directives
into device-specific directives. Gateway adaptors can also
translate collected operational data from device-specific format
into a device-neutral format for use by the service/server-side
logic. Gateway adaptors can also adapt to various protocols used to
communicate with devices. As such, gateway adaptors can facilitate
communication between endpoints that use different communication
protocols.
[0031] FIG. 1 illustrates an example computer architecture 100 that
facilitates translating a device-neutral directive. Referring to
FIG. 1, computer architecture 100 includes directive dispatcher
101, directive processing modules 102, distribution component 103,
platform-specific gateway 104, and target device 107. Each of
directive dispatcher 101, directive processing modules 102,
distribution component 103, platform-specific gateway 104, and
target device 107 can be connected to one another over (or be part
of) a network, such as, for example, a Local Area Network ("LAN"),
a Wide Area Network ("WAN"), and even the Internet. Accordingly,
directive dispatcher 101, directive processing modules 102,
distribution component 103, platform-specific gateway 104, and
target device 107 as well as any other connected computer systems
and their components, can create message related data and exchange
message related data (e.g., Internet Protocol ("IP") datagrams and
other higher layer protocols that utilize IP datagrams, such as,
Transmission Control Protocol ("TCP"), Hypertext Transfer Protocol
("HTTP"), Simple Mail Transfer Protocol ("SMTP"), etc. or using
other non-datagram protocols) over the network.
[0032] In general, directive dispatcher 101 is configured to issue
device-neutral directives targeted to one or more specified target
devices. The device-neutral directives can direct one or more
specified target devices to implement a configuration change. When
appropriate, directive processing modules 102 can process issued
device-neutral directives to modify the device-neutral directives.
Directive processing modules 102 can apply business logic to make
changes for specified target device or to comply with policy
settings. In some embodiments, directive processing modules 102
includes a plurality of modules that interact with one another to
provide various features offered to a user (e.g., an IT admin).
[0033] Distribution component 103 is configured to distribute a
device-neutral directive to one or more specified targeted devices.
Distribution component 103 can receive a device-neutral directive.
From the devices distribution component 103 is aware of,
distribution component 103 can determine which devices are
specified targeted devices of the device-neutral directive.
Distribution component 103 can forward to the device-neutral
directive on to the specified targeted gateways.
[0034] Platform-specific gateway 104 is configured to interface
between more abstract device-neutral directives issued by directive
dispatcher 101 and more concrete device-specific directives for
target device 107 (and other similar devices). More specifically,
translation module 106 can translate a device-neutral directive
into a form suitable for execution at target device 107 (and other
similar devices). In some embodiments, platform-specific gateway
104 is one of a plurality of different platform-specific gateways.
Each of the plurality of different platform-specific gateways can
be configured to interface between more abstract device-neutral
directives issued by directive dispatcher 101 and more concrete
device-specific directives for corresponding target devices. Each
of the plurality of different platform-specific gateways can be
configured for use with differently configured devices including
any of the previously described devices. For example,
platform-specific gateway 104 can be configured for use with mobile
phones, another platform-specific gateway can be configured for use
with personal computers, another platform-specific gateway can be
configured for use with network equipment, etc.
[0035] Target device 107 can be one of a variety of different
devices, such as, for example, a personal computer, a mobile phone,
a tablet, network equipment, etc. or other previously described
devices.
[0036] FIG. 2 illustrates a flow chart of an example method 200 for
translating a device-neutral directive. Method 200 will be
described with respect to the components and data of computer
architecture 100.
[0037] Remaining briefly at FIG. 1, directive dispatcher 101 can
dispatch device-neutral directive 111 to target device 107 (as well
as one or more other devices). Device-neutral directive 111 can
direct target device 107 (as well as the one or more other devices)
to implement a configuration change. When appropriate, directive
processing modules 102 can apply business logic to device-neutral
directive 111. Device-neutral directive 111 is then passed on to
distribution component 103 for distribution. Distribution component
103 can determine that device-neutral component has been issued to
target device 107. In response, distribution component 103 can
forward device-neutral directive 111 to platform-specific gateway
104.
[0038] In general, directives can include setting device
configuration, collecting device hardware and software inventory,
distribution of updates, patches, and applications to a device,
issuing "wipe/rest" commands, etc. Device-neutral directive 111 can
include any of these (as well as other) directives.
[0039] Method 200 includes an act of a platform-specific gateway
receiving an abstract device-neutral directive from a distribution
component, the abstract device-neutral directive issued by a
directive dispatcher, the abstract device-neutral directive
directing a specified target device to implement a configuration
change (201). For example, platform-specific gateway 104 can
receive device-neutral directive 111 from distribution component
103. As described, device-neutral directive 111 was dispatched from
directive dispatcher 101 and directs target device 107 to implement
a configuration change.
[0040] Method 200 includes the platform-specific gateway
translating the abstract device-neutral directive into a form
suitable for execution at the specified target device to implement
the configuration change (202). For example, translation module 106
can translate device-neutral directive 111 into device-specific
directive 112. Device-specific directive 112 can be a form suitable
for execution at target device 107 to implement the directed
configuration change.
[0041] Method 200 includes the platform-specific gateway sending
the form suitable for execution at the specified target device to
the specified target device so as to realize the configuration
change at the specified target device (203). For example,
platform-specific gateway 104 can send device-specific directive
112 to target device 107.
[0042] Target device 107 can execute device-specific directive 112
to implement the directed configuration change.
[0043] FIG. 3 illustrates an example computer architecture 300 that
facilitates translating a device-specific operational data.
Referring to FIG. 3, computer architecture 300 includes directive
dispatcher 301, directive processing modules 302, distribution
component 303, platform-specific gateway 304, target device 307,
data collector 308, and data persistence store 309. Each of
directive dispatcher 301, directive processing modules 302,
distribution component 303, platform-specific gateway 304, target
device 307, data collector 308, and data persistence store 309 can
be connected to one another over (or be part of) a network, such
as, for example, a Local Area Network ("LAN"), a Wide Area Network
("WAN"), and even the Internet. Accordingly, directive dispatcher
301, directive processing modules 302, distribution component 303,
platform-specific gateway 304, target device 307, data collector
308, and data persistence store 309 as well as any other connected
computer systems and their components, can create message related
data and exchange message related data (e.g., Internet Protocol
("IP") datagrams and other higher layer protocols that utilize IP
datagrams, such as, Transmission Control Protocol ("TCP"),
Hypertext Transfer Protocol ("HTTP"), Simple Mail Transfer Protocol
("SMTP"), etc.) over the network.
[0044] Directive dispatcher 301 can be configured similar to
directive dispatcher 101. Directive dispatcher 301 can issue
device-neutral directives targeted to one or more specified target
devices. The device-neutral directives can direct one or more
specified target devices to implement a configuration change. When
appropriate, directive processing modules 302 can process issued
device-neutral directives to modify the device-neutral directives.
Directive processing modules 302 can apply business logic, in
combination with operational data stored in data persistence sore
309, to make changes for specified target device or to comply with
policy settings. In some embodiments, directive processing modules
302 includes a plurality of modules that can access data from data
persistence store 309 and interact with one another to provide
various features offered to a user (e.g., an IT admin).
[0045] Distribution component 303 is configured similar to
distribution component 103. Distribution component 303 can
distribute a device-neutral directive to one or more specified
targeted devices. Distribution component 303 can receive a
device-neutral directive. From the devices distribution component
303 is aware of, distribution component 303 can determine which
devices are specified targeted devices of the device-neutral
directive. Distribution component 303 can forward to the
device-neutral directive on to the specified targeted devices.
[0046] Platform-specific gateway 304 is configured to interface
between more abstract device-neutral directives issued by directive
dispatcher 111 and more concrete device-specific directives for
target device 307 (and other similar devices). More specifically,
translation module 306 can translate a device-neutral directive
into a form suitable for execution at target device 307 (and other
similar devices). In some embodiments, platform-specific gateway
304 is one of a plurality of different platform-specific
gateways.
[0047] Each of the plurality of different platform-specific
gateways can be configured to interface between more abstract
device-neutral directives issued by directive dispatcher 301 and
more concrete device-specific directives for corresponding target
devices. Each of the plurality of different platform-specific
gateways can also be configured to translate device-specific
operational data into device neutral operational data. Each of the
plurality of different platform-specific gateways can be configured
for use with differently configured devices including any of the
previously described devices. For example, platform-specific
gateway 104 can be configured for use with mobile phones, another
platform-specific gateway can be configured for use with personal
computers, another platform-specific gateway can be configured for
use with network equipment, etc.
[0048] Platform-specific gateway 304 is further configured to
collect operational data from target device 307 (and other similar
devices). Collected operational data can be in a device-specific
data format and can be related to a previously issued directive
from directive dispatcher 301.
[0049] Platform-specific gateway 304 can interface between the
device-specific data format and a device-neutral data format. More
specifically, translation module 306 can translate operational data
in the device-specific data format into operational data in the
device-neutral format. The device-neutral format can be defined in
schema 321. Thus, platform-specific gateway 304 (as well as any
other platform-specific gateways) can translate operation data in a
device-specific data format into operational data in the
device-neutral format in accordance with schema 321.
[0050] Data collector 308 is configured to collect operational data
in the device-neutral format from platform-specific gateway 304 (as
well as any other platform-specific gateways). Data collector 308
can store operation in the device-neutral format in data
persistence store 309. Operation data stored in data persistence
store 309 can be accessed by directive processing modules 302.
Directive processing modules 302 can apply business logic based on
stored operational data to access previously issued directives.
Thus, output from prior directives can be used as feedback when
processing new directives.
[0051] Target device 307 can be one of a variety of different
devices, such as, for example, a personal computer, a mobile phone,
a tablet, network equipment, etc. or other previously described
devices.
[0052] FIG. 4 illustrates a flow chart of an example method 400 for
translating device-specific operational data. Method 400 will be
described with respect to the components and data of computer
architecture 300.
[0053] Remaining briefly at FIG. 3, directive dispatcher 301 can
dispatch device-neutral directive 317 to target device 307 (as well
as one or more other devices). Device-neutral directive 317 can
direct target device 307 (as well as the one or more other devices)
to implement a configuration change. When appropriate, directive
processing modules 302 can apply business logic to device-neutral
directive 317. Device-neutral directive 317 is then passed on to
distribution component 103 for distribution. Distribution component
303 can determine that device-neutral component has been issued to
target device 307. In response, distribution component 303 can
forward device-neutral directive 317 to platform-specific gateway
304.
[0054] Platform-specific gateway 304 can receive device-neutral
directive 317 from distribution component 303. Translation module
306 can translate device-neutral directive 317 into device-specific
directive 318. Device-specific directive 318 can be a form suitable
for execution at target device 307 to implement the directed
configuration change. Platform-specific gateway 304 can send
device-specific directive 318 to target device 307.
[0055] Target device 307 can execute device-specific directive 318
to implement the directed configuration change. As part of
execution, target device 307 can emit device-specific operational
data 312 related to the directed configuration change.
[0056] In general, operational data can include
success/failure/details information relevant to the application of
management directives supplied from a gateway. Thus,
device-specific operational data 312 can include
success/failure/details information relevant to the application of
device-specific directive 318.
[0057] Method 400 includes a platform specific gateway collecting
operational data from a specified target device, the operational
data in the device-specific data format, the operational data
related to a previously issued directive from a directive
dispatcher (401). For example, platform-specific gateway 304 can
collect device-specific operational data 312. Device-specific
operational data 312 can be in a format specific to target device
307 (and other similar devices). Device-specific operational data
312 can be related to device-neutral directive 317.
[0058] Method 400 includes the platform specific gateway
translating the operational data from the device-specific data
format into the device-neutral data format, the device-neutral data
format defined in a device-neutral data schema (402). For example,
translation module 306 can translate device-specific operational
data 312 into device-neutral operational data 311. Device-neutral
operational data 311 can be defined in a device-neutral format
defined in schema 321.
[0059] Method 400 includes the platform-specific gateway submitting
the operational data in the device-neutral data format to a data
collection service for storage in a data persistence store, the
operational data for subsequent use by business logic when
processing issued directives from the directive dispatcher (403).
For example, platform-specific gateway 304 can submit
device-neutral operational data 311 to data collector 308 for
storage in data persistence store 309.
[0060] Data collector 308 can receive device-neutral operational
data 311 from platform-specific gateway 304. Data collector 308 can
store device-neutral operational data 311 in data persistence store
309. Device-neutral operational data 311 can then be accessed by
directive processing modules 302 when processing directives from
directive dispatcher 301.
[0061] FIG. 5 illustrates an example computer architecture 500 that
facilitates managing technology resources across multiple
platforms.
[0062] Referring to FIG. 5, an admin user of computer architecture
500 can utilize administrator console software program 541.
Software program 541 can be a Web browser application, software
installed on a computer system, or an application ("app") installed
on a tablet or smart phone. The admin user can supply "directives"
to via admin console 541. "Directives" can be commands, scripts,
software packages, configuration manifests, configuration policies,
software licensing keys, workflows, user and hardware catalogs, and
other such inputs that the admin desires to implement over a
population of devices and external systems.
[0063] Application Programming Interface ("API") 501 can accept the
directives from admin console 541. API 501 can be a
standards-compliant Internet protocol following Simple Object
Access Protocol ("SOAP") or Representational State Transfer
("REST") patterns. Alternatively, API 501 can be a body of industry
standard or proprietary Remote Procedure Call ("RPC")
technologies.
[0064] API 501 can use directive dispatcher 502 to dispatch
device-neutral directives to one or more directive processors 503.
Directive processors can be included for any number of features. As
depicted, directive processors 503 include policy computation 503A,
remote tasks 503B, software distribution 503C, and others 503D.
Core services 504 include identification of users and devices, the
organization of users and devices into groups for administrative
convenience, and the binding of directives to groups of users
and/or devices. Any of directive processors 503 can utilize the
functionality of core services 504.
[0065] When new features are desired, new processors can be added
to implement the desired features. For example, to add a device
backup feature, a directive processor used to back up devices can
be added.
[0066] Data persistence store 542 can store data for use by
directive processors 503. Data collector 512 can collect data from
and about entities that are being managed. Data collector 512 can
store the data in data persistence store 542. Data persistence
store 542 can take the form of a single database server, a cluster
of database servers, or a scale cloud storage device. In some
embodiments, a directive processor can also implement its own data
persistence.
[0067] Directive processors can 503 apply business logic to
device-neutral directives received from directive dispatcher 502,
in combination with data from data persistence store 542, and other
external data. For example, directive processors 503 can tabulate
the results of prior directives used, analyze directives for
correctness and consistency with existing standing directives,
speculatively predict the impact of implementing a directive (i.e.,
impact analysis), determine historical trends and other data mining
operations, package data payloads for subsequent distribution, and
so on. Processing device-neutral directives can result in
additional data being fed back into the system (e.g. analysis
results saved at data persistence store 542) or feedback (e.g.
reports generated for user inspection) being provide to the users
(e.g., an IT admin). Processing device-neutral directives can also
result in data related to the implementation of directives being
distributed to managed external devices and systems (e.g., any of
on-premises external system 516, off-premises external system 518,
3.sup.rd party device agent 544, native device agent 514, or legacy
device client agent 517).
[0068] For example, an IT admin may issue a directive to install a
software package on all computers in the Sales department. Software
distribution processor 503C can analyze this device-neutral
directive to determine the suitability and compatibility of known
computers in the Sales group, analyze the usage of available
licenses against needed licenses, and so forth. A separate external
actor external (e.g., an agent running on each of the target
devices) can then perform the installation steps on each of the
appropriate devices.
[0069] As such, since directive processors 503 process
device-neutral directives, directive processors 503 are able to
accomplish their processing without having to understand the
specific details of the various devices and/or external systems
that are targets of management. Gateway adaptors (e.g., 507, 508,
509, 543, and 511) provide translation of device-neutral directives
into a form suitable for execution in specified target devices.
Each gateway adaptor can be responsible for translating the
abstract, device-neutral (or external system-neutral) directives
into concrete, device-specific (or external system-specific) forms
suitable for execution on specific targeted devices (or external
systems).
[0070] Distribution routing component 506 can route device-neutral
directives to the appropriate gateway. Distribution routing
component 506 can use information recorded about each
device/external system in the data persistence store 542 to
facilitate routing device-neutral directives.
[0071] Various different types of gateway adaptors can be used. The
architecture is also generalized such that new gateway adaptors can
easily be added.
[0072] Device platform-specific gateway 543 can used to adapt
device-neutral directives to those of a specific device platform.
Device platform-specific gateway 543 is responsible for
implementing the "server/service" portion of the management
protocol used by the device client agent 114 for the target device
platform. That is, device platform-specific gateway 543 can
translate a device-neutral directive into the "server/service"
portion of the management protocol used by the device client agent
114.
[0073] For example, a device platform may be a mobile phone or
table operating system. The platform manufacturer can configure the
device platform as a closed system. The platform manufacturer can
also include its own management agent, which it does not allow
other parties to modify. The platform manufacturer can also develop
an accompanying management protocol to interact with the management
agent. In these embodiments, device platform-specific gateway 543
adapts a device-neutral directive to the accompanying management
protocol. As such, an IT admin can enter a generic directive at
admin console 541 to control a device that uses an otherwise closed
and/or propriety management protocol.
[0074] For some device platforms and device client agent protocols,
device platform notification service 513 can be used. For such
platforms and protocols, device platform-specific gateway 543 can
utilize that notification service. Continuing with the prior
example, the platform manufacturer can provide device platform
notification service 513.
[0075] The interaction between the device platform-specific gateway
543, device platform notification service 513, and native device
agent 514 is bi-directional. That is, information can be collected
and distributed between these components.
[0076] These and other patterns can be essentially repeated for
other managed devices. The patter can also be used for device
platforms from the same vender. That is, a management system may
include its own device client agent. In that event, the translation
performed by a gateway adaptor can be significantly reduced.
[0077] Gateway adaptors can also be sued for managing prior (or
legacy) editions of device clients. For example, legacy
client/server gateway 511 can be used to adapt a device-neutral
directive to the accompanying management protocol used by legacy
device client agent 517. Legacy client/server gateway 511 can also
adapt the directives expressed in one version of an IT management
system to those of a previous version of the same system. Adaption
to previous versions can be useful when a legacy agent is designed
to work with a prior version of a now revised system. Adaption to
previous versions can be a way to include continuity of management
of devices not yet upgraded or not able to be upgraded to the
client agent corresponding to the revised system.
[0078] Legacy client/server gateway 511 can also provide
interoperability with a device client agent of a different (perhaps
competing) management system product. In this scenario, the Legacy
client/server gateway 511 can emulate the server portion of the
competing management system, from the perspective of the device
client agent.
[0079] The interaction between legacy client/server gateway 511 and
legacy device client agent 517 is bi-directional. That is,
information can be collected and distributed between these
components.
[0080] External on-premises system-specific gateway 507 and
on-premises adaptor 546 can be used to adapt device-neutral
directives for use with an external software system that is
installed on the premises of an enterprise, such as, for example,
on-premise external system 516. For example, it may be that an IT
admin wishes to manage the email mailboxes of the users in the
enterprise. However, the email mailboxes are part of an email
system not part of an IT management system. The email system can
include one or more servers present on the premises of the owning
and/or operating enterprise.
[0081] Either the IT management system or the email system can
supply on-premises adaptor 546 to be run on-premises with the email
system. On-premise adaptor 546 accepts data and commands from the
external on-premises system-specific gateway 507 and enacts those
commands on on-premises external system 516. Alternately,
on-premises external system may itself provide facilities that
external on-premises system-specific gateway 507 can utilize
directly. In this embodiment, on-premises adaptor 546 may not be
included. The interaction between the components external
on-premises system-specific gateway 507, on-premises adaptor 546
and on-premises external system 516 is bi-directional. That is,
information can be collected and distributed between these
components.
[0082] The pattern is applicable to any number of other external
systems, including document management, customer relationship
management (CRM), complimentary IT management systems, etc.
[0083] External off-premises system-specific gateway 508 can be
used to adapt device-neutral directives for use with an external
software system that is installed off the premises of an
enterprise, such as, for example, off-premise external system 518.
External off-premises system-specific gateway 508 can use service
interfaces exposed by off-premises external system 518 to implement
directives and collect information. Off-premises external system
518 can include services such as Office 365, Google Apps,
Salesforce, Dynamics Online, etc.
[0084] The interaction between External off-premises
system-specific gateway 508 and off-premises external system 518 is
bi-directional. That is, information can be collected and
distributed between these components.
[0085] Device platform-specific gateway 509 and 3.sup.rd party
intermediary 519 can be used to adapt device-neutral directives to
bridge use between an IT management system and systems/devices
operated by a third party, such as, 3.sup.rd party device agent
544. Here, device platform-specific gateway 509 communicates with
3.sup.rd party intermediary 519 that utilizes 3.sup.rd party device
agent 544 also supplied by the external system. That is, 3.sup.rd
party intermediary 519 handles communication with 3.sup.rd party
device agent 544. Device platform-specific gateway 509 directs the
external system utilizing interfaces provided by the external
system.
[0086] The interaction between the Device platform-specific gateway
509, 3.sup.rd party intermediary 519, and 3.sup.rd party device
agent 544 is bi-directional. That is, information can be collected
and distributed between these components.
[0087] Gateway adaptors can also collect data from managed devices
and external systems. The gateway adaptors can translate collected
data into a device-neutral format. The gateway adaptors can submit
collected data in the device-neutral format to data collector 112.
Data collector 112 can define device- and external system-neutral
data schema. Gateway adaptors can use the schema to formulate
collected data into the device-neutral format.
[0088] Data collector 512 can receive collected data (in the
device-neutral format) from gateway adaptors. Data collector 512
can apply further processing when appropriate. Data collector 512
can then store collected data in data persistence store 542.
Directive processors 503 can refer to the collected data when
processing subsequent directives from directive dispatcher 502.
[0089] The present invention may be embodied in other specific
forms without departing from its spirit or essential
characteristics. The described embodiments are to be considered in
all respects only as illustrative and not restrictive. The scope of
the invention is, therefore, indicated by the appended claims
rather than by the foregoing description. All changes which come
within the meaning and range of equivalency of the claims are to be
embraced within their scope.
* * * * *