2. Related Art An age-old challenge to the efficient operation of business and industry is that of the dynamic workload. While most businesses prefer to see their workload increase, the actual workload experienced is rarely predictable. In fact, changes in workload aren't always gradual and uniform. Employers often experience peaks and valleys in their workload curves, regardless of whether business is increasing, diminishing or remaining stable. Such peaks and valleys make cost-effective staffing a difficult problem. Providing enough workers to handle peak workload times, often results in having too many workers on-hand during slower periods, and vice versa. Additionally, even where an optimum or close-to-optimum staffing level can be met, sick time, vacation time and other employee absences can easily upset the delicate workload-workforce balance.

One asset utilized by business and industry to help maintain the workload-workforce balance is the temporary agency. Temporary agencies throughout the world provide manpower needed by business and industry to help equalize their workforce in response to the dynamics of the ever-changing workload.

Because the resource provided by the temporary agency is manpower, it is important that the time worked by the temporary employee is accurately recorded and billed.

Often, the agency or agency's client utilized a manual record-keeping technique to track the time for temporary employees. Such manual time-keeping techniques can be logistically cumbersome requiring significant manpower resources to manage and maintain.

SUMMARY OF THE INVENTION The present invention provides a system and method for capturing and handling information, such as, for example time keeping information. According to one embodiment of the invention, one or more user terminals are provided to employees so that they may enter the amount of time they have spent working on one or more tasks or for one or more clients. The user terminals can be portable. hand held devices that can be carried with the employees to their place of employment at one or more various locations. Preferably, the employees enter the time spent working on one or more tasks in terms of hours and minutes. In one embodiment, the user terminal does not differentiate between tasks for clients, but simply allows a straight entry of time for all of the time worked by an employee. In more complex embodiments, the user terminal allows specific clients, tasks, or other identifications to be entered, identifying a particular task, client, or matter on which the employee worked. In this manner, the time worked by an employee can be appropriately assigned to one or more tasks.

According to one embodiment of the invention, the time entered into the one or more user terminals is subsequently provided to an acceptance unit. Preferably, in one embodiment, the acceptance unit is a front end which checks the format and content of the data and allows the time entered to be checked and authorized by the client. a supervisor, or other appropriate individual. Once the time has been checked and authorized, it can be provided to a processing system for assimilation. The processing system can perform a variety of functions, including, for example, the processing of time entries from one or more employees to generate client and/or project billing information, payroll information, tax or bookkeeping information, or other accounting or accounting-related information. The various entries from one or more employees can be appropriately sorted and/or combined to generate totals and subtotals for various projects or clients. as well as to allow detailed information to be accessed and/or provided in reports or printouts.

One advantage of the invention is that it provides simplified entry of employee timekeeping data. Another advantage of the invention is that it provides for a certain

level of automated content, format, and error checking to help minimize the occurrence of errors and duplicate entries in reported time. Yet another advantage of the invention is that it provides for the authorization and verification of time entered by a supervisor, client, or other appropriate individual such that the time entries can be approved before they are entered into a processing or accounting system. Yet another advantage of the invention is that it allows the assimilation and processing of the various time entries made by one or more employees through the user terminals.

Further features and advantages of the interface system as well as the structure and operation of various embodiments of the interface system are described in detail below with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram illustrating an example implementation of an employee time assimilation system according to one embodiment of the invention.

FIG. 2 is an operational flow diagram illustrating a process for the entry of time information according to one embodiment of the invention.

FIG. 3 is an operational flow diagram illustrating a process for the validation and authorization of entries according to one embodiment of the invention.

FIG. 4 is a block diagram illustrating an example architecture for a user terminal according to one embodiment of the invention.

FIG. 5 is a diagram illustrating example front and rear panels for a user terminal according to one embodiment of the invention.

FIG. 6 is a figure illustrating an example screen format according to one embodiment of the invention.

FIG. 7 is a block diagram illustrating an example computer system which can be used to implement the functionality described for the present invention.

DETAILED DESCRIPTION OF THE INVENTION 1. Overview of the Invention The present invention is directed toward a system and method for capturing and handling employment-related information. Generally speaking, in accordance with one

embodiment of the invention, one or more user terminals are provided to employees for the entry of time spent working on one or more tasks. The user terminals can be portable, hand held data entry devices that allow the employees to key-in or otherwise enter their time worked for one or more employers or particular projects. The time entered can be reviewed by the employees prior to submission. Upon submission, the time entries can be reviewed by an appropriate party for correctness. Once reviewed, the approved entries can be forwarded to a processing system for assimilation.

