BRPI1105598A2 - electronic ticketing system - Google Patents

Abstract

Electronic ticketing system The present invention describes an electronic ticketing system where users use individual and non-transferable non-contact contact smart cards for their use in function of the digital biometric thermal reading identification system, said system allowing the use of various public transport vehicles safely and seamlessly so that the public vehicle can be managed and driven only by its driver or driver and the public transport vehicles have a wireless communication system that updates pass card validators with information said cards and their limitations of use.

Description

FIELD OF ELECTRONIC APPLICATION FIELD

The present invention applies to the area of ticket automation for public transport involving passenger registration, ticketing, and operation of tickets on public transport vehicles, where the present invention allows controllers the transport system ensures that the ticket is personal and non-transferable to third parties and is used only by the person to whom the ticket was issued.

STATE OF ART

Mass public transport systems are a major concern of all major urban centers today.

Thus, businesses and governments have been concerned with making public transport safer, more comfortable and more effective.

One of the problems encountered in traditional public transport is the presence of the collector, who is responsible for selling the tickets and the cashier of the vehicle. This situation has four problems: - First, this employee represents a cost to the company, which is passed on to the users of the transportation system; - Second, the collector works with a money box that attracts the greed of burglars that brings risks to system users; - Third, the payment of cash tickets to the collector is an operation that slows users' entry into the transport vehicle resulting in delays in completing the route performed by the transport vehicle; e - Fourth, the collector is responsible for manual cashier closing, operation is inaccurate and slow.

EP 2112632 (A1) is a method involving a data element reserved for acknowledging availability with acknowledgment of travel sections that are temporarily provided during passenger travel in the event of access by a passenger in a transport unit, for example by bus, during passenger travel. A confirmation data set with the data element is relayed for acknowledgment of availability of a real passenger of the transport unit by a transmitter / receiver (3) in a respective ticket bearer medium (2) after generation of a set. of registered data.

Patent Document CN 201266391 describes a utility model that refers to a two-dimensional barcode multimedia ticket-based public transport vehicle system. The public transport vehicle system comprises a ticket sale terminal, a public bus ticket and a center, a mobile communication network, a collection terminal and a mobile telephone terminal, wherein the ticket sale terminal Billing sends information from a user for the sale of public bus tickets for ticketing and a billing center, the public bus box office and the billing center are connected with the mobile terminal and the public bus collection terminal by In the mobile communications network, the mobile phone terminal stores the two-dimensional barcode multimedia message by authenticating the registration information and authenticating by the public bus ticketing and issuing center and a mobile screen to analyze the device and arranged in a public bus terminal. The public bus registration system can realize the fast electronic means of payment.

However, these systems do not guarantee the individuality and unavailability of the ticket by its user, that is, the user, who, for example, enjoys free of charge, cannot give away his ticket for third parties to use. this passage improperly.

Accordingly, it is an object of the present invention to remedy the problems cited above.

DESCRIPTION OF THE FIGURES

[0009] FIGURE 01 - Illustrative diagram of the step structure of the system of the present invention.

[0010] FIGURE 02 - Illustrative diagram of the chip structure that makes up the system of the present invention.

[0011] FIGURE 03 - Illustrative diagram of the chip hierarchy for the system security module of the present invention.

FIGURE 04 - Illustrative diagram of the credit application process for the public transport ticket of the system of the present invention.

[0013] FIGURE 05 - Illustrative diagram of the pass clearance process in the validators of the public transport vehicles of the system of the present invention.

FIGURE 06 - Illustrative diagram of communication and processing of the system of the present invention.

FIGURE 07 - Illustrative diagram of the process modules of each processing step of the system of the present invention.

FIGURE 08 - Illustrative diagram of the equipment integrating the system of the present invention.

FIGURE 09 - Flowchart of the CUSTOMER SERVICE function of the REGISTRATION and CUSTOMIZATION step of the system of the present invention.

[0018] FIGURE 10 - Flowchart of the card PRINTING function of the REGISTRATION and CUSTOMIZATION step of the system of the present invention.

FIGURE 11 - Flowchart of the VALVE-TRANSPORT function of the REGISTER and CUSTOMIZATION step of the system of the present invention.

FIGURE 12 - Flowchart of the INTEGRATION function of the COC ADMINISTRATION step of the system of the present invention.

FIGURE 13 - Flowchart of the SAC function of the COC ADMINISTRATION step of the system of the present invention.

FIGURE 14 - SALES flowchart of the TRADING step of the system of the present invention.

FIGURE 15 - Flowchart of the HARDWARE TECHNICAL SUPPORT function of the system of the present invention.

FIGURE 16 - Flowchart of the SOFTWARE TECHNICAL SUPPORT function of the system of the present invention.

FIGURE 17 - Flowchart of the NEW REPORT CREATION TECHNICAL SUPPORT function of the system of the present invention.

FIGURE 18 - Flowchart of the NEW SYSTEM CREATION TECHNICAL SUPPORT function of the system of the present invention.

FIGURE 19 - Flowchart of the ticketing process embarked on the public transport vehicles of the system of the present invention.

FIGURE 20 - DATACENTER flow chart of the system of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0029] Figure 01 illustrates the interaction and sequence of steps and functions pertaining to the electronic ticketing system processes of the present invention.

The system is first configured in a process step called Ceremonial (1), detailed in Figures 02 and 03.

Within each of the electronic ticketing system steps illustrated in Figure 01 are a series of function modules responsible for the operation of the system.

[0032] Such modules will be detailed according to their respective step. Figure 07 illustrates the modules within each system process step. CEREMONIAL STEP (1) [0033] Ceremonial, as shown in figure 02, is a prerequisite for initiating system deployment and involves entering secret information to produce the system's key set. This process is done on a workstation (9) isolated from the network. The process requires 4 (four) distinct participants (10, 11, 12 and 13), each of which receives 3 (three) copies of a chip called SAM_KEY (14) together with their access PIN (15). These chips are recorded unique and confidential information provided by the participant.

For the entry of this data the participant must have total privacy. At the end of the typing process the system generates 3 (three) copies of each participant SAM (14) chip (SAM_KEY), with the purpose of maintaining backups.

[0035] For the generation of SAM_MASTER (16), which is the chip responsible for originating all other chips and user cards in the system, it is critical that all participating chips are available with all logged data. The system requires all participants to use one of their respective SAM_KEY (14) routes. The chips are placed simultaneously on the workstation-attached SAM chip readers. After reading and validating the chips the key set is generated and based on the participants passphrase.

[0036] This set of procedures ensures that the generated keys are not known and can only be recreated by joining all participants involved in the process.

Generation of system credit and other system chips: SAM (14) has a key diversification mechanism that allows key hierarchy. Higher level SAM (14) can calculate lower level SAM (14) chip switches, but the opposite is not possible.

There are 7 (seven) types of contact cards, which are named: SAM_KEY, SAM_MASTER (16), SAM_M0 (17), SAM_Ml (18), SAM_M2 (19), SAM_PERS (20), SAM_VAL (21) ).

They are all implementations for the system security module. Below are the functions of each SAM (14) in the electronic ticketing system: [0039] SAM_KEY: Used only to record the Ceremonial participant passphrase. It must be stored in a safe environment owned by the participant and the System Management Company. They are issued in 3 (three) copies.

[0040] SAM_MASTER (16): Has the set of system main keys. It is from this card that all other card types are derived, so it is the highest level in the hierarchy.

[0041] SAM_M0 (17): Is responsible for creating and initial loading money into the system.

[0042] SAM_M1 (18): Who gets money from SAM_M0 and distributes it to the rest of the system.

[0043] SAM_M2 (19): Located on the POS for contactless card authentication (Mifare type cards).

[0044] SAM_PERS (20): This card is capable of formatting and customizing the system's MIFARE cards.

[0045] SAM_VAL (21): Located in the validator, allows operations with MIFARE cards. Debit and credit operations are allowed, and to perform the latter, only having an authorizing cryptogram.

[0046] Figure 03 illustrates a hierarchical diagram referring to the security module. Note that the SAM_KEY card does not appear in the diagram due to the fact that it is out of the system routine and is only used to generate the master key.

System Credit Generation and Distribution: The electronic credit generation system, as illustrated in Figure 04, establishes a credit distribution network at four (4) different levels (SAM_M0 (17), SAM_M1 (18), SAM_M2 (19) and user card (22)), and at each level there will be one or more entities associated with the system, the hierarchy established for credit control and trading must always be respected.

[0048] These electronic credits are generated at the credit center (23). For security purposes, the persons who participated in the Ceremonial (1) and have the SAM_KEY chip (14) are the only ones authorized to generate credit for the system. The generation must be performed with the presence of 4 SAM_KEY (10, 11, 12 and 13), PINS (15) for special operations and SAM_M0 (17) which is the credit holder at the time it is generated.

[0049] Credit generation will require four (4) participants (10, 11, 12 and 13). After electronic credit generation, individualized data such as: credit amount, credit serial number, credit generation dates and identification of the persons participating in this generation operation are sent to the SCM server for enable audit and track the credit generation process. Reports can be generated of all operations performed by each user and card.

[0050] System architecture enables online transactions because system configuration is centralized. Every operation is controlled by the electronic ticketing system, where every transaction regarding the registration of passengers, sale of credits or cards, is consulted, registered and authenticated in real time.

Thus, the outlets, connected to the Central, can be expanded and installed in commercial points to be accredited and in terminals. At the time of data transmission, the stations will receive from the Central the update of the Restriction List and the operating information and, in return, will send the information related to the movement of the current period and each of the transactions performed. Retail outlets may also have a credit card consultation point.

