|Numéro de publication||WO2000068819 A1|
|Type de publication||Demande|
|Numéro de demande||PCT/US2000/012841|
|Date de publication||16 nov. 2000|
|Date de dépôt||10 mai 2000|
|Date de priorité||10 mai 1999|
|Numéro de publication||PCT/2000/12841, PCT/US/0/012841, PCT/US/0/12841, PCT/US/2000/012841, PCT/US/2000/12841, PCT/US0/012841, PCT/US0/12841, PCT/US0012841, PCT/US012841, PCT/US2000/012841, PCT/US2000/12841, PCT/US2000012841, PCT/US200012841, WO 0068819 A1, WO 0068819A1, WO 2000/068819 A1, WO 2000068819 A1, WO 2000068819A1, WO-A1-0068819, WO-A1-2000068819, WO0068819 A1, WO0068819A1, WO2000/068819A1, WO2000068819 A1, WO2000068819A1|
|Inventeurs||Teri Ann Howe, John L. Dilley, Brian Scheffer, Nina Wright, Michael Crovitz, Lloyd Hawes|
|Déposant||Transenda International Llc|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (5), Classifications (9), Événements juridiques (7)|
|Liens externes: Patentscope, Espacenet|
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 -
Request (CmdlD) (PI) (P2) (filename)
Accept (CmdlD) (Pi) (P2) (filename)
(CmdlD) (PI) (P2) (filename) - or -(ACK/NACK)
(CmdlD) (PI) (P2) (filename) - or -(ACK NACK)
ISubmit (Job ID)- or -(NACK)
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
• 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
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
• CmdGroupID CmdGroupID
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.
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
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.
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
•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)
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
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.
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.
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
• 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.
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US5109512 *||31 mai 1990||28 avr. 1992||International Business Machines Corporation||Process for dispatching tasks among multiple information processors|
|US5481698 *||15 mars 1993||2 janv. 1996||Hitachi Ltd.||Computer system and job executing method|
|US5528513 *||4 nov. 1993||18 juin 1996||Digital Equipment Corp.||Scheduling and admission control policy for a continuous media server|
|US5905908 *||19 déc. 1997||18 mai 1999||Datascape, Inc.||Open network system for I/O operations with non-standard I/O devices utilizing extended protocol including device identifier and identifier for operation to be performed with device|
|US6058373 *||16 oct. 1996||2 mai 2000||Microsoft Corporation||System and method for processing electronic order forms|
|Classification internationale||G06Q10/00, H04N1/32, G09B7/00|
|Classification coopérative||G06Q10/10, H04N1/324, G09B7/00|
|Classification européenne||G06Q10/10, G09B7/00, H04N1/32F2|
|16 nov. 2000||AL||Designated countries for regional patents|
Kind code of ref document: A1
Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG
|16 nov. 2000||AK||Designated states|
Kind code of ref document: A1
Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW
|10 janv. 2001||121||Ep: the epo has been informed by wipo that ep was designated in this application|
|15 mars 2001||DFPE||Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)|
|14 mars 2002||REG||Reference to national code|
Ref country code: DE
Ref legal event code: 8642
|2 oct. 2002||122||Ep: pct application non-entry in european phase|
|16 févr. 2004||NENP||Non-entry into the national phase in:|
Ref country code: JP