EP1103140A4

EP1103140A4 - Point of sale activation and deactivation of pre-paid telephone calling cards

Info

Publication number: EP1103140A4
Application number: EP99942644A
Authority: EP
Inventors: James Duke Bond; Karl Henderson; Kamran Mir; Frank Wu
Original assignee: MCI Worldcom Inc
Current assignee: Verizon Business Global LLC
Priority date: 1998-06-03
Filing date: 1999-06-02
Publication date: 2003-02-26
Also published as: EP1103140A1; WO1999063744A1; JP2002517957A; CA2334405A1

Abstract

System (100) includes a PSTN (102), POS devices (credit card terminals, etc.) (104), additional POS (106) which are configured with dial up facilities, POS control system (105), switching control points (108), a customer service center (110), a service data point (112) (central data stores for card state and usage data), a WAN system (114), a ANI server (116), and a WAN access switch (118). During a point-of-sale transaction, the POS system transmits a request related to the pre-paid calling card via the communication network to the processing system. The processing system coupled to the service data point performs a transaction in accordance with the transaction request and transmits a status response message back to the point-of-sale system indicating whether the transaction was performed in accordance with the transaction request.

Description

POINT OF SALE ACTIVATION AND DEACTIVATION OF PRE-PAID TELEPHONE CALLING CARDS

The present invention relates to systems and methods that are used to activate and deactivate prepaid telephone calling cards.

It is well known that pre-paid telephone calling cards have become widely used to obtain telephone services. For example, consumers can purchase pre-paid telephone calling cards from retail stores and use the same to obtain access to telephone services to call friends and family all over the world. As such, many different kinds of pre-paid telephone calling cards are now available. Consumers can purchase pre-paid telephone calling cards having a variety of calling options (domestic calling options, international calling options, etc.) and a wide selection of pre-paid values. For example, consumers can purchase domestic-use calling cards that are charged with 100 call units (i.e., a unit is typically equal to one minute, but may be associated with some other amount of time e.g., 50 seconds, etc.).

The appeal of pre-paid telephone calling cards to consumers is due in large part to the fact that pre-paid telephone calling cards often allow consumers to realize savings associated with making telephone calls. In fact, pre-paid telephone calling cards often allow consumers to avoid the costs associated with using a conventional telephone calling card that is associated with a conventional telephone line (e.g., an access call service charge that is added to other call usage charges) . Additionally, pre-paid telephone calling cards often are coupled to additional services and features (e.g., stock quote services, etc.) that otherwise may not be available through conventional telephone line subscription services.

In addition to their appeal to consumers, many retailers have begun to offer and sell pre-paid telephone calling cards. Since a relatively large selection of pre-paid telephone calling cards can be stocked and displayed without requiring significant retail floor space, retailers can enjoy maximized revenues relative to small sections of their leased or owned storefronts.

Despite their benefits, however, pre-paid telephone calling cards are not without their problems. For example, pre-paid telephone calling cards often are immediately active and usable once displayed for retail sale. As pre-paid telephone calling cards reside on a store shelf they are susceptible to theft and fraudulent use by consumers and store employees. To combat this problem, distributors of pre-paid telephone calling cards have incurred extra packaging costs for packaging an otherwise unusable plastic card. Additionally, retailers often have to keep active cards under lock and key and distribute them as sales are made. These problems present management problems for retailers in addition to not adequately addressing employee pilferage.

Thus, there exists a need to provide systems and methods that address the aforementioned problems associated with retail sales of pre-paid telephone calling cards. To be viable, such systems and methods must allow pre-paid telephone calling cards to be activated and deactivated at a point-of-sale within a retail establishment. The present invention solves the problems associated with prior pre-paid telephone calling cards. That is, the present invention provides systems and methods that allow otherwise unusable pre-paid telephone calling cards to be displayed for retail sale without concern for fraudulent use, theft, and employee pilferage. In providing such systems and methods, retailers can now safely stock varieties of pre-paid telephone calling cards without realizing additional management burdens associated with pre-paid telephone calling card stock security.

Consumers also will benefit from pre-paid telephone calling cards that may be activated and deactivated at a point-of-sale. For example, consumers will be able to re-charge spent calling cards by returning to a retailer who may engage in a card recharge operation at a point-of-sale. Additionally, consumers can now return partially unused cards for refunds and other credits by returning to a retailer and presenting a pre-paid telephone calling card at a point-of-sale.

The present invention provides the aforementioned benefits by providing a system for processing a pre-paid telephone calling card during a point-of-sale transaction that includes a point-of-sale system that is operative to receive a transaction request related to a pre-paid telephone calling card during a point-of-sale transaction and to transmit that transaction request to a pre-paid telephone calling card processing system. The pre-paid telephone calling card processing system is coupled to the point-of-sale system and is operative to receive the transaction request, to perform a transaction in accordance with the transaction request, and to transmit a status response message to the point-of-sale system. The status response message indicates whether the transaction was performed in accordance with the transaction request.

According to another aspect of the present invention, provided is a method for processing a prepaid telephone calling card during a point-of-sale transaction. The method includes the steps of receiving a transaction request relative to a pre-paid telephone calling card at a point-of-sale system, transmitting the transaction request, receiving the transaction request at a pre-paid telephone card processing system, performing a transaction in accordance with the transaction request, and transmitting a status response message to the point-of- sale system. The status response message indicates whether the transaction was performed in accordance with the transaction request. According to another aspect of the present invention, provided is a system for processing a prepaid telephone calling card during a point-of-sale transaction that includes a data storage system for storing state data related to a pre-paid telephone calling card and a pre-paid telephone calling card processing system coupled to the data storage system. The pre-paid telephone calling card processing system is configured to receive a transaction request related to the pre-paid telephone calling card during a point - of -sale transaction, to perform a transaction in accordance with the transaction request, and to change the state data stored within the data storage system based on the transaction. According to another aspect of the present invention, provided is a method for processing a prepaid telephone calling card during a point-of-sale transaction. The method includes the steps of storing state data related to a pre-paid telephone calling card, receiving a transaction request related to the pre-paid telephone calling card during a point-of-sale transaction, performing a transaction in accordance with the transaction request, and changing the state data stored within the data storage system based on the transaction.

The present invention is described in detail below with reference to the following drawing figures of which: FIG. 1 is a block diagram of a system in which pre-paid telephone calling cards may be activated within a point-of-sale system according to a preferred embodiment of the present invention;

FIGS. 2A and 2B are state diagrams that illustrate the states which a pre-paid telephone calling card may possess in accordance with the present invention. Fig. 2A relates to a particular, individual card, while Fig. 2B relates to a batch of cards.

FIG. 3 is a table that illustrates a standard transaction request message format deployed in accordance with a preferred embodiment of the present invention to enable an activation- related message to be communicated via a host-to-host connection from a point-of-sale system to a card service provider; FIG. 4 is a table that illustrates a standard transaction response message format deployed in accordance with a preferred embodiment of the present invention to enable an activation- related message to be communicated via a host-to-host connection from a card service provider to a point-of-sale system;

FIG. 5 is a table that illustrates a standard message format deployed in accordance with a preferred embodiment of the present invention to enable activation- related messages to be communicated via an automated dial-up connection from point-of-sale system to a card service provider;

FIG. 6 is a table that illustrates a standard message format deployed in accordance with a preferred embodiment of the present invention to enable activation-related messages to be communicated via an automated dial-up connection from a card service provider to a point-of-sale system; FIG. 7 is a message- flow diagram for PIN activation via host to-host communications;

FIG. 8 is a message- flow diagram for PIN activation failure conditions via host-to-host communications ; FIG. 9 is a message- flow diagram for PIN deactivation via host -to-host communications;

FIG. 10 is a message- flow diagram for PIN deactivation failure conditions via host-to-host communications ; FIG. 11 is a message- flow diagram for PIN charge via host-to-host communications;

FIG. 12 is a message- flow diagram for PIN charge failure conditions via host-to-host communications ; FIG. 13 is a message- flow diagram for PIN refresh via host -to -host communications; FIG. 14 is a message- flow diagram for PIN refresh failure condition via host-to-host communications;

FIG. 15 is a message- flow diagram for PIN refund via host -to-host communications;

FIG. 16 is a message- flow diagram for PIN refund failure conditions via host-to-host communications ;

FIG. 17 is a message- flow diagram for echo transaction request via host-to-host communications;

FIG. 18 is a message- flow diagram for echo transaction request failure conditions via host-to-host communications ;

FIG. 19 is a message- flow diagram for PIN activation via automated dial-up communications;

FIG. 20 is a message- flow diagram for PIN activation failure conditions via automatic dial-up communications;

FIG. 21 is a message-flow diagram for PIN deactivation via automated dial-up communications;

FIG. 22 is a message- flow diagram for PIN deactivation failure conditions via automated dial-up communications ;

FIG. 23 is a message- flow diagram for PIN charge via automated dial-up communications;

FIG. 24 is a message- flow diagram for PIN charge failure conditions via automated dial-up communications;

FIG. 25 is a message-flow diagram for PIN refresh via automated dial-up communications;

FIG. 26 is a message- flow diagram for PIN refresh failure conditions via automated dial-up communications ; FIG. 27 is a message- flow diagram for PIN refund via automated dial-up communications;

FIG. 28 is a message- flow diagram for Pin refund failure conditions via automated dial-up communications;

FIG. 29 is a message- flow diagram for echo transaction request via automated dial-up communications;

FIG. 30 is a message- flow diagram for echo transaction request failure conditions via automated dial-up communications;

FIG. 31 is a data-flow diagram for authorization validation via DTMF communications;

FIG. 32 is a data-flow diagram for authorization validation failure via DTMF communications;

FIG. 33 is a data-flow diagram for featured PIN transactions via DTMF communications;

FIG. 34 is a data-flow diagram for general batch transactions via DTMF communications;

FIG. 35 is a data-flow diagram for multiple PIN activation via DTMF communications;