For the operating environment both non-redundant systems and redundant environments called "cluster" can be used. The clustered system will ensure greater integrity and continuity of processing in the event of hardware failure.

[0053] The electronic credit generation system establishes an "online" credit distribution network based on a "credit server" (23) to release card sales and recharge.

Electronic credits can be of two types: valued electronic credits (cash) or electronic travel credits (single or multiple), parameterizable according to the Electronic Ticket System concept.

Thus, every sale or recharge of electronic credit must be authenticated and authorized by the "credit server" (23) on assisted or self-service equipment. Each transaction made at these terminals will only be completed when the "credit server" (23) issues a positive response to the credit charge or recharge.

[0056] The control and management process of this system consists of controlling the electronic credits used by transportation users to pay the fare, financial movement and operational information of passenger flow. Thus, there is an effective control of the credit flow in terms of generation as well as utilization.

The entire sales network must be connected to the credit center (23).

[0058] Credit distribution control is done on SAM (14) chips, as many as necessary, to provide the best performance and the highest possible security to the system, with the authentication of all operations performed.

Safe methods of correspondence between the parties are used to ensure the uniqueness and confidentiality of the information. The data is "signed" with a certain key, implying mutual authentication for the success of the operation.

The system rejects any type of information that does not have the necessary security requirements.

Once the system is ready for operation, electronic ticket tickets are prepared and issued, which can be implemented by memory smart cards such as ISO 14443A, B, ISO 15693, Mifare, DesFire, HID iCLASS, etc. This procedure is performed in the Registration and Personalization (2) and Commercialization (3) process steps.

Description of the CEREMONY STEP Modules (1) [0062] Figure 07 illustrates how the modules are distributed by the system steps and the correlation between them. Ceremonial Module (24) [0063] This system module is installed only once, at the beginning of the project, on a workstation formatted specifically for software use, ie the previous operating system must be deleted and must be made a new installation for this purpose only.

[0064] The station must be disconnected from network or internet and have no hard disk write function.

[0065] After using the software it is recommended to format the station again. Operation of this module is by a qualified person only, as this will affect the safety of the entire system.

[0066] The operator is responsible for maintaining the reliability and confidentiality of the entire process.

[0067] The purpose of the ceremonial is to generate a MASTER chip (16) that will be the access key for any type of operation with the SAM chips (14) in the system.

[0068] The MASTER card (16) is the most important card in the system because it derives from all the other SAM (14) chips and contactless cards in the system.

[0069] The ceremonial involves the typing of secret information. The MASTER chip (16) is composed of the gathering of this encrypted information.

[0070] The features available in this module are: [0071] Generate SAM_Key Participant Chip: Each participant enters their system name, PIN number received, and a passphrase of at least 30 characters. After this information is entered, the Ceremonial module (24) encrypts the sentence and the respective SAM_Key card of the participant is generated. Each participant when registering in the system their respective information, receives printed at the end of the operation a PIN to perform special operations issued by the system. This PIN should be used whenever cash is required. It is noteworthy that this operation is only possible if the 4 special operations PIN issued by the system are informed.

[0072] Generate SAM_MASTER chip (16): Only with the 4 SAM_Key chips connected to the station is it possible to generate the SAM_MASTER chip. Each participant informs the system of their PIN number. After completing the process, the SAM_key chips must be unplugged and a blank chip must be plugged in. The SAM_MASTER chip (16) is generated with information derived from the 4 SAM_key chips of the participants.

Generate SAM_M0 (17): Only with the 4 SAM_Key chips connected to the station is it possible to generate the SAM_MASTER chip (16). Each participant (10 to 13) informs the system of their PIN number. After completing the process, the SAM_key chips must be unplugged and a blank chip must be plugged in. In addition to this virgin chip, it is also necessary to connect SAM_MASTER (16). Participants interact again with the module and each one enters the system-specific PIN issued by the system at the time their respective SAM_key chip was generated. After entering and confirming the information by the module, the SAM_M0 chip (17) is generated. SAM_M0 (17) is generated without value and also receives a PIN number that must be used whenever credit generation is required in the system.

[0074] The minimum requirements for module operation are: Workstation with CD-ROM Drive

Inkjet printer; USB HUB with 4 free outputs; 4 smart card readers (SAM Chip); 5 14 SAM chips (3 ways for each participant and 2 ways for SAM_MASTER (16));

[0075] At least 1 chip for SAM_M0 generation (17) (This amount may vary depending on the amount of money to be generated by the project). SAM Provider Module (25) [0076] This system module has a dedicated server for large transaction projects or can share the installation of the SCM module (26).

[0077] All SAM_M1 (18) are connected to this server uninterruptedly, so at least 1 7-port USB hub must be connected to the server. Depending on the amount of SAM_M1 (18) in the project there will be a need to use more hubs and can cascade them together.

[0078] SAM_M1 (18) is responsible for storing system credit and is limited to 21,000,000.00 (monetary value).

The estimated quantity of SAM_M1 (18) for the electronic ticketing system is based on the number of points of sale and users that can perform automatic recharge.

All monetary transactions of the electronic ticketing system are authorized by this module, ie when a sale is made, for example, the sales terminal requests the withdrawal of credit from one of SANMMIl (18). After the withdrawal authorization the sale is completed and the credit is transferred to the user's card (22).

[0081] The functionality of this module is: [0082] Managing, Routing and Allocating SAM_M1 Chips (18): Requests are received by the server and this module performs routing balancing credit withdrawal between SAM_M1 chips (18 ). All management of server SAM_M1 (18) connections is handled by the SAM Provider module (25). Secure Credit Manager (SCM) Module (26) [0083] This system module is installed on a dedicated server or can be installed on a server shared with the SAM Provider module (25). This condition depends on the number of sales points that make up the electronic ticketing system.

SCM (26) has as its primary purpose to manage the credits of the electronic ticketing system. It is subdivided into 2 modules: Transactional Server: Responsible for executing transactions forwarded by sales terminals that communicate via TCP / IP protocol with Transactional Server which will queue the messages and send them to the DLL.

This submodule comprises: a. DLL ·: Processes incoming messages. Processing consists of accessing the database to verify the business rule for the application contained in the card and communicating with SAM chips via the SAM Server module. B. Communication Module: Responsible for receiving requests from sales terminals and sending them to the handling DLL. In addition, it sends the obtained response to the terminal that originated the request.

[0087] SAM Provider: Receives all requests for SAM_M1 chips, which are the system credit holders and directs them to the SAM Provider module. This module manages access to system SAM_M1 cards, meets the credit request after the entire business rule has been validated. The requested amount is debited from a SAM_M1 and sent to the sales terminal to be transferred to the user's card.

[0088] The functionality of this module is as follows: [0089] Receiving credit applications from sales terminals: At the moment the credit sale is being performed, the sales terminal communicates with this module to make the requisition of credits which are being sold. SCM (26) first checks in the database which business rules are registered for the type of application contained on the user's card. After validating all the rules, he applies for credits to the SAM Provider module (25). The SAM Provider (25) routes the request and directs it to one of the SAM_M1 chips (18). The credit amount of the requisition is withdrawn from the chip, if it has sufficient balance, and is transferred to the sales terminal and then to the user's card.

Record sales terminal transactions: SCM (26) receives all transactions made at sales terminals and validates the business rule to record transactions in the database. SAM Cash Module (27) [0091] This system module can be installed on a workstation and is intended to generate system virtual money. Electronic ticketing system credits are always tied to a series. In order to generate credits, it is essential to present the following components: all participants (10 to 13) with all SAM_KEY (14), SAM_M0 (17), PIN (15) chips for special operations of the 4 SAM_KEY (14) and SAM_M0 (17) and at least one connected SAM chip reader.

As in the ceremonial each participant card will be presented and then the PIN for special operations of the respective card should be entered, this module should be accessed only when there is need to generate credit in the system.

The features available in this module are: Generate series (credit or ticket): All system credit (or ticket) originates from a series, so the series must be created to organize, track and account for credit generation in the system. In the first generation of credit it is mandatory that a series has already been generated, while in the other generations, you can assign more money to an existing series or create a new series. For generation of the series it is not necessary to have any chip connected to the station and it is not necessary to enter the PIN number for special operations.

[0095] Generate credit or ticket: The generation of credit / ticket in the system is essential for operations involving the trading of credits / tickets (sale and recharge) to occur. In order to generate the credit, the operator must inform if the value will be included in the current series or in a new series, inform the desired value, then each participant's SAM_key chip (14) must be connected to the workstation and its PIN for special operations must be entered. After validation of the SAM_key chips (14) and their respective PINs (15), the SAM_M0 chip (17) must be connected and its PIN must also be entered. The credit amount entered is assigned to the SAM_M0 card (17). The process for generating credit or ticket is identical.

[0096] The minimum requirements for module operation are: Workstation; 1 smart card reader (SAM chip);

For credit or ticket generation: SANMhO (17) and PIN (15) for special chip operations. SAM Manager Module (28) [0097] This system module can be installed on a workstation or SAM Provider server (25) and is intended to issue system chips and transfer credits between SAM_M0 (17) to SAM_M1 (18) system chips. SAM Manager (28) transfers by connecting the SAM_M0 (17), SAM_M1 (18) chips, and entering the PIN (15) for SAM_M0 (17) special operations.

[0098] SAM Manager access (28) is only required when credit transfer between system cards is required.

[0099] The features available in this module are: [0100] Activate series (credit or tickets): After creating a series you must activate it to unlock the use of credits generated in the system.

