WO2000068819A1 - Apparatus and process for electronic filing of forms - Google Patents

Abstract

An apparatus and process for the electronic filing of forms with an entity. The apparatus, referred to as a filing center ('filing center'), enables an entity ('outside world') to electronically file a form containing communications commands and data with the filing center. The filing center comprises a protocol manager which manages communication between the entity and the center; a command negotiator which determines the order of commands and data sent and received by the protocol manager; a command dispatcher which turns each command and data received from the command negotiator into a job, the job processing a form; a job queue which stores the job until it can be processed; a process schedule which assigns priorities to each job in the job queue, regulates job volume, and routes each job to be executed; and a pluarlity of command processes, wherein groups of command processes execute a particular type of job.

Description

APPARATUS AND PROCESS FOR ELECTRONIC FILING OF FORMS

FIELD OF THE INVENTION

The invention relates to an electronic apparatus for document filing, and more particularly to an apparatus suitable for use by a government for receiving a variety of completed forms such as tax forms. BACKGROUND

Electronic filing can be used to quickly transmit information to some sort of receiving entity. Common examples include income tax information filed at the Internal Revenue Service (IRS); sales tax information filed with state and local government tax agencies; licensing forms filed with a state licensing authority; medical history and billing information filed with a medical insurance company; and loan applications filed with a bank. In each case, the receiving entity requires a standard set of information. For example, the IRS requires identity information, financial information, deduction information, etc, for each taxpayer. Prior to electronic filing systems, most such information was provided on paper forms which were mailed to the entity and had to be processed by hand and transcribed into computers by data entry clerks.

Electronic filing systems provide several advantages over paper-based filing. Electronic filing allows much quicker filing with the receiving entity and quicker responses from the receiving entity. There are inherently fewer errors in using such a system because the need for transcription of information from the paper forms is reduced or eliminated. There is a reduction in the amount of paper used and thus there is conservation of natural resources. Finally, there is a significant reduction in labor cost, as fewer people are required to run the filing. Despite their advantages, existing electronic filing centers have several disadvantages.

Most existing filing systems are large, complex, and must be custom designed for each application. The result is that electronic filing systems are very difficult and expensive to design, implement and maintain, meaning that the large entities who can afford the systems end up spending a lot on them, and smaller entities who cannot afford the systems end up having to do without a filing system which could vastly improve their efficiency. In addition, because such systems are custom-tailored to each customer they tend not to be very flexible. If the entity wants to add, subtract, or otherwise change the standardized set of information they require to be submitted, such changes must be implemented through extensive and expensive programming changes. A tax agency such as the IRS is a good example: frequent changes in the tax laws lead to frequent changes in the forms that taxpayers must file every year. Such changes in required tax information usually set off a round of expensive programming changes in the IRS's electronic filing system.

Given the disadvantages of the electronic filing systems presently available on the market, there is a need for a filing system that can handle a large variety and volume of standardized information sets while being easily customizable to modify existing information sets or add new ones. In addition, there is a need for a filing system that can run on a variety of platforms so that it can be implemented without the need for a lot of capital expense on new computer hardware. The present invention provides such a filing system.

SUMMARY OF THE INVENTION

The present invention provides an apparatus and process for the electronic filing of forms with an entity. The apparatus, referred to as a filing center, enables an entity to electronically file a form containing communications commands, service commands and data with the filing center. The filing center comprises a protocol manager which manages communication between the entity and the form filing center; a command negotiator interfaced to the protocol manager, the command negotiator determining the order of commands and data sent and received by the protocol manager; a command dispatcher interfaced to the command negotiator, the command dispatcher turning each command and data received from the command negotiator into a job, the job processing a form; a job queue interfaced to the command dispatcher, the job queue storing the job until it can be processed; a process scheduler interfaced to the job queue, the process scheduler assigning priorities to each job in the job queue, regulating job volume, and routing each job to be executed; and a plurality of command processes interfaced to the process scheduler, wherein groups of command processes execute a particular type of job.

The process by which the filing center operates comprises establishing communication with the entity, receiving a form from the entity, converting the form received from the entity into a job, each job processing one or more types of forms, queuing the jobs until they can be executed, each job in the queue being assigned a priority, scheduling each job for execution according to its priority and according to the availability of execution resources, and executing each job.

The filing center may be implemented, among other ways, as a computer operative to establish communication with the entity through the device pool; receive commands and data from the entity; convert all commands and data received from the entity into jobs, each job processing one or more types of forms; queue the jobs until they can be executed, each job in the queue being assigned a priority; schedule each job for execution according to its priority and availability of execution resources; and execute each job according to its priority.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a system diagram and flow chart illustrating the elements of the inventive apparatus and the steps in the inventive process.

DETAILED DESCRIPTION OF THE INVENTION Figure 1 illustrates an embodiment of the apparatus and process of the present invention. The embodiment shown is an apparatus and process (collectively referred to as a "filing center") which enables an entity to file commands and data contained in a form with a central filing authority. The entity may be an individual, a business, a government agency, or a tax collection agent. The central filing authority is usually a government entity, but may also be a private entity. Forms that may be filed include tax forms, medical insurance forms, and the like.

The apparatus and process include twelve separate elements. Of these twelve elements, seven perform the basic functions, while the remaining five perform supporting functions. The seven basic elements include a device pool which enables the entity to connect to the filing system; a protocol manager interfaced to the device pool which manages the communication between the entity and the filing center; a command negotiator which determines the order of commands sent or received by the filing center and ensures that commands received complies with the filing center's standard commands; a command dispatcher which turns received commands into jobs which can be executed by the filing center; job queues which hold the jobs until they can be executed; process schedulers which schedule and optimize the execution of each job; and command processes which actually process the jobs. Each of these seven elements is described in further detail below.

The five elements performing support functions include: an event system which notifies the filing center of parts thereof if certain event occur; a storing and forwarding system to store and forward information sent to the entity; a filing system for storing and maintaining the filing center's master files; global logs to log and track different aspects of the filing center's operation; and a ticker and billing system to log and track billable transactions occurring on the filing center. The support elements are further described below. Although described below as a filing center set up on a computer, the filing center could just as easily be set up to run on several connected computers, or could be made using a custom-designed piece of hardware for each of the elements of the filing center. Device Pool

The first element of the apparatus comprises one or more device pools. A device pool is the first point of contact between the filing center and the entity and is the physical layer of communications. A device pool comprises a group of one or more similar devices sharing a common communications method and protocol. Entities attempting to communicate with the filing center can use a common device pool for different services, but all must comply to the same set of rules for data transfer. Examples of device pools include a set of modems for dial- ins, a dedicated ISDN line, WAN link or Internet access.

Every device pool is controlled by its own dedicated protocol manager. The protocol manager is the software layer of communications and is discussed in more depth below. In conjunction, the device pool and the protocol manager isolate all aspects of communications from the rest of the filing center. The device pool and protocol manager ensure that all incoming communications adhere to the filing center's standard communications command structure, and that all outgoing communications adhere to the communication requirements of the entity. This allows entities to communicate with the filing center using different methods and protocols. Such flexibility is important for communications between the filing center and existing legacy systems.