FIG. 36 is a data-flow diagram for non- existing PIN processing via DTMF communications; FIG. 37 is a data-flow diagram for attempted activation of locked PINs via DTMF communications;

FIG. 38 is a data-flow diagram for PIN invalid ownership operations via DTMF communications;

FIG. 39 is a data-flow diagram for attempted activation of already used PINs via DTMF communications ; FIG. 40 is a data-flow diagram for attempted activation of already active cards via DTMF communications ;

FIG. 41 is a data-flow diagram for attempted activation of expired cards via DTMF communications;

FIG. 42 is a data-flow diagram for attempted activation of a suspended card via DTMF communication; FIG. 43 is a data-flow diagram illustrating the case where a caller abandons SDP processing via DTMF communications;

FIG. 44 is a data-flow diagram for Range PIN activation via DTMF communications;

FIG. 45 is a data flow-diagram for invalid PTN or PIN range processing via DTMF communications; FIG. 46 is a data-flow diagram for attempted activation of non- existing PINs via DTMF communications ;

FIG. 47 is a data-flow diagram for attempted activation of locked PINs via DTMF communications; FIG. 48 is a data-flow diagram for invalid ownership processing via DTMF communications;

FIG. 49 is a data-flow diagram for attempted activation of already used PINs via DTMF communications ; FIG. 50 is a data-flow diagram for attempted activation of already active cards;

FIG. 51 is a data-flow diagram for attempted activation of expired cards via DTMF communications;

FIG. 52 is a data-flow diagram for attempted activation of already suspended cards via DTMF communications ; FIG. 53 is a data-flow diagram illustrating a case where a caller abandons SDP processing via DTMF communications ;

FIG. 54 is a data-flow diagram for batch activation via DTMF communications;

FIG. 55 is a data-flow diagram for attempted activation of non- existing batches via DTMF communications ;

FIG. 56 is a data-flow diagram for attempted activation of locked batches via DTMF communications;

FIG. 57 is a data-flow diagram for invalid PIN ownership via DTMF communications;

FIG. 58 is a data-flow diagram for attempted activation of already active batches via DTMF communications;

FIG. 59 is a data-flow diagram illustrating the case where a caller abandons batch processing and, in particular, SDP processing via DTMF communications;

FIG. 60 is a data-flow diagram for range batch activation via DTMF communications;

FIG. 61 is a data-flow diagram for invalid batch number or batch range during batch processing via DTMF communications;

FIG. 62 is a data-flow diagram for attempted activation of non-existing PIN batches via DTMF communications ;

FIG. 63 is a data-flow diagram for attempted activation of already locked batches via DTMF communications ; FIG. 64 is a data-flow diagram for invalid

PIN ownership related to batches via DTMF communications ; FIG. 65 is a data-flow diagram for attempted activation to activate already active batches via DTMF communications ;

FIG. 66 is a data-flow diagram illustrating a case where a caller abandons SDP processing during DTMF communications for batch processing;

FIG. 67 is data-flow diagram for multiple PIN deactivation via DTMF communications;

FIG. 68 is a data-flow diagram for attempted deactivation of non-existing PINS;

FIG. 69 is a data-flow diagram for attempted deactivation of locked PINs via DTMF communications;

FIG. 70 is a data-flow diagram for invalid PIN ownership via DTMF communications; FIG. 71 is a data-flow diagram for attempted deactivation of used PINs via DTMF communications;

FIG 72 is a data-flow diagram for attempted activation of an already generated card via DTMF communications; FIG. 73 is a data-flow diagram for attempted deactivation of an already expired card via DTMF communications ;

FIG. 74 is a data-flow diagram for attempted deactivation of a suspended card via DTMF communications;

FIG. 75 is a data-flow diagram illustrating a case where a caller abandons SDP processing during DTMF communications for multiple PIN activation;

FIG. 76 is a data-flow diagram for range PIN deactivation via DTMF communications;

FIG. 77 is a data-flow diagram for invalid PTN or PIN range processing via DTMF communications; FIG. 78 is a data-flow diagram for attempted deactivation of non-existing PINs via DTMF communications;

FIG. 79 is a data-flow diagram for attempted deactivation of locked PINs via DTMF communications;

FIG. 80 is a data-flow diagram for invalid PIN ownership via DTMF communications;

FIG. 81 is a data-flow diagram for attempted deactivation of already used PINs via DTMF communications;

FIG. 82 is a data-flow diagram for attempted deactivation of already generated cards via DTMF communications;

FIG. 83 is a data-flow diagram for attempted deactivation of expired cards via DTMF communications;

FIG. 84 is a data-flow diagram for attempted deactivation of already suspended cards via DTMF communications ;

FIG. 85 is a data-flow diagram illustrating a case where a caller abandons SDP processing during DTMF communications;

FIG. 86 is a data-flow diagram for multiple batch deactivation via DTMF communications;

FIG. 87 is a data-flow diagram for attempted deactivation of non-existing batches via DTMF communications;

FIG. 88 is a data-flow diagram for attempted deactivation of locked batches via DTMF communications;

FIG. 89 is a data-flow diagram for invalid ownership of batch numbers via DTMF communications;

FIG. 90 is a data-flow diagram for attempted deactivation of inactive batches via DTMF communications ; FIG. 91 is a data-flow diagram for attempted deactivation of batches containing active PINs via DTMF communications ;

FIG. 92 is a data-flow diagram illustrating a case where a caller abandons SDP processing via DTMF communications for multiple batch deactivation;

FIG. 93 is a data-flow diagram for range batch deactivation via DTMF communications;

FIG. 94 is a data-flow diagram for invalid number or batch range processing via DTMF communications ;

FIG. 95 is a data-flow diagram for attempted deactivation of non-existing batches via DTMF communications; FIG. 96 is a data-flow diagram for attempted deactivation of locked batches via DTMF communications;

FIG. 97 is a data-flow diagram for invalid ownership processing via DTMF communications;

FIG. 98 is a data-flow diagram for attempted deactivation of inactive batches via DTMF communications ;

FIG. 99 is a data-flow diagram for attempted deactivation of batches containing active PINs via DTMF communications ; FIG. 100 is a data-flow diagram illustrating the case where a caller abandons SDP processing for range batch deactivation via DTMF communications; FIG. 101 is a data-flow diagram for PIN refunds via DTMF communications; FIG. 102 is a data-flow diagram for attempted refund of non-existing PINs via a DTMF communications;

FIG. 103 is a data-flow diagram for attempted refund of a locked PIN via DTMF communications; FIG. 104 is a data-flow diagram for invalid ownership processing via DTMF communications;

FIG. 105 is a data-flow diagram for attempted refund of a generated card via DTMF communications; FIG. 106 is a data-flow diagram for attempted refund of an expired card via DTMF communications;

FIG. 107 is a data-flow diagram for attempted refund of a suspended card via DTMF communications;

FIG. 108 is a data-flow diagram illustrating a case where a refund amount is greater than a maximum dollar amount which is indicated via DTMF communications :

FIG. 109 is a data-flow diagram that illustrates a case where a caller abandons SDP processing during DTMF communications for PIN refunds;

FIG. 110 is a data-flow diagram illustrating a case where a caller abandons PIN refund operations and corresponding SDP processes during PIN refunds via DTMF communications; FIG. Ill A is a flowchart for DTMF activation scenarios;

FIG. 111B is a continuation of the flowchart started in FIG. 111A;

FIG. Ill C is a continuation flowchart of the flowchart started in FIGS. 111A-B;

FIG. HID is a continuation flowchart of a flowchart started in FIGS. 111A-C;

FIG. HIE is a continuation flowchart of the flowchart started in FIGS. 111A-D; FIG. 111F is a continuation flowchart of the flowchart started in FIGS. 111A-E;

FIG. 111G is a continuation flowchart of the flowchart started in FIGS. 111A-F; FIG. 111H is a continuation flowchart of the flowchart started in FIGS. 111A-G;

FIG. 1111 is a continuation flowchart of the flowchart started in FIGS. 111A-H; FIG. 111J is a continuation flowchart of the flowchart started in FIGS. 111A-I;

FIG. 111K is a continuation flowchart of the flowchart started in FIGS. 111A-J;

FIG. 111L is a continuation flowchart of the flowchart started in FIGS. 111A-K;

FIG. HIM is a continuation flowchart of the flowchart started in FIGS. 111A-L:

FIG. 111N is a continuation flowchart of the flowchart started in FIGS. 111A-M; FIG. 1110 is a continuation flowchart of the flowchart started in FIGS. 111A-N;

FIG. HIP is a continuation flowchart of the flowchart started in FIGS. 111A-0;

FIG. 111Q is a continuation flowchart of the flowchart started in FIGS. 111A-P;

FIG. 111R is a continuation flowchart of the flowchart started in FIGS. 111A-Q; and

FIG. HIS is a continuation flowchart of the flowchart started in FIGS. HIA-R.

The present invention is now discussed in detail with reference to the drawing figures that were briefly described above. A system overview is followed by a discussion of the structural aspects of the present invention and a discussion of corresponding message, data, and call flows. Unless otherwise indicated, like parts, systems, and processes are referred to with like reference numerals. SYSTEM OVERVIEW

The present invention is concerned with the activation/deactivation of pre-paid telephone calling cards (cards) within a point-of-sale (POS) system during POS transactions. Typically, a card is a plastic or paper, credit-card like instrument that may have imprinted thereon certain marketing messages, card-usage instructions, access numbers (e.g., 1-800 access telephone numbers, personal identification numbers (PINs) or unique card numbers) , and an indication of telephone usage units (e.g., a number of units corresponding to telephone service timing units) . Additionally, a card may contain some indication of unit cost in units of currency (e.g., dollars in the case of the U.S., or in other units depending on the country of card origin or intended use) .