2. Example Environment One example environment for which application of the invention is quite suitable, is that of the employer/temporary-employee. In this environment, there is a desire to streamline the timekeeping, billing, review and authorization of temporary employee time. Related alternative environments can include, for example, those involving contract employees, attorneys or solicitors, and other employer/client/employee relationship situations. The invention and its various embodiments are described in terms of this example employee-timekeeper environment. Discussion in these terms is provided to facilitate description and not to limit the scope or application of the invention to this example environment. In fact, after reading this description, it will become apparent to one of ordinary skill in the art how to implement the invention in alternative environments, not necessarily limited to the employment context.

3. Time Sheet Assimilation FIG. 1 is a block diagram illustrating the invention in accordance with one embodiment. Referring now to FIG. 1, one or more user terminals 104 are provided to the temporary employees for the purpose of inputting their time spent working on a project or for a given temporary employer (referred to as a Aclient@). Preferably, in accordance with one embodiment, each temporary employee assigned to a client is provided with his/her own individual user terminal 104. In alternative embodiments, a user terminal 104 can be shared among a plurality of temporary employees.

An acceptance unit 108 is used to accept time inputs from the user terminals. In one embodiment. acceptance unit 108 accepts the data from the user terminals 104,

verifies content and format, and makes the data available for checking and verification.

Processing system 112 performs processing on the verified data to perform accounting functions such as tax, bookkeeping, payroll, and other appropriate functions. As a result, accounting data is generated. Accounting data can include, client and project billing data, payroll data, tax reporting data, and other bookkeeping and accounting related data.

FIG. 2 is an operational flow diagram illustrating a process by which the invention can be utilized for the entry and tracking of employee time in accordance with one embodiment. In a step 204, a temporary employee enters his/her time information into user terminal 104. Preferably, in one embodiment, such entry is accomplished utilizing a keypad or other data entry device associated with user terminal 104 as discussed below. A display screen can be provided to allow the employee to view the information entered as it is being entered.

In one embodiment the user terminal allows time to be tracked for multiple projects, multiple clients or a combination of both. In this embodiment, the employee enters the appropriate or applicable project and client codes, as well as the time spent on each project or for each client. This embodiment is desirable where an employee may work on several projects or for several different clients in a given day. This embodiment allows the time spent for each matter to be separately tracked and tallied.

In an alternative embodiment, the user terminal only supports time entry for a single client or project. In this embodiment, there is no need to enter a project or client identification. The employee need only enter the time spent for a given periodic interval. For example, the employee may be asked to enter a daily total of the hours worked for each day. The advantages of this embodiment over that previously described are a simplified user interface as well as less complex data processing requirements.

In one embodiment, the employee enters the time spent working on a project. In an alternative embodiment, user terminals 104 have the ability to track elapsed time spent on projects with a built-in timer function. Specifically, in one embodiment, the employee enters a project or client code and starts the timer. The timer keeps track of elapsed time until the timer is stopped. In this way, the employee can use user terminal

104 to track elapsed time worked on one or more projects or for one or more clients.

In one embodiment, user terminals can include start and stop keys (or their functional equivalent) which the employee can use to start, stop and restart the timer to track elapsed time.

In one embodiment the employee also enters an employee identification number or other employee identification code such that his or her time entries can be identified as his or hers when they are subsequently collated with entries of other employees. In a preferred embodiment, this entry is accomplished utilizing the keypad or other data input device associated with user terminal 104. Alternatively, this entry can be made, for example, utilizing an encoded label reader such as, for example, a magnetic stripe reader, a bar code reader, or other reader for reading an encoded label. In one example implementation of this embodiment, the employee may have an encoded label such as a magnetic stripe on his or her employment badge. This stripe can be scanned and the identification of the employee entered into user terminal 104.

In yet another embodiment, each user terminal 104 can have a precoded unique identification such that time entries can be identified as being associated with a specific user terminal 104. Where each employee is assigned his or her individual user terminal, the employee's identification can be inferred from the identification of the user terminal 104 in which the time is entered.

In a step 208, the employee verifies the information he or she entered in user terminal 104. As described above, because in one embodiment the entries are displayed as they entered, the user can verify in real time his or her entries.