[0101] Issue system SAM chips (except: SAM_key (14), SAM_Master (16), and SAM_M0 (17)): All SAM (14) chips are issued in this module. The chips are issued individually, for this it is necessary to connect them to the station. Initially the demand for chip issuance is high, it takes into account the amount of equipment that is part of the system. After this initial issue this feature will be accessed only when new equipment is purchased or in some other sporadic situation.

[0102] Transfer credits from SAMJMO chip (17) to SAM_M1 (18): SAM_M0 chip (17) is not connected to any station or server in the system. SAM_M1 chips (18) are responsible for storing system money and are accessed whenever a monetary transaction is made, so they must be uninterruptedly connected to the SAM Provider server (25). For this reason, the money contained in SAM_M0 (17) should be transferred to one or more SAM_M1 (18). To transfer credits from SAM_M0 (17) to a SAM_M1 (18), you must first connect SAM_M0 (17), enter the PIN (15) for special chip operations, and then connect SAM_M1 (18).

[0103] Include Emitter on an Already Recorded Chip: If you need to include one or more transmitters in the system SAM (14) chips, the process is done in this module, for this, each chip must be connected to the workstation or server. that the module is installed.

[0104] Link SAM_M1 (18) to a certain application group: This feature allows a SAM_M1 (18) to be used by only one application group. For example, you can define that a respective SAM_M1 (18) will only be used to make sales to users of a particular type.

[0105] Identify chip type: The system reads the chip after it is plugged in and checks its type.

[0106] The minimum requirements for module operation are: Workstation or server; 1 smart card reader (SAM chip);

Issue system SAM chips (except: SAM_key (14), SAM_Master (16), and SAM_M0 (17)): The chips to be issued and at least 2 readers are required;

Transfer credits from SAM_M0 (17) to SAM_M1 (18): SAM_M0 (17), SAM_M1 (18) chip and at least 2 readers;

Link SAM_M1 (18) to a given application group: chip SAM_M1 (18). REGISTRATION AND CUSTOMIZATION STAGE (2) [0107] Cards issued in the electronic ticketing system are always linked to a user, even for impersonal cards, ie they are cards issued without a specific user to be used by any user. .

[0108] For this reason, card issuance depends on the user registration process. The UCA module is responsible for registering users individually to identify them through personal data or other relevant information.

[0109] In the case of impersonal cards, a card issuance can be made in batch, but firstly users are also registered in batch, but are registered as generic users. This process occurs through the import module.

[0110] It is in the registration module that the application that will be recorded on the card is defined. Through the application that the electronic ticketing system can verify what are the rules that should be applied to the user.

[0111] The card issuing process can be done in several ways: [0112] Saving the card before printing it: [0113] After registering, the system operator configures the user card and requests to save it. In this case, the registration module must use a contactless card reader (PX). Printing is done later by a printer specific only for the printing operation.

[0114] Perform recording and printing simultaneously: [0115] After registration, the operator configures the card. Recording and printing occur simultaneously on a machine that contains both features.

User Card Setup [0116] The user card (22) is customized according to a user group or individually. Information recorded on the user's card (22) includes: applications, restrictions and credits.

[0117] Applications: It is a set of definitions and restrictions for the use of transport. A card is useless if there are no applications defined for it. You can have one or more applications for the same card. It is in the application that card validity, integration time, credit limit value and so on are defined. You can assemble templates with applications to gain quick registration. Templates can be applied to users who will have common applications.

[0118] Wallets: The card is composed among other things by applications. Card applications have a lot of information, including wallet information. The wallet is responsible for storing credit card information. Each application has 2 wallets: A and B. When loading the credits on the card the date and the amount loaded in the empty wallet are recorded.

[0119] Restrictions: Restrictions on use are contained within each application of the card. Thus, it is possible that a particular application will not be used due to a restriction, but another application within the card is triggered, respecting the priorities and restrictions of each one, such as if a card has the application "School" and "Common" and at the time of use the application "School" is within some restriction, automatically the application of "Common" will be triggered and will be checked for credit for the payment of the ticket.

[0120] Restrictions control the user's permissions with respect to the public transport lines he can use, the usage limit for a period or for a certain time.

[0121] There is also a reload restriction that controls the amount of times and the maximum amount an application can be reloaded with credits in a given period. For example: If in the "School" application of the card the charge limit for a certain period (05/2008) is $ 50.00 and you use all the credit on the card before the end of that period, you will not be able to upload more credits for the period 05/2008. The user can only upload their credits in the following period (06/2008). It is noteworthy that the period is not necessarily a full month. The period is configured as per customer requirement. Credit Sale by Wallets [0122] Each application inserted into the card contains 2 wallets: A and B. In case the 2 application wallets still have balance it is possible to make a new sale for this card, but the date of the oldest wallet of the card. card is now "lost" and is no longer considered in validator rate calculations.

[0123] It is also important to note that if the Sale Series is different from the Card Series this process is not performed, otherwise the debit traceability would be lost on the card. In the example below, the important thing to note is that the January rate, in the example, can no longer be considered when using the card. In the case of recharging on board under no circumstances is the portfolios joined. Module Description STEP REGISTRATION AND CUSTOMIZATION (2) User Card Administration (UCA) Module (29) [0124] UCA (29) is the module responsible for maintaining user and provider records.

[0125] Controls the generation of issued cards as well as the validity, applications and restrictions of these cards.

[0126] Also performs lock and unlock operations for card use.

[0127] The specialized care network will use the system to perform the following operations in general: [0128] Registration of users and providers: It makes the registration of users for use of transport according to some previously defined restrictions. Providers are companies that must be previously registered to users so that they can be linked to them according to the definition of user type.

[0129] Customer Service: In situations such as theft or loss the user contacts customer service to block the card and consequently the credits linked to this card.

[0130] The features available in the UCA module are: [0131] Registering Users: The User Registration in the system has 3 purposes: [0132] Transport or Passenger User: User who will use the transport and will receive a card to pay for your ticket.

[0133] System User: User who is an employee of the transportation company and needs access to some module of the electronic ticketing system.

[0134] Operator User: Employee of the transport company that needs to operate the validator. Drivers, collectors and inspectors are examples of employees who operate the validator.

[0135] The user registry is subdivided into: [0136] Register basic data: It is the register of the user's personal information. Before starting the registration it is advisable to make a consultation to make sure that the user has not registered in the system. If the user is generic only a minimum number of fields must be filled. The registration contains the following features: [0137] Fingerprint Capture: Area that allows the capture of the user's fingerprints. You can capture the fingerprint only through a finger print device connected to the computer.

[0138] Image Capture: Area that allows you to attach images of user documents. These images must be previously scanned.

[0139] Photo: Area that allows you to include and exclude photo. It is possible to capture a user image at the time of registration via a webcam or select an image saved on the computer.

[0140] User Type: Definition of the type of user being created. You can select 1 or more types of users.

[0141] Enter details fields according to user type: It is after the user type is defined that the detail screen is incorporated into the registration form to fill in the specific data for the defined user type. If you need to add more user types, it must be done in the SYS (43) system.

[0142] Control Duplicate Registration: The fields for controlling duplicate registration are set in the SYS module (43). Control is done through a combination of fields.

[0143] Consult user register: The user register can be consulted using as filter one or more fields of the Basic Data register. In addition, it is possible to query with the card information: card issuer, card design, card serial number (number range) and status.

[0144] Check and manage user card status in the system: A card can have one of the 4 statuses below in its registration. Depending on the card status some operations are allowed.

[0145] Waiting to be recorded: The card has been registered for the user, but the physical card has not yet been generated, so it does not yet exist physically, but already has an identification number. The operations available for this card are: [0146] Cancel: By setting the status to Inactive, card issuance is Canceled.

[0147] Successfully recorded: When prompted to write the card by the system user. The card is physically recorded.

[0148] Successfully recorded: The physical card has been recorded and is ready for use. The operation available for this card is: [0149] Restrict List: By setting the status as Restrict List or adding the card to the Restrict List, the card identification number is sent to this list.

[0150] Restrict List: The card has been included in the Restrict List and therefore cannot be used. The operation available for this card is: [0151] Uncancel: The card is unlocked and its use is normalized. The card status returns to "Successfully Saved".

[0152] Canceled: The card may be canceled when it was issued wrong, but it was not physically recorded and only received an identification number by the system. In this case it is recommended that a new card be created and it is canceled so that there is a history of the transactions made.

[0153] Physical Card Status: The validator or sales terminal is responsible for updating the physical card status as verified by it on its Restrictive List. One of two statuses are recorded on the physical card: [0154] Locked: When the validator or sales terminal verifies that an unlocked card is in the Restrict List, it writes the lock information to the card.

[0155] Unlocked: When the validator verifies that the locked card is in the Restrict List and there is a request to unsubscribe, it writes the unlocking information to the card.

[0156] Lock / Unblock Card (Restrict List): The card is locked by being added to a list called "Restrict List". The card may be included in this list for several reasons: user request for loss or theft, wrong card issuance, registration change, etc. At the time of inclusion a 2nd copy of the card can be requested and the transfer of credits from the restrictive list card to the card to be issued, but this transfer is not effective and the credits are not released. This only happens after order generation.

[0157] The process of inclusion in the Shortlist is as follows: [0158] The validator contains a Shortlist that is synchronized with the UCA System Shortlist (29) whenever there is communication between it and the garage. This communication is usually done before the bus leaves or after returning to the garage.

[0159] Inclusion of the card in the restrictive list is updated in the bus validator usually the day after it was added to the system restrictive list. If the card is used at this time when the system has been added and the validator's Restriction List has not been updated, the credits will be debited normally.

