JP5715175B2 - Electronic processing system - Google Patents

Description

  The present invention relates to an electronic processing system for handling financial transactions in a highly secure and extremely secure manner.

  Over the past few decades, the range of options available to people to handle and transfer money has increased significantly. For example, the use of credit and debit cards in countries has risen almost exponentially, and in recent years there has also been a substantial and expanding market where goods are purchased over the Internet. As a result of the above developments, the use of standard checks drawn from personal bank accounts has declined relatively. However, other documentary transactions exist, such as vouchers for redemption within the ever-growing retail stores. Thus, a considerable number of monetary transactions based on documents are still taking place each year, even though check issuance has declined relatively.

  It has long been understood that transactions on documents such as checks or gift certificates for redemption are expensive to manage and are subject to counterfeiting. In addition, businesses around the world are outsourcing non-central activities to more specialized third parties, so that at the lower level, retail transactions that can accommodate a single inexpensive product at a retail store There is clearly a need for a flexible and safe transfer system to handle even relatively small amounts of money.

  Another problem that has arisen with electronic money transactions is that there are still many individuals who do not want to reveal details of their banking transactions to retailers when they are not at the retail store. Accordingly, such individuals have limited ability to fully utilize the functionality of the Internet. Furthermore, making purchases over the Internet with the possibility of discounts is not available to people who do not have a credit or debit card. Thus, the current transfer system is substantially deprived of rights from the two groups of potential customers.

  Finally, one of the consequences of the increasing popularity of electronic transfers is that retailers and credit card issuers must follow time-consuming fraud prevention procedures for all purchases.

  Thus, the present invention is particularly highly secure, and at the same time efficient in data storage space usage and processing time, and can be used over the Internet, telephones or in physical stores. It relates to finding the system.

In accordance with one aspect of the present invention, an electronic processor system is provided for use in processing financial transactions including an electronic processor and a database, the processor comprising:
1) To receive a request from a member using a system to generate an encoded number representing a desired monetary value purchased at a remote terminal, so that a previously allocated number can be redeemed An interface for transmitting the generated number to the remote terminal, and for transmitting a message to the terminal indicating that the received redemption request is valid;
2) a verification section for determining whether the received request is valid;
3) a number generation section for generating an encoded number in response to a valid request;
4) To represent each number generated in response to a valid request in the first table of the database, represented by an issued encoded number that has not been redeemed in the funds table. Each of the codes for which a redemption request that was found to be valid is received, and to transfer to the second table the encoded number that is deemed valid for redemption. worth represented by reduction by number, and decrements the total in the fund table, each number is one coded outstanding, is more than once the value represented in the final table incremented it is never, also for each number of redeemed is one coding performed, and a storage section for values stored to the so that it can be decremented by one Including.

Preferably, the number generation section is adapted to generate the cash voucher number in a manner that incorporates other details regarding the subsequent redemption of the cash voucher.
The present invention also includes a method for processing monetary transactions and a terminal for use with the processing system described above.
In order that the present invention may be more readily understood, embodiments of the present invention will now be described by way of example with reference to the accompanying drawings.

FIG. 2 is a block diagram illustrating a general overview of an electronic processor and associated peripheral terminals according to embodiments of the present invention. It is a block diagram which shows the main database table of the electronic processor of FIG. It is a block diagram which shows the hardware regarding the system of FIG. It is a data flow figure which illustrates the purchase of a cash exchange ticket. It is a figure similar to FIG. 4 which shows the purchase of the cash exchange ticket via the internet. It is a data flow figure showing exchange of a cash voucher in a point of sale terminal. It is a data flow figure showing exchange of a cash exchange ticket via the Internet. It is a figure explaining organization of a fund account. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a table which shows the movement of money in the example of dealings. It is a flowchart which shows the purchase of a cash exchange ticket in detail. It is a figure similar to FIG. 12 which shows exchange of a cash voucher. It is a figure which shows the adjustment in the system shown in FIG. FIG. 3 is a block diagram illustrating the relationship between a retailer, a core system, and an actual bank account. It is a table which shows account posting. It is a table which shows account posting. 3 is a flowchart showing a security algorithm.

  Referring now to FIG. 1 of the accompanying drawings, an electronic transaction system including a voucher processing system 1 having a front end interface 2 is shown. The term “money voucher” is used herein with a special meaning. This term should be clearly distinguished from paper vouchers often used by retailers for later redemption. Record tickets are a well-known example of such paper vouchers, as are reward coupons issued by retailers based on the amount of purchases by customers. As used herein, a cash voucher is basically a computer record stored on a secure master database. The system described has several layers of functionality, and for illustrative purposes only, the entire cash voucher handling system includes three different retailers, indicated as 3, 4, and 5, respectively, as participating members. Assume that merchants A, B, and C are involved. Again, for illustrative purposes only, it is assumed here that the retailer is a conventional retailer that supplies goods to individual shoppers or customers who place orders remotely.