Additionally, in one embodiment, the user terminal can recall previously entered records which are stored in a local memory or other storage in user terminal 104. In this embodiment, the employee can verify past entries made, including individual entries, totals and subtotals. For example. at the end of the work week or other periodic interval, the employee may wish to go back and review each of the entries made for that week or period. During this review, the employee can be provided with totals and or subtotals indicating, for example, the total number of hours worked for that employee. the number of hours worked for that employee on a particular project, as well as totals and subtotals for periodic increments such as daily. weekly, or monthly subtotals. Note

that as discussed above, in one embodiment the user terminal does not track time entries on a project-by-project basis, but instead only tracks a daily total of time worked by the employee. In this embodiment the review process allows, for example, the employee to review his or her daily totals, as well as the cumulative weekly total.

In a step 212, a supervisor, the client, or other appropriate individual can confirm and authorize the entries made. The entries can be checked on a daily, weekly, or other periodic increment and provide, for example, a unique confirmation or authorization for the entries. The entries can be reviewed based on employee number, project number, time period indication (i. e., day, week, month, etc.) and the number of hours or amount of time charged to a project. Preferably, client authorization is required before the timekeepers entries are forwarded to a processing system 112 for billing and other accounting purposes. Alternatively, a means is provided for authorization to be waived.

In one embodiment, such authorization is made before the entries are provided to acceptance unit 108. In an alternative embodiment, such authorization is made after the entries are provided to acceptance unit 108 and before they are forwarded to processing system 112. Because in one embodiment, processing system 112 collates entries among various user terminals, it is preferable that the authorization be performed before processing system 112 performs this function. In this manner, review can be simplified and errors can be caught and corrected before collation.

In one embodiment, a four-digit authorization code is entered after a prefix is entered. In one example application of this embodiment, three prefixes are contemplated. A first prefix indicates a non-authorized message and is followed by a default or waived authorization code, such as, for example, all zeros. A second prefix is used to indicate a customer specific number held in the central database. With this prefix, no checking is performed on the authorization code and the authorization code is hidden from view by acceptance unit 108 and processing system 112. A third prefix indicates full authorization in comparison with week, customer number, and the time entered.

In one embodiment, the prefix can be sent with the data to indicate the type of authorization used. Alternatively, the prefix can be stored centrally. In one embodiment of the central storage implementation, acceptance unit 108 does not verify

the authorization. In this embodiment, verification can be performed after delivery of data and a status message is communicated to user terminal 104 depending on the data's validity.

In a step 216, the confirmed entries are provided to processing system 112 so that they can be collated with those of other employee. In a step 220, receipt of the entries by the processing system 112 is confirmed. In one embodiment, data is validated by processing system 112 prior to processing. Processing system 112 can respond with a positive response indicating that the data received is correctly formatted, and that it has passed validation.

The interface between user terminal 104 and acceptance unit 108 can be analog or digital and can be provided via a hard-wired or wireless communications interface.

In one embodiment, the communications interface is provided utilizing an intelligent exchange system using ISDN30 standard.

As discussed above, acceptance unit 108 performs a verification on the data.

Preferably, the data received from user terminals 104 is checked to determine that the content is correctly formatted and that all of the appropriate fields are complete.

Additionally, the data can be checked to ensure that errors have not been introduced in transport. This check can be accomplished, for example, using a cyclic redundancy check (CRC) or simple checksum, although alternative error detection and correction techniques can be utilized.

In one embodiment, acceptance unit 108 replies to user terminal 104 in the affirmative when the data is verified as being correct and complete. In one embodiment, this is audible feedback in the form of a generated tone or a vocal response. If the data is not correct, the user is asked to retransmit the data and/or to correct any errors which may have occurred in the entry of the data prior to retransmission.

FIG. 3 is an operational flow diagram illustrating an example process by which acceptance unit 108 can perform verification testing on data received from user terminals 104. In a step 304 the data are received from user terminals 104. In an embodiment where data is transmitted in the form of audible signals over a telephone line, the tones are translated into digital data. In an embodiment where authorization

is provided at the user terminals, the validation and authorization of the data are checked.

In a step 312, the data format and content are verified as an integrity check. For example, if the user is required to complete entries for fields such as an employee identification, a project number, and the number of hours worked, acceptance unit 108 checks to determine that each of these fields is complete and that a valid entry is made for each field. Acceptance unit 108 can also check fields such as a time sheet number or user terminal 104 ID. For example, in one embodiment, acceptance unit 108 maintains a list of valid project and employee identifications. In this example, acceptance unit 108 can check each entry against the corresponding list to at least ensure that the entry can be found on the list and is, therefore at least valid. As another example, acceptance unit 108 can check to ensure that an employee is authorized to charge time to a specific client or a specific project.