[0160] The actions that are taken when attempting to use a restrictive list card are described below: [0161] Canceling the card: When an attempt is made to use a card and it has already been added to the validator's restrictive list, it is physically blocked. When the validator communicates with the switch in the garage, transmits the lock information (date of lock), the switch updates the system's restrictive list to remove the card number when forwarding the validator's restrictive list update file, as the card is already physically locked and cannot be used.

[0162] Request 2nd card path: The 2nd card path can be requested at the time the card is added to the Restrict List or later, but can only be requested if the card is in the Restrict List.

[0163] Request Credit Transfer for 2nd copy: Credits from the previous card can be transferred to the new card. It may occur that the card does not contain the same amount of credits as it did at the time of inclusion in the restrictive list, due to the period between the inclusion in the restrictive list and the communication with the validators to inform the card block. Credit transfer usually occurs one day after the card is included in the Restrictive List, as the card may have been used prior to the garage communicating with the validator.

[0164] Credit transfers occur in two types of transfers: [0165] Wallet credits: Transfer of all existing credit in the card wallets.

[0166] Pending order credits: Transfer of all pending orders to this card.

[0167] View and print User Card Statement: Statement of all transactions performed with the card, including credit and debit amounts, times and dates, and description of transactions performed. This extract is filtered for a user-defined period of the system.

[0168] On the card statement there are 2 fields that control the amount of transactions and reloads: [0169] Transaction Sequence Number (TSN): Number of transactions performed;

[0170] RSN (Recharge Sequence Number): Number of refills performed.

[0171] Performing a Card Search: Using a contactless card reader connected to the computer, card data can be searched using the UCA module (29). After requesting to read the card in the UCA module (29) the user is located.

[0172] Link user card to registered applications: It is a set of definitions and restrictions for the use of transport. A card is useless if there are no applications defined for it. You can have one or more applications for the same card. It is the application that defines the validity of the card, use by period, credit limit value and etc. You can build templates with applications to gain quick registration. Templates can be applied to users who will have common applications.

[0173] Associating Line or Line Group Restrictions with the Card: For each card application you can restrict the lines that the user is allowed to use. If no rows are selected, the user is allowed to use all rows.

[0174] Setting up the card for printing: This operation allows you to set up to read, write and print a card.

[0175] Requesting Card Recording and Printing: After you have registered the card information and defined the applications and restrictions it should be: [0176] Printed: The defined layout and design are printed on the card using a card printer. .

[0177] Recorded: Registered information is recorded to the card via a card reader / writer. At this time the card status is changed from "Waiting to be Saved" to "Successfully Saved".

[0178] These two operations can be performed at the same time if the printer being used for printing has a card reader / writer attached to it, so the card is printed and recorded at the same time.

[0179] You can also use Remote Printing, where the printer is remotely connected to the workstation and cards are printed in batches according to the print queue.

[0180] Registering Providers: Registration of companies that will have some link with the registration of users as employer company, schools, service stations, bus company, etc. The types of providers must be registered in the SYS (43) system, but the types of providers that must necessarily be registered are: [0181] Company: employer company that will have to request and pay credits to its employees.

[0182] Schools: Users attending students or teachers teaching classes must be linked to this type of provider.

[0183] Service Desk: Older users are linked to this provider because they are allowed to use the free transportation.

[0184] Add card to restrictive list: Adding a card to the restrictive list means locking the card for use. This procedure occurs when the card is lost, lost, stolen, wrongly issued, or for any other reason that needs locking. The card can only be included in the restrictive list if it has been saved before. The inclusion procedure is: Query the desired user name;

Inform the reason for the inclusion (these reasons can be parameterized in the SYS (43) system);

Inform the name of the operator;

Inform the type of document and the document number of the operator;

Then request the inclusion.

[0185] You can include only one or several cards at a time in the Restrict List by simply selecting all the desired users that are returned in the query result.

[0186] The card can be included in the restrictive list also by registering users by changing the card status. To do this, the system user must consult the user register, request the registration edit and change the card status to "Hotlist", and then save the registration.

[0187] Querying Restrict List Cards: You can query all the cards in the Restrict List or filter by filling in one or more fields in the master list. Record Card Module (30) [0188] This system module is installed in the card issuing station and is for the sole purpose of recording the user's card. The Record Card is used when in the registration station using the client version of the UCA module (29) as well as in the RFC station (31). At the moment of registration, the system operator may request the card to be recorded. Remote Printer Card (RPC) Module (31) [0189] This system module is installed on the card issuing station and is intended to control the remote recording and printing of user cards. After registering the user in the UCA module (29), it is possible to request the printing and recording of the card. RPC 31 receives these requests by creating a queue of pending cards. Printer and card writer management is handled by this module.

[0190] Features available in this module are: [0191] Configure Module Usage: The paths where configuration files, image files, print pooling configuration, and print layout selection will be stored.

[0192] Select Printer: Select the desired printer to record and print the card, and select features for recording and printing the card.

[0193] View pending printable cards: View of all cards queued to be recorded and printed;

[0194] Viewing recorded and printed cards: Viewing all cards that have been successfully recorded and printed;

[0195] View error cards in one of two operations: view all cards that have had an error during the process. Card Design Layout (CDL) Module (32) [0196] This electronic ticketing system module is designed to define the design that will be printed on the user's card. The system allows the operator to define where the photo will be printed, if any, and the information to be printed. This information can be variable, such as the username.

[0197] Figure 09 illustrates the flowchart of the processing sub-steps of step 2 of registration and customization.

[0198] The User of the electronic ticketing system is greeted at a store (steps 100 and 101), or another call center, and sent to pre-service (step 102), where he receives all necessary clarifications and may be a request for information, request for new cards or be directed to a specific service sector (step 103).

[0199] Being information only, the user has their questions answered (steps 153 and 154).

[0200] If there is a card request (step 104), its specificity is verified, it can be for a duplicate or a new registration (step 105).

In the duplicate process (steps 106 and 107), a screening is done for which specific motive, which are: Loss (step 108); - Theft / Theft (step 109); - Defect (step 110); Loss (step 111);

[0202] After this identification, if the reason is a card defect or theft, and the occurrence report (BO) is required, the request is sent directly to the printing department (steps 112 and 113), the request is made to duplicate and the card (s) are delivered (step 114). For the reason of loss, theft or loss the user is referred to the sales department to make their request, due to this service being charged and then to the printing department (steps 112 and 113) and delivery (step 114) as above. .

[0203] Upon re-enrollment, the category type is checked (step 119) and then passed through a documentation check.

[0204] Document checking follows the following guidelines: Senior Category (step 128) Copy and original: - Identity Document (RG); - CPF; - Proof of Residence (nominal with recent date); Social Category (step 127) Copy and original: - Identity Document (RG); - CPF; - Proof of Residence (nominal with recent date); - Letter of Concession (INSS);

Special Category (step 125) Copy and original: - Identity Document (RG); - CPF; - Proof of Residence (nominal with recent date); - Medical report (with recent date); - Companion ID and CPF if there is specification for the companion type;

Citizen Child Category (step 126) Copy and original: - Identity Document (RG); - CPF; - Proof of Residence (on behalf of legal guardians); - Companion ID and CPF (legal guardians);

School Category (step 123) Copy and original: - Identity Document (RG); - CPF; - Proof of Residence (nominal with recent date); - School Form (duly completed);

Citizen Category (step 120) Copy and original: - Identity Document (RG); - CPF; - Proof of address; - Citizen Form (duly completed);

Functional Category (step 129) - Identification document; - Request for functional cards (duly completed);

[0205] Going through this screening, meeting the prerequisites for registration (steps 130 to 132), the user receives a password for service if they are not asked to return with the correct documentation after receiving the correct information ( step 154). Upon request for Transportation (voucher 121) or Corporate voucher (step 122) cards, the user receives information for registration via the Web (step 149). For school registration a specific check is required from the GPS department.

[0206] If a specific request is verified, the card or the user is sent to the responsible department which can be: - Transportation Voucher Department: remove card refilling or withdrawal questions. - Integration Department: for complaints of card integration failure or malfunction. - Printing Department: for card malfunction problems. - New Case Department: for specific information regarding the medical evaluation process. - Sales Department: for soliciting charged services (selling forms).

[0207] Once the documentation requirements are met, the registration (step 133) is made according to the category to which the user belongs (steps 135 to 142), considering the following steps: - Entering personal data from VTWeb Admin program such as ID, address and telephone numbering (step 134). - Inclusion of digital photo from a web cam (step 143). If the picture is correct (step 144) the procedure proceeds, otherwise a new picture is taken (step 143). - Digital collection (step 145), from the Finger Collector program, where the user first goes through a test to verify the suitability of his fingerprint with the system, followed by the finalization of the procedure through the definitive recording in the program. If the fingerprint is in good condition (step 146) the procedure proceeds, otherwise new fingerprint is collected (step 145).

[0208] For the Citizen category no photo and digital collection is required, going straight to step 112.

[0209] With all information included in the system, the registration is completed, generating a specific category card (step 112) that is sent to print (step 113), the user must wait for the card to be removed (step 112). 114). If the requested category is the Special type, being a New Case, the card is not made until the result of a medical evaluation is received, and therefore the user should wait for contact from the Operator for a later withdrawal.

[0210] After receiving the cards made, the delivery department is responsible for correctly completing the disclaimer, which is signed by all users upon withdrawal. It is the industry's duty to deliver the cards with the protective cover.