A device pool can be configured to accept incoming calls only, initiate outgoing calls only, or both. In all cases, the device pool is responsible for synchronization and handshaking. If synchronization and handshaking are successful, the device pool assigns a communications handle to each connection. This handle is passed to the protocol manager with every incoming communications command and is used by the filing center to supply immediate, on-line responses when appropriate, for instance, sending a requested file. Upon instruction from the protocol manager, the device pool may terminate a connection.

In operation, the device pool may accept an incoming communication or attempt to connect with an external device, depending on its configuration. When the filing center transmits to the entity, the instruction to initiate an outgoing call is sent to the device pool by the protocol manager.

As configured, the device pool handles synchronization and handshaking. If unsuccessful, the device pool terminates the entity's attempt to connect to the filing center. If synchronization and handshaking are successful, the device pool waits to receive the first submitted command from the entity. As further explained below, this will usually be a standard CallerlD communications command. The device pool sends all submitted communications commands to the protocol manager along with the communications handle of the connection.

The device pool sends all responses from the filing center to the entity. If the response is an error text string, the device pool sends the error message and terminates the entity's connection. The device pool informs the protocol manager if the connection is prematurely terminated by the external device or due to line error. Protocol Manager (Layer 2)

Each device pool has an associated protocol manager. The protocol manager is the software layer of communications, and interfaces both with its associated device pool and with a command negotiator shared with other protocol managers. The device pool and its associated protocol manager work together and are added for each customized communication platform and protocol. The protocol manager's function is to validate and authorize entities attempting to access the filing center and to ensure that all data to be shared with the filing center (starting with the Command Negotiator) conforms to the filing center's standard service command structure.

The protocol manager sends communications commands to, and receives communications commands from, the entity. As further described below, the command negotiator recognizes only a few communication commands. These communication commands wrap up the many different service commands used by the filing center. The service command, its two parameters and filename (if any) are parameters of the communication command. Throughout the communication process, the protocol manager makes entries in a transmission history log. In most configurations, the protocol manager supports simultaneously multiple devices from a single device pool. The protocol manager accomplishes this through time-sharing techniques or by being multi-threaded. The standard communication commands and parameters are:

(LEN) (TID) (PWD) (current user info) - or -

CallerlD (ACK/NACK)

Request (CmdlD) (PI) (P2) (filename)

Accept (CmdlD) (Pi) (P2) (filename)

(CmdlD) (PI) (P2) (filename) - or -(ACK/NACK)

Submit

(CmdlD) (PI) (P2) (filename) - or -(ACK NACK)

ISubmit (Job ID)- or -(NACK)

Receipt

Done (no parameter)

The functions of each of the commands is as follows:

CallerlD (LEN) (TID) (PWD) (current user info-username, company, phone & available STIDs). Information sent by the entity for user authorization by the filing center. (LEN) is the length of the entire command string. (TID) is the identification number set up in the filing center for an authorized transmitting computer. (PWD) is the password shared by the filing center and transmitting computer for that transmitting computer. This password is assigned by the filing center the first time the transmitting computer communicates; this password cannot be viewed or accessed on either side, only erased by a filing center administrator. (Current user info) is a variable string that contains the username, company, phone number and STIDs available to the user logged into the transmitting computer.

CallerlD (ACK/NACK). Acknowledgment by the filing center whether the user is authorized to send commands. (ACK) means the user is authorized. (NACK) means there is an error with authorization and that the entity should resubmit the CallerlD command. If there is not an error but the user is not authorized to communicate, the filing center returns an error text string and hangs up.

Request (CmdlD) (PI) (P2) (filename). Request by the entity to send a specific service command. This request is either granted or denied by the Command Negotiator. (CmdlD) is the identification number of the service command. This number is unique system- wide. (PI) and (P2) are the two parameters standard to any service command. (Filename) is the name of the attached file, if any, for the service command assigned by the entity. The file may be a filed form, e-mail message, etc. Request (NACK). Response from the Command Negotiator when the specifically requested service command is rejected (for instance, STID is off-line) and there are no outstanding service commands on the Precedence Table. The entity program can request a different service command or hang up. Accept (CmdlD) (PI) (P2) (filename). Response from the Command Negotiator on whether the request is granted or denied for a specific service command. See Request above for an explanation of same service command parameters.

Submit (CmdlD) (PI) (P2) (filename). Submission from an entity of a specific service command. See Request above for an explanation of same service command parameters.

Submit (ACK/NACK). Confirmation from the filing center to a submission of a service command. (ACK) means the filing center officially accepts the submitted service command and will either receive or send the designated "attached" file. (NACK) means the filing center is unable to accept the submitted service command and cannot send or receive the designated "attached" file.

ISubmit (CmdlD) (PI) (P2) (filename). Submission from an entity of an interactive specific service command. This interactive service command receives highest priority by the filing center as the entity is waiting for an immediate response before requesting to submit another command. See Request above for an explanation of same service command parameters.

ISubmit (ACK/NACK). Confirmation from the filing center to a submission of an interactive service command. See Submit (ACK NACK) above for an explanation of the same (ACK NACK) parameter.

Receipt (JoblD). Confirmation from the filing center that the service command has been successfully accepted for processing by returning the job identification number (JoblD) after the service command file has been transferred. If the file is being sent to the filing center, the Command Dispatcher sends the Receipt (JoblD) via the protocol manager. If the file is being sent from the filing center, the command process that sends the file also sends the Receipt (JoblD) via the protocol manager. Receipt (NACK). Warning from the filing center that the command was not successfully turned into a job and therefore was not be processed. If a file was being sent from the entity to the filing center, the Command Dispatcher was probably unable to pick up the file and create the job. If a file was being sent from the filing center to the entity, the command process was probably unable to create or access the file to send back to the entity. Done. Signal that the next action taken by the entity will be to terminate the connection. This is used to determine the length of a call and whether the communication was interrupted.

In operation, the standard protocol manager is responsible for accepting communications commands from the entity, passing recognized commands to the command negotiator, and vice-versa. After synchronization and handshaking are completed by the device pool, the protocol manager receives the communications handle for the connection. This communication handle is sent to the command negotiator with every Submit or ISubmit command. The protocol manager waits for the first command sent by the entity which must be

CallerlD (with parameters). When the command is received, the protocol manager checks to see if the command is structured correctly and if it is, whether the entity is authorized to call the filing center and that the password is correct. If all conditions are true, the protocol manager returns a CallerlD ACK command. If any condition is false, the protocol manager returns an error text string and hangs up.

Once the entity successfully connects to the filing center, the protocol manager waits for the next communications command to be sent by the entity. The protocol manager only accepts properly formatted Request, Submit and ISubmit communications commands from the entity. If a different command is sent or the command is not properly formatted, the protocol manager returns an error text string and hangs up.

The protocol manager passes the Request, Submit or ISubmit command to the command negotiator along with the TID and communications handle, and waits for the response from the command negotiator. The protocol manager only accepts Request, Accept, Submit ACK/NACK, ISubmit ACK/NACK and Receipt communications commands from the command negotiator. When it receives a response from the command negotiator, the protocol manager sends the response from the Command Negotiator to the entity.

After the protocol manager sends a Receipt communications command to the entity, the protocol manager only accepts another Request or the Done communications command. If the protocol manager receives Done in any other sequence, the protocol manager records an error in the transmission history log. The above steps, with the exception of establishing a connection, are repeated until the connection is terminated by either the protocol manager or entity.

