JP2007537524A - Improved ticketing system - Google Patents

Abstract

  In the ITSO scheme, the construction and initial stamping of the ITSO product entity (IPE) is one of a number of ITSO Secure Application Modules (“ISAMs”) that are remote from the ticket retailer device where the IPE field is generated. Done by one. Each ticket retailer device can communicate via the Internet or other network by a control means operable to select one available ISAM from the ISAM array for the duration of the imprint transaction initiated by that ticket retailer device. Connected to the ISAM. IPE validation can also be performed on a remote ISAM array accessed via the Internet or other network. Remote ISAM arrays can be used in a variety of ITSO applications, such as, for example, transportation ticket sales and secure systems for drug prescriptions. In the latter scheme, prescription information is presented by a prescriber to stamp in the form of an IPE, and the patient can later validate the prescription IPE at a pharmacy or other supplier. Such a scheme can be used to significantly reduce prescription fraud for security inherent in the ITSO scheme.

Description

  The present invention relates to an improved ticket issuing system using the basic structure of the ITSO system. For the purposes of this document, the term “ITSO” shall mean any version of the Interoperable Ticketing Smart Organization standard developed by the British government and incorporated into the European standard EN 1545, which is now available or will be available in the future. . As can be seen from the following description, the term “ticketing method” not only includes the traditional ticketing operations of transportation, but also for tickets, tokens, coupons, prescriptions for reimbursement for the provision of goods or services. Including any safe method that is validated.

  The existing ITSO-style security architecture allows any point-of-service terminal (“POST”) to use any ticketing ticket, whether it is ticket sales or ticket validation. Rely on including ITSO Secure Application Module ("ISAM"). In the case of ticket franking, the scheme security function performed by the ISAM is very short so as not to delay the service when getting on a bus or passing through a turnstile. Obviously it must be completed in time.

  As a result, in existing schemes, the ISAM must be physically installed in POST so that transactions can be performed "offline" on any central host computer. Otherwise, especially on traveling vehicles such as buses, it is very slow and expensive to communicate.

  However, in the specific case of ticket purchases, this “fast and therefore offline” argument is not valid and ticket selection and ticket purchase events take seconds or even minutes to complete I know there is a possibility. In addition, upgrading all existing ticket retail POSTs by installing ISAM has a negative cost impact, so an alternative approach is needed to provide ITSO ticket retail more economically.