Upon receiving the card, the user is directed to a turnstile, where he proceeds with the card test (step 115). If the test is positive (step 116) it is considered the end of the process (step 118). If the result is negative, a problem identification is made (step 117), which can be: - Card reading error; - Design error; - Error of the registered data; - Error reading the fingerprint;

[0212] Once the error is identified, it is either sent to the printing sector (step 112) that makes a new card or sent to a digital register in the registration sector (step 145). The process is only terminated when the ratchet test is positive (step 116), and then the user is released (step 118).

[0213] The New Case department (step 147) is responsible for the processes generated by entering new cases from the Special card category (steps 135 and 136).

[0214] Operators receive the registration forms, transmitting this information to a new control form, which is sent for medical analysis, performed by the company's responsible physician (step 148).

[0215] Processes are reviewed for two outcomes: Approved: The benefit is approved for the user, who is informed to later withdraw the card from the operator (step 114).

Denied: The benefit is denied to the user, who is informed of the outcome, and may later re-enter different data or enter an appeal letter.

[0216] If an appeal letter is entered, operators receive the outcome of the process, which is performed by another company that has no connection to the system operator.

[0217] From the acquired result, the user is informed by the procedure explained above.

[112] Step 112, generating card, involves printing the public transit ticket. This system process step is detailed in figure 10.

[0219] When triggered at step 112, the printing department receives the card printing request on its RFC system, which can happen in two ways: - Automatic [0220] The printer receives information from a new registration without interference operator and processes the card by depositing it in a tray. - Manual [0221] The printer receives this information from a new interference register from an operator and processes the card by depositing it in a tray.

[0222] Operators are tasked with overseeing the entire printing process, loading printers with the appropriate white cards for each category, and sending the cards ready for delivery (steps 155, 156, 157, 158, 159, 160, 161 , 162 and 165).

[0223] This department also works with the printing of the transportation voucher category, which has the following procedure: The operator generates in the system the batch of cards ordered by each company through VTWeb Admin - Bureau, and sends this information to the printer. doing the automatic printing procedure (steps 155, 156, 157, 158, 166, 167, 160, 163, 164 and 165).

[0224] After this process is finalized a conference is made and then the cards are sent to the Transportation Voucher sector (step 164).

Steps 166, 167, 160, 163 3 164 are detailed in Figure 11 where the steps within the transportation voucher department are shown.

[0226] The Vale-Transporte department receives the registration of the companies acquiring this benefit, made through the VTWeb Client system (34) by the beneficiary itself (steps 168 and 169).

[0227] Upon receiving this registration the operator is tasked with contacting the company, where a release of system functions to the beneficiary occurs (step 170). From there it can register its employees and generate credit requests (steps 171, 172 and 173).

Upon receiving the cards made by printing (steps 174 and 175), they go through three processes (step 176), they are respectively: 1st - Conference; 2nd - Packaging; 3rd - Archive;

[0229] The department receives company representatives to remove the cards (steps 177, 178, 179 and 180), with a letter of authorization made by the beneficiary itself as a form of process protection, these authorizations are filed (steps 179 and 181).

Throughout the procedure there is constant management of information and specific problems. MARKETING STAGE (3) [0231] In the Marketing step (3) system credits are traded through the points of sale or through the web portal. At each sale, a credit request for the sale value is made to the credit center, so an uninterrupted communication channel between the sales terminal and the credit center must be considered.

[0232] Sales are only completed after the system validates (SCM module (26)) all business rules entered in the database for the application on the user's card.

[0233] Figure 04 illustrates the credit request process for the switch at the time of sale.

[0234] The process of requesting credit to the switch at the time of sale follows the following steps: 1. The user's card (22) is placed in the card reader without (49) contact of the sales terminal; 2. The terminal verifies the authenticity of the card presented through the SAM_M2 chip (19); 3. After authenticating the presented card, the sales terminal forwards a credit request to the central (23); 4. The SCM module (26) receives the request and checks the business rules defined in the database for the application contained in the card; 5. If there are no restrictions, the SCM module (26) forwards the credit request to the SAM Provider module (25); 6. The SAM Provider module (25) receives the request and withdraws the respective credit value from one of the SAMJM1 chips (18); 7. The SAM Provider module (25) forwards the response to SCM (26) and the sales terminal with the requested credit amount; 8. The terminal receives the reply and the credit is transferred to the user's ticket (22).

[0235] The credit center holds all the system credit, its balance is controlled using the current account concept. For each sale made, a debit transaction is recorded at the exchange. The sale therefore consists of transferring credit from the switch to a user card.

[0236] The sale is only made when the current account has sufficient credit, otherwise the system does not allow trading.

[0237] In the case of sales made at points of sale or stores, according to the steps illustrated in figure 14, the Sales department is responsible for the procedures involving money movement, this sector is responsible for requesting this type of service.

[0238] The user arrives at this department (step 209), where he / she goes through a screening (step 210) to which procedure will be forwarded (step 211, 212, 213 and 214), which are: - Card refills of the following categories: school and citizen (steps 217 and 218). - Sale of forms: school (step 224), citizen (step 225) and duplicate (234).

[0239] The service is then provided, and the user is referred to specific service sectors.

[0240] The entire procedure is carried out in boxes, which at the end of each working day are properly sealed, and pouches of money are sent to the strong car.

Trading of credits on the web through the portal [0241] The user registers on the WEB Portal for the purpose of placing orders. These postpaid orders generate credits that will be charged to the transport user's card. The portal is accessed to serve the user's employers type: [0242] VT: These are employers who make credit requests to their employees. Although employers place orders, the user's card is personal and linked to their social security number. The transportation company can define whether or not profiles will be made available: [0243] Company: Applicable to companies that pay the transportation voucher benefit to their employees. The company places an order by distributing the amounts to be credited to its employees' cards.

[0244] Individual with employee: Applicable to the individual who pays for the transportation of his domestic servants.

[0245] Order credit may be topped up on the card or at a sales terminal.

Refilling credit at the merchant terminal [0246] Users who have placed orders via the internet can load their cards through the merchant terminal. After the terminal reads the user card, which is placed in the contactless card reader (PX), it checks if the credits are released in the system and if the card is reloaded.

Onboard Refill [0247] Users who have placed orders via the internet can load their cards through the validator. When the user approaches his card to the validator in addition to making the payment of the ticket and after identifying if the card contains an application that allows recharging on board, the CRT list is consulted (list containing pending refills). If the card is identified in the list pending order values are loaded onto the card.

[0248] The limit of records in the reload list depends on the available memory.

Selling on board [0249] If the transport user does not carry a card for the release of his ticket at the turnstile, he can make the direct purchase with the collector / driver. In this case the collector / driver may present a specific card to paying users without a card, use a pushbutton or use a specific keyboard function to account for this payment. The previous options depend on the solution purchased by the customer.

Description of the modules of the MARKETING STAGE (3) POS module (MSD or POS PC) (33) [0250] This sales terminal should be operated by the sales clerk only, as the cashier is opened by means of a card without operator contact. In order to start the business activities of the terminal, the operator must place his card in the reader and enter his password.

[0251] The terminal works with the concept of sessions, that means that if the operator wants it can just pause his session for another operator to use the terminal. As in the validator, all transactions performed at the terminal are associated with an operator card.

[0252] Communication between terminal and control panel must be uninterrupted; if there is no communication the terminal is unable to perform any operation. The type of communication with the switch can be: ethernet or GPRS.

[0253] Terminal parameterization takes place via system modules SYS (43) and POS SYS (42). Among the available settings, you can determine, for example, which operations are allowed.

[0254] The features available in the terminal are: [0255] Selling credits: When the passenger's card is placed in the terminal reader and after the SAM_M2 chip (19) authenticates the card, some checks are made at the central: if the card is found on the Restrict List, if there is a pending top up for the card, and if there are any restrictions that prevent the sale from being made. If the restrictions are met, the terminal requests from the credit servers (SCM (26) and SAM Provider (25)) a withdrawal corresponding to the sale amount. Virtual credit is stored in SAM_M1 chips (18) of the SAM Provider server (25), so with each sale that is made, the amount sold is transferred from a SAM_M1 (18) to the passenger's card (22).

[0256] Refill the terminal: After authenticating the passenger's card, and if there is any pending request for this card, the recharge is done automatically. Credit requests can be pre-generated through a sales portal or through other modules of the electronic ticketing system (VTD and VTC), so the terminal the passenger only needs to attend one point of sale to recharge. credits on your card.

[0257] Cancel Sale: Only the last sale made can be canceled. In this case, the credit that was entered on the user's card is reversed on the credit servers.

[0258] Reprint Receipt: Only the receipt of the last sale can be reprinted.

[0259] Register Cash In and Out: When the cashier is opened, the operator can register an cash in value to be used as change. During the daily movement may also occur the bleeding, that is, the withdrawal of cash from the cash. This operation is also recorded.

[0260] Pay credit request: When there are previously generated orders, the user can make the payment of his order, directly in the terminal.

[0261] Perform User Switching: The handset can be operated by more than one operator after opening. Whenever the operator changes, the current operator will need to log out and the new operator will open a new session. This procedure is performed by reading the operator card and entering the respective password on the terminal.

[0262] Terminal lock: If you need to leave the terminal, the operator can lock the terminal. In this case, no operation can be performed until unlocked.

[0263] Sell other products: The terminal is able to sell products other than credit for card recharge, for this, the list of products must be previously registered in the POS SYS module (42). If the product is related to the card the value of this product must be informed at the time of sale. If not, the amount to be charged is verified in the product register.