In the context of the present invention, cards may be displayed for sale by a retailer/reseller in an inactive (otherwise unusable) state. An inactive card is associated with a personal identification (PIN) number or code/unique card number that may be used by a retailer at a POS station during a POS transaction to activate the card and to render it usable by a card purchaser. The PIN number (e.g., a unique card number) is assigned to a card by a card processor and service provider. Activation and other related transactions (deactivation, etc. as described below) occur through a POS system that is coupled to a card processor and service provider (e.g., an interexchange carrier, a pre-paid telephone card service provider, etc.). A card must be activated prior to use by a customer. PINs and other such unique card codes act as keys into a card service provider's databases and database management systems to enable card activation/deactivation transactions initiated by retailers/resellers to be performed and to allow proper card use by card purchasers. Such PINs may be implemented as Pin Tracking Numbers to create a further level of abstraction and security related to a particular pin code/unique card identifier. Accordingly any reference to a PIN may also be a reference to another code like or similar to a PIN tracking number which may correspond to one or more PINs and/or prepaid cards.

Activation and other related operations and transactions (card deactivation, card re-charge, etc. as described below) are automatically carried out within the present invention through use of a messaging scheme that includes messages that are formatted at a point-of-sale by a POS system and which are transmitted to a processing center for operation by a card service provider. Once an activation message is received by a card service provider (e.g., an inter-exchange carrier) appropriate processing commences and a responsive message is generated and sent back to the requesting POS system. Accordingly, after a retail sale is completed, a card purchaser will be in possession of an activated card that may be used to obtain telephone services. The types of messages that are communicated within the present invention are discussed in detail below.

STRUCTURAL ASPECTS OF THE PRESENT INVENTION The structural aspects of the present invention are described with particular reference to FIGS. 1 -110.

