WO2000068819A1 - Dispositif et procede electroniques de classement de formulaires - Google Patents

Dispositif et procede electroniques de classement de formulaires Download PDF

Info

Publication number
WO2000068819A1
WO2000068819A1 PCT/US2000/012841 US0012841W WO0068819A1 WO 2000068819 A1 WO2000068819 A1 WO 2000068819A1 US 0012841 W US0012841 W US 0012841W WO 0068819 A1 WO0068819 A1 WO 0068819A1
Authority
WO
WIPO (PCT)
Prior art keywords
job
command
entity
filing center
filing
Prior art date
Application number
PCT/US2000/012841
Other languages
English (en)
Inventor
Teri Ann Howe
John L. Dilley
Brian Scheffer
Nina Wright
Michael Crovitz
Lloyd Hawes
Original Assignee
Transenda International Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Transenda International Llc filed Critical Transenda International Llc
Priority to AU48372/00A priority Critical patent/AU4837200A/en
Publication of WO2000068819A1 publication Critical patent/WO2000068819A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
    • G09B7/00—Electrically-operated teaching apparatus or devices working with questions and answers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/32358—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device using picture signal storage, e.g. at transmitter
    • H04N1/324—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device using picture signal storage, e.g. at transmitter intermediate the transmitter and receiver terminals, e.g. at an exchange

Definitions

  • 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.
  • 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.
  • the receiving entity requires a standard set of information.
  • 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.
  • 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
  • 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.
  • Figure 1 is a system diagram and flow chart illustrating the elements of the inventive apparatus and the steps in the inventive process.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • the device pool may accept an incoming communication or attempt to connect with an external device, depending on its configuration.
  • the instruction to initiate an outgoing call is sent to the device pool by the protocol manager.
  • 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.
  • 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.
  • 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:
  • CallerlD (LEN) (TID) (PWD) (current user info-username, company, phone & available STIDs). Information sent by the entity for user authorization by the filing center.
  • LN 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.
  • 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).
  • 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.
  • ISubmit (CmdlD) (PI) (P2) (filename).
  • PI ISubmit
  • P2 filename
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the protocol manager 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.
  • 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.
  • API Send Error Application Program Interface
  • 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.
  • Send File API call with the communications handle, file identification number (FilelD) and job identification number (JoblD) as parameters
  • 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.
  • the filing center 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.
  • a Service Type ID (STID) Gate table
  • This table may only be changed by filing center administrators.
  • 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).
  • 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.
  • 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.
  • TID service command or transmitter
  • 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.
  • 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.
  • 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.
  • the command negotiator 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
  • 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.
  • 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).
  • the command dispatcher When a new service type is added, filing center administrators need to create an entry in the Group Priority Table.
  • a command group identification number CmdGroupID
  • 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.
  • 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).
  • CmdGroupID job identification number
  • the Command Dispatcher 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.
  • 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.
  • SID service type ID
  • the job queue receives a job from the command dispatcher and sets the status of the added job to Waiting.
  • 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
  • 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 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.
  • 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
  • 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.
  • 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 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.
  • ISubmit communications command require an immediate response from a command process.
  • the entity is requesting to receive a specific file(s).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the command process 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.
  • 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.
  • a entry is made in the Alias Definition Table, shown above.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • the protocol manager 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.
  • the protocol manager 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.
  • Job Log accounts for the processing of every job created by the Command
  • 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.
  • 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.
  • 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-
  • 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.
  • 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.
  • 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.
  • a sole payer for instance, a country's tax administration
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Abstract

Cette invention concerne un dispositif et un procédé destinés au classement électroniques de formulaires par une entité. Ce dispositif, dit « centre de classement », permet à une entité (du 'monde extérieur') de classer électroniquement dans ledit centre de classement un formulaire assorti d'instructions de communication et de données. Le centre de classement comprend un gestionnaire de protocole qui gère les communications entre l'entité et le centre ; un négociateur d'ordres qui détermine l'ordre dans lequel les instructions et données sont émises et reçues par le gestionnaire de protocole ; un distributeur d'instructions qui concrétise chaque instruction et donnée reçues sous forme d'une tâche correspondant au traitement d'un formulaire, une liste d'attente qui stocke les tâches en attente d'exécution ; un dispositif d'ordonnancement qui attribue des priorités pour les diverses tâches en attente, régule le volume de travail et distribue chacune des tâches à exécuter ; et une pluralité de systèmes d'instructions, répartis en groupes, qui s'acquittent chacun d'un type particulier de tâches.
PCT/US2000/012841 1999-05-10 2000-05-10 Dispositif et procede electroniques de classement de formulaires WO2000068819A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU48372/00A AU4837200A (en) 1999-05-10 2000-05-10 Apparatus and process for electronic filing of forms

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US30902099A 1999-05-10 1999-05-10
US09/309,020 1999-05-10

Publications (1)