The system shown in FIG. 1 has five layers of functionality, shown separately at 100, 200, 300, 400, and 500.
The functionality of the first layer is shown at 100 and includes a terminal where the customer interacts with the entire system.

  Accordingly, retailer A can be seen to have a cash voucher sales terminal 6 that is self-service and a cash voucher sales terminal 7 with attendant. Retailer B has a voucher redemption terminal 8, but retailer C handles the sale and exchange of money vouchers only via the Internet.

  The second tier functionality 200 represents a retail company where a customer transacts through the tier 100 by purchasing a cash voucher or by redeeming a previously purchased cash voucher for a product.

  At the functional layer 100, the self-service terminal 6 basically includes a manual data structure such as a keyboard, a display terminal, and a reader for reading credit / debit cards for verification or to accept money. . The terminal 6 can also include a printer for providing a hard copy of the voucher. FIG. 3 shows an example of such a terminal using a credit / debit card. A customer who wishes to purchase a cash voucher performs a series of operations similar to those used to obtain money from a cash dispenser based on his PIN. The attendant terminal 7 also has a manual data output configuration used by the attendant and also receives money or any other payment medium acceptable to the retailer in exchange for the issuance of a cash voucher. Can do. Of course, the clerk can make further confirmation of the customer's identity.

  Retailer B, indicated at 4, has a redemption point 8 that can be redeemed for money or merchandise on the cash voucher, while retailer C, indicated at 5, is used by the customer over the Internet. Internet-based system that can obtain cash vouchers. To do this, the customer must have internet access, and this can be provided immediately in several different ways, such as via any internet PC or mobile phone. is there. Typically, the user has a PC 9 with a modem so that the retailer C's Internet Service Provider (ISP) 5 can be contacted via the user's own ISP 9 '.

  It will be appreciated that the above three terminals 6, 7, and 8 are merely exemplary and there is no need for the retailer to be limited to any one type of terminal at the second tier 200. In any case, the function of the terminal is basically to collect exchange ticket purchase information or exchange ticket exchange information from the user, and to perform basic verification. If there is something that depends on the amount of verification, if the data collection terminal is not staffed, it depends on the level of intelligence of the terminal or on the procedure followed by the staffed terminal. This procedure can be determined by the retailer, provided that it meets the minimum requirements of the system operator. The commercial relationship between the retailer and the voucher system is described in more detail later in this specification.

  The normal functions performed in normal business by the various retailers in the second layer 200 of the general system will not be described in detail. However, in this second layer, new data entered at the terminal in layer 100 is processed by the retailer in the functional layer 400 for communication to the interface 2 of the core system 1. .

  All the retailers mentioned above are “members” of the cash voucher system. Therefore, retailers can have their own voucher scheme, and if they have their own scheme, they may have a bank account for funds involved in the operation of the cash voucher system. Is possible. On the other hand, members can also manage the system for themselves. An example is Big Book Tokens Ltd. It is a general-purpose book voucher scheme having such an owner. In this case, the cash voucher can be purchased from any retailer and can be redeemed under appropriate conditions from any accepted retailer.

  In one embodiment of the present invention, this processing in the functional layer 200 is basically suitable for a second level of verification, described in more detail below, and for secure transmission to the layer 400. Consists of encrypting data into a format. This transmission can be via the well-known Interbank Communication System indicated at 11 in the functional layer 300 or directly from the retailer. Even when done directly from the retailer, the encrypted data can be in the standard MTIxxxx format used in interbank communication systems. In addition, retailers can introduce restrictions on voucher redemption at either tier 100 or 200. This constraint is quite important and will be discussed in detail later in this specification.

Another vital function of layer 200 is decryption of messages received from layer 400.
In the figure, a dashed line 12 linking layers 200 and 400 indicates an optional link between the retailer system in layer 200 and layer 400, which linkage is whatever the communication protocol used. There is no need to use a protocol format. This link 12 can be used to transfer additional data held by the retailer regarding the cash voucher and non-emergency data such as the retailer's own analysis and management information about the record. Thus, this link 12 does not require encryption used when details of cash vouchers are transmitted between functional layers.

  In the figure, a further link 13 links the retailer 14 in the tier 200 to the core system 1 located in the tier 400. This link 13 can transfer a lump-sum allocation file for the details of the vouchers allocated in a lump, and for this reason, in some cases, to allocate cash vouchers as patronage rewards or for promotional schemes. Can be used for

  Referring now to core system 1, system 1 receives section 15 for receiving messages via links 12 and 13, and interbank communication system 11, or signs from 3 and 5. It has an interface 2 with a section 16 dedicated to receiving and sending messages in a standard format from or directly to the retailer, as indicated by the unattached link path. Another main interface of the central processor 1 is indicated at 17, which is the interface used by the system operator 18, the organization that manages the entire system for a particular member.

  One of the basic components of the core system 1 is a database 19 that contains a plurality of database tables used to process cash vouchers. The main table of the database 19 is shown in FIG. 2 of the accompanying drawings, which includes a main table 20 that holds data for surviving money vouchers and redeemed cash vouchers. In this embodiment, this table 20 has a history that can hold the details of all the cash vouchers that have been redeemed, and the life voucher table that holds details of all the cash vouchers that have not been redeemed. Divided into sections containing voucher tables. The word “possible” is used because it may be necessary to archive the details of the historical voucher in the archive section after a predetermined period of time. Furthermore, the table 20 holds the details of the voucher without the claimant. Table 21 of database 19 holds member details, i.e., details of all such members, such as retailers A, B, and C, participating in the cash voucher processing system managed by the system operator. Thus, a member is a retailer or owner of an individual scheme.

  Table 22 is a fund ledger table that holds the details of the funds that provide the endorsement of the cash voucher listed in the life voucher table, while table 23 is when the voucher is issued: Or keep details of the ledger transaction that takes place when redeemed. Each cash register substantially tracks a physical bank account held at a financial institution shown in the functional layer 500. The manner in which funds are organized and the manner in which the funds interact with actual bank accounts will be described in more detail later.

  The cash register table 22 is associated with a voucher issuer table 24. This table presents the conditions when the cash voucher is issued by the issuer. At this point, it is crucial to clarify the possible relationship between the core system operator and the members who request the cash voucher and participate in the actual process of redeeming the cash voucher. . Members can belong to a range of different categories.

  The first category is a category of voucher issuers sometimes referred to as owners. The voucher issuer is an organization that has a contract with the system operator and defines a specific class of voucher by setting restrictions on how the voucher can be used.

  The second category includes members who are permitted to sell the voucher on behalf of the voucher issuer, and the third category includes members who are permitted to redeem the voucher. Of course, it is perfectly possible for the voucher issuer to belong to either or both of the remaining two categories. Each cash voucher number generated by the system includes a voucher issuer number (VIN). This VIN identifies the voucher issuer. As described above, the voucher issuer has the ability to define restrictions on the use of money vouchers. In this embodiment, defining the constraint is accomplished by further coding in the cash voucher number, such that the combination of VIN and this further coding defines the conditions for use of the voucher. In normal operation related to the core system, it is a part of the voucher issuer, and when the voucher is purchased, it is not necessary to know the restriction code transmitted to the core system in response to the request for generating the voucher. A specific combination of VIN and constraint code is considered to define a specific product. A method for generating this code will be described later. Accordingly, the data held in the voucher issuer table 24 includes, for example, a fund account related to the voucher, the value of the minimum voucher and the value of the maximum voucher, and the start date on which the voucher can be redeemed. , Voucher duration, and brokerage fees associated with the sale and / or redemption of any voucher. The voucher must remain permanently on the alive voucher table in the database unless it has an expiration date. The duration is expressed in days, months, or years and is calculated from the voucher start date at the time of purchase. The method for organizing the fund account will be described in more detail later.

  A more detailed example of the types of constraints that can be set by a voucher issuer and associated with a cash voucher is now provided. As already explained, this constraint is usually set by the relevant members of the scheme when a cash voucher request is generated in layer 100 or layer 200. First, the constraints imposed on the purchase or exchange of money vouchers can be based on the store of the chain. Thus, cash vouchers can be purchased only at some retailers in a group and redeemable at all retailers in that group or only at some of the retailers that make up that group It is possible to impose restrictions on cash vouchers. The store that sells and the store that exchanges do not have to be the same.

