ZA200106905B - Card, device, product and product management system. - Google Patents

Description

© WO 00/51070 1 - PCT/AU00/00123 of CARD, DEVICE, PRODUCT AND PRODUCT MANAGEMENT SYSTEM

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.

By “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.

By “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”).

The use of apparatus such as cards and/or devices for facilitating product transactions is ubiquitous. Note that by the term “product” we mean the application that the card and/or device associated with the product is arranged to facilitate. There are a large number of such products and a potential for many more. They include (but are not limited to): 1. Payment products - e.g. credit, charge, debit, stored value, purchasing, payphone, calling, and account billing products. 2. Loyalty products - e.g., airline frequent flier, product coupon, retailer discount and customer frequency products.

3. Identification products - e.g., license, mo,’ \ * passport and electronic signature products. 9. Access products - e.g., building, computer, mobile phone, device and security access products. 5. Insurance products - e.g., health, motor vehicle and general insurance products. 6. Information products - e.g., medical, health, personal, computer, motor vehicle service and portable ) information file products. 7. Transport ticketing products - e.g., airline ticket and boarding pass, rapid transit ticketing, car park, parking meter and toll road transport products.

These products are often but not exclusively card based.

The management of card- and/or device-related products, as well as the associated message data, is complex. . Any product. usually requires the involvement of a . number of different .participants. In .a credit card product, for example, the participants involved will usually include the following: 1. 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): 2. 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. 3. 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). Note that 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). 4. Card Accepter. This is usually the participant a 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.

In addition to the above, particularly in the case of credit cards, 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. Examples of 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”).

In a credit card system, 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). In some cases, "15 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.

Other types of products than credit cards may include ) variations on the above, but they will be substantially similar. For loyalty programs, for example, a bureau may : be involved for the calculation of loyalty points. - Management of such products and the relationships between the participants involved is complex. 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. For example, the management system(s) must be able to: 1. make decisions and conduct processes based on product transaction content; 2. route product transactions to and from devices and other participants: 3. obtain and maintain information on card holders, card accepters and other participants; 4. support cryptographic processing (messages may be encrypted).

The implementation of any product may necessarily involve negotiations between various entities involved to decide on the product operating parameters and data that. will be required. A management system(s) will then be designed to operate the product, including devices and processing systems for processing the necessary product transactions and other data. Such dedicated systems do not easily lend themselves to alteration or adaptation to facilitate operation of additional or other products.

For example, 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 thé American Express/Bmerican

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 re- establish 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 re- establish the device.

The presently available management systems limit the extent by which cards associated with different products can be implemented (multi-product cards). Likewise, the presently available management systems also limit the extent to which devices supporting different products can be established (multi-product devices). The more products that there are associated with a card and/or device, the

‘ ‘ more negotiation is required between the different ‘ participants and the more complex the management system(s) required. One of the major benefits of smart cards which is often touted is their ability to support many different 5s 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. . For example, where 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). To enable the loyalty product the primary participants provide further separate processing. For example, 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. As well as transactions associated with the credit card product, 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). In the present systems : therefore, 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.

In such a system there is no real control of the loyalty product by the loyalty product manager. Further, there is no product as such on the card or device. The card and device system have been constructed to support the primary product (e.g. the credit card product) and operation of the further product is done “behind the scenes”. There is no information in the transaction for the loyalty product manager. Separate “batch processing” must be provided by the transaction acquirer.

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”). In the case of a single role environment, the card issuer is also the transaction acquirer. In the case of a dual role environment, the card issuer and transaction acquirer may be separate. It should be noted that there might be multiple participants carrying out a particular s role (i.e., multiple card issuers and multiple transaction acquirers within a dual role environment).

Where a further product is involved being managed by a separate product manager participant, such as described above, 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 1S 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- ) _ 20 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). As some of the previous functions 350 of the card issuer may be transferred to the product owner, the applicants have re-named the previous card issuer role as “card manager”. Likewise, as some of the previous functions of the transaction acquirer may be transferred to the product owner, the applicants have re-named the 35 previous transaction acquirer role as “device manager” .

Note that 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, however, 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.

Similarly, a “device” is anything capable of representing a relationship between a device manager (transaction acquirer) and a card acceptor (merchant). It

} x may be a “virtual” device accessible via a Web page on the

Internet, for example.