If a particular entity requires a different communications protocol and method, a device pool and protocol manager can be set up and customized for that entity. "Pre-processing" steps are added to convert the data sent by the entity to meet the filing center standard command structure and process. The protocol manager then sends recognizable commands to the Command Negotiator and Dispatcher as normal. In all cases, entities must start by passing an acceptable user authorization process. The protocol manager must support a Send Error Application Program Interface (API) call that passes error text messages from Command Negotiator to the entity before hanging up. It must also support the Get File API call that receives a file from an entity. The protocol manager receives a file and assigns it a system- wide unique filename. The call returns the file and an acknowledgment that the transfer was successful. Additionally, the protocol manager must support the Send File API call (with the communications handle, file identification number (FilelD) and job identification number (JoblD) as parameters) that sends a file to an entity using the designated communications handle. If the transfer was successful, the routine is also responsible for sending a Receipt communications command with the JoblD to the entity using the same communications handle to confirm the command was successfully processed. The call returns an acknowledgment that the transfer was successful. Command Negotiator

All protocol managers pass communication commands to the command negotiator, which is multi-threaded and is always available for each protocol manager request. The command negotiator approves or denies every request from an entity to send a specific service command. If a request is accepted, the command negotiator then passes the accepted, submitted commands to the command dispatcher. If a request is denied, the command negotiator suggests which command takes precedence and that the entity tax program should request instead. If the filing center or a particular service type is shut off, the command negotiator returns an error text string and the protocol manager hangs up. The command negotiator can also throttle or stop communications by limiting the amount of commands accepted per hour.

To determine whether a particular service type (i.e., a particular command process) is available, the filing center maintains a Service Type ID (STID) Gate table as shown below.

STID Gate Table

STID

Off-Line Flag

• Off-line text message

This table may only be changed by filing center administrators. When a Request command is received, the service type for the service command (CmdlD) is looked up on the STID Gate Table. The service type is then referenced to the STID Gate Table. The filing center administrators set the text message that is displayed when the service type is off-line.

The Precedence Table shown below is used to see if another command has a higher precedence than the command submitted by the entity (i..e., the CmdlD for the Request command). Precedence Table

CmdlD PI P2

TID

Username

Precedence #

Flag(s)

Sticky Delete

The precedence table is changed by the filing center administrators or by a command process via the event system (described below). A specific service command can be given a specific precedence by adding it to this table, setting the precedence number, and entering a wildcard value in the TID and Username fields. A different precedence number can be given for the same service command for a specific user by adding a similar record but including a specific TID and username. A user-specific precedence is always used in place of a wildcard precedence when both exist for the same service command.

After the connection is complete, user specific service command precedent entries will be removed (by setting the Delete flag) from the table unless the Sticky flag is set. This allows commands to get higher precedence for the next connection only. Service commands with wildcards in the TID and Username fields are never deleted after a call.

The Throttle Table shown below is used to control the volume for a specific service type, service command or transmitter (TID). This is primarily used to limit or stop transactions by the government (by throttling/stopping service types or service commands) or transmitters (by throttling/stopping TIDs) to prevent sizable, delinquent accounts. The only difference between throttling and stopping is the value set for Requests/hour. To gate a condition, the Requests/hour entry would be set to zero (0) so that Request command always exceeds the maximum number allowed per hour. To throttle, this value is set to a non-zero, positive number.

The command negotiator manages a global variable for every entry in the Throttle Table. After a Request command passes all other checks, the command negotiator checks to see if an entry in the Throttle Table limits the service type, service command or transmitter. If so, the command negotiator checks to see if the appropriate global variable exceeds the maximum number for that throttle. If so, the command negotiator sets the Enabled Flag in the table that acts like an off-line switch. If the maximum hasn't been exceeded, the appropriate global variable is incremented. Each hour, the Event System sends notification to the command negotiator to reset all global variables. All fields for this table, except for the Enabled Flag, are modified only by the filing center administrators using special administration commands. STID, CmdlD and TID fields contain either values or wildcards. The Enabled Flag is modified by the Command Negotiator dynamically based on transaction volumes. The Requests/hour field is the maximum number of Request commands that can be made relating to specific service type (STID), service command (CmdlD PI P2) or transmitter (TID). The throttle text message is the text string that is returned if the maximum number of Request commands has been exceeded for that throttle.

Using values and wildcards, the following conditions can be identified for throttling or gating: service type for all transmitters; service type for a specific transmitter; specific service command for all transmitters; and specific service command for a specific transmitter. In operation, the command negotiator first receives a Request communications command from a protocol manager and checks to see if the service type for the requested service command is available. If not, the command negotiator returns a text string (set by filing center administrators) and waits for a new Request. If the command negotiator determines that the service type is available, it checks to see if a different service command has higher precedence. If so, the command negotiator returns a Request command where the (CmdlD) parameter is the identification number of the higher precedence service command. The Command Negotiator then confirms that the same Request command and parameters are echoed back by the entity program. If not, the Command Negotiator returns an error text string and hangs up.

The command negotiator next checks the Throttle Gate table to see if a service type, service command or user (TID and username) is being limited or stopped. If so, the command negotiator sees if the maximum number of commands has been exceeded. If it has, the command negotiator returns an error text string (set by the filing center administrators) and waits for a new Request.

If all checks are passed, the command negotiator returns an Accept command with the same parameters as the approved Request command. The command negotiator then confirms that next command sent is an Submit or ISubmit with the same parameters as the accepted command. If a different command is sent or the parameters are wrong, the Command Negotiator returns a Submit NACK command and waits for a new Request. The command negotiator adjusts the global throttle variables (as needed), and adjusts the sticky entries in the Precedence table. The command negotiator passes the Submit or ISubmit command and its parameters

(including TID and communications handle) to the command dispatcher and returns a Submit ACK or ISubmit ACK command to the entity. Service commands, like Pick Up Message and Send Batch, must be sent with a certain submission communications command. Service commands that demand on-line response by definition must be sent with ISubmit, like Pick Up Message. Service commands that cannot be interactive by definition must use the Submit communications command, like Send Batch. The command negotiator returns an I/Submit NACK if the service command type does not match the submission type of the communications command. Command Dispatcher The command negotiator passes Submit and ISubmit communications commands to the command dispatcher. The command dispatcher strips the service commands from the communications commands and turns them into jobs. These jobs are then placed in the appropriate job queue. In some cases, the command dispatcher may receive a Submit or ISubmit communications command from a command process. In these cases, the command dispatcher returns the job identification number assigned to the command to the command process.

Each job assigned to a command process is created by adding data to the standard service command structure (CmdlD PI P2 File), as shown in the table below.

JoblD is the job's identification number; this number is always unique. JoblD is the how all data accepted, processed, etc. is referred to by the filing center. Jobs also contain TID, the time received by the Command Dispatcher and the COMM handle needed for on-line responses. Priority is also added by the command dispatcher to the job.

Priority is the order the job will be processed in the job queue. Jobs created from ISubmit commands receive the highest priority, since immediate, on-line responses are required. It is possible for several jobs to share the same priority. In these cases, the jobs are processed in order received (FIFO). The command dispatcher sets priority based on the service command (CmdlD).

Group Priority Table Cmd Group Table

STID CmdlD

• CmdGroupID CmdGroupID

Description

• Priority

