U.S. patent application number 10/831323 was filed with the patent office on 2005-02-03 for automated electronic software distribution and management method and system.
Invention is credited to Cirillo, Andrew, Krueger, Ray, Wolfe, Alex.
Application Number | 20050027846 10/831323 |
Document ID | / |
Family ID | 33425173 |
Filed Date | 2005-02-03 |
United States Patent
Application |
20050027846 |
Kind Code |
A1 |
Wolfe, Alex ; et
al. |
February 3, 2005 |
Automated electronic software distribution and management method
and system
Abstract
Embodiments of the present invention provide a method and system
for electronic software distribution and management. A request for
instructions may be received from a managed client machine. The
request for instructions may be analyzed. and may include asset
inventory data. One or more instructions may be generated based on
the request for instructions and the asset inventory data. The one
or more instructions may include an instruction to install an
application on the managed client machine. An acknowledgment may be
received from the managed client machine if the instruction has
been processed.
Inventors: |
Wolfe, Alex; (Chicago,
IL) ; Cirillo, Andrew; (Chicago, IL) ;
Krueger, Ray; (Schaumburg, IL) |
Correspondence
Address: |
ANDREWS KURTH LLP
Intellectual Property Department
Suite 300
1701 Pennsylvania Avenue, N.W.
Washington
DC
20006
US
|
Family ID: |
33425173 |
Appl. No.: |
10/831323 |
Filed: |
April 26, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60465122 |
Apr 24, 2003 |
|
|
|
60465118 |
Apr 24, 2003 |
|
|
|
60465121 |
Apr 24, 2003 |
|
|
|
Current U.S.
Class: |
709/223 ;
709/203; 709/220; 717/176 |
Current CPC
Class: |
G06F 8/61 20130101; Y10S
707/99955 20130101; G06F 8/64 20130101; Y10S 707/99936
20130101 |
Class at
Publication: |
709/223 ;
709/220; 709/203; 717/176 |
International
Class: |
G06F 015/173; G06F
015/177; G06F 015/16; G06F 009/445 |
Claims
1. A method comprising: receiving a request for instructions from a
managed client machine; analyzing the request for instructions,
wherein the request for instructions includes asset inventory data;
generating one or more instructions based on the request for
instructions and the asset inventory data, wherein the one or more
instructions include an instruction to install an application on
the managed client machine; and receiving an acknowledgment from
the managed client machine if the instruction has been
processed.
2. The method of claim 1, further comprising: queuing the one or
more generated instructions in a task queue; transmitting the
queued one or more instructions to the managed client machine; if
the acknowledgment from the managed client has been received,
removing the instruction from the queue.
3. The method of claim 2, wherein the application is a script.
4. The method of claim 1, further comprising: establishing a
priority associated with each of the one or more instructions; and
queuing the one or more generated instructions based on
priority.
5. The method of claim 1, wherein the one or more instructions
include an instruction to remove an application on the managed
client machine.
6. The method of claim 1, wherein the one or more instructions
include an instruction to repair an application on the managed
client machine.
7. A system for automated software distribution comprising: an
agent associated with a managed client to generate a request for
instructions; and a server coupled to the agent, wherein the server
is to: receive the request for instructions from the agent; analyze
the request for instructions; generate one or more instructions
based on the request for instructions; transmit the one or more
instructions to the agent, wherein the agent is to process the one
or more instructions; and receive an acknowledgment from the agent
if the one or more instructions have been processed.
8. The system of claim 7, wherein the request for instructions
includes asset inventory data associated with a managed client.
9. The system of claim 8, wherein the one or more instructions is
based on the request for instructions and the asset inventory
data.
10. The system of claim 7, wherein the one or more instructions
include an instruction to install an application on the managed
client.
11. The system of claim 7, wherein the one or more instructions
include an instruction to install an offer icon on the managed
client.
12. The system of claim 7, wherein the one or more instructions
include an instruction to remove an application on the managed
client.
13. The system of claim 7, wherein the one or more instructions
include an instruction to repair an application on the managed
client.
14. A method implemented on a computer for automatic software
distribution, comprising: receiving a request for instructions from
a managed client machine; analyzing the request for instructions,
wherein the request for instructions includes asset inventory data;
generating one or more instructions based on the request for
instructions and the asset inventory data, wherein the one or more
instructions include an instruction to install an application on
the managed client machine; and receiving an acknowledgment from
the managed client machine if the instruction has been
processed.
15. The method of claim 14, further comprising: queuing the one or
more generated instructions in a task queue; transmitting the
queued one or more instructions to the managed client machine; if
the acknowledgment from the managed client has been received,
removing the instruction from the queue.
16. The method of claim 15, wherein the application is a
script.
17. The method of claim 14, further comprising: establishing a
priority associated with each of the one or more instructions; and
queuing the one or more generated instructions based on
priority.
18. The method of claim 14, wherein the one or more instructions
include an instruction to remove an application on the managed
client machine.
19. The method of claim 14, wherein the one or more instructions
include an instruction to repair an application on the managed
client machine.
20. A license management method comprising: receiving a request for
instructions from a managed client; analyzing the request for
instructions, wherein the request for instructions includes
licensing data; determining whether the licensing data associated
with a program installed on the managed client is valid; if the
licensing data is not valid, sending an offer to purchase a valid
version of the program to the managed client; and if the offer to
purchase is not accepted, sending a remove instruction to the
managed client to remove the program.
21. The method of claim 20, further comprising: if the offer to
purchase is accepted, sending the valid version of the program to
the managed client.
22. The method of claim 21, sending the valid version of the
program comprising: sending an install script to download the valid
version of the program to the managed client.
23. The method of claim 20, further comprising: if the offer to
purchase is not accepted, sending an offer interface to the managed
client, wherein the offer interface providing an offer icon to
purchase a valid version of the program to the managed client.
24. A method for managing a computer software program license, the
method comprising: providing an offer icon to a managed client
device, wherein the offer icon is associated with a program; in
response to a selection of the offer icon, transmitting an install
script to the managed client device, wherein the install script
permitting a download and installation of the program to the
managed client device; receiving an exit indication that the
managed client device has terminated use of the downloaded program;
and in response to the indication, transmitting an remove script to
the managed client, wherein the remove script permitting removal of
the program from the managed client device.
25. The method of claim 24, wherein removal of the program
comprising: un-installing the program from the managed client.
26. The method of claim 24, wherein removal of the program
comprising: deleting files associated with the program from the
managed client.
27. The method of claim 24, further comprising: determining if
licensing information associated with the program is valid; if the
license information is valid, determining if the managed client has
exceeded an use limit associated with the program; and if the use
limit has been exceeded, sending an offer to purchase an additional
license associated with program to the managed client.
28. A method comprising: receiving a poll from an agent; receiving
asset inventory data from the agent if the agent is verified; based
on the asset inventory data, determining if a managed client
associated with the agent is entitled to a program; if the managed
client is entitled to a program, transmitting an install script to
download the program to the agent; based on the asset inventory
data, determining if an existing program, installed on the managed
client, should be removed from the managed client; and if the
existing program should be removed, transmitting a remove script to
un-install the existing program from the managed client.
29. The method of claim 28, further comprising: transmitting a poll
interval to the agent.
30. The method of claim 28, wherein the remove script to delete the
existing program from the managed client.
31. The method of claim 28, further comprising: receiving updated
asset inventory data from the agent, wherein the updated asset
inventory data based on the downloaded program and the n-installed
existing program.
32. The method of claim 31, further comprising: storing the
received asset inventory and the updated asset inventory data in a
memory.
33. The method of claim 28, further comprising: receiving an
acknowledgment from the managed client if the install script has
been processed.
34. The method of claim 28, further comprising: receiving an
acknowledgment from the managed client if the remove script has
been processed.
35. The method of claim 28, further comprising: based on the asset
inventory data, determining if an offer icon should be installed on
the managed client; if the offer icon should be installed,
transmitting an install offer icon script to the agent.
36. The method of claim 28, further comprising: based on the asset
inventory data, determining if an offer icon should be removed from
the managed client; if the offer icon should be removed,
transmitting a remove offer icon script to the agent.
37. A system for providing automated software distribution and
management, comprising: an agent associated with a managed client
to generate a poll; a server coupled to the agent, wherein the
server is to: receive asset inventory data from the agent; based on
the asset inventory data, determine if the managed client is
entitled to a program; if the managed client is entitled to a
program, transmit an install script to the agent, wherein the agent
to process the install script and based on the install script, the
agent is to download the program to the managed client.
38. The system of claim 37, wherein based on the asset inventory
data, the server is to: determine if an existing program, installed
on the managed client, should be removed from the managed client;
and if the existing program should be removed, transmit a remove
script to remove the existing program from the managed client.
39. The system of claim 38, wherein based on the remove script, the
agent is to: un-install the existing program from the managed
client.
40. The system of claim 39, wherein if the existing program is
in-installed from the managed client, the server is to: send an
offer interface to the agent and the offer interface to provide an
offer icon to purchase the program to the managed client.
Description
RELATED APPLICATIONS
[0001] The present application incorporates by reference and claims
the priority of U.S. Provisional Application No. 60/465,118,
entitled "Automated Electronic Software Distribution Method," U.S.
Provisional Application No. 60/465,122, entitled "Software
Distribution Management System," and U.S. Provisional Application
No. 60/465,121, entitled "Method, System and Article of Manufacture
for Data Preservation and Automated Electronic Software
Distribution Across an Enterprise System," all filed Apr. 24, 2003.
The present application also incorporates by reference co-pending
U.S. application Ser. No. ______, entitled "Method, System and
Article of Manufacture for Data Preservation and Automated
Electronic Software Distribution Across an Enterprise System," and
filed herewith.
TECHNICAL FIELD
[0002] The present invention relates to computer systems. In
particular, embodiments of the present invention provide an
automated electronic software distribution and/or management
system.
BACKGROUND OF THE INVENTION
[0003] Electronic Software Distribution (ESD) is the automated
delivery of software to remote computer systems. This can be
accomplished without human administration and/or intervention. ESD
systems are important components of information technology
environments, such as a corporate networks, that have a large
number of computer systems and devices. These computers and/or
networks are usually managed, supported and maintained by a small
staff, and in environments where the administrating personnel may
be physically distant or isolated from the systems they are
responsible for managing.
[0004] Further, ESD systems are also important to Independent
Software Vendors (ISVs) and Original Equipment Manufacturers
(OEMs). ISVs utilize ESD systems to facilitate the distribution of
updates, "hot patches" and "bug fixes." These systems provide for
greater customer support and service to the ISV's end users.
Additionally, OEMs whose equipment contains software can better
manage and monitor their equipment, as well as provide better
service and support to their customers through ESD systems.
[0005] Conventional ESD systems are capable of distributing
software from a remote system and may include the ability to
concurrently distribute identical software to groups of computers
based on existing attributes of those systems, or a pre-defined
mapping. Other systems include some degree of asset discovery,
which is the act of collecting and storing data on the existing
software and hardware assets present on a given computer. However,
asset discovery is usually accomplished through the use of a
separate, dedicated system.
[0006] Using one type of ESD system, an administrator creates a
"job" by specifying what software package they want to distribute,
which targets are to be run, and when the job is to run. The job is
executed on the specified targets at the specified time, after
which the job is removed from the system. This type of system is
highly "action" oriented, that is, the administrator decides what
action to take, and instructs the system to initiate that action.
Once the action is complete, the system returns to an idle state,
and does not initiate any more activity until specifically told to
do so by an administrator.
[0007] With another type of ESD system, certain targets, such as
network user objects, computers or other device containing embedded
software, are "entitled" (referred to herein as an entitlement) to
have a certain package. The system keeps track of whether the
package has been applied to a given system, and installs the
package if it is needed. This type of system may not take action
immediately or any automated actions whatsoever. If the entitlement
is made to a user, for example, the system may not take any action
until that user logs on to a system. After the user has logged on,
the system may deploy the entitled package.
[0008] The conventional job-based ESD system is limited since it
has no way of reacting to the current state of a machine. To
accomplish state management, the administrator must know what the
state of the managed computers is ahead of time, either by
maintaining a strict, detailed and cumbersome history of the
computers, or by monitoring the data returned by an asset discovery
system.
[0009] Conventional ESD systems are unable to effectively determine
if the software that is associated with the package is actually
installed or not. For example, the existing entitlement-based
systems only track whether their proprietary package was applied to
the system or not. As these packages are typically used to wrap the
install programs from the software vendor, if the software is
removed later, either by the user or by another package, the system
will not know to reapply it. Similarly, if the software already
existed on the system, either because it was installed before the
ESD system was in place, or because it was part of the initial
image of the computer, these ESD systems would not be able to
recognize that the software was already in place and would attempt
to re-install it.
[0010] Additionally, conventional ESD systems do not offer the
flexibility and/or the features as described below in accordance
with embodiments of the present invention.
SUMMARY OF THE INVENTION
[0011] Embodiments of the present invention provide a method and
system for electronic software distribution and management. A
request for instructions may be received from a managed client
machine. The request for instructions may be analyzed. and may
include asset inventory data. One or more instructions may be
generated based on the request for instructions and the asset
inventory data. The one or more instructions may include an
instruction to install an application on the managed client
machine. An acknowledgment may be received from the managed client
machine if the instruction has been processed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Embodiments of the present invention are illustrated by way
of example, and not limitation, in the accompanying figures in
which like references denote similar elements, and in which:
[0013] FIG. 1 is a system diagram in accordance with an embodiment
of the present invention;
[0014] FIG. 2 illustrates a block diagram of an agent in accordance
with an embodiment of the present invention;
[0015] FIG. 3 is a block diagram of a server in accordance with an
embodiment of the present invention;
[0016] FIG. 4 is flowchart illustrating a method in accordance with
an embodiment of the present invention; and
[0017] FIG. 5 is flowchart illustrating a method in accordance with
an embodiment of the present invention.
DETAILED DESCRIPTION
[0018] Embodiments of the present invention provide an automated
electronic software distribution and/or management ESDM system and
method that provides, for example, effective state management
across a disparate environment. Embodiments of the present
invention may provide an ESDM that may use asset discovery data to
execute software delivery, installation, removal and/or management.
In one embodiment of the present invention, the automated ESDM
system may explicitly query the managed device(s) prior to
installation and/or removal of software. Embodiments of the present
invention may provide scripts that may be run on one or more
devices. The scripts when processed, by a managed client may
download, remove and/or otherwise process software programs, for
example.
[0019] Embodiments of the present invention, may provide a platform
including integrated asset discovery (inventory, discovery,
tracking and reporting), software distribution (application
deployment, license management, self healing, disaster recovery),
software migration (OS migration, validation, data back up),
detailed real time analytical reporting and/or optimized ESDM
planning and scheduling. Embodiments of the present invention may
provide a license distribution and/or management system.
[0020] Embodiments of the present invention may provide a web-based
tool that may allow, for example, management of software updates
for managed computers. For example, embodiments of the present
invention may permit control of how and/or when the updates to
managed computers are installed. Additional features that may be
provided include but are not limited to repair and/or removal of
software as well as hardware devices, deployment of mandatory
updates, and/or provisioning of scripts on remote devices. A script
may be macro or batch file including a list of commands and/or
instructions that may be executed on a managed client without user
interaction, for example. The script may be written in any suitable
language.
[0021] FIG. 1 is an automated ESDM system 10 in accordance with an
embodiment of the present invention. As shown in FIG. 1, ESDM
system 10 may include one or more enterprise systems (ES) 14 that
may be coupled to one or more master servers (MS) 12 via a transit
network 16. The MS 12 may include and/or may be coupled to a
database (DB) 18. The ES 14 may include one or more on-site servers
(OSS) 24 coupled to one or more databases (DB) 28. The OSS 24 may
be coupled to one or more remote site servers (RSS) 22. In
embodiments of the present invention, the RSS 22 may be coupled to
one or more managed clients 20. The clients 20 may be one or
managed computers, servers, communications devices (e.g., routers,
switches, etc.), consumer appliances, vehicles, and/or any other
device or item.
[0022] In an embodiment of the present invention, the transit
network 16 may be a communications network that may include, for
example, a public switched telephone network (PSTN), an Integrated
Services Digital Network (ISDN), a cellular network, a digital
mobile network, a Personal Communication Systems (PCS) network, an
Internet, an intranet, a signaling system 7 (SS7) network, a local
area network (LAN), a satellite network, an advance intelligent
network (AIN), any suitable digital or analog network, a broadband
network such as a cable network, any other public and/or private
network, any other suitable national and/or international
communications network or any combination thereof.
[0023] In embodiments of the present invention, the various
components shown in ESDM system 10 may be coupled by wired (e.g.,
optical, electrical, etc.) and/or wireless means. For example, the
MS 12 may be coupled to the transit network 16 by a optical and/or
a wireless connection. The managed clients 20 may be coupled to the
RSS 22 and/or the OSS 24 by wired and/or wireless means. Although,
the managed clients 20 are shown coupled to the RSS 22, it is
understood that the managed clients 20 may be coupled directly to
the OSS 24 and/or to the master server 12. Therefore, the RSS 22
and/or the OSS 24 may be bypassed. In addition, the functionality
of any component in ESDM 10 may be provided in any other component.
It is further recognized that the OSS 24, RSS 22 and/or the MS 12
may be provided in a single device. Although not shown, the MS 12
can be connected to more than one ES 14. In such a configuration,
each ES 14 may be a separate campus within a larger organization,
such as a geographically diverse corporation or government
entity.
[0024] In embodiments of the present invention, the automated ESDM
10 including the transit network 16, MS 12, DB 18 and/or ES 14 may
include one or more switches, communication interfaces, and/or
other components that are not shown for convenience. It is
recognized that the various types of communications that may be
provided in these systems may include hard-line, wireless, RF,
optical, and/or any other type of communications or any combination
thereof. The various devices, systems, networks, etc. may be
appropriately configured or equipped with hardware and/or software
to operate in such environments.
[0025] In embodiments of the present invention, the ESDM 10
architecture may include multiple levels including the MS 12, the
OSS 24, the RSS 22, and managed clients 20. However, it is
recognized that the ESDM 10 architecture may be provided by fewer
levels by combining the features of one or more levels, for
example. By the same token, the ESDM 10 architecture may include
more levels by distributing the features throughout additional
components and/or devices.
[0026] In embodiments of the present invention, the MS 12, OSS 24
and/or RSS 22 may provide a centralized location where software
updates, scripts or the like may be available. Software updates and
instructions on how to distribute the updates may be published to
the MS 12. The updates, instructions, scripts, etc. may be passed
to one or OSSs 24 for distribution, for example. The remote MS 12
may act as a redundant backup system to the OSS 24 located within
the ES 14. Connected to the maser server 12 is a database 18 for
storing information and data files relevant to the process of
preserving data stored on managed computers within ES 14. The
updates, scripts, programs, etc. may be stored in a central
repository such as DB 18 and/or DB 28.
[0027] The DB 28 coupled to OSS 24 may additionally contain
information about individual managed client 20 such as their disk
size, memory, last user, IP address, and the like. In addition, the
DB 28 may contain "entitlements" which are associations between
clients 20 and application software that is permitted to be loaded
on the clients 20. The entitlements may be represented as database
records that associate application software program(s) with the
computers 20 based on a device identifier and a user login
identifier. The entitlements for a particular managed device may be
set by a user via the console 30. If a client 20 is entitled to a
software product, as indicated by the OSS 24, for example, the
agent 32 may poll one or more of the other components (e.g., RSS
22, OSS 24, MS 12 and/or DB 28, in FIG. 1), and may retrieve its
entitlement. The software package indicated by the entitlement,
which may stored on the RSS 22, for example, may be downloaded
directly from the RSS 22 to the client 20.
[0028] In embodiments of the present invention, one or more of the
servers (e.g., MS 12, OSS 24, and/or RSS 22) may provide remote
access (e.g., web access) where users can log-in to check on
installation status, program status, health and/or other
information related to clients 32. In one embodiment of the present
invention, the MS 12 may receive replication information from the
OSS 24 and/or RSS 22 for reporting purposes, for example.
[0029] In embodiments of the present invention, the OSS 24 may
resides at an operational center and/or may be the repository for
all customer activity. The OSS 24 may communicate all activity with
each RSS 22 which may be located at customer sites, for example.
The OSS may also provide reporting services as well as replicating
all its information to for example, the MS 12. Embodiments of the
present invention may include an alternate OSS 24 that may serve as
a backup and/or alternative monitoring and/or access point. In some
cases, some information from an alternate OSS 24 may be restricted
to certain functions or information. For example, the alternate OSS
24 may be restricted only to entitlement information or the
like.
[0030] In an embodiment of the invention, the OSS 24 may include a
management console 30. The console 30 may provide an ESDM
administrator with the ability to view and/or manipulate data in an
ESDM hierarchical directory. The directory may provide the listing
of all customers and/or clients assigned to the OSS 24. Customer
and/or clients may include other on-site servers, remote site
servers and/or clients. Customers and/or clients may be organized
in cluster or other arrangement. A cluster may be a grouping of
servers, computers or other devices with an order defined in the
cluster. It is recognized that the servers, computers, etc. can be
dynamically grouped into the proper cluster container, for example.
The console 30 may permit administrators to, for example, control,
monitor and preserve inventory, and/or schedule, audit or deploy
the managed computer systems and software operations.
[0031] In embodiments of the present invention, the RSS 22, like
the OSS 24, the RSS 22 may exist as a stand alone computer and/or
may co-exist with another server on the same physical computer, for
example. The RSS 22 may be coupled to and/or may serve a network or
the like that may include one or more clients 20. Optionally or
additionally, the RSS 22 may replicate with its associate OSS 24
over, for example, the Internet via HTTPS or other protocol. In
some cases, RSS 22 may be a client that hosts an agent (to be
described below in more detail) that points to itself for
entitlement and monitoring purposes. It is recognized that multiple
servers 22 may be connected to a single OSS 24.
[0032] As indicated above, the clients 20 may be one or managed
computers, servers, communications devices (e.g., routers,
switches, etc.), consumer appliances, vehicles, and/or any other
device or item. The clients 20 may be coupled to the RSS 22, OSS 24
and/or MS 12 by any type of wired and/or wireless connection. One
or more of the clients 20 may include a managed agent 32. The agent
32 may be a hardware and/or software component that may
periodically contact the RSS 22, for example, for a request for an
instruction. Once the instruction is received, the agent 32 may
process the instruction in accordance with embodiments of the
present invention. The server may provide a polling interval for
the agent to poll the RSS 22, OSS 24 and/or MS 12. Optionally
and/or additionally, the polling interval may be a pre-determined
periodic interval. In embodiments of the present invention, agent
20 may be incorporated into an RSS 22, MS 12 and/or OSS 24. If the
agent 20 runs on one or more of these servers, the agent 32 may be
used to update deployment system software on these servers, for
example.
[0033] Clients 20 may include various types of computers, such as
conventional desktop personal computers (PCs), portable computers
(notebooks, laptops), workstations, computer network servers or any
other device that has embedded software and is capable of networked
communication. Each device 20 may include conventional computer
components, such as a processor, random access memory (RAM), one or
more local hard drives, OS software, application software, data
files, network interface hardware and software, and the like. In an
embodiment of the invention, one or more clients 20 may runs a
Windows.RTM. OS available from Microsoft.RTM. Corporation of
Redmond, Wash.
[0034] In embodiments of the present invention, the managed client
20 may be an incorporated into an computer, automobile, consumer
appliance, cell phone or other type of communication device (pager,
satellite phone, etc.), personal digital assistant (PDS), and/or
any other device that processes a software program, application
and/or data.
[0035] In an embodiment of the present invention, the clients 20
may be organized into groups, with each group being networked to a
corresponding RSS 22, for example. The RSS 22 and its corresponding
clients 20 may be connected together by a conventional local area
network (LAN), such as Ethernet or a wide area network (WAN), to
permit communication and transfer of data files. The grouping of
the clients 20 and hierarchical structure of the ES 14 may permit
parallel execution of the migration process or software deployment
among the computers. If the RSS 22, OSS 24 and/or MS 12 provide a
license distribution and/or management system, the server(s) may
manage and/or distribute licenses to one or more clients 20 that
may be part of a group such as a LAN, WAN or the like.
[0036] In embodiments of the present invention, the RSS's 22 may be
networked to an OSS 24 using a commercially-available LAN or WAN.
The OSS 24 may be a centralized server that is configured to
initiate and control program deployment to the managed clients 20
across the ES 14. To accomplish this, the OSS 24 may include, among
other things, a browser console 30 and is connected to an onsite DB
28.
[0037] The browser console 30 may be a web browser application that
permits a user to enter commands that control the data preservation
and/or application deployment process. The console 30 may also
provide processing status and reports to the user, and permits the
user to set entitlements, foe example.
[0038] In an embodiment of the present invention, the agent 32 may
include a system management program written in, for example, C++
and/or may run as a Windows.RTM. system service. The agent 32 may
poll the RSS 22, OSS 24 and/or MS 12 (e.g., via HTTPS or other
protocol) for any requests or instructions, for example. In
response, the server(s) may provide entitlement programs, scripts,
install and/or un-install instructions, and or other operations,
for example, to be processed by the managed client 20. Moreover,
these operations may include, for example, the installation,
removal and/or repair of software, installation, removal or repair
of scripts and/or the installation, repair and/or removal of
hardware. The agent 32 may accept Microsoft.RTM. Installer
packages, for example, as content from the RSS 22. The RSS 22 which
the agent 32 is to poll may be predetermined during agent
installation and/or may be dynamically determined by the agent 32
and/or by the RSS 22, OSS 24 and/or MS 12, for example. This
setting may be stored in a registry located in the agent 32 or in
an external registry, for example.
[0039] In embodiments of the present invention, it is recognized,
that the agent 32 may receive instructions from OSS 24 and/or MS 12
as well as RSS 22. Moreover, in embodiments of the present
invention, the RSS 22, OSS 24 and/or MS 12 may contact the agent 32
and request information and/or may instruct the agent to perform
one or more operation or task.
[0040] In embodiments of the present invention, the agent 32
including the system management program may collect hardware and/or
software information from the client 20 system that it is installed
on. For example, the agent 32 may collect system, status, and/or
health information from the hard drive, the random access memory
(RAM), the processing unit such as the CPU, the basic input-output
system (BIOS), etc. This information may be part of the asset
inventory of the system. The agent 32 may use any type of interface
or tool such as the Windows WMI and/or Win32 APIs or the like to
get the desired information. For example. to collect software
information, the agent 32 may use the Microsoft Windows.RTM.
Installer database APIs (contained and populated on Windows 2000
systems by MSI based content) along with the uninstall key of the
Windows.RTM. registry. The information collected by the agent 32
may be formatted in, for example, extensible markup language (XML)
and may be posted to the RSS 22 and/or the OSS 24.
[0041] In one embodiment of the present invention, the ESDM system
may only permit a pre-determined number of clients to be monitored
by the RSS 22, for example. Thus, the RSS 22 may maintain count of
the number of licensed systems for any given customer that are
being monitored by the RSS 22. If the number of licensed
connections is exceeded, the RSS 22 may not allow additional
connections and an error will be logged. The RSS 22, depending on
configuration, may seek permission to allow additional connections
and may report the additional connections to the OSS 24 and/or MS
12, for billing purposes or the like.
[0042] In embodiments of the present invention, the agent 32 and/or
the RSS 22, for example, may monitor the number of, for example,
licensed program applications that are present on one or more
managed clients, and/or one or more networks. For example, the RSS
22 may receive license keys or other licensing related information
related to the program applications from clients 20. The RSS 22 may
validate the information to determine if, for example, the provided
keys are authentic. Once the information is validated, the RSS 22
may determine if, for example, the client has an authorized version
of the program. If the client is determined to have an unauthorized
version of a program, the RSS 22 may warn the user and/or may offer
to provide and/or purchase the client 20 with an authorized version
of the application program. If the client agrees to purchase a
valid version of the program, a install script may be sent to the
manages client by the server. The client may arrange to make
payments for the purchased program by appropriate means (credit
card, debit card, check, etc.). On the install script is processed
by the managed client, the purchased program may be downloaded
and/or installed in the managed client. If however, the client does
not wish to purchase the program, an remove script may be sent to
the managed client from the server. The remove script may be
processed by the agent to un-install and/or delete the unauthorized
version of the program. In embodiments of the present invention, if
an unauthorized version of the program is present on the managed
client, a trial version of the program may be provided by the
server or an offer interface to retrieve a valid version of the
program, as described herein, may be provided to the managed
client.
[0043] In embodiments of the present invention, when the agent 32
is installed, the fingerprint for the X.509 certificate, for
example, of the RSS 22 to which the agent is to communicate with
may be imported and/or declared valid. The agent 32 may utilize the
Microsoft Windows 2000 WinINet APIs (a standard Win32 Library) for
HTTPS and SSL V3 communications, for example, for communications.
The agent 32 may communicate with its designated RSS 22 over the
suitable port such as HTTPS port 8443 and 443. It is recognized
that the ports 8443 and 443 are given by example only and that the
server can be configured to communicate over any port.
[0044] In an embodiment of the present invention, an agent 32 may,
for example, contact the OSS 24 and/or RSS 22 at regular intervals
and may request instructions from the OSS 24 and/or RSS 22. Once
the instructions are received, the agent 32 may process the
received instructions. For example, these instructions may direct
the agent 32 to gather and return asset inventory data, and/or may
direct the agent 32 to install or remove a software package from
client 20.
[0045] In embodiments of the present invention, inside the OSS 24
and/or RSS 24, a task processor may receive requests from agents
32, and based on the request may compare the current state of the
managed client 20 (based on the data returned from asset discovery)
against the entitlements stored in an directory. If there is a
discrepancy between what is entitled and what is currently
installed in the managed client 20, the task processor may
automatically generate the instructions to either add and/or remove
programs necessary to bring the system to the desired state.
Optionally or additionally, the task processor of the OSS 24 or RSS
22 may also send instructions at regular intervals to cause the
agent to resend its asset inventory data.
[0046] In one embodiment of the invention, the servers (e.g., MS
12, OSS 24 and/or RSS 22) may use a hierarchical directory that may
provide the listing and/or access to, for example, all customers
and/or clients assigned to the respective server. The directory,
usually referred to as a serviceability directory, may be based on
based on, for example, the IEEE X.500 standard. See, International
Organization for Standardization/International Electrotechnical
Commission 9594-1 (1993). As an X.500 based directory, this system
may have three types of container objects. The highest level
container type is referred to as the "country". Underneath the
country, it is possible to have zero or more "organization"
containers, and under the organization, it is possible to have zero
or more "organizational unit" containers. The organizational unit
can contain both leaf objects and other organizational units. Leaf
objects include "system" objects, such as Networks and Servers,
"targets", such as Users, Computers, Groups and Containers, and
"products". It is recognized that the directory standard is given
by way of example only and that any type of directory format may be
employed in embodiments of the present invention.
[0047] When used in a multi-server environment, the directory may
be stored in a decentralized structure. All servers 22 and/or 25
may have a full copy of the portion of the directory that they
need. Servers that share parts of the directory may keep the data
consistent across servers by using a replication process.
[0048] In embodiments of the present invention, the concept of an
entitlement involves the interaction of three objects, a target, a
product and an entitlement. Targets may be objects in the
directory, and include users, computers, devices, applications,
groups and/or containers. The relationship between these objects
can be explained in that targets are entitled to products. In other
words, entitlement objects represent a many-to-many relationship
between targets and products. While an entitlement may be made to a
single target, it may ultimately be applied to many computers if it
is made to a group or container.
[0049] In embodiments of the present invention, when a computer is
being analyzed for new tasks, the following process, for example,
may used to find entitlements. All entitlements made directly to
the computer target may be considered. Entitlements made to the
computer's parent container are considered, followed by its
grandparent and so on to the root. Entitlements made to any groups
that the computer belongs to are considered. The groups may be
processed in alphabetical order, and each group's containers may
also be considered. Next, entitlements made to the primary user
target for the computer are considered and again, containers are
also processed. Finally, groups that the user is a member of may be
considered. This process may provide provides the system
administrator with more flexibility in delivering, managing,
monitoring, migrating, and/or inventorying software.
[0050] In embodiments of the present invention, a server such as
RSS 22 may be designated as a "local server" for one or more
clients 20. An installation may also have other server objects that
represent peer installations. The other servers can be used to send
polling agents to other installations that may be physically
closer, or otherwise more appropriate for a particular client
20.
[0051] A network object may represent an IP subnet, or other range
of IP addresses. The network may be used in a multi-server
installation to approximate a physical location for a given agent
or client. For example, when an agent 32 polls a server 22, the
server 22 may first attempts to match the requesting IP address to
a network object that it has in its directory. If a network is
found, the server list that may be mapped to the network is
examined. If the current server 22 is in the list, then the poll is
passed on to the task processor of server 22, for example. If the
current server 22 is not in the list, the list may be sent to the
agent 32, along with a command to reset, so that the agent can
redirect itself to another more appropriate server. The agent may
examine the received list, identify an appropriate server from the
list and may poll that server for a request for instructions.
[0052] In embodiments of the present invention, the agent 32 may
include a system management program that is run on the managed
client 20. The program may be designed to be run continuously, as
long as the system is on or the program may only operate for
certain periods of time. For example, on Windows.RTM. NT based
systems (e.g. Windows.RTM. NT, 2000 and XP), this means that the
agent 32 may normally run as a system service. On other platforms,
for example, the agent 32 may be executed at system startup, and
allowed to run continuously as a daemon until system shutdown.
[0053] FIG. 2 is a diagrammatic representation of an agent 32, in
accordance with an embodiment of the present invention. It is
recognized that agent 32 may be a software program, a hardware
device and/or any combination thereof. The agent 32 may be part of
the hardware and/or software that exists in the managed client 20
or may be a separate unit and/or may be a combination thereof. In
embodiments of the present invention, the agent 32 may be modular,
and may include, for example, a polling module 27, an inventory
module 29, and/or a one or more instruction handlers 25. It is
recognized that the agent may include other components which have
been omitted from this description for simplicity. The polling
module 27 may be responsible for making, for example, an HTTP call
to the server 22 on a regular interval, downloading an instruction
from the server 22, using the appropriate instruction handler 25 to
process the instruction, and/or for sending the results back to the
server 22.
[0054] In embodiments of the present invention, the instruction
handler 25 may process the one or more instructions received by the
polling module 27. The instruction handler 25 may work query the
inventory module 29 for the status of existing software and/or
hardware to fulfill the received instructions. In one example, the
inventory module 29 may include inventory data is broken up into
groupings called "catalogs." Each catalog may include a collection
of related data, for example, a list of installed peripheral
component interconnect (PCI) devices, for example. In one case, the
data for the catalog may be collected by the agent 32 in XML
format. However, it is recognized that the data may be collected in
any other format. The catalogs may be serialized using standard
Java.RTM. serialization mechanisms, for example. The catalogs may
be stored on the servers file system as individual binary files or
may be stored in a database, for example. Catalogs may also be
converted to and from XML using "Castor" technology, for example.
Because a catalog may be represented as XML, other views can be
generated using extensible style language (XSL) transforms,
including hyper text markup language (HTML) and structured query
language (SQL), for example.
[0055] FIG. 3 is a diagrammatic representation of a server 50, in
accordance with an embodiment of the present invention. Server 50
may be any of the servers (or part of any of the servers) of the
ESDM system 10. For example, server 50 may be part of MS 12, OSS 24
and/or RSS 22. It is recognized that server 50 may be represented
as a software program, a hardware device and/or any combination
thereof. The server 50 may include a task processor 51, task queue
53 and/or a license manager 59, for example. Server 50 may include
other components that are omitted for simplicity.
[0056] In embodiments of the present invention, the server 50 pay
process the polling requests, for example, received from agent 32.
For example, when an agent 32 polls a server 50 for the first time,
the server 50 may set up a number of initialization tasks to
execute in a task queue 53 for that agent. At each agent poll, the
server 50 may return one or more instructions for each task to the
agent for it to process. As the agent 32 executes those
instructions and returns the results, the tasks are removed from
the task queue 53.
[0057] In embodiments of the present invention, the task processor
51 may process the installation of a software package and/or
executing an inventory package. The task processor 51 may generate
a list of software that is either directly (e.g., made to the
computer itself) or indirectly (e.g., made to containers, groups or
users) made to the computer. The software on the list may be sorted
by product version so that later versions are processed first. The
task processor 51 may examine each version of the software on the
list and may compare the expected action with the current state of
the managed client 20 based on its agent 32. For example, if the
current state of the managed client 20 is compatible with (or the
same as) the corresponding software on the list being examined,
then the software is ignored and there is no updated needed. For
example, if a product X, version Y is currently installed on the
client 20, then the process to install product X, version Y may be
ignored. If however, product X, version Y is not currently
installed, then the process to install the product may be used to
create one or more tasks that may be added to the task queue 53 for
processing. In one example, once one or more tasks corresponding to
a software installation is scheduled in the queue 53, the server 50
may discontinue further installations associated with that agent
and/or client until the current installation is complete. This
action may be take to maintain compatibility. However, it is
recognized that the server 50 may continue to process other
installations even if a current installation is pending. The server
may use parallel processing techniques, for example, to process
additional instructions and/or processes.
[0058] In embodiments of the present invention, the server 50 may
use, for example, a compatibility criteria to determine if a
particular software product should be installed and/or removed, for
example. For example, a software product is compatible and no
further installation associated with that product may occur if, for
example, the product is installed or if any later version of the
product is installed. If, for example, a lower version of the
software product is installed, an updated version of the program
may be installed or scheduled to be installed. But, if the latest
version of the program or a higher version of the program is
installed, then the program may not need to be updated. It is
recognized that even if an updated or later version is installed,
the same program may be re-installed in the managed client.
Moreover, even if the entire program is not installed, additional
setting, upgrades, fonts, or other data may be installed.
[0059] In an embodiment of the present invention, the server 50 may
forward a un-installation instruction or un-installation
entitlement associated with a software product. If for example, it
is determined that a software or program needs to be partially or
completely un-installed and/or deleted from the managed client, the
server may send an un-installation and/or delete instruction
(and/or script) to the managed client to un-install and/or delete
the program. If a program tom be deleted and/or un-installed exists
in the managed client with the same or lesser version, then the
proper instruction and/or script may be sent to the managed client
for processing. The managed client may receive the instruction
and/or script and process the instruction and/or script to
un-install and/or delete the program. This process can be done at
any time and indicated by the server or as determined by the
managed client, administrator, and/or user. It is recognized that
preconditions may be set before a program can be un-installed
and/or deleted from the machine. If, for example, a proper license
exists for an upgraded program, the old program may not me
un-installed and/or deleted until the upgrade is scheduled and/or
completed. Of course, other checks may also be made before programs
are removed. For example, data associated with the program to be
un-installed and/or removed may be backed up by the client and/or
server so that the data is not lost and can be available at a later
time.
[0060] Embodiments of the present invention may provide a license
authorization script or instruction that provides an offer
interface (e.g., an offer icon) on, for example, a managed client's
computer. The offer interface may provide a program offer to
install a valid program in the managed client, for example. If the
offer icon is selected and/or a valid license is authorized to the
managed client, a program associated with the offer icon and/or
license may be downloaded by the managed client. In embodiments of
the present invention, once the program has been exited and/or use
otherwise terminated, the program may be automatically deleted
and/or un-installed, and the program license may be available to
others if requested via offer interface located on other machines.
Accordingly, an authorized license can be validly used by several
users under the terms of the license.
[0061] In embodiments of the present invention, the offer interface
may be compatible if the same software of any version is not yet
installed, or if the same software with any version is already
installed. An offer interface associated with any program may be
installed on a client's machine. This could be a new program or a
program that is already installed. In the latter case, an
administrator or user may want to change status of the program from
actually having a copy of the program loaded on the machine at all
times to having "access" to the program when needed and allowing
others to used the program when not needed or when "use limits" are
passed, for example. In embodiments of the present invention, "use
limits" may, for example, indicate a predetermined number of uses
for the program, a predetermined time the program may be used
and/or any combination thereof. Once the use limit has been
reached, the program may be un-installed and/or may be deleted. It
is recognized that use limits can be set for programs downloaded
via the offer interface as well as other programs, as described
herein.
[0062] In embodiments of the present invention, an install
entitlement for an offer interface may be designed to be compatible
twice, with different behaviors. For example, first, an offer
interface installation with use limits may follow the same
compatibility rules as a normal install entitlement. In other
words, an offer interface may be installed for any existing or new
programs. Then, when the product catalog indicates that the time
since the software has been used on the client machine has
surpassed the use limit specified in the entitlement, the
entitlement becomes compatible again, this time to change the
installation to an offer interface state. In other words, when the
offer limit has been passed, the associated program may be
un-installed and/or deleted. However, the offer interface may
remain or may be re-installed on the client's machine for future
selection. If the use limit is never reached, then the second
behavior may never be realized by the system and the installed
product remains installed.
[0063] In embodiments of the present invention, installation,
removal, and/or the offer interface, for example, may be provided
by scripts or other instructions that may be sent from the server
to one or more managed clients. The scripts may be processed by the
managed client to complete the operation. For example, if the
instruction is an instruction to install an updated program, the
managed client may process such script to download the program at
any time. In some cases the download may be immediate and/or in
other cases the download may be delayed. This concept may be
applied when programs are un-installed, removed and/or when offer
interfaces are processed, for example.
[0064] FIG. 4 is a flowchart illustrating a method 400 in
accordance with embodiments of the present invention. In an
embodiment of the present invention, an agent may poll one or more
servers in the ESDM system, as shown in box 410. The poll may
include identification data associated with the agent. In other
cases, the poll may also include a request for instructions. Once
the server receives the poll, the server may verify whether the
agent is part of a system that the server is responsible for, as
shown in box 415. If the agent is part of the system, then the
server may process the agent. If however, the agent is not part of
a system the server is responsible, the server and/or a master
server may identify and forward the agent to the correct
server.
[0065] Once the appropriate server is identified for the agent,
processing in accordance with an embodiment of the present
invention may begin. The server may transmit an asset inventory
instruction including a request for the agent to collect and return
inventory asset data to the server. As described herein, the
inventory asset data may include information related to hardware,
software, licensing, etc. installed in the managed client
associated with the agent. It is recognized that the agent may be
associated with more than one managed client. In addition, the
server may provide a polling interval to the agent. The polling
interval may provide, for example, an indication when the
subsequent polls to the server should occur.
[0066] In embodiments of the present invention, the server may
receive the asset inventory data from the agent, as shown in box
420. The server may process the asset inventory data received from
the agent, as shown in box 430. Based on the asset inventory data,
the server may determine if an program is to be installed on the
managed client, un-installed and/or deleted from the managed
client, and/or if an offer interface is to be provided to the
managed client. In addition, the server may provide license
management services for one or more agents as described herein. The
server may place one of more instructions to be sent to the agent
in a queue. As subsequent polls are received, one or more
instructions may be sent to the agent for processing.
[0067] In embodiments of the present invention, the asset inventory
data may be used by the server to established a base-line for the
one or more managed clients associated with the agent. The asset
inventory data and/or other information may be stored in a database
for future use. In embodiments of the present invention, the server
may provide the default tasks to those managed clients that have
designated hardware and/or software configurations. The default
tasks may provide all the managed clients with compatible hardware
and/or software. For example, the default tasks may request removal
of certain programs while the installation of other programs, for
example.
[0068] In embodiments of the present invention, the asset inventory
data may be processed by the server to determine which programs the
managed client is entitled to. If it is determined that a managed
client is entitled to a program, the server may transmit an
installation script to be sent to the agent so that the entitled
program can be downloaded by the agent, as shown in boxes 440 and
443. The installation script may be placed in a queue to be sent to
the agent and/or may be sent directly to the agent. Once the agent
receives, for example, the installation script, the agent may
process the installation script to down load the program, as shown
in box 445.
[0069] In embodiments of the present invention, the asset inventory
data may be processed by the server to determine if a program(s)
should be removed (e.g., un-installed and/or deleted) from the
managed client, as shown in box 450. If it is determined that a
program is to be removed from a managed client, the server may
transmit a remove script to be sent to the agent so that the
identified program can be un-installed and/or removed from the
managed client, as shown in box 453. The remove script may be
placed in a queue to be sent to the agent and/or may be sent
directly to the agent. Once the agent receives, for example, the
remove script, the agent may process the remove script to
un-install and/or delete the identified program(s) from the managed
client(s), as shown in box 455.
[0070] In embodiments of the present invention, the asset inventory
data including, for example, licensing data associated with one or
more managed clients may be processed by the server to determine if
an offer icon may be removed from or installed in a managed client,
as shown in box 460. As described herein, the server may perform
license management functions to manage program licenses associated
with the one or more managed clients. Thus, for example, the server
may provide offer icons to the agent so that programs can be
installed and/or removed so that valid and licensed programs are
available. If it is determined that an offer icon should be
installed or removed from the managed client, the server may
transmit a offer script to be sent to the agent so that the
identified program can be installed or removed from the managed
client, as shown in box 463. The offer script may be placed in a
queue to be sent to the agent and/or may be sent directly to the
agent. Once the agent receives, for example, the offer script, the
agent may process the offer script to install or remove an offer
icon from the managed client(s), as shown in box 465.
[0071] In embodiments of the present invention, the agent may send
an acknowledgement to the server when one or more scripts are
processed. The acknowledgment may indicate the status of the agent
and/or managed client. In embodiments of the present invention, the
agent may forward updated asset inventory data to the server. The
server may update its stored asset inventory data, as shown in box
470. In embodiments of the present invention, the server may
transmit a poll interval to the agent, as shown in box 480. The
poll interval may indicate when the server may need additional
information from the agent, for example. It is recognized that the
agent may poll the server as needed, for example, if there is a
status change, other event, or the like, for example.
[0072] In embodiments of the present invention, the server may
provide a script, file name and/or product code associated the
install, remove and/or offer icon data, for example, to the
agent.
[0073] Embodiments of the present invention may provide a license
management system, as part of the ESDM system, which may permit a
client such as an independent software vendor (ISV) and/or an
Original Equipment Manufacturer (OEM) to maintain an inventory of
and/or maximize the efficient use of their software licenses. This
license management system may incorporate and/or provide
embodiments of the "offer interface" feature described above. The
license manager 59 (FIG. 3) may provide a license management
service that may for example, detect and/or remove unused or
unapproved software from managed systems. The license manager may
permit a user to mange and/or update licenses automatically. The
license manager may provide a "use limit" value associated with one
or more programs, for example, installed on client machines. The
"use limit" may indicate when the manager 59, for example, may
remove a particular software from the managed client 20 if the
inventory indicates, for example, that it has not been used in a
specified number of days or if the existing number of copies has
exceeded an authorized number of copies.
[0074] For example, if the license manager 59 determines that a
software is eligible for removal, the task processor may schedule a
removal task (e.g., remove script) in task queue 53, for example.
The server 50 may send the agent 32 an uninstall script for the
software product. The software instruction may be followed by, for
example, an offer interface to permit the user to re-install and/or
re-activate the software product. The offer interface may provide a
offer icon that may allow a program to appear to be installed on a
client machine without actually having the binaries in place to run
the software. When the user wishes to use the software (indicated
by double clicking the offer icon), it is automatically installed.
The offer interface may provide one or more programs that do not
require a user license until the program is actually installed.
[0075] In embodiments of the present invention, any type of
technique may be utilized, for example, to inventory the installed
software at and/or collect data from the managed client 20. Such
techniques may be platform dependant. For example, if the managed
client is running the Microsoft Windows.RTM. operating system, it
may be possible to quickly query the system for a list of installed
software using the "Add/Remove Programs" function from the control
panel and the contents of the Windows registry. Optionally or
additionally, the Microsoft Windows Installer program may be used
to obtain a list of installed programs and/or other data associated
with the managed client 20. It is recognized that if a different
operating system (OS) is used, appropriate interfaces may be
available to retrieve the desired information.
[0076] In embodiments of the present invention, it may also be
possible to determine if a program/application is installed using a
concept commonly known as a "signature." A signature is a
collection of attributes of a system that indicate with a high
probability that a particular software product is installed.
Signatures are usually based on the existence of at least one
specific program file, but may also be based on directories,
registry entries and/or values from configuration files.
[0077] FIG. 5 is a flowchart illustrating a method 500 in
accordance with embodiments of the present invention. Initially,
the software agent 32 is distributed across the enterprise network
to one or more clients 20, as shown in box 510. Agent 32 may be
downloaded to the managed client 20 from a networked server in
response to a network login script executed by each computer. The
login script may include a path designating the location of the
agent software to be downloaded. Optionally or additionally, an
e-mail attachment or URL link, remote scripting, or other ESD
system may be used to distribute the agent 32. An indication may be
provided when the agent 32 has been successfully installed.
Moreover, additional information may further be provided if the
agent 32 is idle, is performing a task and/or has failed to
complete a task.
[0078] As shown in box 520, the agent 32 may commence an asset
discovery and/or inventory process to collect asset information for
each client 20. This information may be reported to the RSS 22, OSS
24, MS 12 and/or database 28. The agent 32 may conduct the asset
inventory process on its own or based on an instruction received
from RSS 22, OSS 24, or the like. In one example, an agent may
generate and transmit a request for instructions to a server, as
shown in box 530. In response, the server may generate one or more
instructions to the agent, as shown in box 540. The asset data may
include end-user computer hardware and software characteristics,
such as memory size, processor type and speed, resident software,
software versions, and the like. The instructions that are received
from the server may include instructions to, for example, install
software, remove software, repair software, and/or any combination
thereof. The instructions may be based on, for example, the asset
data collected.
[0079] As shown in boxes 550 and 560, the agent may process the
appropriate instruction(s) from the server and/or may transmit an
acknowledgement to indicate that the instruction was processed to
the server, for example.
[0080] In embodiments of the present invention, agent 32 may
conduct a polling routine in which the agent 32 may periodically
poll the OSS 24 via an RSS 22 to check, for example, for programs
or its entitlement. The polling may be accomplished using, for
example, a hypertext transfer protocol (HTTP) GET command sent to
the OSS 24 via the RSS 22 from the client 20. The command may
provide provides a device identifier and/or a user login identifier
to the OSS 24. The polling period may be parameterized and can be
set by a user at the console 30. The period may be set to poll
every few minutes, hours, days, etc. The agent 32 may begin a
polling routine based on a predetermined event such as of a user
manually installs a program and/or the managed client 20 is
otherwise modified, for example.
[0081] As asset information is collected globally (perhaps over a
period of several weeks), a validation routine may run by the OSS
24. This routine may compare the list of supported hardware and
minimum computer requirements to the individual asset inventory
information gathered by the agents 32 about the clients 20. As a
result of this comparison, the agent 32 may identify software
and/or hardware that maybe needed. In the case of software, the
software may be downloaded as described herein. If hardware is
missing, the RSS 22 and/or OSS 24 may determine whether the
hardware exists and if it does, may attempt to run the appropriate
utility to install the hardware in client 20. If the hardware does
not exist, a notice such as via e-mail may be sent to an
administrator and/or user to indicate that such hardware is needed.
As new hardware and/or software is installed, the DB 28 and/or 18
may be updated.
[0082] In response to one or more poll, the agent 32 may receive a
response indicating, for example, a location of its entitlement.
The response may include a Java.RTM. wrapper having a script that
gives a path as to where, for example, a Microsoft Windows.RTM.
Installer (MSI) file may reside on the RSS 22. The Java.RTM.
wrapper may be in XML and may contain JavaScript. The client 20 may
then download the MSI from the RSS 22, and may begin down loading
the entitlement.
[0083] Embodiments of the present invention may provide for a
method, system and apparatus that may repair an existing
application on the client 20 through a process known as
self-healing whereby the application repairs its own defects, it
may install entitled applications and/or scripts, it may uninstall
applications and/or it may provide an offer icon.
[0084] Embodiments of the present invention describe an ESD system
which may provide "state management" or software operations
management. In one embodiment, the invention provides for
management of software products that are installed on a system or
device, and the versions of those software products, conform to
"approved" and optimal operating parameters. State management is
desirable for a number of reasons, including but not limited to,
system stability, standardization, accurate reporting, data and
asset management, efficient software distribution and migration,
information technology, project scheduling and license
management.
[0085] Because the number of permutations of different versions of
the multiplicity of software products is practically infinite, and
because these software products commonly cause conflicts in common
components that can render the system unusable causing significant
barriers to systems integration and software distribution, it is
advantageous from a system stability perspective to limit the
amount of diversity in computer systems as much as possible.
[0086] In an embodiment of the invention, by controlling the number
of different versions of software in a company's environment or
customer base, the support staff can more easily test the common
scenarios, proactively prevent user problems and react more
effectively and efficiently to user dilemmas. For example, in an
environment having a limited versions of tested software products,
the occurrence of software conflicts may be significantly reduced,
and thereby the number of unique configurations that have to be
supported may also be reduced. Among other benefits, this leads to
better monitoring, tracking, support and/or service to end
users.
[0087] In addition to system stability, embodiments of the present
invention may also provide monitoring of the number of versions of
a given software product for license optimization and/or
management. If a corporation has a software with "bulk" or
"site-wide" licenses which may cover only one version of the
software, it is desirable to track software so that only the
licensed versions are installed in their environment for license
compliance reasons. It may also be desirable for both the
manufacturer and purchaser to track that they have too many or too
few of any type of software license. Embodiments of the present
invention provide many of the various features as described
herein.
[0088] It is recognized that embodiments of the invention may
include, for example, components such as processors, computer
readable memories, data ports or other interfaces, network ports or
other interfaces, data buses and/or other hardware and/or software
components (all not shown). The data ports or other interfaces may
permit the various devices to communicate with other devices and/or
with the transit network and/or information info-structure. The
data buses may connect the processor, the computer readable memory,
the data port or other interface and/or the network port or other
interface and may permit communications between the various
components in embodiments of the invention.
[0089] Several embodiments of the present invention are
specifically illustrated and/or described herein. However, it will
be appreciated that modifications and variations of the present
invention are covered by the above teachings and within the purview
of the appended claims without departing from the spirit and
intended scope of the invention.
* * * * *