The addition of a product owner role to the single or dual environment, preferably creates a “tripartite environment”, where there may be three roles required to facilitate the management of card and/or device-associated products: 1. the management of cards being carried out by the card manager. 2. The management of devices, being carried out by the device manager. 3. The management of a product being carried out by the product owner.

Note that all these roles may in some circumstances be carried out by the same participant, i.e. operating each of the device management means, product management means and card management means. - 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. In a preferred embodiment, the message management means includes a software module which can control a processing means to control the routing of message data. Note that by message data is meant any data including transaction data, that needs to be routed within the system. Preferably, each participant in the system is provided with a message management module. For example, where the card manager, product owner and device manager are separate entities, 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.

Preferably, the device management means include storage means for storing product owner identification s 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.

Preferably, 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.

Preferably, the card management means is arranged to store product owner identification data identifying product owner participants respensible 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.

Preferably, each of the management means also stores links to the management means of other participants.

In each management means, a database may store the required data.

Note that in each case identification data may not be the actual identity of the entity. For example, 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.

Usually, it will be required that the card managers have an actual identity of the card holder and that the } device managers have an actual identity of the card acceptor. Other than this, actual identities do not necessarily need to be provided to any other participant.

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 d 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 ary 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 be loaded by the card acceptor and cardholder at any time.

To manage the cardholder (referred to by the product owner as the “product-holder”) relationship, data such as the identity of the cardholder 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 be enough for the product owner to receive transaction data indicating that there is a card holder."

Again, 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. : :

To manage the card accepter (referred to by the product owner as the “product accepter”) relationship, 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.

Again, 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 in 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. Their product management system would only need to be able to manage the information required to 10. manage the loyalty scheme, not the broader aspects of card . and/or device management unrelated to their loyalty scheme. - These other aspects of card and device management will be conducted by card manager and device managers that agree to support the restaurant chain’s product.

IS Preferably, the card management means manages aspects of the card-related environment that are associated with the card manager. The card manager management system(s) 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.

Preferably 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.

With the management system(s) of the present invention, therefore, an entity that wishes to be involved in any one aspect of the tripartite card environment conceived by the applicant (product management, card management and device management) will require only the appropriate part of the system which relates to management of the aspect of the environment that they are responsible for, together with the message management means, enabling communications between the management systems of different entities in a tripartite environment.

The product owner, for example, 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. In the prior art systems discussed in the preamble where a third party operates a product such as a loyalty scheme as a secondary product receiving data from a systém which has been designed to operate a primary ts 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.

In the present invention, the product owner is preferably able to affect control over the product. For example, where 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.

Further, with a management system in accordance with the present invention, the replacement of cards and devices that have been lost, stolen, damaged, destroyed, - re— assigned or the like becomes much simpler. 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 perscnal 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.

Customer service is also facilitated by the system of the present invention. The cardholder may need only a single contact (usually the card manager) if a product is not operating to satisfaction. A cardholder complains to the card manager who may be able to process the complaint themselves or who will be able to pass it on straight away to the product owner (or other relevant party) via the management system. The cardholder does not require multiple contacts corresponding to each one of the multiple . 35 products.

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 oo 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.

By “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 owners. 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 ) 200 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

© WO 00/51070 - 21 - PCT/AU00/00123 ” 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.

Preferably, 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. oo 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.

Note that the 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. . Features and advantages of the present invention will become apparent from the following description of an embodiment thereof, by way of example only, with reference to the accompanying drawings, in which: 2 Fig. 1 is a schematic diagram of a present card- related environment; - 20 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, and : 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.

Traditionally, 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.

Referring to figure 2, a modified environment is shown which is facilitated by the card management system in a preferred embodiment of the present invention. In addition

. to the card manager 1 (the renamed card issuer) and device manager 4 (renamed transaction acquirer), there is a further entity, product owner’ 7. 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 z 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 MULTQOS card platform, support an - interface to a legacy database system, support transaction Bh 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 (the service modules) include relational databases and processing means to provide the following:

Product Management Module 1. Provide products for card holders {Card holder product to Product owner) and Card Acceptors (in the form of a Card

Acceptor product to a Product Acceptor). 2. Establishment of products within Card Manager/Device

Manager constraints. 3. Process product transactions. 4. management of relationships with suppliers, Card holders/Card acceptors and Card Managers/Device managers. 5. Supports management of product life cycle (including product data and applications) and the management of supported device/card relationships per Product (including the relationships with Card Managers and Device Managers). 6. Manage card products and related information. 7. Product specifications. Specifies card and device applications, compatible card and device platforms,