Unavailable Flag

When a new service type is added, filing center administrators need to create an entry in the Group Priority Table. By adding a command group identification number (CmdGroupID) and description, service commands can be added to a group and a priority can be assigned to that group relative to other groups. Service commands can belong to more than one group and, in these cases, the command dispatcher assigns the highest possible priority to the job. Groups can have the same priority. The Unavailable Flag allows groups to be set up but not affect priorities until later. This may be used by administrators to customize priority grouping for anticipated peaks or other special situations. In operation, the command dispatcher first receives a Submit or ISubmit command from the command negotiator or a command process. The Command Dispatcher checks to see if a file needs to be picked up based on the service command (CmdlD). If so, the command dispatcher uses the Get File API call to tell the protocol manager to pick up the file. The command dispatcher receives the file and acknowledges that the file transfer was successful. The command dispatcher records the time and date and assigns the job identification number (JoblD). If the command was submitted by a command process, the command dispatcher returns the JoblD to the command process. The Command Dispatcher looks up the priority for all available groups (CmdGroupID) associated with the service command (CmdlD). The Command Dispatcher assigns the highest priority to the job. The Command Dispatcher passes the entire job to the appropriate job queue based on the service type (STID) for the service command (CmdlD).

For service commands that used the Get File API call, the Command Dispatcher sends a Receipt communications command along with the job identification number (JoblD) using the communications handle. The Command Dispatcher notifies the Event System that a job was just added for a specific service type (STID). API calls need to send Submit or ISubmit communications command from command processes. This call returns the JoblD for the submission. API calls also need to be available so that priorities, priority groups and the unavailable flags can be added and modified by filing center administrators and command processes. Job Queues After each job is processed, it is placed in the job queues, which track each job using the information in the table below.

There is one job queue for each service type ID (STID). Job queues receive jobs from the command dispatcher. Jobs added to the job queue have a status of Waiting. When processing begins for a job, its status changes to Processing and the time processing began is recorded. When processing is completed, its status changes to Completed. Job queues are regularly cleaned to remove completed jobs.

In operation, the job queue receives a job from the command dispatcher and sets the status of the added job to Waiting. Process Scheduler

Each job queue is interfaced to one process scheduler. The process scheduler maintains the number of available command processes, assigns jobs in the job queue to command processes, and monitors each job's progress. By cleverly maintaining the number of available command processes, the process scheduler ensures that the proper balance of system resources is being utilized. Moreover, by cleverly assigning jobs to command processes and monitoring progress, the process scheduler efficiently ensures that the highest priority jobs are processed

Class Maintenance Table Command Class Table

ClassID CmdlD

Description ClassID

Thread Count

Unavailable Flag as soon as possible. The process scheduler uses the following tables to determine how many instances of each command process can be running simultaneously.

Installing a new service type (i.e., a new command process) creates the Class Maintenance and Command Class Tables. Classes are added to the Class Maintenance Table by adding a ClassID and descriptive name. The number entered in the Thread Count field determines the maximum number of instances (or threads) of a command process available at any time. The Unavailable Flag allows classes to be set up but are ignored by the process scheduler. These tables allow administrators to customize classes and thread count for anticipated peaks or other special situations. Service commands (CmdlD) can belong to more than one class. In these cases, the total number of threads available for a service command in several classes is the sum of the thread count of each available associated class.

Fundamentally, the process scheduler checks to see which command processes are available. The process scheduler then checks to see if jobs are waiting in the job queue for those specific available command processes. If so, the process scheduler assigns the highest priority jobs to the available command processes. To assign a job, the process scheduler changes the status of the job in the job queue to Processing, enters a Begin Time, and passes the job identification number (JoblD) to the available command process. When a command process is finished, it alerts the process scheduler, which changes the status of the job to Completed and checks to see if another job is waiting for the same command process. The cycle repeats over and over.

The process scheduler should be optimized to reduce the number of cycles needed to accomplish the same tasks. If all command processes are busy, the process scheduler can be designed so that it waits until a command process is available before continuing regardless of the number of event system notifications sent for new jobs added to the job queue. If the job queue is empty, the process scheduler can be designed so that it waits for an event system notification for a new job before it bothers polling command processes for availability. If all jobs in the queue are waiting for the same command process, the process scheduler needs to only check the availability of that command process, not all command processes. Optimization using these or other ideas will have a dramatic impact on system performance as the endless diligence of the process scheduler requires less processor cycles to complete.

The process scheduler must also be able to handle exceptions during standard processing to prevent serious problems or delays. For example, the process scheduler could determine that a specific job and command process thread has locked up since the time the job has been in Processing exceeds an expected time allowance. Since jobs can be added to the job queue at any time, the process scheduler could also regularly check that a Waiting job hasn't been missed for an available command processes. Although the process scheduler may be optimized to ignore certain event system notifications (like new job added) or other system signals, the process scheduler could notify the event system to regularly send notifications back so that the process scheduler could confirm that nothing was missed and that the system is processing normally. Strong exception handling will greatly improve the reliability of a very critical area of the filing center. In operation, the process scheduler receives notification from the event system

(described below) that a new job has been added to the job queue or is alerted that a command process thread has finished. The process scheduler polls command processes for availability. The process scheduler assigns the highest priority, older jobs needing the available command processes by changing their status to Processing and passing the job identification numbers (JoblD) to the command processes. If a thread has finished, the process scheduler changes the status of the finished job in the job queue to Completed.

In addition, the process scheduler checks to see that all active jobs are still within acceptable time allowances set for each command process. If any active job goes outside the set time allowance, the process scheduler sends the Jobld to an error handling routine. If everything is okay, the process scheduler waits for another job to be added or a command process to complete. Command Processes

Command processes are the core of the filing center. All the preceding elements are the mechanism for service commands to get to the command processes to be completed. Each service type supports a certain number of service commands. Each service command has at least one command process associated with it. Installing a service type adds these service commands and command processes and updates all appropriate tables.

Command processes are multi-threaded. This allows the code to be developed and maintained in one spot only. Threading (instead of simultaneously running executables) is more efficient, actually using less system resources to accomplish the same tasks. Command processes can also share subroutines.

Command processes can yield many effects and outputs. A command process may add or modify an existing entry in a table. A command process may also have an effect on the filing center itself. For instance, a command process may send notification to the event system to initiate a different event or it may affect the command negotiator by changing the precedence of a specific command for all transmitters or a specific TID. Also, a command process may change the thread count for a specific command process, allowing more (or less) instances to be used. A command process may, and often will, generate a new service command. After adding the Submit or ISubmit communications command, the newly created communications/service command is sent to the Command Dispatcher, the job identification number is returned and the newly created command is processed like normal. A command process may (and will often) generate messages to be sent to an entity. These messages are placed in the Store-n-Forward and, in many cases, cause a Pick Up Message service command to get precedence in the Precedence Table for that entity.

By definition, ISubmit communications command require an immediate response from a command process. Often the entity is requesting to receive a specific file(s). After the command process accesses or creates the file, it makes a Send File API call to the protocol manager and passes the communications handle, file identification (FilelD), and job identification (JoblD) as parameters. The API call returns acknowledgment that the transfer of the file and Receipt was successful. A command process should not generate a new service command requiring an ISubmit communications command as it delays the response to the entity. When finished, the command process tells the process scheduler which job was successfully completed. The process scheduler then changes the status of the job to Completed and assigns it the highest priority job needing that process.