Second, it is possible to limit the cash voucher to the purchase of a certain class of merchandise with or without the aforementioned restrictions.
Third, vouchers containing the constraints of the first two examples can be purchased or redeemed at a range of different retailers.

  As already mentioned, a voucher can be redeemed at any of several retailers, but is a separate link linked only to that retailer in the sense of serving the retailer. By being purchased from an organization, it can be a “generic” voucher. In any case, cash vouchers can have geographical constraints so that they can only be redeemed within a specific region that can be a town, city, county, or country. .

  At this point, the term “retailer” as used herein is not limited to retail stores, but actually includes any provider of money vouchers including government agencies such as DHSS, banks, and post offices. It is worth emphasizing that it is possible.

  Most retailers are more likely to take advantage of the flexibility to define and manage their own constraint codes (products), but VIN group operators are looking for retailers who need a relatively low level of constraint management. It is also possible to choose to provide this functionality. In this case, the VIN group operator sets and manages a constraint code using the constraint table described above.

  In order to generate the voucher issuer table 24, the member table 21 holds details of stores that can be used when purchasing or redeeming vouchers. In this context, a large retailer has a large number of channels or stores, so a voucher purchased at one store of a retailer must be valid for all stores belonging to that retailer. Please understand that there is no. Therefore, this feature is also under the control of the voucher issuer. The member table 21 holds a unique identification number for each member so that the voucher can be redeemed only by the identified number.

Table 25 is dedicated to scheme retailers and lists all the details regarding which retailers can sell or redeem cash vouchers.
Other than using the voucher issuer table 24, restrictions can be imposed on the use of money vouchers. This constraint is maintained in a separate constraint table 29 when managed by the core system.

  In addition to the main table described above, the main database 19 holds several auxiliary tables that will be briefly described below. First, the used number is held in the table 26 for security reasons. In addition, tables 27 and 28 hold statistical data related to voucher usage that can be used by management.

  It will be appreciated that the data stored on the database is very detailed with respect to all aspects of voucher usage, such as quantity, geographic distribution of sales and redemptions, media used, etc. Thus, members can easily extract their business profiles for use in adjusting their publicity and generating new products and useful management statistics. None of the current manual or semi-automated systems can achieve this.

  In addition, the main database may include a table that holds details of expired vouchers. Expired vouchers are moved to this table after the expiry date and after a user-defined period, and the structure of this table is the same as the table used for live cash vouchers. is there.

  Although this embodiment discloses a single database at a single location, it is of course possible that various regions and tables of the database are spread and distributed across different geographic locations.

Referring again to FIG. 1 of the drawings, it can be seen that the central core processor 1 is also subdivided into several functional areas.
The overall functionality of Core Processor 1 includes voucher purchase and voucher provision and processing, collective voucher allocation, notification of voucher number allocated to recipient, and voucher fund management. It is.

  Accordingly, the two communication lines 12 and 13 are associated with a functional area 32 that handles collective allocation of voucher numbers and a functional area 33 that handles non-emergency data such as management information about participants. These areas communicate via the interface section 15.

The other functional areas of the core processor 1 communicate with the functional layers 100, 200 and 300 via the interface section 16 in this embodiment.
These are functional areas 34, 35, and 36 that are respectively related to voucher purchase, voucher voucher exchange, and voucher issuer management.