(Summary of Invention)
Broadly speaking, in the ITSO scheme provided by the present invention, the ITSO Product Entities (IPE) imprint or validation is performed by multiple ITSOs at locations remote from the ticket retailer device from which the IPE field is obtained. Performed by one of the Secure Application Modules ("ISAMs"), each ticket retailer device can receive from multiple ISAMs for the duration of a stamp transaction or validation transaction initiated by that ticket retailer device. Connected to one or more ISAMs via the Internet or other network by control means operable to select available ISAMs.

  The IPE “seal” is, in a sense, providing an authentication code known as a MAC (Message Authentication Code). This can be done by using any of several known algorithms, such as the DES algorithm. In essence, the IPE has a signature created and stored by the IPE so that it can be validated later by checking the signature or authentication code.

  IPE validation is the process of checking a previously generated authorization code that was created when an IPE was stamped. Validation is also known as authentication and is performed at the ISAM away from the retailer equipment. In the described embodiment of the invention, the process of impressing the IPE is performed at an ISM remote from the retailer device. Further, the process of authenticating or validating IPE is also performed at the ISAM remote from the retailer equipment.

  Such a scheme, as mentioned above, is particularly suitable for the sale of transportation tickets, but the time taken to stamp or validate tokens, coupons or other “tickets” is not critical. It is also suitable for other systems. In particular, the above scheme may be used to validate a pharmaceutical or pharmaceutical prescription. The present invention further provides a method for issuing drug prescriptions, and the prescription information is in the form of an ITSO product entity ("IPE") stamped in accordance with the method of the present invention outlined above, or a prescription entry by a doctor or other Sent by the person. Similarly, in accordance with the present invention, a drug prescription presents prescription information in the form of an ITSO product entity (“IPE”) to the validation device, and the validity that the IPE is presented for validation. The validation is performed by validating the information in one of a plurality of ITSO Secure Application Modules (“ISAM”) that is remote from the testing device (such as POST), and each validation device is Connected to the ISAM via the Internet or other network by control means operable to select an available ISAM from the array for the duration of the validation transaction initiated by the validation device.

  The present invention also provides an ISAM array for use in the type outlined above, which is transmitted from a remote retailer device or validation device to the control means over the Internet or other network. A plurality of ISAMs and control means corresponding to the retailer or validation request to be made, the control means selecting an available ISAM from the plurality of ISAMs and selecting it as a retailer device or validation During the period of a stamp transaction or validation transaction initiated by the device, it is operable to connect to that retailer device or validation device via the Internet or other network.

  An ISAM “array” is a logical grouping of multiple ISAMs. This allows multiple requests for IPE stamping or authentication to be sent and processed in parallel at any time. The control means can determine an ISAM suitable for any given stamp or authentication request. Further, the ISAMs may be arranged in logical groups within the array such that a particular group of ISAMs is provided, for example, for any one source of stamping or validation requests. In one embodiment of the present invention, the source can be a particular retailer or operator, so the request of that given retailer or operator is provided to a corresponding one of the groups of ISAMs in the array. Is done. Next, a POST system distributed over the Internet according to the present invention will be described as an example with reference to the drawings.

  ITSO schemes contain data related to transactions and operate using ITSO Product Entities (IPE) that are stamped, validated, or authenticated using the algorithms described above. The ITSO product entity itself (IPE) includes multiple IPE fields that both contain one IPE. The process of assembling multiple IPE fields into one IPE is known as construction. In the embodiments described above, the construction of the IPE may be done at the retailer device (POST) where the validation request is made, or the retailer device simply changes the IPE field from the IPE field to the IPE. It may only be provided to the remote third party site being built. Whichever route is selected, the IPE is stamped with an ISAM remote from the retailer device. In addition, any request for authentication or validation of an IPE that has already been stamped can be made to a remote ISAM device. The IPE field is also known as a component.

  As can be seen from FIG. 1, a system embodying the present invention includes two Web servers. One of these (“SAM Array Website” or ISAS) comes with an ISAM “array” and is via the Internet by ticket retailers that provide ticket selection functionality to ticket buyer clients. Connected to the other, including an operated third party website (“third party website”).

  An ISAM array can have any number of ISAMs. In this case, it is assumed that there are X such ISAMs in the array. Similarly, there may be any number of third party websites on the other server (actually any number of third party servers each hosting any number of third party websites). Can be). In this case, it is assumed that there are Y such websites. Each ticket retail website may then be accessible from a number of Z devices that can be accessed therefrom by those who wish to purchase tickets.

  The ISAM array and its management layer route X ISAMs to Y third-party websites, and then route Z terminals (“customer media interface devices”) per session. Work like a telephone exchange. Thus, X * Y * Z connections are conceivable, whereby one array of ISAM can be shared across multiple third party Web ticket resale websites and by more terminals.

  The combination of the logical and physical components in the form of the hub and IPE handler shown in FIG. 1 provides a control means, thereby enabling IPE validation or stamping requests within the SAM array. Can be assigned to any appropriate SAM or group of SAMs.

  The flow of events based on the ITSO scheme implemented as outlined above in connection with FIG. 1 is shown in more detail in FIGS. As can be seen from FIG. 2, the customer logs in to the third party website in the usual way, and the customer and the third party website in the usual way until payment is made and the ticket details are set up. Ticket purchase transactions are processed between. At this point, the third party website contacts the ITSO Sam array website (“ISAS”) to establish a session. The IAS establishes a session and sends the session identification back to the third party website and the customer. Using the ticket details already set up by the third party Web site, the ISAS (“Customer Media Interface”) initiates the customer interaction and continues until the ticket sales transaction is completed.

  In this embodiment, the IPE field is generated at a third party website and sent to the ISAS where the IPE is built. The ISAS then sends an IPE to the ISAM for stamping. As mentioned above, it is also possible to allow an IPE to be built entirely on a retailer device or a third party website. An additional feature of the embodiment (inherited from the ITSO method) is that any pad between fields is removed to ensure that the IPE build is small for subsequent storage on the user's smart card (customer media device). As can be seen, the fields in which the IPE is built are grouped together in an efficient manner.

  As described, the IPE generation may be built entirely with POST, the IPE field may be created with POST, sent to a third party site, or built with IPE fields. May be created at a third party site and sent to the ISAS for construction. In any of these alternatives, IPE is obtained from POST or retailer equipment, in the sense that upon entry of data at POST, the IPE is built either at the POST itself, a third party site, or an ISAS. .

  FIG. 3 illustrates in more detail this process, particularly the communication between the ISAS and the individual ISAM used in a particular transaction session.

  The details of the ITSO transaction executed by the ISAM may all be conventional within the ITSO system.

