WO2000051070A1 - Carte, appareil, produit et système de gestion de produits - Google Patents

Carte, appareil, produit et système de gestion de produits Download PDF

Info

Publication number
WO2000051070A1
WO2000051070A1 PCT/AU2000/000123 AU0000123W WO0051070A1 WO 2000051070 A1 WO2000051070 A1 WO 2000051070A1 AU 0000123 W AU0000123 W AU 0000123W WO 0051070 A1 WO0051070 A1 WO 0051070A1
Authority
WO
WIPO (PCT)
Prior art keywords
product
card
management
participant
accordance
Prior art date
Application number
PCT/AU2000/000123
Other languages
English (en)
Inventor
Mitchell Curtis Green
Michael Charles Walters
Rita Schade
Original Assignee
Cards Etc. Pty Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AUPP8822A external-priority patent/AUPP882299A0/en
Priority claimed from AUPQ3019A external-priority patent/AUPQ301999A0/en
Application filed by Cards Etc. Pty Limited filed Critical Cards Etc. Pty Limited
Priority to AU27848/00A priority Critical patent/AU777610B2/en
Priority to EP00906060A priority patent/EP1155382A4/fr
Priority to JP2000601601A priority patent/JP2002538529A/ja
Priority to NZ513659A priority patent/NZ513659A/en
Priority to IL14503100A priority patent/IL145031A0/xx
Priority to CA002363760A priority patent/CA2363760A1/fr
Priority to BR0008421-2A priority patent/BR0008421A/pt
Publication of WO2000051070A1 publication Critical patent/WO2000051070A1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means