required memory of cards/devices, parameters and data requirements. 8. Product relationships e.g. relationships between different products. 9. Product parameters/configuration. ‘ 10. Primary product certificates, cryptography. 11. Card Manager and Device Manager information. Multiple card managers and device managers may support product. 12. Links to or data from the card management module for card holders using the product. 13. Device management links. Links to or data from the device management module for card acceptors supporting the product. 14. Transaction data may be required to be mirrored for reconstruction. 15. Card/device application. 16. Application provision. Dynamic downloading of applications to cards.

Device Management Module 1. Establish and manage devices used by card acceptors. 2. Establishment of devices at card acceptor locations. - 3. Deployment of products from product owners. . 4. Management of relationships with suppliers, card acceptors and product owners. 5. Ordering of devices from vendors. 6. Maintenance and management of device inventories and devices installed (including data & applications on devices). 7. Management of supported product relationships per device (including the relationships with the product owners). 8. 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. 10. Primary device certificates, keys - cryptography. 11. Device product applications, links. Product applications may be managed by the transaction processor but for device reconstruction processes at least links are maintained. 12. Card acceptor data e.g. conduct details, full title, demographic information, etc. 13. Card acceptor/Device relationships. Multiple device may be linked to same card acceptor. 14. Card acceptor establishment e.g. through manual data entry, electronic file import. Tr 15. Card acceptor communications. Statements, etc. 16. Application distribution. Keep track and distribute applications to devices and card applications to be distributed to smart cards. 17. Device utilisation provides device manager with tools to specify the data to be included on the device. 18. Device update reconfiguration update and reconfigure device. 19. General device/card acceptor management. Fees, management, reports.

Card Management Module 1. Issue and manage cards used by card holders. 2. Issuing of cards to card holders (including re- issuing/reconstruction) 3. Deployment of products from product owners. 4. Management of relationships with Suppliers, Card holders and Product owners. 5. Ordering of cards from vendors. 6. Management of card stock and cards issued (including data and applications on card)

oT.

Management of supported product relationships per card (including the relationships with the product owner). 8. 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. 9. 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). 10. Card specification data, card platform issued, memory capacity, types of memory, for capacity of applications.

11. 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. ~ 12. Personalisation data for card production/reconstruction processes specifies the card . holder data provided on the card, which may be number of cardholder data.

13. Primary card certificates/keys (cryptography)

14. Card product applications/links - maintains links to product manager to enable reconstruction of card.

15. Card holder establishment, through manual data entry, electronic file import, etc.

16. Card holder communications e.g. event dates/time dates such as card issuance.

17. Card production/issuance provides tools for card manager to specify data to be included on cards and provide for unique ID of card.

18. 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. 19. General card management. Card/card holder requirement (determining reports, etc) participants related requirements (fees payable, renewable).

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. 2. Captures formatting, routing and logging of transactions/messages. 3. Sending and receiving of transactions/messages within and between the connected management systems as well as g external systems devices and cards. 4, Cryptographic processing of data, including authentication. : 5. Logging of billable events and support for activity based and generic fees. 6. Production of standard and ad hoc reports. 7. Administration of systems, including installation, configurations, access control, monitoring, recovering and archiving. 8. Compliance with generally accepted standards, performance and operational criteria, including localisation of implementation. 9. Manage and route messages to/from interconnected systems, devices and cards. 10. Manage communications to/from individuals and organisations (e.g. customer inquiries, letters). 11. Produce information representing fees. 12. 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. ) 13. Support appropriate access control, physical security and cryptographic processing (e.g. authentication, -5 encryption). 14. Record and review the current and historical state of the system (e.g. for audit purposes). 15. Convert from transaction format to the internal transaction format of the service module or external system. 16. Capturing transactions and writing them to a log sheet . for reconciliation, auditing, etc. 17. 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

N possible to ensure highest data privacy possible. . For a particular operator of the management system in accordance with the present invention, they may have one, two or all of the three management modules 11, 12, 13, : depending upon their function as an entity in the environment. Referring to figure 4, for example, 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, whilst 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. For example, 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.

In operation, 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 wu message management module 20, card management module 21, on device management module 22 and product management module

Bs 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 i 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¢ and a loyalty system application 31. The loyalty system application 31 is an application designed specifically for 30 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. After processing by the business management module b 25, 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

I5 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.