[0264] Consult Credits: It is possible to check the balance of the user's card (22) by reading it, bringing it closer to the reader of the terminal;

[0265] Closing the Terminal: When you are asked to close the service, the values corresponding to all transactions that have been performed are summarized and printed in a report for accountability. Two types of closure can be performed: [0266] Partial: when the operator wishes to issue the report to his conference at any time without closing the terminal;

[0267] End: Indicates the end of the terminal, ie the end of the service. WEB Portal Module (34) for credit sale [0268] Users have access to the portal and place credit requests. These orders can be paid with tickets that are generated on the portal itself and are available at the end of the order. The portal serves: [0269] Employers: Apply for credit to load their employees' cards. After the credit is released, the recharge can be done on board or in a sales terminal.

[0270] School: Registration is made with a more effective control, because it is a type of user who has the benefit of paying the discounted rate. After the credit is released, the recharge can also be done on board or in a sales terminal. USAGE STEP (4) [0271] Once the ticket cards are ready and configured, users can use them on public transport vehicles in the Usage step (4). When the user presents his card (22) several checks are made, among which we can highlight: which is the priority application: the card can contain more than one application, so a priority order is defined for the use of these applications. . If it is a transaction with credit or gratuity: After identifying the type of application is defined if the transaction involves the payment of the fee or if it is a free transaction.

[0272] Restrictions are verified in the application. The turnstile is only released if there is no restriction on the use of the user's card. Possible restrictions that can be set on the system are: [0273] Usage: Daily, weekly, biweekly, or monthly usage.

[0274] Line: Use on certain lines or group of lines (limit of 4 lines or groups of lines) [0275] Resubmission: Resubmission of the card on the same bus.

[0276] Conference: Whether the biller or driver will identify if the user who is holding the card is actually the cardholder. This identification is made through the photo and the release of the ticket is made through the card, button or keyboard.

[0277] Time group: Whether there will be time restrictions (morning, afternoon, evening), days of the week, holidays, etc.

[0278] Validity: Card expiration date.

[0279] Fingerprint Recognition: When purchased it is attached to the validator and after use of the card, the user must place one of their fingers on the fingerprint reader to read and recognize the fingerprint. This restriction is only possible with the implementation of the fingerprint device and after registering the user's fingerprint in the UCA module (29).

[0280] Fare payment is made after all checks have been completed, including whether the card is pending recharge and whether the card is on the restrictive list.

[0281] Figure 05 illustrates the process of using a user's pass card on the public transport vehicle, such as the bus.

[0282] Operator (50) configures validator (49), binds, and changes state of validator (49) to allow business operations.

[0283] When the validator (49) reads the user card (22), checks if it is a credit or gratuity card, checks the application contained therein and what the restrictions are for it. Then, if it is a credit application and if the restrictions are met, debit the amount corresponding to the user card fee (22) and record the operation in its memory.

[0284] User card reading (22) occurs at an interval within 0.9 seconds and 1.2 seconds. This time depends on some factors, such as whether there is a reload list to check and the number of records contained in it. STEP ACCOUNTABILITY (5) [0285] After one day of operation, public transport vehicles return to the garage to count the cards (22) used in this vehicle in the Accountability stage (5). Accountability should be performed by the person responsible (50) for opening and closing commercial services in the validator, such as in the case of the bus driver.

[0286] Figure 19 illustrates in steps 324 to 331 the actions performed in the accountability step (5) are described.

[0287] After detaching from the validator (49), the operator (50) attends the receipt (step 328) to account for transactions that occurred during the period that the public transport vehicle, such as buses, was in operation. Operator card 22 is read, data is transferred to the terminal (step 329) and operator card is reset, ie data is erased (step 331). This last operation allows the operator card to be available for the next service opening (step 301).

[0288] The operator receives a ticket containing the amount of transactions performed on the validator during the time that his card was linked. This information is grouped by statistical groups, ie by applications.

[0289] With respect to sales made on board, the operator should check the amount collected in the ticket and deliver the specific amount of money (step 330).

Accountability at the sales terminal [0290] The sales terminal, which can be POS PC or MSD, is able to accumulate the function of receiving, that is, allow the operator to be held accountable.

[02 91] POS PC is the software module for selling electronic credits. Installed on Windows platform computers connected to the database via network, dedicated link or internet. All transactions are made under database access and credit release via SCM server (26) and SAM chip (14). Requires a non-contact PX Card Reader and non-tax thermal or dot matrix printer.

[0292] The MSD is an electronic credit marketing device. No computer required, uses GPRS network from mobile operators. All transactions are made under database access and credit release via SCM server (26) and SAM chip (14). Mobility, contingency and security in financial operations are the main features of POS MSD.

[0293] The sales terminal's features with regard to accountability are: reading and transferring data from the operator's card (50) to the database;

Reset the operator card (51);

Print the operator conference ticket (50). STEP Modules Description ACCOUNTING (5) Collector Module (35) [0294] The Collector (35) is a system module installed locally on a workstation and is responsible for collecting information from the operator card (51) responsible for opening and closing the validator (49) and for recording and printing this information.

[0295] The Collector module (35) is used in the Receierge (usually located in the garage). The validator operator (50) (may be: drivers and collectors) attends the receivership to account for the business transactions that occurred during the time his card was linked.

[0296] Collector (35) is responsible for the following operations: Reading the operator card (51) of the public transport vehicle, such as bus, (driver / collector) to collect information on operations performed on the validator (49);

[0297] Reporting on operations performed for the operator's financial settlement.

In a nutshell, the Accountability routine consists of: The module operator (50) must place in the contactless card reader (49) connected to the station where the Collector is installed, the operator card ( 51) that opened and closed the service in the validator (49);

[0299] After reading card (51), data is written to a database (local or Central depending on the project environment), service data is deleted from the operator card (51) and a ticket is printed. containing the amounts of business transactions summarized by application. Collector Module SYS (36) [0300] Collector Sys (36) is responsible for the following operations: Reporting with reporting data;

Configuration and management of the reception windows. COMMUNICATION STAGE (6) [0301] Through the Communication step (6) of Fig. 01, and detailed in Fig. 06, the processing data of ticket tickets are transmitted via wireless communication such as: IrDA, Bluetooth, ROUGH, Wi-Fi, WiMAX, Mesh, WiGig or other IEEE 802 compliant with the server (s), called the system V3LAN (39).

[0302] Data exchange between exchange (7) (location containing database and system administration) and validators (49) installed on public transport vehicles (57) takes place through archives.

[0303] The following files should be generated and exchanged: [0304] From switch (7) to validators (49): EOD generated files (37) containing configuration parameters, updates, reload list, and restrictive list (54 );

[0305] From validators (49) to switch (7): files generated in validator (56) containing the transactions that were performed.

[0306] Files are centered on a station installed with the V3LAN module (39). The WormHole Client module (40) that is installed on the same station (39) manages the distribution of these files. This module is optional and if it has not been implemented its function must be performed manually.

[0307] Communication occurs when validators (49) are within the area covered by the network, in the "Closed" state which is the specific state for communication to occur.

[0308] Communication with validators (49) of public transport vehicles (57), such as buses, will take place over a wireless network. Public transport vehicles (57) communicate in the garage, which is where there is network coverage with wireless antennas (58).

[0309] Prior to the installation of the system, a study called "Site Survey" is carried out. In this study, the location of the antennas (58) access point and the amount required for effective network coverage in the garage are defined.

[0310] All garages must have a station installed with the V3Lan (39) and WormHole Client (40) modules, whose responsibility is to manage file sending and receiving between the switch (7) and the vehicle validators (49) by public transport (57).

[0311] It is also possible for validators (49) to communicate via GPRS or other remote communication protocols.

[0312] From server (s), called V3LAN (39), data is transmitted via wired or wireless ethernet network to the server (s) named WH of the central office in step COC (7) of the system.

Description of STEP COMMUNICATION modules (6) Equipment Operational Data (EOD) module (37) [0313] System module, installed at the administrative station and for the purpose of managing the generation and submission of files to the validator (49). EOD (37) acts as an intermediary for transferring information from database (53) to validators (49).

[0314] The EOD (37) is included in the set of modules whose operation must be monitored, daily the operator (50) must perform the version generation, file generation and distribution operations.

[0315] Configuration of the EOD module (37) is done via the SYS module (43). In this module it is necessary to indicate the storage location of the files that are part of the process.

[0316] Briefly the function of this module is to scan the database tables (53) that contain data that needs to be updated in the validator (49), encode this data in binary data so that it can be interpreted, generate files with the data that were coded and distributed among all stations installed with the V3Lan module (39), which are the stations responsible for communicating with the validators (49).

[0317] The functionality of this module is: [0318] Manage versions: The generation of a new version aims to control the versioning of the files that are generated to send to V3Lan stations (39). Before generating new files to send them to these stations, the system operator must always generate a new version. Versioning allows the system operator (50) to easily identify if there are any outdated V3Lan (39) stations.

[0319] Generate binary files: Binary files are generated after the system scans tables containing data that must be updated in validators (49). The validator (49) only interprets binary data, so the scanned data is encoded by this module and the file is generated to be sent to V3Lan stations (39).

Control file distribution: Files should be distributed to all V3Lan stations (39) after the generation process. Registration of all V3Lan stations (39) that should receive these files is done previously in the SYS (43) module of the electronic ticketing system. The EOD module (37) lists after generation of the binary files and the request to deploy all V3Lan stations (39) and displays the status so that operator (50) can monitor whether all stations are properly updated with the version. correct.

