Patent Application
20060047859
The present invention relates generally to computer systems, and, more particularly to management of device(s) installed on computer systems.
In conventional computer systems, when a device (e.g., plug and play device) is discovered by the operating system, the operating system (e.g., a plug and play manager) automatically attempts device installation without user intervention. If the operating system provides default support for the device, or there is already a matching third-party driver for the device present on the computer system, the device will be automatically installed and immediately available to the user(s) of the computer system.
There are many scenarios with conventional computer system(s) where the large number and wide variety of devices, as well as the ease of installation that operating systems provide, is a liability to the administrators of those computer systems. Device installation has been very successful at making any device that can be supported by the computer system work when discovered, at the expense of not providing adequate support for system administrators to control that experience.
This mechanism effectively allows any user with physical access to the computer system to plug in a wide range of hardware devices and access them without requiring special administrative privileges. However, in many scenarios, this behavior can be undesirable.
The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.
The present invention provides for systems and methods facilitating entity management. In accordance with an aspect of the present invention, a trusted and/or privileged user is given control over entities (e.g., device(s)) that can be installed on a computer system(s), and/or how the installation can be performed. Thus, a trusted and/or privileged user can specify device installation policy that prevents the computer system from automatically installing a driver for device(s) (e.g., even when an appropriate driver is available to be installed). For example, this policy can be applied to driver(s) for substantially all new devices and/or only a subset of devices. Optionally, policy can also control how device driver(s) that are already installed are made available to the computer system.
Accordingly, aspects of the present invention provide for definition of a policy (e.g., by a trusted user and/or privileged user, such as an system administrator) that:
In accordance with an aspect of the present invention, an entity management system is provided. The system includes a device installation component having an installation component, and, a policy data store.
The installation component controls installation of device driver(s) based, at least in part, upon information stored in the policy data store. In one example, the policy data store includes information associated with device(s) that are permitted to be installed on the computer system (e.g., permitted list) and/or specifies a set of criteria for device(s) that dynamically establishes membership in a permitted list. In another example, the policy data store includes information associated with device(s) that are not permitted to be installed on the computer system (e.g., restricted list) and/or specifies a set of criteria for device(s) that dynamically establishes membership in a restricted list.
For example, when a device is discovered by the system, the installation component can receive information associated with the device (e.g., device descriptor and/or identifier). Based, at least in part, upon the information received from the device, the installation component can review information stored in the policy data store to determine whether the installation should proceed. If the device is permitted to be installed (e.g., specifically included on permitted device list and/or not included on restricted device list), installation of a device driver associated with the device continues; otherwise, a device driver associated with the device is not installed (e.g., installation aborts). Device installation policy can further be based, for example, upon device attribute(s) and/or property(ies) such as, but not limited to, removable device capability, category and/or class of the driver to be installed, and/or restricted device extensibility point.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.
As used in this application, the terms “component,” “handler,” “model,” “system,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). Computer components can be stored, for example, on computer readable media including, but not limited to, an ASIC (application specific integrated circuit), CD (compact disc), DVD (digital video disk), ROM (read only memory), floppy disk, hard disk, EEPROM (electrically erasable programmable read only memory) and secure digital memory device in accordance with the present invention.
As used in this application “entity” includes physical, logical and/or virtual device(s) (e.g., hardware, firmware and/or software). Additionally, “trusted context device installation” refers to device installation performed automatically by the operating system (e.g., plug and play service). Trusted context device installation is possible when a new device matches against a driver package that is available to the system, is sufficiently trusted, and can be installed for the current device with no user-interaction. “System administrator” refers to an entity that defines policy on the system. A “trusted and/or privileged user” is an entity that is entitled to install device(s) and/or driver(s) on the system based. Finally, “user-initiated device installation” refers to device installation initiated in the context of an interactive user who is permitted to install device(s) (e.g., trusted and/or privileged user). User-initiated device installation is initiated automatically when the new device cannot be installed using the trusted-context installation mechanism. User-initiated device installation can also be initiated directly by any trusted and/or privileged user permitted to install device(s) on the system.
As noted previously, there are many scenarios with conventional computer system(s) where the large number and wide variety of devices, as well as the ease of installation that operating systems provide, is a liability to the administrators of those computer systems. In conventional computer systems, when a device (e.g., plug and play device) is discovered by the operating system (e.g., a device installation component) automatically attempts stand-alone device installation. If the operating system provides default support for the device, or there is already a matching third-party driver for the device present on the computer system, the device will be automatically installed and immediately available to user(s) of the computer system.
This mechanism effectively allows any user with physical access to the computer system to plug in a wide range of hardware devices and access it without requiring any special privileges. In many scenarios, this behavior can be undesirable.
The present invention allows for a system administrator to define system policy that restricts certain device(s) from being installed, even if the operating system is otherwise capable of providing support for the device. Alternatively, a system administrator is able to specify that only certain device(s) can be installed in the computer system.
Referring to
In conventional systems, when a new device is added to the operating system, the operating system (e.g., a device installation component) first attempts to install the device without user intervention, using any device drivers that are already available on the computer system which describe themselves as a “match” for that device. If no matching driver(s) are present, the operating system (e.g., device installation component) prompts the current user to provide the device driver(s) at that time, and completes the installation.
This behavior can be acceptable, and, even preferred, in a standalone environment (e.g., home environment). However, the ability to indiscriminately install device(s) can be undesirable in controlled computing environments, where the system or domain administrator(s) desire to restrict the ability for device(s) to be dynamically introduced to the computer system. For example, in a bank, it can be highly undesirable for a user to be able to introduce removable storage device(s) and/or printer(s) to the computer system, which could be used to transfer sensitive financial information off of the computer system. With conventional computer system(s), system administrators are generally unable to disable the operating system's behavior of aggressively installing new device(s) that can be supported by the computer system. Instead, system administrator(s) have resorted to haphazard and unsupported approaches, such as modifying the supported configuration to remove unwanted device driver(s).
The system 100 thus allows for privileged user control (e.g., by a trusted user) over which device(s), if any, are permitted to be installed on a computer system. Optionally, a system administrator can control how the installation can be performed. Thus, the system 100 addresses scenario(s) where a system administrator desires precise control over the set of device(s) that will be supported within their environment, regardless of the level of support that could potentially be provided by the computer system.
In one example, a system administrator can specify machine policy that prevents the computer system from automatically installing device(s), even when an appropriate driver is available to be installed. For example, this policy can be applied to substantially all new device(s) and/or only a subset of device(s). Optionally, policy can also control how devices that are already installed are made available to the computer system.
In accordance with an aspect of the present invention, the installation component 120 controls installation of device driver(s) based, at least in part, upon information stored in the policy data store 130. In one example, the policy data store 130 includes information associated with device(s) that are permitted to be installed on the computer system (e.g., permitted list) and/or specifies a set of criteria for device(s) that dynamically establishes membership in a permitted list. In another example, the policy data store 130 includes information associated with device(s) that are not permitted to be installed on the computer system (e.g., restricted list) and/or specifies a set of criteria for device(s) that dynamically establishes membership in a restricted list.
For example, when a device 140 is added to the system, the installation component 120 can receive information associated with the device 140 (e.g., device descriptor and/or identifier). Based, at least in part, upon the information received from the device 140, the installation component 120 can review information stored in the policy data store 130 to determine whether the installation should proceed. If the device 140 is permitted to be installed (e.g., specifically included on permitted device list and/or not included on restricted device list), installation of a device driver associated with the device 140 continues; otherwise, a device driver associated with the device 140 is not installed (e.g., installation fails).
Device Attribute(s) and/or Property(ies)
In one example, the system 100 supports the use of different device attribute(s) and/or properties to describe device(s) affected by installation policy. For each attribute and/or property used to describe a device, separate restricted list and/or permitted list policy setting(s) can be stored in the policy data store 130.
Device(s) 140 can be explicitly allowed or restricted from being installed based on a set of hardware identifier(s) and/or compatible identifier(s) that have been reported for the device 140 by an enumerating bus driver. For example:
In one example, when checking the corresponding permitted list and restricted list entries, preference is given to the permitted list settings. If a device is found to be a match in the permitted list of allowed devices, installation is allowed, regardless of whether the device also exists in the restricted list setting of restricted devices. In another example, the restricted list entries are given preference over the permitted list entries.
Policy can further be based, at least in part, upon attribute(s) and/or property(ies) of device(s) 140.
Removable Device Capability
For example, device(s) 140 can be explicitly allowed or restricted from being installed based on whether the “removable” device capability has been reported for the device 140 by the enumerating bus driver at the time the device 140 is to be installed and/or upgraded (e.g., NolnstallRemovableDevices=[true|false]). In one example, if the device is not restricted, any remaining policy setting(s) are checked.
Device Setup Class and/or Category
In another example, device(s) can be explicitly allowed and/or restricted from being installed based on the device setup class and/or category of an installation package that contains the driver node which best matches the device, as determined, for example, by a plug and play driver ranking algorithm. If a match is found, the appropriate policy is applied. If no match is found, other policy settings are continued to be checked.
As described previously, in one example, the permitted list setting for allowed device setup classes is checked for a match before the restricted list is consulted. In this example, if a device setup class is explicitly allowed, it cannot be rejected.
Restricted Device Extensibility Point
In addition to restricting devices based on their characteristics, the system 100 can support the ability to restrict devices based on their location in a plug and play device tree. A property can be set for specific device instances in the tree that would restrict any child devices from being installed.
Thus, installation of a new device can be restricted or allowed based on its location in the device tree. For example, this mechanism can be used to restrict only the installation of new devices that are enumerated from a bus device that is known to be unsecured, yet allow installation of new devices attached to other bus devices.
This aspect of the present invention facilitates system flexibility. For example, restricting the installation of all new devices can be an unnecessary support issue when replacing critical devices that are attached to bus devices that are known to be contained entirely within a locked machine chassis. If a system administrator can secure physical access to an internal bus device, it is unnecessary for the operating system to prevent installation of any new devices enumerated from it. On the same computer system however, there can exist some externally accessible ports, for example, but not limited to, USB or 1394 ports capable of enumerating unsupported devices, such as a removable disk. Thus, in accordance with an aspect of the present invention, a system administrator can restrict the enumeration of any disk device(s) from the externally available USB and or 1394 bus devices while still allowing for the automatic installation of replacement or additional internal hard disks enumerated from a new or existing internal PCI SCSI adapter device.
Other Device Installation Rules
Those skilled in the art will recognize that other setting(s), property(ies), and/or attribute(s) of a device 140 and/or setting(s), property(ies) and/or attribute(s) of the installation package used to install a device 140 can be employed by policy(ies) of the system 100. For example, restrictions may be enforced against installing a device 140 for which the best matching installation package would set a specific property value for the device. In another example, the device driver manufacturer is employed as a restriction on installation of the device.
Exemplary Scenarios
Lock Down
In one example, a system administrator is able to define a static set of installed device(s) on a computer system via the system 100. Once the computer system has been installed, a system administrator can “lock down” the computer system such that no additional device(s) can be installed by specifying in the policy data store 130 that no additional device(s) are permitted to be installed. Thus, when a new device is discovered, the system 100 determines that the policy stores in the policy data store 130 prevents additional device(s) from being installed, thus the device installation component 110 does not attempt to install the device automatically, does not allow any user to install the device, and further ensures that the device is never started. In a financial institution, for example, users would not be able to install any devices that could potentially allow data to be transferred from the computer system, such as storage devices or printers.
Set of Supported or Unsupported Device Types
A system administrator can decide which types of devices are allowed to be installed and/or are excluded from being installed on managed desktops. When any new device is discovered, the system 100 evaluates whether the device is allowed (or restricted), and attempts (or denies) installation accordingly. For example, while a supported mouse device can be installed on a corporate workstation, game control devices can be explicitly disallowed.
Configurable Installation Behavior
Policy can determine whether an interactive user should be prompted to install new device(s) that could not be installed automatically by the system, or whether the system should leave those devices in an un-configured state until a user that is permitted to install device(s) initiates their installation. For example, if a system administrator generally intends to manually initiate installation of new devices, they can disable the behavior to automatically prompt interactive users to install the new devices.
Privileged User Approved Installation
In this scenario, although substantially all devices that can potentially be supported by the computer system are permitted to be installed, the installation is performed by a user that is permitted to install device(s). The system does not automatically attempt to install any new devices itself. For example, although an operating system may provide in-box support for a user's digital camera, a trusted and/or privileged user is required to install it.
Those skilled in the art will recognize that the scenarios described above are merely examples of policy(ies) can be implemented in accordance with aspects of the present invention. Further, the scenarios described above can be combined to enable more complex scenarios. Separate permitted and restricted lists may be maintained for trusted context and user-initiated device installation scenarios such that the policies for device sets and installation behavior (described above) may be combined to enable automatic installation by the system of some devices only, permit trusted and/or privileged users to install all other devices, yet not automatically prompt them when any such devices require installation.
For example, on a server system managed by an IT Administrator, a new USB mouse or keyboard devices can be permitted to be installed automatically by the computer system (e.g., based on the device setup class and/or category membership of the best available driver match), even though a trusted and/or privileged user is required to install all new disk devices (e.g., based on the presence of the “gendisk” device id in the device Hardware or Compatible Ids properties). Even though a trusted and/or privileged user is permitted to interactively install a new disk device, no user would be prompted when such a device was discovered if the defined policy has disabled such prompts. The trusted and/or privileged user thus manually initiates the installation of any new disk device.
It is to be appreciated that the system 100, the device installation component 110, the installation component 120, the policy data store 130 and/or the device(s) 140 can be computer components as that term is defined herein.
Turning to
The administration component 150 facilitates population of the policy data store 130. For example, the administration component 150 can be employed by a user with sufficient privileges to store information associated with device(s) that are permitted to be installed on the computer system and/or that are not permitted to be installed on the computer system. Thus, in one example, the system 200 allows a system administrator to define a computer system policy that restricts certain device(s) from being installed, even if the operating system (e.g., device installation component 110) is otherwise capable of providing support for the device.
For example, the effective policy which determines whether a given device 140 will be installed can be based on a set of defined rules. In one example, the policy includes a single policy setting that allows for trusted context device installation to be enabled or disabled for all devices: Trusted Context Installation Enabled=[true|false]. In another example, a separate policy can allow user-initiated device installation to be enabled or disabled for all devices: User-initiated Installation Enabled=[true|false]. For example, each setting can be controlled independently, such that both user-initiated and trusted context device installation can be disabled to prevent the installation or upgrade of any device(s).
If user-initiated device installation is permitted, a separate setting can be used to determine whether interactive user(s) will automatically be prompted to initiate user-initiated installation of devices that have not been restricted, and for which a matching device driver was not found, for example: Prompt for User-initiated Installation=[true|false]. In this example, if interactive users are not to be prompted to complete the installation, the device will remain in its initial “not configured” state.
It is to be appreciated that the system 200 and/or the administration component 150 can be computer components as that term is defined herein.
Distributed Environment
Referring next to
The remote administration component 310 facilitates remote population of the policy data store 130. The remote administration component 310 can be coupled to the computer system, for example, via the Internet, an intranet and/or a network connection. The remote administration component 310 can be employed by a system administrator to store information associated with device(s) that are permitted to be installed on a computer system and/or that are not permitted to be installed on the computer system. Thus, in one example, the system 300 allows a system administrator to define a computer system policy that restricts certain device(s) from being installed, even if the operating system (e.g., device installation component 110) is otherwise capable of providing support for the device.
For example, an IT manager can create one or more policies for computer systems installed on a corporate network via the remote administration component 310. The IT manager can then store the policy(ies) in the policy data store 130 of one, some and/or substantially all of the individual computer systems that comprise the corporate network. In this manner, the IT manager is able to remotely administer device installation policy for individual computer system(s).
It is to be appreciated that the system 300 and/or the remote administration component 310 can be computer components as that term is defined herein.
Device Availability Policy
Turning to
Information stored in the availability policy data store 430 can control how device(s) that are already installed are made available to the computer system. Thus, a policy can be set that prevents device(s) 440 from being recognized by the computer system altogether, regardless of whether they have already been installed or not. In one example, this policy can be applied to substantially any device 440 reported to the computer system. In this example, device availability policy can be maintained using separate, but similar setting(s) from those described above for device installation policy.
For example, device(s) 440 can be refused by the system based on their hardware identifier(s) and/or compatible identifier(s):
When a device 440 is reported to the system, the entity availability component 420 can check existing device availability setting(s) against the attribute(s) of the device 440 that can be determined before the device 440 is to be started. If device availability policy settings reject the device 440, it is not made available to the computer system (e.g., and it is not started). For example, this can be accomplished by giving the device 440 a problem code which prevents it from being started, and cannot be programmatically cleared (e.g., by any user).
Even though some devices have been previously installed on the computer system, policy can be used to describe a set of device(s) that the system 400 should not make available for use (e.g., start). For example, even though an external USB mass-storage device has previously been installed for use on a computer system, current availability policy may indicate that no USB mass-storage device(s) should be started on the computer system. The device will be given a problem by the entity availability component 420 that prevents the device from starting being started.
Optionally, device(s) 440 can be refused if enumerated off of a specific parent device 440. To accomplish this, a property can be associated with a specific instance of an installed device 440 that indicates that the system 400 should not start any child device(s) 440 attached to it. For example:
Those skilled in the art will recognize that the information stored in the availability policy data store 430 can be based, at least in part, upon information stored by a system administrator (e.g., administration component) and/or remotely by a system administrator (e.g., remote administration component).
It is to be appreciated that the system 400, the entity availability component 420, the availability policy data store 430 and/or the device(s) 440 can be computer components as that term is defined herein.
Turning briefly to
The invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more components. Generally, program modules include routines, programs, objects, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.
Referring to
Next, turning to
At 640, a determination is made as to whether there are any restriction(s) on device availability. If the determination at 640 is NO, at 650, the device is allowed to be available (e.g., to user(s)), and, no further processing occurs. If the determination at 640 is YES, at 660, the device is made not available (e.g., by giving the device a problem code which prevents it from being started, and cannot be programmatically cleared).
Turning next to
At 706, a determination is made as to whether the device is on a permitted list. If the determination at 706 is NO, at 708, a determination is made as to whether the device is on a restricted list. If the determination at 708 is YES, processing continues at 710. If the determination at 708 is NO, processing continues at 712.
If the determination at 706 is YES, at 712, the device capabilities are reported. At 714, a determination is made as to whether the device is “removable”. If the determination at 714 is YES, at 716, a determination is made as to whether “removable” device(s) are restricted. If the determination at 716 is YES, processing continues at 710. If the determination at 716 is NO, processing continues at 718.
If the determination at 714 is NO, at 718, a determination is made as to whether children of the parent device are restricted. If the determination at 718 is YES, processing continues at 710. If the determination at 718 is NO, at 720, a determination is made as to whether the device is already installed. If the determination at 720 is YES, processing continues at 722.
If the determination at 720 is NO, at 724, a determination is made as to whether trusted context installation is allowed. If the determination at 724 is NO, processing continues at 726. If the determination at 724 is YES, at 728, trusted context installation is attempted.
Next, at 730, a determination is made as to whether the installation is prevented by policy. If the determination at 730 is YES, processing continues at 710. If the determination at 730 is NO, at 732, a determination is made as to whether the installation was successful. If the determination at 732 is YES processing continues at 722.
If the determination at 732 is NO, at 726, a user initiates installation. At 734, determination is made as to whether user-initiated installation is allowed. If the determination at 734 is NO, processing continues at 710. If the determination at 734 is YES, at 736, user-initiated installation is attempted.
At 740, a determination is made as to whether installation is prevented by policy. If the determination at 740 is YES, processing continues at 710. If the determination at 740 is NO, at 742, a determination is made as to whether installation was successful. If the determination at 742 is YES, at 722, the device is installed, and no further processing occurs. If the determination at 742 is NO, at 710, the device is not installed, and, no further processing occurs.
In order to provide additional context for various aspects of the present invention,
With reference to
The system bus 1018 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, an 8-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 1016 includes volatile memory 1020 and nonvolatile memory 1022. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1012, such as during start-up, is stored in nonvolatile memory 1022. By way of illustration, and not limitation, nonvolatile memory 1022 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 1020 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 1012 also includes removable/nonremovable, volatile/nonvolatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 1012 through input device(s) 1036. Input devices 1036 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1014 through the system bus 1018 via interface port(s) 1038. Interface port(s) 1038 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1040 use some of the same type of ports as input device(s) 1036. Thus, for example, a USB port may be used to provide input to computer 1012, and to output information from computer 1012 to an output device 1040. Output adapter 1042 is provided to illustrate that there are some output devices 1040 like monitors, speakers, and printers among other output devices 1040 that require special adapters. The output adapters 1042 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1040 and the system bus 1018. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1044.
Computer 1012 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1044. The remote computer(s) 1044 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1012. For purposes of brevity, only a memory storage device 1046 is illustrated with remote computer(s) 1044. Remote computer(s) 1044 is logically connected to computer 1012 through a network interface 1048 and then physically connected via communication connection 1050. Network interface 1048 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 1050 refers to the hardware/software employed to connect the network interface 1048 to the bus 1018. While communication connection 1050 is shown for illustrative clarity inside computer 1012, it can also be external to computer 1012. The hardware/software necessary for connection to the network interface 1048 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