Figure 6 illustrates the transaction flow for a compound transaction. The steps involved are described in detail below. 1. During an interaction between smart card 40 and device 41, multiple applications generate a compound transaction. 2. Periodically the device dials into the Device

Management 42 to upload all transactions, which are logged by the Message Management module 43 of the Device

Management 42. 3. 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.

4. 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. 5. 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: 1. Multiple applications operating concurrently may generate an atomic transaction each, such that no compound transactions occur. 2. 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. 2. 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. 3. 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 cardapplication 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. : 5. The Card Management module 52 generates a : personalisation file with all the assimilated applications o 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: 1. 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: . 1. During the interaction between smart card 60 and + device 61, the device offers the smart card 60 an application that is not resident on the smart card 60. (a) 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. 3. The device dials into the Device Management 62 of the management system of the present invention. 4. The Device Management 62 sends an application request to the Product Management 63. (a) Should the smart card 60 and device 61 not be able to ascertain the legality of the application on the smart card 60, 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.

S. The Product Management 63 provides the requested application to the Device Management 62. 6. The Device Management 62 provides the requested : application to the device 61. s 7. The device 61 discontinues the on-line link to the

Device Management 62 and provides the smart card 60 with the requested application. 8. The smart card 60 installs the application in its memory. 9. 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 ¢ Card Management 64 e¢ Product Management 63 e both

The Dynamic Application Load 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.

Note that the device management 62, product management 63 and card management 64 may belong to the same entity or separate entities.

Variations

Other possibilities for application loads to smart cards are: 1. 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.

2. 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: - (a) provide all the devices managed by the Device

Management with the application upon request, e.g. when the smart cards are next on-line; (b) provide all the devices managed by the Device

Management with the application the next time the devices are on-line, such that the application loading may be ~ facilitated off-line when the smart cards interact with the . devices. . 3. The Card Management instructs the Device Management to load applications onto a range of smart cards either: (a) the next time the smart cards are on-line for a transaction; - (b) by pre-loading the application onto devices for off-line application loading.

Other possibilities for application loads to devices are: 1. The device requests on-line that an application be ] loaded, e.g. to process a transaction with a smart card a» 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. 2. 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. 3. 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 steps of the transaction flow to facilitate application unloading from smart cards may be described as follows: 1. 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, (a) the next time the device 71 in on-line for a transaction with one of the smart cards 70 within the : . range; (b)broadcast the request to the devices 71 the next - time the devices 71 are on-line for an interaction with the

Device Management 73 such that the unload request may be communicated to the smart card 70 off-line during a transaction interaction (this mode may be necessary if the

Card Management 71 discontinues the support of the application or a cardholder abuses the application). 2. During the interaction between smart card 70 and devices 71. (a) and the device has to dial-in to the Device

Management 73 to complete the transaction, 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. 3. 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,

B 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: 1. 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. 2. The smart card may delete the application from its memory after a single use of the application, e.g. single use coupons. 3. 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. 4. 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.

For example, 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.

It will be appreciated by persons skilled in the art ~ that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the -spirit or scope of the invention as broadly described. The present embodiments are, . therefore, to be considered in all respects as illustrative and not restrictive.

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS: 1. 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, -15 whereby all three roles can be performed by separate entities. 2. A system in accordance with claim 1, further £] comprising a message management means arranged to manage . the routing of message data between cards, devices and a ) card, device and product management system. 3. A system in accordance with claim 2, wherein the - message management means is also arranged to act as a sc communication’s interface routing message data between the card management means, device management means and product management means. 4. A system in accordance with claim 2 or claim 3, the message management means also being arranged to manage the routing of message data to external systems. 5. A system in accordance with any one of claims 2 30. to 4, wherein each one of the card management means, device management means and product management means is provided with an associated message management means. 6. A system in accordance with any one of the preceding claims, wherein the system is arranged so that the product management means is arranged to facilitate the product owner participant to directly affect control of a

Claims (1)

