Patent Application
20220271966
This application relates generally to device monitoring. The application relates more particularly to management of fleets of multifunction peripherals by the use of a handheld digital device.
Document processing devices include printers, copiers, scanners and e-mail gateways. More recently, devices employing two or more of these functions are found in office environments. These devices are referred to as multifunction peripherals (MFPs) or multifunction devices (MFDs). As used herein, MFPs are understood to comprise printers, alone or in combination with other of the afore-noted functions. It is further understood that any suitable document processing device can be used.
Large businesses may have a large number of MFPs, referred to as a fleet. MFPs must be monitored for configuration, hardware or software or firmware modification, consumable replenishment, usage monitoring, or the like. Such monitoring requires periodically getting information from MFPs in the fleet.
Various embodiments will become better understood with regard to the following description, appended claims and accompanying drawings wherein:
The systems and methods disclosed herein are described in detail by way of examples and with reference to the figures. It will be appreciated that modifications to disclosed and described examples, arrangements, configurations, components, elements, apparatuses, devices methods, systems, etc. can suitably be made and may be desired for a specific application. In this disclosure, any identification of specific techniques, arrangements, etc. are either related to a specific example presented or are merely a general description of such a technique, arrangement, etc. Identifications of specific details or examples are not intended to be, and should not be, construed as mandatory or limiting unless specifically designated as such.
Fleet management can be accomplished via a networked computer, such as a workstation. Device information may be secured in this fashion for device maintenance, updating, modification or replenishment. However, since most, if not all MFPs are in different locations, an administrator may have to regularly return to their workstation to determine different device needs or properties as the service devices scattered about a premises. It is thus desirable to undertake MFP fleet management with a handheld device such as a smartphone or tablet. In order to accomplish management, a device must first identify all MFPs of interest on one or more subnets of interest. Device discovery can use more resources than is available on a mobile device.
Example embodiments herein provide a device discovery process accomplished via a handheld device, such as smartphone or tablet computer. The system discovers multiple MFP devices across different networks, wired or wireless or a combination of both. This discovery process is typically a heavy, resource consuming operation which can overwhelm resources available on a handheld device, such as tablet or smartphone. The system enables a mobile handheld device to accomplish discovery of potentially hundreds of MFP's efficiently and in an asynchronous or parallel fashion. A multistep MFP device discovery process is used to accomplish effective device discovery within a mobile device with restricted resources. This routine can traverse local area networks (LANs), area networks (WANs), multiple subnets, virtual LANs (VLANS) and network segments, even if connected through a virtual private network (VPN). The system suitably uses an existing protocol, such as the Simple Network Management Protocol (SMNP) for MFPs so enabled devices in a multistep, parallel execution process. The system implements a software library configured to handle up to several hundreds of MFP petitions and replies to discover a fleet of MFP devices.
After device discovery, which could be hundreds of MPFs within a network, one or fleets can be created for efficient MFP management of the MFP. Each fleet MFP is associated with an IP address and configured to be failure tolerant. If an IP address becomes unreachable, failure tolerant devices adapt to the new network conditions.
In example embodiments, a mobile device analyzes its own network, then sends a multicast petition to traverse its own subnet in a search in a parallel fashion. The mobile device is configured to decide intelligently how to send these petitions. In a subnet defined by an octet of 255 IP addresses, up to 254 in an IP addresses and/or devices may be available in the handheld device's own subnet.
When the devices of interest, such as SMNP compatible MFPs, receive this petition they will most likely be in power saving mode. This petition initially functions to “wake up” MFPs out of power saving mode becoming fully functional. Since the petition is broadcast in parallel, devices respond in an asynchronous matter. The system determines if a replying device is of interest. If so, it will initiate a second petition as a second stage inquiry. This second stage inquiry will use another set of petitions to query for manufacture name, model name and other details, such as an installed software, installed hardware, firmware version, copy count, consumable levels, error codes, and the like. Processing is asynchronous, so the system suitably balances the outgoing petition load, to manage a rate of incoming replies to allow sufficient device resources to handle messaging as it is received in parallel achieving up to 600% improved processing time compared to a traditional, linear device discovery process.
Discovered MFP's are suitably stored in a local database for easy administrator management via their mobile device. When traversing a particular subnet is completed, the system can move to another subnet, allowing fine tuning by the administrator. If a mobile device has sufficient capabilities, several subnets can be traversed by concurrently implementing parallel operations.
Turning now to
Processor 202 is also in data communication with a storage interface 208 for reading or writing to a storage 216, suitably comprised of a hard disk, optical disk, solid-state disk, cloud-based storage, or any other suitable data storage as will be appreciated by one of ordinary skill in the art.
Processor 202 is also in data communication with a network interface 210 which provides an interface to a network interface controller (NIC) 214, which in turn provides a data path to any suitable wired interface or physical network connection 220, or to a wireless data connection via wireless network interface 218. Example wireless data connections include cellular, Wi-Fi, Bluetooth, NFC, wireless universal serial bus (wireless USB), satellite, and the like. Example wired interfaces include Ethernet, USB, IEEE 1394 (FireWire), Lightning, telephone line, or the like. Processor 202 is also in data communication with user interface 21 for interfacing with displays, keyboards, touchscreens, mice, trackballs and the like.
Processor 202 can also be in data communication with any suitable user input/output (I/O) interface 219 which provides data communication with user peripherals, such as displays, keyboards, mice, track balls, touch screens, or the like.
Also in data communication with data bus 212 is a document processor interface 222 suitable for data communication with the document rendering system 200, including MFP functional units. In the illustrated example, these units include copy hardware 240, scan hardware 242, print hardware 244 and fax hardware 246 which together comprise MFP functional hardware 250. It will be understood that functional units are suitably comprised of intelligent units, including any suitable hardware or software platform.
Turning now to
Next, at block 416, once all responses are received and stored, IP addresses in the subnet are traversed, starting with the first IP address of the subnet.
Next, a determination is made at block 420 as to whether a device was detected at the current IP address. If so, a test is made at block 424 to determine if it is a device of interest, such as an SNMP capable MFP. If so, device information is queried via a second petition to the device at block 428. Device information from the MFP reply is received and stored at block 432, and the current IP address is incremented at block 436. If a device is determined not to be of interest in block 424, the process proceeds immediately to block 436.
A test is made at block 440 to determine if all IP addresses in the subnet have been checked. If not, the process returns to block 420 with the incremented IP address. Once an end of the subnet is achieved at block 440, the system progresses to block 444 and a check is made as to whether another subnet is to be processed. If so, a next subnet is selected at block 448 and the system returns to block 408. When a last subnet is determined at block 444, the system ends at block 452.
While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel embodiments described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the embodiments described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the spirit and scope of the inventions.