The checks can look at data items such as the unit number, the week or period number, the employee verification, a customer identification, a project number, or other information. For example, entries which are too old, or indicate an incorrect or missing employee verification are flagged as possibly erroneous. A check against a"blacklist" of units or a list of terminated employees can also be carried out to ensure that unwanted entries are not collated.

Pre-defined conditions or ranges can be established for automatic flagging of errors or other anomalies. Data entered can be checked against the ranges or conditions to determine if the data is valid. For example, there may be a predefined condition that prohibits an employee from billing more than 24 hours in a given day. In this example, acceptance unit 108 may check to ensure that an employee's time entry for a given day does not exceed this predefined maximum.

In a similar vein, the system can check for multiple entries from a single employee covering the same time period, multiple entries from a given a user terminal 104 for a given time period, or other similar duplication checks. Handling of unauthorized messages or messages determined to be suspect can be accomplished, for example, by manually investigating and correcting the anomaly, returning the anomalous entries to the employee for correction, returning them to the client or

supervisor for correction, automatically deleting duplicate entries, or other appropriate correction techniques.

Where there are no unauthorized or potentially erroneous messages, the messages are forwarded to processing center 112 where they are processed and acceptance unit 108 notifies user terminal 104 that the data has been accepted. This is illustrated by steps 318, 320. If an error is discovered in the verification process, an error message is sent back to the user terminal 104 from which the data originated. This is illustrated by a steps 318,324. The error message, for example, can indicate that data was corrupt and request retransmission, or it can indicate the data is not authorized and request a retransmission of corrected data.

In one embodiment, data received is collated and processed such that appropriate accounting information can be determined. In the collation step, the data from a user terminal 104 is combined with data from other user terminals 104 to provide a comprehensive data file of the time entries. Preferably, in one embodiment, the data is collated to a standard formatted ASCII file. In an alternative embodiment, the entries are combined in a relational database and can be retrieved and manipulated based on fields, such as, for example, employee identification, project/client identification, time periods, etc. Hourly rates can be assigned to employees for billing purposes. In processing, a bill amount can be determined from the hourly rates and time billed for the employees and can also include additional fee or cost items. From the collated information, employee paychecks, client bills and other accounting or bookkeeping records or data items can be generated.

FIG. 4 is a block diagram illustrating an example architecture that can be used to implement user terminal 104. The example architecture illustrated in FIG. 4 includes a processor 404, a display 412, a speaker 416, an input interface 420, a local memory 408, local storage 424, a communications interface 428, a power source 440, and a central bus 442. Although a central bus architecture is illustrated in FIG. 4, alternative bus or interconnection architectures can be implemented. Additionally, alternative functional or physical architectures can be implemented to carry out the described functionality.

Processor 404 controls the operation of user terminal 104. Preferably, processor 104 executes a series of program instructions which are embodied on a computer program media and which instruct the processor in carrying out the desired functionality. Processor 404, in response to the program instructions, controls the operation of the various components and devices of user terminal 104. In one embodiment, processor 404 is for example, a PentiumX or X86 processor. In an alternative embodiment a PIC (programmable interface circuit) processor is used.

Data storage is provided to store the computer instructions as well as the time entries entered by the employees, as well as other data useful for the operation of user terminal 104. The data storage can be implemented utilizing either or both a local memory 408 and local storage 424. The storage devices can be implemented utilizing memory or data storage devices such as random access memory (RAM), read-only memory (ROM), magnetic or optical disc storage, or other memory or storage devices.

Preferably, in one embodiment, the program instructions are stored in ROM or on disc storage. The time records or logs entered by the user can be temporarily stored in RAM and subsequently recorded or logged onto more permanent storage such as disc storage.

A display 412 is provided so that the employee can view his or her entries as they are being entered, as well as to recall for display instructions, previously entered data, or other information. Display 412 can be implemented utilizing display devices such as, for example, active or passive matrix displays, liquid crystal displays (LCD), CRT displays, touch screen displays, or other display devices. Preferably, in a hand held portable environment, the display device is a low-power consuming device such as, for example, an LCD. In one embodiment, display is a 2 x 8 display size for displaying data as illustrated in the example of FIG. 6. Alternative display sizes and display formats can be implemented.

