Patent Application
20060253617
The disclosed invention relates generally to the field of software component replacement and specifically to systems and methods for managing replacement of software components.
Modern computing systems typically include with a number of peripheral components such as printers, video displays, audio and video components, and networking devices, among others. In order to operate with these peripherals, the computing system usually employs a device driver that provides a predefined set of functions. These functions generally include means by which the computing system can communicate with the peripheral device in addition to a variety of user-selectable functions or features of the peripheral device.
Many types of peripheral devices employ standardized operational protocols or include common hardware components. Even so, vendors usually have both the ability and desire to customize their peripheral devices. Accordingly, device drivers are usually provided by a manufacturer or distributor of a specific peripheral device. Users, however, have the ability to replace an original driver with a replacement version. The replacement version may be released by a vendor to correct defects in a pervious version, to provide additional functionality, or to interoperate better with various other system components, among other reasons. Replacement drivers can also be provided by third parties.
Replacing device drivers can sometimes have unintended consequences. For example, a replacement device driver may not provide all the functionality of an original driver. A replacement device driver may work well for the peripheral device for which it was designed but may interfere with the functioning of drivers of other devices or other components. These consequences, among others, can make troubleshooting computing problems exceptionally difficult. Current software upgrade or replacement systems do not adequately address these consequences.
The following presents a simplified summary in order to provide a basic understanding. This summary is not an extensive overview. It is not intended to identify key or 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 a more detailed description that is presented later. Additionally, section headings used herein are provided merely for convenience and should not be taken as limiting in any way.
In accordance with one aspect of the invention, a software component such as a device driver includes an upgrade code. The upgrade code serves as an indicator of functions supported by the device driver and also serves as an indicator of ability of the device driver to replace a previously installed device driver. The use of an upgrade code also permits creation and enforcement of software component replacement policies.
In accordance with another aspect of the invention, a software component such as a device driver includes one or more compatible upgrade codecompatible upgrade codes. A compatible upgrade codecompatible upgrade code serves as an indicator of an ability of a software component to replace or function along with another software component. Use of a compatible upgrade codecompatible upgrade code permits creation and enforcement of software component replacement policies at a finer level of control than simply using an upgrade code or can simply serve as an additional or alternative component for creating or enforcing such policies.
Yet another aspect of the invention involves the inclusion of an installation code in a software component such as a device driver. An installation code can serve as an indicator that an associated component should always be installed or that further permission for installation should or must be obtained. Use of an installation code can allow mandatory installation policies to be created and enforced.
Still another aspect of the invention involves the inclusion of a digital signature with a software component such as a device driver. By including such a signature and basing the signature at least in part upon an upgrade code, a compatible upgrade codecompatible upgrade code, an installation code, or a combination of one or more of the foregoing, a source of the device driver can be verified as well as the accuracy of any included codes. The use of such a signature allows for further policy creation and enforcement, such as only installing verified components from trusted sources.
A further aspect of the invention involves a system for locating, obtaining, and installing software components such as device drivers. A computing system can send descriptive information about its device drivers to a repository of device drivers. The repository can then identify device drivers that can be used to upgrade currently installed drivers on the computing system. The computing system can then download and install the updated device drivers automatically or with some user intervention if desired. Policies relating to automatically updating software components can be created and enforced.
To the accomplishment of the foregoing and related ends, the invention then, comprises the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative aspects of the invention. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed. The subject invention is intended to include all such aspects and their equivalents. Other objects, advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
The subject invention relates to systems and methods to facilitate replacement of software components. As used in this application, the terms “component,” “system,” “module,” and the like are intended to refer to a computer-related entity, either hardware, software (for example, in execution), and/or firmware. For example, a component can be a process running on a processor, a processor, an object, an executable, a program, and/or a computer. Also, both an application running on a server and the server can be components. One or more components can reside within a process and a component can be localized on one computer and/or distributed between two or more computers.
The subject invention is 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 subject invention. It may be evident, however, that the subject 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 subject invention. Additionally, although specific examples set forth may use terminology that is consistent with client/server architectures or may even be examples of client/server implementations, skilled artisans will appreciate that the roles of client and server may be reversed, that the subject invention is not limited to client/server architectures and may be readily adapted for use in other architectures, specifically including peer-to-peer (P2P) architectures, without departing from the spirit or scope of the invention. Further, it should be noted that although specific examples presented herein include or reference specific components such as device drivers, the invention is not limited to those specific components or device drivers and can be employed in other contexts as well.
An operating platform layer 120 interacts with, and executes upon, the hardware layer 110. The operating platform layer 120 can be a general-purpose operating system, a specialized operating system, or another component or components that provide a sufficient operating environment for other components of the system. Specifically, the operating platform layer 120 can include a kernel to provide core operating system functions such as file and memory management as well as other modules that cooperate with the kernel to provide support for core operating system functions or services upon which higher-level components depend.
A device driver 130 can interact with the hardware layer 110, the operating platform 120, and with a peripheral device 140. The peripheral device 140 can be a video display; a printer; a network interface; an audio device such as a sound card, a speaker system, or a personal music player (for example, an MP3 player); a video device such as a digital camera or a motion picture camcorder, a personal digital assistant (PDA), or another device. The device driver 130 can provide communication services and other desired functions or services so that the operating platform 120 or the hardware layer 110 can interact with the peripheral device to access features or functions of that device. It should be appreciated that although the device driver 130 is pictured as having direct connections to both the operating platform 120 and the hardware platform 110, such connections may differ according to a specific implementation.
The device driver 130 includes an upgrade code 150. The upgrade code can take a variety of forms, such as an alphanumeric indicator, a binary code, a file name, or another suitable code. The upgrade code can be a simple numeric value or a complex encoding with fields that represent specific aspects or features of the associated device driver 130. For example, a vendor may use the value “111” for its upgrade code for a specific device driver. When the vendor releases an updated driver for that peripheral device, the updated driver will also have an upgrade code of “111,” indicating that the updated driver is intended to replace the older driver with the same upgrade code.
A second example involves encoding additional information into the upgrade code. For instance, if a vendor applies an upgrade code ABC-111-222-333 to its device driver, the upgrade code can be broken down into a group of fields with each individual field representing certain information about the device driver. The first field including “ABC” can represent that the device driver is for ABC device. ABC device can be a specific type of device, a specific model, or a specific revision of a model. Each of the next two fields, “111” and “222” can represent certain functions that are supported by the device driver. The final field “333” can be a revision date, build number, or other desired information. It should be noted that these examples are not limiting and that other types of information can be encoded into the upgrade code. Additionally, various other formats, specifically including, but not limited to, binary formats can be used.
In use, the upgrade code 210 can be mapped to a specific feature set. In so doing, the upgrade code 210 serves as a descriptor of the functionality provided by the driver module 200. A later-released driver module having an upgrade code that is the same as an upgrade code of an older driver can be interpreted as having the same functionality as the older driver. If desired, the upgrade code in a later-released driver module can be interpreted as representing that the later-released driver provides at least the functionality of the older driver. In this case, vendors can add functionality to later-released drivers without changing upgrade codes and while still preserving backward compatibility. By adopting and adhering to such conventions, vendors and other developers can effectively create and enforce policies relating to the upgrading or replacement of driver modules or other components.
For example, a specific vendor may sell a specific computer system with a set of preinstalled device drivers that the vendor has tested with its particular system configuration. By using an upgrade code and only permitting upgrades to drivers with corresponding codes, a vendor can mitigate the risk that any system problems encountered are caused by incompatible or defective software drivers that replaced originally installed drivers. In this way, diagnosis of system problems can be greatly streamlined because the vendor can be confident that device drivers installed on the system are those that the vendor has tested and approved for use with its system configuration.
Use of upgrade codes can also enable a vendor to create device driver families. For instance, a vendor may fork a codebase of a device driver to provide differing functionality for different markets, such as a business enterprise market and a gaming market. The upgrade code for such specialized device drivers can be altered to signify that the specialized driver has been forked from a parent. Possible ways of altering the upgrade code include incrementing a value or by adding a prefix or suffix. It should also be recognized that a different upgrade code can be used for the specialized device driver and associations maintained among upgrade codes for device drivers in the same family.
The upgrade code can also be used to indicate that device drivers on different forks or from different families have been merged into a single new driver. For example, a vendor may make a variety of peripheral devices such as scanners, printers, and facsimile machines. Each peripheral device can have its own driver with an associated upgrade code. If the vendor decides to create a new peripheral device that combines the functions of all three preexisting devices, the vendor can create a new device driver for the combined device that is a combination of the preexisting device drivers. The combined driver can have its own upgrade code. The vendor can then decide to use the combined driver for all its peripheral devices even though some devices will not use all functions of the combined driver. In this case, the upgrade code for the combined driver will signify that the combined driver can replace a previous driver for one of the single-purpose devices.
Turning now to
Compatible upgrade codes 320, 330, 340 provide a means to obtain and exert a finer level of control over component replacement. For example, the primary upgrade code 310 can be referenced to determine whether a replacement device driver is compatible with a previously released version of that device driver. Possible interpretations of this compatibility check are a baseline guarantee of continued functionality by the replacement driver and/or a representation that coding errors present in a prior version have been repaired in the replacement driver. The compatible upgrade codes 320, 330, 340 can then signify specific drivers for which the replacement driver can be used instead. Drivers represented by the compatible upgrade codes 320, 330, 340 can be device drivers that previously have been forked into specialized families, device drivers that are previously released versions, or even device drivers from other vendors or third parties, among others.
The compatible upgrade codes 320, 330, 340 can be used in a variety of comparisons to administer or enforce a variety of policies. One possible implementation involves comparing a compatible upgrade code, such as one of the compatible upgrade codes 320, 330, 340, of a currently-installed driver with a primary upgrade code, such as the primary upgrade code 310, of a new driver to determine whether the new driver can be used to upgrade or replace the currently-installed driver. This implementation can help ensure that only compatible drivers are used to upgrade preexisting components.
When the installation code is set to another value, a conservative policy, such as either prompting for permission to install or simply not installing can be followed. Here, as with other prompts, a user can be warned of possible incompatibilities or feature losses associated with the proposed installation as well as being given an opportunity to abort or continue the installation. Additionally or alternatively, the installation code 450 can be associated with an upgrade code and/or one or more compatible upgrade codes in a data store external to the driver package 400 itself. Such a data store can be local or on a remote system. In that manner, the value of the installation code 450 can be obtained without having to trust that the installation code 450 of the driver package 400 is correct.
The computing system 610 is connected to an update server 650. The update server 650 accesses an update driver data store 660 that contains a set of drivers that are available to be installed. In operation, the update manager 620 can use information about the driver set 640 from the local driver data store 630 to create an update request that can be sent to the update server 650. The update server 650 can access the update driver data store 660 to determine whether a replacement driver is available for a currently installed driver on the computing system 610. The update server 650 can send a located replacement driver to the computing system 610. The update manager can use an upgrade code, a compatible upgrade code, an installation code, or a signature, alone or in combination with other components associated with the replacement driver to select an appropriate policy from the policy data store 645 and apply that policy.
With reference to
If the determination made at decision block 715 is affirmative, processing continues to decision block 745. At decision block 745 a determination is made whether the new or replacement driver has an upgrade code. If no, processing continues to process block 725 where a prompt for verification or permission is created. Processing continues to decision block 730 where a determination is made whether installation of the new driver has been verified or otherwise authorized. If this determination is yes, processing continues to process block 735. If the determination made at decision block 730 is no, processing terminates at END block 740.
If the determination made at decision block 745 is yes, processing continues to decision block 750. At decision block 750, a check is performed to determine whether the upgrade codes of both the currently installed device driver and the new or replacement device driver are compatible. If no, processing continues to process block 725 where a prompt for verification or permission is created. If yes, execution continues at process block 755 where installation of the new or replacement device driver occurs. Processing then continues at process block 760 where user-selectable settings from the now-replaced driver are imported by the new or replacement driver. Processing then terminates at END block 740.
At process block 840 the replacement component is installed to replace the originally installed component. Processing continues to process block 850 where settings for the original component are imported by the replacement component. Processing then terminates at END block 860. If the determination made at either decision block 820 or decision block 830 is negative, processing also concludes at END block 860.
Those of ordinary skill in the art will appreciate that the processing flow depicted in
A second policy of requiring compatible upgrade codes to match is also applied here. If the compatible upgrade code of a replacement component does not indicate that the replacement component is compatible with a component to be replaced, installation will not proceed. It should be noted that in either or both of the above examples, a user may be presented with an option to override the applied policies and thereby allow installation to proceed despite a violation of the policy in place.
A third policy is that of importing settings of an original component by the replacing component. In the example illustrated in
The use of a signature can help to verify that the replacement software component originated from an authentic or trusted source and that the contents of the replacement software component both are what the source purports them to be and that the replacement software component has not been tampered with or otherwise altered during transit between the source and a recipient. Use of a signature can also be triggered by an upgrade code. For example, if a non-public or a special upgrade code is used by, or assigned to a specific vendor, that upgrade code can trigger a signature check to enforce a software upgrade policy. In this instance, if an upgrade code signifies that a replacement driver can be used to upgrade a preexisting driver from a specific vendor, the signature check can be used to verify that the replacement diver originated from that vendor and is not counterfeit. A policy of only using upgrades from a specific vendor can be applied and enforced by refusing to install components that do not pass both a compatibility check and a signature check.
If the signature is verified at decision block 920, processing continues to decision block 930 where a determination is made whether an upgrade code of the replacement software component matches an upgrade code of an originally installed software component. If yes, processing continues to decision block 940.
At decision block 940, a compatible upgrade code of the replacement software component is checked with a compatible upgrade code of the originally installed software component. If the two compatible upgrade codes match or otherwise indicate compatibility between the replacement software component and the originally installed software component, processing continues at process block 950. At process block 950 the replacement software component is installed. Processing then continues at process block 960 where the replacement software component imports settings of the originally installed software component. Processing then terminates at END block 970. If the determinations made at either decision block 920, decision block 930, or decision block 940 are negative, processing also terminates at END block 970.
The termination of processing if the signature verification performed at decision block 920 fails represents an application of a policy of refusing to install a software component either from an unverified source or that includes contents that cannot be verified. As with other policies, an option may be provided to override the policy automatically or in response to an explicit command provided by an appropriate user. Additionally, the process of importing settings at process block 960 may be dispensed with or may only occur in response to an explicit instruction.
If the determination made at decision block 1020 indicates that an aggressive installation mode is not desired, processing continues to decision block 1035 where a determination is made whether an upgrade code of the new device driver matches with an upgrade code of a preexisting device driver. If yes, processing continues to decision block 1040 where a determination is made whether a compatible upgrade code of the new device driver matches with a compatible upgrade code of a preexisting device driver. If yes, processing continues to process block 1045 where the new device driver is installed. Processing then terminates at END block 1030.
If the determination made at decision block 1035 indicates that the upgrade code of the new device driver does not match the upgrade code of the preexisting device driver, processing continues at decision block 1050 where a determination is made whether to continue installation despite the fact that upgrade codes of the device drivers do not match. If no, processing terminates at END block 1030. If yes, processing continues to decision block 1040. If the determination made at decision block 1040 indicates that the compatible upgrade codes of the device drivers do not match, a check to see if installation should continue is performed at decision block 1055. If installation should continue, processing continues to process block 1045 where the new device driver is installed. If installation should not continue, processing terminates at END block 1030.
The use of an installation code provides additional possibilities for installation policy creation and enforcement. For example, a vendor may have created an updated device driver to fix a critical flaw in its original device driver. By assigning an aggressive installation code to its updated device driver, the vendor can require that the updated device driver be installed. Similarly, a vendor can require the installation of a device driver that it has tested and approved in place of a currently installed, but untested or unapproved, device driver.
Additional policies that are illustrated by the method 1000 are to allow installation to continue despite failures of checks for matching upgrade codes and matching compatible upgrade codes. Such a policy can be appropriate, for example, for advanced users or system administrators. These and other policies can be combined or each can stand alone as a single installation policy.
At process block 1120, the set of descriptions is sent to an update server. Processing continues at process block 1125 where the set of descriptions is compared with a similar set of descriptions for device drivers that are available from the update server. At decision block 1130 a determination is made whether an updated version of a device driver currently installed on the local computing system is available on the update server. If no, processing concludes at END block 1135.
If an updated version of a device driver is available, processing continues at process block 1140 where an updated device driver is obtained by the local computing system. Processing continues at decision block 1145 where a determination is made whether a signature associated with the updated version of the device driver can be verified. If yes, processing continues to decision block 1150 where a determination is made whether an upgrade code and a compatible upgrade code associated with the updated version of the device driver match with an upgrade code and a compatible upgrade code of a currently installed device driver. If the upgrade code and the compatible upgrade codes match, installation proceeds to process block 1155 where the updated version of the device driver is installed. Processing terminates at END block 1135. If the signature cannot be verified at decision block 1145 or if the upgrade and compatible upgrade code matching fails at decision block 1150, processing will terminate at END block 1135.
The subject invention, for example in connection with selection or various pattern-matching tasks such as matching upgrade codes or compatible upgrade codes, can employ various artificial intelligence-based schemes for carrying out various aspects thereof. For example, a process for determining whether a replacement device driver is compatible with a currently installed device driver can be facilitated by using an automatic classifier system and process. Moreover, when more than one replacement driver is available, an automatic classifier system can be used to select a preferred or best replacement driver to be installed.
A classifier is a function that maps an input attribute vector, X=(x1, x2, x3, x4, . . . xn), to a confidence that the input belongs to a class, that is, f(X)=confidence(class). Such classification can employ a probabilistic and/or statistical-based analysis (for example, factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. In the case of software component replacement systems, for example, attributes can be file descriptors such as filenames, signatures, hash functions, upgrade codes, compatible upgrade codes, version numbers, build numbers, release dates, or other data-specific attributes derived from the device driver files and the classes are categories or areas of interest, for example, descriptors of other device drivers that the device driver can update.
A support vector machine (SVM) is an example of a classifier that can be employed. The SVM operates by finding a hypersurface in the space of possible inputs, which hypersurface attempts to split the triggering criteria from the non-triggering events. Intuitively, this makes the classification correct for testing data that is near, but not identical to training data. Other directed and undirected model classification approaches include, e.g., naïve Bayes, Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.
As will be readily appreciated from the subject specification, the subject invention can employ classifiers that are explicitly trained (for example, by a generic training data) as well as implicitly trained (for example, by observing user behavior, receiving extrinsic information). For example, SVM's are configured by a learning or training phase within a classifier constructor and feature selection module. Thus, the classifier(s) can be used to automatically perform a number of functions, including but not limited to determining according to a predetermined criteria which device driver should be selected to upgrade a currently installed device driver or whether device drivers are compatible.
If the determination made at decision block 1210 is yes, processing continues to decision block 1240 where a determination is made whether the new driver has an upgrade code or a compatible upgrade code. If that determination is no, processing continues to process block 1230. If the determination is yes, processing continues to decision block 1245. At decision block 1245 a determination is made whether an aggressive installation mode is indicated. If yes, processing continues at process block 1230. If no, processing terminates at END block 1235.
If the determination made at decision block 1215 is no, processing continues at decision block 1250. At decision block 1250 a determination is made whether an override of installation procedures is indicated. If yes, processing continues at process block 1230. If no override is indicated, processing terminates at END block 1235. If the determination made at decision block 1220 is yes, processing continues at process block 1230. If the determination made at decision block 1225 is no, processing processing continues at decision block 1250 and thereon until processing ultimately terminates at END block 1235.
In order to provide additional context for implementing various aspects of the subject invention,
Moreover, those skilled in the art will appreciate that the inventive methods may be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based and/or programmable consumer electronics, and the like, each of which may operatively communicate with one or more associated devices. The illustrated aspects of the invention may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all, aspects of the invention may be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in local and/or remote memory storage devices.
One possible means of communication between a client 1310 and a server 1320 can be in the form of a data packet adapted to be transmitted between two or more computer processes. The system 1300 includes a communication framework 1340 that can be employed to facilitate communications between the client(s) 1310 and the server(s) 1320. The client(s) 1310 are operably connected to one or more client data store(s) 1350 that can be employed to store information local to the client(s) 1310. Similarly, the server(s) 1320 are operably connected to one or more server data store(s) 1330 that can be employed to store information local to the servers 1340.
With reference to
The system bus 1418 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, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), Firewire (IEEE 1394), and Small Computer Systems Interface (SCSI).
The system memory 1416 includes volatile memory 1420 and nonvolatile memory 1422. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1412, such as during start-up, is stored in nonvolatile memory 1422. By way of illustration, and not limitation, nonvolatile memory 1422 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 1420 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 1412 also includes removable/non-removable, volatile/non-volatile computer storage media. For example,
It is to be appreciated that
A user enters commands or information into the computer 1412 through input device(s) 1436. The input devices 1436 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 1414 through the system bus 1418 via interface port(s) 1438. Interface port(s) 1438 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1440 use some of the same type of ports as input device(s) 1436. Thus, for example, a USB port may be used to provide input to computer 1412, and to output information from computer 1412 to an output device 1440. Output adapter 1442 is provided to illustrate that there are some output devices 1440 like monitors, speakers, and printers, among other output devices 1440, which require special adapters. The output adapters 1442 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1440 and the system bus 1418. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1444.
Computer 1412 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1444. The remote computer(s) 1444 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 1412. For purposes of brevity, only a memory storage device 1446 is illustrated with remote computer(s) 1444. Remote computer(s) 1444 is logically connected to computer 1412 through a network interface 1448 and then physically connected via communication connection 1450. Network interface 1448 encompasses wire and/or wireless 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, Token Ring 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) 1450 refers to the hardware/software employed to connect the network interface 1448 to the bus 1418. While communication connection 1450 is shown for illustrative clarity inside computer 1412, it can also be external to computer 1412. The hardware/software necessary for connection to the network interface 1448 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 subject invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the subject invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the subject invention are possible. Accordingly, the subject invention is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.
In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., a functional equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the invention. In this regard, it will also be recognized that the invention includes a system as well as a computer-readable medium having computer-executable instructions for performing the acts and/or events of the various methods of the invention.
In addition, while a particular feature of the invention may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes,” and “including” and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising.”