Of the remaining functional areas of the processor 1, the most important are the area 37 that handles fund management, the area 38 that handles fee management, the area 39 that handles adjustment, and the area 40 that handles member management.
Having presented an overview of an embodiment of an electronic processing system, the hardware components that make up the core processor 1 and interface 2 will now be described by way of example only.

  Referring now to FIG. 3 of the accompanying drawings, there is shown hardware that can be used in the general purpose system shown in FIG. Further, it can be seen that the functional layer described in FIG. 1 is also present in FIG. 3, and the optional layer 300 is omitted. Tier 100 includes an electronic point-of-sale terminal, indicated at 40, that allows an assistant to enter details of cash vouchers purchased by a customer, while 41 Fig. 3 shows a processor located in an actual store where a voucher transaction takes place.

  Also shown in the layer 100 is a printer 43 for printing the issued cash voucher number. The printer can print a bar code representing the voucher number, and when the voucher is redeemed, it can also allow for faster reading of the voucher at a cash register with a bar code reader. is there.

  The retailer's central processing center is in the layer 200 shown in FIG. 4, where the central processor 1 is in the layer 400 along with the main database 19. The data volume and transaction rate of voucher operations are expected to require significant computer storage and processing power. The system also needs to have high availability, resiliency, and security. To meet all the above requirements, on the IBM mainframe using IBM's (RTM) Operating System (MVS), Database (DB2), and Access Control and Security Software (RACF), or on equivalent systems It is expected to operate a voucher system.

  Having provided an overview and description of the appropriate hardware, the operation of the system shown in FIG. 1 will now be described in more detail. The concept of money vouchers has already been described, and it should be understood that money vouchers are “virtual”, that is, they are completely different from paper vouchers in that they exist in the form of data. In short, cash vouchers exist only as computer records stored in a secure master database 19 in which any participating member, such as a boulevard retailer or a web-based retailer, Can be accessed internationally in real time. The computer record is identified by a unique code and includes details defining the location of the computer record and factors defining how the voucher can be redeemed, as already described. Accordingly, the value of each voucher is stored in a dedicated bank account only for funds associated with the voucher. Therefore, when the purchaser purchases a voucher using the functional layer 100, the purchaser is provided with a unique code. This unique code allows the system to determine the value, expiration date, and constraints as described in connection with the voucher issuer table of FIG. 2 or that are typically set by the VIN owner. Accordingly, the purchaser of the cash voucher is provided with data regarding the restrictions attached to the voucher including the expiration date at the time of sale.

  Therefore, the unique code associated with the purchased voucher is quite important. Therefore, it should not be possible for the owner of a valid voucher number to be able to guess another valid number based on experience and use that other number. For example, in the scenario presented only as an example, if voucher numbers with a single check digit are assigned sequentially, the buyer of vouchers with the numbers 896657, 86662, and 996670 will have 89668x Can reasonably be guessed that it is a valid number. Only a maximum of 10 trials are required to determine the x value.

Therefore, in this embodiment, the voucher number is a unique 19-digit number. This length has been chosen to fit the largest size currently used in the credit / debit card industry. That is, this length conforms to ISO8583. The first 6 digits make up the IIN (Identification Number) allocated to system operations.
The encoded number can be divided by the method shown in Table A.

Table A

  Thus, it can be seen that it is the positions 7-10 of the voucher number that allow the participating members of the system to set the constraints as previously described herein. This coded number of divisions can be varied. For example, in detail, the VIN constraint code need not be four digits, but can be, for example, three digits.

Furthermore, the generation of the voucher number involves an algorithm that ensures that the number is not repeated.
In this embodiment, the voucher number can be assigned using the following logic.

Get a random number.
Check that the number is not on the "unavailable" list. If it is on this list, increment the random number and try again. After a predetermined number of unsuccessful skips, another random number is obtained. After a predetermined number of unsuccessful random numbers, change the seed of the random number generator and try again. After a predetermined number of unsuccessful seed changes, give up the allocation attempt and fail the transaction. A failure at this point where the preferred maximum allocation has not been reached indicates that the choice of random number generator is not successful. Statistics about successful / unsuccessful attempts must be maintained, and this statistic must be reported regularly to inform management of possible problems.

Check if the number is already allocated to the required product. If so, retry as described above.
Issue a voucher if it is unlikely, but more than all possible numbers of “Absolute Maximum Live Allocation” or “Absolute Maximum Allocation” are already allocated to a particular product I can't.

