Many electronic devices today include firmware. Firmware may be a software program or set of instructions programmed on a hardware device. The firmware may provide instructions which are executed to determine how the device operates. The firmware may be stored in programmable memory of a hardware device. As updated firmware is developed, the firmware stored in a device may be replaced or updated.
Existing solutions to manage the firmware of electronic devices such, for example, multifunction printing (MFP) devices, have many limitations. MFP devices may perform imaging (scanning), printing, copying and facsimile machine functions, or some subset of these functions. There is a lack of a mechanism to update the firmware for a group of MFP devices or to schedule an update for a future time period.
A method and system are described for firmware updating for one or more electronic devices connected on a user network. A management gateway may be connected on the network, configured to control all firmware update activity for the one or more electronic devices. In an exemplary application, the electronic devices may be multifunction printing devices. An electronically accessible firmware repository for storing firmware updates is maintained. The management gateway may establish a firmware update activity schedule for each electronic device. In another embodiment, a version matrix for the electronic device may be checked before performing an update.
In the following detailed description and in the several figures of the drawing, like elements are identified with like reference numerals. The figures are not to scale, and relative feature sizes may be exaggerated for illustrative purposes.
An exemplary embodiment of a method and system for managing firmware (FW) remotely includes a management gateway and a firmware repository.
A connection may be made through a firewall 50 at the customer's network through an internet connection 60 to a firmware repository 70, which may reside on a remote server 80, which may also be connected to the internet through a firewall 82. In an exemplary embodiment, the firmware repository 70 may provide a mechanism for storing and distributing firmware releases, and the management gateway 20 may fetch the firmware releases or firmware updates from the firmware repository. MFPs may have electronic controllers and may be networkable, so that the MFPs receive commands from an external device, e.g. the management gateway, for changing configuration, updating firmware, pulling a firmware update from a repository upon command, accepting a pushed firmware update from an external source, etc. The management gateway may communicate with the MFP using SNMP, SOAP or any other protocol configured in the management gateway 20. The simple network management protocol (SNMP) forms part of the internet protocol suite as defined by the Internet Engineering Task Force (IETF). SNMP is used by network management systems to monitor network-attached devices for conditions that warrant administrative attention. It includes a set of standards for network management, including an Application Layer protocol, a database schema, and a set of data objects. SOAP represents “Simple Object Access Protocol,” a lightweight XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including SMTP, MIME, and HTTP.
In an exemplary embodiment, either a dealer or the customer may use the management gateway 20 to perform a firmware update. In an exemplary illustrative application, a manufacturer may distribute electronic devices such as MFPs through dealers, who in turn sell the MFPs to customers. The dealers may support and maintain the MFPs for their customers. A dealer typically may have multiple customers.
In an exemplary embodiment, a dealer may install the management gateway in the customer network. In other embodiments, the customer may perform the installation. In an exemplary embodiment, the dealer may have direct access to only the management gateway, and not to other devices or applications installed on the customer network. The management gateway in turn may access the configured MFPs in the customer's environment. The rest of the customer network including the customer MFPs are protected from the direct access of the dealer. The dealer will not be able to access any part of the customer network other than the management gateway. Access to the management gateway may be granted only to the intended dealer and is protected using industry-standard security protocols. The customer may choose to deny access to the dealer.
An exemplary embodiment of a management system may provide the remote management console 96 and the management gateway 20 with a persistent secure virtual tunnel through which the remote management console can communicate with the management gateway. In an exemplary embodiment, the secure virtual tunnel may be an authenticated and encrypted communication link which is persistent or quasi-persistent, i.e., stays on after an exchange of messages. This secure virtual tunnel may provide a private and secure channel of communication between remote management console and management gateway over a public and non-secure medium such as the internet. To further enhance the security, the secure virtual tunnel also ensures that dealer can not access any other part of customer network except the Management Gateway. In an exemplary embodiment, the management gateway 20 may maintain a white list of all the devices which the remote management console is to be permitted to control remotely. Only the management gateway will access those devices. If the remote management console were to ask to control any other devices remotely on the customer intranet, the management gateway would refuse the request.
There are several ways in which a persistent secure virtual tunnel can be established, and which option is used in a particular customer scenario is a function of ease of deployment, scalability and level of security needed. In an exemplary embodiment, the URI scheme known as HTTPS may serve as a primary mechanism to establish a persistent secure virtual tunnel. HTTPS is well known in the art, and refers to Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL. HTTPS is a Web protocol built into browsers that encrypts and decrypts user page requests as well as the pages that are returned by a Web server. HTTPS uses the Secure Socket Layer (SSL) as a sub layer under the HTTP application layering. HTTPS uses port 443 instead of HTTP port 80 in its interactions with the lower layer, TCP/IP.
In an exemplary embodiment using HTTPS, the management gateway 30 may initiate an outgoing connection to the remote management console 96, and the secure tunnel is established after mutual authentication based on digital certificates. In an exemplary embodiment, the dealer may open his HTTPS port in order for the remote management console 96 to communicate with the management gateway 20 installed at the customer site. Then the management gateway 20 authorizes the remote management console 96 for remote management of the MFP devices 10A, 10B, 10C. At the successful end of an authorization step, a secure tunnel is in place.
An exemplary embodiment of a method and system may provide one or more of the following firmware management capabilities to dealers and customers:
Automated firmware updates for one or more MFP devices. A user may access a management gateway and configure the group of devices for firmware update, location of firmware in the firmware repository and the schedule of the update. The update activity can be scheduled for a future time period. The scheduling can be done for each MFP separately or for a group of devices together. The management gateway may in turn ensure that firmware updates are initiated at the specified time for each configured MFP. If the firmware update fails, then there may be retries and an alert notification may be sent to the registered user. Status of updates may be logged for future reference. A user may also be able to modify or cancel the scheduled update.
Managing firmware update for devices spread over protected networks of multiple customers. A dealer may manage the firmware of MFP devices installed across protected networks of multiple customers through access provided by a management gateway installed on each customer's network.
Checking the version matrix before performing updates. A version matrix may be maintained to ensure that the firmware for a subcomponent of an MFP is updated only if it is compatible with the firmware of other subcomponents. A management gateway may check an MFP version matrix to decide if the new version of firmware for a subcomponent is compatible with existing firmware of other subcomponents. This may be applicable for devices that support multiple components and each component has a separate firmware with dependency on firmware of other components.
Push and pull model. In a pull model, the MFPs can pull the firmware from a source location. A push model may be supported in which the management gateway may push the firmware to the MFP from an external system.
Security and access control. Multiple levels of security may be provided to ensure that only the authorized personnel can access the firmware update capability. This may include, for example, username/password based access control to MFPs, HTTPS/SSL connections from the dealer to the management gateway, and mutual authentication using digital certificates, and HTTPS connection between management gateway and MFP.
Notifying and alerting the user for the status of firmware update. Users may register to the management gateway for notifications and alerts. The management gateway may notify the users of the status of updates. In case of failures, the user may also get alert messages.
Logging of Firmware update activities. Status of all the firmware update activities may be logged for future reference.
Reliable Update and Notification. Once the firmware update starts, a mechanism may be provided to ensure that firmware is updated successfully. If firmware update fails, then retries may be made to ensure that the update is successful. If retries also fail then the user may be notified.
Thus, in an exemplary embodiment, a method and system may be provided to automate the firmware update process for MFP devices. A firmware update may be remotely managed from within the premises of the customer where the MFP is deployed or from the dealer location. From the dealer location, a user may access only the management gateway and not any other part of the customer network. Remote management of firmware updates may be enabled with a software application, the management gateway. A management gateway application may typically be installed inside the customer firewall and it can manage the firmware of MFPs in the network. A management gateway uses a firmware repository to obtain the firmware which needs to be updated in the MFPs. The firmware repository provides a mechanism to store and distribute the new firmware releases.
The firmware update process in an exemplary embodiment may be driven by the management gateway. Individual MFPs wait for management gateway instructions before they initiate the firmware update.
Once the user is authenticated for FW updating, the user is prompted at 112 to make a selection of either a “firmware first” or a “device first” method. In this exemplary embodiment, for the “firmware first” method, the user first selects the firmware and then the management gateway displays the list of devices compatible with that firmware. Then the user selects one or more devices from the list and the management gateway takes care of updating the selected devices with selected firmware. For the “device first” method, the user first selects the device to be updated and the management gateway then displays the list of firmware available for the update. Then user selects the desired firmware and the management gateway updates the selected firmware for that device.
For the “firmware first” method, at 114 the user specifies the location of the firmware repository. There may be more than one firmware repository available. In an exemplary embodiment, only one repository will be active for the management gateway at a given time. The management gateway may choose any one repository at a time. It could be either local or remote repository. The location of the firmware repository may be specified by using a URI (Universal Resource Identifier), which could be a URL, a directory path on local server or on the network, by way of example. At 116, the management gateway fetches the information about the firmware from the specified firmware repository, which may include in an exemplary embodiment the version number, family of devices supported and an associated version matrix, with the firmware. Then at 118, the user selects the desired firmware for the update from the displayed list of firmware. Once the user makes a selection of the firmware, the management gateway displays a list of devices which can be upgraded with the selected firmware at 120 and 122. If no devices are eligible for firmware updating, a message is displayed by the management gateway at 125. If at 124 there is at least one device eligible for firmware update, the user selects at 126 which devices are to be updated with the selected firmware. The user can also choose at 128 to do the update at that moment or schedule the update at future time period (130). At the scheduled time, management gateway will wake up and send the update request to all the required MFPs (step 132). 132 denotes a scheduler function, which “wakes up” when a scheduled job is due. At that time, it looks for all the jobs which are scheduled and starts the one which needs to be started at that time. Once in step 130 the job is scheduled, the scheduler at 132 will start the job at the appropriate time.
At 134, the management gateway connects to each device on the update list, and determines whether the device supports the push method or the pull method. In an exemplary embodiment, the management gateway can use either the push model or the pull model to make the firmware available to a MFP device. If at 136, the device supports the push model, then at 138, it gets the firmware file and sends it to MFP device. In the pull model, at 140, the management gateway provides the MFP with the location of the firmware file and the MFP fetches the file from that location. The management gateway receives the status of the firmware update, and if the update fails, retries the firmware update until the update succeeds or a predetermined number of retries has been attempted (steps 142, 144, 146). The management gateway logs the status and sends notification to registered users for the status and alerts if the update fails (step 148).
For the “device first” method, in an exemplary embodiment, most of the processing may be the same as in the “firmware first” method. In the “device first”, the method guides the user to select the device first at 160, 162. The user may specify the firmware repository location at 164, and then the management gateway displays at 166 the firmware available for update for that device, and which may be good candidates for upgrade for the selected device. The management gateway may determine at 168 whether there is at least one firmware available for update. If no firmware is available for that device, a message is displayed at 170. If firmware is available for the device, the user selects the desired firmware from the displayed list of firmware at 172, and operation branches to 128.
In an exemplary embodiment, a decision of whether to update the firmware of a particular MFP or not may be based on a version matrix. A version matrix for a firmware may be stored along with the firmware in the firmware repository. An exemplary version matrix is a matrix of version numbers of all the firmware for different components of the MFP. It may also contain the interdependencies among the various components. For those MFP devices with multiple sub-components, where each component requires a separate firmware, there may be a need to update more than one firmware at the same time. The firmware for different components of an MFP device may have interdependencies. The firmware for different components may have dependency on the order in which the firmware for components is upgraded. Additionally they might have dependency across versions. A particular version of one component may only work with a particular version of firmware for another component. In an exemplary embodiment, the management gateway compares the existing version of the MFP firmware with the version matrix of the new firmware and decides whether the firmware for the MFP needs to be updated or not. An exemplary embodiment of this feature is illustrated in
An exemplary embodiment of a version matrix is a matrix of version numbers of all the firmware for different components of the whole system. It also contains the interdependencies among the various components. A representation of an exemplary version matrix is depicted in the following table.
The first part of the table provides the version numbers of the firmware for different components. For example, the version of the released MFP firmware package is 7.0. In this example, the MFP firmware is made up five components—Print Engine firmware, Copier firmware, Scanner firmware, Fax firmware and Job Accounting Firmware. Components of the MFP may have different versions. In this case, even though the MFP firmware version is 7.0; the Fax firmware version is 5.0.
The bottom half of the table in this example of a version matrix provides the compatibility matrix of the version of components. The columns represent the versions of new firmware components. The rows show the versions of old firmware that are compatible with the new firmware versions shown in the columns. For example, Job Accounting version 4.0 in the new firmware is compatible with copier firmware version 6.5 or greater in the old releases.
The version matrix may be used in making decisions whether to update a particular component on not. For example, if a MFP has Job Accounting firmware with version 3.2 and printer firmware with version 6.7 and someone decides to update the firmware of Job Accounting to 4.0, then he also has to update the print engine firmware to 7.0; otherwise, the Job Accounting firmware will not work properly.
In an exemplary embodiment, a self-check mechanism may be provided to ensure that a firmware upgrade completes successfully. If there is a failure then retries will be made to upgrade the firmware. After certain number of retries, user will be notified on the failure of firmware upgrade. At that time user will have option to restore the old firmware on the MFP. An exemplary self-check mechanism is illustrated in
Although the foregoing has been a description and illustration of specific embodiments of the subject matter, various modifications and changes thereto can be made by persons skilled in the art without departing from the scope and spirit of the invention as defined by the following claims.
Number | Name | Date | Kind |
---|---|---|---|
5805803 | Birrell et al. | Sep 1998 | A |
6055632 | Deegan et al. | Apr 2000 | A |
6167448 | Hemphill et al. | Dec 2000 | A |
6199194 | Wang et al. | Mar 2001 | B1 |
6341143 | Nelson et al. | Jan 2002 | B1 |
6349336 | Sit et al. | Feb 2002 | B1 |
6360362 | Fichtner et al. | Mar 2002 | B1 |
6389464 | Krishnamurthy et al. | May 2002 | B1 |
6526092 | Nelson et al. | Feb 2003 | B1 |
6553422 | Nelson | Apr 2003 | B1 |
6671802 | Ott | Dec 2003 | B1 |
6772096 | Murakami et al. | Aug 2004 | B2 |
6928108 | Nelson et al. | Aug 2005 | B2 |
6930785 | Weyland et al. | Aug 2005 | B1 |
6971095 | Hirai et al. | Nov 2005 | B2 |
6976062 | Denby et al. | Dec 2005 | B1 |
6976163 | Hind et al. | Dec 2005 | B1 |
7069452 | Hind et al. | Jun 2006 | B1 |
7093244 | Lajoie et al. | Aug 2006 | B2 |
7197634 | Kruger et al. | Mar 2007 | B2 |
7213263 | Makineni et al. | May 2007 | B2 |
7280529 | Black et al. | Oct 2007 | B1 |
7349682 | Bennett et al. | Mar 2008 | B1 |
7376666 | Borchers | May 2008 | B2 |
7440465 | Park | Oct 2008 | B2 |
7444400 | Hara et al. | Oct 2008 | B2 |
7447775 | Zhu et al. | Nov 2008 | B1 |
7448080 | Karjala et al. | Nov 2008 | B2 |
7814480 | Sakuda et al. | Oct 2010 | B2 |
8115944 | Zhang et al. | Feb 2012 | B2 |
8266260 | Pathak et al. | Sep 2012 | B2 |
20020138567 | Ogawa | Sep 2002 | A1 |
20020184301 | Parent | Dec 2002 | A1 |
20020188934 | Griffioen et al. | Dec 2002 | A1 |
20020194313 | Brannock | Dec 2002 | A1 |
20030009697 | Uehata et al. | Jan 2003 | A1 |
20030018491 | Nakahara et al. | Jan 2003 | A1 |
20030041137 | Horie et al. | Feb 2003 | A1 |
20030061355 | Yang et al. | Mar 2003 | A1 |
20030086107 | Johnson et al. | May 2003 | A1 |
20030097427 | Parry | May 2003 | A1 |
20030154471 | Teachman et al. | Aug 2003 | A1 |
20030217193 | Thurston et al. | Nov 2003 | A1 |
20040093597 | Rao et al. | May 2004 | A1 |
20040103220 | Bostick et al. | May 2004 | A1 |
20040148379 | Ogura | Jul 2004 | A1 |
20040150851 | Sato | Aug 2004 | A1 |
20040210894 | Zarco | Oct 2004 | A1 |
20050108700 | Chen et al. | May 2005 | A1 |
20050114226 | Tripp et al. | May 2005 | A1 |
20050141025 | Hanada | Jun 2005 | A1 |
20050155029 | Nguyen et al. | Jul 2005 | A1 |
20050162689 | Roztocil | Jul 2005 | A1 |
20050206960 | Shibata | Sep 2005 | A1 |
20050223372 | Borchers | Oct 2005 | A1 |
20050272417 | Liu | Dec 2005 | A1 |
20060010437 | Marolia | Jan 2006 | A1 |
20060064741 | Terao | Mar 2006 | A1 |
20060080734 | Kim et al. | Apr 2006 | A1 |
20060085526 | Gulland | Apr 2006 | A1 |
20060103588 | Chrisop et al. | May 2006 | A1 |
20060109505 | Ha et al. | May 2006 | A1 |
20060168178 | Hwang et al. | Jul 2006 | A1 |
20060174242 | Zhu et al. | Aug 2006 | A1 |
20060209708 | Nakamura | Sep 2006 | A1 |
20060221380 | Pretz et al. | Oct 2006 | A1 |
20060235890 | Vigil | Oct 2006 | A1 |
20060280127 | Mizuno et al. | Dec 2006 | A1 |
20070080776 | Suwabe et al. | Apr 2007 | A1 |
20070159650 | Takamatsu et al. | Jul 2007 | A1 |
20070204045 | Shima | Aug 2007 | A1 |
20070211632 | Song et al. | Sep 2007 | A1 |
20080028385 | Brown et al. | Jan 2008 | A1 |
20080052383 | O'Shaughnessy et al. | Feb 2008 | A1 |
20080069122 | Matsuoka et al. | Mar 2008 | A1 |
20080127159 | Regenmorter | May 2008 | A1 |
20080178278 | Grinstein et al. | Jul 2008 | A1 |
20080189693 | Pathak | Aug 2008 | A1 |
20080189781 | Pathak et al. | Aug 2008 | A1 |
20090072991 | Hayashi et al. | Mar 2009 | A1 |
20100202450 | Ansari et al. | Aug 2010 | A1 |
Number | Date | Country |
---|---|---|
0632629 | Apr 1995 | EP |
2348987 | Oct 2000 | GB |
2002063035 | Feb 2002 | JP |
2002182940 | Jun 2002 | JP |
2004139572 | May 2004 | JP |
2005196462 | Jul 2005 | JP |
2004139572 | Mar 2006 | JP |
2006-243905 | Sep 2006 | JP |
WO0017749 | Mar 2000 | WO |
WO02084484 | Oct 2002 | WO |
Entry |
---|
PTO office action dated May 28, 2009, re U.S. Appl. No. 11/607,604. |
PTO office action dated Jan. 7, 2010, re U.S. Appl. No. 11/670,604. |
Number | Date | Country | |
---|---|---|---|
20080189693 A1 | Aug 2008 | US |