In operation, the command process receives a job identification from the process scheduler. The command process accesses the job queue to pick up parameters and the associated file, when available. The command process executes the job and notifies the process scheduler when it is finished. Executing a job may involve any of the following: adding or changing entries in a table; adding entries to a log (like the billing audit log); initiating an event via a notification to the event system; changing a specific command precedence in the Precedence Table; changing the thread count for a specific command process; generating additional commands that are sent to the command dispatcher; generating messages which are saved in Store-n-Forward (see below); and sending the requested file to an entity using the Send File API call. Event System The event system is the alarm clock of the filing center. All elements of the filing center send and receive notifications from the event system. These notifications can cause the different areas to perform specific tasks. Notifications can be time-based, or can be responses to other events.

All notifications are handled through API calls. The event system supports different notification API calls. Examples of two notifications are alarm clock and stop watch. Alarm clock allows an area to request to be notified when a specific time has passed (like midnight). Stop watch allows an area to request to be notified after a specific amount of time (like 60 minutes) has passed. Any element of the filing center that may need to accept a notification from the event system must have its own specific notification API call. The event system is job independent. The event system is never aware of actual jobs, only how to respond to a timed event or notification received. The event system may know that a specific event occurred (like a job being added to a job queue) but it does not know the specific job that triggered the event. This design allows for a more global, customizable system. The event system supports time-based notifications. The event system can send notification when a specific time of the day has been reached (Alarm Clock API call). This allows filing center administrators to schedule automatic operations, for instance, purging and rebuilding tables in the middle of the night or automatically taking service types off-line after business hours. The event system supports event-based notifications. Different areas of the filing center can send notifications to the filing center that a certain event has occurred. In response, the event system can send a different notification to a different area or program. For instance, the command dispatcher can send notification to a specific process scheduler that a new job has been added to its job queue via notifications to the event system. The event system can also recognize and initiate its own notifications based on the "state" of the filing center. For example, the event system can recognize that specific table needs to be purged and re-built by recognizing the table has exceeded a certain number of records with a specific condition (like archive and remove).

Sophisticated event determination and notification routines can easily be developed and added to the filing center using combinations and variations of time-based and/or event-based notifications. This allows future, more complex filing center demands to be easily integrated and supported with no impact to existing filing center architecture. For instance, the event system can perform system maintenance activities in the middle of the night, such as taking service types off-line so that specific tables can be purged and re-built at 3:00 a.m., assuming no activity has occurred for those service types in the last 90 minutes.

Store-n-Forward

All messages to be sent to an entity are stored in Store-n-Forward. This is the filing center's global outbox. Messages can be e-mail, filed forms, payment transfer requests, acknowledgments, system notifications, status updates, etc. Messages stay in Store-n-Forward until all recipients successfully receive the message.

When a sent message is processed, an entry is first made in the Store-n-Forward Table shown above. The Send Message command process starts by assigning a system-wide unique Message ID and entering the current time in the Added Time field. Then information is entered for the TO List, CC List, From User, STID, Reference ID, Message Priority, Message File ID and Attachment File ID List fields. Reference ID is assigned by the entity program and provides a mechanism to associate Message IDs with the entity's identification system (since Message ID equals the Reference ID + TID). Outbox Table

TID

Username

STID

Message ID

•Successfully Sent Time

The Send Message command process then uses the TO and CC Lists to make entries in the Outbox Table shown above. Aliases and logical names are converted to single entries in this table (see Aliasing below). The STID filed is a copy of the STID shown in the Store-n- Forward table. When a user sends a Pick Up Message command for all messages, the command processes uses the Outbox table to determine the number of messages waiting to be sent for that user.

After a message is sent to an entity, the command process enters the time in the Successfully Sent Time field in the Outbox Table and the Last Successfully Sent field in Store- n-Forward. The command process also increments the # Successfully Sent field. A message stays in the Store-n-Forward Table until the number of recipients equals the number of successfully sent messages. Old entries in the Store-n-Forward and Outbox Tables must be regularly archived and purged. Filing center administrators can use the Last Successfully Sent Time field to quickly determine when the usefulness of a message has been exceeded. If a user is removed from the Outbox before associated messages are successfully sent, the # Recipients field needs to be adjusted.

In addition to single user recipients, messages can also be sent to aliases or logical names. Aliases allows filing center administrators to quickly set up and support commonly used groups of users or logical names. Logical names can be used for easier administration or to hide the transmitter (TID) and username identification for a single user from a mail recipient.

Alias Definition Table Alias List Table

• Abas ID Alias ID

• Description (lc gical name) TID Flag

ID (TID or Alias ID)

User (username)

To set up an alias or logical name, a entry is made in the Alias Definition Table, shown above. After an alias is defined, a user can be added to the Alias List Table by setting the TID flag, entering a TID in the ID field and username in the User field. A different alias can be added to an alias group by not setting the TID Flag and entering an Alias ID in the ID field instead. The User field is ignored unless the TID flag was set.

In most cases, when a message is added to Store-n-Forward and Outbox Tables for a specific user, an entry is made in the Preference Table so that the next time the user communicates with the filing center, one of the first commands that must be completed is Pick

Up Message.

If the Alias List Table is updated, filing center administrators need to determine on a case-by-case basis whether existing messages with the same alias should also receive the message. If so, an entry should be made in the Outbox table and the # Recipients field for that message modified. Once a message is sent to all designated entities, Store-n-Forward creates a log entry and removes the message from this area.

File Shelves

The File Shelves keeps track of all permanent files available to the filing center.

Examples of permanent files may be product downloads, patches, and first time user messages. These files can be sent two different ways. In the case of immediate download, the files are accessed by the command process responding directly to an entity command such as Get

Product. Otherwise, the files are sent in the standard fashion using Store-n-Forward. The message's text or attached file identification refers to the file(s) in the File Shelves.

Global Logs Global logs allow the filing center manufacturer and filing center administrators to recreate communications, jobs, batched messages, event sequences, and billable transactions.

In addition, the filing center itself may use these logs to perform certain administrative functions. All global logs are secure and cannot be modified.

There are five global logs, including one or more Transmission History Log(s); a Job Log; a Ticker Audit Log (discussed below); a Make File Log; and an Event Log. Each log is created and maintained for a different purpose. A transmission history log exists for each protocol manager. For standard protocol managers, the transmission history log records the beginning of each communication attempt, every communications command submitted by the entity during the call, file transfer information, assigned job identification numbers, and the end of every call. Based on the order of entries, these global logs allow any (and every) communication to the filing center to be recreated as needed as well as provide insightful reporting information.

Transmission history log entries are made regardless of whether the communication is initiated by the entity or by the filing center. Each entry in the log is its own line (or record). Since it is possible to have more than one simultaneous connection, the entries for a single call may be mixed with entries for different calls. However, the entries are in order and the communication handle is used to distinguish one call from another. Therefore, it is important that the communications handle is recorded for every entry to the transmission history log. In operation, the transmission history log works as follows. The protocol manager makes a StartCall entry that includes the communications handle, start time, dial-in versus dial-out, baud speed, and level of error correction (if available). This signifies the beginning of a call. The protocol manager records the CallerlD communications command as sent by the entity along with the communications handle; however, password information is not saved in the log. This shows transmitter and user information.