EOD-generated binary files (37) [0320] The binary files that are generated by the EOD (37) are as follows: Usage Data Processor (UDP) module (38) [0321] System module, installed on the processing server for the purpose of which It is to receive the files generated in the validator (49) containing the record of transactions performed and process them to include the data of these transactions in the database (53).

[0322] Like EOD (37), UDP (38) is included in the set of modules whose operation must be monitored, daily files are received from the validator (49) to be processed.

Briefly, the process is as follows: station V3Lan (39) sends the file received from the validator (49) to the UDP module (38), the file is decoded from binary for interpretable data. After decoding, the file is processed record by record, ie the data is read by rows and then inserted into the respective database tables (53).

[0324] UDP (38) contains an internal configuration where you can specify paths for accessing folders that store process files. Depending on the phase of the process the file is transferred from one folder to another. The folders are organized as follows: AProcess: location that stores binary files that have not yet been processed, that is, they were just sent from V3Lan (39) to UDP (38);

Processed: Location that stores binary files that were successfully processed;

FileAlreadyExists Error: Location that stores the files separated because they have already been processed once;

General_Error: Location that stores files that showed inconsistencies during the analysis phase;

SQL_Error: Location that stores files that experienced errors during the database insertion phase (53).

[0325] All of the above folders work with the concept of queuing, ie the UDP module (38) always executes the file that was sent first.

[0326] The functionalities of this module are: [0327] Process binary files: the validator (49) generates a binary file (56) that records all the transactions that were performed, this file is sent to the V3Lan station (39) that the forwards to the UDP module (38). The file is received in the "Apply" file folder. The first file in the queue is always processed, after being processed this file is transferred to the "Processed" files folder or if there is an error to the "Error" folder. The first processing step validates the file and transforms the binary file to readable data.

[0328] The second step is to include the file data in the database (53). The file records are read one by one and are included until the file is finalized. The process of inclusion in the database (53) occurs through procedures. V31an Module (39) [0329] This system module should be installed where validators (49) communicate with the switch (7). It is part of the monitored operations, ie it must be periodically operated to effectively communicate and to avoid outdated files sent by validators (49) and received by them.

[0330] The functionality of this module is: [0331] Receiving validator files (49) and sending to UDP (38): 0 V3Lan (39) is always active waiting for UD (Usage Data) files coming from validators (49) . It can receive multiple communication requests simultaneously. The validator (49) sends the file to UDP (38) which must monitor whether the communication was successful and manage the receipt of the file.

[0332] Receive EOD files (37) to send to validator (49): After the EOD file generation routine (37) occurs, these files (54) are made available to the V3Lan module (39). The validator (49) is in a receptive state waiting for communication from V3Lan (39) (Closed state). The V3Lan (39) runs through the table of registered cars checking which validators (49) are present in the connection zone.

[0333] When connecting to a validator (49), V3Lan (39) forwards the files generated by the EOD module (37).

[0334] Configure module for use: Allows you to configure a number of parameters: database, operating states (such as "under maintenance", "in operation"), file path, network, etc.

[0335] Issuing reports: viewing and issuing various reports: Antennas Access points installed;

History of communications made with validators;

Monitoring of communications made;

Status of validators;

Events held. WormHole - Client Module (40) [0336] This system module is intended to automate communication through file exchange between: V31an (39) stations, validators (49) and switch (7).

[0337] The client version is installed in the garage and the server version is installed in the switch (7). It is an intelligent file transfer service (54 and 56), as its scalability and customization allow it to be applied to different models and easily interact with 100% of the features installed on any of the network bound terminals.

[0338] The client WormHole (40) is part of the operations that must be monitored periodically, daily must be operated.

[0339] WormHole (40) Client is installed on the same station as V31an (39).

[0340] The features of this module are: Automatically Distribute Files: Automatically distribute files from the V3Lan station (39) to validators (49) and vice versa. As well as control of files received from EOD (54) and sent to UDP (56);

Control file versions: Automatic control of file versioning, as well as verification of outdated equipment;

Monitor file send and receive: Allows you to check by equipment a history of received files. COC ADMINISTRATION STAGE (7) [0341] The central system (7) consists of a set of modules responsible for the configuration and administration of the entire electronic ticketing system.

[0342] All modules must be operated by highly qualified professionals, as some modifications may have major impacts on system components.

[0343] Business rules are configured in different system modules. SCM SYS (44), SYS (43), and POS SYS (42) are the modules designed to configure the system according to the project operating rule.

[0344] UDP Process (38) is responsible for keeping up-to-date lists that are sent to validators (49). Customer Monitored Operation [0345] Some modules must be serviced by an operator (50) periodically, this means that daily, for example, it is necessary to generate the updated restrictive list (54). Operation at an improper period impacts a system malfunction, for example, if the restrictive list (54) is not updated every day, a card (22) whose lock request is registered in the system will continue to be used in validators. (49) until an updated restrictive list (54) version is submitted.

[0346] The modules used in the electronic ticketing system are: SAM Provider (25), SCM (26), EOD (37), UDP (38), V3Lan (39), WormHole Server (40), WEB Admin (34) and UDP Process (38).

[0347] It is part of the monitored operation to check the return files (56) from the database (53) and process them.

[0348] These files contain payment data that has been made on slips from orders placed on the portal.

[0349] During the implementation of the electronic ticketing system, the system administrator is trained, who must be the technician responsible for monitoring all processes involving the monitored operation and able to operate the electronic ticketing system modules. Description of STEP COC ADMINISTRATION modules (7) UDP Process Module (38) [0350] This system module is installed on the processing server and is intended for batch processing. It can be started in two ways: by an operator or by scheduling Windows tasks.

[0351] This module is part of the operations that must be monitored.

[0352] The features available in this module are: [0353] Refresh Reload List: Routine that compares the current reload list with the refills that were made on the day. Reloads that have been made are excluded from the list, meaning that the reloads that occurred in the validator are "written off".

[0354] Update cards via validator: User card data (22) can be updated via validator (49). This module manages the entire process for updating the card (22) and consequently removing it from the reload list after reloading on the validator (49).

[0355] Implement smart restrictive list: Smart restrictive list manages the cards that should be left or removed from the list. If, for example, a card (22) is placed on the restrictive list, is not used and exceeds the time it is listed, when it is used, the transaction data of usage will be recorded in the system. UDP Process (38) verifies that use has occurred and adds card (22) back to the restrictive list to block it.

[0356] Update restrictive list: maintenance of restrictive list by removing cards (22) that have already been blocked. The list contains x number of cards that can be checked, so always remove the already physically locked cards. POS Module SYS (42) [0357] System module installed at the administrative station, the purpose of which is to configure POS terminal functions (33), as well as the products sold, the text printed on the receipt, the price of the products, the boxes used in the system, etc.

[0358] This module should be accessed only when the configuration of sales terminals is changed.

[0359] The functionalities of this module are: [0360] Registering Products for Sale: All products that can be sold at POS (33) in addition to recharging credits need to be previously registered in the system. In this register, the price is recorded, if the product will be sold at a discount, what is the minimum and maximum desirable value of the product, to which product group it belongs, etc.

[0361] Register discounts that can be granted by products: register the discount that can be granted for a given product. Discounts are previously registered in the POS SYS module (42).

[0362] Register comments for printing on receipt when sold on a particular terminal: option associated with terminal registration and is used when adding specific comment lines when selling on a particular terminal.

[0363] Register promotion for a particular product: Set a promotional value for selling a product.

[0364] Register Product Groups and Subgroups: Registration to organize the registration of products by classifying them into groups and subgroups.

[0365] Registering different types of receipts: registration for printing different types of receipts. The different receipt impressions must be associated with the sales terminals.

[0366] Register Payment Methods: Registration of the payment methods accepted in sales made at the terminal.

[0367] Register sales terminals: register of all sales terminals operating in the system. SYS Module (43) [0368] This system module is installed on the COC administrative station (7) and is intended for the registration of ancillary data that needs to be used by the system. In addition, the module contains tables responsible for parameterizing the operating rules defined for the electronic ticketing system.

[0369] SYS (43) can be said to be the system configurator module. It defines which features will be available, the behavior of the system in the face of some operations and configures user interaction messages.

[0370] This series of configurations gives the electronic ticketing system much flexibility in defining the rules in the system.

[0371] This module is part of monitored operations, as these are settings that alter system behavior. It should be accessed only when there is a need to make a new registration or reset some parameterization.

[0372] It is noteworthy that the operator of the SYS (43) module must have a thorough knowledge of the whole concept of electronic ticketing system, as a parameter change may result in significant system changes or even in the improper functioning of one of the modules of the system. system or on-board system in public transport vehicles.

[0373] The module is divided into several groups of registers, as described below: [0374] Basic tables: registration of data to support the main registers of the system. It can be considered as one of the main registers of the system, for example, the user register. In this case, some supporting data are: document type, states, cities, address types, etc.

[0375] Vaiidador: register and configurations that are necessary for the validator operation.

[0376] Card: entries related to contactless cards that will be used in the system.

[0377] Application: entries related to applications that will be implemented on the system's user cards.

[0378] Modal: records of locations that there is some electronic ticketing system activity.

[0379] DOE: register of places whose data can be exported.

[0380] Financial: entries related to the receipt of payments made in the system.

[0381] Disabled: Registration of types of deficiencies recognized in the electronic ticketing system.

[0382] Security: user registration and access permissions granted.

[0383] The entries and configurations available in this module are: SCM SYS Module (44) [0384] This electronic ticketing system module is installed on the COC administrative station (7) and is intended to configure and register devices that interact with the SCM module (26). Like SYS (43), this module is part of monitored operations because it deals with settings that alter system behavior.