The algorithm for checking the allocated number and issuing a warning is described in more detail below.
Given the voucher number structure described and the expected amount, the above situation, if any, will warn you for several years that the “preferred maximum allocation” limit has been reached, followed by the “absolute maximum allocation” level. It should only happen after a further warning that you are approaching. If action was taken, these warnings should give enough time to explore and suggest alternatives such as starting a different product number for the “same” product.

  An important feature implemented by this system is that messages about each retailer are confirmed in order by the receiving system as follows in order to reduce the likelihood of invalid or fraudulent transactions being introduced into the communications network: Sequence number (different order for each retailer category and for inbound and outbound messages).

  As a further preventive measure against fraudulent contacts, the system retains in the member table 21 data identifying, for example, a member's network address or telephone number, before the system accepts that the voucher is valid. In addition, both the member identification number and the contact source can be inspected.

  As already mentioned, an additional security feature of the system is that for each product, the number of vouchers that have not been redeemed (“live”) is monitored as a percentage of the total possible voucher and the value profile of the life voucher is Is to identify the most common values. Centralized monitoring allows the system operator to assess the risk that the voucher number, value, and expiration date will be inferred. This risk increases as the percentage of live vouchers increases, with a high percentage of vouchers having the same value. When the risk for a particular product rises to a predetermined threshold, a voucher issuer is alerted. If the second threshold is exceeded, a stronger alert is issued, for example, requesting that a new product be introduced. If the third threshold is exceeded, issuance of vouchers for that particular combination of VIN / constraint codes is stopped. In FIG. 18, the timer 99 starts step S80, which is the start of the periodic security check. Accordingly, at step 81, the processor checks the ratio of the number of surviving vouchers to the number of possible voucher numbers for a given VIN. In step S82, this ratio is determined from the profiles of all surviving vouchers that are the most common products. Step S83 calculates the ratio of the surviving number to the possible number of the most common product, and step S84 determines whether this ratio exceeds a first threshold. If the answer is “no”, nothing further is done until the test sequence is started again by a timer or by a management decision. On the other hand, if the answer to step S84 is “yes”, a first warning is issued in step S85. A second determination is made in step S86 as to whether the ratio calculated in step S83 exceeds a second threshold, and again, if the answer is no, further steps are , Not at all. However, if the answer is “yes”, a stronger warning is issued in step S87. Finally, step S88 determines whether the calculated ratio exceeds a third threshold, and if the answer to this is “yes”, then in step S89, that particular product's Issuance is stopped.

  Referring now to FIG. 4 of the accompanying drawings, there is shown a flow chart box, the basic procedure taken when a voucher is purchased. The point of purchase is assumed to be a boulevard retailer with a sales terminal 6, similar to retailer A in FIG. Thus, a voucher can be purchased with any other item at the store, or can be earned as a reward for the purchase amount just made by the customer.

  In FIG. 4, at step S1, the sales assistant at the sales terminal takes the details of the requested voucher, as well as the locally determined product constraints, as well as other confirmations, and issues the voucher to the local controller. Issue a request. In step S2, the local controller transmits the request to the retailer system in functional layer 200.

  In step S3, the retailer system determines the VIN / constraint code entering the request, encrypts the voucher request in an appropriate manner, and transmits the encrypted voucher request to the functional layer 400 for additional It has the main function of executing the verification procedure.

  In this embodiment, the retailer system uses the APACS standard 60 to issue a voucher purchase request. This is a standard that allows private use messages and defines various data elements, which are mandatory or conditional for each type of message. The APACS standard 60 is a standard used in the interbank communication system 11 in the functional layer 300 of FIG.

  It should be clearly understood that the use of the APACS standard 60 is not essential to the basic concept of the present invention. This is because the use of this standard is not essential to the practice of the present invention. For example, users in the United States can use different formats.

  The interbank communication system 11 is not shown in FIG. 4 or similar FIGS. 5, 6 and 7. This is because in implementing the present invention, the interbank communication system is used only as a secure conduit for messages that are already available.

  Thus, the encrypted message can be sent via the interbank communication system or directly to the section 16 of the interface 2.

  This interface has a form of verification that verifies that the request is in the correct format and from a known source. In step S4, the encrypted voucher request is received by the interface 2 and forwarded for purchase request verification in step S5. The purchase request verification procedure includes checking that the four-digit VIN / constraint code supplied by the retailer is for a valid voucher scheme. In addition, other criteria for the requested voucher must also conform to the attributes for that particular VIN. In step S6, if no error is detected in the verification procedure, a voucher number is assigned to each voucher request. This allocation of the voucher number results in a resulting update to the already explained funding table, this update being performed in step S7. In step S8, information about the voucher is passed to a management system (not shown) for calculating the fee charged by the system operator, and in step S9 a response message is returned to section 16 of the communication interface 2. It is.

  The calculation of the management fee is secondary to the concept of the present invention and can be performed for each voucher, that is, at the time of purchase, and in some cases at the time of redemption. On the other hand, the management fee can be calculated at a predetermined interval with respect to the collective value of vouchers purchased or redeemed.

  If the voucher request is not validated during the processing described above, the response is also negative in the APACS standard 60 format. In any case, the communication interface informs the retailer system of the result, and the retailer system informs the local controller of the original terminal. In this example, the terminal issues a printed voucher with an assigned voucher number. At this point, the printer can add a barcode to the value identifying the unique voucher number.

  Retailers have the option to print information when issuing vouchers. This information may be just a voucher number on paper printed on its own choice or on its own choice, for example as it is, a branded card, or a gift card, or value, expiration date, and others Can be additional descriptive information such as any use conditions. This number can be printed as a bar code to help retailers that accept redemption process the voucher quickly and manage the product constraints identified by that number.

It will be appreciated that the above description is presented from the point of view of a customer at an attendant terminal.
As shown in Figure 1 of the accompanying drawings, this is not the only possible scenario. The functional layer 100 of FIG. 1 includes the possibility of purchasing a cash voucher via the Internet. In this case, the retailer system must issue a voucher request to the transmission function layer 400 after verifying the customer details provided via the Internet. This is the procedure shown in the flowchart of FIG.

  Next, referring to FIG. 5, the purchaser issues a voucher purchase request using a PC in this embodiment. Of course, other access methods on the Internet can also be used, such as a cellular phone with appropriate functionality, or a direct television link. In steps S11 and S12, the purchaser connects to the Internet using his ISP and uses the retailer's ISP to access the retailer's website in step S13. Next, the purchaser completes the purchase form on the retailer's Web site for the selected voucher issuer. For verification purposes, the minimum information provided by the purchaser is the requested voucher type, voucher amount, and debit / credit card details for payment. Additional information may be requested and provided at the customer's option to provide additional customer service and / or marketing information. The request path is therefore identical to that of FIG. 5, and therefore the steps are given the same reference numerals and will not be described again. As in the previous figure, the interbank communication system can be used as a secure path. Again, as in the previous figure, the communication interface returns an appropriate message, but in this case the message is returned to the retailer ISP in return. In return step S13, the retailer's ISP informs the buyer's ISP of the result of the voucher purchase request, and if the request is successful, the voucher number with value and expiration date is given to the purchaser. .

  FIG. 6 of the accompanying drawings returns to the scenario of retailer A attendant terminal 7 handling redemption ticket exchange. The data flow in this figure is very similar to that of FIGS.

  Accordingly, in step S21, the customer presents the voucher number, the value of the voucher, and the voucher expiration date to the sales assistant. It is not essential for the customer to provide the actual voucher printed in step S10 of FIG. It will also be appreciated that providing an expiration date is only an additional security feature that is not essential to the inventive concept. The voucher is intended for partial payment of the goods, the balance of the payment being made by money, check / debit card, or for the full payment of the goods to be purchased. In fact, a new voucher can be given as a difference to a purchaser who has a voucher worth more than the goods needed. Of course, this may not be possible if the particular store where the voucher is redeemed is not the voucher seller at the same time. This feature is not available at all in other voucher schemes. In response to the voucher number and expiration date, in step S22, the sales assistant (local controller) informs the retailer system of the purchase request. The retailer assistant and tier 200 typically must perform a verification procedure on the request. This is because, as already mentioned with respect to voucher generation, vouchers may contain details of voucher restrictions set by voucher issuers or their retailers.

  If validation is deemed necessary when it is validated, the retailer system initiates a payment request and, in this embodiment, constructs an MTIxxxx purchase request. This request is transmitted to the communication interface of the layer 400 in step S24, and verification is performed in step S25. In response to a valid request, the voucher table 20 of the main database 19 is updated in step S26, and the fund ledger 22 is updated in step 27. In step S28, the fee information is transferred to the fee generation system so that the fee to be paid to the system operator can be calculated. The same fee reward applies as described with respect to FIG. Finally, in step S29, a response message is generated in the same format as before and sent to the retailer system via the communication interface. This response message can of course be negative as the original request was invalid. Examples of reject messages are “Invalid Number”, “Scheme Invalid for This Retailer”, “Wrong Value”, “Voucher Expired”, “Voucher Already Redeemed”, and “Transmission Error” It is possible that In reverse step 23, the response is transmitted to the local controller, which passes the response to the assistant at the sales POS terminal, which takes the appropriate action at the terminal.

  FIG. 7 of the accompanying drawings shows redemption corresponding to the procedure of FIG. 6 performed via the Internet. Accordingly, in steps S31, S32, and S33, the redeemer accesses the retailer's ISP with a redemption request for use, for example, for payment for goods purchased via the Internet. The retailer ISP passes the request for the communication interface of layer 400 as shown in FIG. The following steps are identical to those described with respect to FIG. 6 and are therefore given the same reference numerals and will not be further described.

  Since the purchase and exchange of vouchers involves the transfer of funds to / from a dedicated bank account, the manner in which funds are structured and managed will now be described. As already explained, each voucher belongs to a specific voucher issuer that also identifies which fund account manages the voucher funds. It will be appreciated that a single fund account can also hold funds for different products. Each fund, in this embodiment, has a “shadow bank account” associated with a designated physical bank account held at a financial institution.