Publication Number Publication Date
WO2000068819A1 true WO2000068819A1 (fr) 2000-11-16

Family

ID=23196329

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/012841 WO2000068819A1 (fr) 1999-05-10 2000-05-10 Dispositif et procede electroniques de classement de formulaires

Country Status (3)

Country Link
AU (1) AU4837200A (fr)
PE (1) PE20010308A1 (fr)
WO (1) WO2000068819A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108804708A (zh) * 2018-06-22 2018-11-13 平安科技（深圳）有限公司 业务数据表归档修正方法、装置、计算机设备和存储介质
CN111399948A (zh) * 2020-03-18 2020-07-10 上海东普信息科技有限公司 数据处理方法、装置、计算机设备及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5109512A (en) * 1990-05-31 1992-04-28 International Business Machines Corporation Process for dispatching tasks among multiple information processors
US5481698A (en) * 1988-09-28 1996-01-02 Hitachi Ltd. Computer system and job executing method
US5528513A (en) * 1993-11-04 1996-06-18 Digital Equipment Corp. Scheduling and admission control policy for a continuous media server
US5905908A (en) * 1995-06-22 1999-05-18 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
US6058373A (en) * 1996-10-16 2000-05-02 Microsoft Corporation System and method for processing electronic order forms

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481698A (en) * 1988-09-28 1996-01-02 Hitachi Ltd. Computer system and job executing method
US5109512A (en) * 1990-05-31 1992-04-28 International Business Machines Corporation Process for dispatching tasks among multiple information processors
US5528513A (en) * 1993-11-04 1996-06-18 Digital Equipment Corp. Scheduling and admission control policy for a continuous media server
US5905908A (en) * 1995-06-22 1999-05-18 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
US6058373A (en) * 1996-10-16 2000-05-02 Microsoft Corporation System and method for processing electronic order forms

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108804708A (zh) * 2018-06-22 2018-11-13 平安科技（深圳）有限公司 业务数据表归档修正方法、装置、计算机设备和存储介质
CN108804708B (zh) * 2018-06-22 2023-04-07 平安科技（深圳）有限公司 业务数据表归档修正方法、装置、计算机设备和存储介质
CN111399948A (zh) * 2020-03-18 2020-07-10 上海东普信息科技有限公司 数据处理方法、装置、计算机设备及计算机可读存储介质
CN111399948B (zh) * 2020-03-18 2024-03-29 上海东普信息科技有限公司 数据处理方法、装置、计算机设备及计算机可读存储介质

Also Published As

Publication number Publication date
AU4837200A (en) 2000-11-21
PE20010308A1 (es) 2001-03-14

Similar Documents

Publication Publication Date Title
US9037476B1 (en) Providing a wireless environment for processing of financial transactions
CA2119563C (fr) System de courrier electronique mta/tpv
EP0209392B1 (fr) Système pour le traitement centralisé des fonctions de facturation et de paiement
US9716684B1 (en) Automated delayed message redelivery
EP0664904A1 (fr) Systeme et procede de connexion a un systeme de traitement de transactions
US7383355B1 (en) Systems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects
US6044405A (en) Service network incorporating geographically-remote hubs linked by high speed transmission paths
US5220674A (en) Local area print server for requesting and storing required resource data and forwarding printer status message to selected destination
CN111833034B (zh) 一种批量扣款方法、支付服务器、计算机设备及存储介质
US20040267872A1 (en) Provisioning interface
US20100125470A1 (en) Methods and systems for providing a decision making platform
WO2014116344A1 (fr) Blocage de transaction sur guichet automatique bancaire
WO1997024688A9 (fr) Procede et dispositif de traitement des transactions de facturation
US7962382B1 (en) Payment broker system and method
WO1998004992A2 (fr) Matrice, systeme et procede de gestion d'installations, destines a executer un traitement par lots dans un environnement en direct
WO1999009475A1 (fr) Procede et dispositif de traitement de donnees concurrentes
US7472181B2 (en) Automated real-time appointment control by continuously updating resources for possible rescheduling of existing appointments
US20030099337A1 (en) Method and apparatus for exchanging data between a primary computer system and an external computer system to ensure transactional reconciliation between the systems
US7539626B2 (en) System and method for documenting delays associated with a project
EP1332430B1 (fr) Systemes et procedes de gestion centralisee d'objets d'integration d'applications d'entreprises repartis de maniere heterogene
WO2000068819A1 (fr) Dispositif et procede electroniques de classement de formulaires
US7925556B1 (en) Streaming conversion
JPH11306263A (ja) 電子マネーシステム、電子マネー用口座リンク方法及び記録媒体
WO2000033227A2 (fr) Calendrier des paiements destine a un systeme electronique de paiements des factures
WO2021076132A1 (fr) Systèmes et procédés pour aider les passagers en fauteuil roulant

Legal Events

Date Code Title Description
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

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP