Abstract:
The present invention is directed to a network in which a potential user may be notified of the presence of at least one intelligent peripheral device and, upon the potential user&#39;s request, his workstation may be configured to use the selected intelligent peripheral device. The present invention is also directed to an installation method for notifying at least one potential user of the availability of at least one intelligent peripheral device and, if requested, configuring potential users&#39; workstations to use the requested intelligent peripheral device. In one preferred embodiment, the method includes the steps of sending an announcement to at least one potential user, receiving a response to the announcement from the potential user, and configuring the potential user&#39;s workstation to use the intelligent peripheral device.

Description:
BACKGROUND OF INVENTION  
         [0001]    A method and apparatus for discovering and configuring peripheral devices on a network, notifying potential users of the presence of a peripheral device on a network, and conveniently configuring a workstation to use peripheral devices.  
           [0002]    Peripheral devices allow users to put information into or get information out of a computer system. Peripheral devices include, but are not limited to, printers, scanners, copiers, and facsimile machines. Earlier generations of peripheral devices performed a single function and had a limited ability to communicate with other devices or process information. Many peripheral devices today, however, are able to perform multiple functions and are capable of sophisticated communications and information processing. A multifunction peripheral (“MFP”) is a peripheral device that can perform the functions of more than one traditional peripheral device. For example, a single device that can perform the functions of a printer, scanner, copier, and facsimile machine is an MFP. An intelligent peripheral device (“IPD”) is a peripheral device that includes an embedded microprocessor and memory for controlling its operation or for performing other tasks, such as communicating over a network with workstations, server computers, and other peripheral devices. An IPD can sometimes perform the functions of a server and is typically also an MFP.  
           [0003]    A typical network (“network”) includes a plurality of computer systems and peripheral devices capable of communicating with each other. A network can be a local area network, a wide area network, a plurality of networks, wireless networks, or other type of network. The computer system used by an individual user in a network environment is typically referred to as a “workstation.” Other computer systems on a network perform various network services and are referred to as “server computers.” The software associated with the computer systems and peripheral devices on a network includes clients and servers. A client is a program (a “process”) that sends a message to a server requesting that the server perform a task (a “service”). A server is a process that performs the requested task. While a client and a server may run on the same computer system, the client usually runs on a workstation while the server runs on a server computer dedicated to performing one or more server processes. In addition, a network generally includes a server computer that runs a network operating system, which in turn, provides various network services necessary for managing the network. For example, a network operating system often includes a file server, a print server, email, and a directory server.  
           [0004]    A hyperlink or hot link (“link”) is a connection between two hypertext objects and generally appears in a document as a highlighted word, phrase, or graphic object. In operation, clicking on a link causes the target object to be displayed. The target object can be a point elsewhere in the document, a Web page, or a service on a server computer. Hypertext transfer protocol (“HTTP”) is a widely used protocol for transferring a target object from a server to a client.  
           [0005]    When a new peripheral device is physically connected to a network, performing a software setup process is necessary before other devices on the network can communicate with the peripheral device. The setup process involves configuring various network settings, such as Internet protocol (“IP”) addresses, Lightweight Directory Access Protocol (“LDAP”) server entries, network masks, domain name system (“DNS”), and other similar network settings. After network settings for the peripheral device have been established, the workstations of users who want to use the peripheral device must be configured. This requires identifying potential users of the new peripheral device and installing device drivers on their workstations. For example, when a new printer is connected to a network, network settings for the printer must be configured and a print queue must be established on a print server. Users must be told the names of the print server and print queue and must install device drivers for the peripheral device. To install a device driver, the user typically navigates to the correct server through a directory tree displayed on his workstation, locates the correct print queue, and then double-clicks on the queue name. Similarly, when a new device is attached to a network, network settings for the device must be configured, and the workstations of users wanting to use the scanner generally must register with a scanner server. In order to register with the scanner server, the user must be made aware of the scanner, its IP address, and the required setup process.  
           [0006]    While networks can be small, consisting of a few workstations sharing a single peripheral device, they are typically much larger, often comprising hundreds or even thousands of workstations and peripheral devices. But users generally want to be able to use only the services of peripheral devices that are near their workstations. Networks are complicated by their nature dynamic and by the frequent release of, with workstations and peripheral devices being frequently added and removed, new versions of software (such as device drivers) that must be installed on server computers and workstations. In addition, when a peripheral device is assigned a new IP address, subnet mask, gateway, or DNS server, the setup configuration of the workstations with which the device communicates must be updated.  
           [0007]    The size and dynamic nature of many networks make it difficult for systems administrators to set up and maintain workstations so that users are able to use nearby peripheral devices. This task could be left to the user, but proper setup and maintenance of workstation configurations requires some level of expertise. The user must be able to navigate through an often complex series of steps to locate and install the software necessary to communicate with the peripheral device. Another problem is that many users, even if technically sophisticated, are unwilling to perform these steps because they are time-consuming. Users want to be able to use a peripheral device in a simple and transparent manner. If the setup process is complex or time-consuming or doesn&#39;t go smoothly, a time-pressed user will simply abandon the attempt to set up the peripheral device. Moreover, the user needs to be informed each time a peripheral device is added to or removed from the network. And finally, the user needs to be informed each time a new version of software required to use a peripheral device is released.  
           [0008]    To simplify and standardize the setup and maintenance process, several protocols have been developed that coordinate the configuration of computer systems and peripheral devices on a network (“configuration protocols”). Prominent configuration protocols that have been proposed or are in use today include Service Location Protocol (“SLP”); Jini; Universal Plug and Play (“UpnP”); and Universal Description, Discovery, and Integration (“UDDI”).  
           [0009]    SLP is an Internet Engineering Task Force (“IETF”) standard that provides a framework for network-based applications to discover the location of a service. SLP requires a Directory Agent, a Service Agent, and a User Agent. The Directory Agent stores information about services available on the network, including their network addresses. A Service Agent advertises a service. A User Agent discovers services for its client. In operation, Service Agents register with the Directory Agent, and a User Agent that wants to use a service contacts the Directory Agent. Service and User Agents learn the location of the Directory Agents in several ways: First, Service and User Agents can multicast a request to the network, and a Directory Agent that hears the request can reply. Second, a Directory Agent can multicast an advertisement of its location to the network. Third, Service and User Agents learn the location of the Directory Agent using Dynamic Host Configuration Protocol (“DHCP”). If there is no Directory Agent on the network, a User Agent that wants to use a service broadcasts its request to the network repeatedly; a Service Agent capable of providing the requested service will respond and fulfill the request. A drawback of SLP is that it requires that the described Agents be running on the network. A further drawback of SLP is that only network-based applications are able to discover the locations of services.  
           [0010]    Sun Microsystems&#39; Jini architecture is similar to SLP, but it is based on the Java language and is object-oriented. When a peripheral device is attached to a network, it broadcasts a message to the network requesting that all Lookup Services on the network identify themselves. The peripheral device then registers with responding Lookup Services. A workstation that wants to use a service locates one by sending a list of desired attributes to the Lookup Service. In response, the Lookup Service sends the workstation an object for a service that satisfies the requested criteria. The workstation uses the object to request the service from the peripheral device. A drawback of Jini is that it generally requires that a Lookup Service be running on the network.  
           [0011]    UpnP is a framework for the configuration of network devices that is defined at the network transport layer (transmission control protocol (“TCP”)/IP layer). UpnP requires that device manufacturers build application program interfaces (“APIs”) for their devices that implement UpnP protocols. When a device capable of controlling other devices is attached to a network, it broadcasts a message to the network requesting that all devices on the network announce their presence. When a device that only provides a service is attached to the network, it sends an advertisement of its presence to the network. While UpnP provides the protocol support for configuring devices on a network, a drawback of UpnP is that it doesn&#39;t provide a simple method for a user to configure network devices. To set up and maintain workstations so that they are configured to use the services of nearby peripheral devices, UpnP requires software at the network application layer.  
           [0012]    Examples of patent references directed to configuring workstations to use the services of nearby peripheral devices are given below.  
           [0013]    U.S. Pat. No. 5,960,167 to Roberts et al. (the “Roberts reference”) discloses a method for configuring a printer on a network and enabling workstations to use the printer. When a new printer is added to the network, it broadcasts an advertisement to the network. The advertisement is stored in a table, which an auto-install utility periodically reads to see whether new printers have been added to the network. If the auto-install utility discovers a new printer, it configures the printer and creates a print queue, a print server, a printer object, and a printer agent. The Roberts reference is limited in that it requires the auto-install utility to be run on a periodic basis; it also requires a print service manager and service registry service. These requirements add considerable overhead and complexity to a network. Further, the Roberts reference requires a server computer to run a shared printer driver.  
           [0014]    U.S. Pat. No. 5,692,111 to Marbry et al. (the “Marbry reference”) discloses a method that permits a user to print to a printer on a network even if that printer&#39;s configuration information and printer driver are not installed on the user&#39;s workstation. Printer-configuration information and printer drivers are stored on a network server. The user identifies a network printer when requesting a print job or running a printer-installation wizard. Configuration information and a printer driver are copied from the network server to the user&#39;s workstation. A drawback of the Marbry reference is that the user must know the location of the server and print queue to configure a printer. To learn the location of the server and print queue, the user must search through a directory structure. This process can be burdensome and confusing because the user may have to search through hundreds of printers hidden in dozens of folders that are given arcane, technically oriented names assigned by a system administrator. A further limitation of the Marbry reference is that the user is not made aware of nearby printers that are newly attached to the network.  
         BRIEF SUMMARY OF THE INVENTION  
         [0015]    The present invention is directed to a network in which a potential user may be notified of the presence of at least one intelligent peripheral device and, upon the potential user&#39;s request, his workstation may be configured to use the selected intelligent peripheral device. The network preferably includes at least one intelligent peripheral device communicatively coupled to the network. In one preferred embodiment, each of the intelligent peripheral devices include a device memory for storing a process for determining potential users of the intelligent peripheral device and sending an announcement to each potential user. The device memory also may be used for storing a message protocol and a protocol for linking a target object to a client. In one preferred embodiment, each of the workstations is communicatively coupled to the network. Each workstation also preferably includes a workstation memory for storing the message protocol and the protocol for linking to a target object to a client. Preferably, the network also includes at least one deployment server computer for serving the target object to the workstations, the deployment server computer communicatively coupled to the network.  
           [0016]    The present invention is also directed to an installation method for notifying at least one potential user of the availability of at least one intelligent peripheral device and, if requested, configuring potential users&#39; workstations to use the requested intelligent peripheral device. In one preferred embodiment, the method includes the steps of sending an announcement to at least one potential user, receiving a response to the announcement from the potential user, and configuring the potential user&#39;s workstation to use the intelligent peripheral device.  
           [0017]    In one preferred embodiment, the method includes the following steps: examining an all-users file stored in a directory server; creating and storing a potential-users file in the directory server having a network address; providing at least one intelligent peripheral device with the network address of the directory server; getting at least one potential user from the potential-users file; determining whether the potential user is a current user; determining whether the potential user has previously declined an offer to have at least one workstation configured to use the at least one intelligent peripheral device; sending an announcement to the at least one potential user; receiving a response to the announcement; determining whether the at least one potential user wants to have the at least one workstation configured to use the at least one intelligent peripheral device; determining whether the at least one potential user wants to have the at least one workstation configured to use the at least one intelligent peripheral device at a later time; configuring the at least one workstation to use the at least one intelligent peripheral device; and adding the at least one potential user to a current-users file.  
           [0018]    The foregoing and other objectives, features, and advantages of the invention will be more readily understood upon consideration of the following detailed description of the invention, taken in conjunction with the accompanying drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS  
       [0019]    [0019]FIG. 1 is a block diagram of a network of one preferred embodiment of the present invention.  
         [0020]    [0020]FIG. 2 is a block diagram showing the file structure of one preferred embodiment of the present invention.  
         [0021]    [0021]FIG. 3 is a flow diagram of an exemplary method for creating a potential-user file according to one preferred embodiment of the present invention.  
         [0022]    [0022]FIGS. 4A, 4B show a flow diagram of an exemplary method for potential users to discover an IPD and for configuring workstations to use the IPD according to one preferred embodiment of the present invention.  
         [0023]    [0023]FIGS. 5A, 5B show a flow diagram of an exemplary method for potential users to discover that a service upgrade for an IPD is available and for upgrading the service level of workstations according to one preferred embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0024]    The present invention is directed to a system and method for potential users of an IPD on a network to discover the availability of the device and to a simplified process for users to configure their workstations to use the IPD. The present invention also includes a method for current users of an IPD on a network to discover the availability of service upgrades and for upgrading the service level of workstations. In addition, the present invention is directed to a network in which users can discover IPDs or the availability of service upgrades, configure workstations to use the IPD, and upgrade the service level of workstations.  
         [0025]    [0025]FIG. 1 is a block diagram of a network  20  in an exemplary embodiment of the present invention. The network  20  includes a workstation  22 , an IPD  24 , a directory server  26 , a mail server  28 , and a deployment server  30 , each device communicatively coupled to the network  20 . The workstation  22  includes a CPU  32  and a memory  34 . The memory  34  stores software required to communicate with other devices on the network  20 . In a preferred embodiment, the workstation  22  runs clients that obtain services provided by servers on the network  20 . The memory  34  preferably stores software that supports e-mail and linking to Web pages. In a preferred embodiment, the memory  34  stores software that supports SMTP and HTTP. The IPD  24  includes a CPU  36  and a memory  38  for storing software required to communicate with other devices on the network  20 . The memory  38  preferably stores software that supports e-mail and serving Web pages. In a preferred embodiment, the IPD  24  is configured to work with a mail server  28  using SMTP, a directory server  26  using the LDAP, the deployment server  30  using HTTP, and other appropriate network protocols. In an additional preferred embodiment, the IPD  24  is an MFP. The directory server  26  is a server computer that stores information concerning all devices on the network  20  and provides a device-information service to clients. In one preferred embodiment, directory server  26  stores an all-workstations file  40  (described below). The mail server  28  is a server computer that provides clients an e-mail service. In one preferred embodiment, mail server  28  supports SMTP. The deployment server  30  is a server computer that stores client code and device drivers that are necessary for a workstation  22  to use an IPD  24  and provides a configuration service to clients. Workstations  22  may have different operating systems and other features that require unique client code and device drivers. The deployment server  30  preferably stores all versions of client code and device drivers that may be required. In one alternative preferred embodiment, the configuration service provided by deployment server  30  runs on the IPD  24 . The deployment server  30  preferably supports HTTP. If a user of a client workstation  22  clicks on a link to a target object supported by the deployment server  30 , a configuration process is delivered to and automatically executed on the client workstation  22 .  
         [0026]    As shown in FIG. 2, one preferred embodiment of the present invention contemplates eight types of files. An all-workstations file  40  is stored on the directory server  26  and contains information about all workstations  22  on the network  20 . A potential-users file  42  is created as a result of the process described below and shown in FIG. 3. The potential-users file  42  is preferably stored in the memory  34  of IPD  24 , but in an alternative preferred embodiment it is stored in the directory server  26 . In addition, the present invention contemplates a current-users file  44 , a potential-users-ask-later file  46 , and a potential-users-decline-service file  48 . Files  44 ,  46 , and  48  are created as a result of the process shown in FIGS. 4A, 4B and further described below. Finally, the present invention contemplates a current-users-service-level file  50 , a current-users-ask-later file, and a current-users-decline-upgrade file  54 . Files  50 ,  52 , and  54  are created as a result of the process shown in FIGS. 5A, 5B and further described below. Files  44 ,  46 ,  48 ,  50 ,  52 , and  54  are stored in the directory server  26  or in memory  34  of IPD  24 .  
         [0027]    While the description of the present invention is made with respect to the files described in the preceding paragraph, these files are exemplary. It is contemplated that more or fewer than eight file types could be used. Further, the locations where the files are stored are exemplary. The files may be stored in any memory location accessible over the network  20 . The important factor is that the information necessary to perform the method is stored in a location available to the services described below.  
         [0028]    The method of the present invention can be divided into three submethods. First, there is a method for creating a potential-users file  42  (see FIG. 3). Second, there is a method in which a potential user discovers the availability of and configures a workstation  22  to use the IPD  24  (see FIGS. 4A, 4B). Third, there is a method in which a current user discovers the availability of a service upgrade and configures a workstation  22  to use the upgrade (see FIGS. 5A, 5B). These methods are described below.  
         [0029]    [0029]FIG. 3 is a flowchart illustrating the steps that are performed in the preferred embodiment of the method of the present invention to create a potential-users file  42 . Initially, an IPD  24  is connected to the network  20  (step  100 ). Network settings required to enable the IPD  24  to communicate with other devices on the network  20  are configured (step  102 ). In a preferred embodiment, the IPD  24  is configured to work with a mail server  28  using SMTP, a directory server  26  using LDAP, a deployment server  30  using HTTP, and other appropriate network protocols. If the IPD  24  has a print capability, a print queue (optional step  104 ) is established. The all-workstations file  40  is obtained (step  106 ), and workstations  22  in close physical proximity to the IPD  24  are selected to create a potential-users file  42  (step  108 ). It should be understood that physical proximity is an exemplary criterion and that other criteria (such as the particular functions of the IPD  24 ) may be used to select potential users. In an alternative preferred embodiment, workstations  22  of potential users are marked on the all-workstations file  40 . The IPD  24  is provided with the location of the potential-users file  42  or a marked all-workstations file  40  (step  110 ). In one preferred embodiment, the IP address of the directory server  26  is provided to the IPD  24 . In an alternative preferred embodiment, a copy of the potential-users file  42  is provided to the IPD  24 . The steps performed to create a potential-users file  42  may be performed by a systems administrator. In an alternative embodiment, the steps performed to create a potential-users file  42  may be performed by software.  
         [0030]    [0030]FIGS. 4A, 4B show a flowchart illustrating the steps that are performed in a preferred embodiment of the method of the present invention for a potential user to discover an IPD  24  and configure a workstation  22  to use the IPD  24 . Initially, an entry (representing a potential user) is obtained from the potential-users file  42  (step  120 ). A check is made to see if the potential user was previously set up to use the IPD  24  (step  122 ). If the potential user was not previously set up to use the IPD  24 , a check is made to see if the potential user previously declined an offer to have his workstation  22  configured to use the IPD  24  (step  124 ). If the potential user did not previously decline an offer to have his workstation  22  configured, an announcement is sent to the potential user (step  126 ). The announcement preferably includes a link to a configuration service provided by deployment server  30 . Provided the response of the potential user is received (step  128 ) and checked to see if the potential user wants to have his workstation  22  configured (step  130 ). A potential user indicates that he wants to have his workstation  22  configured by simply clicking on the link included in the announcement; in response, a configuration process is delivered to and automatically executed on the specified workstation  22  (step  132 ). The potential user is added to the current-users file  44  (step  134 ). If the potential user does not wish to have his workstation  22  set up to use the IPD  24 , a check is made to see if the potential user would like to be offered the link at a later time (step  136 ). If the potential user wants to be offered the ability to configure his workstation  22  later, the potential user is added to a potential-users-ask-later file  46  (step  138 ). If the potential user does not want to be offered the ability to configure his workstation  22  later, the potential user is added to the current-users-declineservice file  48  (step  140 ). After any step is performed, and if further steps of this method are not appropriate, a check is made to see if this potential user is the last entry (step  142 ). If there are additional entries in the potential-user file  42 , the method is repeated for each entry. If there are no further entries, the method is complete (step  144 ).  
         [0031]    [0031]FIGS. 5A, 5B show a flowchart illustrating the steps that are performed in a preferred embodiment of the method of the present invention for a current user of an IPD  24  to discover the availability of a service upgrade and for upgrading the service level of a workstation  22 . This method may be used when a developer issues a new version of a device driver, new functions become available on the IPD  24 , an IPD  24  is removed from the network  20 , or a configuration upgrade is otherwise required. An entry is obtained from the current-users file  44  (step  220 ). A check is made to see if the current user needs a service update (step  222 ). If the current user needs a service update, a check is made to see if the current user has previously declined a service update (step  224 ). If the current user needs a service update and has not previously declined a service update, the current user is sent an update announcement (step  226 ). The update announcement preferably includes a link to an update service provided by deployment server  30 . A response from the current user is received (step  228 ), and a check is made to see whether the current user wants the service update (step  230 ). A current user indicates that he wants to have the service update installed on his workstation  22  simply by clicking the update link included in the update announcement. In response to the user&#39;s clicking on the update link, a service upgrade process is delivered to and automatically executed on the specified workstation  22  (step  232 ). The current-users file  44  is updated to reflect the service level update (step  234 ). If the current user does not want the update immediately, a check is made to see if the current user would like the update performed later (step  236 ). If the current user would like the update performed later, the current user is added to the current-users-ask-later file  52  (step  238 ). If the current user does not want to be offered a service update later, the current user is added to the current-users-decline-update file  54  (step  240 ). After steps  222 ,  224 ,  234 ,  238 , and  240 , if further steps in the method are not appropriate, a check is made to see if the current user is the last entry in the current-users file  44  (step  242 ). If there are additional entries in the current-users file, the method is repeated for each entry. If there are no further entries, the method is complete (step  244 ).  
         [0032]    The terms and expressions that have been employed in the foregoing specification are used as terms of description, not of limitation, and are not intended to exclude equivalents of the features shown and described or portions of them. The scope of the invention is defined and limited only by the claims that follow.