Abstract:
A system and method for maintaining network activity in a router to keep the router from entering a lock-up state due to inactivity. The system and method is operable to send a ping request via the router to an Internet Protocol (IP) address to which a response is expected. It is then determined whether the response is received. If no response is received, a notification message is displayed indicating that network access is unavailable. The process is preferably automatically repeated such that the network router does not experience a prolonged period of inactivity and the user is apprised of the status of his network connection.

Description:
BACKGROUND 
   1. Field of the Invention 
   The present invention is directed to electronic networks. More particularly, the present invention is directed to maintaining an Internet connection via a router even during periods of network traffic inactivity. 
   2. Background of the Invention 
   The Internet is fast becoming an essential tool for business. Large corporations and similar large entities that can afford it, have connectivity to the Internet via sophisticated networks including multiple hubs, servers and, in some cases, dedicated/leased high speed lines made available by local telecommunications providers. Additionally, entities that can afford it also have dedicated information technology (IT) departments that monitor, detect and correct (when possible) network outages. 
   Small businesses, on the other hand, typically do not have access to the high speed/bandwidth leased lines that larger companies often have access to. Instead, small businesses are becoming increasingly reliant on various forms of Digital Subscriber Line (DSL) services, collectively known as xDSL services, to access the Internet. xDSL service furnishes a small business access to the Internet at speeds which, while not necessarily as fast as leased lines, are nevertheless substantially faster than conventional dial-up modem technology. 
   A significant advantage to employing xDSL service is that one&#39;s Internet access is “always-on.” This is in contrast to conventional dial-up modem access which requires a set-up procedure each time Internet access is desired. 
   Because xDSL access is presumably “always-on,” not surprisingly, users expect this to be the case at all times. In reality, however, xDSL service may go down from time to time, which leads to periods of inactivity across the network. Periods of inactivity in a network can also be caused by overnight periods when, for example, small businesses are closed. Such periods of inactivity can lead to unforeseen consequences with respect to some network hardware components, and especially some models of network routers. 
   Specifically, the present inventor has observed that some router models will, after experiencing a period of inactivity, caused either by inactivity from a user&#39;s end and/or by a failure of a segment of the network on the “other side” of the router, i.e., the xDSL service, succumb to “lock-up” whereby even subsequent network activity will not re-activate the router. To end the lock-up situation, the power to the router might have to be cycled off and on. 
   Unfortunately, unlike a large corporation, a small business does not have the resources to employ a dedicated IT department. Thus, not only might personnel from a small business not know where their router might be located on their premises, but these people often do not even know that there is router on their premises. Accordingly, when it determined that Internet access is “down,” a small business invariably calls its xDSL provider to notify the provider of the outage and request a service call, which in turn, requires that a technician be dispatched to the small business customer. These actions, and the time that the small business does not have Internet access lead to increased expense, inefficiencies and frustration for both the xDSL service provider and small business customer. 
   SUMMARY OF THE INVENTION 
   The present invention provides a method for maintaining activity (traffic) in a network, and in particular keeping a router in the network active to thereby keep the router from falling into a lock-up state. The present invention also preferably informs a user of the status of his Internet access. The foregoing is preferably accomplished by sending a request intended to pass through the router and to which a response is expected, and determining whether the response is received. If no response is received, a notification message is displayed to a user indicating that their Internet connection is “down.” The step of sending a request is preferably automatically carried out on a periodic basis such that the router never experiences a relatively long period of inactivity. Thus, in accordance with the present invention, the router does not lock up as a result of periods of inactivity. 
   In a preferred embodiment of the present invention, the “request” that is sent is a “ping” request or command to a predetermined Internet Protocol (IP) address, though the IP address need not necessarily be accessible only via the Internet. Rather, in accordance with the principles of the present invention, the only requirement is that the IP address is one that will cause the request to pass through the router, thereby precluding the router from experiencing periods of inactivity. 
   Further in accordance with the present invention, software that causes the requests to be sent periodically is preferably operable at all times, i.e., is an active program running within a multi-tasking operating system such as Microsoft Windows 2000, UNIX or Linux. 
   Further still, the present invention is preferably in the form of computer software that is downloadable from an Internet web site. Alternatively, the present invention can be implemented in firmware that is delivered, for example, with an Internet-ready computer. 
   It is therefore an object of the present invention to provide a method for keeping a router operable in a network to preclude the router from experiencing prolonged periods of inactivity. 
   It is yet another object of the present invention to provide a method for notifying a user of the status of his Internet access. 
   It is another object of the present invention to provide a software application that continuously runs in the background of a multi-tasking operating system. 
   It is also an object of the present invention to provide a method for notifying a user that his Internet access has been restored. 
   These and other objects of the present invention will become apparent upon a reading of the following detailed description in conjunction with the accompanying drawings. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a schematic illustration of a network topology including the location of software for implementing the present invention. 
       FIG. 2  is a flowchart illustrating a preferred embodiment of the present invention. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1  depicts a network topology for a small business including two local area networks (LANs)  10  and  20  each comprising several personal computers  30 . LANs  10  and  20  are connected to each other via router  40  which, in turn, is connected to XDSL modem  50 . One or more telephones  60  might be connected directly, or via private branch exchange (PBX)  65 , to xDSL modem  50  by means well-known to those skilled in the art. xDSL modem  50  is also connected to a telephone line  70  that supports xDSL services. This telephone line (along with other similar telephone lines  71 ,  72 , etc.) is typically connected to a DSL Access Multiplexer (DSLAM)  80 , which is connected via, e.g., a DS-3 communications line  81 , to a telecommunications managed facility  90  that has connectivity to an Internet backbone  100 , e.g., UUNET. As is evident from  FIG. 1 , router  40  is a critical link between LANs  10  and  20  and the Internet. Keeping this component of the network in an operative state is therefore especially desirable. 
   Experience by the present inventor has shown that some router models, are configured in such a way that when the router experiences a period of inactivity it has a tendency to lock up and, for all intents and purposes, become inoperative. When the router shuts down in this fashion, the quickest (and usually only) way to bring the router back on line is to cycle its power, i.e., unplug its power source and then reapply power. Unfortunately, during the ensuing router down time, the user has no access to the Internet. Router inactivity can be caused by a failure of a user&#39;s xDSL service, for example, or can be caused by inactivity from the LAN side of the network, e.g., when LANs  10  and  20  are not being used, e.g., at times outside of normal business hours. 
   The present invention keeps router  40  from falling into a lock-up state by periodically and automatically (i.e., without user intervention) accessing router  40 .  FIG. 2  is a flow chart illustrating this process. Specifically, at step  210  a request is sent via router  40 . The request is one that, under normal circumstances, should receive a response. A preferred type of request is the well-known “ping” command which “bounces” a signal off of a predetermined Internet protocol (IP) address. The predetermined IP address, or destination, responds if it is on-line. Alternatively, a browser could be employed to access a predetermined web site and record whether the web site had indeed been properly accessed. 
   At step  220  it is determined whether a response to the request has been received. If no response is received, then at step  230  a message is displayed for the user, e.g., in the form of a pop-up window, notifying the user that his Internet access is temporarily unavailable. That is, since a response to the request was not received it is assumed that the request failed to communicate with the predetermined IP address. Nevertheless, traffic was still passed to router  40  thereby keeping it in an active state. The process then proceeds to step  260 , described below. 
   In an alternative embodiment, if no response is received, then a second IP address is “pinged.” This secondary or backup IP address provides assurance that it is indeed the Internet connection that is down, and not just the first or primary IP address that is off-line or is not responding. 
   If a response was received at step  220 , then at step  240  it is determined whether the last time a request was sent a response was not received. If a response had not been received, i.e., Internet access was unavailable, then at step  250  a pop-up window, for example, notifies the user that his Internet access has been restored. The process then proceeds to step  260 , described below. 
   If at step  240 , the last time a request was sent a response was received, then the process proceeds to step  260 , which provides a time delay of a predetermined length. The process, beginning at step  210 , then repeats. The time delay of step  260  is preferably less than the period of time that causes router  40  to fall into a state of lock-up, e.g., in the range of 5–10 minutes. Therefore, in accordance with the present invention, router  40  does not experience a period of inactivity that is sufficient to cause it to fall into a state of lock-up. Thus, even if users are not themselves accessing the Internet, or their xDSL service fails such that network traffic is also not passing from the Internet toward router  40 , router  40  in accordance with the present invention, will still continue to be active within the network, thereby avoiding the lock-up issues associated with certain models of routers. 
   In a preferred embodiment of the present invention, the process illustrated in  FIG. 2  is implemented in software using well-known high level languages such a C, C++, or Visual Basic, and stored on at least one computer  30  connected to at least one of LANs  10  and  20 .  FIG. 1  shows element  200  as representing the process of  FIG. 2 . The process can be stored on a computer&#39;s hard drive or within a firmware package. A combination of these storage methods can also be implemented depending on the design and configuration of the computer  30 . 
   In a preferred implementation, the software that implements the process of  FIG. 2  is downloaded via the Internet, thereby avoiding having to distribute the software by floppy disks or CD ROMs. By employing the downloading implementation, the IP address(es) used in the ping command can be easily changed by requesting the user, e.g., by email, to download a newer or upgraded version of the software. 
   Preferably, the software that implements the method of the present invention is loaded on one or more PCs  30  in such a way that when the PC is first booted, the software is automatically launched and thereafter performs its iterative process until the PC is subsequently shut down. Such techniques are well-known to those skilled in the art. 
   While the present invention has been described in connection with routers and xDSL service, the present invention is applicable to any network component that may benefit from periodic network traffic. 
   The foregoing disclosure of the preferred embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be obvious to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims appended hereto, and by their equivalents.