The advantages of the above approach are as follows:
There is no need to install one ISAM per POST. Third party websites are dynamically associated with the ISAM array. Dynamic association with Internet client ticket retail websites.

  ITSO Product Entity (“IPE”) if a smart card reader device is attached to the third party website and thus the client terminal (“Customer Media Interface” or “CMI”) used to access the ISAS. ITSO formatted and protected “tickets” can be remotely loaded into CMDs (“customer media devices”) using the highest level of security that a particular type of CMD can support . Also, if the CMD is a dual interface (ISO 7816-3 and ISO 14443), the reader device need not be an ISO 14443 reader, which is advantageous. This is because the ISO 14443 reader is more expensive.

Techniques based on arrays of smart cards accessed over a network have been previously implemented, but these are limited to "pass by value" protocols between smart cards acting as logical peers, such as Mondex Parse It was only for applications. The scheme of the present invention described above is a secure end-to-end dynamically configurable over the Internet between ISAM and many different types of CMDs based on the level and type of security that CMD can support. Provide end protocol. The security protocol may include:
Access password derived from card ID for each memory sector. These passwords are transferred “in a clear state” but are obtained by issuing a CMD and can only be used by one particular CMD.
Mutual authentication based on a shared secret key (derived from card ID). This provides a high level of assurance that the CMD is authentic, and the CMD can only be updated after successful mutual authentication.
Secure messaging based on a shared secret key (derived from session and card ID). As a result, the data read / written from the CMD is “stamped” with a one-time session-based ciphertext, so it can be changed “during transmission” or played back later It is not possible. This is in addition to security that protects the content of the IPE itself.

  As described above, the system described above is suitable for various situations other than the issuance of transportation tickets, which is an application for which the ITSO method was originally developed. One of the specific subjects is that of a prescription fraud.

  Prescription fraud is done in many ways. Paper-based systems currently in use around the world are susceptible to abuse by scammers acting as medical professionals, patients, pharmacies, and the like. Smart cards have been considered for some time as a platform to help fight these scams. Also, ongoing development of patient smart card ID methods is conventionally considered to go in the right direction. However, whether multiple commercial entities are public sector organizations such as pharmacies, medical practitioners, or, more importantly, governments, how can a fully flexible approach take commercial entities into account? There is no exact description of whether it is involved in subsidies for prescription fees or subtypes. This is mainly because managing the commercial and security transitions of these schemes is rather complex.

  The ITSO security architecture is an open scheme for safe dispensing, fulfillment, payment, and reimbursement of drug prescriptions ("Open" is partly due to multiple competitors) It can be used (for example, Visa is an open system).

  Referring to the standard ITSO specification, it is described that the following changes and enhancements are required to apply the ITSO method to the prescription fraud prevention field.

  First, the card held by the patient also needs to be a secure ID card. The ID card must be issued to the patient using a registration procedure that can fully authenticate the patient's identity and is sufficiently secure to give the operator full confidence that no double registration will occur. . There are a variety of known cryptographic and security protocol techniques that can be used and are not themselves the subject of this application.

  For example, a doctor who writes a prescription or other prescription specialist (such as a senior nurse who has permission to update the prescription repeatedly for chronic symptoms), fill in a prescription, pay all, part, Other “role holders” in this scheme, such as pharmacists receiving directly or as a subsidy, must also authenticate their identity through the use of smart cards.

  The patient card has a secure data construction called ITSO shell in the ITSO specification. In essence, it is an electronic wallet of many different types of tickets. These ticket types have templates for data items with definitions preset in each ticket or IPE ("ITSO Product Entity"). There is also an IPE type known as private, in which no data items are defined, and only ITSO security is used to “stamp” ticket data, thus ensuring its integrity Guarantee.

  The above-described system shown in the figure, using an array of remote ISAMs, provides a practical way in which secure prescription issuance and filling can be performed. First, the system avoids the need for ISAMs to be attached to all POSTs, in this case, doctors' clinics and pharmacies. Further, the present invention provides a means by which an electronic ticket representing prescription information can be safely and remotely downloaded via a network such as the Internet or an intranet (private network) version. The system keeps the ticket, in this case the prescription issuance process, secure by placing a security providing element (ISAM) in a controlled location. However, the ISAM can also be placed in other locations, such as a doctor's clinic or pharmacy.

  Using this process, tickets are selected online via the Internet, paid for, and delivered to the service user's card. The architecture is based on two web sites. The first is primarily responsible for selection and payment, and the second is responsible for secure delivery. If the ticket is actually a prescription, the online process can be modified as follows:

  Here, in the context of the prescription issuing system, it is possible to understand the two stages in which the IPE is imprinted and the IPE is validated. In a first embodiment, the doctor causes the IPE to be built by building at the POST in the doctor's clinic or by sending the IPE field to a third party site where the IPE is built. The IPE contains prescription data, which is stamped with the SAM. In this process, since the patient's card is also in POST, the IPE imprint is related to the patient's smart card. The patient then presents the smart card, and the imprinted IPE can be validated based on the patient's smart card at a different POST in the pharmacy.

  The doctor authenticates at the prescription management website and “writes” the patient's prescription. The doctor's card is involved in this process. The patient's card may be present at the same time or can be logged in later to “receive” the prescription. The patient then authenticates at the prescription management website and then initiates a prescription download using the same process described above.

  When the patient presents the card at the pharmacy, the pharmacy terminal may have an ISAM or may be connected online to an ISAM array server via an intranet, and the ISAM array server Are validated and changed / frank accordingly (depending on whether the prescription is only one time or repeated). The ISAM will then be involved in the creation of a secure transaction record, which will be followed by payment and reimbursement procedures in accordance with all commercial agreements and policies that apply to the specific individual involved. Uploaded to get started.

  Assuming the terminal is attached to three card readers (one for the doctor, one for the patient, and one for the ISAM), the prescription is issued “offline” at the doctor's terminal Note that you can also. The ISAM also sometimes receives inquiries about its prescription issuance transaction record that provides a well-described method compared to pharmacist transaction records. This “closed loop” approach provides the same kind of benefits as in the field of transportation tickets, in that it reduces inconsistencies and many types of fraud.