Speaker 416 provides an audible interface to the user of user terminal 104.

Additionally, speaker 416 can be utilized to audibly emit DTMF (dual tone multiple frequency) tones. In this embodiment, the DTMF tones can be utilized to dial a phone, and speaker can be used to establish a connection with acceptance unit 108. The speaker can further be used to transmit the data from user terminal 104 to an acceptance unit 108 at a remote location via the established telephone link. The actual data

transmission can be via DTMF tones, by modem signaling, or by other audible signaling techniques. Where DTMF tones are utilized, a DTMF tone generator (not illustrated) can included in the architecture to facilitate this embodiment. In this embodiment, there is no need for an employee to have access special communications interfaces. The employee can initiate the data transfer from any telephone.

Input interface 420 is provided to allow the employee to enter his or her time and other information into user terminal 104. In one embodiment, input interface 420 is a keyboard or keypad including keys which can be used for the appropriate time entries.

In one embodiment, a numeric keypad is sufficient to enter the information. However, in alternative embodiments, character or alpha-numeric keypads can be utilized.

Additionally, interface 420 can include function keys for one-touch initiation of one or more predefined functions or macros.

A communications interface 428 can be provided to facilitate the communication between user terminals 104 and acceptance unit 108. Communications interface can be implemented utilizing a hard-wired or wireless interface and can include, for example, an RS-232 interface, an optical or infrared interface, a cellular interface, a telecommunications modem, or other communications device. In an application where communications occur via a telephone line, an RJ45 connection can be implemented, for example. Communications device 428 can be provided in place of or in addition to a DTMF tone generator/speaker combination as discussed above.

In yet another embodiment, communications interface 428 can be implemented utilizing a cradle for accepting user terminal 104. Cradle and user terminal 104 can be provided with mating connectors which, when user terminal 104 is inserted into the cradle, make an appropriate optical or electrical connection to complete the interface.

Regardless of the communications interface implemented, in a preferred embodiment acceptance unit 108 is capable of receiving multiple simultaneous transmissions from several user terminals 104.

A power supply 430 is provided to power user terminal 104. In a hand-held portable environment, power source 430 can be implemented utilizing, for example, batteries. In this embodiment. preferably rechargeable batteries such as Nickel-Cadmium (NiCad) or Nickel-Metal-Hydride (NiMH) batteries can be utilized.

An A/C power source can be provided to power user terminal 104 or to recharge the batteries.

FIG. 5 is a block diagram illustrating an example implementation of a user terminal 104 according to one embodiment of the invention. FIG. 5 illustrates a front or top view 504 as well as a back or bottom view 508. User terminal 104 includes display 412 for displaying the appropriate information. As discussed above, in one embodiment, display 412 displays the time entries made by the employee on user terminal 104. Because of the nature of this intended use for the device, it is not necessary that display 412 be a large display device. In fact, in a preferred embodiment, display 412 is a 2 by 16 character display capable of showing a rolling screen.

Input interface 420 is illustrated in FIG. 5 as being implemented utilizing a 12-key keypad having the keys 0-9 as well as an asterisk and octalthorpe keys. A serial number 512 can be printed on the bottom of user terminal 104 for identification purposes.

In the twelve key keypad implementation, the octalthorpe can be used to move between fields and screens while the asterisk can be used for backward movement.

Time entry is entered utilizing the numeric keys and the fields can be of fixed length to facilitate movement between fields.

The keyboard can also be enhanced to include function keys to allow ease of use.

Function keys can allow one-touch invocation of certain specified or preferred functions, features or operations.

Speaker 416 is illustrated as being disposed on back panel 508 of user terminal 104. Additionally, a panel 514 for battery access is also located on rear panel 508 in this embodiment. The example implementations illustrated in FIGS. 4 and 5 are provided to facilitate discussion by way of example only. As would be apparent to one of ordinary skill in the art after reading these discussions, user terminal 104 can be implemented utilizing a variety of different architectures and implementations, different from those pictured and described.

A number of different data formats can be utilized for entry of the time and related information. FIG. 6 is a diagram illustrating a sample screen display showing a rolling screen of 2 by 16 characters. As illustrated in FIG. 6, each day of the week