1. product associated with a card or device, without intervention of any of the other participants.

   7. A system in accordance with claim 6, wherein the control of the product involves loading data to the product.

   8. A system in accordance with claim 6 or claim 7, wherein the control involves the product management means receiving data from the product via the system.

   9. A system in accordance with claim 8, wherein the data is transaction data.

   10. A system in accordance with any one of claims 6 : to 9, wherein the control involves the product management means downloading product applications directly to a card or device. To 1s 11. A system in accordance with any one of claims 6 to 10, wherein the system is arranged so that data associated with the product and provided to the product management means or to the card or device from the product management means may be routed via the message management means of other entities participating in the system.

   12. A system in accordance with any one of the preceding claims, wherein 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.

   13. A system in accordance with any one of the preceding claims, wherein the device management means is arranged to store product owner identification data, identifying product owner participants responsible for managing products associated with devices managed by the device manager participant, and card accepter identification data, identifying card accepters using devices managed by the device manager participant.

   14. A system in accordance with any one of the preceding claims, wherein the product management means is arranged to store card manager identification data identifying card managers managing cards supporting : products managed by the product owner participant.

   15. 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.

   16. A system in accordance with claim 15, wherein the control of the product involves loading data to the . | product.

   17. A system in accordance with claim 15 or claim 16, wherein the control involves the product management means receiving data from the product.

   18. A system in accordance with claim 17, wherein the ; data is transaction data.

   19. A system in accordance with any one of claims 15, 16 or 17, wherein the control involves the product management means downloading product applications to a card - or device. Jn 20. A system in accordance with any one of claims 15 to 20, wherein the product management means is arranged to store card manager identification data identifying card managers managing cards supporting products managed by the product owner participant. : 21. 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.

   22. A card management system in accordance with claim 19, wherein 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.

   23. 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.

   24. A device management system in accordance with claim 21, wherein the device management means is arranged to store product owner identification data, identifying product owner participants responsible for managing products associated with devices managed by the device manager participant, and card accepter identification data, identifying card accepters using devices managed by the device manager. participant: Co oC

   25. A card, device and product management system, - including a plurality of service processing means, each us 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.

   26. 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.

   27. A system in accordance with claim 26, wherein the service processing means includes 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.

   28. A system in accordance with claim 26 or claim 27, . the service processing means 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.

   29. A system in accordance with any one of claims 26, : 27 or 28, wherein the service processing means includes a product management means which enables a product owner participant to perform a product management role alone, without managing cards and without managing devices.

   30. 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 participants, 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.

   31. A method in accordance with claim 30, comprising the further step of providing a computer system including modules enabling each of the card manager participant, device manager participant and product manager participant roles to be carried out separately from each other.

   32. A method in accordance with claim 30 or claim 31, comprising the step of enabling the system to facilitate the product manager participant to have direct access to a product in order to directly affect control of a product associated with a card or device.

   33. A method in accordance with claim 30, comprising the step of enabling the product owner participant to load data onto the product.

   34. A method in accordance with claim 32 or claim 33, comprising the step of enabling the product owner participant to receive data from the product. : 35. A method in accordance with claim 34, wherein the data is transaction data.

   36. A method in accordance with any one of claims 32 to 35, comprising the step of the product owner participant downloading a product application to a card or device.

   37. 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 providing i. the facility for the product manager participant to : pa directly affect control of a product associated with a card or device.

   38. A method in accordance with claim 37, including the step of providing the facility to enable the product owner participant to load data to the product.

   39. A method in accordance with claim 37 or claim 38, ” including the step of providing the facility to enable the product manager participant to receive data from the product on the card or device.

   40. A method in accordance with claim 39, wherein the data is transaction data.

   41. A method in accordance with any one of claims 37 to 40, including the step of providing the facility to enable the product owner participant to download product applications to a card or device.

   42. 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.

   ' 43. 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.

   44. 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.

   45. A system in accordance with claim 44, further comprising a message management module arranged to act as a communications interface to manage the routing of message data between cards, devices, products, card management modules, product management modules and device management . modules and wherein each participant in the generic system utilises a message management module.

   46. A card, device and product arrangement, including a computing system having memory locations for receiving a ) plurality of product applications, and security means enabling selective access to the memory locations for a plurality of product owners, whereby the product owners may separately access and manage their products stored at the memory locations.

   47. A card, device and product arrangement in accordance with claim 46, wherein the memory locations are provided mounted on cards.

   48. A card, device and product arrangement in accordance with claim 47 or claim 48, wherein the memory locations are provided mounted on the devices.

   49. A card device and product arrangement in accordance with claim 46, 47 or 48, wherein the security means comprises tokens operating as keys to enable access to the memory locations.

   * 50. A card, device and product arrangement in accordance with any one of claims 46 to 49, including a product management system in accordance with any one of claims 15 to 20 to enable management of product by a product owner.

   51. A card, device and product arrangement in accordance with any one of claims 46 to 49, including a card, device and product management system in accordance with any one of claims 1 to 15, to enable management of the arrangement.