[0385] It should be accessed only when there is a need to make a new registration or to reset some parameterization.

[0386] The entries and configurations available in this module are: WormHole Server Module (40) [0387] This module is installed on the processing server and is intended to manage the automation of communication between the components of the electronic ticketing system that occurs. through the exchange of files. Must be assisted periodically by an operator.

[0388] The features contained in this module are: [0389] Transfer files received from V31an (39) and forward to UDP (38): Transfer files from V31an (39) that were generated in the network validators. These files are forwarded to UDP (38) for processing.

[0390] File Receipt and Send Protocol: Any transfer operation meets the following premises: [0391] Notify the Processing Service of the quantity and quality of the files (54) transmitted.

[0392] Notify the move file sender of the quantity and quality of files (56) received.

[0393] Notify moving file sender of quantity and quality of successfully processed files.

[0394] Notify the drive file issuer of the absence or corruption of the information contained in any of the received files. WEB Admin Module (34) [0395] It is a web module and is responsible for: UCA (29), SYS (43), Web Client access (34) and port administration functions. It must be operated by a skilled user who is thoroughly familiar with the concepts of the electronic ticketing system.

[0396] In addition, the module includes user administration (52) and access permissions.

[0397] Parallel to the entire system for generating, using and controlling public transit ticket cards or e-tickets, there is a department responsible for receiving, processing and remedying the problems reported by complaints from users of the electronic ticketing system. This department is called the integration department.

The steps performed by this department are illustrated in figure 12.

[0399] The Integration department receives complaints (step 183) and verifies (step 184) whether they were made via store (step 185), website (step 186) or telephone (step 187), from which the analysis procedure begins. (step 188) of each process generated by the complaint.

[0400] The first procedure performed is the verification (step 189) of the card usage statement, if integration failure is detected (step 190), the user is told to attend the store (step 191) and receive a refund for these tickets. (step 192), finishing the process (steps 193 and 194). If no fault is detected, the user is informed (step 195) and receives the appropriate card usage guidance (step 196), with no refund and finalizing the process (steps 193 and 194).

[0401] Some cases need a second evaluation procedure (step 188), when they raise questions, where an on-board report is requested, triggering further analysis and the procedure can then be terminated as stated above, all open processes are archived ( steps 193 and 194). Throughout the procedure there is constant management of information and specific problems.

[0402] In addition to the integration department, there is the telephone customer service for the electronic ticketing system, as detailed in Figure 13.

[0403] The telephone department (step 197) performs customer service using the request control system checking which type of service to perform (step 198).

[0404] Performing the following procedures: Receives complaints via telephone (step 207) and forwards to specific sectors (step 208). - Receives card lock requests (step 199) and sends a card lock request (step 200). - Formulate appeal letters for new special case applicants (steps 202, 203 and 204). When this is not a new case or a card found by a third party and sent to the service provider, it checks the progress of the process (step 205) and transfers it to the customer information department (step 206).

[0405] In all procedures there is constant information management.

Still within the COC administration step (7), the following are provided: the hardware service module as shown in Figure 15 and software as shown in Figure 15; the new report creation module as illustrated in figure 17; and the new systems creation module, as illustrated in figure 18.

[0407] Upon detecting a failure or malfunction of certain hardware (step 240), the user makes an e-mail request to the information technology department via an e-mail channel explaining the problem ( step 241).

[0408] The support department, upon receiving this request, opens a technical call through the OCOMON system (step 242), which will later be sent for analysis (243), which is performed by checking whether the occurrence indicated by the user proceeds. If the same does not proceed, the user is informed having their doubts answered and the call is terminated in the system (step 245).

[0409] If a real problem is found, the possibility of an internal resolution without third party intervention will be verified. If a positive result is obtained, the problem is solved and the call terminated (step 245).

[0410] Noting the need to have it resolved by the service department, a service request is sent to it (step 246). After all procedures are completed by the company, the company sends us the answer to the problem (step 247).

[0411] Upon sending the equipment for service, you would receive a resolution for a resolution. After the return (step 248), it is verified by specific tests (step 249), having a positive result the call is terminated (step 245). Having a negative result (step 250) we move on to the assistance again (step 246).

[0412] Upon detecting a failure in some process of running certain software (step 251), the operator makes an email request to the information technology department via the email channel explaining the problem (step 252) ).

[0413] The support department, upon receiving this request, opens a technical call (step 253), through the OCOMON system, which will later be sent for analysis (step 254), which is performed by checking whether the event indicated by the user proceeds. (step 255). If it does not proceed, the user is informed having their doubts answered (step 263) and the call is terminated in the system (step 257).

[0414] If a real problem is found, an internal resolution (step 256) will be verified without third party intervention. If a positive result is obtained, the problem is solved and the call terminated (step 257).

[0415] Noting the need to be resolved by the software developer, a maintenance request is sent to it (step 258). After all procedures are completed by the company (steps 259), the company sends us the answer to the problem by performing the system update (step 260). The software is then tested (step 261) and if the problem has been resolved the call is terminated (step 257). Otherwise, a new call opens with the company (step 258).

[0416] From the need to develop a new report (step 264), the operator makes an e-mail request to the information technology department (step 265) via the email channel explaining the case.

[0417] The support department, upon receipt of this request, opens a technical call (step 266) through the OCOMON system, which will then be sent for analysis, checking the possibility of the development that was requested (step 267), otherwise A search for new alternatives is started with the user (step 278). If no viable procedure is found (step 279) the user is informed (step 280) and the call terminated (step 276).

[0418] After confirming the feasibility (step 269) of the report development is defined by who will carry out the process (step 270), the procedure being performed by the technology department itself or by the software provider company, starting the creation process. .

[0419] Once finalized it is subjected to specific tests (step 271), the process being positive, the report is published (step 273) and thus the requesting user receives training (step 274) for use. After satisfactory user expression (step 275) the call is terminated (step 276).

[0420] However, if the tests are negative or if there is a manifestation of user dissatisfaction, the report is sent back to development (step 270).

[0421] From the need to develop a new system (step 281), the operator makes an e-mail request (step 282) to the information technology department via the email channel explaining the case.

[0422] The support department, upon receipt of this request, opens a technical call (step 283) through the OCOMON system, which will later be sent for review (step 285), verifying the possibility of the development that was requested (step 286). , otherwise a search for new alternatives is initiated with the user (step 296). If no viable procedure is found the user is informed (step 298) and the call terminated (step 294).

[0423] After confirming the feasibility of the system development (step 287) is defined by who will perform the process, the procedure being performed by the technology department itself or by a specialized company, starting the creation process (step 288).

[0424] Once finalized it is subjected to specific testing (step 289), the process being positive, the system is put into production (step 291) and thus the requesting user receives training (step 292) from it for use. After satisfactory expression (step 293) of the user the call is ended (step 294).

[0425] However, if the tests are negative or if there is a manifestation of user dissatisfaction, the system is sent back to development (step 288). FINANCIAL STAGE (8) [0426] Finally, the data is processed and the process financial data is generated in the Financial step (8).

[0427] The finance module consists of the Clearinghouse (45) which is used only when there is a need to control between two or more transport companies the generation revenue generation through the sale of credits and the use when there is integration between public transport vehicles. from different companies.

Claims (7)

1. ELECTRONIC TICKETING SYSTEM characterized by containing at least one SAM chip card, at least one smart card, at least one contactless smart card reader, at least one contactless card sales terminal, at least one validator contactless cards, at least one wi-fi access point antenna, at least one microprocessed display keyboard, at least one microcontroller, at least one biometric thermal digital reader, at least one contactless card printer, at least one reader SAM card type, at least one server, at least one firewall, at least one public transport vehicle, where the system correlates such devices to enable users with contactless smart card passages to use public transport and said system controls such cards and their use through contactless card validators and digital biometric thermal readers s to ensure that such cards are used only by the persons to whom such cards have been issued through the processing steps: CEREMONIAL STAGE (1); REGISTRATION AND CUSTOMIZATION STAGE (2); MARKETING STAGE (3); STAGE OF USE (4); ACCOUNTING STAGE (5); COMMUNICATION STAGE (6); STEP ADMINISTRATION COC (7); and FINANCIAL STAGE (8). System according to claim 1, characterized in that the CEREMONIAL STEP (1) contains the following processing modules: - Ceremonial Module (24); - SAM Provider Module (25); - Secure Credit Manager (SCM) module (26); and - SAM Cash Module (27). System according to claim 1, characterized in that the REGISTRATION AND CUSTOMIZATION STEP (2) contains the following processing modules: - User Card Administration (UCA) module (29); - Record Card Module (30); Remote Printer Card (RPC) Module (31); and - Card Design Layout (CDL) module (32). System according to claim 1, characterized in that the MARKETING STEP (3) contains the following processing modules: POS module (MSD or POS PC) (33); and - WEB Portal Module (34). System according to claim 1, characterized in that the ACCOUNTING STEP (5) contains the following processing modules: - Collector module (35); and - Collector SYS module (36). System according to claim 1, characterized in that the COMMUNICATION STAGE (6) contains the following processing modules: - Equipment Operational Data (EOD) module (37); - UDP module (Usage Data Processor) (38); - Module V31an (39); and - WormHole - Client Module (40). System according to Claim 1, characterized in that the COC ADMINISTRATION STEP (7) contains the following processing modules: - UDP Process module (38); POS SYS module (42); SYS module (43); SCM SYS module (44); - WormHole Server Module (40); and - WEB Admin Module (34).