The protocol manager records every communications command sent by the entity along with the communications handle. If an error occurs, such as when transmitter authorization fails, the protocol manager makes an Error entry along with the communications handle and error information. Based on the order of Request and I/Submit communications commands, it is possible to determine the Command Negotiator responses as well as the service commands actually submitted.

For every file transferred, the protocol manager makes a FileTransfer entry recording the communications handle, direction (incoming or outgoing), filename, FilelD as assigned by the filing center, and size of the file. The protocol manager also records the Receipt (JoblD) communications command from the filing center along with the communications handle. This allows every submitted service command to be traced to a unique job identification number and is important for matching the transmission history logs with the global Job Log.

When the protocol manager receives a Done communications command after sending a Receipt, the protocol manager makes an EndCall entry which contains the communications handle, end time, and line quality information, if available. If the communication was interrupted, this entry will be missing for the log and the next entry for that communications handle will be StartCall. If the protocol manager terminates the call for any reason, the protocol manager includes the error information at the end of the EndCall entry. Based on this information, it is possible to determine the length of each call and the number of untimely disconnections. If possible, information that shows the number of rings before the call was answered, the number of failed synchronization attempts and the number of calls turned away due to full circuits (for instance, if the device pool is a PBX) should also be captured and recorded in the transmission history log for the device pool. The Job Log accounts for the processing of every job created by the Command

Dispatcher. Matched up with the appropriate transmission history log and Ticker Audit Log, it is possible to follow every job through the filing center as well as double checking billing records. The Job Log records several stages during the "life" of a job. These stages include creating the job; beginning the command process; creation of significant by-products during the command process, such as batched messages or new service commands; completing the command process; and errors that prevent the successful completion of job processing.

One entry exists in the Job Log for each of these stages. Each entry in the log is its own line (or record). The entries will not be sequential, and the job identification number is used to distinguish between different job entries. In operation, the job log works as follows. The Command Dispatcher makes a NewJob entry in the Job Log for job identification number assigned to a service command. This entry includes JoblD, creation time, user information (TID + username), STID, CmdlD PI P2 and FilelD (for any incoming file). The process scheduler makes a Start Job entry in the Job Log when it changes the status of a job in a job queue to Processing. This entry includes JoblD and start time.

Command processes may make a Joblnfo entry as appropriate. These entries include the JoblD, CmdlD, time, and other pertinent information as defined for each command process for this entry. For the Send Batch service command, this is a list of JoblDs for each service commands included in the batch. For Pick Up Message(s), this is the FilelD that corresponds to an entry in the Make File Log. In some cases, the command process may record information results if needed to reconstruct job processing, for instance, the number 42.

The process scheduler makes a CompleteJob entry in the Job Log when it changes the status of a job in a job queue to Completed. This entry includes the JoblD and completion date. An Error entry can be made to the Job Log at any time. This entry must include JoblD, time and error message. Ticker Audit Log

The Ticker Audit Log is the itemization of all billable transactions and is used for billing purposes. Make File Log It is common for command processes, like Pick Up Message(s), to access Store-n-

Forward and create a batch file containing many messages. The command processes then send this batch file to the waiting entity via the protocol manager using the job's communications handle. The Job Log contains the FilelD of the batch file. The Make File Log lists all Message IDs that were included in a batch file as well as the time the batch was created. By matching the FilelD from the Job Log with the FilelD in the Make File Log, it is possible to trace a particular Message ID to a specific batch file to its job which then can be traced to the originating communications/service command request in the transmission history log which also shows the user (TID + username) that submitted the command. Because messages are archived and not destroyed, the Job Log and Make File Log can be used to easily reconstruct and re-sent messages. Each new file added to a batch has its own entry in the log. As many batches may be created simultaneously, the entries may not be sequential. The batch FilelD is used to distinguish the different batched files.

As a batch file is being created, the command process makes an AddFile entry in the Make File Log. The entry includes the batch file's identification number (FilelD), the time the message was added to the batch, and the message's identification number (Message ID). A new entry is made for each file added to the batch. Event Log

The event log records all notifications sent to and from the event system and records significant milestones of the event routines as defined by each event routine. The Event Log is used for reporting purposes and to ascertain the series of the events that lead up to a particular occurrence or incident. Ticker & Billing

The Ticker and Billing System keeps track of all billable transactions, allows general invoicing and itemizations, reflects payments, and supports pre-paid accounts (if used). This system should not be considered or compared to an Accounts Receivables program. However, this system does allow the filing center manufacturer to keep track of revenue generating activities, provides a mechanism to invoice for these items, and can automatically generate warnings and gate or throttle users or transactions.

The Charges Table below identifies which service commands (CmdlD PI P2) are billable transactions and lists each charge. This table can be viewed by filing center administrators, but can only be modified by the filing center manufacturer. The charge amount may be in foreign or US currency; however, this must be consistent for one installation.

Charges Table

Billable Command

The Ticker Audit Log tracks all billable transactions. As a command process finishes a service command (CmdlD PI P2), the command process checks the Charges Table to see if the completed service command is a billable event. If the service command is included in the Charges Table, the command process makes an entry in the Ticker Audit Log that contains the JoblD, time of completion, STID, User (TID + username), service command and descriptive string (optional). The descriptive string can be used to better identify the transaction for invoicing/itemization purposes. For instance, the descriptive string may be the name of a form, its period and amendment information. These entries can be viewed by filing center administrators and the filing center manufacturer but never modified. Adjustments and/or corrections can only be made to this log using offsetting new entries. Auditing of this table can be done against the Job Log. Payers