It is a block diagram which shows the outline | summary of a system architecture. It is a figure which shows the outline | summary of the flow of an event. It is a figure which shows the flow of an event in detail. It is a figure which shows the flow of an event in detail.

Claims (16)

ITSO product entity (IPE) stamping is an ITSO scheme performed by one of a plurality of ITSO Secure Application Modules ("ISAMs") at a location remote from the ticket retailer device from which the IPE is obtained,
Each ticket retailer device is connected to the Internet or other network by a control means operable to select an available ISAM from the plurality of ISAMs for the duration of a seal transaction initiated by that ticket retailer device. ITSO system connected to ISAM via the Internet. It is a method of impressing IPE in the ITSO method,
Generating an ITSO Product Entity (IPE) field at the ticket retailer device;
Constructing and stamping the IPE by one of a plurality of ITSO Secure Application Modules (“ISAMs”) remote from the retailer device from which the IPE is obtained;
Including
Internet or other network by control means that each ticket retailer device is operable to select an available ISAM from the plurality of ISAMs for the duration of the seal transaction initiated by that ticket retailer device Connected to the ISAM via The ITSO method in which the IPE validation is performed by one of a plurality of ISAMs remote from the validation device from which the IPE is obtained for validation,
Each validation device is connected to the Internet or other by a control means operable to select an available ISAM from the plurality of ISAMs during a validation transaction initiated by the validation device. ITSO system connected to ISAM via the network. An IPSO validity check method in the ITSO method,
Obtaining an ITSO product entity (“IPE”) from the validation device;
Validating the IPE by one of a plurality of ITSO Secure Application Modules (“ISAMs”) remote from the validation device from which the IPE is obtained;
Including
Each validation device may be connected to the Internet or other by control means operable to select one available ISAM from the plurality of ISAMs for the duration of a validation transaction initiated by the validation device. Connected to the ISAM via a network of A method of issuing prescriptions for drugs,
The prescription information is used to create an ITSO product entity ("IPE") that is stamped by one of a plurality of ITSO Secure Application Modules ("ISAMs") that are remote from the retailer device where the IPE is generated. Sent by a doctor or other prescriber,
Each retailer device has an ISAM over the Internet or other network by control means operable to select one available ISAM from the array for the duration of the imprint transaction initiated by that retailer device. Connected to the method. A method for validating drug prescriptions,
Prescription information is presented at a validation device to create an ITSO product entity (“IPE”) and is remote from the validation device where the IPE is presented for validation Validated by one of ITSO Secure Application Module ("ISAM")
Each validation device is connected to the Internet or other network by a control means operable to select one available ISAM from the array for the duration of the validation transaction initiated by that validation device. Connected to ISAM via A method of issuing a medicine prescription,
Generating an ITSO product entity ("IPE") that presents prescription information from a retailer device;
Imprinting the IPE with one of a plurality of ITSO Secure Application Modules ("ISAMs") remote from the retailer device where the IPE is generated;
Including
Via the Internet or other network, each retailer device can be controlled by a control means operable to select one available ISAM from the plurality of ISAMs for the duration of the seal transaction initiated by that retailer device. Connected to the ISAM. A method for validating a drug prescription,
Prescription information is presented for validation in the form of an ITSO product entity ("IPE") obtained from a validation device and away from the validation device where the IPE is presented for validation Validating the IPE with one of a plurality of ITSO Secure Application Modules ("ISAMs")
Including
Each validation device may be connected to the Internet or other by control means operable to select one available ISAM from the plurality of ISAMs for the duration of a validation transaction initiated by the validation device. Connected to the ISAM via a network of An ISAM array for use in the method according to claim 1, claim 3, or claim 5, wherein
The array comprises a plurality of ISAMs corresponding to a retailer or validation request sent from a remote retailer device or validation device to the control means over the Internet or other network and the control means Including
The control means selects one ISAM available from the plurality of ISAMs and transmits it to the Internet or during the period of a stamp transaction or validation transaction initiated by the retailer device or validation device. An ISAM array operable to connect to the retailer device or validation device via another network.   The ISAM array of claim 9, wherein the control means is operable to simultaneously connect a plurality of retailer devices or validation devices to each of the plurality of ISAMs. . A method or method according to any one of claims 1 to 8, or an ISAM array according to any of claims 9 or 10.
A method or scheme, or an ISAM array, wherein the plurality of ISAMs are grouped into individual respective logical groups.   12. The method, method or ISAM array of claim 11, wherein a stamp or validation request is received at the ISAM array from a plurality of third parties, each third party having a respective group of ISAMs. A method, scheme, or ISAM array that is assigned to A system for stamping or validating an ITSO product entity (IPE) comprising:
An interface for receiving a seal or validation request; and
An IPE handler to process a stamp or validation request;
A plurality of ITSO secure access modules (ISAMs) configured to receive the seal or validation request;
Including
The system wherein the interface and the IPE handler are configured to present the stamp or validation request to an ISAM or group of ISAMs based on control logic.   14. The system of claim 13, wherein the control logic is configured to select an appropriate ISAM or group of ISAMs based on the source of the request.   15. A method, method or system according to any of claims 1 to 14, wherein the ISAM includes a smart card.   The method, method, or system according to any one of claims 1 to 15, wherein the ISAM is implemented as a logical function on a server.

Images