Appeal No. 2007-0340
Application 10/057,259
Figure 7 illustrates the details of Steps 608 and 610 of FIG. 6 for Thread 1.
In Step 608a, the thread performs a query. If the queried device is present, the
thread immediately returns a “True” reply in Step 608b (id. at 3, para. 45), in
response to which the GUI in Step 610 immediately replaces the “unavailable”
icon (i.e., the icon with an X) with an “available” icon (an icon without an X) and
the thread terminates (id.). If, on other hand, the queried device is offline, a
timeout period will expire (Step 608c) and the query will return a “False” value
(Step 608d), in response to which the GUI continues to display the “unavailable”
icon for that device (id. at 3, para. 45).
The timeout period is determined as follows. Querying device 102 includes
an operating system (not shown) and a timer 120 configured with a default timeout
value (id. at 2, para. 33). In some aspects of the invention, the operating system
can provide the default timeout value (id.). The querying device 102 can use a
Sockets connect function to attempt a socket connection to each of the network-
connected devices (id. at 3, para. 38.) The connect function and some other
functions have automatic timeouts determined by the protocols in use:
Some functions, such as connect( ), will timeout automatically. The
timeout for connect( ) affects non-blocking as well as blocking
operations. The GUI application does not have any control over the
timeout period for these functions, however, the network system alone
determines when their timeout occurs. These network-system
timeouts are related to the timeouts implemented for the protocols in
use (e.g., ARP timeout, TCP SYN, ACK timeouts, or DNS query
timeouts). The WinSock API does not provide a way to detect or
change these network-system timeout values.
6
Page: Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Next
Last modified: September 9, 2013