The filing center is designed to support a sole payer (for instance, a country's tax administration) or groups of individual payers (for instance, a company of tax preparers). This is set up by creating payer groups and then assigning all transmitters to a specific payer group.

Master Payer Table Payer/TID Table

Payer ID • Payer ID

Description TID

• Billing Address, Contact Information These payer groups are set up in the Master Payer Table shown above. In the case of a sole payer, the filing center manufacturer sets up one payer group and the table cannot be modified by filing center administrators. Descriptive name, billing address and contact information is also included in this table. If multiple payer groups are supported, filing center administrations can add payer groups. In either case, the filing center administrators add records in the Payer/TID Table. Before an authorized transmitter can be added to the filing center, the filing center administrators must add the transmitter (TID) to the Payer/TID Table and associate the transmitter with a Payer ID. Even if the transmitter will be paying for its own transactions, the transmitter must still be entered in the Master Payer Table to receive a Payer ID to be entered in the Payer/TID Table. The Restrictions field(s) enables the filing center to throttle or gate STIDs or service commands for the payer group. Entries in these fields cause event notifications to be sent to the Command Negotiator via the Event System and affect the Throttle Table, as appropriate. Summary Log The Summary Log is similar to the Make File Log. Regularly, the filing center administrators will generate invoices or statements that summarize new billable transaction information for a specific payer for a given period. An entry is made in the Summary Log for every billable transaction entry in the Ticker Audit Log included in a summary (whether an invoice or statement). The summary is given a Summary ID. When all summaries have been completed, the Summary Log associates the JoblDs of each entry in the Ticker Audit Log (which is all billable transactions) with a Summary ID. This log can be used to determine which billable transactions have not yet been invoiced or included in a statement. The Summary Log is updated automatically through administrative accounting functions provided by the filing center. Billing Log

The Billing Log is similar to a standard accounting double entry ledger. Every Summary ID in the Summary Table must have an associated entry in the Billing Log. Each entry includes the Payer ID, time, Summary ID and total charges for that summary. This information can be incorporated into the filing center administrator's existing A/R program as a receivable. When payment is received, the filing center administrator can make a new entry to the Billing Log that includes the Payer ID, payment date, payment identification information assigned by the filing center administrator and the total payment received. This log can be used to determine the outstanding account balance of a specific payer, the last date of payment, etc. In the cases where all accounts must be pre-paid, this payment information for a Payer ID is recorded here.

In the case of pre-payments, the Ticker and Billing System needs to monitor individual payer accounts and limit or turn off STIDs, service commands or transmitters (as defined) as accounts become overdrawn. In the case of standard invoicing, the system should monitor for defined thresholds and gate or throttle transmitters as desired. In both cases, warnings should be sent to the filing center administrator and filing center administrators in advance as well as at the time of throttling/gating.

In the case of standard invoicing for a sole payer, the system should also monitor when a certain volume of transactions have accumulated to automatically begin certain processes. For instance, the filing center administrator may wish to be notified when a certain volume of billable transactions has been reached. This may cause the filing center to initiate communications with the filing center administrator and set the precedence such that the first command submitted by the filing center administrator is to check billing.

Claims

1 A form filing center enabling an entity to electronically tile a lorm containing communications commands, serv ice commands and data, the filing center compπsing

(a) a protocol manager, the protocol manager managing communication between the entity and the form filing center.

(b) a command negotiator interfaced to the protocol manager, the command negotiator determining the order of commands and data sent and receiv ed by the protocol manager,

(c) a command dispatcher interfaced to the command negotiator, the command dispatcher turning each command and data received from the command negotiator into a job, the job processing a form.

(d) a job queue interfaced to the command dispatcher, the job queue stoπng the job until it can be processed,

(e) a process scheduler interfaced to the job queue, the process scheduler assigning pπoπties to each job in the job queue, regulating job volume, and routing each job to be executed; and

(f) a plurality of command processes interfaced to the process scheduler, wherein groups of command processes execute a particular type of job

2. The form filing center of claim 1 further compπsing a device pool interfaced to the protocol manager, the device pool compπsing a group of communication devices that share a common method and protocol of communication, and the de\ ιce pool assigning a communication handle to the entity communicating w ith the filing center

3 The form filing center of claim 2 w herein the de\ ιce pool compπses modems, an ISDN line, an internet connection, or a voice response system

4 The form filing center of claim 1 wherein the command negotiator throttles or stops communication betw een the entity and the filing center

5 The form filing center of claim 1 wherein the command negotiator throttles or stops communication betw een the entity and one or more command processes

6 The form filing center of claim 1 wherein the protocol manager \ ahdates and authoπzes the entιt\ attempting to use the filing center

7 The foπn filing center of claim 1 w herein the protocol manager translates received commands into standard communication commands w hich can be understood b> the filing center

8 The form filing center ot claim 1 w herein the job queue maintains the priority of w aiting jobs

9 The lorm filing center of claim 1 herein the command dispatcher extracts the service command from each communication command received from the entity, the serv ice command denoting a group of one or more command process which will execute the form. assigns a unique job identification number to each job, assigns a pπoπty to each job, and records the communication handle of the particular job, the communication handle identifying the entity and allowing the filing center to communicate with the entity

10 The form filing center of claim 1 w herein the command dispatcher receives commands from a command process

1 1 The form filing center of claim 1 wherein the process scheduler polls the command processes for availability and assigns the highest pπoπty jobs in the job queue to the appropπate and available command process

12 The form filing center of claim 1 wherein the process scheduler peπodically checks the status of each job in the job queue

13 The form filing center of claim 12 wherein the process scheduler saves time by not checking the job queue until it is notified by an event system that a job has been added to the job queue

14 The form filing center of claim 1 wherein each command process is initiated by the process scheduler

15 The form filing center of claim 1 wherein each command process notifies the process scheduler when a job is complete

16 The form filing center of claim 1 wherein the process scheduler archives each job executed by the command processes

17 The form filing center of claim 1 herein each command process generates additional service commands that can be sent to the command dispatcher

18 The form filing center of claim 1 further compπsing an e ent system that notifies the filing center or specific elements thereof in response to event notifications received, a storage and forwarding system for stoπng and forwarding data to be delivered to the entity, a master storage system for stoπng the filing center's master files, patches, and other downloadable information. a log system to permanently store information and filing center statistics, and a billing system to track and audit billable transactions conducted using the filing center

19 A form filing center enabling an entity to electronically file a foπn containing communication commands, ser ice commands and data, the filing center compπsing (a) a dev ice pool, the dev ice pool comprising a group of communication dev ices that share a common method and protocol of communication.

(b) a protocol manager interfaced to the de ice pool, the protocol manager v alidating and authoπzing the eπtitv attempting to use the filing center, and managing communication betw een the entity and the form filing center.

(c) a command negotiator interfaced to the protocol manager, the command negotiator determining the order of commands and data sent and received b\ the protocol manager and the command negotiator throttling or stopping communication between the entity and the filing center,

(d) a command dispatcher interfaced to the command negotiator, the command dispatcher extracting a service command from the communication command received from the entity, the service command denoting the command process w hich w ill execute the form, and the command dispatcher turning each command and data receiv ed from the command negotiator into a jobs, each job processing a form,

(e) a job queue interfaced to the command dispatcher, the job queue stoπng the jobs until they can be processed,

(f) a process scheduler interfaced to the job queue, the process scheduler assigning pπoπties to each job, regulating job v olume, and routing each job to be executed, and

(g) a plurality of command processes interfaced to the process scheduler, wherein groups of command processes execute a particular type of job and notify the process scheduler when execution is complete

20 The form filing center of claim 19 wherein the device pool compπses modems, an ISDN line, an internet connection, or a voice response system

21 The form filing center of claim 19 wherein the command negotiator throttles or stops the flow of communication between the entity and the filing center by compaπng the service command in the entities form against a throttle table listing a permissible number of jobs having that service type

22 The form filing center of claim 19 wherein the protocol manager translates received commands into standard communication commands that can be understood by the filing center

23 The form filing center of claim 19 wherein the job queue maintains the pπoπty of waiting jobs

24 The form filing center of claim 19 w herein the command dispatcher assigns a unique job identification number to each job, assigns a priority to each job, and records a communication handle of the particular job. the communication handle identifvins the entitv and allow ing the filing center to transmit data to the entitv

25 The form filing center of claim 19 wherein the command dispatcher receiv es commands from a command process

26 The form filing center of claim 19 wherein the process scheduler polls the command processes for av ailabilitv and assigns the highest pnoπtv jobs in the job queue to the appropπate and available command process

27 The form filing center of claim 19 wherein the process scheduler peπodically checks the status of each job in the job queue

28 The form filing center of claim 27 wherein the process scheduler saves time by not checking the job queue until it is notified by an ev ent sv stem that a job has been added to the job queue

29 The torm filing center of claim 19 wherein each command process is initiated by a process scheduler

30 The form filing center of claim 19 wherein the process scheduler archives each job executed by the command process

31 The form filing center of claim 19 wherein each command process generates additional service commands which can be sent to the command dispatcher

32 The form filing center of claim 19 further compπsing an event system that notifies the filing center or specific elements thereof in response to event notifications received from elements of the system, a storage and forwarding system for stoπng data to be delivered to the entity and forwarding that data to the entity, a second storage system for stoπng the filing center's master file, patches, and other downloadable information, a log system to permanently store information and filing center statistics, and a billing system to track and audit billable transactions conducted using the filing center

33 A process enabling an entity to electronically file a form containing communication commands, serv ice commands and data using a form filing center, the process compπsing

(a) establishing communication w ith the entity,

(b) receiv ing a form from the entity, conv ening the form receiv ed from the entitv into a job. each job processing one or more types of forms.

(c) queuing the jobs until thev can be executed, each job in the queue being assigned a pπoπty,

(d) scheduling each job for execution according to its pπoπtv and according to the availabilitv of execution resources and (e) executing each job

34 The process of claim 33 further comprising prioritizing commands recei ed from the entitv and replying first to interacti e requests

35 The process of claim 33 w herein establishing communication w ith the entity compπses establishing a connection betw een the entity and a device pool, assigning a communication handle to the entity, and managing the communication between the entity and the filing center

36 The process of claim 33 further compπsing sending commands and data to the entity using the entity's communication handle

37 The process of claim 33 wherein converting the form into a job compπses extracting a service command from the form, the service specifying how the job will be processed, assigning a unique job identification number to the job, assigning a pπoπty to the job, and recording a communication handle for the job

38 The process of claim 33 wherein scheduling the job for execution compπses polling the execution resources to assess their availability, and assigning the highest pπoπty job m the queue to an appropπate and available execution resource

39 The process of claim 33 wherein executing the job compπses processing the form according to a set of processing rules, and transmitting a notification upon completing the job

40 The process of claim 33 further compπsing notifying the filing center or specific elements thereof in response to event notifications received from the filing center, stoπng data to be delivered to the entity and forw arding the data to the entity, stoπng the filing center's master file, patches, and other downloadable information, logging information and filing center statistics, and tracking and auditing billable transactions conducted using the filing center

41 A process enabling an entity to electronically file a form containing commands and data using a form filing system, the process compπsing

(a) establishing communication w ith the entity and assigning a communication handle to the entity,

(b) receiving a form from the entitv .

(c) transmitting commands and data to the entitv using the communication handle, (d) converting the form received from the entitv into a job, each job processing one or more types of forms,

(e) queuing the jobs until they can be executed, each job in the queue being assigned a pπoπty.

(0 scheduling each job for execution according to its pπoπty and according to the availability of execution resources, and (g) executing each job

42 The process of claim 41 further compπsing immediately replying to interactive communications commands received from the entity

43 The process of claim 41 further compπsing sending commands and data to the entity

44 The process of claim 41 wherein converting the form into a job compπses extracting a service command from the form, the service command denoting which command process will execute the job, assigning a unique job identification number to the job, assigning a pπoπty to the job, and recording the communication handle for the job

45 The process of claim 41 wherein scheduling the job for execution compπses polling the execution resources to assess their availability, and assigning the highest pπoπty job m the queue to an appropπate and available execution resource

46 The process of claim 41 wherein executing the job compπses processing the form according to a set of processing rules, and transmitting a notification upon completing the processing of the job

47 The process of claim 41 further compπsing notifying the filing center or specific components thereof in response to event notifications receiv ed from specific components of the filing center, stoπng data to be delivered to the entity, stoπng the filing center's master file, patches, and other downloadable information, logging information and filing center statistics, and tracking and auditing billable transactions conducted using the filing center

48 A. form filing center enabling an entity to electronically file a form containing communication commands, service commands and data, the form filing center compπsing a computer connected to a dev ice pool, the computer being operative w ith a program stored thereon to

(a) establish communication with the entity through the dev ice pool, (b) receive commands and data from the entity,

(c) convert all commands and data receiv ed from the entitv into jobs, each job processing one or more types of forms,

(d) queue the jobs until they can be executed, each job in the queue being assigned a pπoπty,

(e) schedule each job for execution according to its pπoπty and availability of execution resources, and

(f) execute each job according to its pπoπty

49 The form filing center of claim 48 herein the computer compπses a plurality of computers networked together

50 The form filing center of claim 48 wherein the computer is further operative to pπoπtize commands received from the entity and reply first to interacti e requests

51 The form filing center of claim 48 wherein the computer establishes communication with the entity by being operative to establish a connection between the entity and a device pool, assign a communication handle to the entity, and manage the communication between the entity and the filing center

52. The form filing center of claim 48 wherein the computer is further operative to send commands and data to the entity using the entity's communication handle

53 The form filing center of claim 48 wherein the computer converts the form into a job by being operative to extract a service command from the form, the service specifying how the job will be form filing centered, assign a unique job identification number to the job, assign a pπoπty to the job, and record the communication handle for the job

54 The form filing center of claim 48 wherein the computer schedules the job for execution by being operative to poll the execution resources to assess their availability, and assign the highest pπoπty job in the queue to an appropπate and available execution resource

55 The form filing center of claim 48 wherein the computer executes the job by being operative to process the form according to a set of form processing rules, and transmit a notification upon completing the job

56 The form filing center of claim 48 wherein the computer is further operative to notify the filing center or specific elements thereof in response to event notifications received from the filing center, store data to be delivered to the entity and forwarding the data to the entity, store the filing center's master file, patches, and other downloadable information, log operating information and filing center statistics, and track and audit billable transactions conducted using the filing center

57 A form filing center enabling an entity to electronically file a form containing communication commands, service commands and data, the form filing center compπsing a computer connected to a device pool, the computer being operative with a program stored thereon to-

(a) establish communication with the entity through the device pool and assign a communication handle to the entity,

(b) receive commands and data from the entity, transmit commands and data to the entity using the communication handle assigned to the entity,

(c) convert all commands and data received from the entity into jobs, each job processing one or more types of forms,

(d) queue the jobs until they can be executed, each job in the queue being assigned a pπoπty;

(e) schedule each job for execution according to its pπoπty and availability of execution resources, and

(f) execute each job according to its pπoπty

58 The form filing center of claim 57 wherein the computer compπses a plurality of computers networked together

59 The form filing center of claim 57 wherein the computer is further operative to immediately reply to interactive communications commands received from the entity

60 The form filing center of claim 57 wherein the computer converts the form into a job by being operative to extract a service command from the form, the service command denoting which command process will execute the job, assign a unique job identification number to the job, assign a pπoπty to the job, and record the communication handle for the job

61 The form filing center of claim 57 herein the computer schedules the job for execution by being operative to poll the execution resources to assess their a ailability, and assign the highest pπoπty job in the queue to an appropπate and available execution resource

62. The form filing center of claim 57 wherein the computer executes the job by being operative to: process the form according to a set of processing rules; and transmit a notification upon completing the processing of the job.

63. The form filing center of claim 57 wherein the computer is further operative to: notify the filing center or specific components thereof in response to event notifications received from specific components of the filing center; store data to be delivered to the entity, store the filing center's master file, patches, and other downloadable information; log information and filing center statistics; and track and auditing billable transactions conducted using the filing center.