Definitions

  • the present invention relates to a system for managing products associated with cards and devices, for example, payment, loyalty, identification, access, insurance, information and transportation products.
  • card we mean, broadly, any apparatus that can be used to facilitate product transactions (typically with a card-accepting device) .
  • This includes magnetic-striped cards, smart cards, “virtual” cards (“wallets”), memory cards, microprocessor cards, contactless cards, optical cards, laser cards, embossed cards, tickets, boarding passes, coupons, and printed cards. It also includes any apparatus which might not be a card but which may provide for similar functionality.
  • device we mean, broadly, any apparatus that can be used to facilitate product transactions (typically with a card). This includes ATM's, EFTPOS terminals, draft capture terminals, card accepters, contactless card readers, optical readers, laser readers, ticket readers, boarding pass readers, coupon readers, imprinters, and “virtual” devices (eg for reading "wallets”).
  • Loyalty products e.g., airline frequent flier, product coupon, retailer discount and customer frequency products.
  • Identification products e.g., license, ID, passport and electronic signature products.
  • Access products e.g., building, computer, mobile phone, device and security access products.
  • Insurance products e.g., health, motor vehicle and general insurance products.
  • Information products e.g., medical, health, personal, computer, motor vehicle service and portable information file products.
  • Transport ticketing products e.g., airline ticket and boarding pass, rapid transit ticketing, car park, parking meter and toll road transport products.
  • Card Issuer This may be an entity such as a bank that issues and/or subsequently manages a card for facilitating the credit product, to a cardholder. Note that the card issuer may outsource certain functions to third parties (e.g., card manufacturing to a card-manufacturing bureau, to specifications provided by the card issuer) ;
  • Cardholder This is usually the person holding the card. Note that the cardholder may be an inanimate object such as a motor vehicle, or a corporation who assigns the card to a position or function.
  • Transaction Acquirer This may be an entity such as a bank that typically (but not exclusively) installs and/or subsequently manages a device that accepts cards to facilitate a credit product transaction, to a card accepter.
  • the transaction acquirer is typically responsible for the management of transactions initiating from these devices (e.g., the routing of product transactions received from and sent to the devices, the routing of product transactions to processors to facilitate the approval and/or processing of product transactions).
  • the transaction acquirer may in some cases be the same entity as the card issuer (e.g., where the same bank that issues the card acquires the product transaction) .
  • the transaction acquirer may outsource certain functions to third parties (e.g., product transaction switching to a transaction- switching bureau, to specifications provided by the transaction acquirer) .
  • Card Accepter This is usually the participant accepting the card and presenting the product transaction to the transaction acquirer via the device.
  • the card accepter in the case of a credit card may be a retail merchant.
  • a "scheme operator" participant may also be involved.
  • Product transactions may be routed via a scheme operator from the device or transaction acquirer to the card issuer for approval and/or processing of the product transaction.
  • scheme operators include VISA® and MASTERCARD®.
  • the transaction acquirer may need to authorise the product transaction with the card issuer, before the transaction is approved.
  • Authorisation for the transaction may be sought on-line directly from the card issuer, via a scheme operator (where a scheme is involved) or a third party ("stand in").
  • the transaction acquirer will need to clear and settle the product transaction with the card issuer, as well as provide the product transaction to the card issuer so it can be processed. In credit card transactions, this can be done in a number of ways. Where the transaction acquirer and the card issuer are the same participant, it can be settled and provided for processing directly with the card issuer (an "on us" product transaction) . Where the transaction acquirer and the card issuer are different participants, it can be settled and provided for processing through a bilateral interchange agreement or via a scheme operator (where a scheme is involved) interchange arrangement ("off us").
  • the card accepter usually pays a fee to the transaction acquirer, who in turn usually pays a fee to the card issuer (as well as the scheme operator or third party, if applicable) .
  • the cardholder will also pay a fee to the card issuer and/or card accepter. Alternately, the flow of fees between the various participants may be reversed in some cases .
  • Any management system (s) must be able to carry out a large number of processes and manage information enabling the management of the product and relationships.
  • the management system (s) must be able to:
  • a product scheme and product package may overlap, such as where a VISA® or MASTERCARD® credit product issued by one bank is tied to a package of products in a confined locality (e.g., the Qantas/Telstra/Visa scheme in Australia or the American Express/American Airlines/Hilton Hotels scheme in North America) .
  • a VISA® or MASTERCARD® credit product issued by one bank is tied to a package of products in a confined locality (e.g., the Qantas/Telstra/Visa scheme in Australia or the American Express/American Airlines/Hilton Hotels scheme in North America) .
  • Present card and/or device product management systems therefore have a number of problems. Firstly, as discussed above, they are not readily adaptable to support significant changes in the product. Secondly, if a card or device is lost or damaged and requires replacement, it can be a complex matter to obtain all the necessary information to reissue the card or reestablish the device. This is particularly the case where a card and/or device may be associated with more than one product (e.g., a credit card product and a loyalty scheme product supported by the same card and/or device) . Information may have to be obtained from a number of different entities in order to reissue the card and/or reestablish the device. The presently available management systems limit the extent by which cards associated with different products can be implemented (multi-product cards).
  • multi-product devices devices supporting different products can be established.
  • One of the major benefits of smart cards which is often claimed is their ability to support many different products on a single card. A cardholder may therefore only need to carry one or two cards that support all the products that they may require.
  • the present management systems stand in the way of the implementation of multi product cards, as well as multi-product devices. The present management systems often result in product operating errors and delays in completing transactions, particularly where the product is one of a multiple-product system.
  • the present multiple-product systems generally arise by the addition of a further product to an already existing card/device based product.
  • the management system is amended or added to to cope with the further product.
  • the further product includes a loyalty scheme
  • presently transaction information from the primary product (e.g. credit card product) will undergo further processing to establish data associated with the loyalty product.
  • Primary participants in this system are the managers of the credit card product (e.g. transaction acquirer and card issuer for the credit card product) .
  • the primary participants provide further separate processing.
  • the transaction acquirer and the card issuer may be a bank.
  • the bank is responsible for processing a transaction it receives from devices associated with the credit card product.
  • the bank In a separate process (usually carried out in batch) the bank must determine which of the credit product transactions are associated with card holders who belong to the loyalty scheme. The data from those transactions is then used to calculate loyalty points. Loyalty points are often calculated by a separate bureau which receives the relevant transaction data from the bank. The loyalty points may then be passed on to the loyalty product manager. The transaction data processed by the transaction acquirer will include the same data whether the transaction is associated with the loyalty scheme or not.
  • the transaction acquirer (or other entity processing the transactions) must first of all "match up" the transaction data with the loyalty scheme (which may be by identifying the card holder the transaction is associated with determining whether or not that card holder is a member of the loyalty scheme) and then pass only the relevant transactions onto the loyalty product manager (or bureau) .
  • the transaction must go past the transaction acquirer first for primary processing before it is passed on for further processing to enable implementation of the loyalty product. This complicates processing.
  • This system can result in errors and delays. For example, it may take weeks or even months for loyalty points to be credited to a card holders account. In some cases, loyalty points may not be allocated at all. Further, redemption of loyalty points is done as a totally separate process, which is also slow and requires effort by the card holder.
  • the present "card processing environment" can be considered either a single role environment (where all product transactions are “on us”) or a dual role environment (where at least some product transactions are "off us”) .
  • the card issuer is also the transaction acquirer.
  • the card issuer and transaction acquirer may be separate. It should be noted that there might be multiple participants carrying out a particular role (i.e., multiple card issuers and multiple transaction acquirers within a dual role environment) .
  • the product manager is an indirect participant.
  • Indirect participants rely on the participants in the single role or dual role environment to provide them with the information necessary for them to manage the product. They are not directly involved in the "card processing environment" .
  • the raw data provided in the transaction is not usable by the further indirect participant. Further processing must be provided by a separate process.
  • the present applicants have identified the possibility of a further role being involved in the card processing environment to facilitate the management of card device- based products, particularly where multiple products are to be supported by cards and/or devices.
  • the applicants have termed this third role a "product owner" .
  • the product owner is an entity who can be considered to "own” a product associated with the card and/or device.
  • the product owner may be responsible for the management of the product in isolation of other card and/or device management requirements (i.e., they may not be responsible for the issuing or management of cards, nor the establishment or management of devices) .
  • the applicants have re-named the previous card issuer role as "card manager".
  • a product may be implemented as a product application on a card, on a device, or distributed on both card and the device. Smart cards in particular facilitate the provision of product applications on the card.
  • the management system of the present invention although particularly appropriate for the smart card environment may also be implemented to manage products which may not be on the card, which may be on the device, or which may be neither on the card or on the device.
  • the present invention provides a card device and product management system, including a card management means which enables a card manager participant to perform a card management role alone, without managing products associated with a card and without managing devices; a device management means which enables a device manager participant to perform a device management role alone, without managing products associated with the card and without managing cards; and a product management means, which enables a product owner participant to perform a product management role alone, without managing cards and without managing devices, whereby all three roles can be performed by separate entities .
  • the terms "card”, “device” and “product” have the definitions which are given above, as amplified as follows:
  • the “card” includes any means which enables representation of a relationship between a card holder and a card manager. In the simplest terms, it may include merely an identification number or account number. It is a guarantee that the card holder is enabled to carry out the product transaction. It may include a token or electronic wallet which is utilisable over a computer network such as the Internet, from a card holder's PC.
  • a "device” is anything capable of representing a relationship between a device manager
  • transaction acquirer and a card acceptor (merchant) .
  • card acceptor and a card acceptor (merchant) . It may be a "virtual" device accessible via a Web page on the
  • Each of the product management means, card management means and device management means preferably includes a software module controlling a processing means to facilitate the product owner, card manager and device manager roles.
  • the system preferably further comprises a message management means which is arranged to manage the routing of message data between cards, devices and the card, device and product management system.
  • the message management means includes a software module which can control a processing means to control the routing of message data.
  • message data is meant any data including transaction data, that needs to be routed within the system.
  • each participant in the system is provided with a message management module.
  • each of the entities will have a message management means to control the routing of message data within the system, i.e. between the management means and the cards and devices.
  • tne device management means include storage means for storing product owner identification data, identifying product owner participants responsible for managing products associated with devices managed by the device manager participant, and card acceptor identification data, identifying card acceptors using devices managed by the device manager participant.
  • the product management means includes storage means arranged to store card manager identification data identifying card managers managing cards supporting products managed by the product owner participant.
  • the product management means may also store card holder identification data, identifying card holders holding cards having products managed by the product owner participant, and card acceptor identification data, identifying card acceptors having devices supporting products managed by the product owner participant.
  • the card management means is arranged to store product owner identification data identifying product owner participants responsible for managing products associated with cards managed by the card manager participant.
  • the card management means may also store card holder identification data, identifying card holders holding cards managed by the card managed participant.
  • each of the management means also stores links to the management means of other participants.
  • a database may store the required data.
  • each case identification data may not be the actual identity of the entity.
  • the product owner may not need necessarily to have the name of the card holder who has a product of the product owner. It may be sufficient to have an ID number, without knowing the actual name of the card holder. It may only be necessary for the card manager to know the actual identity of the card holder. In many cases a card holder will not wish to provide their identity to more entities than necessary.
  • the present system enables products to be provided to a card holder without the card holder having necessarily to provide his identity to a product owner.
  • Any product owner must have a relationship with a cardholder.
  • the relationship with the cardholder need not be direct. It could be by way of a card manager. What the product owner requires in the relationship with the cardholder is the right type of product data to enable management of the product.
  • This can be any data that the product owner requires from the cardholder, as well as any data that the product owner provides to the cardholder. It may be a product transaction, the name and address of the cardholder, a card application for a product, a unique identifier of the card (e.g., a card number) and cardholder, or any other information.
  • Any product owner must have a relationship with a card accepter.
  • the relationship with the card acceptor need not be direct. It could be by way of a device manager. What the product owner requires in the relationship with the card accepter is the right type of product data to enable management of the product. This can be any data that the product owner requires from the card accepter, as well as any data that the product owner provides to the card accepter. It may be a product transaction, the name and address of the card accepter, a device application for a product, a unique identifier of the device (e.g., a device number) and card accepter, or any other information.
  • the relationship with the card accepter and the cardholder may be implemented dynamically. That is, the relationship may occur only when the card accepter and cardholder come to operate the product e.g., the product may Pe loaded by the card acceptor and cardholder at any time .
  • data such as the identity of the cardholder will usually be required ⁇ y the product owner.
  • the identity need not be an actual identity but may merely be an identification number. In some cases even identity information may not be necessary i.e., it may be enough for the product owner to receive transaction data indicating that there is a card holder.
  • the relationship with the cardholder may be indirect and any information on the cardholder could be provided by other parties in the system e.g., a card manager.
  • data such as the identity of the card accepter will usually be required by the product owner.
  • the identity need not be an actual identity but may merely be an identification number. In some cases even identity information may not be necessary i.e., it may sufficient merely to receive transaction information from the card acceptor so that the product owner is aware that there is a card acceptor.
  • the relationship with the card accepter may be indirect and any information on the card accepter could be provided by other parties in the system e.g., a device manager.
  • Separation out of product management from other aspects of card management provides a number of advantages. Any card and/or device product can be managed separately from all other aspects of the card- and/or device-related environment. Thus, the role of the product owner is simplified (management of the product only) , such that the product owner - need not be concerned with, for example, the provision and management of cards and - devices required to support their product. This also results m less effort on the part of card managers and device managers to support the products of a product owner. For example, a chain of restaurants may wish to manage a loyalty scheme, where they would be the product owner of the loyalty scheme.
  • the card management means manages aspects of the card-related environment that are associated with the card manager.
  • the card manager management system should preferably be able to uniquely identify each card it manages, maintain data relating to that card, and share such data with product owners and device managers.
  • the device management means manages aspects of the device-related environment that are associated with the device manager.
  • the device manager management system (s) should preferably be able to uniquely identify each device it manages, maintain data relating to that device, and share such data with product owners and card managers .
  • the product owner thus manages the product in isolation from all the other tasks. Aspects of the product may be updated (e.g., a new version of the product application on the card) through the product management means in a tripartite environment, thus avoiding the need for that entity to also have a card and/or device management means.
  • This serves to illustrate an important aspect of the present invention.
  • a third party operates a product such as a loyalty scheme as a secondary product receiving data from a system which has been designed to operate a primary product
  • the loyalty product owner is not really a party to the management system at all.
  • the prior art environment is dual role or single role environment, and the third party depends upon the parties to the primary product for any information, transactional information and to make any amendments to the product. Where the product is on the card or in the device, it is the primary participants who must make amendments to the product application.
  • the product owner is preferably able to affect control over the product.
  • the product application exist either on a device or on a card (such as a smart card) or on both
  • the product owner may be able to download an updated application via the management system, perhaps without any intervention of any of the other management participants in the system.
  • Transaction data created in relation to the product may be routed to the product owner via the message management means of the other participants in the system, without processing by the management modules of the other participants.
  • the management system of the present invention therefore, preferably facilitates enabling the product holder to communicate directly with the product e.g., to put information on the product or to receive information from the product. This cannot be done in the prior art by a third party operator who is not directly involved in the prior art dual role or single role environment.
  • a card or device may include a number of products which are known by the management system (s) of the card manager and the device manager, which also maintains non-product specific data.
  • the management system) s) of the card manager and device manager may also maintain product specific data provided by each product owner, or may maintain links to each product owner' s management system such that this product-specific data can be obtained. In this way, a card manager or device manager may obtain data from the management system (s) of product owners that, together with data maintained on their own management system, will enable a card or device to be reconstructed and replaced.
  • the provision and management of multi-product cards and devices becomes simpler with a management system in accordance with the present invention. If a product owner wishes to deploy a product onto a card or device, all they need do is obtain the product management system and message management package, and establish a relationship with a card manager and device manager for that product. The card manager can then assist the product owner to deploy the product on their cards, and the device manager can assist the product owner to deploy the product on their devices. Once the product is operational, the device manager and card manager can configure their management systems to manage transactions facilitated by the product. For example, the device manager's management system may route product transactions received from their devices directly to the product owner' s management system, and the card managers' management system may inform the product owners' management system of any change of address details advised by the cardholder.
  • the security and privacy aspects of the system of the present invention are also particularly advantageous. Cardholders are often reluctant to give too many personal details to certain entities. With the present invention, all that the product management system requires is sufficient information to be able to manage the product. The personal identity of a cardholder may not be required. Such aspects can be left to the card manager. If the card manager is a reputable bank, therefore, for example, the product owner may "trust" the bank to ensure the bona fides of the cardholder, and thus would not require this information themselves. This is advantageous for the cardholder as it limits the number of entities that require detailed personal information, but still enables the cardholder to obtain access to multiple products, thus protecting personal privacy. If the product owner must communicate with the cardholder, this can be achieved through the card manager who can link the unique identifier of the cardholder maintained by the product owner with the personal information of the product owner, and then communicate directly with the latter.
  • the management system of the present invention also preferably includes interface means to interface the management system with external systems.
  • This interface means is preferably provided in the form of software modules which the applicant terms "business modules" which operate a processing means to interface with a desired external system. For example, a product owner may already have or may wish to design their own external system for processing aspects of a product.
  • a business module therefore provides a link between the external system and the management system and may convert the data being received by the management system into a form which is usable by the product owners external system. Modules may also interface to legacy systems, so that the management system of the present invention is able to fit in with existing systems.
  • the present invention further provides a product management system, comprising a product management means which enables a product owner participant to perform a product management role alone, without managing cards and without managing devices, wherein the system is arranged to facilitate the product owner participant to directly affect control of a product associated with a card or device.
  • a product management system comprising a product management means which enables a product owner participant to perform a product management role alone, without managing cards and without managing devices, wherein the system is arranged to facilitate the product owner participant to directly affect control of a product associated with a card or device.
  • “facilitate” is meant that the system gives a mechanism by which data can be communicated directly between the product holder and the product associated with the card or device.
  • the product may be on the card or on the device in the sense that software is resting on the card or device relating to the product.
  • the card or device may be considered in terms of "real estate” e.g. the smart card may include a number of storage locations which the card manager can "let” to product
  • the card manager will provide a "key" to enable the product owner to have access to a secure location on the card and the product owner could in fact provide their own key to prevent interference with the product on the card. This cannot be done by present multiple product arrangements, wherein primary processing is required by a card manager or device manager before a product owner, such as a loyalty points owner, can manage the product.
  • the present invention further provides a card management system, including a card management means which enables a card manager participant to perform a card management role alone, without managing products associated with a card and without managing devices.
  • the present invention further provides a device management system, including a device management means which enables a device manager participant to perform a device management role alone, without managing products associated with a card and without managing cards.
  • the present invention further provides a card, device and product management system, including a plurality of service processing means, each service processing means enabling a participant to the system to carry out at least one of card, device and product management, and a message management means provided to each participant in the system and arranged to act as a communications interface routing message data between each of the service processing means and between cards and devices, to enable a network of service processing means and a plurality of participants to interface to carry out card, device and product management.
  • the service processing means preferably include card management means, device management means and product management means, as discussed above.
  • the present invention further provides a card, device and product management system including a network comprising a plurality of nodes, each node comprising a service processing means enabling a system participant to carry out at least one of card, device and product management, and a message management means arranged to act as a communications interface routing message data between the service processing means of each node and between cards and devices.
  • the present invention further provides a method of managing cards, devices and products, comprising the steps of defining a tripartite environment for card management, the card management tripartite environment comprising; a card manager participant responsible for managing non-product specific card operations; a device manager participant responsible for managing devices for accepting cards and for carrying out product transactions; and a product manager participant, responsible for the management of product-related aspects of the card environment, wherein the device manager participant, card management participant and product manager participant may be separate entities.
  • the present invention further provides a method of managing products, comprising the steps of defining a product manager participant, responsible for the management of products alone, without managing cards and without managing devices, and facilitating the product manager participant to directly affect control of a product associated with a card or device.
  • the present invention further provides a method of managing cards, comprising the steps of defining a card manager participant whose role is to perform management of cards alone, without managing products associated with a card and without managing devices.
  • the present invention further provides a method of managing devices, comprising the steps of defining a device manager participant whose role is to perform management of devices alone, without managing products associated with a card and without managing cards .
  • the present invention further provides a generic system for the management of cards, devices and products, the system including a card management module, a device management module and a product management module, which can be used separately and networked with each other to enable different entities to carry out card management, device management and product management alone, and to network with other similar systems to facilitate card, device and product management.
  • any entity wishing to become involved acquires the necessary module (depending on whether they are card manager, device manager or product manager) and configures it to their requirements.
  • Such a generic system particularly designed to facilitate the management of cards, devices and products is a novel concept. Any number of entities can become involved in a networked system.
  • the system of this aspect of the present invention may include any or all of the features of the aspects discussed above.
  • the present invention further provides a card, device and product arrangement, including a computing system having storage locations for receiving a plurality of product applications, and security means enabling selective access to the storage locations for a plurality of product owners, whereby the product owners may separately access and manage their products stored at the storage locations.
  • the storage locations for receiving the product applications may be mounted on the cards themselves eg where the cards are smart cards, or may be mounted on devices or shared between cards and devices.
  • the storage locations can be considered in terms of "real estate" as discussed above, and a card or device manager can "let” the real estate to product owners so that they can run their products using the arrangement.
  • the security means may comprise a key, preferably in the form of any token which enables the product owner access to the storage location (a token may be any identifier, eg PIN) .
  • Security means may also be provided to prevent the card or device manager from accessing a particular product owner' s storage location, once it has been "let" to that product owner.
  • storage locations need not be mounted on the cards or the devices, but may be located elsewhere in the computer system, or may be distributed within the computer system.
  • the card, device and product arrangement of the present invention is preferably implemented within a card, device and product management system in accordance with the preceding aspects of the present invention discussed above. Indeed, the use of such a system facilitates the product owner management of their product application stored at the storage location.
  • Fig. 1 is a schematic diagram of a present card- related environment
  • Fig. 2 is a schematic diagram of a card-related environment facilitated by the card management system of the present invention
  • Fig. 3 is a block diagram of a system architecture of a card management system in accordance with an embodiment of the present invention.
  • Fig. 4 is a schematic diagram giving an example of an overall linked system including entities running a plurality of card management systems in accordance with embodiments of the present invention, for managing transactions for multiple product cards;
  • Fig. 5 is an illustration of application of a management system in accordance with an embodiment of the present invention.
  • Fig. 6 is a schematic diagram illustrating processing of a compound transaction in a management system in accordance with an embodiment of the present invention
  • Fig. 7 is a schematic diagram illustrating a smart card reconstruction process utilising a management system in accordance with an embodiment of the present invention
  • Fig. 8 is a schematic diagram illustrating an application download to a smart card utilising a management system in accordance with the present invention
  • Fig. 9 is a schematic diagram illustrating a process for deleting an application from a smart card utilising a management system in accordance with an embodiment of the present invention.
  • Figure 1 shows the current environment for management of card products.
  • the environment includes a card issuer 1.
  • the card issuer is responsible for issuing and managing a card 2 (perhaps by way of a separate card-manufacturing bureau) to a cardholder 3.
  • the card issuer may be a bank or other financial institution that wishes to issue cardholders cards having a credit card product, for example.
  • the card issuer would require details of the identity of the cardholder, address, credit rating, etc.
  • the environment also includes a transaction acquirer 4.
  • the transaction acquirer is responsible for deploying and managing devices 5 (perhaps by way of a third party distributor) to a card accepter 6.
  • the transaction acquirer may be a bank or other organisation that wishes to deploy devices to card accepters who support a credit card product, for example.
  • the transaction acquirer would require details of the identity of the card accepter, address, bank account details, etc.
  • dedicated computer systems are used to manage the card product in the current environment. These systems are subject to the problems discussed in the preamble of this specification.
  • a modified environment is shown which is facilitated by the card management system in a preferred embodiment of the present invention.
  • the product owner 7 is responsible for management of aspects of the environment that relates to a particular product supported by the card 2 and the device 5.
  • the product owner is only responsible for the product.
  • the product owner is not responsible for other aspects of the card and device environment that are not specifically product related, such as issuing and managing cards and deploying and managing devices.
  • a product owner needs only information on a card, device, cardholder and card accepter that is required to operate the product.
  • the product owner 7 will have relationships with card accepters and card holders who support the product.
  • the product owner, card manager, and device manager functions may be carried out by one or more entities, which may in turn perform one of more functions. In this way, many scenarios are supported. For example, one entity may only perform the product owner function, another entity may perform the card manager and product owner function, a third entity may perform all three functions, whilst a final entity may perform only the device management function.
  • the architecture of the management system in accordance with an embodiment of the present invention is illustrated schematically in figure 3.
  • the management system comprises a message management module 10, card management module 11, device management module 12, and product management module 13.
  • the message management module which is arranged to receive message-data (e.g., from devices) and forward the message data onto the appropriate service management module 11, 12, 13. Similarly, it can receive message data from the management module 11, 12, 13 and forward them out of the system or to other management modules.
  • Each of the management system modules includes functionality that enables management of cards (card management module 11), devices (device management module 12) and products (product management module 13).
  • the system also comprises one or more business modules 14. These modules encapsulate the functionality required to meet a particular business need of one or more entities participating in a card environment utilising a management system in accordance with the present invention.
  • the business modules provide extensions and/or constraints to the management system in order to support specific business requirements. For example, they may support the technical implementation of the MULTOS card platform, support an interface to a legacy database system, support transaction processing specific to a particular product, or manage transactions received from a particular device.
  • Each of the card 11, device 12 and product management 13 modules include relational databases and processing means to provide the following:
  • Card Manager and Device Manager information may support product.
  • Device management links Links to or data from the device management module for card acceptors supporting the product .
  • Transaction data may be required to be mirrored for reconstruction.
  • Device specification data To define device maintenance/management processes - provides details about capacity for applications, etc. 9. Device parameters/configuration data required for device installation reconstruction processes. Defines device manager specific configuration of device data.
  • Card acceptor data e.g. conduct details, full title, demographic information, etc.
  • Card acceptor/Device relationships Multiple device may be linked to same card acceptor.
  • Card acceptor establishment e.g. through manual data entry, electronic file import. 15. Card acceptor communications. Statements, etc.
  • Application distribution Keep track and distribute applications to devices and card applications to be distributed to smart cards.
  • Device utilisation provides device manager with tools to specify the data to be included on the device.
  • Card holder Data All card holder related data is required to be captured and maintained by the card management module e.g. card holders name, contact details, identification references, demographic information, market research findings and diary notes.
  • Card/card holder relationships (relationship links required for many to many relationships between cards and card holders. Multiple card holders may be linked to the same group (e.g. family cards) - multiple cards to same card holder (company, corporation cards) .
  • Card specification data card platform issued, memory capacity, types of memory, for capacity of applications.
  • Card parameters/configuration data for card production/updating/reconstruction processes. Specify how card memory space is used and data/applications downloaded onto card and defines general card issuer specific configuration of the card data (this does not include product specific data/applications.
  • Personalisation data for card production/reconstruction processes specifies the card holder data provided on the card, which may be number of cardholder data.
  • Card product applications/links - maintains links to product manager to enable reconstruction of card.
  • Card holder establishment through manual data entry, electronic file import, etc.
  • Card holder communications e.g. event dates/time dates such as card issuance.
  • Card production/issuance provides tools for card manager to specify data to be included on cards and provide for unique ID of card.
  • Card updating/reconstruction - facility to update reconstruct specified card or range of cards - may require the need for regular "reconciliations" with card in on-line environment .
  • the message management module enables the following functions :
  • Message management Module 1 Manages message and data flows for and between the service and business modules.
  • Perform system administration tasks e.g. installing and uninstalling configuring, performance monitoring, logging, notifying users, detecting and analysing anomalies, backing up and restoring, archiving and retrieving.
  • Transaction splitting Some transactions received may be compound transactions (same transaction applies to multiple products or applications) and are required to be split into two or more atomic transactions - transactions must be routed as early in the transaction chain as possible to ensure highest data privacy possible.
  • entity one is an organisation that wishes to provide and run certain products. All they require of the system is the foundation module and the product management module, as well as any business modules that may be needed in order to support particular business functionality.
  • entity two is a card and device manager
  • entity three is a card manager, device manager and also a product owner.
  • Each of the management systems of entity one, entity two and entity three may be connected to support various products.
  • a product owner may establish a commercial relationship with entity one and/or entity two as the card manager and/or device manager for their particular product.
  • a cardholder 1 who requires an available product may seek the product from the product owner.
  • the product may be provided as a software application downloaded via a device 5.
  • the cardholder could in fact interact directly with the device to request the product, provide any details that may be required (if they cannot already be provided from the details that the card manager has on the cardholder) .
  • the product can then be entered on the card holders card.
  • Fig. 5 is an illustration of an example configuration of the use of management systems in accordance with the present invention. Two participants are illustrated.
  • Participant "A” is a bank or other financial institution that operates a credit card product. They run a management system in accordance with the present invention, including message management module 20, card management module 21, device management module 22 and product management module 23. Business management module a 24 and business management module b 25 are also provided. Participant A not only manages the credit card product using product management module 23, but also manages devices 26 and cards 27, utilising device management module 22 and card management module 21, respectively.
  • Participant "B” is an airline which owns a loyalty product. They have a system in accordance with the present invention comprising a message management module 28, a product management module 29, business management module c 30 and a loyalty system application 31.
  • the loyalty system application 31 is an application designed specifically for participant B, for processing its loyalty system transactions .
  • Card holder 32 possesses a card 27 which supports both the credit card product of participant A and the loyalty product of participant B. Card holder 32 purchases goods from card acceptor 33. In order to pay for the goods the cardholder uses the credit card product on the card 27 via device 26.
  • Message data 34 generated by the device 26 is transferred directly to the message management module 20 participant A.
  • Message management module 20 routes the message data to the device management module 22.
  • the device management module determines that message data relates to a transaction which is associated with their credit card product and also with the loyalty product of participant B.
  • the device management module 22 operates to break down the transaction data into message data for the participant B and also message data for the product management module 23 of participant A. Message data for the product management module 23 is routed via the message management means 20 to the product management module 23.
  • the credit transaction is an "on us" transaction and the product management module 23 determines that the participant A is also the card manager 21.
  • Appropriate transaction information may be provided to the card management module 21 via the message management module 20 and also to an external credit card processing system 34 after having been converted by business module a 24 into an appropriate (different) form required for the credit card processing external system 34.
  • the system 34 may be a legacy system which was already in place at participant A before installation of the management system of the present invention.
  • the message data intended for the participant B is first of all routed by business management module b 25, for appropriate cryptographic conversion. Participant B requires that this cryptographic processing be carried out for security purposes.
  • the encrypted message data is transmitted via the message management module 20 to- the message management module 28 of participant B.
  • Message management module 28 passes on the message data to product management module 29.
  • the product management module 29 calculates loyalty points, for example. In this particular case, participant B has a separate loyalty product system 31 that needs to be updated with the loyalty points. Further message data generated by the product management module 29 and including the loyalty point information is converted via business management module c 30 to an appropriate format for the loyalty point system 31 and passed to the loyalty point system 31 via the message management module 28.
  • Another example of the utility of the management system of the present invention is in the handling of compound transactions.
  • a compound transaction is a single transaction which applies to multiple applications managed by the same or different processing systems/management systems of the present invention. For instance, a credit product transaction with an attached loyalty product may generate one transaction between smart card and device; however, the atomic transactions for the credit product and the loyalty product may be routed to different systems. Compound transactions occur each time multiple applications generate a compound transaction during the interaction between smart card and devices.
  • FIG. 6 illustrates the transaction flow for a compound transaction. The steps involved are described in detail below.
  • the Device Management 42 applies pre-defined rules to the logged transactions.
  • a compound transaction rule generates multiple atomic transactions destined for multiple management systems in accordance with the present invention or legacy systems.
  • the Device Management 42 transmits the atomic transactions to one or more Product Management modules, 44, 45 and/or to one or more legacy systems 46, for further processing.
  • the Device Management may optionally transmit an advice to one or more Card Management systems to advise altered smart card data or applications. Other possibilities are:
  • Multiple applications operating concurrently may generate an atomic transaction each, such that no compound transactions occur.
  • a compound transaction may be divided into its atomic transactions in the device prior to a periodic batch transmission to the Device Management.
  • the process of recreating smart cards may become necessary when cardholders advise the card issuer that the smart cards are lost or stolen.
  • the recreation of the smart card involves blocking the lost/stolen card, accumulating the applications and data from the Card Management system, and personalising a new smart card.
  • the Card Management may only recreate the smart card' s applications and data for which the Card Management has received explicit permission from the cardholder.
  • the cardholder is responsible for recreating private data. For instance, cryptographic keys may only be obtained by the cardholder or by the Card Management with explicit permission from the cardholder, possible through a request to the Product Management module which may request the cardholder keys for an application from the CA.
  • Figures 7 illustrates the transaction flow for the recreation of a smart card. The steps involved are described in detail below.
  • the steps of the transaction flow may be described as follows : 1.
  • the cardholder 50 requests a smart card recreation from the card issuer 51, and provides card issuer 51 with desired permission for the reconstruction process.
  • the card issuer instructs the Card Management module 52 to block the previous card and schedule the reconstruction process, and requests a smart card reconstruction.
  • the Card Management 52 generates a new card number, assimilates the cardholder data, the card applications references and requests the applications and possibly the permissive card data (should the card data not reside within the Card Management module) from one or more Product Management modules 53 and/or one or more legacy systems 54 referred to in the card application references. 4.
  • the Product Management modules (s) 53 and/or legacy system(s) 54 review the permissions, may request the appropriate data from other sources, e.g. CA, update the appropriate databases with the new card number and transmit the applications and possibly the card data to the Card Management module 52.
  • the Card Management module 52 generates a personalisation file with all the assimilated applications and data.
  • the personalisation file may be processed in the form of a report by an independent card personalisation machine 55 and the card 56 submitted to the cardholder 50. Variations :
  • the card Management may request a smart card or a range of smart cards to be reconstructed, e.g. the expiry date is printed on the card face.
  • One of the major advantages of the management system in accordance with the present invention is that it enables dynamic loading and unloading of product applications from smart cards and/or devices after issuance of the smart card or installation of the device.
  • the dynamic application load transfers an application to a smart card or device, to ensure that new applications may be loaded onto smart cards after the cards have been issued, and loaded onto the devices after they have been installed.
  • the application load transaction occurs upon request, the request may be issued by the management system modules or by the cardholder or card acceptor.
  • Figure 8 illustrates one of the possible transaction flows for an application load transaction to smart cards. The steps involved in this variation are described in detail below.
  • the step of the transaction flow to facilitate application loading onto smart cards may be described as follows :
  • the device offers the smart card 60 an application that is not resident on the smart card 60.
  • the smart card 60 may verify that the application may legally reside on the card manager's card (e.g. ascertaining that an agreement is in place between card manager and device manager for this application) . 2. The cardholder agrees to load the application onto the smart card 60, the smart card 60 requests the device 61 to provide the application for the smart card 60 to load into its memory.
  • the device dials into the Device Management 62 of the management system of the present invention.
  • the Device Management 62 sends an application request to the Product Management 63.
  • the verification may be required between Device Management 62 and Card Management 64, prior to the application request being submitted to the Product Management 63. Also, if the application has a value associated with the application, the Device Management 62 may ascertain that the smart card 60 has not been blocked. 5. The Product Management 63 provides the requested application to the Device Management 62.
  • the Device Management 62 provides the requested application to the device 61. 7.
  • the device 61 discontinues the on-line link to the Device Management 62 and provides the smart card 60 with the requested application.
  • the smart card 60 installs the application in its memory.
  • the smart card 60 may send an advice of the successful loading to the device 61 for batch upload to the Device Management 62 for distribution to the requesting participant. This advice may be necessary for mission critical application, whilst other products or Card Management 64 may not require the advice.
  • the Device Management 62 may transmit the advice to
  • the device management 62, product management 63 and card management 64 may belong to the same entity or separate entities.
  • the cardholder requests by phone that the application be loaded onto the smart card, e.g. the next time the smart card is on-line for another transaction.
  • the Product Management will schedule the load and request the Device Management to provide the device with the application upon request, e.g. when the smart card is on-line.
  • the Product Management arranges an agreement with the Card Management to provide all the smart cards managed by the Card Management with an application. Either the Card Management or the Product Management instructs the Device Management to:
  • the Card Management instructs the Device Management to load applications onto a range of smart cards either:
  • the device requests on-line that an application be loaded, e.g. to process a transaction with a smart card which holds an unknown application.
  • the Device Management requests the application from one or more Product Management modules.
  • the application is loaded onto the device in a similar fashion to the smart card application load. Once the application is installed in the device, the transaction with the smart card may proceed.
  • the Device Management requests the device applications from the Product Management module (s) and transfers the applications to a range/all devices for installation during the next interaction with the devices.
  • the Product Management requests the Device Management to provide the devices with applications during the next interaction with the devices.
  • the dynamic application unload deletes an application from a smart card 70n or device 71, to ensure that applications may be unloaded from smart cards after the cards have been issued, and unloaded from the devices after they have been installed.
  • the application unload transaction may occur automatically (e.g. single use coupons) or upon request, the request may be issued by the modules of the management system of the present invention or by the cardholder or card acceptor.
  • Figure 9 illustrates the transaction flow for an unload transaction. The steps involved are described in detail below.
  • the Card Management 72 may request the Device Management 73 to delete an application from a range of smart cards managed by the Card Management 73,
  • the Device Management 73 may request the device 71 to communicate the unload request to the smart card 70 as part of the response to the device 71.
  • the device 71 discontinues the communication with the Device Management 73, completes the transaction, and communicates the unload request to the smart card 70.
  • (b) communicates the broadcasted unload request to the smart card 70.
  • the smart card 70 deletes the application from its memory, with an optional advice to the device 71 tat the application ahs been deleted.
  • the advice may be uploaded to the Device Management 73 during the next interaction, which may be transmitted to the Card Management 72 and the Product 73 Management modules.
  • the Dynamic Application Unload for devices may be facilitated in a similar manner with the instruction for the load originating either from the device, the Device Management module or the Product Management module.
  • Other possibilities for application unloads to smart cards and/or devices are:
  • the Product Management may request the Device Management to unload an application from all smart cards and/or all devices, e.g. a discontinued application.
  • the smart card may delete the application from its memory after a single use of the application, e.g. single use coupons.
  • the device may request the smart card to delete the application from its memory after a single use of the application, e.g. single use coupons.
  • the Device Management may request the device that an application that is no longer supported by the Device Management be deleted from the device's memory.
  • Implementation of a management system in accordance with the present invention can enable methods of operating and making available products that are not presently practical .
  • card managers and device managers operating the system may publish a set of "standards" for compliance with their systems.
  • Product owners complying with those standards could then offer products for use with the cards and devices managed by the card manager and device manager. There would be no need for any complex negotiations to establish the parameters of the relationship between the product owner, device manager and card manager.
  • the product owner would merely have to arrange his product to comply with the standards and then make the product available to the card manager and device manager, who would in turn make the product available to the card holder.
  • An already fully compliant product is offered for use with the systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Warehouses Or Storage Devices (AREA)

Abstract

La présente invention concerne un système de gestion de produits, de cartes et d'appareils, et notamment un dispositif de gestion de cartes qui permet à une partie gestionnaire de cartes d'assumer seule la gestion des cartes sans gérer les produits associés à une carte et sans avoir besoin de gérer des appareils. L'invention concerne également un dispositif de gestion d'appareils qui permet à une partie gestionnaire d'appareils d'assumer seule la gestion d'appareils sans gérer les produits associés à la carte et sans avoir besoin de gérer les cartes. L'invention concerne également un dispositif de gestion de produits qui permet à la partie propriétaire des produits d'assumer seule la gestion des produits, sans gérer les cartes ni les appareils, les trois fonctions pouvant alors être exécutées par des entités séparées.
PCT/AU2000/000123 1999-02-22 2000-02-22 Carte, appareil, produit et système de gestion de produits WO2000051070A1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
AU27848/00A AU777610B2 (en) 1999-02-22 2000-02-22 Card, device, product and product management system
EP00906060A EP1155382A4 (fr) 1999-02-22 2000-02-22 Carte, appareil, produit et syst me de gestion de produits
JP2000601601A JP2002538529A (ja) 1999-02-22 2000-02-22 カード、装置、商品および商品管理システム
NZ513659A NZ513659A (en) 1999-02-22 2000-02-22 Card, device, product and product management system
IL14503100A IL145031A0 (en) 1999-02-22 2000-02-22 Card, device, product and product management system
CA002363760A CA2363760A1 (fr) 1999-02-22 2000-02-22 Carte, appareil, produit et systeme de gestion de produits
BR0008421-2A BR0008421A (pt) 1999-02-22 2000-02-22 Sistemas e processos para a administração de cartões, dispositivos e produtos

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AUPP8822 1999-02-22
AUPP8822A AUPP882299A0 (en) 1999-02-22 1999-02-22 Card management system
AUPQ3019 1999-09-22
AUPQ3019A AUPQ301999A0 (en) 1999-09-22 1999-09-22 Card, device, product and product management system

Publications (1)

Publication Number Publication Date
WO2000051070A1 true WO2000051070A1 (fr) 2000-08-31

Family

ID=25645998

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2000/000123 WO2000051070A1 (fr) 1999-02-22 2000-02-22 Carte, appareil, produit et système de gestion de produits

Country Status (8)

Country Link
EP (1) EP1155382A4 (fr)
JP (1) JP2002538529A (fr)
CN (1) CN1346477A (fr)
BR (1) BR0008421A (fr)
CA (1) CA2363760A1 (fr)
IL (1) IL145031A0 (fr)
NZ (1) NZ513659A (fr)
WO (1) WO2000051070A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7874492B2 (en) 2001-12-04 2011-01-25 Visa U.S.A. Inc. Method and system for facilitating memory and application management on a secured token
US8548923B2 (en) 2002-10-07 2013-10-01 Sonia Reed Method and system for facilitating data access and management on a secure token

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5276311A (en) * 1989-03-01 1994-01-04 Hartmut Hennige Method and device for simplifying the use of a plurality of credit cards, or the like
WO1996025724A1 (fr) * 1995-02-17 1996-08-22 Europay International S.A. Systeme de gestion de transactions commande par circuit integre
AU1790495A (en) * 1995-05-08 1996-11-21 Helmut Dr. Rieder Special multifunctional applications for contact and/or contactless data transmission systems via microprocessor card for the purpose of execution of air travelling formalities and personal identification
US5578808A (en) * 1993-12-22 1996-11-26 Datamark Services, Inc. Data card that can be used for transactions involving separate card issuers
WO1996038804A1 (fr) * 1995-05-30 1996-12-05 Syseca S.A. Lecteur pour carte a puce intelligente
US5812668A (en) * 1996-06-17 1998-09-22 Verifone, Inc. System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5276311A (en) * 1989-03-01 1994-01-04 Hartmut Hennige Method and device for simplifying the use of a plurality of credit cards, or the like
US5578808A (en) * 1993-12-22 1996-11-26 Datamark Services, Inc. Data card that can be used for transactions involving separate card issuers
WO1996025724A1 (fr) * 1995-02-17 1996-08-22 Europay International S.A. Systeme de gestion de transactions commande par circuit integre
AU1790495A (en) * 1995-05-08 1996-11-21 Helmut Dr. Rieder Special multifunctional applications for contact and/or contactless data transmission systems via microprocessor card for the purpose of execution of air travelling formalities and personal identification
WO1996038804A1 (fr) * 1995-05-30 1996-12-05 Syseca S.A. Lecteur pour carte a puce intelligente
US5812668A (en) * 1996-06-17 1998-09-22 Verifone, Inc. System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CLARKE R: "ELECTRONIC PAYMENT MECHANISMS", XP002909680, Retrieved from the Internet <URL:HTTP://WWW.ANU.EDU.AU/PEOPLE/ROGER.CLARKE/EC/EPM> [retrieved on 19950101] *
See also references of EP1155382A4 *
STEPHEN B. WEINTEIN.: "Technology and market trends; A perspective on financial industry networking", JOURNAL OF TELECOMMUNICATIONS NETWORKS,, 1982, pages 317 - 332, XP000812937 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7874492B2 (en) 2001-12-04 2011-01-25 Visa U.S.A. Inc. Method and system for facilitating memory and application management on a secured token
US8548923B2 (en) 2002-10-07 2013-10-01 Sonia Reed Method and system for facilitating data access and management on a secure token
US9430666B2 (en) 2002-10-07 2016-08-30 Visa International Service Association Method and system for facilitating data access and management on a secure token

Also Published As

Publication number Publication date
BR0008421A (pt) 2002-01-29
CA2363760A1 (fr) 2000-08-31
IL145031A0 (en) 2002-06-30
EP1155382A1 (fr) 2001-11-21
JP2002538529A (ja) 2002-11-12
NZ513659A (en) 2003-08-29
EP1155382A4 (fr) 2002-09-11
CN1346477A (zh) 2002-04-24

Similar Documents

Publication Publication Date Title
CA2345391C (fr) Structure de fichiers fidelite pour carte a puce
US7200578B2 (en) Method and system for anonymizing purchase data
US8626577B2 (en) Network centric loyalty system
JP4565703B2 (ja) データ記憶装置およびデータ記憶方法
US20030191709A1 (en) Distributed payment and loyalty processing for retail and vending
CN101542540A (zh) 运输费用的移动支付
CN101263524A (zh) 建立控制子账户的规则的系统和方法
JP2001514402A (ja) 多重機能カードシステム
JP2002157491A (ja) 特典サービスシステム、それに用いられる記録媒体及び特典サービス方法
CN102150398A (zh) 用于在安全网络上提供另一安全网络的系统和方法
US20240232860A9 (en) Method and System for Transferring a Digital Asset and for Managing a Digital Wallet Application
US20140012723A1 (en) Method of and system for managing an asset
JP2002109237A (ja) カード取引用ｉｃカード
WO2000051070A1 (fr) Carte, appareil, produit et système de gestion de produits
AU777610B2 (en) Card, device, product and product management system
KR102286045B1 (ko) 블록체인 기반의 택배 가상 화폐 운영 시스템 및 가상 화폐의 채굴 방법
ZA200106905B (en) Card, device, product and product management system.
KR100831733B1 (ko) 무선 통신망에서의 로열티 포인트 운영 장치 및 로열티 어플리케이션 탑재방법
KR101162928B1 (ko) 매개시스템을 이용한 거래 및 카드결제 시스템 및 방법
JPWO2020027269A1 (ja) 送金方法、システムおよびプログラム
EP2671197A1 (fr) Procédé et système permettant de gérer un actif
KR20060005052A (ko) 현금 영수증을 통한 광고/이벤트 시스템(bm)
KR20030097159A (ko) 전자 상거래용 단말기

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 00805947.0

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref document number: 2001/06905

Country of ref document: ZA

Ref document number: 145031

Country of ref document: IL

Ref document number: 200106905

Country of ref document: ZA

ENP Entry into the national phase

Ref document number: 2000 601601

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 513659

Country of ref document: NZ

Ref document number: 2000906060

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: IN/PCT/2001/00749/DE

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 27848/00

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2363760

Country of ref document: CA

Ref document number: 2363760

Country of ref document: CA

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2000906060

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 09914148

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 27848/00

Country of ref document: AU

WWW Wipo information: withdrawn in national office

Ref document number: 2000906060

Country of ref document: EP