(Monday through Sunday) is illustrated with a space for time entry beneath it. A weekly total is also displayed. The total can be automatically calculated from the daily entries. Also illustrated is a display field for the authorization code entered by the authorizing client. In one embodiment, the actual code entered is not displayed (alternatively, asterisks can be displayed) to protect the secrecy of the authorization code. The embodiment illustrated in FIG. 6 corresponds to an embodiment wherein the user enters his or her time in hours and minutes for each day.

Preferably, in one embodiment, a booking number is also used. According to one implementation of the booking number, the first two digits of the booking number represent a week and a further five digits provide a unique number. A final eighth digit can be provided as a check digit which can be verified upon entry into user terminal 104 as well as at acceptance unit 108.

In one embodiment, each user terminal carries with it a unique identification.

This unique identification is stored in data storage in user terminal 104 and is preferably not alterable without appropriate authorization. This identification can be included in data streams to provide identification and/or verification of the transmitted time records.

This identification can be recorded when the user terminal 104 is assigned to an employee such that the user terminal identification can be utilized to further identify the employee.

In one embodiment, multiple Atimesheets@ can be created and stored in a user terminal 104. In this embodiment, any or all of these timesheets can be transmitted to acceptance unit 108 during a data transmission. In a basic embodiment, all of the data present in a user terminal 104 is transmitted during a given transmission. The data is maintained until an authorization or conformation is received, an then deleted. As such, there is no need for a user to identify which data in the entire set of data should be transmitted. In an alternative embodiment, the user can determine which data set of a plurality of datasets should be transmitted on a given transmission.

Acceptance unit 108 and processing system 112 can be implemented utilizing, for example, a Pentium or X86-based processing system such as a personal computer.

Although illustrated as separate boxes in FIG. 1, it will be apparent to one of ordinary skill in the art after reading this description that the described functionality can be

implemented utilizing a single processing system. In one embodiment, however, acceptance unit 108 is a stand-alone unit as illustrated.

Acceptance unit 108 can include multiple input channels for accepting data from multiple user terminals 104 simultaneously. In a preferred embodiment, this is accomplished using separate hardware for each channel. One embodiment utilizes two PIC processors for each channel, plus one coordinating processor for managing the communications interface to processing system 112.

The various embodiments of the invention and their components or subsystems described above may be implemented using hardware, software or a combination thereof and may be, as stated, implemented in a computer system or other processing system. In fact, in one embodiment, these elements are implemented using one or more computer systems capable of carrying out the functionality described with respect thereto. An example computer system 702 is shown in FIG. 7. The computer system 702 includes one or more processors, such as processor 704. The processor 704 is connected to a communication bus 706. Various software embodiments are described in terms of this example computer system. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

Computer system 702 also includes a main memory 708, preferably random access memory (RAM), and can also include a secondary memory 710. The secondary memory 710 can include, for example, a hard disk drive 712 and/or a removable storage drive 714, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 714 reads from and/or writes to a removable storage medium 718 in a well known manner. Removable storage media 718, represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 714. As will be appreciated, the removable storage media 718 includes a computer usable storage medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory 710 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 702. Such means can include, for example, a removable storage unit 722 and

an interface 720. Examples of such can include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 722 and interfaces 720 which allow software and data to be transferred from the removable storage unit 718 to computer system 702.

Computer system 702 can also include a communications interface 724.

Communications interface 724 allows software and data to be transferred between computer system 702 and external devices. Examples of communications interface 724 can include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 724 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 724. These signals are provided to communications interface via a channel 728. This channel 728 carries signals and can be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of a channel can include a phone line, a cellular phone link, an RF link, a network interface, and other communications channels.

In this document, the terms Acomputer program medium@ and Acomputer usable medium@ are used to generally refer to media such as removable storage device 718, a hard disk installed in hard disk drive 712, and signals on channel 728. These computer program products are means for providing software to computer system 702.

Computer programs (also called computer control logic) are stored in main memory and/or secondary memory 710. Computer programs can also be received via communications interface 724. Such computer programs, when executed, enable the computer system 702 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 704 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 702.

In an embodiment where the elements are implemented using software, the software may be stored in a computer program product and loaded into computer system 702 using removable storage drive 714, hard drive 712 or communications

interface 724. The control logic (software), when executed by the processor 704, causes the processor 704 to perform the functions of the invention as described herein.

In another embodiment, the elements are implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art (s). In yet another embodiment, elements are implemented using a combination of both hardware and software.

4. Conclusion While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.