Referring now to FIG. 1, depicted therein is a block diagram of a system in which pre-paid telephone calling cards (cards) may be activated within a point- of-sale (POS) system according to a preferred embodiment of the present invention. More particularly, system 100 includes a network architecture that enables POS activation of cards that may, for example, be sold and otherwise distributed by a retailer. System 100 includes a publicly switched telephone network (PSTN) 102, one or more POS devices (e.g., cash register systems, credit card terminals (e.g. , VERIFONE™ devices, etc.) 104, one or more additional POS devices 106 which are configured with dial-up facilities (e.g., modems, DTMF tone generators, etc.), POS controller systems (POSC hosts) 105, one or more service switching control points (SSCP) 108, a customer service center 110, one or more service data points (SDP) 112 (central data stores for card state and usage data), a wide area network system (WAN) 114, an automatic number identifier (AND server 116, and a WAN access switch 118. SSCPs 108 may be implemented using a switching system similar or like the AXE- 10 switching system with integrated service control functionality (SCF) which is manufactured and marketed by ERICSSON CORPORATION. Preferably, an SSCP according to the present invention is configured to run an ERICSSON AS- 701 application software load on an APZ 21220 processor within the AXE- 10 switching system. The SCF of SSCP 108 provides the capability of intelligent network services independent of underlying network topologies. SSCP 108 uses ISUP signaling in performing its call processing operations.

SDP 112 may be implemented using a TANDEM K20000 HIMALAYA SERVER with the GUARDIAN OPERATING SYSTEM manufactured and/or marketed by TANDEM CORPORATION. SDP 112 runs non-stop SQL, TCP/IP, SNAX/HLS, and ODBC (open database client) . SDP 112 is the database server for all activation related data corresponding to pre-paid telephone calling cards within the context of the present invention and, in particular, within the context of system 100.

The links connecting the aforementioned structures are well known and will be readily understood by those skilled in the art. For example, a host-to-host coupling of POSC 105 via an SNA link or X.25 link to SDP 112 will be readily understood by those skilled in the art.

In system 100 POSCs 105 are responsible for centralizing POS transactions from POS terminals and devices 104, for formatting activation related transaction messages, and for transmitting such messages to SDP 112 for processing. Accordingly, a set comprising a POSC 105 and one or more POS devices (e.g., cash register units, VERIFONE terminals, etc.) make up a point-of-sale system that may be operated and managed by a retailer. As such, System 100 supports several different types of message communication capabilities between a retailer's POS systems and a card processor that operates SDP 112 and other components and sub- systems within system 100. Such communications include host-to-host communications, automated dial-up communications, DTMF (telephone set keypad entry) communications, and live -operator customer service communications.

Host-to-host communications are carried out between a POSC 105 and SDP 112. Such communications may be carried out in accordance with the TCP/IP (via WAN 114), SNA/LU.O, SNA/LU.2, SNA/LU6.2 and X.25 protocols. Such communications are illustrated by the broad lines (links) between POSCs 105 and SDP 112.

Automated dial-up communications may be used to communicate activation related messages between

POSCs 105 and SDP 112. Such communications are carried out when a POSC 105 initiates a transaction request (and formats and transmits an appropriate message) to WAS 118 via asynchronous communications links over PSTN 102. Based on a received transaction request, SDP 112 will format and send a resultant message in a TCP/IP packet format. WAS 118 converts the resultant message to asynchronous data and sends it back to the requesting POSC 105. Accordingly, WAS 118 is used as a modem bank, a network access management tool, and a protocol converter. The VISA Second Generation (VISA- 2) Authorization Terminal Link Level Protocol- -External Link Specification 1051 is used for the asynchronous flow control between POSCs 105 and SDP 112. DTMF communications provide an alternative to card activators (retailers, etc.) to complete POS activation- related transactions. For example, DTMF communications are particularly useful when host-to- host and automated dial-up communications are not available. A retailer can take advantage of DTMF communications to access SSCP 108 to complete transactions via a toll free telephone call. When this method of communications is used, the retailer is instructed to enter required transaction information such as PASSCODE, PIN, Access Number (e.g., an access telephone number printed on the back of a card, etc.), etc. Such information will then be relayed to SDP 112 and processed accordingly. Any responsive messages generated by SDP 112 can be provided in the form of automatic voiced responses (e.g., voiced responses from a voice response unit (VRU) ) .

If any of the above-described types of communications are not available, a retailer can engage in live-operator communications by dialing a toll-free call to reach a live operator who can respond to transaction requests and the like. Additionally, if a time-out condition occurs during any other communications session (e.g., during a dial up session) , live-operator customer services can be automatically spawned.

Many of the structures and components included within system 100 are part of an intelligent services network often referred to in the telecommunications industry as an Intelligent Network (IN) . That IN is denoted by the box formed by phantom lines and referenced by numeral 120. In addition to SSCP 108 and SDP 112, IN 120 may also include other structures to perform other functions including, but not limited to, service management and application systems (SMASs) . Such other systems will be apparent to those skilled in the art. Accordingly, in addition to activation related processing to support activation of cards, IN 1N20 will support other functions such as call processing and management to enable end-user (consumer use) of cards. The structures described above are arranged and configured to format, transmit, receive, and process activation related messages related to cards that may be sold/distributed by retailers and others. In the context of the present invention, cards are manufactured (or caused to be manufactured) by a card service provider that generates and pre- loads (installs) corresponding card data entries in an SDP like SDP 112 (FIG. 1) . Such card data entries include states which a card may undergo during its use lifetime. The states which a card may take on are controlled in accordance with POS transactions according to the present invention. Such states are illustrated in a state-diagram in FIG. 2A to which reference is now made.

In FIG. 2A, a particular card may be in a GENERATED STATE, a SUSPENDED STATE (REFUND) , a SUSPENDED STATE (FRAUD) , an EXPIRED STATE, and an ACTIVE STATE. A card is in a GENERATED STATE after it has been manufactured and data related to the card

(PIN, access telephone number, etc.) have been recorded in SDP 112 or after a card and, in particular, its associated calling units have been used. A card, may be placed in a SUSPENDED STATE when a card purchaser requests a refund related to unused card usage units at a POS or otherwise. A card may be placed in a SUSPENDED STATE (FRAUD) when there is a fraud detected by SDP 112 relative to an associated PIN code. A card may be placed into an EXPIRED STATE when an expiration date associated with a particular PIN code has been reached (e.g., three years after a last use of a card). And, a card may be placed in an ACTIVE STATE (ready for use) upon purchase, refresh (telephone calling unit addition) , etc.. Those skilled in the art will readily appreciate the state changes illustrated in FIG. 2A. The states illustrated in FIG. 2A , relate to particular, individual cards. Activating single cards may become quite time-consuming when a purchaser seeks to purchase more than one card such as a batch of 12 or more cards or even a batch of batches (e.g., a gross of cards) . Additionally, the present invention contemplates a situation where a retailer can engage in an extra step during inventory operations, for example, to require that a batch of cards must be activated prior to allowing each particular card in a batch to be individually activated. The present invention and, in particular, system 100 can accommodate such transactions. The present invention allows batch operations (e.g., operations on more than one card at a time) such as Batch Activation (activation of more than one card/PIN - such as a batch of 12 cards-- at one time via a single transaction request, etc.). The state changes relative to a batch of cards are illustrated in FIG. 2B to which reference is now made.

A batch of cards (e.g., 12 cards) is said to be in an INACTIVE STATE when data about the batch is first installed in SDP 112. An INACTIVE STATE batch of cards may be activated before corresponding PINs associated with the individual cards in that batch can be activated. Accordingly, a batch of cards in an INACTIVE STATE 214 may be changed to possess an ACTIVE STATE 212. The transactions to bring about such state changes are described below.

Mentioned above were "messages" that include activation related requests from POS systems and corresponding responses from SDP 112. Such messages are intended to bring about state changes relative to cards issued in accordance with the present invention. That is, messages relate to a host of activation related transactions that can cause the state changes illustrated in FIGS. 2A and 2B. The transactions carried out within the present invention are centered around activation of a card and, more particularly, the activation of a PIN (or card number) within SDP 112 that corresponds to a card. A PIN is a unique card number or unique, serialized pin tracking number that is managed by SDP 112. A serialized pin tracking number will allow a POSC to transmit a unique identifier associated with a particular pre-paid telephone calling card. SDP 112, in turn, manages and controls states relative to a particular card in accordance with POS transactions. The following list illustrates the transactions (and corresponding messages) that may be processed within the context of the present invention and, in particular, in a system similar or like system 100 (FIG. 1) . The transactions listed below are further described and defined in the remaining sections of this patent document.

PIN Activation This transaction is used to activate a PIN when a card associated with that PIN is first purchased. A PIN can be activated only when it is in 'GENERATED STATE. ' PINs in any other states are not allowed for activation.

Multiple PIN Activation This transaction is used to activate multiple

PINs by making a single call/connection request within system 100. PINs are activated in a sequential manner.

Range PIN Activation This transaction is used to activate up to 12 cards at a time. By providing a starting PIN and ending PIN, a retailer can activate all PINs in the range.

Batch Activation

This transaction is used to activate all new PINs in a batch of cards . A batch can be activated only when it is in 'INACTIVE STATE.' Batches in any other states are not allowed for activation.

Multiple Batch Activation This transaction is used to activate multiple batches of cards making a single call/connection request. Batches are activated in a sequential manner. The processing on one batch is independent from the other.

Range Batch Activation This transaction is used to allow a reseller to activate up to 12 batches of cards at a time (e.g., up to 144 cards) . By providing a starting batch number and an ending batch number, a retailer can activate all cards in the batch range.

PIN Deactivation This transaction is used to void a PIN/card purchase when the card purchaser decides not to buy the card. A PIN can be deactivated only when it is in ^■ACTIVE STATE." A deactivated PIN can be re- stocked and sold to a next card purchaser by re-activating the PIN via PIN Activation. No money is refunded to the card purchaser,

Multiple PIN Deactivation This transaction is used to deactivate multiple cards/PINs by making a single call/connection request. PINs are deactivated in a sequential manner. The processing on one PIN is independent from the other.

Range PIN Deactivation This transaction is used to deactivate up to 12 cards/PINs at a time. By providing a starting PIN and an ending PIN, a retailer can deactivate all PINs in the range.

Batch Deactivation This transaction is used to deactivate all cards/PINs in a batch. Deactivated PINs can be restocked and sold to the next card buyer by reactivating the cards/PINs.

Multiple Batch Deactivation This transaction is used to deactivate multiple batches of cards/PINs by making a single call/connection request. Batches are deactivated in a sequential manner. The processing on one batch is independent from the other.

Range Batch Deactivation This transaction is used to deactivate up to 12 batches of cards at a time. By providing a starting batch number and an ending batch number, a retailer can deactivate all PINs in the batch range.

PIN Charge This transaction is used to activate a

'GENERATED STATE,' zero-unit card and add purchased units toward the card. The card is automatically activated when it is charged. The maximum number of units can be charged toward a card/PIN is 999 (e.g., 999 minutes) .

PIN Refresh This transaction is used to add additional purchased units to an 'ACTIVE STATE' card. The maximum number of units that can be refreshed may be calculated by subtracting the number of remaining units on the card from 999.

PIN Refund This transaction is used to refund all units remaining on an 'ACTIVE STATE' card. After a refund, a card is suspended and can not be sold or re -activated.

Echo This transaction is used to allow a POSC or a host to verify that a Data Communication Protocol (SNA, X.25, TCP/IP, etc.) and the Database Server (e.g., SDP 112) are operational.

The above- listed message types have been designed to fit within a standard message format relative to the type of communications between a POS system and SDP 112. That is, standard message types have been defined for host-to-host communications and for automatic dial-up communications. In the case of DTMF -based communications, a user manually interacts with a voice response unit and, as such, automated messages are not applicable. And, in the case of live- operator communications, there again is no need for automated, standard message formats as all SDP interaction is through a live operator. The following paragraphs describe the structural aspects of standard message formats for host-to-host communications and for automatic dial-up communications.

Referring now to FIG. 3, depicted therein is a table that illustrates a standard transaction request message format deployed in accordance with a preferred embodiment of the present invention to enable activation- related messages (e.g., PIN Activation, etc.) to be communicated via a host-to-host connection from a point -of sale system to a card service provider (e.g., SDP 112). All inputs to SDP 112 via a host-to- host connection preferably should be in the ASCII character set unless specifically noted otherwise. Data elements contained within a message formatted in accordance with the format illustrated in FIG. 3 are categorized into three types of level of preference: MANDATORY DATA (M) - A data element that must be communicated. • OPTIONAL DATA (0) - A data element is required on for certain cases. If not required, the data element should be padded with padding characters (e.g., spaces, etc.). Certain data flows described below will use OPTIONAL DATA. • OMITTABLE DATA (T) - A data element that is populated only when a processing flag is to be set. If a processing flag is not to be set, the data element should be completely removed from the message. Additionally, the notation used in FIG. 3 indicates that data may take on several different types:

• ALPHA/NUMERIC DATA (X)

• NUMERIC DATA (9) • Implicit decimal point for numeric digits (V)

- (E.g., 9(6)v9(2) indicates a numeric value with two decimal places)

• BCD numeric digit string (B)

• Hexadecimal string (H) Accordingly, the table in FIG. 3 illustrates the content of a POS transaction request message (e.g., for PIN activation, etc.). The system data is "fixed data" that never changes. However, the "user data" indicates that variable portion of message that a user (e.g., a retailer's POSC, etc.) can reformat for different messages. The values in the table in FIG. 3 are byte lengths that may take on any values to suit particular design requirements. Moreover, the data elements carried in a message formatted in accordance with Fig. 3 may change to suit particular messaging requirements. Accordingly, the present invention is not limited to the message structure illustrated and exemplified in FIG. 3. The descriptions found in FIG. 3 corresponding to each identified data element specify the exact nature of such data. Accordingly, for purposes of brevity a further detailed discussion of FIG. 3 is omitted. Referring now to FIG. 4, depicted therein is a table that illustrates a standard transaction response message format deployed in accordance with a preferred embodiment of the present invention to enable activation- related messages (e.g., PIN Activation Status Response, etc.) to be communicated via a host- to-host connection from a card service provider (e.g. , SDP 112) to a point-of-sale system. The data elements defined in a responsive message from SDP 112 formatted in accordance with the message format defined in FIG. 4 have the same data types as described above in reference to FIG. 3. The descriptions found in FIG. 4 corresponding to each identified data element specify the exact nature of such data. Accordingly, for purposes of brevity a further detailed discussion of FIG. 4 is omitted.

Referring now to FIG. 5, depicted therein is a table that illustrates a standard message format deployed in accordance with a preferred embodiment of the present invention to enable activation related messages to be communicated via an automated dial-up connection from a point-of-sale system to a card service provider (e.g., SDP 112). All inputs to SDP 112 via an automated dial-up connection preferably should be in the ASCII character set unless specifically noted otherwise. Data elements contained within a message formatted in accordance with the format illustrated in FIG. 3 are categorized into three types of level of preference:

MANDATORY DATA (M) - A data element that must be communicated.

• OPTIONAL DATA (0) - A data element is required on for certain cases. If not required, the data element should be padded with padding characters (e.g., spaces, etc.). Certain data flows described below will use OPTIONAL DATA. OMITTABLE DATA (T) - A data element that is populated only when a processing flag is to be set. If a processing flag is not to be set, the data element should be completely removed from the message.

Additionally, the notation used in FIG. 5 indicates that data may take on several different types :

ALPHA/NUMERIC DATA (X) NUMERIC DATA (9)

• Implicit decimal point for numeric digits (V) - (E.g., 9(6)v9(2) indicates a numeric value with two decimal places)

• BCD numeric digit string (B)

• Hexadecimal string (H) Accordingly, the table in FIG. 5 illustrates the content of a POS transaction request message (e.g., for PIN Activation, etc.). The system data is "fixed data" that never changes. However, the "user data" indicates that variable portion of message that a user (e.g., a retailer's POSC, etc.) can reformat for different messages. The values in the table in FIG. 5 are byte lengths that may take on any values to suit particular design requirements. Moreover, the data elements carried in a message formatted in accordance with FIG. 5 may change to suit particular messaging requirements. Accordingly, the present invention is not limited to the message structure illustrated and exemplified in FIG. 5. The descriptions found in FIG. 5 corresponding to each identified data element specify the exact nature of such data. Accordingly, for purposes of brevity a further detailed discussion of FIG. 5 is omitted.

FIG. 6 is a table that illustrates a standard message format deployed in accordance with a preferred embodiment of the present invention to enable activation-related messages to be communicated via an automated dial-up connection from a card service provider (e.g., SDP 112) to a point-of-sale system.

MESSAGE FLOWS The structures described above are configured to operate together to allow pre-paid telephone calling cards to be activated (or otherwise processed) at a point-of-sale within a retailer/reseller establishment. The present invention provides such functionality via standard formatted messages (transaction requests and corresponding responses) that are communicated between a POSC (e.g., POSC 105 - FIG. 1) and an SDP within an IN network (e.g., SDP 112 - FIG. 1). Accordingly, the following paragraphs refer to FIGS. 7-110 to illustrate the flow of messages to execute transactions in accordance with those described above (e.g., PIN

Activation for a particular pre-paid telephone calling card) . FIGS. 7-18 illustrate message flows in a host- to-host communications arrangement, whereas FIGS 19-30 illustrate message flows in an automated dial-up communications arrangement. FIGS. 31-110 illustrate message flows in a DTMF communications arrangement. The message flows illustrated in FIGS. 7-110 are vertically arranged data and call flow diagrams. That is, time is experienced in the downward direction while data (as formatted in a standard form message format in accordance with the present invention - FIGS. 3-6) is illustrated as passing from one structure to another (e.g., from a POSC 105 to an SDP 112 and vice- versa as illustrated in FIGS. 7-18) . Referring now to FIGS. 7-18, depicted therein are message flows related to the flow of data between a POSC like POSCs 105 and an SDP like SDP 112 (e.g., within system 100 as shown in FIG. 1) via host-to-host communications. The message flows depicted in FIGS. 7- 18 relate to messages formatted in accordance with the message formats defined in FIGS. 3 and 4. Transactions for which messages will flow as depicted in FIGS. 7-18 may cause state changes to cards as illustrated in FIGS. 2A and 2B. It should be understood that any transactions related to cards in accordance with the present invention may access, retrieve, modify, and add data related to one or more cards for which data is stored in SDP 112. In the following discussions, references are made to activating, deactivating, or otherwise processing transactions related to a "PIN." This reference is a shorthand intended to refer to the transactions and operations that are carried out or otherwise performed relative to the data stored in SDP 112 for a particular pre-paid telephone calling card or group of cards. For example, "PIN Activation" is intended to indicate that data (including state data, etc.) stored within SDP 112 may be reviewed, changed, etc. to bring about a particular result (state change, etc.) relative to a particular card or group of cards (e.g., activation of a pre-paid telephone calling card for use by a card purchaser) . Host-to-Host Communications

Referring now to FIG. 7, depicted therein is a message- flow diagram for PIN activation. In successfully performing PIN activation, SDP 12 checks certain conditions to make sure that a PIN is allowed to be activated. For example, the PIN status must be in a generated state, the card expiration must not have been reached, and the purchase price must be within predefined business price range limits. Such data is maintained and managed by SDP 112 as the central store for card setup and usage. SDP must change the PIN status from generated to active once a PIN activation transaction is complete. If the activation type is equal to POS Batch (as described above) SDP 112 must increment a data field in the record of a batch table corresponding to the appropriate PIN by one to activate more than one card via one activation transaction. The SDP calculates the unit rate by dividing the purchase price by number of unit and stores the unit rate accordingly. The unit rate can be used for later refunds and reporting, etc.. Additionally, the SDP sets the new PIN expiration date to be the date of the current date plus the activation duration (e.g., three years from date of last use, etc.) and sets the activation to be the current date. The SDP also indicates that the completion status is successful when reason code is set to 000. Finally, the SDP will log transaction details and generate a corresponding responsive message and submit/transmit the same to a requesting POSC system.

Referring now to FIG. 8, depicted therein is a message- flow diagram when a PIN activation request fails. A PIN activation may fail when there is a unit mismatch between the data submitted by the point of sale controller and the units stored in the SDP before activating the PIN. Additionally, a failure will occur when the POS controller attempts to activate an already active PIN. Moreover, a failure may occur when the POS controller attempts to activate an expired PIN.

Additionally, a failure on PIN activation will occur when the POS controller attempts to activate a suspended PIN, which was suspended because of fraud, etc.. Finally, a failure condition will occur when the purchase price of the card/PIN does not fit a particular business rule. Such a business rule may be mandated by the card processor or provider or retailer/reseller.

Below, other messages and corresponding transactions are described. Since such messages are communicated relative to particular transactions like the PIN activation message/transaction illustrated in FIG. 7, verbose descriptions of such message flows are omitted. Accordingly, for purposes of brevity, only a summary of each message flow is next described, Where appropriate for clarification, however, additional discussion is provided. Referring now to FIG. 9, depicted therein is a message- flow diagram for PIN deactivation.

Referring now to FIG. 10, depicted therein is a message- flow diagram for failure conditions related to PIN deactivation. An error on PIN deactivation will occur when a POS controller attempts to deactivate an unused PIN, to deactivate a generated PIN, to deactivate an expired PIN, and when POS controller attempts to deactivate a suspended PIN.

Referring now to FIG. 11, depicted therein is a message- flow diagram for PIN charge.

Referring now to FIG. 12, depicted therein is a message-flow diagram for PIN charge failure conditions. In particular, an error on PIN charge will occur when a POS controller attempts to charge a non- zero unit PIN/card, to charge units not in a particular range

(e.g., outside of a time limit such as "999 units"), to charge an already active PIN, to charge an expired PIN, or to charge a suspended PIN.

Referring now to FIG. 13, depicted therein is a message- flow diagram for PIN refresh.

Referring now to FIG. 14, depicted therein is a message-flow diagram for PIN refresh failure conditions. An error on PIN refresh will occur when a POSC attempts to refresh a card/PIN that is not refreshable, when the number of refreshed units is not in a particular range, when the POS controller attempts to refresh a generated PIN, when the POS controller attempts to refresh an expired PIN, when the POS controller attempts to refresh a suspended PIN, when the POS controller attempts to do a redundant refresh operation, and when the POS controller attempts to do a refresh beyond certain allowed units, etc. Referring now to FIG. 15, depicted therein is a message-flow diagram for PIN refund.

Referring now to Fig. 16, depicted therein is a message- flow diagram relating to error conditions on PIN refund. An error on a PIN refund transaction will occur when POS controller attempts a refund on a generated PIN, when a POS controller attempts a refund on an expired PIN, and when a POS controller attempts a refund on a suspended PIN.

Referring now to FIG. 17, depicted therein is a message- flow diagram related to an Echo Transaction Request and corresponding responses. The scenario depicted in FIG. 17 allows a POS controller or host to test system availability. Requests are accepted by the protocol and routed to SDP 112. SDP 112 verifies the message and responds accordingly. Such requests and responses indicate whether the protocol of an application are operational. This message may also be referred to as a heartbeat message or test message.

Referring now to FIG. 18, depicted therein is a message- flow diagram related to Echo Transaction

Request failure conditions. In the message sent back from SDP 112, error codes or notes will be contained in a reason code response area of the message. Such error conditions include database server unavailability, etc..

Dial -Up Communications Referring now to FIGS. 19-30, depicted therein are message flows related to the flow of data between a POSC like POSCS 105 and SDP 112 via automated modem dial-up communications. The messages that flow between POS and SDP 112 flow via a WAN access system, such as WAN access system 118 in FIG. 1. The message flows depicted in FIGS. 19-30 relate to messages formatted in accordance with the message format definitions depicted in FIGS. 5 and 6. Transactions for which messages will flow as depicted in FIGS. 19-30 may cause state changes to cards as illustrated in FIGS. 2A and 2B. It should be understood that any transactions related to cards in accordance with the present invention may access, retrieve, modify, and add data related to one or more cards for which data is stored in SDP 112.

Referring now to FIG. 19, depicted therein is a message- flow diagram for PIN activation.

Referring now to FIG. 20, depicted therein is a message- flow diagram for failure conditions related to PIN activation. A failure condition on PIN activation will occur if a POS controller attempts to activate an already active PIN, activate an expired PIN, activate a suspended PIN, or if a purchase price does not fit a business rule. For example, a purchase price will not fit a business rule if the price charged for a particular card is more than a service provider's top- line value, etc.

Referring now to FIG. 21, depicted therein is a message- flow diagram for PIN deactivation.

Referring now to FIG. 22, depicted therein is a message- flow diagram for PIN deactivation failure conditions. A failure condition on PIN deactivation will occur if a POS controller attempts to deactivate a used PIN number or code, to deactivate a generated PIN, to deactivate an expired PIN, or to deactivate a suspended PIN.

Referring now to FIG. 23, depicted therein is a message- flow diagram for PIN charge transactions. Referring now to FIG. 24, depicted therein is a message flow diagram for PIN charge failure conditions.

PIN charge failure conditions will occur when a POS controller attempts to charge a non- zero unit PIN, to charge units not in a particular range, such as 1-999 telephone calling units, to charge an already active

PIN, to charge an expired PIN, or to charge a suspended

PIN.

Referring now to FIG. 25, depicted therein is a message-flow, diagram for PIN refresh transactions. Referring now to FIG. 26, depicted therein is a message- flow diagram for PIN refresh failure conditions. The failure conditions related to PIN refresh are the same as those described above with regard to host-to-host connections. Referring now to FIG. 27, depicted therein is a message- flow diagram for PIN refund transactions.

Referring now to FIG. 28, depicted therein is a message- flow diagram for PIN refund failure conditions.

A refund failure condition will occur when a POS controller attempts to refund a generated PIN, an expired PIN, or a suspended PIN.

Referring now to FIG. 29, depicted therein is a message- flow diagram for Echo Transactions.

Referring now to FIG. 30, depicted therein is a message -flow diagram for Echo Transaction failure conditions. An echo failure condition will occur, for example, if the POS controller is unable to appropriately access the database within the SDP. DTMF (User- Interaction) Communications Referring now to FIGS. 31-110, depicted therein are data-flow diagrams related to the flow of data between POSCs 105 and SDP 112 via DTMF communications. Such communications usually will be carried out at the option of retailer/reseller personnel who choose to access SDP 112 by manually initiating an "activation/deactivation" call via a telephone coupled to the PSTN. Once routed and connected to SSCP 108 as part of IN network 120 (via the PSTN and an appropriate access telephone number) , a caller operates his keypad to enter appropriate DTMF sequences to control SDP 112 in the performance of activation and deactivation transactions . The data flows depicted in FIGS. 31-110 relate to DTMF sequences submitted to an SDP via an SSCP in accordance with the present invention. Moreover, transactions caused as a result of DTMF inputs may cause state changes to cards as illustrated in Figs.2A and 2B. It should be understood that any transactions related to cards in accordance with the present invention retrieve, modify, and add data related to one or more cards for which data is stored in SDP 112. It is also important to note that the use of DTMF signaling to cause state change data within SDP 112 requires certain user validation transactions to ensure security and validity of data that is entered. Such user validation and security transactions will be readily understood by those skilled in the art. It is important to note that for purposes of clarity, FIGS. 31-110 are referred to as data-flow diagrams instead of message- flow diagrams. This is the case since a message like that for host -to -host communications is not actually generated between a POSC and SDP 112. Instead, messaging is logically carried out based on user responses to voiced inquiries from SSCP 108. As there are many possible outcomes and intermediate steps associated with call processing to effectuate DTMF communications (e.g., a caller making a DTMF call to an SSCP for card activation may abruptly or prematurely terminate that call) , processes need to be in place to handle various processing scenarios. Such scenarios are illustrated in FIGS. 31-110 as described below.

Referring now to FIG. 31, depicted therein is a data-flow diagram related to successful authorization validation.

Referring now to FIG. 32, depicted therein is a data flow diagram for validation authorization failure. Referring now to FIG. 33, depicted therein is a data flow diagram for POS featured in transactions. In FIG. 33, the acronym "PTN" refers to a PIN tracking number, which is to be considered a unique, serialized number corresponding to a PIN associated with a particular pre-paid telephone calling card. In a preferred embodiment, a PIN and an access telephone number (e.g., a 1-800 number) create a unique key into databases managed by SDP 112. A PTN is unique across all access telephone numbers responded to by SDP 112. Accordingly, a card may actually possess a PTN instead of a PIN. Thus, references to PTN in FIGS. 31-110 may be replaced with PIN and vice-versa. All that is required is that a unique key be formed for SDP processing related to a particular card or group of cards . Referring now to FIG. 34, depicted therein is a data-flow diagram for batch transactions via DTMF communications .

Referring now to FIG. 35, depicted therein is a data-flow diagram for PIN activation of multiple PINs according to a preferred embodiment of the present invention.

Referring now to FIG. 36, depicted therein is a data-flow diagram for responding to a DTMF sequence for activation of a non- existing PIN.

Referring now to FIG. 37, depicted therein is a data-flow diagram corresponding to a DTMF sequence for activating a locked PIN. A PIN is locked when it has been deactivated and has been rendered inoperable and not -currently usable by SDP 112.

Referring now to FIG. 38, depicted therein is a data-flow diagram that illustrates a situation in which an error has occurred upon DTMF entry and a customer (e.g., retailer/reseller personnel) will not be allowed to activate a PIN belonging to another card issuer.

Referring now to FIG. 39, depicted therein is a data-flow diagram that illustrates the flow of data in response to a DTMF sequence attempting to activate a used PIN. Referring now to FIG. 40, depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate an already active card.

Referring now to FIG. 41, depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate an expired card.

Referring now to FIG. 42, depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate a suspended card. Referring now to FIG. 43, depicted therein is a data-flow diagram illustrating the case where a caller abandons a call after SDP application 30 is launched. Application 30 will be launched after the SSCP has completed collection of information from the caller and has requested the SDP to perform PIN activation.

Referring now to FIG. 44, depicted therein is a data-flow diagram that illustrates a DTMF sequence for activating a range of PINS according to a preferred embodiment of the present invention.

Referring now to FIG. 45, depicted therein is a data-flow diagram illustrating a DTMF sequence that caused an error condition based upon an invalid entry of either a PIN tracking number or PIN. Referring now to FIG. 46, depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate non-existing PINS.

Referring now to FIG. 47, depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate locked PINS.

Referring now to FIG. 48, depicted therein is a data-flow diagram that illustrates a DTMF sequence calling for activation of certain PINs where the caller does not have proper authorization or may not be considered the owner of such PINS.

Referring now to FIG. 49, depicted therein is a data-flow diagram corresponding to a DTMF sequence that attempts to activate used PINS.

Referring now to FIG. 50, depicted therein, is a data-flow diagram that illustrates a corresponding

DTMF sequence that attempts to activate already active cards . Referring now to FIG. 51, depicted therein is a data-flow diagram illustrating a DTMF sequence that attempts to activate an expired card/PIN.

Referring now to FIG. 52, depicted therein is a data-flow diagram illustrating a DTMF sequence that attempts to activate suspended cards .

Referring now to FIG. 53, depicted therein is a data-flow diagram that illustrates a situation after a caller has abandoned his call, after SSCP has launched application 30 (as described above) .

Referring now to FIG. 54, depicted therein is a data-flow diagram illustrating a DTMF sequence for batch activation of batch PINS.

Referring now to FIG. 55, depicted therein is a data-flow diagram illustrating a caller's attempt to activate a non- existing batch of PINs/cards.

Referring now to FIG. 56, depicted therein is a data-flow diagram illustrating a caller's attempt to activate a locked batch of PINs. Referring now to FIG. 57, depicted therein is a data-flow diagram that illustrates an SDP's responsive message indicating invalid ownership of PIN codes entered during DTMF entry.

Referring now to FIG. 58, depicted therein is a data-flow diagram of a caller's attempt to activate an already active batch of PINs.

Referring now to FIG. 59, depicted therein is a data-flow diagram illustrating a case where a caller abandons his telephone call after SSCP 108 has launched application 25. Application 25 is normally invoked by an SSCP after it has collected all information from the ^■caller and has requested SDP for batch activation of PINS. Referring now to FIG. 60, depicted therein is a data-flow diagram illustrating a range batch activation transaction in accordance with a DTMF instruction for the same. Referring now to Fig. 61, depicted therein is a data-flow diagram illustrating a situation where a caller's batch number or batch range specifics are invalid (e.g., outside of a particular valid range).

Referring now to FIG. 62, depicted therein is a data-flow diagram illustrating a caller's attempt to activate non -existing batches.

Referring now to FIG. 63, depicted therein is a data-flow diagram illustrating a caller's attempt to activate locked batches in accordance with a DTMF sequence.

Referring now to FIG. 64, depicted therein is a data-flow diagram that illustrates an error situation on range batch activation based upon invalid ownership of batch numbers and the like. Referring now to FIG. 65, depicted therein is a data-flow diagram illustrating a caller's attempt to activate already active batches.

Referring now to FIG. 66, depicted therein is a data-flow diagram that illustrates a situation where a caller abandons his call to SSCP 108 after an SSCP has launched application 25. Application 25 is normally invoked by SSCP after SSCP completes collection of all information from the caller and has requested an SDP for a range batch activation process. Referring now to FIG. 67, depicted therein is a data-flow diagram illustrating PIN deactivation for multiple PINs. Referring now to FIG. 68, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a non- existing PIN.

Referring now to FIG. 69, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a locked PIN.

Referring now to FIG. 70, depicted therein is a data-flow diagram that illustrates a situation in which an error occurs based upon a caller's invalid ownership of an entered PIN tracking number or PIN.

Referring now to FIG. 71, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a used PIN.

Referring now to FIG. 72, depicted therein is a data-flow diagram illustrating a caller's attempt to deactivate a generated card.

Referring now to FIG. 73, depicted therein is a data-flow diagram illustrating a caller's attempt to deactivate an expired card/PIN. Referring now to FIG. 74, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a suspended card.

Referring now to FIG. 75, depicted therein is a data-flow diagram that illustrates a situation in which a caller abandons his telephone call to an SSCP after an SSCP has launched application 30. Application 30, as noted above is normally invoked to trigger an SDP to engage in a PIN deactivation transaction.

Referring now to FIG. 76, depicted therein is a data-flow diagram that illustrates a range PIN deactivation transaction.

Referring now to FIG. 77, depicted therein is a data-flow diagram that illustrates a situation in which an SDP will respond to a caller's DTMF entry when an invalid PTN or PTN range has been entered by the caller.

Referring now to FIG. 78, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate non- existing PINS.

Referring now to FIG. 79, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate locked PINs.

Referring now to FIG. 80, depicted therein is a data-flow diagram that illustrates a situation_^ in which an SDP will respond to a user's DTMF entry and indicate that the user does not own the entered PIN or PIN tracking number.

Referring now to FIG. 81, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate used PINs via DTMF entry.

Referring now to FIG. 82, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate generated cards via DTMF entry. Referring now to FIG. 83, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate expired cards via DTMF entry.

Referring now to FIG. 84, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate suspended cards via DTMF entry.

Referring now to FIG. 85, depicted therein is a data-flow diagram that illustrates a situation in which a caller abandons his telephone call after an SSCP has completed the collection of information from the caller and has requested the SDP for PIN deactivation by invoking SDP application 30. Referring now to FIG. 86, depicted therein is a data-flow diagram that illustrates batch deactivation for multiple batches of PINs via DTMF communications.

Referring now to FIG. 87, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a non- existing batch of PINs/cards.

Referring now to FIG. 88, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a locked batch of PINs . Referring now to FIG. 89, depicted therein is a data-flow diagram that illustrates a situation in which a caller has entered a DTMF sequence that does not correspond to a particular set of batches (e.g., the caller is not the appropriate owner/representative for the entered batch numbers) .

Referring now to FIG. 90, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate an inactive batch of PINs .

Referring now to FIG. 91, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a batch containing active PINs via DTMF communications .

Referring now to FIG. 92, depicted therein is a data-flow diagram that illustrates a situation in which a caller abandons his call to an SSCP after the SSCP has completed collecting information from the caller and has requested an SDP to engage in batch deactivation transactions by invoking SDP application 25.

Referring now to FIG. 93, depicted therein is a data-flow diagram illustrating range batch deactivation via DTMF communications.

Referring now to Fig. 94, depicted therein is a data-flow diagram illustrating a situation in which a caller has entered an invalid batch number or batch range via DTMF communication.

Referring now to FIG. 95, depicted therein is a data-flow diagram that illustrates a user's attempt to deactivate non- existing batches.

Referring now to FIG. 96, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate locked batches of PINs.

Referring now to FIG. 97, depicted therein is a data-flow diagram that illustrates a situation in which a caller has entered batch numbers that he or his organization owns.

Referring to now FIG. 98, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate inactive batches.

Referring now to FIG. 99, depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate batches containing active PINs.

Referring now to FIG. 100, depicted therein is a data-flow diagram that illustrates a situation in which a caller abandons his telephone call to an SSCP after the SSCP has completed collecting information from the caller and has requested an SDP to engage in range batch deactivation transactions by invoking SDP application 25. Referring now to FIG. 101, depicted therein is a data-flow diagram that illustrates a PIN refund transaction via DTMF communications.

Referring now to FIG. 102, depicted therein is a data-flow diagram that illustrates a situation in which a caller attempts to refund on a non -existing PIN.

Referring now to FIG. 103, depicted therein is a data-flow diagram that illustrates a situation in which caller attempts to refund on a locked PIN. Referring now to FIG. 104, depicted therein is a data-flow diagram that illustrates a situation in which a caller enters information that does not correspond to PINs that the caller and/or his organization owns. Referring now to FIG. 105, depicted therein is a data-flow diagram that illustrates a caller's attempt to refund a generated card.

Referring now to FIG. 106, depicted therein is a data-flow diagram that illustrates a caller's attempt to refund an expired card.

Referring now to FIG. 107, depicted therein is a data-flow diagram that illustrates a caller's attempt to refund a suspended card.

Referring now to FIG. 108, depicted therein is a data-flow diagram that illustrates a situation in which a caller attempts to seek a refund amount that is greater than a maximum dollar/money amount. The scenario depicted in FIG. 109 describes the refund amount that is greater than the maximum money allowed, for example $999.00 US. Under normal system operation, this scenario should not occur. However, if it does occur, a refund should be rejected.

Referring now to FIG. 109, depicted therein is a data-flow diagram illustrating a situation in which a caller abandons his telephone call to an SSCP after the SSCP has launched SDP application 30, for completing a refund transaction.

Referring now to FIG. 110, depicted therein is a data-flow diagram illustrating a situation in which a caller abandons his telephone call to an SSCP after the SSCP has completed collecting information from the caller and has requested the SDP to update PIN information related to the refund. DATA AND CALL FLOWS FOR ACTIVATION/DEACTIVATION VIA DTMF COMMUNICATIONS To further illustrate the data-flow diagrams discussed above with regard to DTMF communications, the following paragraphs describe call sequences initiated by a caller (e.g., retail store personnel) to engage in card/PIN related transactions (e.g., activation, deactivation, batch activation, range batch deactivation, etc.). Such transactions are intended to cause state changes to one or more cards as illustrated in FIGS. 2A and 2B. To illustrate such operations, reference is now made to the flowcharts contained within FIGS. HIA-HIS. Those skilled in the art will readily appreciate and understand the call flows illustrated in the flowcharts of FIGS.

HIA-HIS. It should be noted, however, that the data and call flows illustrated in FIGS. IHA-IHS are exemplary and actual implementations may take on different features that require different processing and the like.

Referring now to FIGS. HIA-HIS, depicted therein are flowcharts that illustrate the salient operations that may be carried out within system 100 (FIG. 1) to cause activation-related transactions and card/PIN state changes as described above. Many of the operations carried out within FIGS. IHA-IHS are intended to be performed automatically through use of computer hardware and software. The routines and programs necessary to bring about the illustrated functionality will be readily apparent to those skilled in the art after reviewing the data and call flows illustrated in FIGS. IHA-IHS. Referring now to FIG. HIA, processing and call flow start at SI and immediately proceed to S2. At S2 and after a caller has called a 1-800 access to engage in

DTMF communications and corresponding PIN/card activation transactions, a voice message (from a VRU) will be played to him. That message may indicate that the caller has reached a service provider's prepaid POS service. Call flow then proceeds to S3 where the caller is prompted to enter a pass code. At S5, system routines will wait for user input. At S7, system routines will determine whether or not the caller entered a valid pass code. If not, processing proceeds to S6, where an invalid entry notification will be voiced to the caller via his telephone call and a looping construct is thereby formed through the determination S4 back to S3. The number of tries a caller may be allowed to enter a valid pass code can be set based on specific implementation parameters.

If at S7 a valid pass code was not entered, processing proceeds at the top of FIG. HIC. If at S5 a timeout occurs processing proceeds at the top of FIG.

111B.

At the top of HIB, and in particular, at S8, a timeout has occurred and system routines will voice an indication to the caller thanking him for using the POS service via DTMF communications .

Processing proceeds at the top of FIG. HIC, and in particular, at S10, where a voice prompt asking a caller to press a DTMF sequence for activating PTN batches, deactivating PTN batches or for refunding a PTN. At Sll, a system routine timing loop will be initiated and if a timeout occurs, processing will proceed to as described at the top of FIG. HIB. If a timeout does not occur, processing proceeds to S12, where a case is made as to the type of inputs supplied by the user. That is, if the user entered a 1, 2, or 3 or other character via DTMF entry appropriate case logic will direct further call flow and processing, Accordingly at S13, the caller will be allowed a certain number of maximum retries in order to enter appropriate DTMF digits to properly mandate call flow. Accordingly, a looping structure is formed through S14, at which point a voice prompt will be voiced to the caller back to S10.

If the caller intended to activate either a particular PIN number or batch of the same, processing proceeds at the top of FIG. HID. At S15, the caller will be prompted with a voice request to enter further DTMF digits corresponding to the type of activation in which the caller wishes to engage. At S16, a familiar waiting for input loop will be initiated and if a timeout occurs, precessing proceeds again at the top of FIG. HIB. If no timeout occurs, the entered DTMF digits by the caller will be evaluated in appropriate case logic at S17 to direct further call flow and processing. Step 18 is configured to determine if a maximum number of retries has been hit thereby forming a loop between steps S18, S19, S15, S16, and S17. If, at S17, it is determined that the caller intends to engage in an activation transaction for a particular card, processing proceeds at the top of FIG. Ill E. At S20, a voice response to the caller requesting the caller to enter the card tracking number to be activated (i.e., the PIN). At S21, a determination is made as to whether or not the card is already activated. If the card is already activated, a voice response is played at S22 and processing and call flow stops at S23.

If, at S21, the card is not already activated, a familiar waiting for input loop is initiated and if no input is provided call flow and processing stops at S25. At S26, a determination is made as to whether or not there was valid input of a particular PIN number. If not, processing proceeds to S28 where a looping structure is created between steps S28, S31, S24, and S26. If, at S26, valid input was received from the caller, a determination is made as to whether or not the PIN active default scenario or transaction should be carried out. If not, processing proceeds to S30, where voice responses are played to the caller at S40 and processing a call flow terminate at S41. It should also be noted, that if maximum retries at S28 are reached then a voice response is played to the caller at S33, which also is followed by S40 and S41.

If, at S27, a PIN active default transaction is to occur, processing proceeds to S29.

At S29, the state change of the card will be set to active within an SDP. At S32, a voiced response to the caller directing the caller to press certain digits to go to certain menu options will be played. Thereafter, at S34 and at S35, a familiar timeout waiting sequence is initiated. If the caller enters a particular DTMF sequence (e.g., asterisks), appropriate case logic at S36 will be carried out to direct further call flow and processing. At S37, a max retries loop is again initiated and if a certain number of maximum retries is met upon invalid entry by a user, the user will be prompted with a voice response thanking him for activating a particular card and processing will end at S39.

If at S17 in FIG. HID, the caller desires to deactivate a range of PIN tracking numbers, processing proceeds at the top of FIG. HIF. At S42, a voice response is played to the caller requesting the entry of the first card number of the cards to be activated. At S43, system routines will engage in a familiar waiting for input routine and logic and if a timeout occurs, processing will proceed as earlier described at the top of HIB. At S44, a second voiced response requesting the caller to enter the last card number to be activated will be played. At S45, a familiar waiting for input routine will commence. At S46, a determination will be made whether the last number and entered is greater than the first number. If not, processing proceeds to S51, where a voice response is played to the caller indicating that the last number is greater than the first number, processing then proceeds to S52 to go through a max retries scenario as earlier described and a loop is created through steps S42, S43, S44, S45, and S46.

If at S46, the last number (of a batch) is less than or equal to the first number, processing proceeds to S47. At S47, a determination will be made whether the card range is within 12 (i.e., 12 cards). If not, a voice response is played at S50 to caller and processing proceeds thereafter to S52 as earlier described. If the card range is within 12, processing proceeds to steps S48, S49, S53, S54, S55, S56, S57, and ultimately to S58.

If at S49, activation was not successful, processing proceeds at the top of FIG. 111G. FIG. HIG contains steps S60, S61, S62, S63, and S64. These steps are directed to playing an appropriate error message and prompting a caller to enter DTMF sequences to go back to previous menus and the like. If at S17 (FIG. HID) , the caller intended to engage in batch activation for a batch of cards/PINs, processing proceeds at the top of HIH. In particular, FIG. HIH contains steps S65, S66, S67, S68, S69, S70, S80, S81, S82, S83, S84, S85, S86, S87, S88, S89, and ultimately S90. These steps are directed to entering a batch number for activation and performing appropriate processing as described therein.

If at S17, it is determined that the caller intended to activate a range of batches, processing proceeds at the top of FIG. 1111. FIG. 1111 is directed to processes and corresponding call flows for activating a range of batches of cards. In particular, FIG. 1111 includes steps S91, S92, S93, S94, S95, S96, S97, S98, S99, S100, S101, S102, S103, S104, S105, S106, and ultimately, S107.

FIG. HIJ includes steps S108, S109, SHO, SHI, and S112, which are directed to error handling in accordance with call flows depicted in FIG. 1111.

If, at S12, it was determined that the caller intended to engage in deactivation of PINS or batches of the same, processing proceeds at the top of FIG. HlK for deactivation processes. In FIG. HIK, steps S113, S114, S115, S116, and S117 are directed to providing prompts to a caller and for directing further call flow. Step 15 directs further call flow as defined in FIGS. HIL, HIM, HIN, 1110, HIP, and FIG. HIQ, as next described.

FIG. HIL includes steps S118, S119, S120, S121, S122, S123, S124, S125, S126, S127, S128, S129, S130, S131, S132, and S133. These steps are directed to prompting a caller for appropriate information related to card deactivation.

FIG. HIM includes steps S134, S135, S136, S137, S138, S139, S140, S141, S142, S143, S144, S145, S146, S147, S148, S149, and S150. These steps are directed to card range deactivation and are similar in nature to other processes carried out as described above. Accordingly, for purposes of brevity, further discussion is omitted. Referring now to FIG. HIN, steps S151, S152,

S153, S154, and S155 are contained therein. These steps are directed to playing certain messages in the context card range deactivation and processing accordingly. Referring now to FIG. 1110, depicted therein are call flow and process steps to be carried out for PIN batch deactivation. FIG. 1110 includes steps S156 2, S157, S157-2, S158, S159, S160, S161, S162, S163, S164, S165, S166, S167, S168, S169, and S170. These steps are carried out to form batch PIN deactivation and are similar to other method steps previously described.

Referring now to FIG. HIP, depicted therein are steps S171, S172, S173, S174, S175, S176, S177, S178, S179, S180, S181, S182, S183, S184, S185, S186, and S187. These steps are carried out to enable a caller to engage in batch range deactivation for multiple batches of PINs/cards. Referring now to FIG. 111Q, depicted therein are steps S188, S189, S190, S191, S192. These steps are similar to previous method steps as described above. These steps are directed to error handling and menu directing within the processes for batch range deactivation.

Referring now to FIG. HlR, depicted therein are steps S193, S194, S195, S196, S197, S198, S199, and S201. The steps depicted in FIG. HlR are directed to PIN refund transactions and include the steps illustrated in FIG. HIS discussed below.

In FIG. HIS, further processes are carried out to enable refund transactions to be performed via DTMF communications. In particular, FIG. HIS includes steps S202-2, S203, S204, S205, S206, S207, S208, S209, S210, S211, S212, and S213. These steps are directed to further enabling refunds to occur.

Thus, having fully described the present invention by way of example with reference to the attached drawing figures, it will be readily appreciated that many changes and modifications may be made to the invention and to any of the exemplary embodiments shown and/or described herein without departing from the spirit or scope of the invention, which is defined in the appended claims.

Claims

1. A system for processing a pre-paid telephone calling card during a point-of-sale transaction, comprising: a point-of-sale system operative to receive a transaction request relative to a pre-paid telephone calling card during a point-of-sale transaction and to transmit said transaction request; and a pre-paid telephone calling card processing system coupled to said point-of-sale system and operative to receive said transaction request from said point-of-sale system, to perform a transaction in accordance with said transaction request, and to transmit a status response message to said point -of - sale system, said status response message indicating whether said transaction was performed in accordance with said transaction request.

2. The system according to claim 1, wherein said point- of-sale system is further operative to automatically process retail sales transactions.

3. The system according to claim 1, wherein said point- of-sale system is further operative to transmit data relating to said pre-paid calling card to said pre-paid telephone calling card processing system.

4. The system according to claim 3, wherein said data relating to said pre-paid telephone calling card includes a number corresponding to usage minutes .

5. The system according to claim 3, wherein said data relating to said pre-paid telephone calling card includes a number corresponding to a purchase price for said pre-paid telephone calling card.

6. The system according to claim 1, wherein said transaction request is an activation message corresponding to an activation process to be performed by said pre-paid telephone calling card processing system, said pre-paid telephone calling card being activated and ready for use after said pre-paid telephone calling card processing system performs said activation process.

7. The system according to claim 1, wherein said transaction request is a deactivation message corresponding to an deactivation process to be performed by said pre-paid telephone calling card processing system, said pre-paid telephone calling card being deactivated after said pre-paid telephone calling card processing system performs said deactivation process.

8. The system according to claim 1, wherein said transaction request is a multiple card activation message corresponding to a multiple card activation process to be performed by said pre-paid telephone calling card processing system to activate a plurality of pre-paid telephone calling cards, said plurality of pre-paid telephone calling cards being activated and ready for use after said pre-paid telephone calling card processing system performs said multiple card activation process.

9. The system according to claim 1, wherein said transaction request is a multiple card deactivation message corresponding to a multiple card deactivation process to be performed by said pre-paid telephone calling card processing system to deactivate a plurality of pre-paid telephone calling cards, said plurality of pre-paid telephone calling cards being deactivated after said pre-paid telephone calling card processing system performs said multiple card deactivation process.

10. The system according to claim 1, wherein said point- of-sale system and said pre-paid telephone calling card system are coupled via a host-to-host connection.

11. The system according to claim 1, wherein said point- of-sale system and said pre-paid telephone calling card system are coupled via a dial-up connection through a publicly switched telephone network.

12. A method for processing a pre-paid telephone calling card during a point-of-sale transaction, comprising the steps of: receiving a transaction request relative to a pre-paid telephone calling card at a point-of-sale system; transmitting said transaction request; receiving said transaction request at a pre- paid telephone card processing system; performing a transaction in accordance with said transaction request; and transmitting a status response message to said point-of-sale system, said status response message indicating whether said transaction was performed in accordance with said transaction request.

13. The method according to claim 12, wherein said transaction request is an activation message corresponding to an activation process to be performed by said pre-paid telephone calling card processing system, said pre-paid telephone calling card being activated and ready for use after said pre-paid telephone calling card processing system performs said activation process.

14. The method according to claim 12, wherein said transaction request is a deactivation message corresponding to a deactivation process to be performed by said pre-paid telephone calling card processing system, said pre-paid telephone calling card being deactivated after said pre-paid telephone calling card processing system performs said deactivation process.

15. The method according to claim 12, wherein said transaction request is a multiple card activation message corresponding to a multiple card activation process to be performed by said pre-paid telephone calling card processing system to activate a plurality of pre-paid telephone calling cards, said plurality of pre-paid telephone calling cards being activated and ready for use after said pre-paid telephone calling card processing system performs said multiple card activation process.

6. The method according to claim 12, wherein said transaction request is a multiple card deactivation message corresponding to a multiple card deactivation process to be performed by said pre-paid telephone calling card processing system to deactivate a plurality of pre-paid telephone calling cards, said plurality of pre-paid telephone calling cards being deactivated after said pre-paid telephone calling card processing system performs said multiple card deactivation process.

17. A system for processing a pre-paid telephone calling card during a point-of-sale transaction, comprising: a data storage system storing state data related to a pre-paid telephone calling card; and a pre-paid telephone calling card processing system coupled to said data storage system and configured to receive a transaction request related to said pre-paid telephone calling card during a point -of - sale transaction, to perform a transaction in accordance with said transaction request, and to change said state data stored within said data storage system based on said transaction.

18. The system according to claim 17, wherein said transaction request is an activation message corresponding to an automatic activation process to be performed by said pre-paid telephone calling card processing system, said pre-paid telephone calling card being activated and ready for use after said pre-paid telephone calling card processing system performs said automatic activation process.

19. The system according to claim 17, wherein said transaction request is a deactivation message corresponding to an automatic deactivation process to be performed by said pre-paid telephone calling card processing system, said pre-paid telephone calling card being deactivated after said pre-paid telephone calling card processing system performs said automatic deactivation process.

20. The system according to claim 17, wherein said prepaid telephone calling card processing system receives said transaction request from a point-of-sale system coupled to said pre-paid telephone calling card processing system.

21. The system according to claim 17, wherein said prepaid telephone calling card processing system is further operative to transmit a response message to said point-of-sale system indicating that said transaction was performed.

22. The system according to claim 17, wherein said transaction request includes a unique card tracking number, said unique card tracking number uniquely identifying said pre-paid telephone card.

23. The system according to claim 17, wherein said transaction request includes a card usage parameter, pre-paid telephone calling card storing said card usage parameter in said data storage system, said card usage parameter affecting the use of said card after said pre- paid telephone card processing system performs said transaction.

24. The system according to claim 23, wherein said card usage parameter is a number of call usage units to be associated with said pre-paid telephone calling card.

25. A system for processing pre-paid telephone calling cards during a point-of-sale transaction, comprising: a data storage system storing state data related to a plurality of pre-paid telephone calling cards ; and a pre-paid telephone calling card processing system coupled to said data storage system and configured to receive a transaction request related to said plurality of pre-paid telephone calling cards during a point-of-sale transaction, to perform a transaction in accordance with said transaction request, and to change said state data stored within said data storage system based on said transaction.

26. The system according to claim 25, wherein said transaction request is a multiple card activation message corresponding to a multiple card activation process to be performed by said pre-paid telephone calling card processing system to activate a said plurality of pre-paid telephone calling cards, said plurality of pre-paid telephone calling cards being activated and ready for use after said pre-paid telephone calling card processing system performs said multiple card activation process.

7. The system according to claim 25, wherein said transaction request is a multiple card deactivation message corresponding to a multiple card deactivation process to be performed by said pre-paid telephone calling card processing system to deactivate said plurality of pre-paid telephone calling cards said plurality of pre-paid telephone calling cards being deactivated after said pre-paid telephone calling card processing system performs said multiple card deactivation process.

28. A method for processing a pre-paid telephone calling card during a point-of-sale transaction, comprising the steps of: storing state data related to a pre-paid telephone calling card; receiving a transaction request related to said pre-paid telephone calling card during a point-of- sale transaction; performing a transaction in accordance with said transaction request; and changing said state data stored within said data storage system based on said transaction

29. The method according to claim 28, wherein said transaction request is an activation message corresponding to an activation process, said method further comprising the step of performing said activation process, said pre-paid telephone calling card being activated and ready for use after said activation process has been performed.

30. The method according to claim 28, wherein said transaction request is a deactivation message corresponding to a deactivation process, said method further comprising the step of performing said deactivation process, said pre-paid telephone calling card being deactivated after said deactivation process has been performed.

31. The method according to claim 28, further comprising the step of transmitting a response message indicating that said transaction was performed.

32. The method according to claim 28, wherein said transaction request includes a unique card tracking number, said unique card tracking number uniquely identifying said pre-paid telephone card.

33. The method according to claim 28, wherein said transaction request includes a card usage parameter intended to affect the use of said card after said transaction has been performed.

34. The method according to claim 33, wherein said card usage parameter is a number of call usage units to be associated with said pre-paid telephone calling card.