FIG. 8 of the accompanying drawings shows the overall structure of the ledger for different retailers and different products.
In FIG. 8, a set of individual vouchers is shown at 60, 61, 62, and 63. Each of the vouchers has a value, a unique number, and a product definition, which are shown as A1, A2, A3, and B6. Vouchers 60, 61, and 62 are all issued for retailers ABC stores, A1 is equivalent to vouchers that can be redeemed for white goods, and A2 is redeemed for food items A3 corresponds to a voucher that can be redeemed for a record at a participating branch in an ABC store. The voucher 63 is issued for an XYZ store, and in some cases, issued as a reward for patronage.

Each product definition is shown at 64, 65, 66, and 67 in FIG. 8, and as can be seen, the ABC store has two separate funds, one for product A1 and A2 and the other for product A3. While having accounts 68 and 69, retailer XYZ has only one fund account 70.
The above fund accounts track accounts 71 and 72 in bank A and account 73 in bank B.

The core system in this embodiment manages seven accounts for funds. This is as follows.
1) Funding bank There is one such account for each VIN. This account tracks a physical external account (usually a bank account) that holds the actual funds that endorse an existing voucher. The balance of this account is adjusted to match the balance in the physical bank account. This is an external adjustment. This represents the portion of funds that have already been transferred to the actual fund bank account. The total value of this fund is the sum of three fund accounts, fund bank, fund sales unsettled, and fund transfer unsettled.
2) Funds sales not yet settled Again, there is one account for each VIN. The balance of this account is an amount waiting for the transfer from the actual bank account to the general bank account in the functional layer 500. The transfer is performed via interbank transfer, for example, BACS.

3) Funds not yet settled Again, there is one of these accounts for each VIN, which is similar to Funds not yet settled, but only for the purpose of exchange.
4) Funds canceled and not yet settled There is still one for each VIN. The balance of this account is the amount waiting for the transfer from the general bank account of the system operator to the general bank account of the VIN owner. This transfer is performed between banks, for example, via BASC. This account is the equivalent of an unsettled account at a retailer exchange regarding expired vouchers, unclaimed vouchers, canceled vouchers, and the like. This account is used to return the funds to VIN ownership.

5) Retailer sales not settled One account exists for each retailer. This account balance is the amount waiting to be transferred from the retailer bank account to the general bank account on the system operator's functional layer 500 and is usually sold by the retailer the same day, regardless of VIN. Represents the value of all vouchers issued. This transfer is performed via interbank transfer, for example, BACS.
6) Retailer exchange unsettled Again, there is one for each retailer, similar to a retailer unsettled account.
7) There is one such account for the entire money control system. Match account for retailer transfers. The balance of this account is the total amount of all the funding bank accounts (opposite sign).

  The actual structure of the various accounts of the members using the system, system operator, and actual bank are shown in FIG. 16 along with the appropriate functional layers. Take the voucher (at 90) sold by retailer ABC as an example. Accordingly, in step A, the unsettled account of the core system is updated when the voucher is sold. At this point, no funds are transferred. Step B shows an end-of-day transfer related to retailer sales. The balance of each retailer sales unsettled account is transferred to the overall cash management account. An instruction is given to transfer the amount from the retailer bank account to the system operator bank account via the interbank clearing system. Finally, Step C shows the end-of-day transfer related to the redemption of the voucher. The balance of each fund sales unsettled account is transferred to the fund bank account. An instruction is given to transfer the amount from the system operator bank account to the funding bank account via the interbank clearing system.

The next four examples show how the actual money associated with a voucher can move through the banking system described above.
Four examples are shown in FIGS. 9, 10, 11, and 12. FIG. In the table of FIG. 9, a customer purchases a 5 × 10 pound voucher from ABC bookstore, and the customer deposits in Lloyds and gives the voucher to his bag as a present. The book coupon scheme is VIN34 and is operated by Big Books. The bank account holding the funds for this VIN is held at Barclays Bank, but only the system operator has the authority to withdraw money. The system operator maintains a general account with an RBS that is the client debit credit used. In this example of £ 50, the retailer starts selling tickets and ends with £ 40 in the bank account of the retailer who accepted the voucher instead of money and £ 10 in the funding bank account. During the period between issuance and redemption, the entire £ 50 amount is in the funding bank account. This is an example of a general exchange ticket.

  The example of FIG. 10 is an example of a voucher for an independent retailer. The ABC store operates a voucher scheme for its store so that the voucher can only be purchased and redeemed from the ABC store at a physical store or via the Internet. A customer purchases a 5 × 10 pound voucher from an ABC store and gives the voucher to his bag as a gift, and the bag uses 40 pounds to purchase an item from the ABC store. Hold their own voucher funds, but in separate accounts under the control of the core system.

  The third example, the example of the table 11, is an example of a patronage scheme operated by an ABC store. This scheme rewards customers with vouchers that can be redeemed either physically at their store or via the Internet. The total allocation on a specific issue date is £ 500. A customer purchases an item using a £ 40 voucher. The ABC store maintains a separate bank account under the control of the system operator, including funds that endorse the value of the issued voucher.

The example of FIG. 12 shows the contents to be performed when the voucher is not redeemed before the expiration date.
Having described the overall functionality and structure of the processing system real-time function of the central processor 1, it will now be described in connection with using the system with an interbank communication system. This is because it is a likely scenario. Thus, in this embodiment, voucher purchases are always triggered by an MTIxxxx request message received at interface 2. In response to this message, the central processor 1 always generates an MTIxxxx response message that returns to the source of the message. Under normal circumstances, the response message includes a voucher number, but if any errors are encountered during processing, the response is a rejection of the purchase request.

Accordingly, in response to the voucher purchase request, the central processor 1 has the following functionality. Because of security concerns, it is emphasized that all activities in the processor 1 must go through the interfaces 2 and 17.
This procedure is shown in the flowchart of FIG.

  At step S100, an MTIxxx voucher purchase request message is sent to the central processor 1, and this message is received at interface 2, section 16 at step S101, sent for verification at step S102, and at step S103. Sent for error handling. If the two steps of steps S102 and S103 determine that the purchase request is invalid, an MTIxxxx to that effect is returned to the interbank communication system 11 and also in the audit section of the database MTIxxxx indicated at 50. Sent. If it is determined in steps S101 and S102 that the purchase request is valid, the purchase request is passed to step S104. At this point in the flow diagram, several linked processes take place, and purchases (and voucher redemptions) can always be made in real time to minimize delays during purchases and vouchers. Understood. Therefore, in step S105, the voucher number is generated by the method already described, and in step S106, the newly generated voucher is already described in relation to the main database table shown in FIG. In this figure, it is transferred into an appropriate life voucher area of the voucher table 20 indicated by 51 and 52. Similarly, the successful generation of the voucher is audited in step S108, and the result of this process is again stored in the main database audit table, indicated by 50. Another result of successful creation of the voucher is shown in step 109, which requires data from the charge structure table 53 in the main database, and charge transactions in the main database. It is a charge processing step for updating the table 54. Further, in step S110, the creation of the voucher sets up equivalent funds in the main database fund account transaction table and sets up the appropriate data in the main database membership table. As required, the central processor 1 processes the funds. The fund account transaction table and membership table are shown at 55 and 56, respectively.

Finally, a voucher response including the voucher and product details is transmitted to the interbank communication system 11 in step S111.
FIG. 13 of the accompanying drawings is a flowchart of processing performed in the central processor 1 when the voucher is redeemed. As will be described later, the management fee processing is actually performed by batch processing after the transaction is logged.

  This figure is very similar to that of FIG. 12, as would be expected. Accordingly, the same reference numbers are given to the steps related to the exchange of the voucher and the data table. However, in step S101, a redemption request is received, step S104 relates to the redemption process, and in step S105, the step refers to verification of the voucher number rather than the generation of the voucher number.

Further, in step S106 where the voucher is processed so that the value can be redeemed, an entry for giving voucher information to the history data table of the main database is made.
An important feature is that the funding account providing the endorsement of the life voucher is always equal to the total amount represented by the life voucher.

  Thus, the system described above has a consistency check-adjustment process that can be triggered automatically at a given time or can be manually requested at any time. The reconciliation process involves checking that the total value of the surviving voucher associated with the fund matches the balance in its fund ledger.

  The process is shown in the flowchart of FIG. Accordingly, this process is initiated by the user or timer in step S50, and in step S51, the funds balance is adjusted using data from the fund account table 22 and the fund account transaction table 23 of the main database 19. Is called. In step S52, the voucher balance adjustment is performed using the details of the life voucher stored in the life voucher table 20 of the main database. Finally, a user alert or user report is sent in step S53.

  FIG. 16 illustrates the relationship between the retail world of functional layers 100 and 200, the core system of layer 400, and the actual bank account shown in functional layer 500. At 90, it is assumed that the cash voucher is sold by retailer ABC. As a result of the sales, the tables 22 and 23 of the main database 19 are updated, and an encoded number is generated, and an appropriate entry is made in the voucher ticket table 20. As will become apparent, at this point no physical transfer of funds is necessary. Accordingly, in step A, the unsettled account of the core system is updated when the voucher is sold. There is no physical transfer of funds. Step B shows the end-of-day transfer, ie retailer sales. The balance of each retailer sales unsettled account is transferred to the overall cash management account. Through the interbank clearing system, an instruction is given to transfer the amount from the retailer's bank account to the system operator's bank account. Step C shows the transfer at the end of the day, i.e. the fund sales. The balance of each fund sales unsettled account is transferred to the fund bank account. Through the interbank clearing system, an order is given to transfer the amount from the system operator bank account to the bank account of the funds.

  The table of FIG. 17 shows how transactions are posted for various funds. In FIG. 17, the direction of the transfer is determined by the balance transfer code, and -VE is the system operator's sign. It means entering a general account, that is, transferring funds from a retailer account or VIN account, and + VE means transferring from a general account of the system operator to a retailer account or VIN account.

Now that we have provided a description of the general system and how it works, some basic features will become apparent.
Specifically, when a purchaser obtains a cash voucher using any of the procedures described above, the funds provided by the purchaser are transferred to a fund account in the system. This is done only in the form of a balance representing the exchange value. The vouchers are not listed individually, but simply in a fund account that is totally equal to the redemption value of all alive (non-redeemed) vouchers associated with that particular fund by the product table. The amount to be held.

  Similarly, each voucher exists completely independently of the voucher purchaser. Thus, the voucher can be easily transferred to another individual. In particular, vouchers can be transferred very easily via the Internet or verbally via telephone, since the recipient does not need to be linked in any way to the overall system. it can.

  Another feature of the system described above is that both voucher purchases and redemptions already exist at the retailer's location or make minimal changes to the regular terminals used for Internet transactions. It is possible to do without. In addition, an individual presenting a voucher for redemption over the Internet can purchase the item without having to supply credit / debit card details.

  In addition to the simplicity of operation and the specific advantages of using existing equipment such as an interbank communication system, the system described in detail above requires the amount of processing and data to be performed. It offers a considerable technical advantage with respect to the need to allocate a considerable amount of memory for storage. The described system has applications in many areas where money transfers must be made and, if successful, the number of transactions handled by the system is very large. Therefore, the feature that the voucher is not allocated to an individual and the funds that support an existing voucher are not subdivided to reflect the value of the individual voucher results in a reduction in the amount of processing to be performed, It also results in reduced memory space usage.

  In addition, the system described above has a high level of security because a cash voucher cannot be used unless funds are committed by request. Thus, the voucher cannot be redeemed unless funding is committed to the system operator. Further, in the method in which the encoded voucher number includes a constraint that defines the number as a product, a table holding a voucher that has not been redeemed is tracked in the fund ledger table 22 of FIG. Means indirectly representing a precisely defined monetary value with a corresponding monetary balance in the actual bank account. Therefore, any change that increases or decreases the number of surviving vouchers in the voucher table 20 must be reflected in the cash register table 22 and in the actual bank account.

Claims (6)

An electronic processor system that generates an encoded number representing money,
An electronic processor, the electronic processor comprising:
A processor interface unit , the processor interface unit comprising :
Receiving a request to generate an encoded number from a known membership configuration, wherein the request defines a desired monetary value that can be redeemed at a remote terminal by an individual;
Sending the encoded number generated in response to the received request to the remote terminal;
Receiving a redemption request for a previously generated encoded number from the known member configuration;
A processor interface unit operable to send a message indicating that the received redemption request is valid;
A verification processor unit operable to verify a received request for generating an encoded number and to verify a received request for redemption of a previously generated encoded number; ,
A number generation processor unit operable to generate an encoded number, the encoded number comprising a first part digit identifying the desired monetary value and the known member's A random multi-digit identification number including a second part digit identifying the configuration, wherein the encoded number identifies the individual for which the encoded number was generated for the individual Is not intended to identify other individuals, and the electronic processor system further includes
A database unit operable to provide a database , the database unit comprising:
A first table storing the generated encoded numbers;
A fund table storing the total amount of all encoded numbers that have not been redeemed ;
Storing a second table that stores the number which is the encoded if the redemption request is received is verified,
The electronic processor
If (a) the encoded number of redemption request is received is verified, the total amount of redeemable said monetary value in said resource gold table, only monetary value identified by the encoded number reduced Let
(B) If the number that is one encoded is generated, in monetary value the number of coded newly generated, so as to increase the total redeemable said monetary value in said resource gold table And
Thereby, the generation of one encoded number cannot result in more than one increase in the total of the redeemable monetary values in the fund table, and one encoded number redemption An electronic processor system that is operable such that no more than one reduction can be made in the total amount of money that can be redeemed in the funds table .
The electronic processor system of claim 1, wherein the database maintains a voucher table that includes details of all generated encoded numbers that have not been redeemed.
3. The electronic processor system according to claim 2, wherein the database includes, for each member, a fund ledger table storing all generated encoded number balances related to the member that have not been redeemed. And each fund register table is being transferred to or from the bank account or transferred to or from the bank account so that the total balance in the fund register table represents a monetary value that has not been redeemed A system that keeps track of money being spent.
The electronic processor system of claim 1, wherein the number generation processor unit is adapted to generate an encoded number and incorporate constraints imposed on the use of the generated monetary value, A system in which constraints are represented as a series of digits that form part of the encoded number.
A method of processing financial transactions utilizing an electronic processor system including an electronic processor and a database, comprising:
Receiving at the electronic processor system a request from a member to generate an encoded number representative of a desired monetary value purchased at a remote terminal;
Using the validation section of the electronic processor to determine if the request is valid;
Using the electronic processor to generate a number encoded in response to a valid request verified by the verification section;
Transmitting the generated number from the electronic processor system to the remote terminal;
Receiving at the electronic processor system a request to be able to redeem a previously allocated number;
In response to the verification section finding that the number is valid, transmitting a message from the electronic processor system to the remote terminal indicating that the received redemption request is valid;
Storing each number generated in response to a valid request in a first table of the database;
Storing the total monetary value represented by the issued encoded number not redeemed in the fund table of the database;
Transferring the encoded number that the redemption was deemed valid by the verification section to a second table of the database;
The electronic processor is used to reduce the total monetary value in the fund table of the database by the value represented by each encoded number of redemption requests deemed valid. minute to a few which are all coded is issued, it is not possible to bring more increased than once total of the monetary value represented in said resource gold table were all coded redeemed Allowing a number to cause a one- time reduction in the total amount of the stored monetary value .
  5. The electronic processor system according to claim 1, further comprising a printer, the printer being operable to print at least a portion of the encoded number as a barcode. Electronic processor system.

Images